From ffb37ca3bd16ce6ea2df2f87fde9a31e94ebb54b Mon Sep 17 00:00:00 2001 From: Al Viro Date: Thu, 1 Apr 2021 19:00:57 -0400 Subject: switch file_open_root() to struct path ... and provide file_open_root_mnt(), using the root of given mount. Signed-off-by: Al Viro --- Documentation/filesystems/porting.rst | 9 +++++++++ 1 file changed, 9 insertions(+) (limited to 'Documentation') diff --git a/Documentation/filesystems/porting.rst b/Documentation/filesystems/porting.rst index 0302035781be..9bb2b35f90bb 100644 --- a/Documentation/filesystems/porting.rst +++ b/Documentation/filesystems/porting.rst @@ -890,3 +890,12 @@ been called or returned with non -EIOCBQUEUED code. mnt_want_write_file() can now only be paired with mnt_drop_write_file(), whereas previously it could be paired with mnt_drop_write() as well. + +--- + +**mandatory** + +Calling conventions for file_open_root() changed; now it takes struct path * +instead of passing mount and dentry separately. For callers that used to +pass mnt_root> pair (i.e. the root of given mount), a new helper +is provided - file_open_root_mnt(). In-tree users adjusted. -- cgit v1.2.3 From bcba1e7d0d520adba895d9e0800a056f734b0a6a Mon Sep 17 00:00:00 2001 From: Al Viro Date: Thu, 1 Apr 2021 22:03:41 -0400 Subject: take LOOKUP_{ROOT,ROOT_GRABBED,JUMPED} out of LOOKUP_... space Separate field in nameidata (nd->state) holding the flags that should be internal-only - that way we both get some spare bits in LOOKUP_... and get simpler rules for nd->root lifetime rules, since we can set the replacement of LOOKUP_ROOT (ND_ROOT_PRESET) at the same time we set nd->root. Signed-off-by: Al Viro --- Documentation/filesystems/path-lookup.rst | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/filesystems/path-lookup.rst b/Documentation/filesystems/path-lookup.rst index c482e1619e77..ede67f705787 100644 --- a/Documentation/filesystems/path-lookup.rst +++ b/Documentation/filesystems/path-lookup.rst @@ -1321,18 +1321,18 @@ to lookup: RCU-walk, REF-walk, and REF-walk with forced revalidation. yet. This is primarily used to tell the audit subsystem the full context of a particular access being audited. -``LOOKUP_ROOT`` indicates that the ``root`` field in the ``nameidata`` was +``ND_ROOT_PRESET`` indicates that the ``root`` field in the ``nameidata`` was provided by the caller, so it shouldn't be released when it is no longer needed. -``LOOKUP_JUMPED`` means that the current dentry was chosen not because +``ND_JUMPED`` means that the current dentry was chosen not because it had the right name but for some other reason. This happens when following "``..``", following a symlink to ``/``, crossing a mount point or accessing a "``/proc/$PID/fd/$FD``" symlink (also known as a "magic link"). In this case the filesystem has not been asked to revalidate the name (with ``d_revalidate()``). In such cases the inode may still need to be revalidated, so ``d_op->d_weak_revalidate()`` is called if -``LOOKUP_JUMPED`` is set when the look completes - which may be at the +``ND_JUMPED`` is set when the look completes - which may be at the final component or, when creating, unlinking, or renaming, at the penultimate component. Resolution-restriction flags -- cgit v1.2.3 From 7169d082e7e623209081318abc26b0d899a4e63f Mon Sep 17 00:00:00 2001 From: Parshuram Thombare Date: Sat, 10 Apr 2021 20:15:08 +0200 Subject: dt-bindings: drm/bridge: MHDP8546 bridge binding changes for HDCP Add binding changes for HDCP in the MHDP8546 DPI/DP bridge binding. Signed-off-by: Parshuram Thombare Reviewed-by: Rob Herring Signed-off-by: Robert Foss Link: https://patchwork.freedesktop.org/patch/msgid/1618078508-30466-1-git-send-email-pthombar@cadence.com --- .../devicetree/bindings/display/bridge/cdns,mhdp8546.yaml | 15 +++++++++++---- 1 file changed, 11 insertions(+), 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/bridge/cdns,mhdp8546.yaml b/Documentation/devicetree/bindings/display/bridge/cdns,mhdp8546.yaml index 63427878715e..2333fdbe9296 100644 --- a/Documentation/devicetree/bindings/display/bridge/cdns,mhdp8546.yaml +++ b/Documentation/devicetree/bindings/display/bridge/cdns,mhdp8546.yaml @@ -18,7 +18,7 @@ properties: reg: minItems: 1 - maxItems: 2 + maxItems: 3 items: - description: Register block of mhdptx apb registers up to PHY mapped area (AUX_CONFIG_P). @@ -26,13 +26,16 @@ properties: included in the associated PHY. - description: Register block for DSS_EDP0_INTG_CFG_VP registers in case of TI J7 SoCs. + - description: + Register block of mhdptx sapb registers. reg-names: minItems: 1 - maxItems: 2 + maxItems: 3 items: - const: mhdptx - const: j721e-intg + - const: mhdptx-sapb clocks: maxItems: 1 @@ -99,14 +102,18 @@ allOf: properties: reg: minItems: 2 + maxItems: 3 reg-names: minItems: 2 + maxItems: 3 else: properties: reg: - maxItems: 1 + minItems: 1 + maxItems: 2 reg-names: - maxItems: 1 + minItems: 1 + maxItems: 2 required: - compatible -- cgit v1.2.3 From 2916059147ea38f76787d7b38dee883da2e9def2 Mon Sep 17 00:00:00 2001 From: Thomas Zimmermann Date: Mon, 12 Apr 2021 15:10:41 +0200 Subject: drm/aperture: Add infrastructure for aperture ownership Platform devices might operate on firmware framebuffers, such as VESA or EFI. Before a native driver for the graphics hardware can take over the device, it has to remove any platform driver that operates on the firmware framebuffer. Aperture helpers provide the infrastructure for native drivers to remove the generic ones. For now, this only concerns generic fbdev drivers. Code for removing these is provided by drm_fb_helper_remove_conflicting_framebuffers() et al. Simply wrap these functions for now. At a later point, code can be added for generic DRM drivers to acquire firmware framebuffers. v2: * fix docs for drm_aperture_remove_framebuffers() Signed-off-by: Thomas Zimmermann Acked-by: Daniel Vetter Acked-by: Jani Nikula Link: https://patchwork.freedesktop.org/patch/msgid/20210412131043.5787-2-tzimmermann@suse.de --- Documentation/gpu/drm-internals.rst | 12 ++++++++++++ 1 file changed, 12 insertions(+) (limited to 'Documentation') diff --git a/Documentation/gpu/drm-internals.rst b/Documentation/gpu/drm-internals.rst index 12272b168580..06af044c882f 100644 --- a/Documentation/gpu/drm-internals.rst +++ b/Documentation/gpu/drm-internals.rst @@ -75,6 +75,18 @@ update it, its value is mostly useless. The DRM core prints it to the kernel log at initialization time and passes it to userspace through the DRM_IOCTL_VERSION ioctl. +Managing Ownership of the Framebuffer Aperture +---------------------------------------------- + +.. kernel-doc:: drivers/gpu/drm/drm_aperture.c + :doc: overview + +.. kernel-doc:: include/drm/drm_aperture.h + :internal: + +.. kernel-doc:: drivers/gpu/drm/drm_aperture.c + :export: + Device Instance and Driver Handling ----------------------------------- -- cgit v1.2.3 From 0c1a77cbdafb0e1874a42284479f3d6023b91f90 Mon Sep 17 00:00:00 2001 From: Matthew Auld Date: Mon, 19 Apr 2021 11:57:39 +0100 Subject: drm/doc: add section for driver uAPI Add section for drm/i915 uAPI and pull in i915_drm.h. Suggested-by: Daniel Vetter Signed-off-by: Matthew Auld Cc: Joonas Lahtinen Cc: Jordan Justen Cc: Daniel Vetter Cc: Kenneth Graunke Cc: Jason Ekstrand Cc: Dave Airlie Cc: dri-devel@lists.freedesktop.org Cc: mesa-dev@lists.freedesktop.org Reviewed-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20210419105741.27844-2-matthew.auld@intel.com --- Documentation/gpu/driver-uapi.rst | 8 ++++++++ Documentation/gpu/index.rst | 1 + 2 files changed, 9 insertions(+) create mode 100644 Documentation/gpu/driver-uapi.rst (limited to 'Documentation') diff --git a/Documentation/gpu/driver-uapi.rst b/Documentation/gpu/driver-uapi.rst new file mode 100644 index 000000000000..4411e6919a3d --- /dev/null +++ b/Documentation/gpu/driver-uapi.rst @@ -0,0 +1,8 @@ +=============== +DRM Driver uAPI +=============== + +drm/i915 uAPI +============= + +.. kernel-doc:: include/uapi/drm/i915_drm.h diff --git a/Documentation/gpu/index.rst b/Documentation/gpu/index.rst index ec4bc72438e4..b9c1214d8f23 100644 --- a/Documentation/gpu/index.rst +++ b/Documentation/gpu/index.rst @@ -10,6 +10,7 @@ Linux GPU Driver Developer's Guide drm-kms drm-kms-helpers drm-uapi + driver-uapi drm-client drivers backlight -- cgit v1.2.3 From b7745a160a23d9bcaf5bb7a6b3b1a586e8f12e2b Mon Sep 17 00:00:00 2001 From: Phong LE Date: Mon, 19 Apr 2021 09:12:21 +0200 Subject: dt-bindings: display: bridge: add it66121 bindings Add the ITE bridge HDMI it66121 bindings. Signed-off-by: Phong LE Signed-off-by: Neil Armstrong Reviewed-by: Rob Herring Reviewed-by: Laurent Pinchart Link: https://patchwork.freedesktop.org/patch/msgid/20210419071223.2673533-2-narmstrong@baylibre.com --- .../bindings/display/bridge/ite,it66121.yaml | 124 +++++++++++++++++++++ 1 file changed, 124 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/bridge/ite,it66121.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/bridge/ite,it66121.yaml b/Documentation/devicetree/bindings/display/bridge/ite,it66121.yaml new file mode 100644 index 000000000000..6ec1d5fbb8bc --- /dev/null +++ b/Documentation/devicetree/bindings/display/bridge/ite,it66121.yaml @@ -0,0 +1,124 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/bridge/ite,it66121.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: ITE it66121 HDMI bridge Device Tree Bindings + +maintainers: + - Phong LE + - Neil Armstrong + +description: | + The IT66121 is a high-performance and low-power single channel HDMI + transmitter, fully compliant with HDMI 1.3a, HDCP 1.2 and backward compatible + to DVI 1.0 specifications. + +properties: + compatible: + const: ite,it66121 + + reg: + maxItems: 1 + + reset-gpios: + maxItems: 1 + description: GPIO connected to active low reset + + vrf12-supply: + description: Regulator for 1.2V analog core power. + + vcn33-supply: + description: Regulator for 3.3V digital core power. + + vcn18-supply: + description: Regulator for 1.8V IO core power. + + interrupts: + maxItems: 1 + + ports: + $ref: /schemas/graph.yaml#/properties/ports + + properties: + port@0: + $ref: /schemas/graph.yaml#/$defs/port-base + unevaluatedProperties: false + description: DPI input port. + + properties: + endpoint: + $ref: /schemas/graph.yaml#/$defs/endpoint-base + unevaluatedProperties: false + + properties: + bus-width: + description: + Endpoint bus width. + enum: + - 12 # 12 data lines connected and dual-edge mode + - 24 # 24 data lines connected and single-edge mode + default: 24 + + port@1: + $ref: /schemas/graph.yaml#/properties/port + description: HDMI Connector port. + + required: + - port@0 + - port@1 + +required: + - compatible + - reg + - reset-gpios + - vrf12-supply + - vcn33-supply + - vcn18-supply + - interrupts + - ports + +additionalProperties: false + +examples: + - | + #include + #include + i2c { + #address-cells = <1>; + #size-cells = <0>; + + it66121hdmitx: hdmitx@4c { + compatible = "ite,it66121"; + pinctrl-names = "default"; + pinctrl-0 = <&ite_pins_default>; + vcn33-supply = <&mt6358_vcn33_wifi_reg>; + vcn18-supply = <&mt6358_vcn18_reg>; + vrf12-supply = <&mt6358_vrf12_reg>; + reset-gpios = <&pio 160 GPIO_ACTIVE_LOW>; + interrupt-parent = <&pio>; + interrupts = <4 IRQ_TYPE_LEVEL_LOW>; + reg = <0x4c>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + it66121_in: endpoint { + bus-width = <12>; + remote-endpoint = <&display_out>; + }; + }; + + port@1 { + reg = <1>; + hdmi_conn_out: endpoint { + remote-endpoint = <&hdmi_conn_in>; + }; + }; + }; + }; + }; -- cgit v1.2.3 From bbbb6fdaa3ce083b1ca9ea9f774c22da9a5dafde Mon Sep 17 00:00:00 2001 From: Daniel Vetter Date: Wed, 21 Apr 2021 17:29:11 +0200 Subject: drm/todo: Add link to old debugfs RFC I always forget where it was, store it until this gets picked up by an internship again. Cc: Wambui Karuga Cc: Melissa Wen Acked-by: Melissa Wen Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20210421152911.1871473-1-daniel.vetter@ffwll.ch --- Documentation/gpu/todo.rst | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst index 7ff9fac10d8b..12e61869939e 100644 --- a/Documentation/gpu/todo.rst +++ b/Documentation/gpu/todo.rst @@ -546,6 +546,8 @@ There's a bunch of issues with it: this (together with the drm_minor->drm_device move) would allow us to remove debugfs_init. +Previous RFC that hasn't landed yet: https://lore.kernel.org/dri-devel/20200513114130.28641-2-wambui.karugax@gmail.com/ + Contact: Daniel Vetter Level: Intermediate -- cgit v1.2.3 From 6c525b72f985e967f8d171a7d3f9210c4018decd Mon Sep 17 00:00:00 2001 From: Linus Walleij Date: Tue, 6 Apr 2021 01:47:12 +0200 Subject: drm/panel: Add DT bindings for Samsung LMS397KF04 This adds device tree bindings for the Samsung LMS397KF04 RGB DPI display panel. Cc: devicetree@vger.kernel.org Signed-off-by: Linus Walleij Reviewed-by: Rob Herring Reviewed-by: Douglas Anderson Link: https://patchwork.freedesktop.org/patch/msgid/20210405234713.3190693-1-linus.walleij@linaro.org --- .../bindings/display/panel/samsung,lms397kf04.yaml | 74 ++++++++++++++++++++++ 1 file changed, 74 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/panel/samsung,lms397kf04.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/panel/samsung,lms397kf04.yaml b/Documentation/devicetree/bindings/display/panel/samsung,lms397kf04.yaml new file mode 100644 index 000000000000..4cb75a5f2e3a --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/samsung,lms397kf04.yaml @@ -0,0 +1,74 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/panel/samsung,lms397kf04.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Samsung LMS397KF04 display panel + +description: The datasheet claims this is based around a display controller + named DB7430 with a separate backlight controller. + +maintainers: + - Linus Walleij + +allOf: + - $ref: panel-common.yaml# + +properties: + compatible: + const: samsung,lms397kf04 + + reg: true + + reset-gpios: true + + vci-supply: + description: regulator that supplies the VCI analog voltage + usually around 3.0 V + + vccio-supply: + description: regulator that supplies the VCCIO voltage usually + around 1.8 V + + backlight: true + + spi-max-frequency: + $ref: /schemas/types.yaml#/definitions/uint32 + description: inherited as a SPI client node, the datasheet specifies + maximum 300 ns minimum cycle which gives around 3 MHz max frequency + maximum: 3000000 + + port: true + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + #include + + spi { + #address-cells = <1>; + #size-cells = <0>; + panel@0 { + compatible = "samsung,lms397kf04"; + spi-max-frequency = <3000000>; + reg = <0>; + vci-supply = <&lcd_3v0_reg>; + vccio-supply = <&lcd_1v8_reg>; + reset-gpios = <&gpio 1 GPIO_ACTIVE_LOW>; + backlight = <&ktd259>; + + port { + panel_in: endpoint { + remote-endpoint = <&display_out>; + }; + }; + }; + }; + +... -- cgit v1.2.3 From 2bc9c04ea7020df3a98682f12c50e38870d3104a Mon Sep 17 00:00:00 2001 From: Matthew Auld Date: Thu, 29 Apr 2021 11:30:48 +0100 Subject: drm/doc/rfc: i915 DG1 uAPI MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Add an entry for the new uAPI needed for DG1. Also add the overall upstream plan, including some notes for the TTM conversion. v2(Daniel): - include the overall upstreaming plan - add a note for mmap, there are differences here for TTM vs i915 - bunch of other suggestions from Daniel v3: (Daniel) - add a note for set/get caching stuff - add some more docs for existing query and extensions stuff - add an actual code example for regions query - bunch of other stuff (Jason) - uAPI change(!): - try a simpler design with the placements extension - rather than have a generic setparam which can cover multiple use cases, have each extension be responsible for one thing only v4: (Daniel) - add some more notes for ttm conversion - bunch of other stuff (Jason) - uAPI change(!): - drop all the extra rsvd members for the region_query and region_info, just keep the bare minimum needed for padding v5: (Jason) - for the upstream plan, add a requirement that we send the uAPI bits again for final sign off before turning it on for real - document how we intend to extend the rsvd bits for the region query (Kenneth) - improve the comment for the smem+lmem mmap mode and caching Signed-off-by: Matthew Auld Cc: Joonas Lahtinen Cc: Thomas Hellström Cc: Daniele Ceraolo Spurio Cc: Lionel Landwerlin Cc: Jon Bloomfield Cc: Jordan Justen Cc: Daniel Vetter Cc: Kenneth Graunke Cc: Jason Ekstrand Cc: Dave Airlie Cc: dri-devel@lists.freedesktop.org Cc: mesa-dev@lists.freedesktop.org Acked-by: Daniel Vetter Acked-by: Dave Airlie Acked-by: Kenneth Graunke Acked-by: Jon Bloomfield Link: https://patchwork.freedesktop.org/patch/msgid/20210429103056.407067-1-matthew.auld@intel.com --- Documentation/gpu/rfc/i915_gem_lmem.h | 237 ++++++++++++++++++++++++++++++++ Documentation/gpu/rfc/i915_gem_lmem.rst | 131 ++++++++++++++++++ Documentation/gpu/rfc/index.rst | 4 + 3 files changed, 372 insertions(+) create mode 100644 Documentation/gpu/rfc/i915_gem_lmem.h create mode 100644 Documentation/gpu/rfc/i915_gem_lmem.rst (limited to 'Documentation') diff --git a/Documentation/gpu/rfc/i915_gem_lmem.h b/Documentation/gpu/rfc/i915_gem_lmem.h new file mode 100644 index 000000000000..d9c61bea0556 --- /dev/null +++ b/Documentation/gpu/rfc/i915_gem_lmem.h @@ -0,0 +1,237 @@ +/** + * enum drm_i915_gem_memory_class - Supported memory classes + */ +enum drm_i915_gem_memory_class { + /** @I915_MEMORY_CLASS_SYSTEM: System memory */ + I915_MEMORY_CLASS_SYSTEM = 0, + /** @I915_MEMORY_CLASS_DEVICE: Device local-memory */ + I915_MEMORY_CLASS_DEVICE, +}; + +/** + * struct drm_i915_gem_memory_class_instance - Identify particular memory region + */ +struct drm_i915_gem_memory_class_instance { + /** @memory_class: See enum drm_i915_gem_memory_class */ + __u16 memory_class; + + /** @memory_instance: Which instance */ + __u16 memory_instance; +}; + +/** + * struct drm_i915_memory_region_info - Describes one region as known to the + * driver. + * + * Note that we reserve some stuff here for potential future work. As an example + * we might want expose the capabilities for a given region, which could include + * things like if the region is CPU mappable/accessible, what are the supported + * mapping types etc. + * + * Note that to extend struct drm_i915_memory_region_info and struct + * drm_i915_query_memory_regions in the future the plan is to do the following: + * + * .. code-block:: C + * + * struct drm_i915_memory_region_info { + * struct drm_i915_gem_memory_class_instance region; + * union { + * __u32 rsvd0; + * __u32 new_thing1; + * }; + * ... + * union { + * __u64 rsvd1[8]; + * struct { + * __u64 new_thing2; + * __u64 new_thing3; + * ... + * }; + * }; + * }; + * + * With this things should remain source compatible between versions for + * userspace, even as we add new fields. + * + * Note this is using both struct drm_i915_query_item and struct drm_i915_query. + * For this new query we are adding the new query id DRM_I915_QUERY_MEMORY_REGIONS + * at &drm_i915_query_item.query_id. + */ +struct drm_i915_memory_region_info { + /** @region: The class:instance pair encoding */ + struct drm_i915_gem_memory_class_instance region; + + /** @rsvd0: MBZ */ + __u32 rsvd0; + + /** @probed_size: Memory probed by the driver (-1 = unknown) */ + __u64 probed_size; + + /** @unallocated_size: Estimate of memory remaining (-1 = unknown) */ + __u64 unallocated_size; + + /** @rsvd1: MBZ */ + __u64 rsvd1[8]; +}; + +/** + * struct drm_i915_query_memory_regions + * + * The region info query enumerates all regions known to the driver by filling + * in an array of struct drm_i915_memory_region_info structures. + * + * Example for getting the list of supported regions: + * + * .. code-block:: C + * + * struct drm_i915_query_memory_regions *info; + * struct drm_i915_query_item item = { + * .query_id = DRM_I915_QUERY_MEMORY_REGIONS; + * }; + * struct drm_i915_query query = { + * .num_items = 1, + * .items_ptr = (uintptr_t)&item, + * }; + * int err, i; + * + * // First query the size of the blob we need, this needs to be large + * // enough to hold our array of regions. The kernel will fill out the + * // item.length for us, which is the number of bytes we need. + * err = ioctl(fd, DRM_IOCTL_I915_QUERY, &query); + * if (err) ... + * + * info = calloc(1, item.length); + * // Now that we allocated the required number of bytes, we call the ioctl + * // again, this time with the data_ptr pointing to our newly allocated + * // blob, which the kernel can then populate with the all the region info. + * item.data_ptr = (uintptr_t)&info, + * + * err = ioctl(fd, DRM_IOCTL_I915_QUERY, &query); + * if (err) ... + * + * // We can now access each region in the array + * for (i = 0; i < info->num_regions; i++) { + * struct drm_i915_memory_region_info mr = info->regions[i]; + * u16 class = mr.region.class; + * u16 instance = mr.region.instance; + * + * .... + * } + * + * free(info); + */ +struct drm_i915_query_memory_regions { + /** @num_regions: Number of supported regions */ + __u32 num_regions; + + /** @rsvd: MBZ */ + __u32 rsvd[3]; + + /** @regions: Info about each supported region */ + struct drm_i915_memory_region_info regions[]; +}; + +#define DRM_I915_GEM_CREATE_EXT 0xdeadbeaf +#define DRM_IOCTL_I915_GEM_CREATE_EXT DRM_IOWR(DRM_COMMAND_BASE + DRM_I915_GEM_CREATE_EXT, struct drm_i915_gem_create_ext) + +/** + * struct drm_i915_gem_create_ext - Existing gem_create behaviour, with added + * extension support using struct i915_user_extension. + * + * Note that in the future we want to have our buffer flags here, at least for + * the stuff that is immutable. Previously we would have two ioctls, one to + * create the object with gem_create, and another to apply various parameters, + * however this creates some ambiguity for the params which are considered + * immutable. Also in general we're phasing out the various SET/GET ioctls. + */ +struct drm_i915_gem_create_ext { + /** + * @size: Requested size for the object. + * + * The (page-aligned) allocated size for the object will be returned. + * + * Note that for some devices we have might have further minimum + * page-size restrictions(larger than 4K), like for device local-memory. + * However in general the final size here should always reflect any + * rounding up, if for example using the I915_GEM_CREATE_EXT_MEMORY_REGIONS + * extension to place the object in device local-memory. + */ + __u64 size; + /** + * @handle: Returned handle for the object. + * + * Object handles are nonzero. + */ + __u32 handle; + /** @flags: MBZ */ + __u32 flags; + /** + * @extensions: The chain of extensions to apply to this object. + * + * This will be useful in the future when we need to support several + * different extensions, and we need to apply more than one when + * creating the object. See struct i915_user_extension. + * + * If we don't supply any extensions then we get the same old gem_create + * behaviour. + * + * For I915_GEM_CREATE_EXT_MEMORY_REGIONS usage see + * struct drm_i915_gem_create_ext_memory_regions. + */ +#define I915_GEM_CREATE_EXT_MEMORY_REGIONS 0 + __u64 extensions; +}; + +/** + * struct drm_i915_gem_create_ext_memory_regions - The + * I915_GEM_CREATE_EXT_MEMORY_REGIONS extension. + * + * Set the object with the desired set of placements/regions in priority + * order. Each entry must be unique and supported by the device. + * + * This is provided as an array of struct drm_i915_gem_memory_class_instance, or + * an equivalent layout of class:instance pair encodings. See struct + * drm_i915_query_memory_regions and DRM_I915_QUERY_MEMORY_REGIONS for how to + * query the supported regions for a device. + * + * As an example, on discrete devices, if we wish to set the placement as + * device local-memory we can do something like: + * + * .. code-block:: C + * + * struct drm_i915_gem_memory_class_instance region_lmem = { + * .memory_class = I915_MEMORY_CLASS_DEVICE, + * .memory_instance = 0, + * }; + * struct drm_i915_gem_create_ext_memory_regions regions = { + * .base = { .name = I915_GEM_CREATE_EXT_MEMORY_REGIONS }, + * .regions = (uintptr_t)®ion_lmem, + * .num_regions = 1, + * }; + * struct drm_i915_gem_create_ext create_ext = { + * .size = 16 * PAGE_SIZE, + * .extensions = (uintptr_t)®ions, + * }; + * + * int err = ioctl(fd, DRM_IOCTL_I915_GEM_CREATE_EXT, &create_ext); + * if (err) ... + * + * At which point we get the object handle in &drm_i915_gem_create_ext.handle, + * along with the final object size in &drm_i915_gem_create_ext.size, which + * should account for any rounding up, if required. + */ +struct drm_i915_gem_create_ext_memory_regions { + /** @base: Extension link. See struct i915_user_extension. */ + struct i915_user_extension base; + + /** @pad: MBZ */ + __u32 pad; + /** @num_regions: Number of elements in the @regions array. */ + __u32 num_regions; + /** + * @regions: The regions/placements array. + * + * An array of struct drm_i915_gem_memory_class_instance. + */ + __u64 regions; +}; diff --git a/Documentation/gpu/rfc/i915_gem_lmem.rst b/Documentation/gpu/rfc/i915_gem_lmem.rst new file mode 100644 index 000000000000..1d344c593018 --- /dev/null +++ b/Documentation/gpu/rfc/i915_gem_lmem.rst @@ -0,0 +1,131 @@ +========================= +I915 DG1/LMEM RFC Section +========================= + +Upstream plan +============= +For upstream the overall plan for landing all the DG1 stuff and turning it for +real, with all the uAPI bits is: + +* Merge basic HW enabling of DG1(still without pciid) +* Merge the uAPI bits behind special CONFIG_BROKEN(or so) flag + * At this point we can still make changes, but importantly this lets us + start running IGTs which can utilize local-memory in CI +* Convert over to TTM, make sure it all keeps working. Some of the work items: + * TTM shrinker for discrete + * dma_resv_lockitem for full dma_resv_lock, i.e not just trylock + * Use TTM CPU pagefault handler + * Route shmem backend over to TTM SYSTEM for discrete + * TTM purgeable object support + * Move i915 buddy allocator over to TTM + * MMAP ioctl mode(see `I915 MMAP`_) + * SET/GET ioctl caching(see `I915 SET/GET CACHING`_) +* Send RFC(with mesa-dev on cc) for final sign off on the uAPI +* Add pciid for DG1 and turn on uAPI for real + +New object placement and region query uAPI +========================================== +Starting from DG1 we need to give userspace the ability to allocate buffers from +device local-memory. Currently the driver supports gem_create, which can place +buffers in system memory via shmem, and the usual assortment of other +interfaces, like dumb buffers and userptr. + +To support this new capability, while also providing a uAPI which will work +beyond just DG1, we propose to offer three new bits of uAPI: + +DRM_I915_QUERY_MEMORY_REGIONS +----------------------------- +New query ID which allows userspace to discover the list of supported memory +regions(like system-memory and local-memory) for a given device. We identify +each region with a class and instance pair, which should be unique. The class +here would be DEVICE or SYSTEM, and the instance would be zero, on platforms +like DG1. + +Side note: The class/instance design is borrowed from our existing engine uAPI, +where we describe every physical engine in terms of its class, and the +particular instance, since we can have more than one per class. + +In the future we also want to expose more information which can further +describe the capabilities of a region. + +.. kernel-doc:: Documentation/gpu/rfc/i915_gem_lmem.h + :functions: drm_i915_gem_memory_class drm_i915_gem_memory_class_instance drm_i915_memory_region_info drm_i915_query_memory_regions + +GEM_CREATE_EXT +-------------- +New ioctl which is basically just gem_create but now allows userspace to provide +a chain of possible extensions. Note that if we don't provide any extensions and +set flags=0 then we get the exact same behaviour as gem_create. + +Side note: We also need to support PXP[1] in the near future, which is also +applicable to integrated platforms, and adds its own gem_create_ext extension, +which basically lets userspace mark a buffer as "protected". + +.. kernel-doc:: Documentation/gpu/rfc/i915_gem_lmem.h + :functions: drm_i915_gem_create_ext + +I915_GEM_CREATE_EXT_MEMORY_REGIONS +---------------------------------- +Implemented as an extension for gem_create_ext, we would now allow userspace to +optionally provide an immutable list of preferred placements at creation time, +in priority order, for a given buffer object. For the placements we expect +them each to use the class/instance encoding, as per the output of the regions +query. Having the list in priority order will be useful in the future when +placing an object, say during eviction. + +.. kernel-doc:: Documentation/gpu/rfc/i915_gem_lmem.h + :functions: drm_i915_gem_create_ext_memory_regions + +One fair criticism here is that this seems a little over-engineered[2]. If we +just consider DG1 then yes, a simple gem_create.flags or something is totally +all that's needed to tell the kernel to allocate the buffer in local-memory or +whatever. However looking to the future we need uAPI which can also support +upcoming Xe HP multi-tile architecture in a sane way, where there can be +multiple local-memory instances for a given device, and so using both class and +instance in our uAPI to describe regions is desirable, although specifically +for DG1 it's uninteresting, since we only have a single local-memory instance. + +Existing uAPI issues +==================== +Some potential issues we still need to resolve. + +I915 MMAP +--------- +In i915 there are multiple ways to MMAP GEM object, including mapping the same +object using different mapping types(WC vs WB), i.e multiple active mmaps per +object. TTM expects one MMAP at most for the lifetime of the object. If it +turns out that we have to backpedal here, there might be some potential +userspace fallout. + +I915 SET/GET CACHING +-------------------- +In i915 we have set/get_caching ioctl. TTM doesn't let us to change this, but +DG1 doesn't support non-snooped pcie transactions, so we can just always +allocate as WB for smem-only buffers. If/when our hw gains support for +non-snooped pcie transactions then we must fix this mode at allocation time as +a new GEM extension. + +This is related to the mmap problem, because in general (meaning, when we're +not running on intel cpus) the cpu mmap must not, ever, be inconsistent with +allocation mode. + +Possible idea is to let the kernel picks the mmap mode for userspace from the +following table: + +smem-only: WB. Userspace does not need to call clflush. + +smem+lmem: We only ever allow a single mode, so simply allocate this as uncached +memory, and always give userspace a WC mapping. GPU still does snooped access +here(assuming we can't turn it off like on DG1), which is a bit inefficient. + +lmem only: always WC + +This means on discrete you only get a single mmap mode, all others must be +rejected. That's probably going to be a new default mode or something like +that. + +Links +===== +[1] https://patchwork.freedesktop.org/series/86798/ + +[2] https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5599#note_553791 diff --git a/Documentation/gpu/rfc/index.rst b/Documentation/gpu/rfc/index.rst index a8621f7dab8b..05670442ca1b 100644 --- a/Documentation/gpu/rfc/index.rst +++ b/Documentation/gpu/rfc/index.rst @@ -15,3 +15,7 @@ host such documentation: * Once the code has landed move all the documentation to the right places in the main core, helper or driver sections. + +.. toctree:: + + i915_gem_lmem.rst -- cgit v1.2.3 From 157da630c7ff848439f721257f26655b5ae2d856 Mon Sep 17 00:00:00 2001 From: Ivan Uvarov Date: Wed, 7 Apr 2021 14:14:26 +0300 Subject: dt-bindings: add compatible vendor prefix for Forlinx Baoding Forlinx Embedded Technology Co., Ltd. is the manufacturer of the Allwinner R40/A40i-powered FETA40i-C SoM and the OKA40i-C dev/carrier board based on it. This patch adds the DT vendor prefix for Forlinx in preparation for a further patch, which includes a devicetree for the OKA40i-C board. Signed-off-by: Ivan Uvarov 1 file changed, 2 insertions(+) Acked-by: Rob Herring Signed-off-by: Maxime Ripard Link: https://lore.kernel.org/r/20210407111428.3755684-4-i.uvarov@cognitivepilot.com --- Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index b868cefc7c55..44e59ee2ae90 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -409,6 +409,8 @@ patternProperties: description: Firefly "^focaltech,.*": description: FocalTech Systems Co.,Ltd + "^forlinx,.*": + description: Baoding Forlinx Embedded Technology Co., Ltd. "^frida,.*": description: Shenzhen Frida LCD Co., Ltd. "^friendlyarm,.*": -- cgit v1.2.3 From ed85561fe39c994e9ba1a97614b5269158a98ca9 Mon Sep 17 00:00:00 2001 From: Ivan Uvarov Date: Wed, 7 Apr 2021 14:14:27 +0300 Subject: dt-bindings: arm: add compatible for Forlinx OKA40i-C and FETA40i-C The FETA40i-C is a SoM by Forlinx based on the Allwinner R40/A40i SoC. The OKA40i-C is a carrier/development board by the same company based on this SoM. This patch adds compatible strings for these two devices in preparation for the next patch containing a devicetree for them. Signed-off-by: Ivan Uvarov 1 file changed, 6 insertions(+) Acked-by: Rob Herring Signed-off-by: Maxime Ripard Link: https://lore.kernel.org/r/20210407111428.3755684-5-i.uvarov@cognitivepilot.com --- Documentation/devicetree/bindings/arm/sunxi.yaml | 6 ++++++ 1 file changed, 6 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/sunxi.yaml b/Documentation/devicetree/bindings/arm/sunxi.yaml index ac750025a2eb..ec8108483b49 100644 --- a/Documentation/devicetree/bindings/arm/sunxi.yaml +++ b/Documentation/devicetree/bindings/arm/sunxi.yaml @@ -224,6 +224,12 @@ properties: - const: empire-electronix,m712 - const: allwinner,sun5i-a13 + - description: Forlinx OKA40i-C Development board + items: + - const: forlinx,oka40i-c + - const: forlinx,feta40i-c + - const: allwinner,sun8i-r40 + - description: FriendlyARM NanoPi A64 items: - const: friendlyarm,nanopi-a64 -- cgit v1.2.3 From 41413a20b08258cc34af06e01236980ac68ae334 Mon Sep 17 00:00:00 2001 From: Johan Jonker Date: Sat, 17 Apr 2021 13:29:48 +0200 Subject: dt-bindings: arm: rockchip: convert pmu.txt to YAML Current dts files with 'pmu' nodes are manually verified. In order to automate this process pmu.txt has to be converted to yaml. Signed-off-by: Johan Jonker Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20210417112952.8516-12-jbx6244@gmail.com Signed-off-by: Heiko Stuebner --- .../devicetree/bindings/arm/rockchip/pmu.txt | 16 ------- .../devicetree/bindings/arm/rockchip/pmu.yaml | 49 ++++++++++++++++++++++ 2 files changed, 49 insertions(+), 16 deletions(-) delete mode 100644 Documentation/devicetree/bindings/arm/rockchip/pmu.txt create mode 100644 Documentation/devicetree/bindings/arm/rockchip/pmu.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/rockchip/pmu.txt b/Documentation/devicetree/bindings/arm/rockchip/pmu.txt deleted file mode 100644 index 3ee9b428b2f7..000000000000 --- a/Documentation/devicetree/bindings/arm/rockchip/pmu.txt +++ /dev/null @@ -1,16 +0,0 @@ -Rockchip 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 : = "rockchip,rk3066-pmu"; -- reg : physical base address and the size of the registers window - -Example: - - pmu@20004000 { - compatible = "rockchip,rk3066-pmu"; - reg = <0x20004000 0x100>; - }; diff --git a/Documentation/devicetree/bindings/arm/rockchip/pmu.yaml b/Documentation/devicetree/bindings/arm/rockchip/pmu.yaml new file mode 100644 index 000000000000..0b816943d9aa --- /dev/null +++ b/Documentation/devicetree/bindings/arm/rockchip/pmu.yaml @@ -0,0 +1,49 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/arm/rockchip/pmu.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Rockchip Power Management Unit (PMU) + +maintainers: + - Elaine Zhang + - Heiko Stuebner + +description: | + The PMU is used to turn on and off different power domains of the SoCs. + This includes the power to the CPU cores. + +select: + properties: + compatible: + contains: + enum: + - rockchip,rk3066-pmu + + required: + - compatible + +properties: + compatible: + items: + - enum: + - rockchip,rk3066-pmu + - const: syscon + - const: simple-mfd + + reg: + maxItems: 1 + +required: + - compatible + - reg + +additionalProperties: true + +examples: + - | + pmu@20004000 { + compatible = "rockchip,rk3066-pmu", "syscon", "simple-mfd"; + reg = <0x20004000 0x100>; + }; -- cgit v1.2.3 From 9a531e4d5a49925554f99024d164572cbd6a8d9b Mon Sep 17 00:00:00 2001 From: Steen Hegelund Date: Fri, 16 Apr 2021 10:40:52 +0200 Subject: dt-bindings: reset: microchip sparx5 reset driver bindings Document the Sparx5 reset device driver bindings The driver uses a syscon and an IO range on sparx5 for access to the reset control and the reset status. Sparx5 will no longer use the existing Ocelot chip reset driver, but use this new switch reset driver as it has the reset controller interface that allows the first client to perform the reset on behalf of all the Sparx5 component drivers. Signed-off-by: Steen Hegelund Reviewed-by: Rob Herring Signed-off-by: Philipp Zabel --- .../devicetree/bindings/reset/microchip,rst.yaml | 58 ++++++++++++++++++++++ 1 file changed, 58 insertions(+) create mode 100644 Documentation/devicetree/bindings/reset/microchip,rst.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/reset/microchip,rst.yaml b/Documentation/devicetree/bindings/reset/microchip,rst.yaml new file mode 100644 index 000000000000..370579aeeca1 --- /dev/null +++ b/Documentation/devicetree/bindings/reset/microchip,rst.yaml @@ -0,0 +1,58 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/reset/microchip,rst.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: Microchip Sparx5 Switch Reset Controller + +maintainers: + - Steen Hegelund + - Lars Povlsen + +description: | + The Microchip Sparx5 Switch provides reset control and implements the following + functions + - One Time Switch Core Reset (Soft Reset) + +properties: + $nodename: + pattern: "^reset-controller@[0-9a-f]+$" + + compatible: + const: microchip,sparx5-switch-reset + + reg: + items: + - description: global control block registers + + reg-names: + items: + - const: gcb + + "#reset-cells": + const: 1 + + cpu-syscon: + $ref: "/schemas/types.yaml#/definitions/phandle" + description: syscon used to access CPU reset + +required: + - compatible + - reg + - reg-names + - "#reset-cells" + - cpu-syscon + +additionalProperties: false + +examples: + - | + reset: reset-controller@11010008 { + compatible = "microchip,sparx5-switch-reset"; + reg = <0x11010008 0x4>; + reg-names = "gcb"; + #reset-cells = <1>; + cpu-syscon = <&cpu_ctrl>; + }; + -- cgit v1.2.3 From 27736ddd24cb99b9bef2b36b42381eb41da15958 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Rafa=C5=82=20Mi=C5=82ecki?= Date: Fri, 23 Apr 2021 07:05:36 +0200 Subject: dt-bindings: mtd: brcmnand: convert to the json-schema MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit This helps validating DTS files. Changes that require mentioning: 1. Property "clock" was renamed to "clocks" 2. Duplicated properties (defined in nand-controller.yaml) were dropped 3. Compatible "brcm,nand-bcm63168" was added 4. SoC specific "compatible" cases got limited controller versions Examples changes: 1. Nodes "nand" were renamed to "nand-controller" 2. Nodes "nandcs" were renamed to "nand" 3. Dropped partitions as they were using old syntax and are well documented elsewhere anyway This rewritten binding validates cleanly using the "dt_binding_check". Some Linux stored DTS files will require updating to make "dtbs_check" happy. Signed-off-by: Rafał Miłecki Reviewed-by: Rob Herring Reviewed-by: Brian Norris Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20210423050536.29504-1-zajec5@gmail.com --- .../devicetree/bindings/mtd/brcm,brcmnand.txt | 186 ---------------- .../devicetree/bindings/mtd/brcm,brcmnand.yaml | 242 +++++++++++++++++++++ 2 files changed, 242 insertions(+), 186 deletions(-) delete mode 100644 Documentation/devicetree/bindings/mtd/brcm,brcmnand.txt create mode 100644 Documentation/devicetree/bindings/mtd/brcm,brcmnand.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mtd/brcm,brcmnand.txt b/Documentation/devicetree/bindings/mtd/brcm,brcmnand.txt deleted file mode 100644 index 44335a4f8bfb..000000000000 --- a/Documentation/devicetree/bindings/mtd/brcm,brcmnand.txt +++ /dev/null @@ -1,186 +0,0 @@ -* Broadcom STB NAND Controller - -The Broadcom Set-Top Box NAND controller supports low-level access to raw NAND -flash chips. It has a memory-mapped register interface for both control -registers and for its data input/output buffer. On some SoCs, this controller is -paired with a custom DMA engine (inventively named "Flash DMA") which supports -basic PROGRAM and READ functions, among other features. - -This controller was originally designed for STB SoCs (BCM7xxx) but is now -available on a variety of Broadcom SoCs, including some BCM3xxx, BCM63xx, and -iProc/Cygnus. Its history includes several similar (but not fully register -compatible) versions. - -Required properties: -- compatible : May contain an SoC-specific compatibility string (see below) - to account for any SoC-specific hardware bits that may be - added on top of the base core controller. - In addition, must contain compatibility information about - the core NAND controller, of the following form: - "brcm,brcmnand" and an appropriate version compatibility - string, like "brcm,brcmnand-v7.0" - Possible values: - brcm,brcmnand-v2.1 - brcm,brcmnand-v2.2 - brcm,brcmnand-v4.0 - brcm,brcmnand-v5.0 - brcm,brcmnand-v6.0 - brcm,brcmnand-v6.1 - brcm,brcmnand-v6.2 - brcm,brcmnand-v7.0 - brcm,brcmnand-v7.1 - brcm,brcmnand-v7.2 - brcm,brcmnand-v7.3 - brcm,brcmnand -- reg : the register start and length for NAND register region. - (optional) Flash DMA register range (if present) - (optional) NAND flash cache range (if at non-standard offset) -- reg-names : a list of the names corresponding to the previous register - ranges. Should contain "nand" and (optionally) - "flash-dma" or "flash-edu" and/or "nand-cache". -- interrupts : The NAND CTLRDY interrupt, (if Flash DMA is available) - FLASH_DMA_DONE and if EDU is avaialble and used FLASH_EDU_DONE -- interrupt-names : May be "nand_ctlrdy" or "flash_dma_done" or "flash_edu_done", - if broken out as individual interrupts. - May be "nand", if the SoC has the individual NAND - interrupts multiplexed behind another custom piece of - hardware -- #address-cells : <1> - subnodes give the chip-select number -- #size-cells : <0> - -Optional properties: -- clock : reference to the clock for the NAND controller -- clock-names : "nand" (required for the above clock) -- brcm,nand-has-wp : Some versions of this IP include a write-protect - (WP) control bit. It is always available on >= - v7.0. Use this property to describe the rare - earlier versions of this core that include WP - - -- Additional SoC-specific NAND controller properties -- - -The NAND controller is integrated differently on the variety of SoCs on which it -is found. Part of this integration involves providing status and enable bits -with which to control the 8 exposed NAND interrupts, as well as hardware for -configuring the endianness of the data bus. On some SoCs, these features are -handled via standard, modular components (e.g., their interrupts look like a -normal IRQ chip), but on others, they are controlled in unique and interesting -ways, sometimes with registers that lump multiple NAND-related functions -together. The former case can be described simply by the standard interrupts -properties in the main controller node. But for the latter exceptional cases, -we define additional 'compatible' properties and associated register resources within the NAND controller node above. - - - compatible: Can be one of several SoC-specific strings. Each SoC may have - different requirements for its additional properties, as described below each - bullet point below. - - * "brcm,nand-bcm63138" - - reg: (required) the 'NAND_INT_BASE' register range, with separate status - and enable registers - - reg-names: (required) "nand-int-base" - - * "brcm,nand-bcm6368" - - compatible: should contain "brcm,nand-bcm", "brcm,nand-bcm6368" - - reg: (required) the 'NAND_INTR_BASE' register range, with combined status - and enable registers, and boot address registers - - reg-names: (required) "nand-int-base" - - * "brcm,nand-iproc" - - reg: (required) the "IDM" register range, for interrupt enable and APB - bus access endianness configuration, and the "EXT" register range, - for interrupt status/ack. - - reg-names: (required) a list of the names corresponding to the previous - register ranges. Should contain "iproc-idm" and "iproc-ext". - - -* NAND chip-select - -Each controller (compatible: "brcm,brcmnand") may contain one or more subnodes -to represent enabled chip-selects which (may) contain NAND flash chips. Their -properties are as follows. - -Required properties: -- compatible : should contain "brcm,nandcs" -- reg : a single integer representing the chip-select - number (e.g., 0, 1, 2, etc.) -- #address-cells : see partition.txt -- #size-cells : see partition.txt - -Optional properties: -- nand-ecc-strength : see nand-controller.yaml -- nand-ecc-step-size : must be 512 or 1024. See nand-controller.yaml -- nand-on-flash-bbt : boolean, to enable the on-flash BBT for this - chip-select. See nand-controller.yaml -- brcm,nand-oob-sector-size : integer, to denote the spare area sector size - expected for the ECC layout in use. This size, in - addition to the strength and step-size, - determines how the hardware BCH engine will lay - out the parity bytes it stores on the flash. - This property can be automatically determined by - the flash geometry (particularly the NAND page - and OOB size) in many cases, but when booting - from NAND, the boot controller has only a limited - number of available options for its default ECC - layout. - -Each nandcs device node may optionally contain sub-nodes describing the flash -partition mapping. See partition.txt for more detail. - - -Example: - -nand@f0442800 { - compatible = "brcm,brcmnand-v7.0", "brcm,brcmnand"; - reg = <0xF0442800 0x600>, - <0xF0443000 0x100>; - reg-names = "nand", "flash-dma"; - interrupt-parent = <&hif_intr2_intc>; - interrupts = <24>, <4>; - - #address-cells = <1>; - #size-cells = <0>; - - nandcs@1 { - compatible = "brcm,nandcs"; - reg = <1>; // Chip select 1 - nand-on-flash-bbt; - nand-ecc-strength = <12>; - nand-ecc-step-size = <512>; - - // Partitions - #address-cells = <1>; // <2>, for 64-bit offset - #size-cells = <1>; // <2>, for 64-bit length - flash0.rootfs@0 { - reg = <0 0x10000000>; - }; - flash0@0 { - reg = <0 0>; // MTDPART_SIZ_FULL - }; - flash0.kernel@10000000 { - reg = <0x10000000 0x400000>; - }; - }; -}; - -nand@10000200 { - compatible = "brcm,nand-bcm63168", "brcm,nand-bcm6368", - "brcm,brcmnand-v4.0", "brcm,brcmnand"; - reg = <0x10000200 0x180>, - <0x10000600 0x200>, - <0x100000b0 0x10>; - reg-names = "nand", "nand-cache", "nand-int-base"; - interrupt-parent = <&periph_intc>; - interrupts = <50>; - clocks = <&periph_clk 20>; - clock-names = "nand"; - - #address-cells = <1>; - #size-cells = <0>; - - nand0: nandcs@0 { - compatible = "brcm,nandcs"; - reg = <0>; - nand-on-flash-bbt; - nand-ecc-strength = <1>; - nand-ecc-step-size = <512>; - }; -}; diff --git a/Documentation/devicetree/bindings/mtd/brcm,brcmnand.yaml b/Documentation/devicetree/bindings/mtd/brcm,brcmnand.yaml new file mode 100644 index 000000000000..e5f1a33332a5 --- /dev/null +++ b/Documentation/devicetree/bindings/mtd/brcm,brcmnand.yaml @@ -0,0 +1,242 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mtd/brcm,brcmnand.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Broadcom STB NAND Controller + +maintainers: + - Brian Norris + - Kamal Dasu + +description: | + The Broadcom Set-Top Box NAND controller supports low-level access to raw NAND + flash chips. It has a memory-mapped register interface for both control + registers and for its data input/output buffer. On some SoCs, this controller + is paired with a custom DMA engine (inventively named "Flash DMA") which + supports basic PROGRAM and READ functions, among other features. + + This controller was originally designed for STB SoCs (BCM7xxx) but is now + available on a variety of Broadcom SoCs, including some BCM3xxx, BCM63xx, and + iProc/Cygnus. Its history includes several similar (but not fully register + compatible) versions. + + -- Additional SoC-specific NAND controller properties -- + + The NAND controller is integrated differently on the variety of SoCs on which + it is found. Part of this integration involves providing status and enable + bits with which to control the 8 exposed NAND interrupts, as well as hardware + for configuring the endianness of the data bus. On some SoCs, these features + are handled via standard, modular components (e.g., their interrupts look like + a normal IRQ chip), but on others, they are controlled in unique and + interesting ways, sometimes with registers that lump multiple NAND-related + functions together. The former case can be described simply by the standard + interrupts properties in the main controller node. But for the latter + exceptional cases, we define additional 'compatible' properties and associated + register resources within the NAND controller node above. + +properties: + compatible: + oneOf: + - items: + - enum: + - brcm,brcmnand-v2.1 + - brcm,brcmnand-v2.2 + - brcm,brcmnand-v4.0 + - brcm,brcmnand-v5.0 + - brcm,brcmnand-v6.0 + - brcm,brcmnand-v6.1 + - brcm,brcmnand-v6.2 + - brcm,brcmnand-v7.0 + - brcm,brcmnand-v7.1 + - brcm,brcmnand-v7.2 + - brcm,brcmnand-v7.3 + - const: brcm,brcmnand + - description: BCM63138 SoC-specific NAND controller + items: + - const: brcm,nand-bcm63138 + - enum: + - brcm,brcmnand-v7.0 + - brcm,brcmnand-v7.1 + - const: brcm,brcmnand + - description: iProc SoC-specific NAND controller + items: + - const: brcm,nand-iproc + - const: brcm,brcmnand-v6.1 + - const: brcm,brcmnand + - description: BCM63168 SoC-specific NAND controller + items: + - const: brcm,nand-bcm63168 + - const: brcm,nand-bcm6368 + - const: brcm,brcmnand-v4.0 + - const: brcm,brcmnand + + reg: + minItems: 1 + maxItems: 6 + + reg-names: + minItems: 1 + maxItems: 6 + items: + enum: [ nand, flash-dma, flash-edu, nand-cache, nand-int-base, iproc-idm, iproc-ext ] + + interrupts: + minItems: 1 + maxItems: 3 + items: + - description: NAND CTLRDY interrupt + - description: FLASH_DMA_DONE if flash DMA is available + - description: FLASH_EDU_DONE if EDU is available + + interrupt-names: + minItems: 1 + maxItems: 3 + items: + - const: nand_ctlrdy + - const: flash_dma_done + - const: flash_edu_done + + clocks: + maxItems: 1 + description: reference to the clock for the NAND controller + + clock-names: + const: nand + + brcm,nand-has-wp: + description: > + Some versions of this IP include a write-protect + (WP) control bit. It is always available on >= + v7.0. Use this property to describe the rare + earlier versions of this core that include WP + type: boolean + +patternProperties: + "^nand@[a-f0-9]$": + type: object + properties: + compatible: + const: brcm,nandcs + + nand-ecc-step-size: + enum: [ 512, 1024 ] + + brcm,nand-oob-sector-size: + description: | + integer, to denote the spare area sector size + expected for the ECC layout in use. This size, in + addition to the strength and step-size, + determines how the hardware BCH engine will lay + out the parity bytes it stores on the flash. + This property can be automatically determined by + the flash geometry (particularly the NAND page + and OOB size) in many cases, but when booting + from NAND, the boot controller has only a limited + number of available options for its default ECC + layout. + $ref: /schemas/types.yaml#/definitions/uint32 + +allOf: + - $ref: nand-controller.yaml# + - if: + properties: + compatible: + contains: + const: brcm,nand-bcm63138 + then: + properties: + reg-names: + minItems: 2 + maxItems: 2 + items: + - const: nand + - const: nand-int-base + - if: + properties: + compatible: + contains: + const: brcm,nand-bcm6368 + then: + properties: + reg-names: + minItems: 3 + maxItems: 3 + items: + - const: nand + - const: nand-int-base + - const: nand-cache + - if: + properties: + compatible: + contains: + const: brcm,nand-iproc + then: + properties: + reg-names: + minItems: 3 + maxItems: 3 + items: + - const: nand + - const: iproc-idm + - const: iproc-ext + +unevaluatedProperties: false + +required: + - reg + - reg-names + - interrupts + +examples: + - | + nand-controller@f0442800 { + compatible = "brcm,brcmnand-v7.0", "brcm,brcmnand"; + reg = <0xf0442800 0x600>, + <0xf0443000 0x100>; + reg-names = "nand", "flash-dma"; + interrupt-parent = <&hif_intr2_intc>; + interrupts = <24>, <4>; + + #address-cells = <1>; + #size-cells = <0>; + + nand@1 { + compatible = "brcm,nandcs"; + reg = <1>; // Chip select 1 + nand-on-flash-bbt; + nand-ecc-strength = <12>; + nand-ecc-step-size = <512>; + + #address-cells = <1>; + #size-cells = <1>; + }; + }; + - | + nand-controller@10000200 { + compatible = "brcm,nand-bcm63168", "brcm,nand-bcm6368", + "brcm,brcmnand-v4.0", "brcm,brcmnand"; + reg = <0x10000200 0x180>, + <0x100000b0 0x10>, + <0x10000600 0x200>; + reg-names = "nand", "nand-int-base", "nand-cache"; + interrupt-parent = <&periph_intc>; + interrupts = <50>; + clocks = <&periph_clk 20>; + clock-names = "nand"; + + #address-cells = <1>; + #size-cells = <0>; + + nand@0 { + compatible = "brcm,nandcs"; + reg = <0>; + nand-on-flash-bbt; + nand-ecc-strength = <1>; + nand-ecc-step-size = <512>; + + #address-cells = <1>; + #size-cells = <1>; + }; + }; -- cgit v1.2.3 From a4d82940ff85a7e307953dfa715f65d5ab487e10 Mon Sep 17 00:00:00 2001 From: Hauke Mehrtens Date: Sun, 18 Apr 2021 23:46:14 +0200 Subject: dt-bindings: mtd: brcm,trx: Add brcm,trx-magic This adds the description of an additional property which allows to specify a custom partition parser magic to detect a trx partition. Buffalo has multiple device which are using the trx format, but with different magic values. Signed-off-by: Hauke Mehrtens Acked-by: Rob Herring Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20210418214616.239574-2-hauke@hauke-m.de --- Documentation/devicetree/bindings/mtd/partitions/brcm,trx.txt | 5 +++++ 1 file changed, 5 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mtd/partitions/brcm,trx.txt b/Documentation/devicetree/bindings/mtd/partitions/brcm,trx.txt index b677147ca4e1..c2175d3c82ec 100644 --- a/Documentation/devicetree/bindings/mtd/partitions/brcm,trx.txt +++ b/Documentation/devicetree/bindings/mtd/partitions/brcm,trx.txt @@ -28,6 +28,11 @@ detected by a software parsing TRX header. Required properties: - compatible : (required) must be "brcm,trx" +Optional properties: + +- brcm,trx-magic: TRX magic, if it is different from the default magic + 0x30524448 as a u32. + Example: flash@0 { -- cgit v1.2.3 From e6aed6717cd429a48995d2c6533fdde9f88d8cf1 Mon Sep 17 00:00:00 2001 From: Michael Walle Date: Sat, 24 Apr 2021 13:06:05 +0200 Subject: dt-bindings: mtd: add YAML schema for the generic MTD bindings Convert MTD's common.txt to mtd.yaml. Signed-off-by: Michael Walle Reviewed-by: Rob Herring Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20210424110608.15748-3-michael@walle.cc --- Documentation/devicetree/bindings/mtd/common.txt | 16 +--------- Documentation/devicetree/bindings/mtd/mtd.yaml | 39 ++++++++++++++++++++++++ 2 files changed, 40 insertions(+), 15 deletions(-) create mode 100644 Documentation/devicetree/bindings/mtd/mtd.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mtd/common.txt b/Documentation/devicetree/bindings/mtd/common.txt index fc068b923d7a..ae16f9ea8606 100644 --- a/Documentation/devicetree/bindings/mtd/common.txt +++ b/Documentation/devicetree/bindings/mtd/common.txt @@ -1,15 +1 @@ -* Common properties of all MTD devices - -Optional properties: -- label: user-defined MTD device name. Can be used to assign user - friendly names to MTD devices (instead of the flash model or flash - controller based name) in order to ease flash device identification - and/or describe what they are used for. - -Example: - - flash@0 { - label = "System-firmware"; - - /* flash type specific properties */ - }; +This file has been moved to mtd.yaml. diff --git a/Documentation/devicetree/bindings/mtd/mtd.yaml b/Documentation/devicetree/bindings/mtd/mtd.yaml new file mode 100644 index 000000000000..086b0ecd1604 --- /dev/null +++ b/Documentation/devicetree/bindings/mtd/mtd.yaml @@ -0,0 +1,39 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mtd/mtd.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: MTD (Memory Technology Device) Device Tree Bindings + +maintainers: + - Miquel Raynal + - Richard Weinberger + +properties: + $nodename: + pattern: "^flash(@.*)?$" + + label: + description: + User-defined MTD device name. Can be used to assign user friendly + names to MTD devices (instead of the flash model or flash controller + based name) in order to ease flash device identification and/or + describe what they are used for. + +additionalProperties: true + +examples: + - | + spi { + #address-cells = <1>; + #size-cells = <0>; + + flash@0 { + reg = <0>; + compatible = "jedec,spi-nor"; + label = "System-firmware"; + }; + }; + +... -- cgit v1.2.3 From 74ae3663b110d8d3e5d41dd4b05f4fa6bd79d49d Mon Sep 17 00:00:00 2001 From: Michael Walle Date: Sat, 24 Apr 2021 13:06:06 +0200 Subject: dt-bindings: mtd: add OTP bindings Flash devices can have one-time-programmable regions. Add a nvmem binding so they can be used as a nvmem provider. Signed-off-by: Michael Walle Reviewed-by: Rob Herring Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20210424110608.15748-4-michael@walle.cc --- Documentation/devicetree/bindings/mtd/mtd.yaml | 50 ++++++++++++++++++++++++++ 1 file changed, 50 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mtd/mtd.yaml b/Documentation/devicetree/bindings/mtd/mtd.yaml index 086b0ecd1604..376b679cfc70 100644 --- a/Documentation/devicetree/bindings/mtd/mtd.yaml +++ b/Documentation/devicetree/bindings/mtd/mtd.yaml @@ -21,6 +21,25 @@ properties: based name) in order to ease flash device identification and/or describe what they are used for. +patternProperties: + "^otp(-[0-9]+)?$": + type: object + $ref: ../nvmem/nvmem.yaml# + + description: | + An OTP memory region. Some flashes provide a one-time-programmable + memory whose content can either be programmed by a user or is already + pre-programmed by the factory. Some flashes might provide both. + + properties: + compatible: + enum: + - user-otp + - factory-otp + + required: + - compatible + additionalProperties: true examples: @@ -36,4 +55,35 @@ examples: }; }; + - | + spi { + #address-cells = <1>; + #size-cells = <0>; + + flash@0 { + reg = <0>; + compatible = "jedec,spi-nor"; + + otp-1 { + compatible = "factory-otp"; + #address-cells = <1>; + #size-cells = <1>; + + electronic-serial-number@0 { + reg = <0 8>; + }; + }; + + otp-2 { + compatible = "user-otp"; + #address-cells = <1>; + #size-cells = <1>; + + mac-address@0 { + reg = <0 6>; + }; + }; + }; + }; + ... -- cgit v1.2.3 From 96d3af22f87c81f21bd4c79b257e205240157ae0 Mon Sep 17 00:00:00 2001 From: Michael Walle Date: Sat, 24 Apr 2021 13:06:07 +0200 Subject: dt-bindings: mtd: spi-nor: add otp property SPI-NOR flashes may have OTP regions and have a nvmem binding. This binding is described in mtd.yaml. Signed-off-by: Michael Walle Reviewed-by: Rob Herring Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20210424110608.15748-5-michael@walle.cc --- Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml | 6 ++++++ 1 file changed, 6 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml b/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml index 5e7e5349f9a1..ed590d7c6e37 100644 --- a/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml +++ b/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml @@ -9,6 +9,9 @@ title: SPI NOR flash ST M25Pxx (and similar) serial flash chips maintainers: - Rob Herring +allOf: + - $ref: "mtd.yaml#" + properties: compatible: oneOf: @@ -82,6 +85,9 @@ patternProperties: '^partition@': type: object + "^otp(-[0-9]+)?$": + type: object + additionalProperties: false examples: -- cgit v1.2.3 From 880e007f15a31f446b9e1713720c6ae5a539f3f4 Mon Sep 17 00:00:00 2001 From: Samuel Holland Date: Thu, 29 Apr 2021 22:58:53 -0500 Subject: ASoC: dt-bindings: sun8i-codec: Increase #sound-dai-cells Increase sound-dai-cells to 1 to allow using the DAIs in the codec corresponding to AIF2 and AIF3. The generic ASoC OF code supports a #sound-dai-cells value of 0 or 1 with no impact to the driver, so this is a backward-compatible change. Signed-off-by: Samuel Holland Link: https://lore.kernel.org/r/20210430035859.3487-2-samuel@sholland.org Signed-off-by: Mark Brown --- .../devicetree/bindings/sound/allwinner,sun8i-a33-codec.yaml | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/allwinner,sun8i-a33-codec.yaml b/Documentation/devicetree/bindings/sound/allwinner,sun8i-a33-codec.yaml index 67405e6d8168..19f111f40225 100644 --- a/Documentation/devicetree/bindings/sound/allwinner,sun8i-a33-codec.yaml +++ b/Documentation/devicetree/bindings/sound/allwinner,sun8i-a33-codec.yaml @@ -12,7 +12,11 @@ maintainers: properties: "#sound-dai-cells": - const: 0 + minimum: 0 + maximum: 1 + description: + A value of 0 is deprecated. When used, it only allows access to + the ADC/DAC and AIF1 (the CPU DAI), not the other two AIFs/DAIs. compatible: oneOf: @@ -50,7 +54,7 @@ additionalProperties: false examples: - | audio-codec@1c22e00 { - #sound-dai-cells = <0>; + #sound-dai-cells = <1>; compatible = "allwinner,sun8i-a33-codec"; reg = <0x01c22e00 0x400>; interrupts = <0 29 4>; -- cgit v1.2.3 From 00c8b0b1e6e1314bb57aab6438fbc2803c637d9d Mon Sep 17 00:00:00 2001 From: Bartosz Dudziak Date: Sun, 2 May 2021 13:53:03 +0200 Subject: regulator: qcom: Document PM8226 smd regulator Document the PM8226 SMD-RPM regulator entry. Signed-off-by: Bartosz Dudziak Acked-by: Rob Herring Link: https://lore.kernel.org/r/20210502115304.8570-1-bartosz.dudziak@snejp.pl Signed-off-by: Mark Brown --- .../devicetree/bindings/regulator/qcom,smd-rpm-regulator.yaml | 5 +++++ 1 file changed, 5 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/regulator/qcom,smd-rpm-regulator.yaml b/Documentation/devicetree/bindings/regulator/qcom,smd-rpm-regulator.yaml index a35c6cb9bf97..83b53579f463 100644 --- a/Documentation/devicetree/bindings/regulator/qcom,smd-rpm-regulator.yaml +++ b/Documentation/devicetree/bindings/regulator/qcom,smd-rpm-regulator.yaml @@ -24,6 +24,10 @@ description: For mp5496, s2 + For pm8226, s1, s2, s3, s4, s5, l1, l2, l3, l4, l5, l6, l7, l8, l9, l10, + l11, l12, l13, l14, l15, l16, l17, l18, l19, l20, l21, l22, l23, l24, l25, + l26, l27, l28, lvs1 + For pm8841, s1, s2, s3, s4, s5, s6, s7, s8 For pm8916, s1, s2, s3, s4, l1, l2, l3, l4, l5, l6, l7, l8, l9, l10, l11, @@ -68,6 +72,7 @@ properties: compatible: enum: - qcom,rpm-mp5496-regulators + - qcom,rpm-pm8226-regulators - qcom,rpm-pm8841-regulators - qcom,rpm-pm8916-regulators - qcom,rpm-pm8941-regulators -- cgit v1.2.3 From 029d32a892a860017d33ff8d9598259731e776ad Mon Sep 17 00:00:00 2001 From: Geert Uytterhoeven Date: Thu, 6 May 2021 13:52:59 +0200 Subject: spi: dw-apb-ssi: Integrate Renesas RZ/N1 SPI controller Originally, the Renesas RZ/N1 SPI Controller DT bindings were not integrated in the main DT bindings for the Synopsys DesignWare Synchronous Serial Interface, but in its own file, as the RZ/N1 controller has additional registers for software CS control and DMA. As so far DMA is not supported on RZ/N1, and json-schema can handle any possible differences fine, integrate the RZ/N1 compatible values in the main DT bindings for the Synopsys DW SSI. Signed-off-by: Geert Uytterhoeven Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/aef15aa119ed02487ded4691141678bc1040c3b4.1620301936.git.geert+renesas@glider.be Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/spi/renesas,rzn1-spi.txt | 11 ----------- Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.yaml | 6 ++++++ 2 files changed, 6 insertions(+), 11 deletions(-) delete mode 100644 Documentation/devicetree/bindings/spi/renesas,rzn1-spi.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/spi/renesas,rzn1-spi.txt b/Documentation/devicetree/bindings/spi/renesas,rzn1-spi.txt deleted file mode 100644 index fb1a6728638d..000000000000 --- a/Documentation/devicetree/bindings/spi/renesas,rzn1-spi.txt +++ /dev/null @@ -1,11 +0,0 @@ -Renesas RZ/N1 SPI Controller - -This controller is based on the Synopsys DW Synchronous Serial Interface and -inherits all properties defined in snps,dw-apb-ssi.txt except for the -compatible property. - -Required properties: -- compatible : The device specific string followed by the generic RZ/N1 string. - Therefore it must be one of: - "renesas,r9a06g032-spi", "renesas,rzn1-spi" - "renesas,r9a06g033-spi", "renesas,rzn1-spi" diff --git a/Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.yaml b/Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.yaml index 4825157cd92e..ca91201a9926 100644 --- a/Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.yaml +++ b/Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.yaml @@ -67,6 +67,12 @@ properties: const: baikal,bt1-sys-ssi - description: Canaan Kendryte K210 SoS SPI Controller const: canaan,k210-spi + - description: Renesas RZ/N1 SPI Controller + items: + - enum: + - renesas,r9a06g032-spi # RZ/N1D + - renesas,r9a06g033-spi # RZ/N1S + - const: renesas,rzn1-spi # RZ/N1 reg: minItems: 1 -- cgit v1.2.3 From 340272b04036f2b833a7094eca5c15e5ed8e184c Mon Sep 17 00:00:00 2001 From: Christian Brauner Date: Sat, 8 May 2021 14:15:39 +0200 Subject: docs/cgroup: add entry for cgroup.kill Give a brief overview of the cgroup.kill functionality. Link: https://lore.kernel.org/r/20210503143922.3093755-2-brauner@kernel.org Cc: Roman Gushchin Cc: Tejun Heo Cc: cgroups@vger.kernel.org Reviewed-by: Shakeel Butt Signed-off-by: Christian Brauner Signed-off-by: Tejun Heo --- Documentation/admin-guide/cgroup-v2.rst | 15 +++++++++++++++ 1 file changed, 15 insertions(+) (limited to 'Documentation') diff --git a/Documentation/admin-guide/cgroup-v2.rst b/Documentation/admin-guide/cgroup-v2.rst index b1e81aa8598a..91cd601a1454 100644 --- a/Documentation/admin-guide/cgroup-v2.rst +++ b/Documentation/admin-guide/cgroup-v2.rst @@ -952,6 +952,21 @@ All cgroup core files are prefixed with "cgroup." it's possible to delete a frozen (and empty) cgroup, as well as create new sub-cgroups. + cgroup.kill + A write-only single value file which exists in non-root cgroups. + The only allowed value is "1". + + Writing "1" to the file causes the cgroup and all descendant cgroups to + be killed. This means that all processes located in the affected cgroup + tree will be killed via SIGKILL. + + Killing a cgroup tree will deal with concurrent forks appropriately and + is protected against migrations. + + In a threaded cgroup, writing this file fails with EOPNOTSUPP as + killing cgroups is a process directed operation, i.e. it affects + the whole thread-group. + Controllers =========== -- cgit v1.2.3 From 6f64aa5746d254f2b9b94b837b7862549f2565a0 Mon Sep 17 00:00:00 2001 From: Corentin Labbe Date: Fri, 30 Apr 2021 18:36:51 +0000 Subject: dt-bindings: dma: convert arm-pl08x to yaml Converts dma/arm-pl08x.txt to yaml. In the process, I add an example for the faraday variant. Signed-off-by: Corentin Labbe Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20210430183651.919317-1-clabbe@baylibre.com Signed-off-by: Vinod Koul --- .../devicetree/bindings/dma/arm-pl08x.txt | 59 --------- .../devicetree/bindings/dma/arm-pl08x.yaml | 136 +++++++++++++++++++++ 2 files changed, 136 insertions(+), 59 deletions(-) delete mode 100644 Documentation/devicetree/bindings/dma/arm-pl08x.txt create mode 100644 Documentation/devicetree/bindings/dma/arm-pl08x.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/dma/arm-pl08x.txt b/Documentation/devicetree/bindings/dma/arm-pl08x.txt deleted file mode 100644 index 0ba81f79266f..000000000000 --- a/Documentation/devicetree/bindings/dma/arm-pl08x.txt +++ /dev/null @@ -1,59 +0,0 @@ -* ARM PrimeCells PL080 and PL081 and derivatives DMA controller - -Required properties: -- compatible: "arm,pl080", "arm,primecell"; - "arm,pl081", "arm,primecell"; - "faraday,ftdmac020", "arm,primecell" -- arm,primecell-periphid: on the FTDMAC020 the primecell ID is not hard-coded - in the hardware and must be specified here as <0x0003b080>. This number - follows the PrimeCell standard numbering using the JEP106 vendor code 0x38 - for Faraday Technology. -- reg: Address range of the PL08x registers -- interrupt: The PL08x interrupt number -- clocks: The clock running the IP core clock -- clock-names: Must contain "apb_pclk" -- lli-bus-interface-ahb1: if AHB master 1 is eligible for fetching LLIs -- lli-bus-interface-ahb2: if AHB master 2 is eligible for fetching LLIs -- mem-bus-interface-ahb1: if AHB master 1 is eligible for fetching memory contents -- mem-bus-interface-ahb2: if AHB master 2 is eligible for fetching memory contents -- #dma-cells: must be <2>. First cell should contain the DMA request, - second cell should contain either 1 or 2 depending on - which AHB master that is used. - -Optional properties: -- dma-channels: contains the total number of DMA channels supported by the DMAC -- dma-requests: contains the total number of DMA requests supported by the DMAC -- memcpy-burst-size: the size of the bursts for memcpy: 1, 4, 8, 16, 32 - 64, 128 or 256 bytes are legal values -- memcpy-bus-width: the bus width used for memcpy in bits: 8, 16 or 32 are legal - values, the Faraday FTDMAC020 can also accept 64 bits - -Clients -Required properties: -- dmas: List of DMA controller phandle, request channel and AHB master id -- dma-names: Names of the aforementioned requested channels - -Example: - -dmac0: dma-controller@10130000 { - compatible = "arm,pl080", "arm,primecell"; - reg = <0x10130000 0x1000>; - interrupt-parent = <&vica>; - interrupts = <15>; - clocks = <&hclkdma0>; - clock-names = "apb_pclk"; - lli-bus-interface-ahb1; - lli-bus-interface-ahb2; - mem-bus-interface-ahb2; - memcpy-burst-size = <256>; - memcpy-bus-width = <32>; - #dma-cells = <2>; -}; - -device@40008000 { - ... - dmas = <&dmac0 0 2 - &dmac0 1 2>; - dma-names = "tx", "rx"; - ... -}; diff --git a/Documentation/devicetree/bindings/dma/arm-pl08x.yaml b/Documentation/devicetree/bindings/dma/arm-pl08x.yaml new file mode 100644 index 000000000000..3bd9eea543ca --- /dev/null +++ b/Documentation/devicetree/bindings/dma/arm-pl08x.yaml @@ -0,0 +1,136 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/dma/arm-pl08x.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: ARM PrimeCells PL080 and PL081 and derivatives DMA controller + +maintainers: + - Vinod Koul + +allOf: + - $ref: "dma-controller.yaml#" + +# We need a select here so we don't match all nodes with 'arm,primecell' +select: + properties: + compatible: + contains: + enum: + - arm,pl080 + - arm,pl081 + required: + - compatible + +properties: + compatible: + oneOf: + - items: + - enum: + - arm,pl080 + - arm,pl081 + - const: arm,primecell + - items: + - const: faraday,ftdma020 + - const: arm,pl080 + - const: arm,primecell + + reg: + maxItems: 1 + description: Address range of the PL08x registers + + interrupts: + minItems: 1 + description: The PL08x interrupt number + + clocks: + minItems: 1 + description: The clock running the IP core clock + + clock-names: + maxItems: 1 + + lli-bus-interface-ahb1: + type: boolean + description: if AHB master 1 is eligible for fetching LLIs + + lli-bus-interface-ahb2: + type: boolean + description: if AHB master 2 is eligible for fetching LLIs + + mem-bus-interface-ahb1: + type: boolean + description: if AHB master 1 is eligible for fetching memory contents + + mem-bus-interface-ahb2: + type: boolean + description: if AHB master 2 is eligible for fetching memory contents + + memcpy-burst-size: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: + - 1 + - 4 + - 8 + - 16 + - 32 + - 64 + - 128 + - 256 + description: the size of the bursts for memcpy + + memcpy-bus-width: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: + - 8 + - 16 + - 32 + - 64 + description: bus width used for memcpy in bits. FTDMAC020 also accept 64 bits + +required: + - reg + - interrupts + - clocks + - clock-names + - "#dma-cells" + +unevaluatedProperties: false + +examples: + - | + dmac0: dma-controller@10130000 { + compatible = "arm,pl080", "arm,primecell"; + reg = <0x10130000 0x1000>; + interrupt-parent = <&vica>; + interrupts = <15>; + clocks = <&hclkdma0>; + clock-names = "apb_pclk"; + lli-bus-interface-ahb1; + lli-bus-interface-ahb2; + mem-bus-interface-ahb2; + memcpy-burst-size = <256>; + memcpy-bus-width = <32>; + #dma-cells = <2>; + }; + - | + #include + #include + #include + dma-controller@67000000 { + compatible = "faraday,ftdma020", "arm,pl080", "arm,primecell"; + /* Faraday Technology FTDMAC020 variant */ + arm,primecell-periphid = <0x0003b080>; + reg = <0x67000000 0x1000>; + interrupts = <9 IRQ_TYPE_EDGE_RISING>; + resets = <&syscon GEMINI_RESET_DMAC>; + clocks = <&syscon GEMINI_CLK_AHB>; + clock-names = "apb_pclk"; + /* Bus interface AHB1 (AHB0) is totally tilted */ + lli-bus-interface-ahb2; + mem-bus-interface-ahb2; + memcpy-burst-size = <256>; + memcpy-bus-width = <32>; + #dma-cells = <2>; + }; -- cgit v1.2.3 From 9a81b8cbc24599bcd009b0b9113e440e9658705d Mon Sep 17 00:00:00 2001 From: Nishanth Menon Date: Mon, 26 Apr 2021 10:54:54 -0500 Subject: dt-bindings: reset: Convert ti,sci-reset to json schema Convert the ti,sci-reset to json schema for better checks and documentation. Differences being: - Drop consumer example as they are documented in the corresponding bindings themselves. - Drop phandle description for reset consumer or cell definition as it is redundant. Signed-off-by: Nishanth Menon Reviewed-by: Rob Herring Reviewed-by: Tero Kristo Acked-by: Stephen Boyd Link: https://lore.kernel.org/r/20210426155457.21221-2-nm@ti.com Signed-off-by: Rob Herring --- .../devicetree/bindings/reset/ti,sci-reset.txt | 62 ---------------------- .../devicetree/bindings/reset/ti,sci-reset.yaml | 51 ++++++++++++++++++ 2 files changed, 51 insertions(+), 62 deletions(-) delete mode 100644 Documentation/devicetree/bindings/reset/ti,sci-reset.txt create mode 100644 Documentation/devicetree/bindings/reset/ti,sci-reset.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/reset/ti,sci-reset.txt b/Documentation/devicetree/bindings/reset/ti,sci-reset.txt deleted file mode 100644 index 8b1cf022f18a..000000000000 --- a/Documentation/devicetree/bindings/reset/ti,sci-reset.txt +++ /dev/null @@ -1,62 +0,0 @@ -Texas Instruments System Control Interface (TI-SCI) Reset Controller -===================================================================== - -Some TI SoCs contain a system controller (like the Power Management Micro -Controller (PMMC) on Keystone 66AK2G SoC) that are responsible for controlling -the state of the various hardware modules present on the SoC. Communication -between the host processor running an OS and the system controller happens -through a protocol called TI System Control Interface (TI-SCI protocol). -For TI SCI details, please refer to the document, -Documentation/devicetree/bindings/arm/keystone/ti,sci.txt - -TI-SCI Reset Controller Node -============================ -This reset controller node uses the TI SCI protocol to perform the reset -management of various hardware modules present on the SoC. Must be a child -node of the associated TI-SCI system controller node. - -Required properties: --------------------- - - compatible : Should be "ti,sci-reset" - - #reset-cells : Should be 2. Please see the reset consumer node below for - usage details. - -TI-SCI Reset Consumer Nodes -=========================== -Each of the reset consumer nodes should have the following properties, -in addition to their own properties. - -Required properties: --------------------- - - resets : A phandle and reset specifier pair, one pair for each reset - signal that affects the device, or that the device manages. - The phandle should point to the TI-SCI reset controller node, - and the reset specifier should have 2 cell-values. The first - cell should contain the device ID. The second cell should - contain the reset mask value used by system controller. - Please refer to the protocol documentation for these values - to be used for different devices, - http://processors.wiki.ti.com/index.php/TISCI#66AK2G02_Data - -Please also refer to Documentation/devicetree/bindings/reset/reset.txt for -common reset controller usage by consumers. - -Example: --------- -The following example demonstrates both a TI-SCI reset controller node and a -consumer (a DSP device) on the 66AK2G SoC. - -pmmc: pmmc { - compatible = "ti,k2g-sci"; - - k2g_reset: reset-controller { - compatible = "ti,sci-reset"; - #reset-cells = <2>; - }; -}; - -dsp0: dsp@10800000 { - ... - resets = <&k2g_reset 0x0046 0x1>; - ... -}; diff --git a/Documentation/devicetree/bindings/reset/ti,sci-reset.yaml b/Documentation/devicetree/bindings/reset/ti,sci-reset.yaml new file mode 100644 index 000000000000..4639d2cec557 --- /dev/null +++ b/Documentation/devicetree/bindings/reset/ti,sci-reset.yaml @@ -0,0 +1,51 @@ +# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/reset/ti,sci-reset.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: TI-SCI reset controller node bindings + +maintainers: + - Nishanth Menon + +description: | + Some TI SoCs contain a system controller (like the Power Management Micro + Controller (PMMC) on Keystone 66AK2G SoC) that are responsible for controlling + the state of the various hardware modules present on the SoC. Communication + between the host processor running an OS and the system controller happens + through a protocol called TI System Control Interface (TI-SCI protocol). + + This reset controller node uses the TI SCI protocol to perform the reset + management of various hardware modules present on the SoC. Must be a child + node of the associated TI-SCI system controller node. + +properties: + $nodename: + pattern: "^reset-controller$" + + compatible: + const: ti,sci-reset + + "#reset-cells": + const: 2 + description: + The two cells represent values that the TI-SCI controller defines. + + The first cell should contain the device ID. + + The second cell should contain the reset mask corresponding to the device + used by system controller. + + Please see http://processors.wiki.ti.com/index.php/TISCI for + protocol documentation for the values to be used for different devices. + + +additionalProperties: false + +examples: + - | + k3_reset: reset-controller { + compatible = "ti,sci-reset"; + #reset-cells = <2>; + }; -- cgit v1.2.3 From a7dbfa6f3877183d6d263ff11184d17b161f61cb Mon Sep 17 00:00:00 2001 From: Nishanth Menon Date: Mon, 26 Apr 2021 10:54:55 -0500 Subject: dt-bindings: clock: Convert ti,sci-clk to json schema Convert the ti,sci-clk to json schema for better checks and documentation. Differences being: - Drop consumer example as they are documented in the corresponding bindings themselves. - Standardize the node name as clock-controller rather than clocks as it is more appropriate. - Drop phandle description for clock-cells as it is redundant. Signed-off-by: Nishanth Menon Reviewed-by: Tero Kristo Acked-by: Stephen Boyd Link: https://lore.kernel.org/r/20210426155457.21221-3-nm@ti.com Signed-off-by: Rob Herring --- .../devicetree/bindings/clock/ti,sci-clk.txt | 36 ---------------- .../devicetree/bindings/clock/ti,sci-clk.yaml | 49 ++++++++++++++++++++++ 2 files changed, 49 insertions(+), 36 deletions(-) delete mode 100644 Documentation/devicetree/bindings/clock/ti,sci-clk.txt create mode 100644 Documentation/devicetree/bindings/clock/ti,sci-clk.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/ti,sci-clk.txt b/Documentation/devicetree/bindings/clock/ti,sci-clk.txt deleted file mode 100644 index 4e59dc6b1778..000000000000 --- a/Documentation/devicetree/bindings/clock/ti,sci-clk.txt +++ /dev/null @@ -1,36 +0,0 @@ -Texas Instruments TI-SCI Clocks -=============================== - -All clocks on Texas Instruments' SoCs that contain a System Controller, -are only controlled by this entity. Communication between a host processor -running an OS and the System Controller happens through a protocol known -as TI-SCI[1]. This clock implementation plugs into the common clock -framework and makes use of the TI-SCI protocol on clock API requests. - -[1] Documentation/devicetree/bindings/arm/keystone/ti,sci.txt - -Required properties: -------------------- -- compatible: Must be "ti,k2g-sci-clk" -- #clock-cells: Shall be 2. - In clock consumers, this cell represents the device ID and clock ID - exposed by the PM firmware. The list of valid values for the device IDs - and clocks IDs for 66AK2G SoC are documented at - http://processors.wiki.ti.com/index.php/TISCI#66AK2G02_Data - -Examples: --------- - -pmmc: pmmc { - compatible = "ti,k2g-sci"; - - k2g_clks: clocks { - compatible = "ti,k2g-sci-clk"; - #clock-cells = <2>; - }; -}; - -uart0: serial@2530c00 { - compatible = "ns16550a"; - clocks = <&k2g_clks 0x2c 0>; -}; diff --git a/Documentation/devicetree/bindings/clock/ti,sci-clk.yaml b/Documentation/devicetree/bindings/clock/ti,sci-clk.yaml new file mode 100644 index 000000000000..0e370289a053 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/ti,sci-clk.yaml @@ -0,0 +1,49 @@ +# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/ti,sci-clk.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: TI-SCI clock controller node bindings + +maintainers: + - Nishanth Menon + +description: | + Some TI SoCs contain a system controller (like the Power Management Micro + Controller (PMMC) on Keystone 66AK2G SoC) that are responsible for controlling + the state of the various hardware modules present on the SoC. Communication + between the host processor running an OS and the system controller happens + through a protocol called TI System Control Interface (TI-SCI protocol). + + This clock controller node uses the TI SCI protocol to perform various clock + management of various hardware modules (devices) present on the SoC. This + node must be a child node of the associated TI-SCI system controller node. + +properties: + $nodename: + pattern: "^clock-controller$" + + compatible: + const: ti,k2g-sci-clk + + "#clock-cells": + const: 2 + description: + The two cells represent values that the TI-SCI controller defines. + + The first cell should contain the device ID. + + The second cell should contain the clock ID. + + Please see http://processors.wiki.ti.com/index.php/TISCI for + protocol documentation for the values to be used for different devices. + +additionalProperties: false + +examples: + - | + k3_clks: clock-controller { + compatible = "ti,k2g-sci-clk"; + #clock-cells = <2>; + }; -- cgit v1.2.3 From fda55c7256fea589008e62b7a24099ac98f33967 Mon Sep 17 00:00:00 2001 From: Nishanth Menon Date: Mon, 26 Apr 2021 10:54:56 -0500 Subject: dt-bindings: soc: ti: Convert ti,sci-pm-domain to json schema Convert the ti,sci-pm-domain to json schema for better checks and documentation. Differences being: - Drop consumer example as they are documented in the corresponding bindings themselves. - Drop phandle description for reset consumer or cell definition as it is redundant. Signed-off-by: Nishanth Menon Reviewed-by: Rob Herring Reviewed-by: Tero Kristo Acked-by: Stephen Boyd Link: https://lore.kernel.org/r/20210426155457.21221-4-nm@ti.com Signed-off-by: Rob Herring --- .../devicetree/bindings/soc/ti/sci-pm-domain.txt | 65 ---------------------- .../devicetree/bindings/soc/ti/sci-pm-domain.yaml | 59 ++++++++++++++++++++ 2 files changed, 59 insertions(+), 65 deletions(-) delete mode 100644 Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt create mode 100644 Documentation/devicetree/bindings/soc/ti/sci-pm-domain.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt b/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt deleted file mode 100644 index 6217e64309de..000000000000 --- a/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt +++ /dev/null @@ -1,65 +0,0 @@ -Texas Instruments TI-SCI Generic Power Domain ---------------------------------------------- - -Some TI SoCs contain a system controller (like the PMMC, etc...) that is -responsible for controlling the state of the IPs that are present. -Communication between the host processor running an OS and the system -controller happens through a protocol known as TI-SCI [1]. - -[1] Documentation/devicetree/bindings/arm/keystone/ti,sci.txt - -PM Domain Node -============== -The PM domain node represents the global PM domain managed by the PMMC, which -in this case is the implementation as documented by the generic PM domain -bindings in Documentation/devicetree/bindings/power/power-domain.yaml. Because -this relies on the TI SCI protocol to communicate with the PMMC it must be a -child of the pmmc node. - -Required Properties: --------------------- -- compatible: should be "ti,sci-pm-domain" -- #power-domain-cells: Can be one of the following: - 1: Containing the device id of each node - 2: First entry should be device id - Second entry should be one of the floowing: - TI_SCI_PD_EXCLUSIVE: To allow device to be - exclusively controlled by - the requesting hosts. - TI_SCI_PD_SHARED: To allow device to be shared - by multiple hosts. - -Example (K2G): -------------- - pmmc: pmmc { - compatible = "ti,k2g-sci"; - ... - - k2g_pds: power-controller { - compatible = "ti,sci-pm-domain"; - #power-domain-cells = <1>; - }; - }; - -PM Domain Consumers -=================== -Hardware blocks belonging to a PM domain should contain a "power-domains" -property that is a phandle pointing to the corresponding PM domain node -along with an index representing the device id to be passed to the PMMC -for device control. - -Required Properties: --------------------- -- power-domains: phandle pointing to the corresponding PM domain node - and an ID representing the device. - -See http://processors.wiki.ti.com/index.php/TISCI#66AK2G02_Data for the list -of valid identifiers for k2g. - -Example (K2G): --------------------- - uart0: serial@2530c00 { - compatible = "ns16550a"; - ... - power-domains = <&k2g_pds 0x002c>; - }; diff --git a/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.yaml b/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.yaml new file mode 100644 index 000000000000..9e6cb4ee9755 --- /dev/null +++ b/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.yaml @@ -0,0 +1,59 @@ +# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/soc/ti/sci-pm-domain.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: TI-SCI generic power domain node bindings + +maintainers: + - Nishanth Menon + +allOf: + - $ref: /schemas/power/power-domain.yaml# + +description: | + Some TI SoCs contain a system controller (like the Power Management Micro + Controller (PMMC) on Keystone 66AK2G SoC) that are responsible for controlling + the state of the various hardware modules present on the SoC. Communication + between the host processor running an OS and the system controller happens + through a protocol called TI System Control Interface (TI-SCI protocol). + + This PM domain node represents the global PM domain managed by the TI-SCI + controller. Since this relies on the TI SCI protocol to communicate with + the TI-SCI controller, it must be a child of the TI-SCI controller node. + +properties: + compatible: + const: ti,sci-pm-domain + + "#power-domain-cells": + enum: [1, 2] + description: + The two cells represent values that the TI-SCI controller defines. + + The first cell should contain the device ID. + + The second cell, if cell-value is 2, should be one of the following + TI_SCI_PD_EXCLUSIVE - Allows the device to be exclusively controlled + or + TI_SCI_PD_SHARED - Allows the device to be shared by multiple hosts. + Please refer to dt-bindings/soc/ti,sci_pm_domain.h for the definitions. + + Please see http://processors.wiki.ti.com/index.php/TISCI for + protocol documentation for the values to be used for different devices. + +additionalProperties: false + +examples: + - | + k2g_pds: power-controller { + compatible = "ti,sci-pm-domain"; + #power-domain-cells = <1>; + }; + + - | + k3_pds: power-controller { + compatible = "ti,sci-pm-domain"; + #power-domain-cells = <2>; + }; -- cgit v1.2.3 From 5a9652f6994eb7a3424de3e206860dd3bef8b819 Mon Sep 17 00:00:00 2001 From: Nishanth Menon Date: Mon, 26 Apr 2021 10:54:57 -0500 Subject: dt-bindings: arm: keystone: Convert ti,sci to json schema Convert the ti,sci to json schema for better checks and documentation. NOTE: This change does introduce a stricter naming convention for TI-SCI controller nodes. Signed-off-by: Nishanth Menon Reviewed-by: Tero Kristo Acked-by: Stephen Boyd Link: https://lore.kernel.org/r/20210426155457.21221-5-nm@ti.com Signed-off-by: Rob Herring --- .../devicetree/bindings/arm/keystone/ti,sci.txt | 86 -------------- .../devicetree/bindings/arm/keystone/ti,sci.yaml | 129 +++++++++++++++++++++ 2 files changed, 129 insertions(+), 86 deletions(-) delete mode 100644 Documentation/devicetree/bindings/arm/keystone/ti,sci.txt create mode 100644 Documentation/devicetree/bindings/arm/keystone/ti,sci.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/keystone/ti,sci.txt b/Documentation/devicetree/bindings/arm/keystone/ti,sci.txt deleted file mode 100644 index 6f0cd31c1520..000000000000 --- a/Documentation/devicetree/bindings/arm/keystone/ti,sci.txt +++ /dev/null @@ -1,86 +0,0 @@ -Texas Instruments System Control Interface (TI-SCI) Message Protocol --------------------------------------------------------------------- - -Texas Instrument's processors including those belonging to Keystone generation -of processors have separate hardware entity which is now responsible for the -management of the System on Chip (SoC) system. These include various system -level functions as well. - -An example of such an SoC is K2G, which contains the system control hardware -block called Power Management Micro Controller (PMMC). This hardware block is -initialized early into boot process and provides services to Operating Systems -on multiple processors including ones running Linux. - -See http://processors.wiki.ti.com/index.php/TISCI for protocol definition. - -TI-SCI controller Device Node: -============================= - -The TI-SCI node describes the Texas Instrument's System Controller entity node. -This parent node may optionally have additional children nodes which describe -specific functionality such as clocks, power domain, reset or additional -functionality as may be required for the SoC. This hierarchy also describes the -relationship between the TI-SCI parent node to the child node. - -Required properties: -------------------- -- compatible: should be "ti,k2g-sci" for TI 66AK2G SoC - should be "ti,am654-sci" for for TI AM654 SoC -- mbox-names: - "rx" - Mailbox corresponding to receive path - "tx" - Mailbox corresponding to transmit path - -- mboxes: Mailboxes corresponding to the mbox-names. Each value of the mboxes - property should contain a phandle to the mailbox controller device - node and an args specifier that will be the phandle to the intended - sub-mailbox child node to be used for communication. - -See Documentation/devicetree/bindings/mailbox/mailbox.txt for more details -about the generic mailbox controller and client driver bindings. Also see -Documentation/devicetree/bindings/mailbox/ti,message-manager.txt for typical -controller that is used to communicate with this System controllers. - -Optional Properties: -------------------- -- reg-names: - debug_messages - Map the Debug message region -- reg: register space corresponding to the debug_messages -- ti,system-reboot-controller: If system reboot can be triggered by SoC reboot -- ti,host-id: Integer value corresponding to the host ID assigned by Firmware - for identification of host processing entities such as virtual - machines - -Example (K2G): -------------- - pmmc: pmmc { - compatible = "ti,k2g-sci"; - ti,host-id = <2>; - mbox-names = "rx", "tx"; - mboxes= <&msgmgr &msgmgr_proxy_pmmc_rx>, - <&msgmgr &msgmgr_proxy_pmmc_tx>; - reg-names = "debug_messages"; - reg = <0x02921800 0x800>; - }; - - -TI-SCI Client Device Node: -========================= - -Client nodes are maintained as children of the relevant TI-SCI device node. - -Example (K2G): -------------- - pmmc: pmmc { - compatible = "ti,k2g-sci"; - ... - - my_clk_node: clk_node { - ... - ... - }; - - my_pd_node: pd_node { - ... - ... - }; - }; diff --git a/Documentation/devicetree/bindings/arm/keystone/ti,sci.yaml b/Documentation/devicetree/bindings/arm/keystone/ti,sci.yaml new file mode 100644 index 000000000000..34f5f877d444 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/keystone/ti,sci.yaml @@ -0,0 +1,129 @@ +# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/arm/keystone/ti,sci.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: TI-SCI controller device node bindings + +maintainers: + - Nishanth Menon + +description: | + Texas Instrument's processors including those belonging to Keystone generation + of processors have separate hardware entity which is now responsible for the + management of the System on Chip (SoC) system. These include various system + level functions as well. + + An example of such an SoC is K2G, which contains the system control hardware + block called Power Management Micro Controller (PMMC). This hardware block is + initialized early into boot process and provides services to Operating Systems + on multiple processors including ones running Linux. + + See http://processors.wiki.ti.com/index.php/TISCI for protocol definition. + + The TI-SCI node describes the Texas Instrument's System Controller entity node. + This parent node may optionally have additional children nodes which describe + specific functionality such as clocks, power domain, reset or additional + functionality as may be required for the SoC. This hierarchy also describes the + relationship between the TI-SCI parent node to the child node. + +properties: + $nodename: + pattern: "^system-controller@[0-9a-f]+$" + + compatible: + oneOf: + - description: System controller on TI 66AK2G SoC and other K3 SoCs + items: + - const: ti,k2g-sci + - description: System controller on TI AM654 SoC + items: + - const: ti,am654-sci + + reg-names: + description: | + Specifies the debug messages memory mapped region that is optionally + made available from TI-SCI controller. + const: debug_messages + + reg: + minItems: 1 + + mbox-names: + description: | + Specifies the mailboxes used to communicate with TI-SCI Controller + made available from TI-SCI controller. + items: + - const: rx + - const: tx + + mboxes: + minItems: 2 + + ti,system-reboot-controller: + description: Determines If system reboot can be triggered by SoC reboot + type: boolean + + ti,host-id: + $ref: /schemas/types.yaml#/definitions/uint32 + description: | + Value corresponding to the host ID assigned by Firmware + for identification of host processing entities such as virtual machines. + + power-controller: + type: object + $ref: /schemas/soc/ti/sci-pm-domain.yaml# + + clock-controller: + type: object + $ref: /schemas/clock/ti,sci-clk.yaml# + + reset-controller: + type: object + $ref: /schemas/reset/ti,sci-reset.yaml# + +required: + - compatible + - mbox-names + - mboxes + +additionalProperties: false + +examples: + - | + pmmc: system-controller@2921800 { + compatible = "ti,k2g-sci"; + ti,system-reboot-controller; + mbox-names = "rx", "tx"; + mboxes= <&msgmgr 5 2>, + <&msgmgr 0 0>; + reg-names = "debug_messages"; + reg = <0x02921800 0x800>; + }; + + - | + dmsc: system-controller@44083000 { + compatible = "ti,k2g-sci"; + ti,host-id = <12>; + mbox-names = "rx", "tx"; + mboxes= <&secure_proxy_main 11>, + <&secure_proxy_main 13>; + reg-names = "debug_messages"; + reg = <0x44083000 0x1000>; + + k3_pds: power-controller { + compatible = "ti,sci-pm-domain"; + #power-domain-cells = <2>; + }; + + k3_clks: clock-controller { + compatible = "ti,k2g-sci-clk"; + #clock-cells = <2>; + }; + + k3_reset: reset-controller { + compatible = "ti,sci-reset"; + #reset-cells = <2>; + }; + }; -- cgit v1.2.3 From be78329717e47649789fd4604960c6fc1a859eb1 Mon Sep 17 00:00:00 2001 From: Nishanth Menon Date: Mon, 26 Apr 2021 11:40:08 -0500 Subject: dt-bindings: arm: firmware: Convert linaro,optee-tz to json schema Convert linaro,optee-tz to json schema format for better documentation and error checks. NOTE: This change does introduce a stricter naming convention for optee nodes. Signed-off-by: Nishanth Menon Link: https://lore.kernel.org/r/20210426164008.20000-1-nm@ti.com Signed-off-by: Rob Herring --- .../bindings/arm/firmware/linaro,optee-tz.txt | 31 ------------ .../bindings/arm/firmware/linaro,optee-tz.yaml | 58 ++++++++++++++++++++++ 2 files changed, 58 insertions(+), 31 deletions(-) delete mode 100644 Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.txt create mode 100644 Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.txt b/Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.txt deleted file mode 100644 index d38834c67dff..000000000000 --- a/Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.txt +++ /dev/null @@ -1,31 +0,0 @@ -OP-TEE Device Tree Bindings - -OP-TEE is a piece of software using hardware features to provide a Trusted -Execution Environment. The security can be provided with ARM TrustZone, but -also by virtualization or a separate chip. - -We're using "linaro" as the first part of the compatible property for -the reference implementation maintained by Linaro. - -* OP-TEE based on ARM TrustZone required properties: - -- compatible : should contain "linaro,optee-tz" - -- method : The method of calling the OP-TEE Trusted OS. Permitted - values are: - - "smc" : SMC #0, with the register assignments specified - in drivers/tee/optee/optee_smc.h - - "hvc" : HVC #0, with the register assignments specified - in drivers/tee/optee/optee_smc.h - - - -Example: - firmware { - optee { - compatible = "linaro,optee-tz"; - method = "smc"; - }; - }; diff --git a/Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.yaml b/Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.yaml new file mode 100644 index 000000000000..c24047c1fdd5 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.yaml @@ -0,0 +1,58 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/arm/firmware/linaro,optee-tz.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: OP-TEE Device Tree Bindings + +maintainers: + - Jens Wiklander + +description: | + OP-TEE is a piece of software using hardware features to provide a Trusted + Execution Environment. The security can be provided with ARM TrustZone, but + also by virtualization or a separate chip. + + We're using "linaro" as the first part of the compatible property for + the reference implementation maintained by Linaro. + +properties: + $nodename: + const: optee + + compatible: + const: linaro,optee-tz + + method: + enum: [smc, hvc] + description: | + The method of calling the OP-TEE Trusted OS depending on smc or hvc + instruction usage. + SMC #0, register assignments + or + HVC #0, register assignments + register assignments are specified in drivers/tee/optee/optee_smc.h + +required: + - compatible + - method + +additionalProperties: false + +examples: + - | + firmware { + optee { + compatible = "linaro,optee-tz"; + method = "smc"; + }; + }; + + - | + firmware { + optee { + compatible = "linaro,optee-tz"; + method = "hvc"; + }; + }; -- cgit v1.2.3 From a869742ff51e5eb6aeaa43151ad69281f0d3c98a Mon Sep 17 00:00:00 2001 From: Geert Uytterhoeven Date: Thu, 29 Apr 2021 14:45:03 +0200 Subject: dt-bindings: ata: renesas,rcar-sata: Make power-domains and resets required The "power-domains" property is present on all supported platforms. The "resets" property is present on all but R-Car H1. Signed-off-by: Geert Uytterhoeven Link: https://lore.kernel.org/r/ca35d7d837b155c69232a1c25060737b4c87720f.1619700260.git.geert+renesas@glider.be Signed-off-by: Rob Herring --- Documentation/devicetree/bindings/ata/renesas,rcar-sata.yaml | 11 +++++++++++ 1 file changed, 11 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/ata/renesas,rcar-sata.yaml b/Documentation/devicetree/bindings/ata/renesas,rcar-sata.yaml index d06096a7ba4b..c060c7914cae 100644 --- a/Documentation/devicetree/bindings/ata/renesas,rcar-sata.yaml +++ b/Documentation/devicetree/bindings/ata/renesas,rcar-sata.yaml @@ -53,6 +53,17 @@ required: - reg - interrupts - clocks + - power-domains + +if: + not: + properties: + compatible: + contains: + const: renesas,sata-r8a7779 +then: + required: + - resets additionalProperties: false -- cgit v1.2.3 From 4fa9ee2e65ece14f040cc3596525c9e8d6a395eb Mon Sep 17 00:00:00 2001 From: Geert Uytterhoeven Date: Thu, 29 Apr 2021 14:46:45 +0200 Subject: dt-bindings: pwm: renesas,pwm-rcar: Make power-domains and resets required The "power-domains" property is present on all supported platforms. The "resets" property is present on all but R-Car Gen1. Signed-off-by: Geert Uytterhoeven Link: https://lore.kernel.org/r/16e82b5019b913f9a63e312166a37ef67266d425.1619700364.git.geert+renesas@glider.be Signed-off-by: Rob Herring --- Documentation/devicetree/bindings/pwm/renesas,pwm-rcar.yaml | 13 +++++++++++++ 1 file changed, 13 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pwm/renesas,pwm-rcar.yaml b/Documentation/devicetree/bindings/pwm/renesas,pwm-rcar.yaml index 3c2fa2e93d1b..7ea1070b4b3a 100644 --- a/Documentation/devicetree/bindings/pwm/renesas,pwm-rcar.yaml +++ b/Documentation/devicetree/bindings/pwm/renesas,pwm-rcar.yaml @@ -61,6 +61,19 @@ required: - reg - '#pwm-cells' - clocks + - power-domains + +if: + not: + properties: + compatible: + contains: + enum: + - renesas,pwm-r8a7778 + - renesas,pwm-r8a7779 +then: + required: + - resets additionalProperties: false -- cgit v1.2.3 From 4d92239b6517e705433d89c23d792c7dcf35235e Mon Sep 17 00:00:00 2001 From: Geert Uytterhoeven Date: Tue, 4 May 2021 11:09:00 +0200 Subject: dt-bindings: power: sysc-rmobile: Convert to json-schema Convert the Renesas R-Mobile System Controller (SYSC) Device Tree binding documentation to json-schema. Document missing properties. Drop consumer example, as it does not belong here. Signed-off-by: Geert Uytterhoeven Link: https://lore.kernel.org/r/22150cfd2ef9d57e84eb53a5dfed8379627a9423.1620119210.git.geert+renesas@glider.be Signed-off-by: Rob Herring --- .../bindings/power/renesas,sysc-rmobile.txt | 100 ----------------- .../bindings/power/renesas,sysc-rmobile.yaml | 121 +++++++++++++++++++++ 2 files changed, 121 insertions(+), 100 deletions(-) delete mode 100644 Documentation/devicetree/bindings/power/renesas,sysc-rmobile.txt create mode 100644 Documentation/devicetree/bindings/power/renesas,sysc-rmobile.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/power/renesas,sysc-rmobile.txt b/Documentation/devicetree/bindings/power/renesas,sysc-rmobile.txt deleted file mode 100644 index 49aba15dff8b..000000000000 --- a/Documentation/devicetree/bindings/power/renesas,sysc-rmobile.txt +++ /dev/null @@ -1,100 +0,0 @@ -DT bindings for the Renesas R-Mobile System Controller - -== System Controller Node == - -The R-Mobile System Controller provides the following functions: - - Boot mode management, - - Reset generation, - - Power management. - -Required properties: -- compatible: Should be "renesas,sysc-", "renesas,sysc-rmobile" as - fallback. - Examples with soctypes are: - - "renesas,sysc-r8a73a4" (R-Mobile APE6) - - "renesas,sysc-r8a7740" (R-Mobile A1) - - "renesas,sysc-sh73a0" (SH-Mobile AG5) -- reg: Two address start and address range blocks for the device: - - The first block refers to the normally accessible registers, - - the second block refers to the registers protected by the HPB - semaphore. - -Optional nodes: -- pm-domains: This node contains a hierarchy of PM domain nodes, which should - match the Power Area Hierarchy in the Power Domain Specifications section of - the device's datasheet. - - -== PM Domain Nodes == - -Each of the PM domain nodes represents a PM domain, as documented by the -generic PM domain bindings in -Documentation/devicetree/bindings/power/power-domain.yaml. - -The nodes should be named by the real power area names, and thus their names -should be unique. - -Required properties: - - #power-domain-cells: Must be 0. - -Optional properties: -- reg: If the PM domain is not always-on, this property must contain the bit - index number for the corresponding power area in the various Power - Control and Status Registers. The parent's node must contain the - following two properties: - - #address-cells: Must be 1, - - #size-cells: Must be 0. - If the PM domain is always-on, this property must be omitted. - - -Example: - -This shows a subset of the r8a7740 PM domain hierarchy, containing the -C5 "always-on" domain, 2 of its subdomains (A4S and A4SU), and the A3SP domain, -which is a subdomain of A4S. - - sysc: system-controller@e6180000 { - compatible = "renesas,sysc-r8a7740", "renesas,sysc-rmobile"; - reg = <0xe6180000 0x8000>, <0xe6188000 0x8000>; - - pm-domains { - pd_c5: c5 { - #address-cells = <1>; - #size-cells = <0>; - #power-domain-cells = <0>; - - pd_a4s: a4s@10 { - reg = <10>; - #address-cells = <1>; - #size-cells = <0>; - #power-domain-cells = <0>; - - pd_a3sp: a3sp@11 { - reg = <11>; - #power-domain-cells = <0>; - }; - }; - - pd_a4su: a4su@20 { - reg = <20>; - #power-domain-cells = <0>; - }; - }; - }; - }; - - -== PM Domain Consumers == - -Hardware blocks belonging to a PM domain should contain a "power-domains" -property that is a phandle pointing to the corresponding PM domain node. - -Example: - - tpu: pwm@e6600000 { - compatible = "renesas,tpu-r8a7740", "renesas,tpu"; - reg = <0xe6600000 0x100>; - clocks = <&mstp3_clks R8A7740_CLK_TPU0>; - power-domains = <&pd_a3sp>; - #pwm-cells = <3>; - }; diff --git a/Documentation/devicetree/bindings/power/renesas,sysc-rmobile.yaml b/Documentation/devicetree/bindings/power/renesas,sysc-rmobile.yaml new file mode 100644 index 000000000000..559718997de7 --- /dev/null +++ b/Documentation/devicetree/bindings/power/renesas,sysc-rmobile.yaml @@ -0,0 +1,121 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/power/renesas,sysc-rmobile.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Renesas R-Mobile System Controller + +maintainers: + - Geert Uytterhoeven + - Magnus Damm + +description: | + The R-Mobile System Controller provides the following functions: + - Boot mode management, + - Reset generation, + - Power management. + +properties: + compatible: + items: + - enum: + - renesas,sysc-r8a73a4 # R-Mobile APE6 + - renesas,sysc-r8a7740 # R-Mobile A1 + - renesas,sysc-sh73a0 # SH-Mobile AG5 + - const: renesas,sysc-rmobile # Generic SH/R-Mobile + + reg: + items: + - description: Normally accessible register block + - description: Register block protected by the HPB semaphore + + pm-domains: + type: object + description: | + This node contains a hierarchy of PM domain nodes, which should match the + Power Area Hierarchy in the Power Domain Specifications section of the + device's datasheet. + + properties: + '#address-cells': + const: 1 + + '#size-cells': + const: 0 + + additionalProperties: + $ref: "#/$defs/pd-node" + +required: + - compatible + - reg + - pm-domains + +additionalProperties: false + +$defs: + pd-node: + type: object + description: + PM domain node representing a PM domain. This node hould be named by + the real power area name, and thus its name should be unique. + + properties: + reg: + maxItems: 1 + description: + If the PM domain is not always-on, this property must contain the + bit index number for the corresponding power area in the various + Power Control and Status Registers. + If the PM domain is always-on, this property must be omitted. + + '#address-cells': + const: 1 + + '#size-cells': + const: 0 + + '#power-domain-cells': + const: 0 + + required: + - '#power-domain-cells' + + additionalProperties: + $ref: "#/$defs/pd-node" + +examples: + - | + // This shows a subset of the r8a7740 PM domain hierarchy, containing the + // C5 "always-on" domain, 2 of its subdomains (A4S and A4SU), and the A3SP + // domain, which is a subdomain of A4S. + sysc: system-controller@e6180000 { + compatible = "renesas,sysc-r8a7740", "renesas,sysc-rmobile"; + reg = <0xe6180000 0x8000>, <0xe6188000 0x8000>; + + pm-domains { + pd_c5: c5 { + #address-cells = <1>; + #size-cells = <0>; + #power-domain-cells = <0>; + + pd_a4s: a4s@10 { + reg = <10>; + #address-cells = <1>; + #size-cells = <0>; + #power-domain-cells = <0>; + + pd_a3sp: a3sp@11 { + reg = <11>; + #power-domain-cells = <0>; + }; + }; + + pd_a4su: a4su@20 { + reg = <20>; + #power-domain-cells = <0>; + }; + }; + }; + }; -- cgit v1.2.3 From aef654741de377526d91fb24926348dc2e994822 Mon Sep 17 00:00:00 2001 From: Geert Uytterhoeven Date: Tue, 4 May 2021 11:10:20 +0200 Subject: dt-bindings: clk: emev2: Convert to json-schema Convert the Renesas EMMA Mobile EV2 System Management Unit (SMU) Device Tree binding documentation to json-schema. Drop the separate provider examples, as they mostly duplicate the global example. Drop the consumer example, as it doesn't belong here. Update the global example to match reality. Signed-off-by: Geert Uytterhoeven Link: https://lore.kernel.org/r/526e1a412145a0fcc5a43dcf6de5c580301017cb.1620119350.git.geert+renesas@glider.be Signed-off-by: Rob Herring --- .../bindings/clock/renesas,emev2-smu.txt | 98 --------------- .../bindings/clock/renesas,emev2-smu.yaml | 140 +++++++++++++++++++++ 2 files changed, 140 insertions(+), 98 deletions(-) delete mode 100644 Documentation/devicetree/bindings/clock/renesas,emev2-smu.txt create mode 100644 Documentation/devicetree/bindings/clock/renesas,emev2-smu.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/renesas,emev2-smu.txt b/Documentation/devicetree/bindings/clock/renesas,emev2-smu.txt deleted file mode 100644 index 268ca615459e..000000000000 --- a/Documentation/devicetree/bindings/clock/renesas,emev2-smu.txt +++ /dev/null @@ -1,98 +0,0 @@ -Device tree Clock bindings for Renesas EMMA Mobile EV2 - -This binding uses the common clock binding. - -* SMU -System Management Unit described in user's manual R19UH0037EJ1000_SMU. -This is not a clock provider, but clocks under SMU depend on it. - -Required properties: -- compatible: Should be "renesas,emev2-smu" -- reg: Address and Size of SMU registers - -* SMU_CLKDIV -Function block with an input mux and a divider, which corresponds to -"Serial clock generator" in fig."Clock System Overview" of the manual, -and "xxx frequency division setting register" (XXXCLKDIV) registers. -This makes internal (neither input nor output) clock that is provided -to input of xxxGCLK block. - -Required properties: -- compatible: Should be "renesas,emev2-smu-clkdiv" -- reg: Byte offset from SMU base and Bit position in the register -- clocks: Parent clocks. Input clocks as described in clock-bindings.txt -- #clock-cells: Should be <0> - -* SMU_GCLK -Clock gating node shown as "Clock stop processing block" in the -fig."Clock System Overview" of the manual. -Registers are "xxx clock gate control register" (XXXGCLKCTRL). - -Required properties: -- compatible: Should be "renesas,emev2-smu-gclk" -- reg: Byte offset from SMU base and Bit position in the register -- clocks: Input clock as described in clock-bindings.txt -- #clock-cells: Should be <0> - -Example of provider: - -usia_u0_sclkdiv: usia_u0_sclkdiv { - compatible = "renesas,emev2-smu-clkdiv"; - reg = <0x610 0>; - clocks = <&pll3_fo>, <&pll4_fo>, <&pll1_fo>, <&osc1_fo>; - #clock-cells = <0>; -}; - -usia_u0_sclk: usia_u0_sclk { - compatible = "renesas,emev2-smu-gclk"; - reg = <0x4a0 1>; - clocks = <&usia_u0_sclkdiv>; - #clock-cells = <0>; -}; - -Example of consumer: - -serial@e1020000 { - compatible = "renesas,em-uart"; - reg = <0xe1020000 0x38>; - interrupts = <0 8 0>; - clocks = <&usia_u0_sclk>; - clock-names = "sclk"; -}; - -Example of clock-tree description: - - This describes a clock path in the clock tree - c32ki -> pll3_fo -> usia_u0_sclkdiv -> usia_u0_sclk - -smu@e0110000 { - compatible = "renesas,emev2-smu"; - reg = <0xe0110000 0x10000>; - #address-cells = <2>; - #size-cells = <0>; - - c32ki: c32ki { - compatible = "fixed-clock"; - clock-frequency = <32768>; - #clock-cells = <0>; - }; - pll3_fo: pll3_fo { - compatible = "fixed-factor-clock"; - clocks = <&c32ki>; - clock-div = <1>; - clock-mult = <7000>; - #clock-cells = <0>; - }; - usia_u0_sclkdiv: usia_u0_sclkdiv { - compatible = "renesas,emev2-smu-clkdiv"; - reg = <0x610 0>; - clocks = <&pll3_fo>; - #clock-cells = <0>; - }; - usia_u0_sclk: usia_u0_sclk { - compatible = "renesas,emev2-smu-gclk"; - reg = <0x4a0 1>; - clocks = <&usia_u0_sclkdiv>; - #clock-cells = <0>; - }; -}; diff --git a/Documentation/devicetree/bindings/clock/renesas,emev2-smu.yaml b/Documentation/devicetree/bindings/clock/renesas,emev2-smu.yaml new file mode 100644 index 000000000000..4d9a64800481 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/renesas,emev2-smu.yaml @@ -0,0 +1,140 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/renesas,emev2-smu.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Renesas EMMA Mobile EV2 System Management Unit + +maintainers: + - Geert Uytterhoeven + - Magnus Damm + +description: | + The System Management Unit is described in user's manual R19UH0037EJ1000_SMU. + This is not a clock provider, but clocks under SMU depend on it. + +properties: + compatible: + const: renesas,emev2-smu + + reg: + maxItems: 1 + + '#address-cells': + const: 2 + + '#size-cells': + const: 0 + +required: + - compatible + - reg + - '#address-cells' + - '#size-cells' + +patternProperties: + ".*sclkdiv@.*": + type: object + + description: | + Function block with an input mux and a divider, which corresponds to + "Serial clock generator" in fig. "Clock System Overview" of the manual, + and "xxx frequency division setting register" (XXXCLKDIV) registers. + This makes internal (neither input nor output) clock that is provided + to input of xxxGCLK block. + + properties: + compatible: + const: renesas,emev2-smu-clkdiv + + reg: + maxItems: 1 + description: + Byte offset from SMU base and Bit position in the register. + + clocks: + minItems: 1 + maxItems: 4 + + '#clock-cells': + const: 0 + + required: + - compatible + - reg + - clocks + - '#clock-cells' + + additionalProperties: false + + ".*sclk@.*": + type: object + + description: | + Clock gating node shown as "Clock stop processing block" in the + fig. "Clock System Overview" of the manual. + Registers are "xxx clock gate control register" (XXXGCLKCTRL). + + properties: + compatible: + const: renesas,emev2-smu-gclk + + reg: + maxItems: 1 + description: + Byte offset from SMU base and Bit position in the register. + + clocks: + maxItems: 1 + + '#clock-cells': + const: 0 + + required: + - compatible + - reg + - clocks + - '#clock-cells' + + additionalProperties: false + +additionalProperties: true + +examples: + - | + // Example of clock-tree description: + // + // This describes a clock path in the clock tree + // c32ki -> pll3_fo -> usia_u0_sclkdiv -> usia_u0_sclk + clocks@e0110000 { + compatible = "renesas,emev2-smu"; + reg = <0xe0110000 0x10000>; + #address-cells = <2>; + #size-cells = <0>; + + c32ki: c32ki { + compatible = "fixed-clock"; + clock-frequency = <32768>; + #clock-cells = <0>; + }; + pll3_fo: pll3_fo { + compatible = "fixed-factor-clock"; + clocks = <&c32ki>; + clock-div = <1>; + clock-mult = <7000>; + #clock-cells = <0>; + }; + usia_u0_sclkdiv: usia_u0_sclkdiv@610,0 { + compatible = "renesas,emev2-smu-clkdiv"; + reg = <0x610 0>; + clocks = <&pll3_fo>; + #clock-cells = <0>; + }; + usia_u0_sclk: usia_u0_sclk@4a0,1 { + compatible = "renesas,emev2-smu-gclk"; + reg = <0x4a0 1>; + clocks = <&usia_u0_sclkdiv>; + #clock-cells = <0>; + }; + }; -- cgit v1.2.3 From 57d4ef85fc33d40856d0a64d38ccf2b9030805d0 Mon Sep 17 00:00:00 2001 From: Geert Uytterhoeven Date: Tue, 4 May 2021 11:12:31 +0200 Subject: dt-bindings: clock: renesas,r9a06g032-sysctrl: Convert to json-schema Convert the Renesas RZ/N1D (R9A06G032) System Controller (SYSCTRL) Device Tree binding documentation to json-schema. Drop the consumer example, as it doesn't belong here. Signed-off-by: Geert Uytterhoeven Link: https://lore.kernel.org/r/24d1bd7c4c46747f4e2828974c2e2e48e778bff8.1620119439.git.geert+renesas@glider.be Signed-off-by: Rob Herring --- .../bindings/clock/renesas,r9a06g032-sysctrl.txt | 46 ---------------- .../bindings/clock/renesas,r9a06g032-sysctrl.yaml | 62 ++++++++++++++++++++++ 2 files changed, 62 insertions(+), 46 deletions(-) delete mode 100644 Documentation/devicetree/bindings/clock/renesas,r9a06g032-sysctrl.txt create mode 100644 Documentation/devicetree/bindings/clock/renesas,r9a06g032-sysctrl.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/renesas,r9a06g032-sysctrl.txt b/Documentation/devicetree/bindings/clock/renesas,r9a06g032-sysctrl.txt deleted file mode 100644 index aed713cf0831..000000000000 --- a/Documentation/devicetree/bindings/clock/renesas,r9a06g032-sysctrl.txt +++ /dev/null @@ -1,46 +0,0 @@ -* Renesas R9A06G032 SYSCTRL - -Required Properties: - - - compatible: Must be: - - "renesas,r9a06g032-sysctrl" - - reg: Base address and length of the SYSCTRL IO block. - - #clock-cells: Must be 1 - - clocks: References to the parent clocks: - - external 40mhz crystal. - - external (optional) 32.768khz - - external (optional) jtag input - - external (optional) RGMII_REFCLK - - clock-names: Must be: - clock-names = "mclk", "rtc", "jtag", "rgmii_ref_ext"; - - #power-domain-cells: Must be 0 - -Examples --------- - - - SYSCTRL node: - - sysctrl: system-controller@4000c000 { - compatible = "renesas,r9a06g032-sysctrl"; - reg = <0x4000c000 0x1000>; - #clock-cells = <1>; - - clocks = <&ext_mclk>, <&ext_rtc_clk>, - <&ext_jtag_clk>, <&ext_rgmii_ref>; - clock-names = "mclk", "rtc", "jtag", "rgmii_ref_ext"; - #power-domain-cells = <0>; - }; - - - Other nodes can use the clocks provided by SYSCTRL as in: - - #include - uart0: serial@40060000 { - compatible = "snps,dw-apb-uart"; - reg = <0x40060000 0x400>; - interrupts = ; - reg-shift = <2>; - reg-io-width = <4>; - clocks = <&sysctrl R9A06G032_CLK_UART0>, <&sysctrl R9A06G032_HCLK_UART0>; - clock-names = "baudclk", "apb_pclk"; - power-domains = <&sysctrl>; - }; diff --git a/Documentation/devicetree/bindings/clock/renesas,r9a06g032-sysctrl.yaml b/Documentation/devicetree/bindings/clock/renesas,r9a06g032-sysctrl.yaml new file mode 100644 index 000000000000..25dbb0fac065 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/renesas,r9a06g032-sysctrl.yaml @@ -0,0 +1,62 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/renesas,r9a06g032-sysctrl.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Renesas RZ/N1D (R9A06G032) System Controller + +maintainers: + - Gareth Williams + - Geert Uytterhoeven + +properties: + compatible: + const: renesas,r9a06g032-sysctrl + + reg: + maxItems: 1 + + clocks: + minItems: 1 + items: + - description: External 40 MHz crystal + - description: Optional external 32.768 kHz crystal + - description: Optional external JTAG input + - description: Optional external RGMII_REFCLK + + clock-names: + minItems: 1 + items: + - const: mclk + - const: rtc + - const: jtag + - const: rgmii_ref_ext + + '#clock-cells': + const: 1 + + '#power-domain-cells': + const: 0 + +required: + - compatible + - reg + - clocks + - clock-names + - '#clock-cells' + - '#power-domain-cells' + +additionalProperties: false + +examples: + - | + sysctrl: system-controller@4000c000 { + compatible = "renesas,r9a06g032-sysctrl"; + reg = <0x4000c000 0x1000>; + clocks = <&ext_mclk>, <&ext_rtc_clk>, <&ext_jtag_clk>, + <&ext_rgmii_ref>; + clock-names = "mclk", "rtc", "jtag", "rgmii_ref_ext"; + #clock-cells = <1>; + #power-domain-cells = <0>; + }; -- cgit v1.2.3 From 2e64ad1ca775b06a5cf87d5b0b83a6e60ecbfb1c Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Tue, 4 May 2021 08:07:42 -0400 Subject: dt-bindings: add vendor prefix for Insignal Ltd Add vendor prefix for Insignal Ltd (http://www.insignal.co.kr). Signed-off-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20210504120742.12922-1-krzysztof.kozlowski@canonical.com Signed-off-by: Rob Herring --- Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index b868cefc7c55..92fa427d2a80 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -533,6 +533,8 @@ patternProperties: description: Innolux Corporation "^inside-secure,.*": description: INSIDE Secure + "^insignal,.*": + description: Insignal Ltd. "^inspur,.*": description: Inspur Corporation "^intel,.*": -- cgit v1.2.3 From d30e82a6461baf709f8d850ce58cdf71095e0c66 Mon Sep 17 00:00:00 2001 From: Corentin Labbe Date: Wed, 5 May 2021 20:28:15 +0000 Subject: dt-bindings: net: Convert mdio-gpio to yaml Converts net/mdio-gpio.txt to yaml Reviewed-by: Andrew Lunn Signed-off-by: Corentin Labbe Link: https://lore.kernel.org/r/20210505202815.2665920-1-clabbe@baylibre.com Signed-off-by: Rob Herring --- .../devicetree/bindings/net/mdio-gpio.txt | 27 ---------- .../devicetree/bindings/net/mdio-gpio.yaml | 58 ++++++++++++++++++++++ 2 files changed, 58 insertions(+), 27 deletions(-) delete mode 100644 Documentation/devicetree/bindings/net/mdio-gpio.txt create mode 100644 Documentation/devicetree/bindings/net/mdio-gpio.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/mdio-gpio.txt b/Documentation/devicetree/bindings/net/mdio-gpio.txt deleted file mode 100644 index 4d91a36c5cf5..000000000000 --- a/Documentation/devicetree/bindings/net/mdio-gpio.txt +++ /dev/null @@ -1,27 +0,0 @@ -MDIO on GPIOs - -Currently defined compatibles: -- virtual,gpio-mdio -- microchip,mdio-smi0 - -MDC and MDIO lines connected to GPIO controllers are listed in the -gpios property as described in section VIII.1 in the following order: - -MDC, MDIO. - -Note: Each gpio-mdio bus should have an alias correctly numbered in "aliases" -node. - -Example: - -aliases { - mdio-gpio0 = &mdio0; -}; - -mdio0: mdio { - compatible = "virtual,mdio-gpio"; - #address-cells = <1>; - #size-cells = <0>; - gpios = <&qe_pio_a 11 - &qe_pio_c 6>; -}; diff --git a/Documentation/devicetree/bindings/net/mdio-gpio.yaml b/Documentation/devicetree/bindings/net/mdio-gpio.yaml new file mode 100644 index 000000000000..7c15a508af5b --- /dev/null +++ b/Documentation/devicetree/bindings/net/mdio-gpio.yaml @@ -0,0 +1,58 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/mdio-gpio.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: MDIO on GPIOs + +maintainers: + - Andrew Lunn + - Heiner Kallweit + - Russell King + +allOf: + - $ref: "mdio.yaml#" + +properties: + compatible: + enum: + - virtual,mdio-gpio + - microchip,mdio-smi0 + + "#address-cells": + const: 1 + + "#size-cells": + const: 0 + + gpios: + minItems: 2 + maxItems: 3 + items: + - description: MDC + - description: MDIO + - description: MDO + +#Note: Each gpio-mdio bus should have an alias correctly numbered in "aliases" +#node. +additionalProperties: + type: object + +examples: + - | + aliases { + mdio-gpio0 = &mdio0; + }; + + mdio0: mdio { + compatible = "virtual,mdio-gpio"; + #address-cells = <1>; + #size-cells = <0>; + gpios = <&qe_pio_a 11>, + <&qe_pio_c 6>; + ethphy0: ethernet-phy@0 { + reg = <0>; + }; + }; +... -- cgit v1.2.3 From 8f711f68cffdacb86444cf1d86292a776bf17dc1 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Rafa=C5=82=20Mi=C5=82ecki?= Date: Sat, 24 Apr 2021 22:23:41 +0200 Subject: dt-bindings: clock: brcm, iproc-clocks: convert to the json-schema MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit This helps validating DTS files. Signed-off-by: Rafał Miłecki Reviewed-by: Rob Herring Signed-off-by: Florian Fainelli --- .../bindings/clock/brcm,iproc-clocks.txt | 313 ---------------- .../bindings/clock/brcm,iproc-clocks.yaml | 395 +++++++++++++++++++++ 2 files changed, 395 insertions(+), 313 deletions(-) delete mode 100644 Documentation/devicetree/bindings/clock/brcm,iproc-clocks.txt create mode 100644 Documentation/devicetree/bindings/clock/brcm,iproc-clocks.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/brcm,iproc-clocks.txt b/Documentation/devicetree/bindings/clock/brcm,iproc-clocks.txt deleted file mode 100644 index ab730ea0a560..000000000000 --- a/Documentation/devicetree/bindings/clock/brcm,iproc-clocks.txt +++ /dev/null @@ -1,313 +0,0 @@ -Broadcom iProc Family Clocks - -This binding uses the common clock binding: - Documentation/devicetree/bindings/clock/clock-bindings.txt - -The iProc clock controller manages clocks that are common to the iProc family. -An SoC from the iProc family may have several PPLs, e.g., ARMPLL, GENPLL, -LCPLL0, MIPIPLL, and etc., all derived from an onboard crystal. Each PLL -comprises of several leaf clocks - -Required properties for a PLL and its leaf clocks: - -- compatible: - Should have a value of the form "brcm,-". For example, GENPLL on -Cygnus has a compatible string of "brcm,cygnus-genpll" - -- #clock-cells: - Have a value of <1> since there are more than 1 leaf clock of a given PLL - -- reg: - Define the base and range of the I/O address space that contain the iProc -clock control registers required for the PLL - -- clocks: - The input parent clock phandle for the PLL. For most iProc PLLs, this is an -onboard crystal with a fixed rate - -- clock-output-names: - An ordered list of strings defining the names of the clocks - -Example: - - osc: oscillator { - #clock-cells = <0>; - compatible = "fixed-clock"; - clock-frequency = <25000000>; - }; - - genpll: genpll { - #clock-cells = <1>; - compatible = "brcm,cygnus-genpll"; - reg = <0x0301d000 0x2c>, <0x0301c020 0x4>; - clocks = <&osc>; - clock-output-names = "genpll", "axi21", "250mhz", "ihost_sys", - "enet_sw", "audio_125", "can"; - }; - -Required properties for ASIU clocks: - -ASIU clocks are a special case. These clocks are derived directly from the -reference clock of the onboard crystal - -- compatible: - Should have a value of the form "brcm,-asiu-clk". For example, ASIU -clocks for Cygnus have a compatible string of "brcm,cygnus-asiu-clk" - -- #clock-cells: - Have a value of <1> since there are more than 1 ASIU clocks - -- reg: - Define the base and range of the I/O address space that contain the iProc -clock control registers required for ASIU clocks - -- clocks: - The input parent clock phandle for the ASIU clock, i.e., the onboard -crystal - -- clock-output-names: - An ordered list of strings defining the names of the ASIU clocks - -Example: - - osc: oscillator { - #clock-cells = <0>; - compatible = "fixed-clock"; - clock-frequency = <25000000>; - }; - - asiu_clks: asiu_clks { - #clock-cells = <1>; - compatible = "brcm,cygnus-asiu-clk"; - reg = <0x0301d048 0xc>, <0x180aa024 0x4>; - clocks = <&osc>; - clock-output-names = "keypad", "adc/touch", "pwm"; - }; - -Cygnus ------- -PLL and leaf clock compatible strings for Cygnus are: - "brcm,cygnus-armpll" - "brcm,cygnus-genpll" - "brcm,cygnus-lcpll0" - "brcm,cygnus-mipipll" - "brcm,cygnus-asiu-clk" - "brcm,cygnus-audiopll" - -The following table defines the set of PLL/clock index and ID for Cygnus. -These clock IDs are defined in: - "include/dt-bindings/clock/bcm-cygnus.h" - - Clock Source (Parent) Index ID - --- ----- ----- --------- - crystal N/A N/A N/A - - armpll crystal N/A N/A - - keypad crystal (ASIU) 0 BCM_CYGNUS_ASIU_KEYPAD_CLK - adc/tsc crystal (ASIU) 1 BCM_CYGNUS_ASIU_ADC_CLK - pwm crystal (ASIU) 2 BCM_CYGNUS_ASIU_PWM_CLK - - genpll crystal 0 BCM_CYGNUS_GENPLL - axi21 genpll 1 BCM_CYGNUS_GENPLL_AXI21_CLK - 250mhz genpll 2 BCM_CYGNUS_GENPLL_250MHZ_CLK - ihost_sys genpll 3 BCM_CYGNUS_GENPLL_IHOST_SYS_CLK - enet_sw genpll 4 BCM_CYGNUS_GENPLL_ENET_SW_CLK - audio_125 genpll 5 BCM_CYGNUS_GENPLL_AUDIO_125_CLK - can genpll 6 BCM_CYGNUS_GENPLL_CAN_CLK - - lcpll0 crystal 0 BCM_CYGNUS_LCPLL0 - pcie_phy lcpll0 1 BCM_CYGNUS_LCPLL0_PCIE_PHY_REF_CLK - ddr_phy lcpll0 2 BCM_CYGNUS_LCPLL0_DDR_PHY_CLK - sdio lcpll0 3 BCM_CYGNUS_LCPLL0_SDIO_CLK - usb_phy lcpll0 4 BCM_CYGNUS_LCPLL0_USB_PHY_REF_CLK - smart_card lcpll0 5 BCM_CYGNUS_LCPLL0_SMART_CARD_CLK - ch5_unused lcpll0 6 BCM_CYGNUS_LCPLL0_CH5_UNUSED - - mipipll crystal 0 BCM_CYGNUS_MIPIPLL - ch0_unused mipipll 1 BCM_CYGNUS_MIPIPLL_CH0_UNUSED - ch1_lcd mipipll 2 BCM_CYGNUS_MIPIPLL_CH1_LCD - ch2_v3d mipipll 3 BCM_CYGNUS_MIPIPLL_CH2_V3D - ch3_unused mipipll 4 BCM_CYGNUS_MIPIPLL_CH3_UNUSED - ch4_unused mipipll 5 BCM_CYGNUS_MIPIPLL_CH4_UNUSED - ch5_unused mipipll 6 BCM_CYGNUS_MIPIPLL_CH5_UNUSED - - audiopll crystal 0 BCM_CYGNUS_AUDIOPLL - ch0_audio audiopll 1 BCM_CYGNUS_AUDIOPLL_CH0 - 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: - "brcm,nsp-armpll" - "brcm,nsp-genpll" - "brcm,nsp-lcpll0" - -The following table defines the set of PLL/clock index and ID for Northstar and -Northstar Plus. These clock IDs are defined in: - "include/dt-bindings/clock/bcm-nsp.h" - - Clock Source Index ID - --- ----- ----- --------- - crystal N/A N/A N/A - - armpll crystal N/A N/A - - genpll crystal 0 BCM_NSP_GENPLL - phy genpll 1 BCM_NSP_GENPLL_PHY_CLK - ethernetclk genpll 2 BCM_NSP_GENPLL_ENET_SW_CLK - usbclk genpll 3 BCM_NSP_GENPLL_USB_PHY_REF_CLK - iprocfast genpll 4 BCM_NSP_GENPLL_IPROCFAST_CLK - sata1 genpll 5 BCM_NSP_GENPLL_SATA1_CLK - sata2 genpll 6 BCM_NSP_GENPLL_SATA2_CLK - - lcpll0 crystal 0 BCM_NSP_LCPLL0 - pcie_phy lcpll0 1 BCM_NSP_LCPLL0_PCIE_PHY_REF_CLK - sdio lcpll0 2 BCM_NSP_LCPLL0_SDIO_CLK - ddr_phy lcpll0 3 BCM_NSP_LCPLL0_DDR_PHY_CLK - -Northstar 2 ------------ -PLL and leaf clock compatible strings for Northstar 2 are: - "brcm,ns2-genpll-scr" - "brcm,ns2-genpll-sw" - "brcm,ns2-lcpll-ddr" - "brcm,ns2-lcpll-ports" - -The following table defines the set of PLL/clock index and ID for Northstar 2. -These clock IDs are defined in: - "include/dt-bindings/clock/bcm-ns2.h" - - Clock Source Index ID - --- ----- ----- --------- - crystal N/A N/A N/A - - genpll_scr crystal 0 BCM_NS2_GENPLL_SCR - scr genpll_scr 1 BCM_NS2_GENPLL_SCR_SCR_CLK - fs genpll_scr 2 BCM_NS2_GENPLL_SCR_FS_CLK - audio_ref genpll_scr 3 BCM_NS2_GENPLL_SCR_AUDIO_CLK - ch3_unused genpll_scr 4 BCM_NS2_GENPLL_SCR_CH3_UNUSED - ch4_unused genpll_scr 5 BCM_NS2_GENPLL_SCR_CH4_UNUSED - ch5_unused genpll_scr 6 BCM_NS2_GENPLL_SCR_CH5_UNUSED - - genpll_sw crystal 0 BCM_NS2_GENPLL_SW - rpe genpll_sw 1 BCM_NS2_GENPLL_SW_RPE_CLK - 250 genpll_sw 2 BCM_NS2_GENPLL_SW_250_CLK - nic genpll_sw 3 BCM_NS2_GENPLL_SW_NIC_CLK - chimp genpll_sw 4 BCM_NS2_GENPLL_SW_CHIMP_CLK - port genpll_sw 5 BCM_NS2_GENPLL_SW_PORT_CLK - sdio genpll_sw 6 BCM_NS2_GENPLL_SW_SDIO_CLK - - lcpll_ddr crystal 0 BCM_NS2_LCPLL_DDR - pcie_sata_usb lcpll_ddr 1 BCM_NS2_LCPLL_DDR_PCIE_SATA_USB_CLK - ddr lcpll_ddr 2 BCM_NS2_LCPLL_DDR_DDR_CLK - ch2_unused lcpll_ddr 3 BCM_NS2_LCPLL_DDR_CH2_UNUSED - ch3_unused lcpll_ddr 4 BCM_NS2_LCPLL_DDR_CH3_UNUSED - ch4_unused lcpll_ddr 5 BCM_NS2_LCPLL_DDR_CH4_UNUSED - ch5_unused lcpll_ddr 6 BCM_NS2_LCPLL_DDR_CH5_UNUSED - - lcpll_ports crystal 0 BCM_NS2_LCPLL_PORTS - wan lcpll_ports 1 BCM_NS2_LCPLL_PORTS_WAN_CLK - rgmii lcpll_ports 2 BCM_NS2_LCPLL_PORTS_RGMII_CLK - ch2_unused lcpll_ports 3 BCM_NS2_LCPLL_PORTS_CH2_UNUSED - ch3_unused lcpll_ports 4 BCM_NS2_LCPLL_PORTS_CH3_UNUSED - ch4_unused lcpll_ports 5 BCM_NS2_LCPLL_PORTS_CH4_UNUSED - ch5_unused lcpll_ports 6 BCM_NS2_LCPLL_PORTS_CH5_UNUSED - -BCM63138 --------- -PLL and leaf clock compatible strings for BCM63138 are: - "brcm,bcm63138-armpll" - -Stingray ------------ -PLL and leaf clock compatible strings for Stingray are: - "brcm,sr-genpll0" - "brcm,sr-genpll1" - "brcm,sr-genpll2" - "brcm,sr-genpll3" - "brcm,sr-genpll4" - "brcm,sr-genpll5" - "brcm,sr-genpll6" - - "brcm,sr-lcpll0" - "brcm,sr-lcpll1" - "brcm,sr-lcpll-pcie" - - -The following table defines the set of PLL/clock index and ID for Stingray. -These clock IDs are defined in: - "include/dt-bindings/clock/bcm-sr.h" - - Clock Source Index ID - --- ----- ----- --------- - crystal N/A N/A N/A - crmu_ref25m crystal N/A N/A - - genpll0 crystal 0 BCM_SR_GENPLL0 - clk_125m genpll0 1 BCM_SR_GENPLL0_125M_CLK - clk_scr genpll0 2 BCM_SR_GENPLL0_SCR_CLK - clk_250 genpll0 3 BCM_SR_GENPLL0_250M_CLK - clk_pcie_axi genpll0 4 BCM_SR_GENPLL0_PCIE_AXI_CLK - clk_paxc_axi_x2 genpll0 5 BCM_SR_GENPLL0_PAXC_AXI_X2_CLK - clk_paxc_axi genpll0 6 BCM_SR_GENPLL0_PAXC_AXI_CLK - - genpll1 crystal 0 BCM_SR_GENPLL1 - clk_pcie_tl genpll1 1 BCM_SR_GENPLL1_PCIE_TL_CLK - clk_mhb_apb genpll1 2 BCM_SR_GENPLL1_MHB_APB_CLK - - genpll2 crystal 0 BCM_SR_GENPLL2 - clk_nic genpll2 1 BCM_SR_GENPLL2_NIC_CLK - clk_ts_500_ref genpll2 2 BCM_SR_GENPLL2_TS_500_REF_CLK - clk_125_nitro genpll2 3 BCM_SR_GENPLL2_125_NITRO_CLK - clk_chimp genpll2 4 BCM_SR_GENPLL2_CHIMP_CLK - clk_nic_flash genpll2 5 BCM_SR_GENPLL2_NIC_FLASH_CLK - clk_fs genpll2 6 BCM_SR_GENPLL2_FS_CLK - - genpll3 crystal 0 BCM_SR_GENPLL3 - clk_hsls genpll3 1 BCM_SR_GENPLL3_HSLS_CLK - clk_sdio genpll3 2 BCM_SR_GENPLL3_SDIO_CLK - - genpll4 crystal 0 BCM_SR_GENPLL4 - clk_ccn genpll4 1 BCM_SR_GENPLL4_CCN_CLK - clk_tpiu_pll genpll4 2 BCM_SR_GENPLL4_TPIU_PLL_CLK - clk_noc genpll4 3 BCM_SR_GENPLL4_NOC_CLK - clk_chclk_fs4 genpll4 4 BCM_SR_GENPLL4_CHCLK_FS4_CLK - clk_bridge_fscpu genpll4 5 BCM_SR_GENPLL4_BRIDGE_FSCPU_CLK - - genpll5 crystal 0 BCM_SR_GENPLL5 - clk_fs4_hf genpll5 1 BCM_SR_GENPLL5_FS4_HF_CLK - clk_crypto_ae genpll5 2 BCM_SR_GENPLL5_CRYPTO_AE_CLK - clk_raid_ae genpll5 3 BCM_SR_GENPLL5_RAID_AE_CLK - - genpll6 crystal 0 BCM_SR_GENPLL6 - clk_48_usb genpll6 1 BCM_SR_GENPLL6_48_USB_CLK - - lcpll0 crystal 0 BCM_SR_LCPLL0 - clk_sata_refp lcpll0 1 BCM_SR_LCPLL0_SATA_REFP_CLK - clk_sata_refn lcpll0 2 BCM_SR_LCPLL0_SATA_REFN_CLK - clk_sata_350 lcpll0 3 BCM_SR_LCPLL0_SATA_350_CLK - clk_sata_500 lcpll0 4 BCM_SR_LCPLL0_SATA_500_CLK - - lcpll1 crystal 0 BCM_SR_LCPLL1 - clk_wan lcpll1 1 BCM_SR_LCPLL1_WAN_CLK - clk_usb_ref lcpll1 2 BCM_SR_LCPLL1_USB_REF_CLK - clk_crmu_ts lcpll1 3 BCM_SR_LCPLL1_CRMU_TS_CLK - - lcpll_pcie crystal 0 BCM_SR_LCPLL_PCIE - clk_pcie_phy_ref lcpll1 1 BCM_SR_LCPLL_PCIE_PHY_REF_CLK diff --git a/Documentation/devicetree/bindings/clock/brcm,iproc-clocks.yaml b/Documentation/devicetree/bindings/clock/brcm,iproc-clocks.yaml new file mode 100644 index 000000000000..8dc7b404ee12 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/brcm,iproc-clocks.yaml @@ -0,0 +1,395 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/brcm,iproc-clocks.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Broadcom iProc Family Clocks + +maintainers: + - Ray Jui + - Scott Branden + +description: | + The iProc clock controller manages clocks that are common to the iProc family. + An SoC from the iProc family may have several PLLs, e.g., ARMPLL, GENPLL, + LCPLL0, MIPIPLL, and etc., all derived from an onboard crystal. Each PLL + comprises of several leaf clocks + + ASIU clocks are a special case. These clocks are derived directly from the + reference clock of the onboard crystal. + +properties: + compatible: + enum: + - brcm,bcm63138-armpll + - brcm,cygnus-armpll + - brcm,cygnus-genpll + - brcm,cygnus-lcpll0 + - brcm,cygnus-mipipll + - brcm,cygnus-asiu-clk + - brcm,cygnus-audiopll + - brcm,hr2-armpll + - brcm,nsp-armpll + - brcm,nsp-genpll + - brcm,nsp-lcpll0 + - brcm,ns2-genpll-scr + - brcm,ns2-genpll-sw + - brcm,ns2-lcpll-ddr + - brcm,ns2-lcpll-ports + - brcm,sr-genpll0 + - brcm,sr-genpll1 + - brcm,sr-genpll2 + - brcm,sr-genpll3 + - brcm,sr-genpll4 + - brcm,sr-genpll5 + - brcm,sr-genpll6 + - brcm,sr-lcpll0 + - brcm,sr-lcpll1 + - brcm,sr-lcpll-pcie + + reg: + minItems: 1 + maxItems: 3 + items: + - description: base register + - description: power register + - description: ASIU or split status register + + clocks: + description: The input parent clock phandle for the PLL / ASIU clock. For + most iProc PLLs, this is an onboard crystal with a fixed rate. + maxItems: 1 + + '#clock-cells': + const: 1 + + clock-output-names: + minItems: 1 + maxItems: 45 + +allOf: + - if: + properties: + compatible: + contains: + enum: + - brcm,cygnus-armpll + - brcm,cygnus-genpll + - brcm,cygnus-lcpll0 + - brcm,cygnus-mipipll + - brcm,cygnus-asiu-clk + - brcm,cygnus-audiopll + then: + properties: + clock-output-names: + description: | + The following table defines the set of PLL/clock index and ID for Cygnus. + These clock IDs are defined in: + "include/dt-bindings/clock/bcm-cygnus.h" + + Clock Source (Parent) Index ID + ----- --------------- ----- -- + crystal N/A N/A N/A + + armpll crystal N/A N/A + + keypad crystal (ASIU) 0 BCM_CYGNUS_ASIU_KEYPAD_CLK + adc/tsc crystal (ASIU) 1 BCM_CYGNUS_ASIU_ADC_CLK + pwm crystal (ASIU) 2 BCM_CYGNUS_ASIU_PWM_CLK + + genpll crystal 0 BCM_CYGNUS_GENPLL + axi21 genpll 1 BCM_CYGNUS_GENPLL_AXI21_CLK + 250mhz genpll 2 BCM_CYGNUS_GENPLL_250MHZ_CLK + ihost_sys genpll 3 BCM_CYGNUS_GENPLL_IHOST_SYS_CLK + enet_sw genpll 4 BCM_CYGNUS_GENPLL_ENET_SW_CLK + audio_125 genpll 5 BCM_CYGNUS_GENPLL_AUDIO_125_CLK + can genpll 6 BCM_CYGNUS_GENPLL_CAN_CLK + + lcpll0 crystal 0 BCM_CYGNUS_LCPLL0 + pcie_phy lcpll0 1 BCM_CYGNUS_LCPLL0_PCIE_PHY_REF_CLK + ddr_phy lcpll0 2 BCM_CYGNUS_LCPLL0_DDR_PHY_CLK + sdio lcpll0 3 BCM_CYGNUS_LCPLL0_SDIO_CLK + usb_phy lcpll0 4 BCM_CYGNUS_LCPLL0_USB_PHY_REF_CLK + smart_card lcpll0 5 BCM_CYGNUS_LCPLL0_SMART_CARD_CLK + ch5_unused lcpll0 6 BCM_CYGNUS_LCPLL0_CH5_UNUSED + + mipipll crystal 0 BCM_CYGNUS_MIPIPLL + ch0_unused mipipll 1 BCM_CYGNUS_MIPIPLL_CH0_UNUSED + ch1_lcd mipipll 2 BCM_CYGNUS_MIPIPLL_CH1_LCD + ch2_v3d mipipll 3 BCM_CYGNUS_MIPIPLL_CH2_V3D + ch3_unused mipipll 4 BCM_CYGNUS_MIPIPLL_CH3_UNUSED + ch4_unused mipipll 5 BCM_CYGNUS_MIPIPLL_CH4_UNUSED + ch5_unused mipipll 6 BCM_CYGNUS_MIPIPLL_CH5_UNUSED + + audiopll crystal 0 BCM_CYGNUS_AUDIOPLL + ch0_audio audiopll 1 BCM_CYGNUS_AUDIOPLL_CH0 + ch1_audio audiopll 2 BCM_CYGNUS_AUDIOPLL_CH1 + ch2_audio audiopll 3 BCM_CYGNUS_AUDIOPLL_CH2 + - if: + properties: + compatible: + contains: + enum: + - brcm,hr2-armpll + then: + properties: + clock-output-names: + description: | + 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 + - if: + properties: + compatible: + contains: + enum: + - brcm,nsp-armpll + - brcm,nsp-genpll + - brcm,nsp-lcpll0 + then: + properties: + clock-output-names: + description: | + The following table defines the set of PLL/clock index and ID for Northstar and + Northstar Plus. These clock IDs are defined in: + "include/dt-bindings/clock/bcm-nsp.h" + + Clock Source Index ID + ----- ------ ----- -- + crystal N/A N/A N/A + + armpll crystal N/A N/A + + genpll crystal 0 BCM_NSP_GENPLL + phy genpll 1 BCM_NSP_GENPLL_PHY_CLK + ethernetclk genpll 2 BCM_NSP_GENPLL_ENET_SW_CLK + usbclk genpll 3 BCM_NSP_GENPLL_USB_PHY_REF_CLK + iprocfast genpll 4 BCM_NSP_GENPLL_IPROCFAST_CLK + sata1 genpll 5 BCM_NSP_GENPLL_SATA1_CLK + sata2 genpll 6 BCM_NSP_GENPLL_SATA2_CLK + + lcpll0 crystal 0 BCM_NSP_LCPLL0 + pcie_phy lcpll0 1 BCM_NSP_LCPLL0_PCIE_PHY_REF_CLK + sdio lcpll0 2 BCM_NSP_LCPLL0_SDIO_CLK + ddr_phy lcpll0 3 BCM_NSP_LCPLL0_DDR_PHY_CLK + - if: + properties: + compatible: + contains: + enum: + - brcm,ns2-genpll-scr + - brcm,ns2-genpll-sw + - brcm,ns2-lcpll-ddr + - brcm,ns2-lcpll-ports + then: + properties: + clock-output-names: + description: | + The following table defines the set of PLL/clock index and ID for Northstar 2. + These clock IDs are defined in: + "include/dt-bindings/clock/bcm-ns2.h" + + Clock Source Index ID + ----- ------ ----- -- + crystal N/A N/A N/A + + genpll_scr crystal 0 BCM_NS2_GENPLL_SCR + scr genpll_scr 1 BCM_NS2_GENPLL_SCR_SCR_CLK + fs genpll_scr 2 BCM_NS2_GENPLL_SCR_FS_CLK + audio_ref genpll_scr 3 BCM_NS2_GENPLL_SCR_AUDIO_CLK + ch3_unused genpll_scr 4 BCM_NS2_GENPLL_SCR_CH3_UNUSED + ch4_unused genpll_scr 5 BCM_NS2_GENPLL_SCR_CH4_UNUSED + ch5_unused genpll_scr 6 BCM_NS2_GENPLL_SCR_CH5_UNUSED + + genpll_sw crystal 0 BCM_NS2_GENPLL_SW + rpe genpll_sw 1 BCM_NS2_GENPLL_SW_RPE_CLK + 250 genpll_sw 2 BCM_NS2_GENPLL_SW_250_CLK + nic genpll_sw 3 BCM_NS2_GENPLL_SW_NIC_CLK + chimp genpll_sw 4 BCM_NS2_GENPLL_SW_CHIMP_CLK + port genpll_sw 5 BCM_NS2_GENPLL_SW_PORT_CLK + sdio genpll_sw 6 BCM_NS2_GENPLL_SW_SDIO_CLK + + lcpll_ddr crystal 0 BCM_NS2_LCPLL_DDR + pcie_sata_usb lcpll_ddr 1 BCM_NS2_LCPLL_DDR_PCIE_SATA_USB_CLK + ddr lcpll_ddr 2 BCM_NS2_LCPLL_DDR_DDR_CLK + ch2_unused lcpll_ddr 3 BCM_NS2_LCPLL_DDR_CH2_UNUSED + ch3_unused lcpll_ddr 4 BCM_NS2_LCPLL_DDR_CH3_UNUSED + ch4_unused lcpll_ddr 5 BCM_NS2_LCPLL_DDR_CH4_UNUSED + ch5_unused lcpll_ddr 6 BCM_NS2_LCPLL_DDR_CH5_UNUSED + + lcpll_ports crystal 0 BCM_NS2_LCPLL_PORTS + wan lcpll_ports 1 BCM_NS2_LCPLL_PORTS_WAN_CLK + rgmii lcpll_ports 2 BCM_NS2_LCPLL_PORTS_RGMII_CLK + ch2_unused lcpll_ports 3 BCM_NS2_LCPLL_PORTS_CH2_UNUSED + ch3_unused lcpll_ports 4 BCM_NS2_LCPLL_PORTS_CH3_UNUSED + ch4_unused lcpll_ports 5 BCM_NS2_LCPLL_PORTS_CH4_UNUSED + ch5_unused lcpll_ports 6 BCM_NS2_LCPLL_PORTS_CH5_UNUSED + - if: + properties: + compatible: + contains: + enum: + - brcm,sr-genpll0 + - brcm,sr-genpll1 + - brcm,sr-genpll2 + - brcm,sr-genpll3 + - brcm,sr-genpll4 + - brcm,sr-genpll5 + - brcm,sr-genpll6 + - brcm,sr-lcpll0 + - brcm,sr-lcpll1 + - brcm,sr-lcpll-pcie + then: + properties: + clock-output-names: + description: | + The following table defines the set of PLL/clock index and ID for Stingray. + These clock IDs are defined in: + "include/dt-bindings/clock/bcm-sr.h" + + Clock Source Index ID + ----- ------ ----- -- + crystal N/A N/A N/A + crmu_ref25m crystal N/A N/A + + genpll0 crystal 0 BCM_SR_GENPLL0 + clk_125m genpll0 1 BCM_SR_GENPLL0_125M_CLK + clk_scr genpll0 2 BCM_SR_GENPLL0_SCR_CLK + clk_250 genpll0 3 BCM_SR_GENPLL0_250M_CLK + clk_pcie_axi genpll0 4 BCM_SR_GENPLL0_PCIE_AXI_CLK + clk_paxc_axi_x2 genpll0 5 BCM_SR_GENPLL0_PAXC_AXI_X2_CLK + clk_paxc_axi genpll0 6 BCM_SR_GENPLL0_PAXC_AXI_CLK + + genpll1 crystal 0 BCM_SR_GENPLL1 + clk_pcie_tl genpll1 1 BCM_SR_GENPLL1_PCIE_TL_CLK + clk_mhb_apb genpll1 2 BCM_SR_GENPLL1_MHB_APB_CLK + + genpll2 crystal 0 BCM_SR_GENPLL2 + clk_nic genpll2 1 BCM_SR_GENPLL2_NIC_CLK + clk_ts_500_ref genpll2 2 BCM_SR_GENPLL2_TS_500_REF_CLK + clk_125_nitro genpll2 3 BCM_SR_GENPLL2_125_NITRO_CLK + clk_chimp genpll2 4 BCM_SR_GENPLL2_CHIMP_CLK + clk_nic_flash genpll2 5 BCM_SR_GENPLL2_NIC_FLASH_CLK + clk_fs genpll2 6 BCM_SR_GENPLL2_FS_CLK + + genpll3 crystal 0 BCM_SR_GENPLL3 + clk_hsls genpll3 1 BCM_SR_GENPLL3_HSLS_CLK + clk_sdio genpll3 2 BCM_SR_GENPLL3_SDIO_CLK + + genpll4 crystal 0 BCM_SR_GENPLL4 + clk_ccn genpll4 1 BCM_SR_GENPLL4_CCN_CLK + clk_tpiu_pll genpll4 2 BCM_SR_GENPLL4_TPIU_PLL_CLK + clk_noc genpll4 3 BCM_SR_GENPLL4_NOC_CLK + clk_chclk_fs4 genpll4 4 BCM_SR_GENPLL4_CHCLK_FS4_CLK + clk_bridge_fscpu genpll4 5 BCM_SR_GENPLL4_BRIDGE_FSCPU_CLK + + genpll5 crystal 0 BCM_SR_GENPLL5 + clk_fs4_hf genpll5 1 BCM_SR_GENPLL5_FS4_HF_CLK + clk_crypto_ae genpll5 2 BCM_SR_GENPLL5_CRYPTO_AE_CLK + clk_raid_ae genpll5 3 BCM_SR_GENPLL5_RAID_AE_CLK + + genpll6 crystal 0 BCM_SR_GENPLL6 + clk_48_usb genpll6 1 BCM_SR_GENPLL6_48_USB_CLK + + lcpll0 crystal 0 BCM_SR_LCPLL0 + clk_sata_refp lcpll0 1 BCM_SR_LCPLL0_SATA_REFP_CLK + clk_sata_refn lcpll0 2 BCM_SR_LCPLL0_SATA_REFN_CLK + clk_sata_350 lcpll0 3 BCM_SR_LCPLL0_SATA_350_CLK + clk_sata_500 lcpll0 4 BCM_SR_LCPLL0_SATA_500_CLK + + lcpll1 crystal 0 BCM_SR_LCPLL1 + clk_wan lcpll1 1 BCM_SR_LCPLL1_WAN_CLK + clk_usb_ref lcpll1 2 BCM_SR_LCPLL1_USB_REF_CLK + clk_crmu_ts lcpll1 3 BCM_SR_LCPLL1_CRMU_TS_CLK + + lcpll_pcie crystal 0 BCM_SR_LCPLL_PCIE + clk_pcie_phy_ref lcpll1 1 BCM_SR_LCPLL_PCIE_PHY_REF_CLK + - if: + properties: + compatible: + contains: + const: brcm,cygnus-genpll + then: + properties: + clock-output-names: + items: + - const: genpll + - const: axi21 + - const: 250mhz + - const: ihost_sys + - const: enet_sw + - const: audio_125 + - const: can + - if: + properties: + compatible: + contains: + const: brcm,nsp-lcpll0 + then: + properties: + clock-output-names: + items: + - const: lcpll0 + - const: pcie_phy + - const: sdio + - const: ddr_phy + - if: + properties: + compatible: + contains: + const: brcm,nsp-genpll + then: + properties: + clock-output-names: + items: + - const: genpll + - const: phy + - const: ethernetclk + - const: usbclk + - const: iprocfast + - const: sata1 + - const: sata2 + +required: + - reg + - clocks + - '#clock-cells' + - clock-output-names + +additionalProperties: false + +examples: + - | + osc1: oscillator { + #clock-cells = <0>; + compatible = "fixed-clock"; + clock-frequency = <25000000>; + }; + + genpll@301d000 { + #clock-cells = <1>; + compatible = "brcm,cygnus-genpll"; + reg = <0x301d000 0x2c>, <0x301c020 0x4>; + clocks = <&os1c>; + clock-output-names = "genpll", "axi21", "250mhz", "ihost_sys", + "enet_sw", "audio_125", "can"; + }; + - | + osc2: oscillator { + #clock-cells = <0>; + compatible = "fixed-clock"; + clock-frequency = <25000000>; + }; + + asiu_clks@301d048 { + #clock-cells = <1>; + compatible = "brcm,cygnus-asiu-clk"; + reg = <0x301d048 0xc>, <0x180aa024 0x4>; + clocks = <&osc2>; + clock-output-names = "keypad", "adc/touch", "pwm"; + }; -- cgit v1.2.3 From b18def121f077857ccf92fc620366e19850bc297 Mon Sep 17 00:00:00 2001 From: Yury Norov Date: Tue, 20 Apr 2021 20:13:25 -0700 Subject: bitmap_parse: Support 'all' semantics RCU code supports an 'all' group as a special case when parsing rcu_nocbs parameter. This patch moves the 'all' support to the core bitmap_parse code, so that all bitmap users can enjoy this extension. Moving 'all' parsing to a bitmap_parse level also allows users to pass patterns together with 'all' in regular group:pattern format, for example, "rcu_nocbs=all:1/2" would offload all the even-numbered CPUs regardless of the number of CPUs on the system. Reviewed-by: Andy Shevchenko Signed-off-by: Yury Norov Signed-off-by: Paul E. McKenney --- Documentation/admin-guide/kernel-parameters.rst | 5 +++++ 1 file changed, 5 insertions(+) (limited to 'Documentation') diff --git a/Documentation/admin-guide/kernel-parameters.rst b/Documentation/admin-guide/kernel-parameters.rst index 3996b54158bf..01ba293a2d70 100644 --- a/Documentation/admin-guide/kernel-parameters.rst +++ b/Documentation/admin-guide/kernel-parameters.rst @@ -76,6 +76,11 @@ to change, such as less cores in the CPU list, then N and any ranges using N will also change. Use the same on a small 4 core system, and "16-N" becomes "16-3" and now the same boot input will be flagged as invalid (start > end). +The special case-tolerant group name "all" has a meaning of selecting all CPUs, +so that "nohz_full=all" is the equivalent of "nohz_full=0-N". + +The semantics of "N" and "all" is supported on a level of bitmaps and holds for +all users of bitmap_parse(). 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 -- cgit v1.2.3 From 18389c4570211e10e94f4a2ce907d01397abc335 Mon Sep 17 00:00:00 2001 From: "Paul E. McKenney" Date: Fri, 19 Mar 2021 16:30:15 -0700 Subject: doc: Fix statement of RCU's memory-ordering requirements The sentence defining the relationship of accesses before a grace period to read-side accesses following that same grace period was missing a small word: "not". This commit therefore adds it. Reported-by: Frederic Weisbecker Signed-off-by: Paul E. McKenney --- Documentation/RCU/Design/Memory-Ordering/Tree-RCU-Memory-Ordering.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/RCU/Design/Memory-Ordering/Tree-RCU-Memory-Ordering.rst b/Documentation/RCU/Design/Memory-Ordering/Tree-RCU-Memory-Ordering.rst index a648b423ba0e..3f6ce41ee0c5 100644 --- a/Documentation/RCU/Design/Memory-Ordering/Tree-RCU-Memory-Ordering.rst +++ b/Documentation/RCU/Design/Memory-Ordering/Tree-RCU-Memory-Ordering.rst @@ -21,7 +21,7 @@ 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 +period is guaranteed to not see the effects of all accesses following the end of that grace period that are within RCU read-side critical sections. Note well that RCU-sched read-side critical sections include any region -- cgit v1.2.3 From 58d0db869d7ab8ca97b521f167022caa2c42cbe7 Mon Sep 17 00:00:00 2001 From: Frederic Weisbecker Date: Sun, 4 Apr 2021 23:58:43 +0200 Subject: doc: Fix diagram references in memory-ordering document The three diagrams describing rcu_gp_init() all spuriously refer to the same figure, probably due to a copy/paste issue. This commit fixes these references. Signed-off-by: Frederic Weisbecker Signed-off-by: Paul E. McKenney --- Documentation/RCU/Design/Memory-Ordering/Tree-RCU-Memory-Ordering.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/RCU/Design/Memory-Ordering/Tree-RCU-Memory-Ordering.rst b/Documentation/RCU/Design/Memory-Ordering/Tree-RCU-Memory-Ordering.rst index 3f6ce41ee0c5..11cdab037bff 100644 --- a/Documentation/RCU/Design/Memory-Ordering/Tree-RCU-Memory-Ordering.rst +++ b/Documentation/RCU/Design/Memory-Ordering/Tree-RCU-Memory-Ordering.rst @@ -339,14 +339,14 @@ The diagram below shows the path of ordering if the leftmost leftmost ``rcu_node`` structure offlines its last CPU and if the next ``rcu_node`` structure has no online CPUs). -.. kernel-figure:: TreeRCU-gp-init-1.svg +.. kernel-figure:: TreeRCU-gp-init-2.svg The final ``rcu_gp_init()`` pass through the ``rcu_node`` tree traverses breadth-first, setting each ``rcu_node`` structure's ``->gp_seq`` field to the newly advanced value from the ``rcu_state`` structure, as shown in the following diagram. -.. kernel-figure:: TreeRCU-gp-init-1.svg +.. kernel-figure:: TreeRCU-gp-init-3.svg This change will also cause each CPU's next call to ``__note_gp_changes()`` to notice that a new grace period has started, -- cgit v1.2.3 From d0bfa8b3c411e25e014e4131d2804afe29c440a6 Mon Sep 17 00:00:00 2001 From: Zhang Qiang Date: Thu, 15 Apr 2021 19:19:56 +0200 Subject: kvfree_rcu: Release a page cache under memory pressure Add a drain_page_cache() function to drain a per-cpu page cache. The reason behind of it is a system can run into a low memory condition, in that case a page shrinker can ask for its users to free their caches in order to get extra memory available for other needs in a system. When a system hits such condition, a page cache is drained for all CPUs in a system. By default a page cache work is delayed with 5 seconds interval until a memory pressure disappears, if needed it can be changed. See a rcu_delay_page_cache_fill_msec module parameter. Co-developed-by: Uladzislau Rezki (Sony) Signed-off-by: Uladzislau Rezki (Sony) Signed-off-by: Zqiang Signed-off-by: Paul E. McKenney --- Documentation/admin-guide/kernel-parameters.txt | 5 +++++ 1 file changed, 5 insertions(+) (limited to 'Documentation') diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index cb89dbdedc46..4405fd32e8ab 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -4290,6 +4290,11 @@ whole algorithm to behave better in low memory condition. + rcutree.rcu_delay_page_cache_fill_msec= [KNL] + Set the page-cache refill delay (in milliseconds) + in response to low-memory conditions. The range + of permitted values is in the range 0:100000. + rcutree.jiffies_till_first_fqs= [KNL] Set delay from grace-period initialization to first attempt to force quiescent states. -- cgit v1.2.3 From 0626e6641f6b467447c81dd7678a69c66f7746cf Mon Sep 17 00:00:00 2001 From: Namjae Jeon Date: Tue, 16 Mar 2021 13:07:11 +0900 Subject: cifsd: add server handler for central processing and tranport layers This adds server handler for central processing, transport layers(tcp, rdma, ipc) and a document describing cifsd architecture. Signed-off-by: Namjae Jeon Signed-off-by: Sergey Senozhatsky Signed-off-by: Hyunchul Lee Acked-by: Ronnie Sahlberg Signed-off-by: Steve French --- Documentation/filesystems/cifs/cifsd.rst | 136 +++++++++++++++++++++++++++++++ 1 file changed, 136 insertions(+) create mode 100644 Documentation/filesystems/cifs/cifsd.rst (limited to 'Documentation') diff --git a/Documentation/filesystems/cifs/cifsd.rst b/Documentation/filesystems/cifs/cifsd.rst new file mode 100644 index 000000000000..e0c33d03f290 --- /dev/null +++ b/Documentation/filesystems/cifs/cifsd.rst @@ -0,0 +1,136 @@ +.. SPDX-License-Identifier: GPL-2.0 + +========================= +CIFSD - SMB3 Kernel Server +========================= + +CIFSD is a linux kernel server which implements SMB3 protocol in kernel space +for sharing files over network. + +CIFSD architecture +================== + +The subset of performance related operations belong in kernelspace and +the other subset which belong to operations which are not really related with +performance in userspace. So, DCE/RPC management that has historically resulted +into number of buffer overflow issues and dangerous security bugs and user +account management are implemented in user space as ksmbd.mountd. +File operations that are related with performance (open/read/write/close etc.) +in kernel space (ksmbd). This also allows for easier integration with VFS +interface for all file operations. + +ksmbd (kernel daemon) +--------------------- + +When the server daemon is started, It starts up a forker thread +(ksmbd/interface name) at initialization time and open a dedicated port 445 +for listening to SMB requests. Whenever new clients make request, Forker +thread will accept the client connection and fork a new thread for dedicated +communication channel between the client and the server. It allows for parallel +processing of SMB requests(commands) from clients as well as allowing for new +clients to make new connections. Each instance is named ksmbd/1~n(port number) +to indicate connected clients. Depending on the SMB request types, each new +thread can decide to pass through the commands to the user space (ksmbd.mountd), +currently DCE/RPC commands are identified to be handled through the user space. +To further utilize the linux kernel, it has been chosen to process the commands +as workitems and to be executed in the handlers of the ksmbd-io kworker threads. +It allows for multiplexing of the handlers as the kernel take care of initiating +extra worker threads if the load is increased and vice versa, if the load is +decreased it destroys the extra worker threads. So, after connection is +established with client. Dedicated ksmbd/1..n(port number) takes complete +ownership of receiving/parsing of SMB commands. Each received command is worked +in parallel i.e., There can be multiple clients commands which are worked in +parallel. After receiving each command a separated kernel workitem is prepared +for each command which is further queued to be handled by ksmbd-io kworkers. +So, each SMB workitem is queued to the kworkers. This allows the benefit of load +sharing to be managed optimally by the default kernel and optimizing client +performance by handling client commands in parallel. + +ksmbd.mountd (user space daemon) +-------------------------------- + +ksmbd.mountd is userspace process to, transfer user account and password that +are registered using ksmbd.adduser(part of utils for user space). Further it +allows sharing information parameters that parsed from smb.conf to ksmbd in +kernel. For the execution part it has a daemon which is continuously running +and connected to the kernel interface using netlink socket, it waits for the +requests(dcerpc and share/user info). It handles RPC calls (at a minimum few +dozen) that are most important for file server from NetShareEnum and +NetServerGetInfo. Complete DCE/RPC response is prepared from the user space +and passed over to the associated kernel thread for the client. + +Key Features +============ + +The supported features are: + * SMB3 protocols for basic file sharing + * Auto negotiation + * Compound requests + * Oplock/Lease + * Large MTU + * NTLM/NTLMv2 + * HMAC-SHA256 Signing + * Secure negotiate + * Signing Update + * Pre-authentication integrity(SMB 3.1.1) + * SMB3 encryption(CCM, GCM) + * SMB direct(RDMA) + * SMB3.1.1 POSIX extension support + * ACLs + * Kerberos + +The features that are planned or not supported: + * SMB3 Multi-channel + * Durable handle v1,v2 + * Persistent handles + * Directory lease + * SMB2 notify + +How to run +========== + +1. Download ksmbd-tools and compile them. + - https://github.com/cifsd-team/ksmbd-tools + +2. Create user/password for SMB share. + + # mkdir /etc/ksmbd/ + # ksmbd.adduser -a + +3. Create /etc/ksmbd/smb.conf file, add SMB share in smb.conf file + - Refer smb.conf.example and Documentation/configuration.txt + in ksmbd-tools + +4. Insert ksmbd.ko module + + # insmod ksmbd.ko + +5. Start ksmbd user space daemon + # ksmbd.mountd + +6. Access share from Windows or Linux using CIFS + +Shutdown CIFSD +============== + +1. kill user and kernel space daemon + # sudo ksmbd.control -s + +How to turn debug print on +========================== + +Each layer +/sys/class/ksmbd-control/debug + +1. Enable all component prints + # sudo ksmbd.control -d "all" + +2. Enable one of components(smb, auth, vfs, oplock, ipc, conn, rdma) + # sudo ksmbd.control -d "smb" + +3. Show what prints are enable. + # cat/sys/class/ksmbd-control/debug + [smb] auth vfs oplock ipc conn [rdma] + +4. Disable prints: + If you try the selected component once more, It is disabled without brackets. -- cgit v1.2.3 From c0e8110e6c75758c4567f8e713f26e5dbd88cc7c Mon Sep 17 00:00:00 2001 From: Namjae Jeon Date: Wed, 17 Mar 2021 16:52:17 +0900 Subject: cifsd: fix WARNING: Title overline too short Stephen reported a warning message from cifsd.rst file. Documentation/filesystems/cifs/cifsd.rst:3: WARNING: Title overline too short. Reported-by: Stephen Rothwell Signed-off-by: Namjae Jeon Signed-off-by: Steve French --- Documentation/filesystems/cifs/cifsd.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/filesystems/cifs/cifsd.rst b/Documentation/filesystems/cifs/cifsd.rst index e0c33d03f290..af3589da6923 100644 --- a/Documentation/filesystems/cifs/cifsd.rst +++ b/Documentation/filesystems/cifs/cifsd.rst @@ -1,8 +1,8 @@ .. SPDX-License-Identifier: GPL-2.0 -========================= +========================== CIFSD - SMB3 Kernel Server -========================= +========================== CIFSD is a linux kernel server which implements SMB3 protocol in kernel space for sharing files over network. -- cgit v1.2.3 From 42da4086b987fbb35562e93e534e57ad3f81f855 Mon Sep 17 00:00:00 2001 From: Namjae Jeon Date: Wed, 17 Mar 2021 16:55:28 +0900 Subject: cifsd: fix WARNING: document isn't included in any toctree Stephen reported a warning message from cifsd.rst file. Documentation/filesystems/cifs/cifsd.rst: WARNING: document isn't included in any toctree Reported-by: Stephen Rothwell Signed-off-by: Namjae Jeon Signed-off-by: Steve French --- Documentation/filesystems/index.rst | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/filesystems/index.rst b/Documentation/filesystems/index.rst index d4853cb919d2..ac9396f2bb8a 100644 --- a/Documentation/filesystems/index.rst +++ b/Documentation/filesystems/index.rst @@ -72,6 +72,7 @@ Documentation for filesystem implementations. befs bfs btrfs + cifs/cifsd cifs/cifsroot ceph coda -- cgit v1.2.3 From 04bee6e336be1accb7f28d8e86454f42b58a860f Mon Sep 17 00:00:00 2001 From: Namjae Jeon Date: Sat, 20 Mar 2021 16:06:59 +0900 Subject: cifsd: update cifsd.rst document Add work flow of cifsd and feature stats table. Signed-off-by: Namjae Jeon Signed-off-by: Steve French --- Documentation/filesystems/cifs/cifsd.rst | 96 +++++++++++++++++++++++--------- 1 file changed, 70 insertions(+), 26 deletions(-) (limited to 'Documentation') diff --git a/Documentation/filesystems/cifs/cifsd.rst b/Documentation/filesystems/cifs/cifsd.rst index af3589da6923..7eac7e459c2d 100644 --- a/Documentation/filesystems/cifs/cifsd.rst +++ b/Documentation/filesystems/cifs/cifsd.rst @@ -10,6 +10,34 @@ for sharing files over network. CIFSD architecture ================== + |--- ... + --------|--- ksmbd/3 - Client 3 + |-------|--- ksmbd/2 - Client 2 + | | ____________________________________________________ + | | |- Client 1 | +<--- Socket ---|--- ksmbd/1 <<= Authentication : NTLM/NTLM2, Kerberos | + | | | | <<= SMB engine : SMB2, SMB2.1, SMB3, SMB3.0.2, | + | | | | SMB3.1.1 | + | | | |____________________________________________________| + | | | + | | |--- VFS --- Local Filesystem + | | +KERNEL |--- ksmbd/0(forker kthread) +---------------||--------------------------------------------------------------- +USER || + || communication using NETLINK + || ______________________________________________ + || | | + ksmbd.mountd <<= DCE/RPC(srvsvc, wkssvc, smar, lsarpc) | + ^ | <<= configure shares setting, user accounts | + | |______________________________________________| + | + |------ smb.conf(config file) + | + |------ ksmbdpwd.db(user account/password file) + ^ + ksmbd.adduser ---------------| + The subset of performance related operations belong in kernelspace and the other subset which belong to operations which are not really related with performance in userspace. So, DCE/RPC management that has historically resulted @@ -59,32 +87,48 @@ dozen) that are most important for file server from NetShareEnum and NetServerGetInfo. Complete DCE/RPC response is prepared from the user space and passed over to the associated kernel thread for the client. -Key Features -============ - -The supported features are: - * SMB3 protocols for basic file sharing - * Auto negotiation - * Compound requests - * Oplock/Lease - * Large MTU - * NTLM/NTLMv2 - * HMAC-SHA256 Signing - * Secure negotiate - * Signing Update - * Pre-authentication integrity(SMB 3.1.1) - * SMB3 encryption(CCM, GCM) - * SMB direct(RDMA) - * SMB3.1.1 POSIX extension support - * ACLs - * Kerberos - -The features that are planned or not supported: - * SMB3 Multi-channel - * Durable handle v1,v2 - * Persistent handles - * Directory lease - * SMB2 notify + +CIFSD Feature Status +==================== + +============================== ================================================= +Feature name Status +============================== ================================================= +Dialects Supported. SMB2.1 SMB3.0, SMB3.1.1 dialects + excluding security vulnerable SMB1. +Auto Negotiation Supported. +Compound Request Supported. +Oplock Cache Mechanism Supported. +SMB2 leases(v1 lease) Supported. +Directory leases(v2 lease) Planned for future. +Multi-credits Supported. +NTLM/NTLMv2 Supported. +HMAC-SHA256 Signing Supported. +Secure negotiate Supported. +Signing Update Supported. +Pre-authentication integrity Supported. +SMB3 encryption(CCM, GCM) Supported. +SMB direct(RDMA) Partial Supported. SMB3 Multi-channel is required + to connect to Windows client. +SMB3 Multi-channel In Progress. +SMB3.1.1 POSIX extension Supported. +ACLs Partial Supported. only DACLs available, SACLs is + planned for future. ksmbd generate random subauth + values(then store it to disk) and use uid/gid + get from inode as RID for local domain SID. + The current acl implementation is limited to + standalone server, not a domain member. +Kerberos Supported. +Durable handle v1,v2 Planned for future. +Persistent handle Planned for future. +SMB2 notify Planned for future. +Sparse file support Supported. +DCE/RPC support Partial Supported. a few calls(NetShareEnumAll, + NetServerGetInfo, SAMR, LSARPC) that needed as + file server via netlink interface from + ksmbd.mountd. +============================== ================================================= + How to run ========== -- cgit v1.2.3 From 04165366515a2ba36c78540da776d3a12164f824 Mon Sep 17 00:00:00 2001 From: Namjae Jeon Date: Sat, 20 Mar 2021 16:19:01 +0900 Subject: cifsd: add index.rst in cifs documentation Since more than one file is in the cifs document directory, This patch add an index.rst. Signed-off-by: Namjae Jeon Signed-off-by: Steve French --- Documentation/filesystems/cifs/index.rst | 10 ++++++++++ Documentation/filesystems/index.rst | 3 +-- 2 files changed, 11 insertions(+), 2 deletions(-) create mode 100644 Documentation/filesystems/cifs/index.rst (limited to 'Documentation') diff --git a/Documentation/filesystems/cifs/index.rst b/Documentation/filesystems/cifs/index.rst new file mode 100644 index 000000000000..e762586b5dc7 --- /dev/null +++ b/Documentation/filesystems/cifs/index.rst @@ -0,0 +1,10 @@ +=============================== +CIFS +=============================== + + +.. toctree:: + :maxdepth: 1 + + cifsd + cifsroot diff --git a/Documentation/filesystems/index.rst b/Documentation/filesystems/index.rst index ac9396f2bb8a..bdba80ae2bb1 100644 --- a/Documentation/filesystems/index.rst +++ b/Documentation/filesystems/index.rst @@ -72,8 +72,7 @@ Documentation for filesystem implementations. befs bfs btrfs - cifs/cifsd - cifs/cifsroot + cifs/index ceph coda configfs -- cgit v1.2.3 From 269d3feec1b0f0c286ff3cc3eef43416614ee261 Mon Sep 17 00:00:00 2001 From: Namjae Jeon Date: Tue, 23 Mar 2021 15:17:00 +0900 Subject: cifsd: fix build warnings from cifsd.rst Stephen reported a build warnings from cifsd.rst: Documentation/filesystems/cifs/cifsd.rst:13: WARNING: Inline substitution_reference start-string without end-string. Documentation/filesystems/cifs/cifsd.rst:14: WARNING: Block quote ends without a blank line; unexpected unindent. Documentation/filesystems/cifs/cifsd.rst:14: WARNING: Inline substitution_reference start-string without end-string. Documentation/filesystems/cifs/cifsd.rst:18: WARNING: Block quote ends without a blank line; unexpected unindent. Documentation/filesystems/cifs/cifsd.rst:23: WARNING: Inline substitution_reference start-string without end-string. Documentation/filesystems/cifs/cifsd.rst:23: WARNING: Inline substitution_reference start-string without end-string. Documentation/filesystems/cifs/cifsd.rst:24: WARNING: Inline substitution_reference start-string without end-string. Documentation/filesystems/cifs/cifsd.rst:25: WARNING: Definition list ends without a blank line; unexpected unindent. Documentation/filesystems/cifs/cifsd.rst:28: WARNING: Unexpected indentation. Documentation/filesystems/cifs/cifsd.rst:31: WARNING: Block quote ends without a blank line; unexpected unindent. Documentation/filesystems/cifs/cifsd.rst:38: WARNING: Unexpected indentation. Documentation/filesystems/cifs/cifsd.rst:32: WARNING: Inline substitution_reference start-string without end-string. Documentation/filesystems/cifs/cifsd.rst:32: WARNING: Inline substitution_reference start-string without end-string. Documentation/filesystems/cifs/cifsd.rst:39: WARNING: Block quote ends without a blank line; unexpected unindent. Documentation/filesystems/cifs/cifsd.rst:14: WARNING: Undefined substitution referenced: "--- ksmbd/3 - Client 3 |-------". Documentation/filesystems/cifs/cifsd.rst:0: WARNING: Undefined substitution referenced: "____________________________________________________". Documentation/filesystems/cifs/cifsd.rst:25: WARNING: Undefined substitution referenced: "--- ksmbd/0(forker kthread) ---------------|". Documentation/filesystems/cifs/cifsd.rst:32: WARNING: Undefined substitution referenced: "______________________________________________". Signed-off-by: Namjae Jeon Signed-off-by: Steve French --- Documentation/filesystems/cifs/cifsd.rst | 28 ---------------------------- 1 file changed, 28 deletions(-) (limited to 'Documentation') diff --git a/Documentation/filesystems/cifs/cifsd.rst b/Documentation/filesystems/cifs/cifsd.rst index 7eac7e459c2d..48ae58f2a53c 100644 --- a/Documentation/filesystems/cifs/cifsd.rst +++ b/Documentation/filesystems/cifs/cifsd.rst @@ -10,34 +10,6 @@ for sharing files over network. CIFSD architecture ================== - |--- ... - --------|--- ksmbd/3 - Client 3 - |-------|--- ksmbd/2 - Client 2 - | | ____________________________________________________ - | | |- Client 1 | -<--- Socket ---|--- ksmbd/1 <<= Authentication : NTLM/NTLM2, Kerberos | - | | | | <<= SMB engine : SMB2, SMB2.1, SMB3, SMB3.0.2, | - | | | | SMB3.1.1 | - | | | |____________________________________________________| - | | | - | | |--- VFS --- Local Filesystem - | | -KERNEL |--- ksmbd/0(forker kthread) ----------------||--------------------------------------------------------------- -USER || - || communication using NETLINK - || ______________________________________________ - || | | - ksmbd.mountd <<= DCE/RPC(srvsvc, wkssvc, smar, lsarpc) | - ^ | <<= configure shares setting, user accounts | - | |______________________________________________| - | - |------ smb.conf(config file) - | - |------ ksmbdpwd.db(user account/password file) - ^ - ksmbd.adduser ---------------| - The subset of performance related operations belong in kernelspace and the other subset which belong to operations which are not really related with performance in userspace. So, DCE/RPC management that has historically resulted -- cgit v1.2.3 From 9cca7516f4c6373223d6059f1a69548fed74c5ed Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Fri, 2 Apr 2021 13:17:04 +0900 Subject: doc: cifsd: change the reference to configuration.txt added documentation for cifsd. There, it points to a file named: Documentation/configuration.txt This confuses Kernel scripts, as they think that this is a document within the Kernel tree, instead of a file from some other place. Replace it by an hyperlink to the ksmbd-tools tree, in order to avoid false-positives. Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Namjae Jeon Signed-off-by: Steve French --- Documentation/filesystems/cifs/cifsd.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/filesystems/cifs/cifsd.rst b/Documentation/filesystems/cifs/cifsd.rst index 48ae58f2a53c..cb9f87b8529f 100644 --- a/Documentation/filesystems/cifs/cifsd.rst +++ b/Documentation/filesystems/cifs/cifsd.rst @@ -114,8 +114,8 @@ How to run # ksmbd.adduser -a 3. Create /etc/ksmbd/smb.conf file, add SMB share in smb.conf file - - Refer smb.conf.example and Documentation/configuration.txt - in ksmbd-tools + - Refer smb.conf.example and + https://github.com/cifsd-team/ksmbd-tools/blob/master/Documentation/configuration.txt 4. Insert ksmbd.ko module -- cgit v1.2.3 From 204fcceb7ccf43034da8e97078153c7c6d0bc84d Mon Sep 17 00:00:00 2001 From: Namjae Jeon Date: Wed, 28 Apr 2021 13:17:47 +0900 Subject: cifsd: add ksmbd/nfsd interoperability to feature table Add ksmbd/nfsd interoperability to feature table and sync with a table in patch cover letter. Signed-off-by: Namjae Jeon Signed-off-by: Steve French --- Documentation/filesystems/cifs/cifsd.rst | 32 ++++++++++++++++++++++---------- 1 file changed, 22 insertions(+), 10 deletions(-) (limited to 'Documentation') diff --git a/Documentation/filesystems/cifs/cifsd.rst b/Documentation/filesystems/cifs/cifsd.rst index cb9f87b8529f..01a0be272ce6 100644 --- a/Documentation/filesystems/cifs/cifsd.rst +++ b/Documentation/filesystems/cifs/cifsd.rst @@ -67,7 +67,8 @@ CIFSD Feature Status Feature name Status ============================== ================================================= Dialects Supported. SMB2.1 SMB3.0, SMB3.1.1 dialects - excluding security vulnerable SMB1. + (intentionally excludes security vulnerable SMB1 + dialect). Auto Negotiation Supported. Compound Request Supported. Oplock Cache Mechanism Supported. @@ -79,26 +80,37 @@ HMAC-SHA256 Signing Supported. Secure negotiate Supported. Signing Update Supported. Pre-authentication integrity Supported. -SMB3 encryption(CCM, GCM) Supported. -SMB direct(RDMA) Partial Supported. SMB3 Multi-channel is required - to connect to Windows client. +SMB3 encryption(CCM, GCM) Supported. (CCM and GCM128 supported, GCM256 in + progress) +SMB direct(RDMA) Partially Supported. SMB3 Multi-channel is + required to connect to Windows client. SMB3 Multi-channel In Progress. SMB3.1.1 POSIX extension Supported. -ACLs Partial Supported. only DACLs available, SACLs is - planned for future. ksmbd generate random subauth +ACLs Partially Supported. only DACLs available, SACLs + (auditing) is planned for the future. For + ownership (SIDs) ksmbd generates random subauth values(then store it to disk) and use uid/gid get from inode as RID for local domain SID. The current acl implementation is limited to standalone server, not a domain member. + Integration with Samba tools is being worked on + to allow future support for running as a domain + member. Kerberos Supported. Durable handle v1,v2 Planned for future. Persistent handle Planned for future. SMB2 notify Planned for future. Sparse file support Supported. -DCE/RPC support Partial Supported. a few calls(NetShareEnumAll, - NetServerGetInfo, SAMR, LSARPC) that needed as - file server via netlink interface from - ksmbd.mountd. +DCE/RPC support Partially Supported. a few calls(NetShareEnumAll, + NetServerGetInfo, SAMR, LSARPC) that are needed + for file server handled via netlink interface + from ksmbd.mountd. Additional integration with + Samba tools and libraries via upcall is being + investigated to allow support for additional + DCE/RPC management calls (and future support + for Witness protocol e.g.) +ksmbd/nfsd interoperability Planned for future. The features that ksmbd + support are Leases, Notify, ACLs and Share modes. ============================== ================================================= -- cgit v1.2.3 From 8562e78c0b834e77d96c752974af7586939fcc54 Mon Sep 17 00:00:00 2001 From: Neil Armstrong Date: Mon, 19 Apr 2021 09:32:40 +0200 Subject: dt-bindings: display: mediatek, hdmi: Convert to use graph schema Update the mediatek,dpi binding to use the graph schema. Signed-off-by: Neil Armstrong Reviewed-by: Rob Herring Signed-off-by: Chun-Kuang Hu --- .../bindings/display/mediatek/mediatek,cec.yaml | 51 ++++++++ .../display/mediatek/mediatek,hdmi-ddc.yaml | 57 +++++++++ .../bindings/display/mediatek/mediatek,hdmi.txt | 136 --------------------- .../bindings/display/mediatek/mediatek,hdmi.yaml | 132 ++++++++++++++++++++ 4 files changed, 240 insertions(+), 136 deletions(-) create mode 100644 Documentation/devicetree/bindings/display/mediatek/mediatek,cec.yaml create mode 100644 Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi-ddc.yaml delete mode 100644 Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.txt create mode 100644 Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,cec.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,cec.yaml new file mode 100644 index 000000000000..b38d8732d7e0 --- /dev/null +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,cec.yaml @@ -0,0 +1,51 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/mediatek/mediatek,cec.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Mediatek HDMI CEC Controller Device Tree Bindings + +maintainers: + - CK Hu + - Jitao shi + +description: | + The HDMI CEC controller handles hotplug detection and CEC communication. + +properties: + compatible: + enum: + - mediatek,mt7623-cec + - mediatek,mt8173-cec + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + +required: + - compatible + - reg + - interrupts + - clocks + +additionalProperties: false + +examples: + - | + #include + #include + #include + cec: cec@10013000 { + compatible = "mediatek,mt8173-cec"; + reg = <0x10013000 0xbc>; + interrupts = ; + clocks = <&infracfg CLK_INFRA_CEC>; + }; + +... diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi-ddc.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi-ddc.yaml new file mode 100644 index 000000000000..c8ba94d6908b --- /dev/null +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi-ddc.yaml @@ -0,0 +1,57 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/mediatek/mediatek,hdmi-ddc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Mediatek HDMI DDC Device Tree Bindings + +maintainers: + - CK Hu + - Jitao shi + +description: | + The HDMI DDC i2c controller is used to interface with the HDMI DDC pins. + +properties: + compatible: + enum: + - mediatek,mt7623-hdmi-ddc + - mediatek,mt8173-hdmi-ddc + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + + clock-names: + items: + - const: ddc-i2c + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + +additionalProperties: false + +examples: + - | + #include + #include + #include + hdmi_ddc0: i2c@11012000 { + compatible = "mediatek,mt8173-hdmi-ddc"; + reg = <0x11012000 0x1c>; + interrupts = ; + clocks = <&pericfg CLK_PERI_I2C5>; + clock-names = "ddc-i2c"; + }; + +... diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.txt b/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.txt deleted file mode 100644 index b284ca51b913..000000000000 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.txt +++ /dev/null @@ -1,136 +0,0 @@ -Mediatek HDMI Encoder -===================== - -The Mediatek HDMI encoder can generate HDMI 1.4a or MHL 2.0 signals from -its parallel input. - -Required properties: -- compatible: Should be "mediatek,-hdmi". -- the supported chips are mt2701, mt7623 and mt8173 -- reg: Physical base address and length of the controller's registers -- interrupts: The interrupt signal from the function block. -- clocks: device clocks - See Documentation/devicetree/bindings/clock/clock-bindings.txt for details. -- clock-names: must contain "pixel", "pll", "bclk", and "spdif". -- phys: phandle link to the HDMI PHY node. - See Documentation/devicetree/bindings/phy/phy-bindings.txt for details. -- phy-names: must contain "hdmi" -- mediatek,syscon-hdmi: phandle link and register offset to the system - configuration registers. For mt8173 this must be offset 0x900 into the - MMSYS_CONFIG region: <&mmsys 0x900>. -- ports: A node containing input and output port nodes with endpoint - definitions as documented in Documentation/devicetree/bindings/graph.txt. -- port@0: The input port in the ports node should be connected to a DPI output - port. -- port@1: The output port in the ports node should be connected to the input - port of a connector node that contains a ddc-i2c-bus property, or to the - input port of an attached bridge chip, such as a SlimPort transmitter. - -HDMI CEC -======== - -The HDMI CEC controller handles hotplug detection and CEC communication. - -Required properties: -- compatible: Should be "mediatek,-cec" -- the supported chips are mt7623 and mt8173 -- reg: Physical base address and length of the controller's registers -- interrupts: The interrupt signal from the function block. -- clocks: device clock - -HDMI DDC -======== - -The HDMI DDC i2c controller is used to interface with the HDMI DDC pins. -The Mediatek's I2C controller is used to interface with I2C devices. - -Required properties: -- compatible: Should be "mediatek,-hdmi-ddc" -- the supported chips are mt7623 and mt8173 -- reg: Physical base address and length of the controller's registers -- clocks: device clock -- clock-names: Should be "ddc-i2c". - -HDMI PHY -======== -See phy/mediatek,hdmi-phy.yaml - -Example: - -cec: cec@10013000 { - compatible = "mediatek,mt8173-cec"; - reg = <0 0x10013000 0 0xbc>; - interrupts = ; - clocks = <&infracfg CLK_INFRA_CEC>; -}; - -hdmi_phy: hdmi-phy@10209100 { - compatible = "mediatek,mt8173-hdmi-phy"; - reg = <0 0x10209100 0 0x24>; - clocks = <&apmixedsys CLK_APMIXED_HDMI_REF>; - clock-names = "pll_ref"; - clock-output-names = "hdmitx_dig_cts"; - mediatek,ibias = <0xa>; - mediatek,ibias_up = <0x1c>; - #clock-cells = <0>; - #phy-cells = <0>; -}; - -hdmi_ddc0: i2c@11012000 { - compatible = "mediatek,mt8173-hdmi-ddc"; - reg = <0 0x11012000 0 0x1c>; - interrupts = ; - clocks = <&pericfg CLK_PERI_I2C5>; - clock-names = "ddc-i2c"; -}; - -hdmi0: hdmi@14025000 { - compatible = "mediatek,mt8173-hdmi"; - reg = <0 0x14025000 0 0x400>; - interrupts = ; - clocks = <&mmsys CLK_MM_HDMI_PIXEL>, - <&mmsys CLK_MM_HDMI_PLLCK>, - <&mmsys CLK_MM_HDMI_AUDIO>, - <&mmsys CLK_MM_HDMI_SPDIF>; - clock-names = "pixel", "pll", "bclk", "spdif"; - pinctrl-names = "default"; - pinctrl-0 = <&hdmi_pin>; - phys = <&hdmi_phy>; - phy-names = "hdmi"; - mediatek,syscon-hdmi = <&mmsys 0x900>; - assigned-clocks = <&topckgen CLK_TOP_HDMI_SEL>; - assigned-clock-parents = <&hdmi_phy>; - - ports { - #address-cells = <1>; - #size-cells = <0>; - - port@0 { - reg = <0>; - - hdmi0_in: endpoint { - remote-endpoint = <&dpi0_out>; - }; - }; - - port@1 { - reg = <1>; - - hdmi0_out: endpoint { - remote-endpoint = <&hdmi_con_in>; - }; - }; - }; -}; - -connector { - compatible = "hdmi-connector"; - type = "a"; - ddc-i2c-bus = <&hdmiddc0>; - - port { - hdmi_con_in: endpoint { - remote-endpoint = <&hdmi0_out>; - }; - }; -}; diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.yaml new file mode 100644 index 000000000000..6a144faed682 --- /dev/null +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.yaml @@ -0,0 +1,132 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/mediatek/mediatek,hdmi.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Mediatek HDMI Encoder Device Tree Bindings + +maintainers: + - CK Hu + - Jitao shi + +description: | + The Mediatek HDMI encoder can generate HDMI 1.4a or MHL 2.0 signals from + its parallel input. + +properties: + compatible: + enum: + - mediatek,mt2701-hdmi + - mediatek,mt7623-hdmi + - mediatek,mt8173-hdmi + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + items: + - description: Pixel Clock + - description: HDMI PLL + - description: Bit Clock + - description: S/PDIF Clock + + clock-names: + items: + - const: pixel + - const: pll + - const: bclk + - const: spdif + + phys: + maxItems: 1 + + phy-names: + items: + - const: hdmi + + mediatek,syscon-hdmi: + $ref: '/schemas/types.yaml#/definitions/phandle-array' + maxItems: 1 + description: | + phandle link and register offset to the system configuration registers. + + ports: + $ref: /schemas/graph.yaml#/properties/ports + + properties: + port@0: + $ref: /schemas/graph.yaml#/properties/port + description: | + Input port node. This port should be connected to a DPI output port. + + port@1: + $ref: /schemas/graph.yaml#/properties/port + description: | + Output port node. This port should be connected to the input port of a connector + node that contains a ddc-i2c-bus property, or to the input port of an attached + bridge chip, such as a SlimPort transmitter. + + required: + - port@0 + - port@1 + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + - phys + - phy-names + - mediatek,syscon-hdmi + - ports + +additionalProperties: false + +examples: + - | + #include + #include + #include + hdmi0: hdmi@14025000 { + compatible = "mediatek,mt8173-hdmi"; + reg = <0x14025000 0x400>; + interrupts = ; + clocks = <&mmsys CLK_MM_HDMI_PIXEL>, + <&mmsys CLK_MM_HDMI_PLLCK>, + <&mmsys CLK_MM_HDMI_AUDIO>, + <&mmsys CLK_MM_HDMI_SPDIF>; + clock-names = "pixel", "pll", "bclk", "spdif"; + pinctrl-names = "default"; + pinctrl-0 = <&hdmi_pin>; + phys = <&hdmi_phy>; + phy-names = "hdmi"; + mediatek,syscon-hdmi = <&mmsys 0x900>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + + hdmi0_in: endpoint { + remote-endpoint = <&dpi0_out>; + }; + }; + + port@1 { + reg = <1>; + + hdmi0_out: endpoint { + remote-endpoint = <&hdmi_con_in>; + }; + }; + }; + }; + +... -- cgit v1.2.3 From bf3605187530d82ece4f22bb1f2ac53d231f41d4 Mon Sep 17 00:00:00 2001 From: Tim Harvey Date: Tue, 30 Mar 2021 08:19:43 -0700 Subject: dt-bindings: arm: imx: add imx8mm gw7901 support The Gateworks GW7901 is an ARM based single board computer (SBC) featuring: - i.MX8M Mini SoC - LPDDR4 DRAM - eMMC FLASH - SPI FRAM - Gateworks System Controller (GSC) - Atmel ATECC Crypto Authentication - USB 2.0 - Microchip GbE Switch - Multiple multi-protocol RS232/RS485/RS422 Serial ports - onboard 802.11ac WiFi / BT - microSD socket - miniPCIe socket with PCIe, USB 2.0 and dual SIM sockets - Wide range DC power input - 802.3at PoE Acked-by: Rob Herring Signed-off-by: Tim Harvey Reviewed-by: Fabio Estevam Signed-off-by: Shawn Guo --- Documentation/devicetree/bindings/arm/fsl.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml index e3c50f231d71..eacbc1f8d466 100644 --- a/Documentation/devicetree/bindings/arm/fsl.yaml +++ b/Documentation/devicetree/bindings/arm/fsl.yaml @@ -685,6 +685,7 @@ properties: - gw,imx8mm-gw71xx-0x # i.MX8MM Gateworks Development Kit - gw,imx8mm-gw72xx-0x # i.MX8MM Gateworks Development Kit - gw,imx8mm-gw73xx-0x # i.MX8MM Gateworks Development Kit + - gw,imx8mm-gw7901 # i.MX8MM Gateworks Board - kontron,imx8mm-n801x-som # i.MX8MM Kontron SL (N801X) SOM - variscite,var-som-mx8mm # i.MX8MM Variscite VAR-SOM-MX8MM module - const: fsl,imx8mm -- cgit v1.2.3 From 5bd15031337f544891185361899db40961d9044e Mon Sep 17 00:00:00 2001 From: Samuel Holland Date: Sun, 21 Mar 2021 23:47:03 -0500 Subject: dt-bindings: timer: Simplify conditional expressions The sun4i timer IP block has a variable number of interrupts based on the compatible. Use enums to combine the two sections for the existing 3-interrupt variants, and to simplify adding new compatible strings. Acked-by: Maxime Ripard Signed-off-by: Samuel Holland Reviewed-by: Rob Herring Acked-by: Daniel Lezcano Signed-off-by: Maxime Ripard Link: https://lore.kernel.org/r/20210322044707.19479-2-samuel@sholland.org --- .../bindings/timer/allwinner,sun4i-a10-timer.yaml | 25 ++++++---------------- 1 file changed, 7 insertions(+), 18 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/timer/allwinner,sun4i-a10-timer.yaml b/Documentation/devicetree/bindings/timer/allwinner,sun4i-a10-timer.yaml index 1c7cf32e7ac2..3462598e609d 100644 --- a/Documentation/devicetree/bindings/timer/allwinner,sun4i-a10-timer.yaml +++ b/Documentation/devicetree/bindings/timer/allwinner,sun4i-a10-timer.yaml @@ -34,8 +34,8 @@ allOf: - if: properties: compatible: - items: - const: allwinner,sun4i-a10-timer + enum: + - allwinner,sun4i-a10-timer then: properties: @@ -46,8 +46,8 @@ allOf: - if: properties: compatible: - items: - const: allwinner,sun8i-a23-timer + enum: + - allwinner,sun8i-a23-timer then: properties: @@ -58,20 +58,9 @@ allOf: - if: properties: compatible: - items: - const: allwinner,sun8i-v3s-timer - - then: - properties: - interrupts: - minItems: 3 - maxItems: 3 - - - if: - properties: - compatible: - items: - const: allwinner,suniv-f1c100s-timer + enum: + - allwinner,sun8i-v3s-timer + - allwinner,suniv-f1c100s-timer then: properties: -- cgit v1.2.3 From bffdc0f3c26c7d9b5006326e0f7b7871d4eaaf13 Mon Sep 17 00:00:00 2001 From: Samuel Holland Date: Sun, 21 Mar 2021 23:47:04 -0500 Subject: dt-bindings: timer: Add compatibles for sun50i timers The sun50i SoCs contain timer blocks which are useful as broadcast clockevent sources. They each have 2 interrupts, matching the A23 variant, so add the new compatible strings with the A23 compatible as a fallback. Acked-by: Maxime Ripard Signed-off-by: Samuel Holland Reviewed-by: Rob Herring Acked-by: Daniel Lezcano Signed-off-by: Maxime Ripard Link: https://lore.kernel.org/r/20210322044707.19479-3-samuel@sholland.org --- .../bindings/timer/allwinner,sun4i-a10-timer.yaml | 17 ++++++++++++----- 1 file changed, 12 insertions(+), 5 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/timer/allwinner,sun4i-a10-timer.yaml b/Documentation/devicetree/bindings/timer/allwinner,sun4i-a10-timer.yaml index 3462598e609d..53fd24bdc34e 100644 --- a/Documentation/devicetree/bindings/timer/allwinner,sun4i-a10-timer.yaml +++ b/Documentation/devicetree/bindings/timer/allwinner,sun4i-a10-timer.yaml @@ -12,11 +12,18 @@ maintainers: properties: compatible: - enum: - - allwinner,sun4i-a10-timer - - allwinner,sun8i-a23-timer - - allwinner,sun8i-v3s-timer - - allwinner,suniv-f1c100s-timer + oneOf: + - enum: + - allwinner,sun4i-a10-timer + - allwinner,sun8i-a23-timer + - allwinner,sun8i-v3s-timer + - allwinner,suniv-f1c100s-timer + - items: + - enum: + - allwinner,sun50i-a64-timer + - allwinner,sun50i-h6-timer + - allwinner,sun50i-h616-timer + - const: allwinner,sun8i-a23-timer reg: maxItems: 1 -- cgit v1.2.3 From d88834bfefdeb8f2456934b662613dbe3bae58df Mon Sep 17 00:00:00 2001 From: Samuel Holland Date: Thu, 29 Apr 2021 22:58:53 -0500 Subject: ASoC: dt-bindings: sun8i-codec: Increase #sound-dai-cells Increase sound-dai-cells to 1 to allow using the DAIs in the codec corresponding to AIF2 and AIF3. The generic ASoC OF code supports a #sound-dai-cells value of 0 or 1 with no impact to the driver, so this is a backward-compatible change. Signed-off-by: Samuel Holland Acked-by: Rob Herring Signed-off-by: Maxime Ripard Link: https://lore.kernel.org/r/20210430035859.3487-2-samuel@sholland.org --- .../devicetree/bindings/sound/allwinner,sun8i-a33-codec.yaml | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/allwinner,sun8i-a33-codec.yaml b/Documentation/devicetree/bindings/sound/allwinner,sun8i-a33-codec.yaml index 67405e6d8168..19f111f40225 100644 --- a/Documentation/devicetree/bindings/sound/allwinner,sun8i-a33-codec.yaml +++ b/Documentation/devicetree/bindings/sound/allwinner,sun8i-a33-codec.yaml @@ -12,7 +12,11 @@ maintainers: properties: "#sound-dai-cells": - const: 0 + minimum: 0 + maximum: 1 + description: + A value of 0 is deprecated. When used, it only allows access to + the ADC/DAC and AIF1 (the CPU DAI), not the other two AIFs/DAIs. compatible: oneOf: @@ -50,7 +54,7 @@ additionalProperties: false examples: - | audio-codec@1c22e00 { - #sound-dai-cells = <0>; + #sound-dai-cells = <1>; compatible = "allwinner,sun8i-a33-codec"; reg = <0x01c22e00 0x400>; interrupts = <0 29 4>; -- cgit v1.2.3 From 0b889618939f28bf447a1618f997243f82c7ff9a Mon Sep 17 00:00:00 2001 From: Odelu Kukatla Date: Tue, 27 Apr 2021 15:20:56 +0530 Subject: dt-bindings: interconnect: Add Qualcomm SC7280 DT bindings The Qualcomm SC7280 platform has several bus fabrics that could be controlled and tuned dynamically according to the bandwidth demand. Signed-off-by: Odelu Kukatla Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/1619517059-12109-2-git-send-email-okukatla@codeaurora.org Signed-off-by: Georgi Djakov --- .../devicetree/bindings/interconnect/qcom,rpmh.yaml | 12 ++++++++++++ 1 file changed, 12 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/interconnect/qcom,rpmh.yaml b/Documentation/devicetree/bindings/interconnect/qcom,rpmh.yaml index cb6498108b78..d8afb0fbf04a 100644 --- a/Documentation/devicetree/bindings/interconnect/qcom,rpmh.yaml +++ b/Documentation/devicetree/bindings/interconnect/qcom,rpmh.yaml @@ -37,6 +37,18 @@ properties: - qcom,sc7180-npu-noc - qcom,sc7180-qup-virt - qcom,sc7180-system-noc + - qcom,sc7280-aggre1-noc + - qcom,sc7280-aggre2-noc + - qcom,sc7280-clk-virt + - qcom,sc7280-cnoc2 + - qcom,sc7280-cnoc3 + - qcom,sc7280-dc-noc + - qcom,sc7280-gem-noc + - qcom,sc7280-lpass-ag-noc + - qcom,sc7280-mc-virt + - qcom,sc7280-mmss-noc + - qcom,sc7280-nsp-noc + - qcom,sc7280-system-noc - qcom,sdm845-aggre1-noc - qcom,sdm845-aggre2-noc - qcom,sdm845-config-noc -- cgit v1.2.3 From 72ae976363a2169d95eecca07e62ccdf5b1ee4de Mon Sep 17 00:00:00 2001 From: Johan Jonker Date: Sat, 17 Apr 2021 13:29:49 +0200 Subject: dt-bindings: arm: rockchip: add more compatible strings to pmu.yaml The compatible strings below are already in use in the Rockchip dtsi files, but were somehow never added to a document, so add "rockchip,px30-pmu", "syscon", "simple-mfd" "rockchip,rk3288-pmu", "syscon", "simple-mfd" "rockchip,rk3399-pmu", "syscon", "simple-mfd" for pmu nodes to pmu.yaml. Signed-off-by: Johan Jonker Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20210417112952.8516-13-jbx6244@gmail.com Signed-off-by: Heiko Stuebner --- Documentation/devicetree/bindings/arm/rockchip/pmu.yaml | 6 ++++++ 1 file changed, 6 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/rockchip/pmu.yaml b/Documentation/devicetree/bindings/arm/rockchip/pmu.yaml index 0b816943d9aa..53115b92d17f 100644 --- a/Documentation/devicetree/bindings/arm/rockchip/pmu.yaml +++ b/Documentation/devicetree/bindings/arm/rockchip/pmu.yaml @@ -19,7 +19,10 @@ select: compatible: contains: enum: + - rockchip,px30-pmu - rockchip,rk3066-pmu + - rockchip,rk3288-pmu + - rockchip,rk3399-pmu required: - compatible @@ -28,7 +31,10 @@ properties: compatible: items: - enum: + - rockchip,px30-pmu - rockchip,rk3066-pmu + - rockchip,rk3288-pmu + - rockchip,rk3399-pmu - const: syscon - const: simple-mfd -- cgit v1.2.3 From d74622138a9bfaaaf102280ae8aeee6fae565de0 Mon Sep 17 00:00:00 2001 From: Enric Balletbo i Serra Date: Sat, 17 Apr 2021 13:29:50 +0200 Subject: dt-bindings: power: rockchip: Convert to json-schema Convert the soc/rockchip/power_domain.txt binding document to json-schema and move to the power bindings directory. Signed-off-by: Enric Balletbo i Serra Signed-off-by: Elaine Zhang Signed-off-by: Johan Jonker Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20210417112952.8516-14-jbx6244@gmail.com Signed-off-by: Heiko Stuebner --- .../bindings/power/rockchip,power-controller.yaml | 246 +++++++++++++++++++++ .../bindings/soc/rockchip/power_domain.txt | 136 ------------ 2 files changed, 246 insertions(+), 136 deletions(-) create mode 100644 Documentation/devicetree/bindings/power/rockchip,power-controller.yaml delete mode 100644 Documentation/devicetree/bindings/soc/rockchip/power_domain.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/power/rockchip,power-controller.yaml b/Documentation/devicetree/bindings/power/rockchip,power-controller.yaml new file mode 100644 index 000000000000..f71569de9ab5 --- /dev/null +++ b/Documentation/devicetree/bindings/power/rockchip,power-controller.yaml @@ -0,0 +1,246 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/power/rockchip,power-controller.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Rockchip Power Domains + +maintainers: + - Elaine Zhang + - Heiko Stuebner + +description: | + Rockchip processors include support for multiple power domains + which can be powered up/down by software based on different + application scenarios to save power. + + Power domains contained within power-controller node are + generic power domain providers documented in + Documentation/devicetree/bindings/power/power-domain.yaml. + + IP cores belonging to a power domain should contain a + "power-domains" property that is a phandle for the + power domain node representing the domain. + +properties: + $nodename: + const: power-controller + + compatible: + enum: + - rockchip,px30-power-controller + - rockchip,rk3036-power-controller + - rockchip,rk3066-power-controller + - rockchip,rk3128-power-controller + - rockchip,rk3188-power-controller + - rockchip,rk3228-power-controller + - rockchip,rk3288-power-controller + - rockchip,rk3328-power-controller + - rockchip,rk3366-power-controller + - rockchip,rk3368-power-controller + - rockchip,rk3399-power-controller + + "#power-domain-cells": + const: 1 + + "#address-cells": + const: 1 + + "#size-cells": + const: 0 + +required: + - compatible + - "#power-domain-cells" + +additionalProperties: false + +patternProperties: + "^power-domain@[0-9a-f]+$": + + $ref: "#/$defs/pd-node" + + unevaluatedProperties: false + + properties: + "#address-cells": + const: 1 + + "#size-cells": + const: 0 + + patternProperties: + "^power-domain@[0-9a-f]+$": + + $ref: "#/$defs/pd-node" + + unevaluatedProperties: false + + properties: + "#address-cells": + const: 1 + + "#size-cells": + const: 0 + + patternProperties: + "^power-domain@[0-9a-f]+$": + + $ref: "#/$defs/pd-node" + + unevaluatedProperties: false + + properties: + "#power-domain-cells": + const: 0 + +$defs: + pd-node: + type: object + description: | + Represents the power domains within the power controller node. + + properties: + reg: + maxItems: 1 + description: | + Power domain index. Valid values are defined in + "include/dt-bindings/power/px30-power.h" + "include/dt-bindings/power/rk3036-power.h" + "include/dt-bindings/power/rk3066-power.h" + "include/dt-bindings/power/rk3128-power.h" + "include/dt-bindings/power/rk3188-power.h" + "include/dt-bindings/power/rk3228-power.h" + "include/dt-bindings/power/rk3288-power.h" + "include/dt-bindings/power/rk3328-power.h" + "include/dt-bindings/power/rk3366-power.h" + "include/dt-bindings/power/rk3368-power.h" + "include/dt-bindings/power/rk3399-power.h" + + clocks: + minItems: 1 + maxItems: 30 + description: | + A number of phandles to clocks that need to be enabled + while power domain switches state. + + pm_qos: + $ref: /schemas/types.yaml#/definitions/phandle-array + description: | + A number of phandles to qos blocks which need to be saved and restored + while power domain switches state. + + "#power-domain-cells": + enum: [0, 1] + description: + Must be 0 for nodes representing a single PM domain and 1 for nodes + providing multiple PM domains. + + required: + - reg + - "#power-domain-cells" + +examples: + - | + #include + #include + + soc { + #address-cells = <2>; + #size-cells = <2>; + + qos_hdcp: qos@ffa90000 { + compatible = "rockchip,rk3399-qos", "syscon"; + reg = <0x0 0xffa90000 0x0 0x20>; + }; + + qos_iep: qos@ffa98000 { + compatible = "rockchip,rk3399-qos", "syscon"; + reg = <0x0 0xffa98000 0x0 0x20>; + }; + + qos_rga_r: qos@ffab0000 { + compatible = "rockchip,rk3399-qos", "syscon"; + reg = <0x0 0xffab0000 0x0 0x20>; + }; + + qos_rga_w: qos@ffab0080 { + compatible = "rockchip,rk3399-qos", "syscon"; + reg = <0x0 0xffab0080 0x0 0x20>; + }; + + qos_video_m0: qos@ffab8000 { + compatible = "rockchip,rk3399-qos", "syscon"; + reg = <0x0 0xffab8000 0x0 0x20>; + }; + + qos_video_m1_r: qos@ffac0000 { + compatible = "rockchip,rk3399-qos", "syscon"; + reg = <0x0 0xffac0000 0x0 0x20>; + }; + + qos_video_m1_w: qos@ffac0080 { + compatible = "rockchip,rk3399-qos", "syscon"; + reg = <0x0 0xffac0080 0x0 0x20>; + }; + + power-management@ff310000 { + compatible = "rockchip,rk3399-pmu", "syscon", "simple-mfd"; + reg = <0x0 0xff310000 0x0 0x1000>; + + power-controller { + compatible = "rockchip,rk3399-power-controller"; + #power-domain-cells = <1>; + #address-cells = <1>; + #size-cells = <0>; + + /* These power domains are grouped by VD_CENTER */ + power-domain@RK3399_PD_IEP { + reg = ; + clocks = <&cru ACLK_IEP>, + <&cru HCLK_IEP>; + pm_qos = <&qos_iep>; + #power-domain-cells = <0>; + }; + power-domain@RK3399_PD_RGA { + reg = ; + clocks = <&cru ACLK_RGA>, + <&cru HCLK_RGA>; + pm_qos = <&qos_rga_r>, + <&qos_rga_w>; + #power-domain-cells = <0>; + }; + power-domain@RK3399_PD_VCODEC { + reg = ; + clocks = <&cru ACLK_VCODEC>, + <&cru HCLK_VCODEC>; + pm_qos = <&qos_video_m0>; + #power-domain-cells = <0>; + }; + power-domain@RK3399_PD_VDU { + reg = ; + clocks = <&cru ACLK_VDU>, + <&cru HCLK_VDU>; + pm_qos = <&qos_video_m1_r>, + <&qos_video_m1_w>; + #power-domain-cells = <0>; + }; + power-domain@RK3399_PD_VIO { + reg = ; + #power-domain-cells = <1>; + #address-cells = <1>; + #size-cells = <0>; + + power-domain@RK3399_PD_HDCP { + reg = ; + clocks = <&cru ACLK_HDCP>, + <&cru HCLK_HDCP>, + <&cru PCLK_HDCP>; + pm_qos = <&qos_hdcp>; + #power-domain-cells = <0>; + }; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/soc/rockchip/power_domain.txt b/Documentation/devicetree/bindings/soc/rockchip/power_domain.txt deleted file mode 100644 index 8304eceb62e4..000000000000 --- a/Documentation/devicetree/bindings/soc/rockchip/power_domain.txt +++ /dev/null @@ -1,136 +0,0 @@ -* Rockchip Power Domains - -Rockchip processors include support for multiple power domains which can be -powered up/down by software based on different application scenes to save power. - -Required properties for power domain controller: -- compatible: Should be one of the following. - "rockchip,px30-power-controller" - for PX30 SoCs. - "rockchip,rk3036-power-controller" - for RK3036 SoCs. - "rockchip,rk3066-power-controller" - for RK3066 SoCs. - "rockchip,rk3128-power-controller" - for RK3128 SoCs. - "rockchip,rk3188-power-controller" - for RK3188 SoCs. - "rockchip,rk3228-power-controller" - for RK3228 SoCs. - "rockchip,rk3288-power-controller" - for RK3288 SoCs. - "rockchip,rk3328-power-controller" - for RK3328 SoCs. - "rockchip,rk3366-power-controller" - for RK3366 SoCs. - "rockchip,rk3368-power-controller" - for RK3368 SoCs. - "rockchip,rk3399-power-controller" - for RK3399 SoCs. -- #power-domain-cells: Number of cells in a power-domain specifier. - Should be 1 for multiple PM domains. -- #address-cells: Should be 1. -- #size-cells: Should be 0. - -Required properties for power domain sub nodes: -- reg: index of the power domain, should use macros in: - "include/dt-bindings/power/px30-power.h" - for PX30 type power domain. - "include/dt-bindings/power/rk3036-power.h" - for RK3036 type power domain. - "include/dt-bindings/power/rk3066-power.h" - for RK3066 type power domain. - "include/dt-bindings/power/rk3128-power.h" - for RK3128 type power domain. - "include/dt-bindings/power/rk3188-power.h" - for RK3188 type power domain. - "include/dt-bindings/power/rk3228-power.h" - for RK3228 type power domain. - "include/dt-bindings/power/rk3288-power.h" - for RK3288 type power domain. - "include/dt-bindings/power/rk3328-power.h" - for RK3328 type power domain. - "include/dt-bindings/power/rk3366-power.h" - for RK3366 type power domain. - "include/dt-bindings/power/rk3368-power.h" - for RK3368 type power domain. - "include/dt-bindings/power/rk3399-power.h" - for RK3399 type power domain. -- clocks (optional): phandles to clocks which need to be enabled while power domain - switches state. -- pm_qos (optional): phandles to qos blocks which need to be saved and restored - while power domain switches state. - -Qos Example: - - qos_gpu: qos_gpu@ffaf0000 { - compatible ="syscon"; - reg = <0x0 0xffaf0000 0x0 0x20>; - }; - -Example: - - power: power-controller { - compatible = "rockchip,rk3288-power-controller"; - #power-domain-cells = <1>; - #address-cells = <1>; - #size-cells = <0>; - - pd_gpu { - reg = ; - clocks = <&cru ACLK_GPU>; - pm_qos = <&qos_gpu>; - }; - }; - - power: power-controller { - compatible = "rockchip,rk3368-power-controller"; - #power-domain-cells = <1>; - #address-cells = <1>; - #size-cells = <0>; - - pd_gpu_1 { - reg = ; - clocks = <&cru ACLK_GPU_CFG>; - }; - }; - -Example 2: - power: power-controller { - compatible = "rockchip,rk3399-power-controller"; - #power-domain-cells = <1>; - #address-cells = <1>; - #size-cells = <0>; - - pd_vio { - #address-cells = <1>; - #size-cells = <0>; - reg = ; - - pd_vo { - #address-cells = <1>; - #size-cells = <0>; - reg = ; - - pd_vopb { - reg = ; - }; - - pd_vopl { - reg = ; - }; - }; - }; - }; - -Node of a device using power domains must have a power-domains property, -containing a phandle to the power device node and an index specifying which -power domain to use. -The index should use macros in: - "include/dt-bindings/power/px30-power.h" - for px30 type power domain. - "include/dt-bindings/power/rk3036-power.h" - for rk3036 type power domain. - "include/dt-bindings/power/rk3128-power.h" - for rk3128 type power domain. - "include/dt-bindings/power/rk3128-power.h" - for rk3228 type power domain. - "include/dt-bindings/power/rk3288-power.h" - for rk3288 type power domain. - "include/dt-bindings/power/rk3328-power.h" - for rk3328 type power domain. - "include/dt-bindings/power/rk3366-power.h" - for rk3366 type power domain. - "include/dt-bindings/power/rk3368-power.h" - for rk3368 type power domain. - "include/dt-bindings/power/rk3399-power.h" - for rk3399 type power domain. - -Example of the node using power domain: - - node { - /* ... */ - power-domains = <&power RK3288_PD_GPU>; - /* ... */ - }; - - node { - /* ... */ - power-domains = <&power RK3368_PD_GPU_1>; - /* ... */ - }; - - node { - /* ... */ - power-domains = <&power RK3399_PD_VOPB>; - /* ... */ - }; -- cgit v1.2.3 From 66b89b8b5e4cfb1d492c1ac16c0ef07e47c44e84 Mon Sep 17 00:00:00 2001 From: Elaine Zhang Date: Sat, 17 Apr 2021 13:29:51 +0200 Subject: dt-bindings: power: rockchip: Add bindings for RK3568 Soc Add the compatible string for RK3568 SoC. Signed-off-by: Elaine Zhang Signed-off-by: Johan Jonker Acked-by: Rob Herring Link: https://lore.kernel.org/r/20210417112952.8516-15-jbx6244@gmail.com Signed-off-by: Heiko Stuebner --- Documentation/devicetree/bindings/power/rockchip,power-controller.yaml | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/power/rockchip,power-controller.yaml b/Documentation/devicetree/bindings/power/rockchip,power-controller.yaml index f71569de9ab5..9b9d71087466 100644 --- a/Documentation/devicetree/bindings/power/rockchip,power-controller.yaml +++ b/Documentation/devicetree/bindings/power/rockchip,power-controller.yaml @@ -40,6 +40,7 @@ properties: - rockchip,rk3366-power-controller - rockchip,rk3368-power-controller - rockchip,rk3399-power-controller + - rockchip,rk3568-power-controller "#power-domain-cells": const: 1 @@ -117,6 +118,7 @@ $defs: "include/dt-bindings/power/rk3366-power.h" "include/dt-bindings/power/rk3368-power.h" "include/dt-bindings/power/rk3399-power.h" + "include/dt-bindings/power/rk3568-power.h" clocks: minItems: 1 -- cgit v1.2.3 From de3d7018372cdb2325ba375872578405cf0554d0 Mon Sep 17 00:00:00 2001 From: Dmitry Osipenko Date: Tue, 11 May 2021 00:23:20 +0300 Subject: dt-bindings: memory: tegra20: emc: Convert to schema Convert Tegra20 External Memory Controller binding to schema. Signed-off-by: Dmitry Osipenko Link: https://lore.kernel.org/r/20210510212320.3255-1-digetx@gmail.com Signed-off-by: Rob Herring --- .../memory-controllers/nvidia,tegra20-emc.txt | 130 ------------ .../memory-controllers/nvidia,tegra20-emc.yaml | 230 +++++++++++++++++++++ 2 files changed, 230 insertions(+), 130 deletions(-) delete mode 100644 Documentation/devicetree/bindings/memory-controllers/nvidia,tegra20-emc.txt create mode 100644 Documentation/devicetree/bindings/memory-controllers/nvidia,tegra20-emc.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra20-emc.txt b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra20-emc.txt deleted file mode 100644 index d2250498c36d..000000000000 --- a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra20-emc.txt +++ /dev/null @@ -1,130 +0,0 @@ -Embedded Memory Controller - -Properties: -- name : Should be emc -- #address-cells : Should be 1 -- #size-cells : Should be 0 -- compatible : Should contain "nvidia,tegra20-emc". -- reg : Offset and length of the register set for the device -- nvidia,use-ram-code : If present, the sub-nodes will be addressed - and chosen using the ramcode board selector. If omitted, only one - set of tables can be present and said tables will be used - irrespective of ram-code configuration. -- interrupts : Should contain EMC General interrupt. -- clocks : Should contain EMC clock. -- nvidia,memory-controller : Phandle of the Memory Controller node. -- #interconnect-cells : Should be 0. -- operating-points-v2: See ../bindings/opp/opp.txt for details. - -For each opp entry in 'operating-points-v2' table: -- opp-supported-hw: One bitfield indicating SoC process ID mask - - A bitwise AND is performed against this value and if any bit - matches, the OPP gets enabled. - -Optional properties: -- power-domains: Phandle of the SoC "core" power domain. - -Child device nodes describe the memory settings for different configurations and clock rates. - -Example: - - opp_table: opp-table { - compatible = "operating-points-v2"; - - opp@36000000 { - opp-microvolt = <950000 950000 1300000>; - opp-hz = /bits/ 64 <36000000>; - }; - ... - }; - - memory-controller@7000f400 { - #address-cells = < 1 >; - #size-cells = < 0 >; - #interconnect-cells = <0>; - compatible = "nvidia,tegra20-emc"; - reg = <0x7000f400 0x400>; - interrupts = <0 78 0x04>; - clocks = <&tegra_car TEGRA20_CLK_EMC>; - nvidia,memory-controller = <&mc>; - power-domains = <&domain>; - operating-points-v2 = <&opp_table>; - } - - -Embedded Memory Controller ram-code table - -If the emc node has the nvidia,use-ram-code property present, then the -next level of nodes below the emc table are used to specify which settings -apply for which ram-code settings. - -If the emc node lacks the nvidia,use-ram-code property, this level is omitted -and the tables are stored directly under the emc node (see below). - -Properties: - -- name : Should be emc-tables -- nvidia,ram-code : the binary representation of the ram-code board strappings - for which this node (and children) are valid. - - - -Embedded Memory Controller configuration table - -This is a table containing the EMC register settings for the various -operating speeds of the memory controller. They are always located as -subnodes of the emc controller node. - -There are two ways of specifying which tables to use: - -* The simplest is if there is just one set of tables in the device tree, - and they will always be used (based on which frequency is used). - This is the preferred method, especially when firmware can fill in - this information based on the specific system information and just - pass it on to the kernel. - -* The slightly more complex one is when more than one memory configuration - might exist on the system. The Tegra20 platform handles this during - early boot by selecting one out of possible 4 memory settings based - on a 2-pin "ram code" bootstrap setting on the board. The values of - these strappings can be read through a register in the SoC, and thus - used to select which tables to use. - -Properties: -- name : Should be emc-table -- compatible : Should contain "nvidia,tegra20-emc-table". -- reg : either an opaque enumerator to tell different tables apart, or - the valid frequency for which the table should be used (in kHz). -- clock-frequency : the clock frequency for the EMC at which this - table should be used (in kHz). -- nvidia,emc-registers : a 46 word array of EMC registers to be programmed - for operation at the 'clock-frequency' setting. - The order and contents of the registers are: - RC, RFC, RAS, RP, R2W, W2R, R2P, W2P, RD_RCD, WR_RCD, RRD, REXT, - WDV, QUSE, QRST, QSAFE, RDV, REFRESH, BURST_REFRESH_NUM, PDEX2WR, - PDEX2RD, PCHG2PDEN, ACT2PDEN, AR2PDEN, RW2PDEN, TXSR, TCKE, TFAW, - TRPAB, TCLKSTABLE, TCLKSTOP, TREFBW, QUSE_EXTRA, FBIO_CFG6, ODT_WRITE, - ODT_READ, FBIO_CFG5, CFG_DIG_DLL, DLL_XFORM_DQS, DLL_XFORM_QUSE, - ZCAL_REF_CNT, ZCAL_WAIT_CNT, AUTO_CAL_INTERVAL, CFG_CLKTRIM_0, - CFG_CLKTRIM_1, CFG_CLKTRIM_2 - - emc-table@166000 { - reg = <166000>; - compatible = "nvidia,tegra20-emc-table"; - clock-frequency = < 166000 >; - nvidia,emc-registers = < 0 0 0 0 0 0 0 0 0 0 0 0 0 0 - 0 0 0 0 0 0 0 0 0 0 0 0 0 0 - 0 0 0 0 0 0 0 0 0 0 0 0 0 0 - 0 0 0 0 >; - }; - - emc-table@333000 { - reg = <333000>; - compatible = "nvidia,tegra20-emc-table"; - clock-frequency = < 333000 >; - nvidia,emc-registers = < 0 0 0 0 0 0 0 0 0 0 0 0 0 0 - 0 0 0 0 0 0 0 0 0 0 0 0 0 0 - 0 0 0 0 0 0 0 0 0 0 0 0 0 0 - 0 0 0 0 >; - }; diff --git a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra20-emc.yaml b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra20-emc.yaml new file mode 100644 index 000000000000..cac6842dc8f1 --- /dev/null +++ b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra20-emc.yaml @@ -0,0 +1,230 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/memory-controllers/nvidia,tegra20-emc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NVIDIA Tegra20 SoC External Memory Controller + +maintainers: + - Dmitry Osipenko + - Jon Hunter + - Thierry Reding + +description: | + The External Memory Controller (EMC) interfaces with the off-chip SDRAM to + service the request stream sent from Memory Controller. The EMC also has + various performance-affecting settings beyond the obvious SDRAM configuration + parameters and initialization settings. Tegra20 EMC supports multiple JEDEC + standard protocols: DDR1, LPDDR2 and DDR2. + +properties: + compatible: + const: nvidia,tegra20-emc + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + + interrupts: + maxItems: 1 + + "#address-cells": + const: 1 + + "#size-cells": + const: 0 + + "#interconnect-cells": + const: 0 + + nvidia,memory-controller: + $ref: /schemas/types.yaml#/definitions/phandle + description: + Phandle of the Memory Controller node. + + power-domains: + maxItems: 1 + description: + Phandle of the SoC "core" power domain. + + operating-points-v2: + description: + Should contain freqs and voltages and opp-supported-hw property, which + is a bitfield indicating SoC process ID mask. + + nvidia,use-ram-code: + type: boolean + description: + If present, the emc-tables@ sub-nodes will be addressed. + +$defs: + emc-table: + type: object + properties: + compatible: + const: nvidia,tegra20-emc-table + + clock-frequency: + description: + Memory clock rate in kHz. + minimum: 1000 + maximum: 900000 + + reg: + maxItems: 1 + description: + Either an opaque enumerator to tell different tables apart, or + the valid frequency for which the table should be used (in kHz). + + nvidia,emc-registers: + description: + EMC timing characterization data. These are the registers + (see section "15.4.1 EMC Registers" in the TRM) whose values + need to be specified, according to the board documentation. + $ref: /schemas/types.yaml#/definitions/uint32-array + items: + - description: EMC_RC + - description: EMC_RFC + - description: EMC_RAS + - description: EMC_RP + - description: EMC_R2W + - description: EMC_W2R + - description: EMC_R2P + - description: EMC_W2P + - description: EMC_RD_RCD + - description: EMC_WR_RCD + - description: EMC_RRD + - description: EMC_REXT + - description: EMC_WDV + - description: EMC_QUSE + - description: EMC_QRST + - description: EMC_QSAFE + - description: EMC_RDV + - description: EMC_REFRESH + - description: EMC_BURST_REFRESH_NUM + - description: EMC_PDEX2WR + - description: EMC_PDEX2RD + - description: EMC_PCHG2PDEN + - description: EMC_ACT2PDEN + - description: EMC_AR2PDEN + - description: EMC_RW2PDEN + - description: EMC_TXSR + - description: EMC_TCKE + - description: EMC_TFAW + - description: EMC_TRPAB + - description: EMC_TCLKSTABLE + - description: EMC_TCLKSTOP + - description: EMC_TREFBW + - description: EMC_QUSE_EXTRA + - description: EMC_FBIO_CFG6 + - description: EMC_ODT_WRITE + - description: EMC_ODT_READ + - description: EMC_FBIO_CFG5 + - description: EMC_CFG_DIG_DLL + - description: EMC_DLL_XFORM_DQS + - description: EMC_DLL_XFORM_QUSE + - description: EMC_ZCAL_REF_CNT + - description: EMC_ZCAL_WAIT_CNT + - description: EMC_AUTO_CAL_INTERVAL + - description: EMC_CFG_CLKTRIM_0 + - description: EMC_CFG_CLKTRIM_1 + - description: EMC_CFG_CLKTRIM_2 + + required: + - clock-frequency + - compatible + - reg + - nvidia,emc-registers + + additionalProperties: false + +patternProperties: + "^emc-table@[0-9]+$": + $ref: "#/$defs/emc-table" + + "^emc-tables@[a-z0-9-]+$": + type: object + properties: + reg: + maxItems: 1 + description: + An opaque enumerator to tell different tables apart. + + nvidia,ram-code: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + Value of RAM_CODE this timing set is used for. + + "#address-cells": + const: 1 + + "#size-cells": + const: 0 + + patternProperties: + "^emc-table@[0-9]+$": + $ref: "#/$defs/emc-table" + + required: + - nvidia,ram-code + + additionalProperties: false + +required: + - compatible + - reg + - interrupts + - clocks + - nvidia,memory-controller + - "#interconnect-cells" + - operating-points-v2 + +additionalProperties: false + +examples: + - | + external-memory-controller@7000f400 { + compatible = "nvidia,tegra20-emc"; + reg = <0x7000f400 0x400>; + interrupts = <0 78 4>; + clocks = <&clock_controller 57>; + + nvidia,memory-controller = <&mc>; + operating-points-v2 = <&dvfs_opp_table>; + power-domains = <&domain>; + + #interconnect-cells = <0>; + #address-cells = <1>; + #size-cells = <0>; + + nvidia,use-ram-code; + + emc-tables@0 { + nvidia,ram-code = <0>; + reg = <0>; + + #address-cells = <1>; + #size-cells = <0>; + + emc-table@333000 { + reg = <333000>; + compatible = "nvidia,tegra20-emc-table"; + clock-frequency = <333000>; + nvidia,emc-registers = <0x00000018 0x00000033 + 0x00000012 0x00000004 0x00000004 0x00000005 + 0x00000003 0x0000000c 0x00000006 0x00000006 + 0x00000003 0x00000001 0x00000004 0x00000005 + 0x00000004 0x00000009 0x0000000d 0x00000bff + 0x00000000 0x00000003 0x00000003 0x00000006 + 0x00000006 0x00000001 0x00000011 0x000000c8 + 0x00000003 0x0000000e 0x00000007 0x00000008 + 0x00000002 0x00000000 0x00000000 0x00000002 + 0x00000000 0x00000000 0x00000083 0xf0440303 + 0x007fe010 0x00001414 0x00000000 0x00000000 + 0x00000000 0x00000000 0x00000000 0x00000000>; + }; + }; + }; -- cgit v1.2.3 From 727ecd99a4c91cd08cea7301d0e97d81d2d11d20 Mon Sep 17 00:00:00 2001 From: Matthew Auld Date: Tue, 11 May 2021 18:03:56 +0100 Subject: drm/doc/rfc: drop the i915_gem_lmem.h header The proper headers have now landed in include/uapi/drm/i915_drm.h, so we can drop i915_gem_lmem.h and instead just reference the real headers for pulling in the kernel doc. Suggested-by: Daniel Vetter Signed-off-by: Matthew Auld Reviewed-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20210511170356.430284-1-matthew.auld@intel.com --- Documentation/gpu/rfc/i915_gem_lmem.h | 237 -------------------------------- Documentation/gpu/rfc/i915_gem_lmem.rst | 6 +- 2 files changed, 3 insertions(+), 240 deletions(-) delete mode 100644 Documentation/gpu/rfc/i915_gem_lmem.h (limited to 'Documentation') diff --git a/Documentation/gpu/rfc/i915_gem_lmem.h b/Documentation/gpu/rfc/i915_gem_lmem.h deleted file mode 100644 index d9c61bea0556..000000000000 --- a/Documentation/gpu/rfc/i915_gem_lmem.h +++ /dev/null @@ -1,237 +0,0 @@ -/** - * enum drm_i915_gem_memory_class - Supported memory classes - */ -enum drm_i915_gem_memory_class { - /** @I915_MEMORY_CLASS_SYSTEM: System memory */ - I915_MEMORY_CLASS_SYSTEM = 0, - /** @I915_MEMORY_CLASS_DEVICE: Device local-memory */ - I915_MEMORY_CLASS_DEVICE, -}; - -/** - * struct drm_i915_gem_memory_class_instance - Identify particular memory region - */ -struct drm_i915_gem_memory_class_instance { - /** @memory_class: See enum drm_i915_gem_memory_class */ - __u16 memory_class; - - /** @memory_instance: Which instance */ - __u16 memory_instance; -}; - -/** - * struct drm_i915_memory_region_info - Describes one region as known to the - * driver. - * - * Note that we reserve some stuff here for potential future work. As an example - * we might want expose the capabilities for a given region, which could include - * things like if the region is CPU mappable/accessible, what are the supported - * mapping types etc. - * - * Note that to extend struct drm_i915_memory_region_info and struct - * drm_i915_query_memory_regions in the future the plan is to do the following: - * - * .. code-block:: C - * - * struct drm_i915_memory_region_info { - * struct drm_i915_gem_memory_class_instance region; - * union { - * __u32 rsvd0; - * __u32 new_thing1; - * }; - * ... - * union { - * __u64 rsvd1[8]; - * struct { - * __u64 new_thing2; - * __u64 new_thing3; - * ... - * }; - * }; - * }; - * - * With this things should remain source compatible between versions for - * userspace, even as we add new fields. - * - * Note this is using both struct drm_i915_query_item and struct drm_i915_query. - * For this new query we are adding the new query id DRM_I915_QUERY_MEMORY_REGIONS - * at &drm_i915_query_item.query_id. - */ -struct drm_i915_memory_region_info { - /** @region: The class:instance pair encoding */ - struct drm_i915_gem_memory_class_instance region; - - /** @rsvd0: MBZ */ - __u32 rsvd0; - - /** @probed_size: Memory probed by the driver (-1 = unknown) */ - __u64 probed_size; - - /** @unallocated_size: Estimate of memory remaining (-1 = unknown) */ - __u64 unallocated_size; - - /** @rsvd1: MBZ */ - __u64 rsvd1[8]; -}; - -/** - * struct drm_i915_query_memory_regions - * - * The region info query enumerates all regions known to the driver by filling - * in an array of struct drm_i915_memory_region_info structures. - * - * Example for getting the list of supported regions: - * - * .. code-block:: C - * - * struct drm_i915_query_memory_regions *info; - * struct drm_i915_query_item item = { - * .query_id = DRM_I915_QUERY_MEMORY_REGIONS; - * }; - * struct drm_i915_query query = { - * .num_items = 1, - * .items_ptr = (uintptr_t)&item, - * }; - * int err, i; - * - * // First query the size of the blob we need, this needs to be large - * // enough to hold our array of regions. The kernel will fill out the - * // item.length for us, which is the number of bytes we need. - * err = ioctl(fd, DRM_IOCTL_I915_QUERY, &query); - * if (err) ... - * - * info = calloc(1, item.length); - * // Now that we allocated the required number of bytes, we call the ioctl - * // again, this time with the data_ptr pointing to our newly allocated - * // blob, which the kernel can then populate with the all the region info. - * item.data_ptr = (uintptr_t)&info, - * - * err = ioctl(fd, DRM_IOCTL_I915_QUERY, &query); - * if (err) ... - * - * // We can now access each region in the array - * for (i = 0; i < info->num_regions; i++) { - * struct drm_i915_memory_region_info mr = info->regions[i]; - * u16 class = mr.region.class; - * u16 instance = mr.region.instance; - * - * .... - * } - * - * free(info); - */ -struct drm_i915_query_memory_regions { - /** @num_regions: Number of supported regions */ - __u32 num_regions; - - /** @rsvd: MBZ */ - __u32 rsvd[3]; - - /** @regions: Info about each supported region */ - struct drm_i915_memory_region_info regions[]; -}; - -#define DRM_I915_GEM_CREATE_EXT 0xdeadbeaf -#define DRM_IOCTL_I915_GEM_CREATE_EXT DRM_IOWR(DRM_COMMAND_BASE + DRM_I915_GEM_CREATE_EXT, struct drm_i915_gem_create_ext) - -/** - * struct drm_i915_gem_create_ext - Existing gem_create behaviour, with added - * extension support using struct i915_user_extension. - * - * Note that in the future we want to have our buffer flags here, at least for - * the stuff that is immutable. Previously we would have two ioctls, one to - * create the object with gem_create, and another to apply various parameters, - * however this creates some ambiguity for the params which are considered - * immutable. Also in general we're phasing out the various SET/GET ioctls. - */ -struct drm_i915_gem_create_ext { - /** - * @size: Requested size for the object. - * - * The (page-aligned) allocated size for the object will be returned. - * - * Note that for some devices we have might have further minimum - * page-size restrictions(larger than 4K), like for device local-memory. - * However in general the final size here should always reflect any - * rounding up, if for example using the I915_GEM_CREATE_EXT_MEMORY_REGIONS - * extension to place the object in device local-memory. - */ - __u64 size; - /** - * @handle: Returned handle for the object. - * - * Object handles are nonzero. - */ - __u32 handle; - /** @flags: MBZ */ - __u32 flags; - /** - * @extensions: The chain of extensions to apply to this object. - * - * This will be useful in the future when we need to support several - * different extensions, and we need to apply more than one when - * creating the object. See struct i915_user_extension. - * - * If we don't supply any extensions then we get the same old gem_create - * behaviour. - * - * For I915_GEM_CREATE_EXT_MEMORY_REGIONS usage see - * struct drm_i915_gem_create_ext_memory_regions. - */ -#define I915_GEM_CREATE_EXT_MEMORY_REGIONS 0 - __u64 extensions; -}; - -/** - * struct drm_i915_gem_create_ext_memory_regions - The - * I915_GEM_CREATE_EXT_MEMORY_REGIONS extension. - * - * Set the object with the desired set of placements/regions in priority - * order. Each entry must be unique and supported by the device. - * - * This is provided as an array of struct drm_i915_gem_memory_class_instance, or - * an equivalent layout of class:instance pair encodings. See struct - * drm_i915_query_memory_regions and DRM_I915_QUERY_MEMORY_REGIONS for how to - * query the supported regions for a device. - * - * As an example, on discrete devices, if we wish to set the placement as - * device local-memory we can do something like: - * - * .. code-block:: C - * - * struct drm_i915_gem_memory_class_instance region_lmem = { - * .memory_class = I915_MEMORY_CLASS_DEVICE, - * .memory_instance = 0, - * }; - * struct drm_i915_gem_create_ext_memory_regions regions = { - * .base = { .name = I915_GEM_CREATE_EXT_MEMORY_REGIONS }, - * .regions = (uintptr_t)®ion_lmem, - * .num_regions = 1, - * }; - * struct drm_i915_gem_create_ext create_ext = { - * .size = 16 * PAGE_SIZE, - * .extensions = (uintptr_t)®ions, - * }; - * - * int err = ioctl(fd, DRM_IOCTL_I915_GEM_CREATE_EXT, &create_ext); - * if (err) ... - * - * At which point we get the object handle in &drm_i915_gem_create_ext.handle, - * along with the final object size in &drm_i915_gem_create_ext.size, which - * should account for any rounding up, if required. - */ -struct drm_i915_gem_create_ext_memory_regions { - /** @base: Extension link. See struct i915_user_extension. */ - struct i915_user_extension base; - - /** @pad: MBZ */ - __u32 pad; - /** @num_regions: Number of elements in the @regions array. */ - __u32 num_regions; - /** - * @regions: The regions/placements array. - * - * An array of struct drm_i915_gem_memory_class_instance. - */ - __u64 regions; -}; diff --git a/Documentation/gpu/rfc/i915_gem_lmem.rst b/Documentation/gpu/rfc/i915_gem_lmem.rst index 1d344c593018..675ba8620d66 100644 --- a/Documentation/gpu/rfc/i915_gem_lmem.rst +++ b/Documentation/gpu/rfc/i915_gem_lmem.rst @@ -48,7 +48,7 @@ particular instance, since we can have more than one per class. In the future we also want to expose more information which can further describe the capabilities of a region. -.. kernel-doc:: Documentation/gpu/rfc/i915_gem_lmem.h +.. kernel-doc:: include/uapi/drm/i915_drm.h :functions: drm_i915_gem_memory_class drm_i915_gem_memory_class_instance drm_i915_memory_region_info drm_i915_query_memory_regions GEM_CREATE_EXT @@ -61,7 +61,7 @@ Side note: We also need to support PXP[1] in the near future, which is also applicable to integrated platforms, and adds its own gem_create_ext extension, which basically lets userspace mark a buffer as "protected". -.. kernel-doc:: Documentation/gpu/rfc/i915_gem_lmem.h +.. kernel-doc:: include/uapi/drm/i915_drm.h :functions: drm_i915_gem_create_ext I915_GEM_CREATE_EXT_MEMORY_REGIONS @@ -73,7 +73,7 @@ them each to use the class/instance encoding, as per the output of the regions query. Having the list in priority order will be useful in the future when placing an object, say during eviction. -.. kernel-doc:: Documentation/gpu/rfc/i915_gem_lmem.h +.. kernel-doc:: include/uapi/drm/i915_drm.h :functions: drm_i915_gem_create_ext_memory_regions One fair criticism here is that this seems a little over-engineered[2]. If we -- cgit v1.2.3 From e4042ad492357fa995921376462b04a025dd53b6 Mon Sep 17 00:00:00 2001 From: Peter Zijlstra Date: Tue, 4 May 2021 22:43:32 +0200 Subject: delayacct: Default disabled Assuming this stuff isn't actually used much; disable it by default and avoid allocating and tracking the task_delay_info structure. taskstats is changed to still report the regular sched and sched_info and only skip the missing task_delay_info fields instead of not reporting anything. Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Thomas Gleixner Reviewed-by: Ingo Molnar Link: https://lkml.kernel.org/r/20210505111525.308018373@infradead.org --- Documentation/accounting/delay-accounting.rst | 8 ++++---- Documentation/admin-guide/kernel-parameters.txt | 2 +- 2 files changed, 5 insertions(+), 5 deletions(-) (limited to 'Documentation') diff --git a/Documentation/accounting/delay-accounting.rst b/Documentation/accounting/delay-accounting.rst index 7cc7f5852da0..f20b282d6de0 100644 --- a/Documentation/accounting/delay-accounting.rst +++ b/Documentation/accounting/delay-accounting.rst @@ -69,13 +69,13 @@ Compile the kernel with:: CONFIG_TASK_DELAY_ACCT=y CONFIG_TASKSTATS=y -Delay accounting is enabled by default at boot up. -To disable, add:: +Delay accounting is disabled by default at boot up. +To enable, add:: - nodelayacct + delayacct to the kernel boot options. The rest of the instructions -below assume this has not been done. +below assume this has been done. After the system has booted up, use a utility similar to getdelays.c to access the delays diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index cb89dbdedc46..ef5048c127a3 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -3244,7 +3244,7 @@ noclflush [BUGS=X86] Don't use the CLFLUSH instruction - nodelayacct [KNL] Disable per-task delay accounting + delayacct [KNL] Enable per-task delay accounting nodsp [SH] Disable hardware DSP at boot time. -- cgit v1.2.3 From 0cd7c741f01de13dc1eecf22557593b3514639bb Mon Sep 17 00:00:00 2001 From: Peter Zijlstra Date: Mon, 10 May 2021 14:01:00 +0200 Subject: delayacct: Add sysctl to enable at runtime Just like sched_schedstats, allow runtime enabling (and disabling) of delayacct. This is useful if one forgot to add the delayacct boot time option. Signed-off-by: Peter Zijlstra (Intel) Link: https://lkml.kernel.org/r/YJkhebGJAywaZowX@hirez.programming.kicks-ass.net --- Documentation/accounting/delay-accounting.rst | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/accounting/delay-accounting.rst b/Documentation/accounting/delay-accounting.rst index f20b282d6de0..1b8b46deeb29 100644 --- a/Documentation/accounting/delay-accounting.rst +++ b/Documentation/accounting/delay-accounting.rst @@ -74,8 +74,10 @@ To enable, add:: delayacct -to the kernel boot options. The rest of the instructions -below assume this has been done. +to the kernel boot options. The rest of the instructions below assume this has +been done. Alternatively, use sysctl kernel.task_delayacct to switch the state +at runtime. Note however that only tasks started after enabling it will have +delayacct information. After the system has booted up, use a utility similar to getdelays.c to access the delays -- cgit v1.2.3 From 63c4acfb8031fbcd50cf51cb94aaadc816d99c7c Mon Sep 17 00:00:00 2001 From: Johan Jonker Date: Tue, 11 May 2021 07:05:08 +0200 Subject: dt-bindings: gpio: convert rk3328-grf-gpio.txt to YAML Current dts files with RK3328 GRF 'gpio' nodes are manually verified. In order to automate this process rk3328-grf-gpio.txt has to be converted to YAML. Rename 'grf-gpio' nodename to 'gpio'. Signed-off-by: Johan Jonker Reviewed-by: Rob Herring Reviewed-by: Linus Walleij Signed-off-by: Bartosz Golaszewski --- .../bindings/gpio/rockchip,rk3328-grf-gpio.txt | 32 -------------- .../bindings/gpio/rockchip,rk3328-grf-gpio.yaml | 50 ++++++++++++++++++++++ 2 files changed, 50 insertions(+), 32 deletions(-) delete mode 100644 Documentation/devicetree/bindings/gpio/rockchip,rk3328-grf-gpio.txt create mode 100644 Documentation/devicetree/bindings/gpio/rockchip,rk3328-grf-gpio.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/gpio/rockchip,rk3328-grf-gpio.txt b/Documentation/devicetree/bindings/gpio/rockchip,rk3328-grf-gpio.txt deleted file mode 100644 index f9231df17c2b..000000000000 --- a/Documentation/devicetree/bindings/gpio/rockchip,rk3328-grf-gpio.txt +++ /dev/null @@ -1,32 +0,0 @@ -Rockchip RK3328 GRF (General Register Files) GPIO controller. - -In Rockchip RK3328, the output only GPIO_MUTE pin, originally for codec mute -control, can also be used for general purpose. It is manipulated by the -GRF_SOC_CON10 register in GRF. Aside from the GPIO_MUTE pin, the HDMI pins can -also be set in the same way. - -Currently this GPIO controller only supports the mute pin. If needed in the -future, the HDMI pins support can also be added. - -Required properties: -- compatible: Should contain "rockchip,rk3328-grf-gpio". -- 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 the gpio polarity: - 0 = Active high, - 1 = Active low. - -Example: - - grf: syscon@ff100000 { - compatible = "rockchip,rk3328-grf", "syscon", "simple-mfd"; - - grf_gpio: grf-gpio { - compatible = "rockchip,rk3328-grf-gpio"; - gpio-controller; - #gpio-cells = <2>; - }; - }; - -Note: The grf_gpio node should be declared as the child of the GRF (General -Register File) node. The GPIO_MUTE pin is referred to as <&grf_gpio 0>. diff --git a/Documentation/devicetree/bindings/gpio/rockchip,rk3328-grf-gpio.yaml b/Documentation/devicetree/bindings/gpio/rockchip,rk3328-grf-gpio.yaml new file mode 100644 index 000000000000..d8cce73ea0ae --- /dev/null +++ b/Documentation/devicetree/bindings/gpio/rockchip,rk3328-grf-gpio.yaml @@ -0,0 +1,50 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/gpio/rockchip,rk3328-grf-gpio.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Rockchip RK3328 General Register Files GPIO controller + +description: + The Rockchip RK3328 General Register File (GRF) outputs only the + GPIO_MUTE pin, originally for codec mute control, but it can also be used + for general purpose. It is manipulated by the GRF_SOC_CON10 register. + If needed in the future support for the HDMI pins can also be added. + The GPIO node should be declared as the child of the GRF node. + + The GPIO_MUTE pin is referred to in the format + + <&grf_gpio 0 GPIO_ACTIVE_LOW> + + The first cell is the pin number and + the second cell is used to specify the GPIO polarity + 0 = Active high + 1 = Active low + +maintainers: + - Heiko Stuebner + +properties: + compatible: + const: rockchip,rk3328-grf-gpio + + gpio-controller: true + + "#gpio-cells": + const: 2 + +required: + - compatible + - gpio-controller + - "#gpio-cells" + +additionalProperties: false + +examples: + - | + grf_gpio: gpio { + compatible = "rockchip,rk3328-grf-gpio"; + gpio-controller; + #gpio-cells = <2>; + }; -- cgit v1.2.3 From c9f2e3c3ddab87d93cde99f6da10dd00c1d1edb9 Mon Sep 17 00:00:00 2001 From: Vitaly Rodionov Date: Tue, 11 May 2021 15:52:20 +0100 Subject: ASoC: cs42l42: make HSBIAS_SENSE_EN optional HSBIAS_SENSE_EN configures HSBIAS output current sense through the external 2.21-k resistor. HSBIAS_SENSE is hardware feature to reduce the potential pop noise during the headset plug out slowly. But on some platforms ESD voltage will affect it causing test to fail, especially with CTIA headset type. For different hardware setups, a designer might want to tweak default behavior. Signed-off-by: Vitaly Rodionov Link: https://lore.kernel.org/r/20210511145220.125760-1-vitalyr@opensource.cirrus.com Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/sound/cs42l42.txt | 7 +++++++ 1 file changed, 7 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/cs42l42.txt b/Documentation/devicetree/bindings/sound/cs42l42.txt index 7dfaa2ab906f..5d416fdaf023 100644 --- a/Documentation/devicetree/bindings/sound/cs42l42.txt +++ b/Documentation/devicetree/bindings/sound/cs42l42.txt @@ -81,6 +81,13 @@ Optional properties: < x1 x2 x3 x4 > Default = < 15 8 4 1> + - cirrus,hs-bias-sense-disable: This is boolean property. If present the + HSBIAS sense is disabled. Configures HSBIAS output current sense through + the external 2.21-k resistor. HSBIAS_SENSE is hardware feature to reduce + the potential pop noise during the headset plug out slowly. But on some + platforms ESD voltage will affect it causing test to fail, especially + with CTIA headset type. For different hardware setups, a designer might + want to tweak default behavior. Example: -- cgit v1.2.3 From 4eab77fc8ae77316417b987ad16e67d2bc739cc5 Mon Sep 17 00:00:00 2001 From: Hsin-Yi Wang Date: Wed, 21 Apr 2021 17:05:52 +0800 Subject: dt-bindings: arm64: dts: mediatek: Add mt8183-kukui-jacuzzi-kappa Kappa is known as HP Chromebook 11a. Signed-off-by: Hsin-Yi Wang Reviewed-by: Enric Balletbo i Serra Acked-by: Rob Herring Link: https://lore.kernel.org/r/20210421090601.730744-2-hsinyi@chromium.org Signed-off-by: Matthias Brugger --- Documentation/devicetree/bindings/arm/mediatek.yaml | 4 ++++ 1 file changed, 4 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/mediatek.yaml b/Documentation/devicetree/bindings/arm/mediatek.yaml index aff57a8c8c30..81b86b189a8d 100644 --- a/Documentation/devicetree/bindings/arm/mediatek.yaml +++ b/Documentation/devicetree/bindings/arm/mediatek.yaml @@ -144,6 +144,10 @@ properties: - const: google,kakadu-rev2 - const: google,kakadu - const: mediatek,mt8183 + - description: Google Kappa (HP Chromebook 11a) + items: + - const: google,kappa + - const: mediatek,mt8183 - description: Google Kodama (Lenovo 10e Chromebook Tablet) items: - enum: -- cgit v1.2.3 From 82665ef7dd65ce3b0c2e579df08f17708b728f2e Mon Sep 17 00:00:00 2001 From: Hsin-Yi Wang Date: Wed, 21 Apr 2021 17:05:53 +0800 Subject: dt-bindings: arm64: dts: mediatek: Add mt8183-kukui-jacuzzi-willow Willow is known as Acer Chromebook 311 (C722/C722T). Signed-off-by: Hsin-Yi Wang Reviewed-by: Enric Balletbo i Serra Acked-by: Rob Herring Link: https://lore.kernel.org/r/20210421090601.730744-3-hsinyi@chromium.org Signed-off-by: Matthias Brugger --- Documentation/devicetree/bindings/arm/mediatek.yaml | 7 +++++++ 1 file changed, 7 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/mediatek.yaml b/Documentation/devicetree/bindings/arm/mediatek.yaml index 81b86b189a8d..96c401597bd8 100644 --- a/Documentation/devicetree/bindings/arm/mediatek.yaml +++ b/Documentation/devicetree/bindings/arm/mediatek.yaml @@ -157,6 +157,13 @@ properties: - google,kodama-sku32 - const: google,kodama - const: mediatek,mt8183 + - description: Google Willow (Acer Chromebook 311 C722/C722T) + items: + - enum: + - google,willow-sku0 + - google,willow-sku1 + - const: google,willow + - const: mediatek,mt8183 - items: - enum: - mediatek,mt8183-pumpkin -- cgit v1.2.3 From 204c134818498985c1d235a294af5803d5cce1da Mon Sep 17 00:00:00 2001 From: Hsin-Yi Wang Date: Wed, 21 Apr 2021 17:05:54 +0800 Subject: dt-bindings: arm64: dts: mediatek: Add mt8183-kukui-jacuzzi-burnet Burnet is known as HP Chromebook x360 11MK G3 EE. Signed-off-by: Hsin-Yi Wang Reviewed-by: Enric Balletbo i Serra Acked-by: Rob Herring Link: https://lore.kernel.org/r/20210421090601.730744-4-hsinyi@chromium.org Signed-off-by: Matthias Brugger --- Documentation/devicetree/bindings/arm/mediatek.yaml | 4 ++++ 1 file changed, 4 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/mediatek.yaml b/Documentation/devicetree/bindings/arm/mediatek.yaml index 96c401597bd8..0870490aa350 100644 --- a/Documentation/devicetree/bindings/arm/mediatek.yaml +++ b/Documentation/devicetree/bindings/arm/mediatek.yaml @@ -122,6 +122,10 @@ properties: - enum: - mediatek,mt8195-evb - const: mediatek,mt8195 + - description: Google Burnet (HP Chromebook x360 11MK G3 EE) + items: + - const: google,burnet + - const: mediatek,mt8183 - description: Google Krane (Lenovo IdeaPad Duet, 10e,...) items: - enum: -- cgit v1.2.3 From ffea8b5b89f1d2ed14d84289aa48cbaef7f31a52 Mon Sep 17 00:00:00 2001 From: Hsin-Yi Wang Date: Wed, 21 Apr 2021 17:05:55 +0800 Subject: dt-bindings: arm64: dts: mediatek: Add mt8183-kukui-jacuzzi-kenzo Kenzo is known as Acer Chromebook 311. Signed-off-by: Hsin-Yi Wang Reviewed-by: Enric Balletbo i Serra Acked-by: Rob Herring Link: https://lore.kernel.org/r/20210421090601.730744-5-hsinyi@chromium.org Signed-off-by: Matthias Brugger --- Documentation/devicetree/bindings/arm/mediatek.yaml | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/mediatek.yaml b/Documentation/devicetree/bindings/arm/mediatek.yaml index 0870490aa350..7afd01aad964 100644 --- a/Documentation/devicetree/bindings/arm/mediatek.yaml +++ b/Documentation/devicetree/bindings/arm/mediatek.yaml @@ -137,9 +137,11 @@ properties: items: - const: google,damu - const: mediatek,mt8183 - - description: Google Juniper (Acer Chromebook Spin 311) + - description: Google Juniper (Acer Chromebook Spin 311) / Kenzo (Acer Chromebook 311) items: - - const: google,juniper-sku16 + - enum: + - google,juniper-sku16 + - google,juniper-sku17 - const: google,juniper - const: mediatek,mt8183 - description: Google Kakadu (ASUS Chromebook Detachable CM3) -- cgit v1.2.3 From 009add139c2e1942e49cc576ed1655f5313b5fe4 Mon Sep 17 00:00:00 2001 From: Hsin-Yi Wang Date: Wed, 21 Apr 2021 17:05:56 +0800 Subject: dt-bindings: arm64: dts: mediatek: Add mt8183-kukui-jacuzzi-fennel Fennel is known as Lenovo IdeaPad Flex 3 Chromebook. Signed-off-by: Hsin-Yi Wang Acked-by: Rob Herring Link: https://lore.kernel.org/r/20210421090601.730744-6-hsinyi@chromium.org Signed-off-by: Matthias Brugger --- Documentation/devicetree/bindings/arm/mediatek.yaml | 8 ++++++++ 1 file changed, 8 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/mediatek.yaml b/Documentation/devicetree/bindings/arm/mediatek.yaml index 7afd01aad964..80a05f6fee85 100644 --- a/Documentation/devicetree/bindings/arm/mediatek.yaml +++ b/Documentation/devicetree/bindings/arm/mediatek.yaml @@ -137,6 +137,14 @@ properties: items: - const: google,damu - const: mediatek,mt8183 + - description: Google Fennel (Lenovo IdeaPad 3 Chromebook) + items: + - enum: + - google,fennel-sku0 + - google,fennel-sku1 + - google,fennel-sku6 + - const: google,fennel + - const: mediatek,mt8183 - description: Google Juniper (Acer Chromebook Spin 311) / Kenzo (Acer Chromebook 311) items: - enum: -- cgit v1.2.3 From 15870b97c36ab7fa07d4488b0a2457c2f2da6700 Mon Sep 17 00:00:00 2001 From: Neil Armstrong Date: Mon, 19 Apr 2021 09:32:41 +0200 Subject: dt-bindings: mediatek: add mt8167 to hdmi, hdmi-ddc and cec bindings Add mt8167 SoC compatible to Mediatek hdmi, hdmi-ddc and cec schema bindings. Signed-off-by: Neil Armstrong Acked-by: Rob Herring Signed-off-by: Chun-Kuang Hu --- Documentation/devicetree/bindings/display/mediatek/mediatek,cec.yaml | 1 + .../devicetree/bindings/display/mediatek/mediatek,hdmi-ddc.yaml | 1 + Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.yaml | 1 + 3 files changed, 3 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,cec.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,cec.yaml index b38d8732d7e0..66288b9f0aa6 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,cec.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,cec.yaml @@ -17,6 +17,7 @@ properties: compatible: enum: - mediatek,mt7623-cec + - mediatek,mt8167-cec - mediatek,mt8173-cec reg: diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi-ddc.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi-ddc.yaml index c8ba94d6908b..b6fcdfb99ab2 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi-ddc.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi-ddc.yaml @@ -17,6 +17,7 @@ properties: compatible: enum: - mediatek,mt7623-hdmi-ddc + - mediatek,mt8167-hdmi-ddc - mediatek,mt8173-hdmi-ddc reg: diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.yaml index 6a144faed682..111967efa999 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.yaml @@ -19,6 +19,7 @@ properties: enum: - mediatek,mt2701-hdmi - mediatek,mt7623-hdmi + - mediatek,mt8167-hdmi - mediatek,mt8173-hdmi reg: -- cgit v1.2.3 From d91133eddb582a9a6e3c041cfbec4e1aa006b310 Mon Sep 17 00:00:00 2001 From: Geert Uytterhoeven Date: Mon, 10 May 2021 14:18:34 +0200 Subject: dt-bindings: pwm: renesas,tpu-pwm: Improve json-schema - Include the general PWM controller schema, - Make clocks, power-domains, and resets properties required. Signed-off-by: Geert Uytterhoeven Acked-by: Yoshinori Sato Link: https://lore.kernel.org/r/d36e3690ce8c5a1e53d054552e4fd8b90d6a5478.1620648868.git.geert+renesas@glider.be Signed-off-by: Rob Herring --- .../devicetree/bindings/pwm/renesas,tpu-pwm.yaml | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pwm/renesas,tpu-pwm.yaml b/Documentation/devicetree/bindings/pwm/renesas,tpu-pwm.yaml index aa9a4570c906..7c99e42ad780 100644 --- a/Documentation/devicetree/bindings/pwm/renesas,tpu-pwm.yaml +++ b/Documentation/devicetree/bindings/pwm/renesas,tpu-pwm.yaml @@ -58,6 +58,23 @@ required: - compatible - reg - '#pwm-cells' + - clocks + - power-domains + +allOf: + - $ref: pwm.yaml# + + - if: + not: + properties: + compatible: + contains: + enum: + - renesas,tpu-r8a73a4 + - renesas,tpu-r8a7740 + then: + required: + - resets additionalProperties: false -- cgit v1.2.3 From d1dd216738f54c7a29a608c33ac98ce1f41e8fda Mon Sep 17 00:00:00 2001 From: Geert Uytterhoeven Date: Mon, 10 May 2021 14:18:35 +0200 Subject: dt-bindings: timer: renesas,tpu: Convert to json-schema Convert the Renesas H8/300 Timer Pulse Unit Device Tree binding documentation to json-schema. Correct clock-names, as "peripheral_clk" is the name of the supplier, and all users use "fck". Note that there are two different bindings for the TPU, both using "renesas,tpu": this one for using the TPU as a clock source (used on H8/300), and a second use for using the TPU as a PWM controller (used on ARM). To avoid conflicts, both bindings are marked with the appropriate "select" logic, to check for the absence respectively presence of the "#pwm-cells" property. Signed-off-by: Geert Uytterhoeven Reviewed-by: Rob Herring Acked-by: Yoshinori Sato Link: https://lore.kernel.org/r/1c33e62c3a74979c3ca9580176e6cf89384caea9.1620648868.git.geert+renesas@glider.be Signed-off-by: Rob Herring --- .../devicetree/bindings/pwm/renesas,tpu-pwm.yaml | 9 ++++ .../devicetree/bindings/timer/renesas,tpu.txt | 21 -------- .../devicetree/bindings/timer/renesas,tpu.yaml | 56 ++++++++++++++++++++++ 3 files changed, 65 insertions(+), 21 deletions(-) delete mode 100644 Documentation/devicetree/bindings/timer/renesas,tpu.txt create mode 100644 Documentation/devicetree/bindings/timer/renesas,tpu.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pwm/renesas,tpu-pwm.yaml b/Documentation/devicetree/bindings/pwm/renesas,tpu-pwm.yaml index 7c99e42ad780..81ccb2110162 100644 --- a/Documentation/devicetree/bindings/pwm/renesas,tpu-pwm.yaml +++ b/Documentation/devicetree/bindings/pwm/renesas,tpu-pwm.yaml @@ -9,6 +9,15 @@ title: Renesas R-Car Timer Pulse Unit PWM Controller maintainers: - Laurent Pinchart +select: + properties: + compatible: + contains: + const: renesas,tpu + required: + - compatible + - '#pwm-cells' + properties: compatible: items: diff --git a/Documentation/devicetree/bindings/timer/renesas,tpu.txt b/Documentation/devicetree/bindings/timer/renesas,tpu.txt deleted file mode 100644 index 1d46f9de4feb..000000000000 --- a/Documentation/devicetree/bindings/timer/renesas,tpu.txt +++ /dev/null @@ -1,21 +0,0 @@ -* Renesas H8/300 Timer Pulse Unit - -The TPU is a 16bit timer/counter with configurable clock inputs and -programmable compare match. -This implementation support only cascade mode. - -Required Properties: - - - compatible: must contain "renesas,tpu" - - reg: base address and length of the registers block in 2 channel. - - clocks: a list of phandle, one for each entry in clock-names. - - clock-names: must contain "peripheral_clk" for the functional clock. - - -Example: - tpu: tpu@ffffe0 { - compatible = "renesas,tpu"; - reg = <0xffffe0 16>, <0xfffff0 12>; - clocks = <&pclk>; - clock-names = "peripheral_clk"; - }; diff --git a/Documentation/devicetree/bindings/timer/renesas,tpu.yaml b/Documentation/devicetree/bindings/timer/renesas,tpu.yaml new file mode 100644 index 000000000000..01554dff23d8 --- /dev/null +++ b/Documentation/devicetree/bindings/timer/renesas,tpu.yaml @@ -0,0 +1,56 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/timer/renesas,tpu.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Renesas H8/300 Timer Pulse Unit + +maintainers: + - Yoshinori Sato + +description: + The TPU is a 16bit timer/counter with configurable clock inputs and + programmable compare match. + This implementation supports only cascade mode. + +select: + properties: + compatible: + contains: + const: renesas,tpu + '#pwm-cells': false + required: + - compatible + +properties: + compatible: + const: renesas,tpu + + reg: + items: + - description: First channel + - description: Second channel + + clocks: + maxItems: 1 + + clock-names: + const: fck + +required: + - compatible + - reg + - clocks + - clock-names + +additionalProperties: false + +examples: + - | + tpu: tpu@ffffe0 { + compatible = "renesas,tpu"; + reg = <0xffffe0 16>, <0xfffff0 12>; + clocks = <&pclk>; + clock-names = "fck"; + }; -- cgit v1.2.3 From 52008ebd62adc4f7da2518d638555c765c63388e Mon Sep 17 00:00:00 2001 From: Liang Chen Date: Thu, 29 Apr 2021 16:11:43 +0800 Subject: dt-bindings: serial: snps-dw-apb-uart: add description for rk3568 add "rockchip,rk3568-uart", "snps,dw-apb-uart" for uart nodes on a rk3568 platform to snps-dw-apb-uart.yaml. Signed-off-by: Liang Chen Acked-by: Rob Herring Link: https://lore.kernel.org/r/20210429081151.17558-3-cl@rock-chips.com Signed-off-by: Greg Kroah-Hartman --- Documentation/devicetree/bindings/serial/snps-dw-apb-uart.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/serial/snps-dw-apb-uart.yaml b/Documentation/devicetree/bindings/serial/snps-dw-apb-uart.yaml index 87ef1e218152..97debbf68748 100644 --- a/Documentation/devicetree/bindings/serial/snps-dw-apb-uart.yaml +++ b/Documentation/devicetree/bindings/serial/snps-dw-apb-uart.yaml @@ -31,6 +31,7 @@ properties: - rockchip,rk3328-uart - rockchip,rk3368-uart - rockchip,rk3399-uart + - rockchip,rk3568-uart - rockchip,rv1108-uart - const: snps,dw-apb-uart - items: -- cgit v1.2.3 From 8f082dcf2c3dadef0fd118207d47215c917b8a1e Mon Sep 17 00:00:00 2001 From: Zhen Lei Date: Thu, 6 May 2021 21:20:48 +0800 Subject: dt-bindings: serial: Change to reference the kernel-defined serial.yaml The /schemas/serial.yaml from dt-schema only has the property $nodename, whereas the kernel-defined /schemas/serial/serial.yaml contains more useful properties, support for more complex application scenarios. For example: 1) The property "current-speed" in fsl-lx2160a.dtsi 2) The subnode "bluetooth" in hi3660-hikey960.dts Reviewed-by: Rob Herring Signed-off-by: Zhen Lei Link: https://lore.kernel.org/r/20210506132049.1513-2-thunder.leizhen@huawei.com Signed-off-by: Greg Kroah-Hartman --- Documentation/devicetree/bindings/serial/8250.yaml | 2 +- Documentation/devicetree/bindings/serial/brcm,bcm7271-uart.yaml | 2 +- Documentation/devicetree/bindings/serial/ingenic,uart.yaml | 2 +- Documentation/devicetree/bindings/serial/pl011.yaml | 4 ++-- Documentation/devicetree/bindings/serial/qca,ar9330-uart.yaml | 4 ++-- Documentation/devicetree/bindings/serial/renesas,em-uart.yaml | 2 +- Documentation/devicetree/bindings/serial/samsung_uart.yaml | 2 +- Documentation/devicetree/bindings/serial/sifive-serial.yaml | 4 ++-- Documentation/devicetree/bindings/serial/snps-dw-apb-uart.yaml | 2 +- Documentation/devicetree/bindings/serial/st,stm32-uart.yaml | 3 +-- 10 files changed, 13 insertions(+), 14 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/serial/8250.yaml b/Documentation/devicetree/bindings/serial/8250.yaml index 41f57c448621..a0bf061b80fe 100644 --- a/Documentation/devicetree/bindings/serial/8250.yaml +++ b/Documentation/devicetree/bindings/serial/8250.yaml @@ -10,7 +10,7 @@ maintainers: - devicetree@vger.kernel.org allOf: - - $ref: /schemas/serial.yaml# + - $ref: serial.yaml# - if: anyOf: - required: diff --git a/Documentation/devicetree/bindings/serial/brcm,bcm7271-uart.yaml b/Documentation/devicetree/bindings/serial/brcm,bcm7271-uart.yaml index 46c62745f901..6d176588df47 100644 --- a/Documentation/devicetree/bindings/serial/brcm,bcm7271-uart.yaml +++ b/Documentation/devicetree/bindings/serial/brcm,bcm7271-uart.yaml @@ -10,7 +10,7 @@ maintainers: - Al Cooper allOf: - - $ref: /schemas/serial.yaml# + - $ref: serial.yaml# description: |+ The Broadcom UART is based on the basic 8250 UART but with diff --git a/Documentation/devicetree/bindings/serial/ingenic,uart.yaml b/Documentation/devicetree/bindings/serial/ingenic,uart.yaml index 7748d8c3bab8..b432d4dff730 100644 --- a/Documentation/devicetree/bindings/serial/ingenic,uart.yaml +++ b/Documentation/devicetree/bindings/serial/ingenic,uart.yaml @@ -10,7 +10,7 @@ maintainers: - Paul Cercueil allOf: - - $ref: /schemas/serial.yaml# + - $ref: serial.yaml# properties: $nodename: diff --git a/Documentation/devicetree/bindings/serial/pl011.yaml b/Documentation/devicetree/bindings/serial/pl011.yaml index 1f8e9f2644b6..142187337c76 100644 --- a/Documentation/devicetree/bindings/serial/pl011.yaml +++ b/Documentation/devicetree/bindings/serial/pl011.yaml @@ -10,7 +10,7 @@ maintainers: - Rob Herring allOf: - - $ref: /schemas/serial.yaml# + - $ref: serial.yaml# # Need a custom select here or 'arm,primecell' will match on lots of nodes select: @@ -103,7 +103,7 @@ dependencies: poll-rate-ms: [ auto-poll ] poll-timeout-ms: [ auto-poll ] -additionalProperties: false +unevaluatedProperties: false examples: - | diff --git a/Documentation/devicetree/bindings/serial/qca,ar9330-uart.yaml b/Documentation/devicetree/bindings/serial/qca,ar9330-uart.yaml index a344369285b6..a644e5af12b2 100644 --- a/Documentation/devicetree/bindings/serial/qca,ar9330-uart.yaml +++ b/Documentation/devicetree/bindings/serial/qca,ar9330-uart.yaml @@ -10,7 +10,7 @@ maintainers: - Oleksij Rempel allOf: - - $ref: /schemas/serial.yaml# + - $ref: serial.yaml# properties: compatible: @@ -35,7 +35,7 @@ required: - clocks - clock-names -additionalProperties: false +unevaluatedProperties: false examples: - | diff --git a/Documentation/devicetree/bindings/serial/renesas,em-uart.yaml b/Documentation/devicetree/bindings/serial/renesas,em-uart.yaml index 82aefdb0d45e..e98ec48fee46 100644 --- a/Documentation/devicetree/bindings/serial/renesas,em-uart.yaml +++ b/Documentation/devicetree/bindings/serial/renesas,em-uart.yaml @@ -35,7 +35,7 @@ required: - clocks - clock-names -additionalProperties: false +unevaluatedProperties: false examples: - | diff --git a/Documentation/devicetree/bindings/serial/samsung_uart.yaml b/Documentation/devicetree/bindings/serial/samsung_uart.yaml index 97ec8a093bf3..0c24e7b1f15e 100644 --- a/Documentation/devicetree/bindings/serial/samsung_uart.yaml +++ b/Documentation/devicetree/bindings/serial/samsung_uart.yaml @@ -82,7 +82,7 @@ required: unevaluatedProperties: false allOf: - - $ref: /schemas/serial.yaml# + - $ref: serial.yaml# - if: properties: diff --git a/Documentation/devicetree/bindings/serial/sifive-serial.yaml b/Documentation/devicetree/bindings/serial/sifive-serial.yaml index 5fa94dacbba9..09aae43f65a7 100644 --- a/Documentation/devicetree/bindings/serial/sifive-serial.yaml +++ b/Documentation/devicetree/bindings/serial/sifive-serial.yaml @@ -12,7 +12,7 @@ maintainers: - Palmer Dabbelt allOf: - - $ref: /schemas/serial.yaml# + - $ref: serial.yaml# properties: compatible: @@ -49,7 +49,7 @@ required: - interrupts - clocks -additionalProperties: false +unevaluatedProperties: false examples: - | diff --git a/Documentation/devicetree/bindings/serial/snps-dw-apb-uart.yaml b/Documentation/devicetree/bindings/serial/snps-dw-apb-uart.yaml index 97debbf68748..88bf4adf1067 100644 --- a/Documentation/devicetree/bindings/serial/snps-dw-apb-uart.yaml +++ b/Documentation/devicetree/bindings/serial/snps-dw-apb-uart.yaml @@ -10,7 +10,7 @@ maintainers: - Rob Herring allOf: - - $ref: /schemas/serial.yaml# + - $ref: serial.yaml# properties: compatible: diff --git a/Documentation/devicetree/bindings/serial/st,stm32-uart.yaml b/Documentation/devicetree/bindings/serial/st,stm32-uart.yaml index 71a6426bc558..f50f4ca893a0 100644 --- a/Documentation/devicetree/bindings/serial/st,stm32-uart.yaml +++ b/Documentation/devicetree/bindings/serial/st,stm32-uart.yaml @@ -112,8 +112,7 @@ required: - interrupts - clocks -additionalProperties: - type: object +unevaluatedProperties: false examples: - | -- cgit v1.2.3 From e27671f66321f97b62424aebacd6d9b678b0c5be Mon Sep 17 00:00:00 2001 From: Zhen Lei Date: Thu, 6 May 2021 21:20:49 +0800 Subject: dt-bindings: serial: Add label property in serial.yaml When there is more than one serial port present, the property 'label' allows a custom name to be used for briefly describe the usage or position of each serial port. Without this "label" property, many dtbs_check warnings similar to the following are reported: arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dt.yaml: \ serial@ffd74000: Additional properties are not allowed ('label' was unexpected) From schema: Documentation/devicetree/bindings/serial/pl011.yaml Reviewed-by: Rob Herring Signed-off-by: Zhen Lei Link: https://lore.kernel.org/r/20210506132049.1513-3-thunder.leizhen@huawei.com Signed-off-by: Greg Kroah-Hartman --- Documentation/devicetree/bindings/serial/serial.yaml | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/serial/serial.yaml b/Documentation/devicetree/bindings/serial/serial.yaml index 2fdf4ed198da..c75ba3fb6465 100644 --- a/Documentation/devicetree/bindings/serial/serial.yaml +++ b/Documentation/devicetree/bindings/serial/serial.yaml @@ -23,6 +23,8 @@ properties: $nodename: pattern: "^serial(@.*)?$" + label: true + cts-gpios: maxItems: 1 description: -- cgit v1.2.3 From 6e94dbc7a4e49a028b81302d755bba1a518f973b Mon Sep 17 00:00:00 2001 From: Jiri Slaby Date: Wed, 5 May 2021 11:19:05 +0200 Subject: tty: cumulate and document tty_struct::flow* members Group the flow flags under a single struct called flow. The new struct contains 'stopped' and 'tco_stopped' bools which used to be bits in a bitfield. The struct also contains the lock protecting them to potentially share the same cache line. Note that commit c545b66c6922b (tty: Serialize tcflow() with other tty flow control changes) added a padding to the original bitfield. It was for the bitfield to occupy a whole 64b word to avoid interferring stores on Alpha (cannot we evaporate this arch with weird implications to C code yet?). But it doesn't work as expected as the padding (tty_struct::unused) is aligned to a 8B boundary too and occupies some bytes from the next word. So make it reliable by: 1) setting __aligned of the struct -- that aligns the start, and 2) making 'unsigned long unused[0]' as the last member of the struct -- pads the end. This is also the perfect time to start the documentation of tty_struct where all this lives. So we start by documenting what these bools actually serve for. And why we do all the alignment dances. Only the few up-to-date information from the Theodore's comment made it into this new Kerneldoc comment. Signed-off-by: Jiri Slaby Cc: "David S. Miller" Cc: Jakub Kicinski Cc: Jonathan Corbet Cc: Arnd Bergmann Cc: Ulf Hansson Cc: Heiko Carstens Cc: Vasily Gorbik Cc: Christian Borntraeger Cc: Shawn Guo Cc: Sascha Hauer Cc: Vineet Gupta Cc: "Maciej W. Rozycki" Link: https://lore.kernel.org/r/20210505091928.22010-13-jslaby@suse.cz Signed-off-by: Greg Kroah-Hartman --- Documentation/networking/caif/caif.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/networking/caif/caif.rst b/Documentation/networking/caif/caif.rst index 81a14373d780..d922d419c513 100644 --- a/Documentation/networking/caif/caif.rst +++ b/Documentation/networking/caif/caif.rst @@ -69,9 +69,9 @@ There are debugfs parameters provided for serial communication. - 0x01 - tty->warned is on. - 0x04 - tty->packed is on. - - 0x08 - tty->flow_stopped is on. + - 0x08 - tty->flow.tco_stopped is on. - 0x10 - tty->hw_stopped is on. - - 0x20 - tty->stopped is on. + - 0x20 - tty->flow.stopped is on. * last_tx_msg: Binary blob Prints the last transmitted frame. -- cgit v1.2.3 From 3e42d1de020805ff3f7d854e1cff742d14e158f5 Mon Sep 17 00:00:00 2001 From: Carlos Bilbao Date: Thu, 13 May 2021 09:31:10 -0400 Subject: docs: typo fixes in Documentation/ABI/ Fix the following typos in the Documentation/ABI/ directory: - In file obsolete/sysfs-cpuidle, change "obselete" for "obsolete". - In file removed/sysfs-kernel-uids, change "propotional" for "proportional". - In directory stable/, fix the following words: "associtated" for "associated", "hexidecimal" for "hexadecimal", "vlue" for "value", "csed" for "caused" and "wrtie" for "write". This updates a total of five files. - In directory testing/, fix the following words: "subystem" for "subsystem", "isochrnous" for "isochronous", "Desctiptors" for "Descriptors", "picutre" for "picture", "capture" for "capture", "occured" for "ocurred", "connnected" for "connected","agressively" for "aggressively","manufacturee" for "manufacturer" and "transaction" for "transaction", "malformatted" for "incorrectly formated" ,"internel" for "internal", "writtento" for "written to", "specificed" for "specified", "beyound" for "beyond", "Symetric" for "Symmetric". This updates a total of eleven files. Signed-off-by: Carlos Bilbao Reviewed-by: Randy Dunlap Reviewed-by: Mauro Carvalho Chehab Link: https://lore.kernel.org/r/5710038.lOV4Wx5bFT@iron-maiden Signed-off-by: Jonathan Corbet --- Documentation/ABI/obsolete/sysfs-cpuidle | 2 +- Documentation/ABI/removed/sysfs-kernel-uids | 2 +- Documentation/ABI/stable/sysfs-bus-vmbus | 2 +- Documentation/ABI/stable/sysfs-bus-xen-backend | 2 +- Documentation/ABI/stable/sysfs-driver-dma-idxd | 2 +- Documentation/ABI/stable/sysfs-driver-mlxreg-io | 4 ++-- Documentation/ABI/testing/configfs-iio | 2 +- Documentation/ABI/testing/configfs-most | 8 ++++---- Documentation/ABI/testing/configfs-usb-gadget | 2 +- Documentation/ABI/testing/configfs-usb-gadget-uvc | 4 ++-- Documentation/ABI/testing/debugfs-driver-genwqe | 2 +- Documentation/ABI/testing/debugfs-driver-habanalabs | 2 +- Documentation/ABI/testing/sysfs-bus-fsi | 2 +- Documentation/ABI/testing/sysfs-bus-pci | 4 ++-- Documentation/ABI/testing/sysfs-devices-system-cpu | 10 +++++----- Documentation/ABI/testing/sysfs-driver-ufs | 4 ++-- Documentation/ABI/testing/sysfs-fs-f2fs | 2 +- 17 files changed, 28 insertions(+), 28 deletions(-) (limited to 'Documentation') diff --git a/Documentation/ABI/obsolete/sysfs-cpuidle b/Documentation/ABI/obsolete/sysfs-cpuidle index e398fb5e542f..972cc11d3434 100644 --- a/Documentation/ABI/obsolete/sysfs-cpuidle +++ b/Documentation/ABI/obsolete/sysfs-cpuidle @@ -6,4 +6,4 @@ Description: with the update that cpuidle governor can be changed at runtime in default, both current_governor and current_governor_ro co-exist under /sys/devices/system/cpu/cpuidle/ file, it's duplicate so make - current_governor_ro obselete. + current_governor_ro obsolete. diff --git a/Documentation/ABI/removed/sysfs-kernel-uids b/Documentation/ABI/removed/sysfs-kernel-uids index dc4463f190a7..85a90b86ce1e 100644 --- a/Documentation/ABI/removed/sysfs-kernel-uids +++ b/Documentation/ABI/removed/sysfs-kernel-uids @@ -5,7 +5,7 @@ Contact: Dhaval Giani Description: The /sys/kernel/uids//cpu_shares tunable is used to set the cpu bandwidth a user is allowed. This is a - propotional value. What that means is that if there + proportional value. What that means is that if there are two users logged in, each with an equal number of shares, then they will get equal CPU bandwidth. Another example would be, if User A has shares = 1024 and user diff --git a/Documentation/ABI/stable/sysfs-bus-vmbus b/Documentation/ABI/stable/sysfs-bus-vmbus index 42599d9fa161..3066feae1d8d 100644 --- a/Documentation/ABI/stable/sysfs-bus-vmbus +++ b/Documentation/ABI/stable/sysfs-bus-vmbus @@ -61,7 +61,7 @@ Date: September. 2017 KernelVersion: 4.14 Contact: Stephen Hemminger Description: Directory for per-channel information - NN is the VMBUS relid associtated with the channel. + NN is the VMBUS relid associated with the channel. What: /sys/bus/vmbus/devices//channels//cpu Date: September. 2017 diff --git a/Documentation/ABI/stable/sysfs-bus-xen-backend b/Documentation/ABI/stable/sysfs-bus-xen-backend index e8b60bd766f7..480a89edfa05 100644 --- a/Documentation/ABI/stable/sysfs-bus-xen-backend +++ b/Documentation/ABI/stable/sysfs-bus-xen-backend @@ -19,7 +19,7 @@ Date: April 2011 KernelVersion: 3.0 Contact: Konrad Rzeszutek Wilk Description: - The major:minor number (in hexidecimal) of the + The major:minor number (in hexadecimal) of the physical device providing the storage for this backend block device. diff --git a/Documentation/ABI/stable/sysfs-driver-dma-idxd b/Documentation/ABI/stable/sysfs-driver-dma-idxd index 55285c136cf0..d431e2d00472 100644 --- a/Documentation/ABI/stable/sysfs-driver-dma-idxd +++ b/Documentation/ABI/stable/sysfs-driver-dma-idxd @@ -173,7 +173,7 @@ What: /sys/bus/dsa/devices/wq./priority Date: Oct 25, 2019 KernelVersion: 5.6.0 Contact: dmaengine@vger.kernel.org -Description: The priority value of this work queue, it is a vlue relative to +Description: The priority value of this work queue, it is a value relative to other work queue in the same group to control quality of service for dispatching work from multiple workqueues in the same group. diff --git a/Documentation/ABI/stable/sysfs-driver-mlxreg-io b/Documentation/ABI/stable/sysfs-driver-mlxreg-io index fd9a8045bb0c..b2553df2e786 100644 --- a/Documentation/ABI/stable/sysfs-driver-mlxreg-io +++ b/Documentation/ABI/stable/sysfs-driver-mlxreg-io @@ -137,7 +137,7 @@ Contact: Vadim Pasternak Description: These files show the system reset cause, as following: COMEX thermal shutdown; wathchdog power off or reset was derived by one of the next components: COMEX, switch board or by Small Form - Factor mezzanine, reset requested from ASIC, reset cuased by BIOS + Factor mezzanine, reset requested from ASIC, reset caused by BIOS reload. Value 1 in file means this is reset cause, 0 - otherwise. Only one of the above causes could be 1 at the same time, representing only last reset cause. @@ -183,7 +183,7 @@ What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/vpd_wp Date: January 2020 KernelVersion: 5.6 Contact: Vadim Pasternak -Description: This file allows to overwrite system VPD hardware wrtie +Description: This file allows to overwrite system VPD hardware write protection when attribute is set 1. The file is read/write. diff --git a/Documentation/ABI/testing/configfs-iio b/Documentation/ABI/testing/configfs-iio index aebda53ec0f7..1637fcb50f56 100644 --- a/Documentation/ABI/testing/configfs-iio +++ b/Documentation/ABI/testing/configfs-iio @@ -31,4 +31,4 @@ Date: April 2016 KernelVersion: 4.7 Description: Dummy IIO devices directory. Creating a directory here will result - in creating a dummy IIO device in the IIO subystem. + in creating a dummy IIO device in the IIO subsystem. diff --git a/Documentation/ABI/testing/configfs-most b/Documentation/ABI/testing/configfs-most index bc6b8bd18da4..0a4b8649aa5a 100644 --- a/Documentation/ABI/testing/configfs-most +++ b/Documentation/ABI/testing/configfs-most @@ -20,7 +20,7 @@ Description: subbuffer_size configure the sub-buffer size for this channel - (needed for synchronous and isochrnous data) + (needed for synchronous and isochronous data) num_buffers @@ -75,7 +75,7 @@ Description: subbuffer_size configure the sub-buffer size for this channel - (needed for synchronous and isochrnous data) + (needed for synchronous and isochronous data) num_buffers @@ -130,7 +130,7 @@ Description: subbuffer_size configure the sub-buffer size for this channel - (needed for synchronous and isochrnous data) + (needed for synchronous and isochronous data) num_buffers @@ -196,7 +196,7 @@ Description: subbuffer_size configure the sub-buffer size for this channel - (needed for synchronous and isochrnous data) + (needed for synchronous and isochronous data) num_buffers diff --git a/Documentation/ABI/testing/configfs-usb-gadget b/Documentation/ABI/testing/configfs-usb-gadget index dc351e9af80a..b7943aa7e997 100644 --- a/Documentation/ABI/testing/configfs-usb-gadget +++ b/Documentation/ABI/testing/configfs-usb-gadget @@ -137,7 +137,7 @@ Description: This group contains "OS String" extension handling attributes. ============= =============================================== - use flag turning "OS Desctiptors" support on/off + use flag turning "OS Descriptors" support on/off b_vendor_code one-byte value used for custom per-device and per-interface requests qw_sign an identifier to be reported as "OS String" diff --git a/Documentation/ABI/testing/configfs-usb-gadget-uvc b/Documentation/ABI/testing/configfs-usb-gadget-uvc index ac5e11af79a8..889ed45be4ca 100644 --- a/Documentation/ABI/testing/configfs-usb-gadget-uvc +++ b/Documentation/ABI/testing/configfs-usb-gadget-uvc @@ -170,7 +170,7 @@ Description: Default color matching descriptors bMatrixCoefficients matrix used to compute luma and chroma values from the color primaries bTransferCharacteristics optoelectronic transfer - characteristic of the source picutre, + characteristic of the source picture, also called the gamma function bColorPrimaries color primaries and the reference white @@ -311,7 +311,7 @@ Description: Specific streaming header descriptors a hardware trigger interrupt event bTriggerSupport flag specifying if hardware triggering is supported - bStillCaptureMethod method of still image caputre + bStillCaptureMethod method of still image capture supported bTerminalLink id of the output terminal to which the video endpoint of this interface diff --git a/Documentation/ABI/testing/debugfs-driver-genwqe b/Documentation/ABI/testing/debugfs-driver-genwqe index 1c2f25674e8c..b45b016545d8 100644 --- a/Documentation/ABI/testing/debugfs-driver-genwqe +++ b/Documentation/ABI/testing/debugfs-driver-genwqe @@ -31,7 +31,7 @@ What: /sys/kernel/debug/genwqe/genwqe_card/prev_regs Date: Oct 2013 Contact: haver@linux.vnet.ibm.com Description: Dump of the error registers before the last reset of - the card occured. + the card occurred. Only available for PF. What: /sys/kernel/debug/genwqe/genwqe_card/prev_dbg_uid0 diff --git a/Documentation/ABI/testing/debugfs-driver-habanalabs b/Documentation/ABI/testing/debugfs-driver-habanalabs index c78fc9282876..e89c6351503c 100644 --- a/Documentation/ABI/testing/debugfs-driver-habanalabs +++ b/Documentation/ABI/testing/debugfs-driver-habanalabs @@ -153,7 +153,7 @@ KernelVersion: 5.1 Contact: ogabbay@kernel.org Description: Triggers an I2C transaction that is generated by the device's CPU. Writing to this file generates a write transaction while - reading from the file generates a read transcation + reading from the file generates a read transaction What: /sys/kernel/debug/habanalabs/hl/i2c_reg Date: Jan 2019 diff --git a/Documentation/ABI/testing/sysfs-bus-fsi b/Documentation/ABI/testing/sysfs-bus-fsi index d148214181a1..76e0caa0c2b3 100644 --- a/Documentation/ABI/testing/sysfs-bus-fsi +++ b/Documentation/ABI/testing/sysfs-bus-fsi @@ -12,7 +12,7 @@ KernelVersion: 4.12 Contact: linux-fsi@lists.ozlabs.org Description: Sends an FSI BREAK command on a master's communication - link to any connnected slaves. A BREAK resets connected + link to any connected slaves. A BREAK resets connected device's logic and preps it to receive further commands from the master. diff --git a/Documentation/ABI/testing/sysfs-bus-pci b/Documentation/ABI/testing/sysfs-bus-pci index ef00fada2efb..793cbb76cd25 100644 --- a/Documentation/ABI/testing/sysfs-bus-pci +++ b/Documentation/ABI/testing/sysfs-bus-pci @@ -139,8 +139,8 @@ Description: binary file containing the Vital Product Data for the device. It should follow the VPD format defined in PCI Specification 2.1 or 2.2, but users should consider - that some devices may have malformatted data. If the - underlying VPD has a writable section then the + that some devices may have incorrectly formatted data. + If the underlying VPD has a writable section then the corresponding section of this file will be writable. What: /sys/bus/pci/devices/.../virtfnN diff --git a/Documentation/ABI/testing/sysfs-devices-system-cpu b/Documentation/ABI/testing/sysfs-devices-system-cpu index fe13baa53c59..160b10c029c0 100644 --- a/Documentation/ABI/testing/sysfs-devices-system-cpu +++ b/Documentation/ABI/testing/sysfs-devices-system-cpu @@ -50,7 +50,7 @@ Description: Dynamic addition and removal of CPU's. This is not hotplug architecture specific. release: writes to this file dynamically remove a CPU from - the system. Information writtento the file to remove CPU's + the system. Information written to the file to remove CPU's is architecture specific. What: /sys/devices/system/cpu/cpu#/node @@ -97,7 +97,7 @@ Description: CPU topology files that describe a logical CPU's relationship corresponds to a physical socket number, but the actual value is architecture and platform dependent. - thread_siblings: internel kernel map of cpu#'s hardware + thread_siblings: internal kernel map of cpu#'s hardware threads within the same core as cpu# thread_siblings_list: human-readable list of cpu#'s hardware @@ -280,7 +280,7 @@ Description: Disable L3 cache indices on a processor with this functionality will return the currently disabled index for that node. There is one L3 structure per node, or per internal node on MCM machines. Writing a valid - index to one of these files will cause the specificed cache + index to one of these files will cause the specified cache index to be disabled. All AMD processors with L3 caches provide this functionality. @@ -295,7 +295,7 @@ 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. + beyond it's nominal limit. More details can be found in Documentation/admin-guide/pm/cpufreq.rst @@ -532,7 +532,7 @@ What: /sys/devices/system/cpu/smt /sys/devices/system/cpu/smt/control Date: June 2018 Contact: Linux kernel mailing list -Description: Control Symetric Multi Threading (SMT) +Description: Control Symmetric Multi Threading (SMT) active: Tells whether SMT is active (enabled and siblings online) diff --git a/Documentation/ABI/testing/sysfs-driver-ufs b/Documentation/ABI/testing/sysfs-driver-ufs index d1bc23cb6a9d..eaac6898f0c0 100644 --- a/Documentation/ABI/testing/sysfs-driver-ufs +++ b/Documentation/ABI/testing/sysfs-driver-ufs @@ -168,7 +168,7 @@ Description: This file shows the manufacturing date in BCD format. What: /sys/bus/platform/drivers/ufshcd/*/device_descriptor/manufacturer_id Date: February 2018 Contact: Stanislav Nijnikov -Description: This file shows the manufacturee ID. This is one of the +Description: This file shows the manufacturer ID. This is one of the UFS device descriptor parameters. The full information about the descriptor could be found at UFS specifications 2.1. @@ -521,7 +521,7 @@ Description: This file shows maximum VCC, VCCQ and VCCQ2 value for What: /sys/bus/platform/drivers/ufshcd/*/string_descriptors/manufacturer_name Date: February 2018 Contact: Stanislav Nijnikov -Description: This file contains a device manufactureer name string. +Description: This file contains a device manufacturer name string. The full information about the descriptor could be found at UFS specifications 2.1. diff --git a/Documentation/ABI/testing/sysfs-fs-f2fs b/Documentation/ABI/testing/sysfs-fs-f2fs index 4849b8e84e42..5d9ae27bd462 100644 --- a/Documentation/ABI/testing/sysfs-fs-f2fs +++ b/Documentation/ABI/testing/sysfs-fs-f2fs @@ -238,7 +238,7 @@ Description: Shows current reserved blocks in system, it may be temporarily What: /sys/fs/f2fs//gc_urgent Date: August 2017 Contact: "Jaegeuk Kim" -Description: Do background GC agressively when set. When gc_urgent = 1, +Description: Do background GC aggressively when set. When gc_urgent = 1, background thread starts to do GC by given gc_urgent_sleep_time interval. When gc_urgent = 2, F2FS will lower the bar of checking idle in order to process outstanding discard commands -- cgit v1.2.3 From a5afc7605b2ae7fb95be9b94e85179bc4c8aaee4 Mon Sep 17 00:00:00 2001 From: Sebastian Reichel Date: Tue, 13 Apr 2021 01:03:18 +0200 Subject: dt-bindings: power: supply: charger-manager: Convert to DT schema format Convert the binding to DT schema format. I slightly modified the binding by allowing regulator-[0-9] and cable-[0-9] instead of regulator@[0-9] and cable@[0-9], so that DT compiler does not complain about missing 'reg' property. The driver actually ignores the nodename and can handle both styles. Signed-off-by: Sebastian Reichel Reviewed-by: Rob Herring Signed-off-by: Sebastian Reichel --- .../bindings/power/supply/charger-manager.txt | 91 --------- .../bindings/power/supply/charger-manager.yaml | 215 +++++++++++++++++++++ 2 files changed, 215 insertions(+), 91 deletions(-) delete mode 100644 Documentation/devicetree/bindings/power/supply/charger-manager.txt create mode 100644 Documentation/devicetree/bindings/power/supply/charger-manager.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/power/supply/charger-manager.txt b/Documentation/devicetree/bindings/power/supply/charger-manager.txt deleted file mode 100644 index b5ae9061b7a0..000000000000 --- a/Documentation/devicetree/bindings/power/supply/charger-manager.txt +++ /dev/null @@ -1,91 +0,0 @@ -charger-manager bindings -~~~~~~~~~~~~~~~~~~~~~~~~ - -Required properties : - - compatible : "charger-manager" - - <>-supply : for regulator consumer, named according to cm-regulator-name - - cm-chargers : name of chargers - - cm-fuel-gauge : name of battery fuel gauge - - subnode : - - cm-regulator-name : name of charger regulator - - subnode : - - cm-cable-name : name of charger cable - one of USB, USB-HOST, - SDP, DCP, CDP, ACA, FAST-CHARGER, SLOW-CHARGER, WPT, - PD, DOCK, JIG, or MECHANICAL - - cm-cable-extcon : name of extcon dev -(optional) - cm-cable-min : minimum current of cable -(optional) - cm-cable-max : maximum current of cable - -Optional properties : - - cm-name : charger manager's name (default : "battery") - - cm-poll-mode : polling mode - 0 for disabled, 1 for always, 2 for when - external power is connected, or 3 for when charging. If not present, - then polling is disabled - - cm-poll-interval : polling interval (in ms) - - cm-battery-stat : battery status - 0 for battery always present, 1 for no - battery, 2 to check presence via fuel gauge, or 3 to check presence - via charger - - cm-fullbatt-vchkdrop-volt : voltage drop (in uV) before restarting charging - - cm-fullbatt-voltage : voltage (in uV) of full battery - - cm-fullbatt-soc : state of charge to consider as full battery - - cm-fullbatt-capacity : capcity (in uAh) to consider as full battery - - cm-thermal-zone : name of external thermometer's thermal zone - - cm-battery-* : threshold battery temperature for charging - -cold : critical cold temperature of battery for charging - -cold-in-minus : flag that cold temperature is in minus degrees - -hot : critical hot temperature of battery for charging - -temp-diff : temperature difference to allow recharging - - cm-dis/charging-max = limits of charging duration - -Deprecated properties: - - cm-num-chargers - - cm-fullbatt-vchkdrop-ms - -Example : - charger-manager@0 { - compatible = "charger-manager"; - chg-reg-supply = <&charger_regulator>; - - cm-name = "battery"; - /* Always polling ON : 30s */ - cm-poll-mode = <1>; - cm-poll-interval = <30000>; - - cm-fullbatt-vchkdrop-volt = <150000>; - cm-fullbatt-soc = <100>; - - cm-battery-stat = <3>; - - cm-chargers = "charger0", "charger1", "charger2"; - - cm-fuel-gauge = "fuelgauge0"; - - cm-thermal-zone = "thermal_zone.1" - /* in deci centigrade */ - cm-battery-cold = <50>; - cm-battery-cold-in-minus; - cm-battery-hot = <800>; - cm-battery-temp-diff = <100>; - - /* Allow charging for 5hr */ - cm-charging-max = <18000000>; - /* Allow discharging for 2hr */ - cm-discharging-max = <7200000>; - - regulator@0 { - cm-regulator-name = "chg-reg"; - cable@0 { - cm-cable-name = "USB"; - cm-cable-extcon = "extcon-dev.0"; - cm-cable-min = <475000>; - cm-cable-max = <500000>; - }; - cable@1 { - cm-cable-name = "SDP"; - cm-cable-extcon = "extcon-dev.0"; - cm-cable-min = <650000>; - cm-cable-max = <675000>; - }; - }; - - }; diff --git a/Documentation/devicetree/bindings/power/supply/charger-manager.yaml b/Documentation/devicetree/bindings/power/supply/charger-manager.yaml new file mode 100644 index 000000000000..c863cfa67865 --- /dev/null +++ b/Documentation/devicetree/bindings/power/supply/charger-manager.yaml @@ -0,0 +1,215 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/power/supply/charger-manager.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Charger Manager + +maintainers: + - Sebastian Reichel + +description: | + Binding for the legacy charger manager driver. + Please do not use for new products. + +properties: + compatible: + const: charger-manager + + cm-chargers: + description: name of chargers + $ref: /schemas/types.yaml#/definitions/string-array + + cm-num-chargers: + $ref: /schemas/types.yaml#/definitions/uint32 + deprecated: true + + cm-fuel-gauge: + description: name of battery fuel gauge + $ref: /schemas/types.yaml#/definitions/string + + cm-name: + description: name of the charger manager + default: battery + $ref: /schemas/types.yaml#/definitions/string + + cm-poll-mode: + description: polling mode + default: 0 + enum: + - 0 # disabled + - 1 # always + - 2 # when external power is connected + - 3 # when charging + + cm-poll-interval: + description: polling interval (in ms) + $ref: /schemas/types.yaml#/definitions/uint32 + + cm-battery-stat: + description: battery status + enum: + - 0 # battery always present + - 1 # no battery + - 2 # check presence via fuel gauge + - 3 # check presence via charger + + cm-fullbatt-vchkdrop-volt: + description: voltage drop before restarting charging in uV + $ref: /schemas/types.yaml#/definitions/uint32 + + cm-fullbatt-vchkdrop-ms: + deprecated: true + + cm-fullbatt-voltage: + description: voltage of full battery in uV + $ref: /schemas/types.yaml#/definitions/uint32 + + cm-fullbatt-soc: + description: state of charge to consider as full battery in % + $ref: /schemas/types.yaml#/definitions/uint32 + + cm-fullbatt-capacity: + description: capcity to consider as full battery in uAh + $ref: /schemas/types.yaml#/definitions/uint32 + + cm-thermal-zone: + description: name of external thermometer's thermal zone + $ref: /schemas/types.yaml#/definitions/string + + cm-discharging-max: + description: limits of discharging duration in ms + $ref: /schemas/types.yaml#/definitions/uint32 + + cm-charging-max: + description: limits of charging duration in ms + $ref: /schemas/types.yaml#/definitions/uint32 + + cm-battery-cold: + description: critical cold temperature of battery for charging in deci-degree celsius + $ref: /schemas/types.yaml#/definitions/uint32 + + cm-battery-cold-in-minus: + description: if set cm-battery-cold temperature is in minus degrees + type: boolean + + cm-battery-hot: + description: critical hot temperature of battery for charging in deci-degree celsius + $ref: /schemas/types.yaml#/definitions/uint32 + + cm-battery-temp-diff: + description: temperature difference to allow recharging in deci-degree celsius + $ref: /schemas/types.yaml#/definitions/uint32 + +patternProperties: + "-supply$": + description: regulator consumer, named according to cm-regulator-name + $ref: /schemas/types.yaml#/definitions/phandle + + "^regulator[@-][0-9]$": + type: object + properties: + cm-regulator-name: + description: name of charger regulator + $ref: /schemas/types.yaml#/definitions/string + + required: + - cm-regulator-name + + additionalProperties: false + + patternProperties: + "^cable[@-][0-9]$": + type: object + properties: + cm-cable-name: + description: name of charger cable + enum: + - USB + - USB-HOST + - SDP + - DCP + - CDP + - ACA + - FAST-CHARGER + - SLOW-CHARGER + - WPT + - PD + - DOCK + - JIG + - MECHANICAL + + cm-cable-extcon: + description: name of extcon dev + $ref: /schemas/types.yaml#/definitions/string + + cm-cable-min: + description: minimum current of cable in uA + $ref: /schemas/types.yaml#/definitions/uint32 + + cm-cable-max: + description: maximum current of cable in uA + $ref: /schemas/types.yaml#/definitions/uint32 + + required: + - cm-cable-name + - cm-cable-extcon + + additionalProperties: false + +required: + - compatible + - cm-chargers + - cm-fuel-gauge + +additionalProperties: false + +examples: + - | + charger-manager { + compatible = "charger-manager"; + chg-reg-supply = <&charger_regulator>; + + cm-name = "battery"; + /* Always polling ON : 30s */ + cm-poll-mode = <1>; + cm-poll-interval = <30000>; + + cm-fullbatt-vchkdrop-volt = <150000>; + cm-fullbatt-soc = <100>; + + cm-battery-stat = <3>; + + cm-chargers = "charger0", "charger1", "charger2"; + + cm-fuel-gauge = "fuelgauge0"; + + cm-thermal-zone = "thermal_zone.1"; + /* in deci centigrade */ + cm-battery-cold = <50>; + cm-battery-cold-in-minus; + cm-battery-hot = <800>; + cm-battery-temp-diff = <100>; + + /* Allow charging for 5hr */ + cm-charging-max = <18000000>; + /* Allow discharging for 2hr */ + cm-discharging-max = <7200000>; + + regulator-0 { + cm-regulator-name = "chg-reg"; + cable-0 { + cm-cable-name = "USB"; + cm-cable-extcon = "extcon-dev.0"; + cm-cable-min = <475000>; + cm-cable-max = <500000>; + }; + cable-1 { + cm-cable-name = "SDP"; + cm-cable-extcon = "extcon-dev.0"; + cm-cable-min = <650000>; + cm-cable-max = <675000>; + }; + }; + }; -- cgit v1.2.3 From 1e886090cefe26113122a7d59a36a9aec492fef5 Mon Sep 17 00:00:00 2001 From: Rasmus Villemoes Date: Tue, 20 Apr 2021 14:06:38 +0200 Subject: docs: admin-guide: update description for kernel.hotplug sysctl It's been a few releases since this defaulted to /sbin/hotplug. Update the text, and include pointers to the two CONFIG_UEVENT_HELPER{,_PATH} config knobs whose help text could provide more info, but also hint that the user probably doesn't need to care at all. Fixes: 7934779a69f1 ("Driver-Core: disable /sbin/hotplug by default") Signed-off-by: Rasmus Villemoes Link: https://lore.kernel.org/r/20210420120638.1104016-1-linux@rasmusvillemoes.dk Signed-off-by: Jonathan Corbet --- Documentation/admin-guide/sysctl/kernel.rst | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/admin-guide/sysctl/kernel.rst b/Documentation/admin-guide/sysctl/kernel.rst index 1d56a6b73a4e..c24f57f2c782 100644 --- a/Documentation/admin-guide/sysctl/kernel.rst +++ b/Documentation/admin-guide/sysctl/kernel.rst @@ -333,7 +333,12 @@ hotplug ======= Path for the hotplug policy agent. -Default value is "``/sbin/hotplug``". +Default value is ``CONFIG_UEVENT_HELPER_PATH``, which in turn defaults +to the empty string. + +This file only exists when ``CONFIG_UEVENT_HELPER`` is enabled. Most +modern systems rely exclusively on the netlink-based uevent source and +don't need this. hung_task_all_cpu_backtrace -- cgit v1.2.3 From 2c5ff2caa4f8164e93a9bf035af9a2ad87cad9f2 Mon Sep 17 00:00:00 2001 From: Wei Ming Chen Date: Thu, 6 May 2021 20:20:20 +0800 Subject: docs: usb: function: Modify path name Original path does not exists, so changed to "Documentation/ABI/testing/configfs-usb-gadget" Signed-off-by: Wei Ming Chen Link: https://lore.kernel.org/r/20210506122020.7117-1-jj251510319013@gmail.com Signed-off-by: Jonathan Corbet --- Documentation/usb/gadget_configfs.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/usb/gadget_configfs.rst b/Documentation/usb/gadget_configfs.rst index 158e48dab586..e4566ffb223f 100644 --- a/Documentation/usb/gadget_configfs.rst +++ b/Documentation/usb/gadget_configfs.rst @@ -140,7 +140,7 @@ is an arbitrary string allowed in a filesystem, e.g.:: Each function provides its specific set of attributes, with either read-only or read-write access. Where applicable they need to be written to as appropriate. -Please refer to Documentation/ABI/*/configfs-usb-gadget* for more information. +Please refer to Documentation/ABI/testing/configfs-usb-gadget for more information. 4. Associating the functions with their configurations ------------------------------------------------------ -- cgit v1.2.3 From 8a981128a81e1cec66c43784f01938953dccac88 Mon Sep 17 00:00:00 2001 From: Geert Uytterhoeven Date: Mon, 10 May 2021 14:10:40 +0200 Subject: dt-bindings: phy: renesas,rcar-gen3-pcie-phy: Convert to json-schema Convert the Renesas R-Car Gen3 PCIe PHY Device Tree binding documentation to json-schema. Update the example to match reality. Signed-off-by: Geert Uytterhoeven Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/0301c3a7dae9afde115b6437a11c23ab85cb8b75.1620648490.git.geert+renesas@glider.be Signed-off-by: Vinod Koul --- .../devicetree/bindings/phy/rcar-gen3-phy-pcie.txt | 24 ---------- .../bindings/phy/renesas,rcar-gen3-pcie-phy.yaml | 53 ++++++++++++++++++++++ 2 files changed, 53 insertions(+), 24 deletions(-) delete mode 100644 Documentation/devicetree/bindings/phy/rcar-gen3-phy-pcie.txt create mode 100644 Documentation/devicetree/bindings/phy/renesas,rcar-gen3-pcie-phy.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/phy/rcar-gen3-phy-pcie.txt b/Documentation/devicetree/bindings/phy/rcar-gen3-phy-pcie.txt deleted file mode 100644 index 63853b35e083..000000000000 --- a/Documentation/devicetree/bindings/phy/rcar-gen3-phy-pcie.txt +++ /dev/null @@ -1,24 +0,0 @@ -* Renesas R-Car generation 3 PCIe PHY - -This file provides information on what the device node for the R-Car -generation 3 PCIe PHY contains. - -Required properties: -- compatible: "renesas,r8a77980-pcie-phy" if the device is a part of the - R8A77980 SoC. -- reg: offset and length of the register block. -- clocks: clock phandle and specifier pair. -- power-domains: power domain phandle and specifier pair. -- resets: reset phandle and specifier pair. -- #phy-cells: see phy-bindings.txt in the same directory, must be <0>. - -Example (R-Car V3H): - - pcie-phy@e65d0000 { - compatible = "renesas,r8a77980-pcie-phy"; - reg = <0 0xe65d0000 0 0x8000>; - #phy-cells = <0>; - clocks = <&cpg CPG_MOD 319>; - power-domains = <&sysc 32>; - resets = <&cpg 319>; - }; diff --git a/Documentation/devicetree/bindings/phy/renesas,rcar-gen3-pcie-phy.yaml b/Documentation/devicetree/bindings/phy/renesas,rcar-gen3-pcie-phy.yaml new file mode 100644 index 000000000000..247ef7c47cf5 --- /dev/null +++ b/Documentation/devicetree/bindings/phy/renesas,rcar-gen3-pcie-phy.yaml @@ -0,0 +1,53 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/phy/renesas,rcar-gen3-pcie-phy.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Renesas R-Car Generation 3 PCIe PHY + +maintainers: + - Sergei Shtylyov + +properties: + compatible: + const: renesas,r8a77980-pcie-phy + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + + power-domains: + maxItems: 1 + + resets: + maxItems: 1 + + '#phy-cells': + const: 0 + +required: + - compatible + - reg + - clocks + - power-domains + - resets + - '#phy-cells' + +additionalProperties: false + +examples: + - | + #include + #include + + pcie-phy@e65d0000 { + compatible = "renesas,r8a77980-pcie-phy"; + reg = <0xe65d0000 0x8000>; + #phy-cells = <0>; + clocks = <&cpg CPG_MOD 319>; + power-domains = <&sysc R8A77980_PD_ALWAYS_ON>; + resets = <&cpg 319>; + }; -- cgit v1.2.3 From 77945a345acfc32b8c1aadf470b55d6a4aa8e01e Mon Sep 17 00:00:00 2001 From: Sergio Paracuellos Date: Sat, 8 May 2021 09:09:26 +0200 Subject: dt-bindings: phy: mediatek,mt7621-pci-phy: add clock entries MT7621 SoC clock driver has already mainlined in 'commit 48df7a26f470 ("clk: ralink: add clock driver for mt7621 SoC")' Hence update schema with the add of the entries related to clock. Since until now things were not properly being done we mark also 'clock' as required in the binding since this will be now the only way to properly retrieve frequency to be able to make a correct configuration of the PCIe phy registers. Signed-off-by: Sergio Paracuellos Acked-by: Rob Herring Link: https://lore.kernel.org/r/20210508070930.5290-3-sergio.paracuellos@gmail.com Signed-off-by: Vinod Koul --- Documentation/devicetree/bindings/phy/mediatek,mt7621-pci-phy.yaml | 5 +++++ 1 file changed, 5 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/phy/mediatek,mt7621-pci-phy.yaml b/Documentation/devicetree/bindings/phy/mediatek,mt7621-pci-phy.yaml index 0ccaded3f245..29d4123323c2 100644 --- a/Documentation/devicetree/bindings/phy/mediatek,mt7621-pci-phy.yaml +++ b/Documentation/devicetree/bindings/phy/mediatek,mt7621-pci-phy.yaml @@ -16,6 +16,9 @@ properties: reg: maxItems: 1 + clocks: + maxItems: 1 + "#phy-cells": const: 1 description: selects if the phy is dual-ported @@ -23,6 +26,7 @@ properties: required: - compatible - reg + - clocks - "#phy-cells" additionalProperties: false @@ -32,5 +36,6 @@ examples: pcie0_phy: pcie-phy@1e149000 { compatible = "mediatek,mt7621-pci-phy"; reg = <0x1e149000 0x0700>; + clocks = <&sysc 0>; #phy-cells = <1>; }; -- cgit v1.2.3 From 46eba71a1d1537cc3f7bb5652cc72509504b1b4c Mon Sep 17 00:00:00 2001 From: Baruch Siach Date: Wed, 5 May 2021 12:18:33 +0300 Subject: dt-bindings: phy: qcom,qmp: Add IPQ60xx PCIe PHY bindings Add ipq6018 qmp phy device for the single PCIe serdes lane on IPQ60xx SoCs. Reviewed-by: Rob Herring Signed-off-by: Baruch Siach Link: https://lore.kernel.org/r/be83d8580942ab9d141dffff4e4f33f34a4c9ed9.1620203062.git.baruch@tkos.co.il Signed-off-by: Vinod Koul --- .../devicetree/bindings/phy/qcom,qmp-phy.yaml | 25 ++++++++++++++++++++++ 1 file changed, 25 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/phy/qcom,qmp-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,qmp-phy.yaml index 7808ec8bc712..b8e1a33fd0df 100644 --- a/Documentation/devicetree/bindings/phy/qcom,qmp-phy.yaml +++ b/Documentation/devicetree/bindings/phy/qcom,qmp-phy.yaml @@ -17,6 +17,7 @@ description: properties: compatible: enum: + - qcom,ipq6018-qmp-pcie-phy - qcom,ipq8074-qmp-pcie-phy - qcom,ipq8074-qmp-usb3-phy - qcom,msm8996-qmp-pcie-phy @@ -296,6 +297,30 @@ allOf: items: - const: phy - const: common + - if: + properties: + compatible: + contains: + enum: + - qcom,ipq6018-qmp-pcie-phy + then: + properties: + clocks: + items: + - description: Phy aux clock. + - description: Phy config clock. + clock-names: + items: + - const: aux + - const: cfg_ahb + resets: + items: + - description: reset of phy block. + - description: phy common block reset. + reset-names: + items: + - const: phy + - const: common - if: properties: compatible: -- cgit v1.2.3 From 9f7368ff121042ba7032c754f108cf08bdc11a43 Mon Sep 17 00:00:00 2001 From: Baruch Siach Date: Wed, 5 May 2021 12:18:34 +0300 Subject: dt-bindings: pci: qcom: Document PCIe bindings for IPQ6018 SoC Document qcom,pcie-ipq6018. This is similar to the ipq8074 with a few different clock sources, and one additional reset. Reviewed-by: Rob Herring Signed-off-by: Baruch Siach Link: https://lore.kernel.org/r/fd732635f4ad64263e361ce98af2944bfbd513ef.1620203062.git.baruch@tkos.co.il Signed-off-by: Vinod Koul --- .../devicetree/bindings/pci/qcom,pcie.txt | 24 ++++++++++++++++++++++ 1 file changed, 24 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pci/qcom,pcie.txt b/Documentation/devicetree/bindings/pci/qcom,pcie.txt index 0da458a051b6..25f4def468bf 100644 --- a/Documentation/devicetree/bindings/pci/qcom,pcie.txt +++ b/Documentation/devicetree/bindings/pci/qcom,pcie.txt @@ -14,6 +14,7 @@ - "qcom,pcie-qcs404" for qcs404 - "qcom,pcie-sdm845" for sdm845 - "qcom,pcie-sm8250" for sm8250 + - "qcom,pcie-ipq6018" for ipq6018 - reg: Usage: required @@ -123,6 +124,16 @@ - "ahb" AHB clock - "aux" Auxiliary clock +- clock-names: + Usage: required for ipq6018 + Value type: + Definition: Should contain the following entries + - "iface" PCIe to SysNOC BIU clock + - "axi_m" AXI Master clock + - "axi_s" AXI Slave clock + - "axi_bridge" AXI bridge clock + - "rchng" + - clock-names: Usage: required for qcs404 Value type: @@ -209,6 +220,19 @@ - "ahb" AHB Reset - "axi_m_sticky" AXI Master Sticky reset +- reset-names: + Usage: required for ipq6018 + Value type: + Definition: Should contain the following entries + - "pipe" PIPE reset + - "sleep" Sleep reset + - "sticky" Core Sticky reset + - "axi_m" AXI Master reset + - "axi_s" AXI Slave reset + - "ahb" AHB Reset + - "axi_m_sticky" AXI Master Sticky reset + - "axi_s_sticky" AXI Slave Sticky reset + - reset-names: Usage: required for qcs404 Value type: -- cgit v1.2.3 From a56dfb6a79ee744d2b4ebdc6be56d7201c6bd22c Mon Sep 17 00:00:00 2001 From: Emmanuel Gil Peyrot Date: Tue, 11 May 2021 23:07:26 +0200 Subject: dt-bindings: eeprom-93xx46: Add support for 93C46, 93C56 and 93C66 These devices differ by the size of their storage, which is why they have different compatible strings. Acked-by: Rob Herring Signed-off-by: Emmanuel Gil Peyrot Link: https://lore.kernel.org/r/20210511210727.24895-4-linkmauve@linkmauve.fr Signed-off-by: Greg Kroah-Hartman --- Documentation/devicetree/bindings/misc/eeprom-93xx46.txt | 3 +++ 1 file changed, 3 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/misc/eeprom-93xx46.txt b/Documentation/devicetree/bindings/misc/eeprom-93xx46.txt index 7b636b7a8311..72ea0af368d4 100644 --- a/Documentation/devicetree/bindings/misc/eeprom-93xx46.txt +++ b/Documentation/devicetree/bindings/misc/eeprom-93xx46.txt @@ -2,7 +2,10 @@ EEPROMs (SPI) compatible with Microchip Technology 93xx46 family. Required properties: - compatible : shall be one of: + "atmel,at93c46" "atmel,at93c46d" + "atmel,at93c56" + "atmel,at93c66" "eeprom-93xx46" "microchip,93lc46b" - data-size : number of data bits per word (either 8 or 16) -- cgit v1.2.3 From a7a596cd31151b08ad0273af3665dac8c0b93842 Mon Sep 17 00:00:00 2001 From: Nicolas Boichat Date: Wed, 21 Apr 2021 13:28:52 +0800 Subject: dt-bindings: gpu: mali-bifrost: Add Mediatek MT8183 Define a compatible string for the Mali Bifrost GPU found in Mediatek's MT8183 SoCs. Signed-off-by: Nicolas Boichat Reviewed-by: Rob Herring Signed-off-by: Steven Price Link: https://patchwork.freedesktop.org/patch/msgid/20210421132841.v13.1.Ie74d3355761aab202d4825ac6f66d990bba0130e@changeid --- .../devicetree/bindings/gpu/arm,mali-bifrost.yaml | 30 +++++++++++++++++++++- 1 file changed, 29 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml b/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml index 894ba217ab32..0f73f436bea7 100644 --- a/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml +++ b/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml @@ -17,6 +17,7 @@ properties: items: - enum: - amlogic,meson-g12a-mali + - mediatek,mt8183-mali - realtek,rtd1619-mali - rockchip,px30-mali - const: arm,mali-bifrost # Mali Bifrost GPU model/revision is fully discoverable @@ -41,10 +42,13 @@ properties: mali-supply: true + sram-supply: true + operating-points-v2: true power-domains: - maxItems: 1 + minItems: 1 + maxItems: 3 resets: maxItems: 2 @@ -89,6 +93,30 @@ allOf: then: required: - resets + - if: + properties: + compatible: + contains: + const: mediatek,mt8183-mali + then: + properties: + power-domains: + minItems: 3 + power-domain-names: + items: + - const: core0 + - const: core1 + - const: core2 + + required: + - sram-supply + - power-domains + - power-domain-names + else: + properties: + power-domains: + maxItems: 1 + sram-supply: false examples: - | -- cgit v1.2.3 From 2cc8c910f51594dde79764a52b2974ddc8f70509 Mon Sep 17 00:00:00 2001 From: Tobias Schramm Date: Fri, 14 May 2021 13:38:11 +0200 Subject: dt-bindings: net: rockchip-dwmac: add rk3308 gmac compatible The Rockchip RK3308 has a gmac that is not fully compatible with any of the other Rockchip gmacs. This patch adds a compatible string for it. Signed-off-by: Tobias Schramm Signed-off-by: David S. Miller --- Documentation/devicetree/bindings/net/rockchip-dwmac.yaml | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/rockchip-dwmac.yaml b/Documentation/devicetree/bindings/net/rockchip-dwmac.yaml index 5acddb6171bf..34a660ad6b30 100644 --- a/Documentation/devicetree/bindings/net/rockchip-dwmac.yaml +++ b/Documentation/devicetree/bindings/net/rockchip-dwmac.yaml @@ -19,6 +19,7 @@ select: - rockchip,rk3128-gmac - rockchip,rk3228-gmac - rockchip,rk3288-gmac + - rockchip,rk3308-gmac - rockchip,rk3328-gmac - rockchip,rk3366-gmac - rockchip,rk3368-gmac @@ -38,6 +39,7 @@ properties: - rockchip,rk3128-gmac - rockchip,rk3228-gmac - rockchip,rk3288-gmac + - rockchip,rk3308-gmac - rockchip,rk3328-gmac - rockchip,rk3366-gmac - rockchip,rk3368-gmac -- cgit v1.2.3 From 227a9ffc1bc77037339530607fe129af3824620e Mon Sep 17 00:00:00 2001 From: Ansuel Smith Date: Fri, 14 May 2021 23:00:00 +0200 Subject: devicetree: net: dsa: qca8k: Document new compatible qca8327 Add support for qca8327 in the compatible list. Signed-off-by: Ansuel Smith Reviewed-by: Andrew Lunn Acked-by: Rob Herring Reviewed-by: Florian Fainelli Signed-off-by: David S. Miller --- Documentation/devicetree/bindings/net/dsa/qca8k.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/dsa/qca8k.txt b/Documentation/devicetree/bindings/net/dsa/qca8k.txt index ccbc6d89325d..1daf68e7ae19 100644 --- a/Documentation/devicetree/bindings/net/dsa/qca8k.txt +++ b/Documentation/devicetree/bindings/net/dsa/qca8k.txt @@ -3,6 +3,7 @@ Required properties: - compatible: should be one of: + "qca,qca8327" "qca,qca8334" "qca,qca8337" -- cgit v1.2.3 From 0c994a28e7518f098c84a3049cb2915780db873a Mon Sep 17 00:00:00 2001 From: Ansuel Smith Date: Fri, 14 May 2021 23:00:11 +0200 Subject: devicetree: bindings: dsa: qca8k: Document internal mdio definition Document new way of declare mapping of internal PHY to port. The new implementation directly declare the PHY connected to the port by adding a node in the switch node. The driver detect this and register an internal mdiobus using the mapping defined in the mdio node. Signed-off-by: Ansuel Smith Reviewed-by: Rob Herring Signed-off-by: David S. Miller --- .../devicetree/bindings/net/dsa/qca8k.txt | 39 ++++++++++++++++++++++ 1 file changed, 39 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/dsa/qca8k.txt b/Documentation/devicetree/bindings/net/dsa/qca8k.txt index 1daf68e7ae19..8c73f67c43ca 100644 --- a/Documentation/devicetree/bindings/net/dsa/qca8k.txt +++ b/Documentation/devicetree/bindings/net/dsa/qca8k.txt @@ -21,6 +21,10 @@ described in dsa/dsa.txt. If the QCA8K switch is connect to a SoC's external mdio-bus each subnode describing a port needs to have a valid phandle referencing the internal PHY it is connected to. This is because there's no N:N mapping of port and PHY id. +To declare the internal mdio-bus configuration, declare a mdio node in the +switch node and declare the phandle for the port referencing the internal +PHY is connected to. In this config a internal mdio-bus is registered and +the mdio MASTER is used as communication. Don't use mixed external and internal mdio-bus configurations, as this is not supported by the hardware. @@ -150,26 +154,61 @@ for the internal master mdio-bus configuration: port@1 { reg = <1>; label = "lan1"; + phy-mode = "internal"; + phy-handle = <&phy_port1>; }; port@2 { reg = <2>; label = "lan2"; + phy-mode = "internal"; + phy-handle = <&phy_port2>; }; port@3 { reg = <3>; label = "lan3"; + phy-mode = "internal"; + phy-handle = <&phy_port3>; }; port@4 { reg = <4>; label = "lan4"; + phy-mode = "internal"; + phy-handle = <&phy_port4>; }; port@5 { reg = <5>; label = "wan"; + phy-mode = "internal"; + phy-handle = <&phy_port5>; + }; + }; + + mdio { + #address-cells = <1>; + #size-cells = <0>; + + phy_port1: phy@0 { + reg = <0>; + }; + + phy_port2: phy@1 { + reg = <1>; + }; + + phy_port3: phy@2 { + reg = <2>; + }; + + phy_port4: phy@3 { + reg = <3>; + }; + + phy_port5: phy@4 { + reg = <4>; }; }; }; -- cgit v1.2.3 From 5f653f7590ab7db7379f668b2975744585206b0d Mon Sep 17 00:00:00 2001 From: Dan Williams Date: Thu, 13 May 2021 22:22:00 -0700 Subject: cxl/core: Rename bus.c to core.c In preparation for more generic shared functionality across endpoint consumers of core cxl resources, and platform-firmware producers of those resources, rename bus.c to core.c. In addition to the central rendezvous for interleave coordination, the core will also define common routines like CXL register block mapping. Acked-by: Ben Widawsky Reviewed-by: Jonathan Cameron Link: https://lore.kernel.org/r/162096972018.1865304.11079951161445408423.stgit@dwillia2-desk3.amr.corp.intel.com Signed-off-by: Dan Williams --- Documentation/driver-api/cxl/memory-devices.rst | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/driver-api/cxl/memory-devices.rst b/Documentation/driver-api/cxl/memory-devices.rst index 1bad466f9167..71495ed77069 100644 --- a/Documentation/driver-api/cxl/memory-devices.rst +++ b/Documentation/driver-api/cxl/memory-devices.rst @@ -28,10 +28,10 @@ CXL Memory Device .. kernel-doc:: drivers/cxl/mem.c :internal: -CXL Bus +CXL Core ------- -.. kernel-doc:: drivers/cxl/bus.c - :doc: cxl bus +.. kernel-doc:: drivers/cxl/core.c + :doc: cxl core External Interfaces =================== -- cgit v1.2.3 From 1d8613a23f3c3b8f0101e453ff150e05a0d1cd4f Mon Sep 17 00:00:00 2001 From: Can Guo Date: Wed, 21 Apr 2021 19:28:39 -0700 Subject: scsi: ufs: core: Introduce HBA performance monitor sysfs nodes Add a new sysfs group which has nodes to monitor data/request transfer performance. This sysfs group has nodes showing total sectors/requests transferred, total busy time spent and max/min/avg/sum latencies. This group can be enhanced later to show more UFS driver layer performance statistics data during runtime. Link: https://lore.kernel.org/r/1619058521-35307-2-git-send-email-cang@codeaurora.org Reviewed-by: Daejun Park Acked-by: Bean Huo Signed-off-by: Can Guo Signed-off-by: Martin K. Petersen --- Documentation/ABI/testing/sysfs-driver-ufs | 126 +++++++++++++++++++++++++++++ 1 file changed, 126 insertions(+) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-driver-ufs b/Documentation/ABI/testing/sysfs-driver-ufs index d1bc23cb6a9d..8380866d8ed0 100644 --- a/Documentation/ABI/testing/sysfs-driver-ufs +++ b/Documentation/ABI/testing/sysfs-driver-ufs @@ -995,6 +995,132 @@ Description: This entry shows the target state of an UFS UIC link The file is read only. +What: /sys/bus/platform/drivers/ufshcd/*/monitor/monitor_enable +Date: January 2021 +Contact: Can Guo +Description: This file shows the status of performance monitor enablement + and it can be used to start/stop the monitor. When the monitor + is stopped, the performance data collected is also cleared. + +What: /sys/bus/platform/drivers/ufshcd/*/monitor/monitor_chunk_size +Date: January 2021 +Contact: Can Guo +Description: This file tells the monitor to focus on requests transferring + data of specific chunk size (in Bytes). 0 means any chunk size. + It can only be changed when monitor is disabled. + +What: /sys/bus/platform/drivers/ufshcd/*/monitor/read_total_sectors +Date: January 2021 +Contact: Can Guo +Description: This file shows how many sectors (in 512 Bytes) have been + sent from device to host after monitor gets started. + + The file is read only. + +What: /sys/bus/platform/drivers/ufshcd/*/monitor/read_total_busy +Date: January 2021 +Contact: Can Guo +Description: This file shows how long (in micro seconds) has been spent + sending data from device to host after monitor gets started. + + The file is read only. + +What: /sys/bus/platform/drivers/ufshcd/*/monitor/read_nr_requests +Date: January 2021 +Contact: Can Guo +Description: This file shows how many read requests have been sent after + monitor gets started. + + The file is read only. + +What: /sys/bus/platform/drivers/ufshcd/*/monitor/read_req_latency_max +Date: January 2021 +Contact: Can Guo +Description: This file shows the maximum latency (in micro seconds) of + read requests after monitor gets started. + + The file is read only. + +What: /sys/bus/platform/drivers/ufshcd/*/monitor/read_req_latency_min +Date: January 2021 +Contact: Can Guo +Description: This file shows the minimum latency (in micro seconds) of + read requests after monitor gets started. + + The file is read only. + +What: /sys/bus/platform/drivers/ufshcd/*/monitor/read_req_latency_avg +Date: January 2021 +Contact: Can Guo +Description: This file shows the average latency (in micro seconds) of + read requests after monitor gets started. + + The file is read only. + +What: /sys/bus/platform/drivers/ufshcd/*/monitor/read_req_latency_sum +Date: January 2021 +Contact: Can Guo +Description: This file shows the total latency (in micro seconds) of + read requests sent after monitor gets started. + + The file is read only. + +What: /sys/bus/platform/drivers/ufshcd/*/monitor/write_total_sectors +Date: January 2021 +Contact: Can Guo +Description: This file shows how many sectors (in 512 Bytes) have been sent + from host to device after monitor gets started. + + The file is read only. + +What: /sys/bus/platform/drivers/ufshcd/*/monitor/write_total_busy +Date: January 2021 +Contact: Can Guo +Description: This file shows how long (in micro seconds) has been spent + sending data from host to device after monitor gets started. + + The file is read only. + +What: /sys/bus/platform/drivers/ufshcd/*/monitor/write_nr_requests +Date: January 2021 +Contact: Can Guo +Description: This file shows how many write requests have been sent after + monitor gets started. + + The file is read only. + +What: /sys/bus/platform/drivers/ufshcd/*/monitor/write_req_latency_max +Date: January 2021 +Contact: Can Guo +Description: This file shows the maximum latency (in micro seconds) of write + requests after monitor gets started. + + The file is read only. + +What: /sys/bus/platform/drivers/ufshcd/*/monitor/write_req_latency_min +Date: January 2021 +Contact: Can Guo +Description: This file shows the minimum latency (in micro seconds) of write + requests after monitor gets started. + + The file is read only. + +What: /sys/bus/platform/drivers/ufshcd/*/monitor/write_req_latency_avg +Date: January 2021 +Contact: Can Guo +Description: This file shows the average latency (in micro seconds) of write + requests after monitor gets started. + + The file is read only. + +What: /sys/bus/platform/drivers/ufshcd/*/monitor/write_req_latency_sum +Date: January 2021 +Contact: Can Guo +Description: This file shows the total latency (in micro seconds) of write + requests after monitor gets started. + + The file is read only. + What: /sys/bus/platform/drivers/ufshcd/*/device_descriptor/wb_presv_us_en Date: June 2020 Contact: Asutosh Das -- cgit v1.2.3 From 20bc8c1e972f29afcac85e524e430c11a6df5f58 Mon Sep 17 00:00:00 2001 From: Andy Shevchenko Date: Tue, 11 May 2021 18:39:55 +0300 Subject: lib/vsprintf: Allow to override ISO 8601 date and time separator ISO 8601 defines 'T' as a separator between date and time. Though, some ABIs use time and date with ' ' (space) separator instead. Add a flavour to the %pt specifier to override default separator. Signed-off-by: Andy Shevchenko Reviewed-by: Petr Mladek Reviewed-by: Sergey Senozhatsky Signed-off-by: Petr Mladek Link: https://lore.kernel.org/r/20210511153958.34527-1-andriy.shevchenko@linux.intel.com --- Documentation/core-api/printk-formats.rst | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/core-api/printk-formats.rst b/Documentation/core-api/printk-formats.rst index 9be6de402cb9..7b6bfd8a78d3 100644 --- a/Documentation/core-api/printk-formats.rst +++ b/Documentation/core-api/printk-formats.rst @@ -514,9 +514,10 @@ Time and date :: %pt[RT] YYYY-mm-ddTHH:MM:SS + %pt[RT]s YYYY-mm-dd HH:MM:SS %pt[RT]d YYYY-mm-dd %pt[RT]t HH:MM:SS - %pt[RT][dt][r] + %pt[RT][dt][r][s] For printing date and time as represented by:: @@ -528,6 +529,10 @@ in human readable format. By default year will be incremented by 1900 and month by 1. Use %pt[RT]r (raw) to suppress this behaviour. +The %pt[RT]s (space) will override ISO 8601 separator by using ' ' (space) +instead of 'T' (Capital T) between date and time. It won't have any effect +when date or time is omitted. + Passed by reference. struct clk -- cgit v1.2.3 From 5e713b25d137d9cfb9bcf4387513b3acf00c4828 Mon Sep 17 00:00:00 2001 From: Puranjay Mohan Date: Wed, 7 Apr 2021 23:51:46 +0530 Subject: dt-bindings: iio: temperature: Add DT bindings for TMP117 Add devicetree binding document for TMP117, a digital temperature sensor. Signed-off-by: Puranjay Mohan Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20210407182147.77221-2-puranjay12@gmail.com Signed-off-by: Jonathan Cameron --- .../bindings/iio/temperature/ti,tmp117.yaml | 41 ++++++++++++++++++++++ 1 file changed, 41 insertions(+) create mode 100644 Documentation/devicetree/bindings/iio/temperature/ti,tmp117.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/iio/temperature/ti,tmp117.yaml b/Documentation/devicetree/bindings/iio/temperature/ti,tmp117.yaml new file mode 100644 index 000000000000..347bc16a4671 --- /dev/null +++ b/Documentation/devicetree/bindings/iio/temperature/ti,tmp117.yaml @@ -0,0 +1,41 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/iio/temperature/ti,tmp117.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: "TI TMP117 - Digital temperature sensor with integrated NV memory" + +description: | + TI TMP117 - Digital temperature sensor with integrated NV memory that supports + I2C interface. + https://www.ti.com/lit/gpn/tmp1 + +maintainers: + - Puranjay Mohan + +properties: + compatible: + enum: + - ti,tmp117 + + reg: + maxItems: 1 + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + tmp117@48 { + compatible = "ti,tmp117"; + reg = <0x48>; + }; + }; -- cgit v1.2.3 From 0cd71145803dc2b87b3afc8e2990ff0d43bf7027 Mon Sep 17 00:00:00 2001 From: Linus Walleij Date: Mon, 12 Apr 2021 14:23:31 +0200 Subject: iio: st-sensors: Update ST Sensor bindings This adjusts the ST Sensor bindings with the more fine-grained syntax checks that were proposed late in the last kernel cycle and colliding with parallel work. Cc: devicetree@vger.kernel.org Reviewed-by: Rob Herring Signed-off-by: Linus Walleij Link: https://lore.kernel.org/r/20210412122331.1631643-1-linus.walleij@linaro.org Signed-off-by: Jonathan Cameron --- .../devicetree/bindings/iio/st,st-sensors.yaml | 259 +++++++++++++++------ 1 file changed, 182 insertions(+), 77 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/iio/st,st-sensors.yaml b/Documentation/devicetree/bindings/iio/st,st-sensors.yaml index 7e98f47987dc..d7c274a4cdc3 100644 --- a/Documentation/devicetree/bindings/iio/st,st-sensors.yaml +++ b/Documentation/devicetree/bindings/iio/st,st-sensors.yaml @@ -6,7 +6,9 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: STMicroelectronics MEMS sensors -description: | +description: The STMicroelectronics sensor devices are pretty straight-forward + I2C or SPI devices, all sharing the same device tree descriptions no matter + what type of sensor it is. Note that whilst this covers many STMicro MEMs sensors, some more complex IMUs need their own bindings. The STMicroelectronics sensor devices are pretty straight-forward I2C or @@ -15,90 +17,178 @@ description: | maintainers: - Denis Ciocca + - Linus Walleij properties: compatible: - description: | - Some values are deprecated. - st,lis3lv02d (deprecated, use st,lis3lv02dl-accel) - st,lis302dl-spi (deprecated, use st,lis3lv02dl-accel) - enum: - # Accelerometers - - st,lis3lv02d - - st,lis302dl-spi - - st,lis3lv02dl-accel - - st,lsm303dlh-accel - - st,lsm303dlhc-accel - - st,lis3dh-accel - - st,lsm330d-accel - - st,lsm330dl-accel - - st,lsm330dlc-accel - - st,lis331dl-accel - - st,lis331dlh-accel - - st,lsm303dl-accel - - st,lsm303dlm-accel - - st,lsm330-accel - - st,lsm303agr-accel - - st,lis2dh12-accel - - st,h3lis331dl-accel - - st,lng2dm-accel - - st,lis3l02dq - - st,lis2dw12 - - st,lis3dhh - - st,lis3de - - st,lis2de12 - - st,lis2hh12 - # Gyroscopes - - st,l3g4200d-gyro - - st,lsm330d-gyro - - st,lsm330dl-gyro - - st,lsm330dlc-gyro - - st,l3gd20-gyro - - st,l3gd20h-gyro - - st,l3g4is-gyro - - st,lsm330-gyro - - st,lsm9ds0-gyro - # Magnetometers - - st,lsm303agr-magn - - st,lsm303dlh-magn - - st,lsm303dlhc-magn - - st,lsm303dlm-magn - - st,lis3mdl-magn - - st,lis2mdl - - st,lsm9ds1-magn - - st,iis2mdc - # Pressure sensors - - st,lps001wp-press - - st,lps25h-press - - st,lps331ap-press - - st,lps22hb-press - - st,lps33hw - - st,lps35hw - - st,lps22hh + oneOf: + - description: STMicroelectronics Accelerometers + enum: + - st,h3lis331dl-accel + - st,lis2de12 + - st,lis2dw12 + - st,lis2hh12 + - st,lis2dh12-accel + - st,lis331dl-accel + - st,lis331dlh-accel + - st,lis3de + - st,lis3dh-accel + - st,lis3dhh + - st,lis3l02dq + - st,lis3lv02dl-accel + - st,lng2dm-accel + - st,lsm303agr-accel + - st,lsm303dl-accel + - st,lsm303dlh-accel + - st,lsm303dlhc-accel + - st,lsm303dlm-accel + - st,lsm330-accel + - st,lsm330d-accel + - st,lsm330dl-accel + - st,lsm330dlc-accel + - description: STMicroelectronics Gyroscopes + enum: + - st,l3g4200d-gyro + - st,l3g4is-gyro + - st,l3gd20-gyro + - st,l3gd20h-gyro + - st,lsm330-gyro + - st,lsm330d-gyro + - st,lsm330dl-gyro + - st,lsm330dlc-gyro + - st,lsm9ds0-gyro + - description: STMicroelectronics Magnetometers + enum: + - st,lis2mdl + - st,lis3mdl-magn + - st,lsm303agr-magn + - st,lsm303dlh-magn + - st,lsm303dlhc-magn + - st,lsm303dlm-magn + - st,lsm9ds1-magn + - description: STMicroelectronics Pressure Sensors + enum: + - st,lps001wp-press + - st,lps22hb-press + - st,lps22hh + - st,lps25h-press + - st,lps331ap-press + - st,lps33hw + - st,lps35hw + - description: Deprecated bindings + enum: + - st,lis302dl-spi + - st,lis3lv02d + deprecated: true reg: maxItems: 1 interrupts: + description: interrupt line(s) connected to the DRDY line(s) and/or the + Intertial interrupt lines INT1 and INT2 if these exist. This means up to + three interrupts, and the DRDY must be the first one if it exists on + the package. The trigger edge of the interrupts is sometimes software + configurable in the hardware so the operating system should parse this + flag and set up the trigger edge as indicated in the device tree. minItems: 1 + maxItems: 2 vdd-supply: true vddio-supply: true st,drdy-int-pin: + description: the pin on the package that will be used to signal + "data ready" (valid values 1 or 2). This property is not configurable + on all sensors. $ref: /schemas/types.yaml#/definitions/uint32 - description: - Some sensors have multiple possible pins via which they can provide - a data ready interrupt. This selects which one. - enum: - - 1 - - 2 + enum: [1, 2] drive-open-drain: $ref: /schemas/types.yaml#/definitions/flag - description: | - The interrupt/data ready line will be configured as open drain, which - is useful if several sensors share the same interrupt line. + description: the interrupt/data ready line will be configured + as open drain, which is useful if several sensors share the same + interrupt line. (This binding is taken from pinctrl.) + + mount-matrix: + description: an optional 3x3 mounting rotation matrix. + +allOf: + - if: + properties: + compatible: + enum: + # These have no interrupts + - st,lps001wp + then: + properties: + interrupts: false + st,drdy-int-pin: false + drive-open-drain: false + + - if: + properties: + compatible: + enum: + # These have only DRDY + - st,lis2mdl + - st,lis3l02dq + - st,lis3lv02dl-accel + - st,lps22hb-press + - st,lps22hh + - st,lps25h-press + - st,lps33hw + - st,lps35hw + - st,lsm303agr-magn + - st,lsm303dlh-magn + - st,lsm303dlhc-magn + - st,lsm303dlm-magn + then: + properties: + interrupts: + maxItems: 1 + st,drdy-int-pin: false + + - if: + properties: + compatible: + enum: + # Two intertial interrupts i.e. accelerometer/gyro interrupts + - st,h3lis331dl-accel + - st,l3g4200d-gyro + - st,l3g4is-gyro + - st,l3gd20-gyro + - st,l3gd20h-gyro + - st,lis2de12 + - st,lis2dw12 + - st,lis2hh12 + - st,lis2dh12-accel + - st,lis331dl-accel + - st,lis331dlh-accel + - st,lis3de + - st,lis3dh-accel + - st,lis3dhh + - st,lis3mdl-magn + - st,lng2dm-accel + - st,lps331ap-press + - st,lsm303agr-accel + - st,lsm303dlh-accel + - st,lsm303dlhc-accel + - st,lsm303dlm-accel + - st,lsm330-accel + - st,lsm330-gyro + - st,lsm330d-accel + - st,lsm330d-gyro + - st,lsm330dl-accel + - st,lsm330dl-gyro + - st,lsm330dlc-accel + - st,lsm330dlc-gyro + - st,lsm9ds0-gyro + - st,lsm9ds1-magn + then: + properties: + interrupts: + maxItems: 2 required: - compatible @@ -110,15 +200,30 @@ examples: - | #include i2c { - #address-cells = <1>; - #size-cells = <0>; - accelerometer@1d { - compatible = "st,lis3lv02dl-accel"; - reg = <0x1d>; - interrupt-parent = <&gpio2>; - interrupts = <18 IRQ_TYPE_EDGE_RISING>; - pinctrl-0 = <&lis3lv02dl_nhk_mode>; - pinctrl-names = "default"; - }; + #address-cells = <1>; + #size-cells = <0>; + + accelerometer@1c { + compatible = "st,lis331dl-accel"; + reg = <0x1c>; + st,drdy-int-pin = <1>; + vdd-supply = <&ldo1>; + vddio-supply = <&ldo2>; + interrupt-parent = <&gpio>; + interrupts = <18 IRQ_TYPE_EDGE_RISING>, <19 IRQ_TYPE_EDGE_RISING>; + }; + }; + spi { + #address-cells = <1>; + #size-cells = <0>; + num-cs = <1>; + + l3g4200d: gyroscope@0 { + compatible = "st,l3g4200d-gyro"; + st,drdy-int-pin = <2>; + reg = <0>; + vdd-supply = <&vcc_io>; + vddio-supply = <&vcc_io>; + }; }; ... -- cgit v1.2.3 From afa2b78f1e58eaca820f32c124e5655f43583eb1 Mon Sep 17 00:00:00 2001 From: Joe Sandom Date: Wed, 21 Apr 2021 23:13:30 +0100 Subject: dt-bindings: iio: light: Added AMS tsl2591 device tree binding Device tree binding for AMS/TAOS tsl2591 ambient light sensor. This driver supports configuration via device tree and sysfs. Supported channels for raw infrared light intensity, raw combined light intensity and illuminance in lux. The driver additionally supports iio events on lower and upper thresholds. This is a very-high sensitivity light-to-digital converter that transforms light intensity into a digital signal. Signed-off-by: Joe Sandom Reviewed-by: Rob Herring Reviewed-by: Andy Shevchenko Link: https://lore.kernel.org/r/20210421221330.17007-2-joe.g.sandom@gmail.com Signed-off-by: Jonathan Cameron --- .../bindings/iio/light/amstaos,tsl2591.yaml | 50 ++++++++++++++++++++++ 1 file changed, 50 insertions(+) create mode 100644 Documentation/devicetree/bindings/iio/light/amstaos,tsl2591.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/iio/light/amstaos,tsl2591.yaml b/Documentation/devicetree/bindings/iio/light/amstaos,tsl2591.yaml new file mode 100644 index 000000000000..83b88c6a243d --- /dev/null +++ b/Documentation/devicetree/bindings/iio/light/amstaos,tsl2591.yaml @@ -0,0 +1,50 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iio/light/amstaos,tsl2591.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: AMS/TAOS TSL2591 Ambient Light Sensor (ALS) + +maintainers: + - Joe Sandom + +description: | + AMS/TAOS TSL2591 is a very-high sensitivity + light-to-digital converter that transforms light intensity into a digital + signal. + +properties: + compatible: + const: amstaos,tsl2591 + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + description: + Interrupt (INT:Pin 2) Active low. Should be set to IRQ_TYPE_EDGE_FALLING. + interrupt is used to detect if the light intensity has fallen below + or reached above the configured threshold values. + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + #include + i2c { + #address-cells = <1>; + #size-cells = <0>; + + tsl2591@29 { + compatible = "amstaos,tsl2591"; + reg = <0x29>; + interrupts = <20 IRQ_TYPE_EDGE_FALLING>; + }; + }; +... -- cgit v1.2.3 From 2599d5bc910dbcd7f447e4c960efde5550e21852 Mon Sep 17 00:00:00 2001 From: Jonathan Cameron Date: Thu, 1 Apr 2021 18:41:07 +0100 Subject: dt-bindings:iio:accel:adis16201 and adis16209 bindings These two devices have different internal characteristics, but their external connectivity and as a result device tree descriptions are identical. Note that neither driver in Linux currently has an of_match_table but instead rely on matching via name alone. Signed-off-by: Jonathan Cameron Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20210401174112.320497-2-jic23@kernel.org --- .../bindings/iio/accel/adi,adis16201.yaml | 55 ++++++++++++++++++++++ 1 file changed, 55 insertions(+) create mode 100644 Documentation/devicetree/bindings/iio/accel/adi,adis16201.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/iio/accel/adi,adis16201.yaml b/Documentation/devicetree/bindings/iio/accel/adi,adis16201.yaml new file mode 100644 index 000000000000..6f8f8a6258fe --- /dev/null +++ b/Documentation/devicetree/bindings/iio/accel/adi,adis16201.yaml @@ -0,0 +1,55 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iio/accel/adi,adis16201.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: ADIS16201 Dual Axis Inclinometer and similar + +maintainers: + - Jonathan Cameron + +description: | + Two similar parts from external interface point of view. + SPI interface. + https://www.analog.com/en/products/adis16201.html + https://www.analog.com/en/products/adis16209.html + +properties: + compatible: + enum: + - adi,adis16201 + - adi,adis16209 + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + spi-max-frequency: true + + vdd-supply: true + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + #include + spi0 { + #address-cells = <1>; + #size-cells = <0>; + + accelerometer@0 { + compatible = "adi,adis16201"; + reg = <0>; + spi-max-frequency = <2500000>; + interrupt-parent = <&gpio0>; + interrupts = <0 IRQ_TYPE_LEVEL_HIGH>; + }; + }; +... -- cgit v1.2.3 From 7dbd479425d26678b968e363691b8113d3b106af Mon Sep 17 00:00:00 2001 From: Jonathan Cameron Date: Thu, 1 Apr 2021 18:41:08 +0100 Subject: dt-bindings:iio:accel:bosch,bma220 device tree binding documentation Linux driver currently relies on the driver.name to match to the compatible, but that doesn't mean it isn't a good idea to document it. Only real complexity is the 3 separate power supplies. Signed-off-by: Jonathan Cameron Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20210401174112.320497-3-jic23@kernel.org --- .../bindings/iio/accel/bosch,bma220.yaml | 50 ++++++++++++++++++++++ 1 file changed, 50 insertions(+) create mode 100644 Documentation/devicetree/bindings/iio/accel/bosch,bma220.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/iio/accel/bosch,bma220.yaml b/Documentation/devicetree/bindings/iio/accel/bosch,bma220.yaml new file mode 100644 index 000000000000..942b23ad0712 --- /dev/null +++ b/Documentation/devicetree/bindings/iio/accel/bosch,bma220.yaml @@ -0,0 +1,50 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iio/accel/bosch,bma220.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Bosch BMA220 Trixial Acceleration Sensor + +maintainers: + - Jonathan Cameron + +properties: + compatible: + enum: + - bosch,bma220 + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + spi-max-frequency: true + + vdda-supply: true + vddd-supply: true + vddio-supply: true + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + #include + spi0 { + #address-cells = <1>; + #size-cells = <0>; + + accelerometer@0 { + compatible = "bosch,bma220"; + reg = <0>; + spi-max-frequency = <2500000>; + interrupt-parent = <&gpio0>; + interrupts = <0 IRQ_TYPE_LEVEL_HIGH>; + }; + }; +... -- cgit v1.2.3 From 3ed7928d9f1598786908cc8a160df1c9bb55e5b7 Mon Sep 17 00:00:00 2001 From: Jonathan Cameron Date: Thu, 1 Apr 2021 18:41:09 +0100 Subject: dt-bindings:iio:accel:fsl,mma7455 binding doc Binding documentation for this driver was missing. Note that the binding and some in tree dts files specifiy interrupts etc but the driver is fairly simple and does not yet make use of them. Listed both Joachim and myself as maintainers for this binding on basis it's Joachim's driver but I don't want to volunteer Joachim too strongly to look after this doc. Signed-off-by: Jonathan Cameron Cc: Joachim Eastwood Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20210401174112.320497-4-jic23@kernel.org --- .../devicetree/bindings/iio/accel/fsl,mma7455.yaml | 82 ++++++++++++++++++++++ 1 file changed, 82 insertions(+) create mode 100644 Documentation/devicetree/bindings/iio/accel/fsl,mma7455.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/iio/accel/fsl,mma7455.yaml b/Documentation/devicetree/bindings/iio/accel/fsl,mma7455.yaml new file mode 100644 index 000000000000..7c8f8bdc2333 --- /dev/null +++ b/Documentation/devicetree/bindings/iio/accel/fsl,mma7455.yaml @@ -0,0 +1,82 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iio/accel/fsl,mma7455.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Freescale MMA7455 and MMA7456 three axis accelerometers + +maintainers: + - Joachim Eastwood + - Jonathan Cameron + +description: + Devices support both SPI and I2C interfaces. + +properties: + compatible: + enum: + - fsl,mma7455 + - fsl,mma7456 + reg: + maxItems: 1 + + avdd-supply: true + vddio-supply: true + + interrupts: + minItems: 1 + maxItems: 2 + + interrupt-names: + description: + Data ready is only available on INT1, but events can use either or + both pins. If not specified, first element assumed to correspond + to INT1 and second (where present) to INT2. + minItems: 1 + maxItems: 2 + items: + enum: + - "INT1" + - "INT2" + + spi-max-frequency: true + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + # include + i2c { + #address-cells = <1>; + #size-cells = <0>; + + accelerometer@18 { + compatible = "fsl,mma7455"; + reg = <0x18>; + vddio-supply = <&iovdd>; + avdd-supply = <&avdd>; + interrupts = <57 IRQ_TYPE_EDGE_FALLING>, <58 IRQ_TYPE_EDGE_FALLING>; + interrupt-names = "INT2", "INT1"; + }; + }; + - | + # include + spi { + #address-cells = <1>; + #size-cells = <0>; + accelerometer@0 { + compatible = "fsl,mma7456"; + reg = <0>; + spi-max-frequency = <10000000>; + vddio-supply = <&iovdd>; + avdd-supply = <&avdd>; + interrupts = <57 IRQ_TYPE_EDGE_FALLING>; + interrupt-names = "INT1"; + }; + }; +... -- cgit v1.2.3 From d9bf5d37fd58dc96220270e253116350ec26522b Mon Sep 17 00:00:00 2001 From: Jonathan Cameron Date: Thu, 1 Apr 2021 18:41:10 +0100 Subject: dt-bindings:trivial-devices: Add memsic,mxc4005/mxc6255/mxc6655 entries Simple devices with I2C interface and single interrupt line so entries in trivial devices are sufficient. Signed-off-by: Jonathan Cameron Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20210401174112.320497-5-jic23@kernel.org --- Documentation/devicetree/bindings/trivial-devices.yaml | 6 ++++++ 1 file changed, 6 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/trivial-devices.yaml b/Documentation/devicetree/bindings/trivial-devices.yaml index 8341e9d23c1e..8dd19cbc4b2b 100644 --- a/Documentation/devicetree/bindings/trivial-devices.yaml +++ b/Documentation/devicetree/bindings/trivial-devices.yaml @@ -173,8 +173,14 @@ properties: - meas,tsys01 # MEMSIC magnetometer - memsic,mmc35240 + # MEMSIC 3-axis accelerometer + - memsic,mx4005 # MEMSIC 2-axis 8-bit digital accelerometer - memsic,mxc6225 + # MEMSIC 2-axis 8-bit digital accelerometer + - memsic,mxc6255 + # MEMSIC 3-axis accelerometer + - memsic,mxc6655 # Microchip differential I2C ADC, 1 Channel, 18 bit - microchip,mcp3421 # Microchip differential I2C ADC, 2 Channel, 18 bit -- cgit v1.2.3 From 1ce9da1f61643f84258697891b1a3e3ccdb8e660 Mon Sep 17 00:00:00 2001 From: Jonathan Cameron Date: Thu, 1 Apr 2021 18:41:11 +0100 Subject: dt-bindings:trivial-devices: Add sensortek,stk8312 and sensortek,s8ba50 Two simple devices. The stk8ba50 datasheet could be found via google, but I only have the driver for the 8312. Given they both seem to be 3 axis devices with a single interrupt line, add them to trivial-devices.yaml Signed-off-by: Jonathan Cameron Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20210401174112.320497-6-jic23@kernel.org --- Documentation/devicetree/bindings/trivial-devices.yaml | 4 ++++ 1 file changed, 4 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/trivial-devices.yaml b/Documentation/devicetree/bindings/trivial-devices.yaml index 8dd19cbc4b2b..35e58fe46999 100644 --- a/Documentation/devicetree/bindings/trivial-devices.yaml +++ b/Documentation/devicetree/bindings/trivial-devices.yaml @@ -265,6 +265,10 @@ properties: - sensirion,sgpc3 # Sensirion multi-pixel gas sensor with I2C interface - sensirion,sgp30 + # Sensortek 3 axis accelerometer + - sensortek,stk8312 + # Sensortek 3 axis accelerometer + - sensortek,stk8ba50 # SGX Sensortech VZ89X Sensors - sgx,vz89x # Relative Humidity and Temperature Sensors -- cgit v1.2.3 From c1096dce272ff773b2af12424956d2c2699869cd Mon Sep 17 00:00:00 2001 From: Jonathan Cameron Date: Thu, 1 Apr 2021 18:41:12 +0100 Subject: dt-bindings:iio:adc:adi,ad7298 document bindings The device has a tsens-busy pin, but it's both fiddly and currently ignored by the Linux driver. Given it's not clear whether the binding should be an interrupt, or a GPIO I have left that out for now. Signed-off-by: Jonathan Cameron Cc: Michael Hennerich Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20210401174112.320497-7-jic23@kernel.org --- .../devicetree/bindings/iio/adc/adi,ad7298.yaml | 48 ++++++++++++++++++++++ 1 file changed, 48 insertions(+) create mode 100644 Documentation/devicetree/bindings/iio/adc/adi,ad7298.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/iio/adc/adi,ad7298.yaml b/Documentation/devicetree/bindings/iio/adc/adi,ad7298.yaml new file mode 100644 index 000000000000..ca414bb396c5 --- /dev/null +++ b/Documentation/devicetree/bindings/iio/adc/adi,ad7298.yaml @@ -0,0 +1,48 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +# Copyright 2019 Analog Devices Inc. +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iio/adc/adi,ad7298.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Analog Devices AD7298 ADC + +maintainers: + - Michael Hennerich + +description: | + Bindings for the Analog Devices AD7298 ADC device. Datasheet can be + found here: + https://www.analog.com/en/products/ad7298.html + +properties: + compatible: + const: adi,ad7298 + + reg: + maxItems: 1 + + vref-supply: true + vdd-supply: true + spi-max-frequency: true + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + spi { + #address-cells = <1>; + #size-cells = <0>; + + adc@0 { + compatible = "adi,ad7298"; + reg = <0>; + spi-max-frequency = <5000000>; + vref-supply = <&adc_vref>; + }; + }; +... -- cgit v1.2.3 From 7f9ef8ed0f4020348342a5c87b0559aad90a29a9 Mon Sep 17 00:00:00 2001 From: Jonathan Cameron Date: Thu, 1 Apr 2021 15:09:56 +0100 Subject: dt-bindings:iio:dac:ti,dac082s085 yaml conversion Fairly simple conversion with the exception of the XOR between spi-cpha and spi-cpol. Signed-off-by: Jonathan Cameron Cc: Lukas Wunner Link: https://lore.kernel.org/r/20201031134110.724233-17-jic23@kernel.org Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20210401140956.224084-3-jic23@kernel.org --- .../devicetree/bindings/iio/dac/ti,dac082s085.yaml | 72 ++++++++++++++++++++++ .../devicetree/bindings/iio/dac/ti-dac082s085.txt | 34 ---------- 2 files changed, 72 insertions(+), 34 deletions(-) create mode 100644 Documentation/devicetree/bindings/iio/dac/ti,dac082s085.yaml delete mode 100644 Documentation/devicetree/bindings/iio/dac/ti-dac082s085.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/iio/dac/ti,dac082s085.yaml b/Documentation/devicetree/bindings/iio/dac/ti,dac082s085.yaml new file mode 100644 index 000000000000..b0157050f1ee --- /dev/null +++ b/Documentation/devicetree/bindings/iio/dac/ti,dac082s085.yaml @@ -0,0 +1,72 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iio/dac/ti,dac082s085.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Texas Instruments DAC082s085 and similar DACs + +description: + A family of Texas Instruments 8/10/12-bit 2/4-channel DACs + +maintainers: + - Lukas Wunner + +properties: + compatible: + enum: + - ti,dac082s085 + - ti,dac102s085 + - ti,dac122s085 + - ti,dac084s085 + - ti,dac104s085 + - ti,dac124s085 + + reg: + maxItems: 1 + + spi-cpha: true + spi-cpol: + description: + Must be either spi-cpha, or spi-cpol but not both. + + vref-supply: + description: Needed to provide output scaling. + + spi-max-frequency: true + +required: + - compatible + - reg + - vref-supply + +additionalProperties: false + +oneOf: + - required: + - spi-cpha + - required: + - spi-cpol + +examples: + - | + vref_2v5_reg: regulator-vref { + compatible = "regulator-fixed"; + regulator-name = "2v5"; + regulator-min-microvolt = <2500000>; + regulator-max-microvolt = <2500000>; + regulator-always-on; + }; + spi { + #address-cells = <1>; + #size-cells = <0>; + + dac@0 { + compatible = "ti,dac082s085"; + reg = <0>; + spi-max-frequency = <40000000>; + spi-cpol; + vref-supply = <&vref_2v5_reg>; + }; + }; +... diff --git a/Documentation/devicetree/bindings/iio/dac/ti-dac082s085.txt b/Documentation/devicetree/bindings/iio/dac/ti-dac082s085.txt deleted file mode 100644 index 9cb0e10df704..000000000000 --- a/Documentation/devicetree/bindings/iio/dac/ti-dac082s085.txt +++ /dev/null @@ -1,34 +0,0 @@ -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 2cd2b093e4447c2cd9287d4ab15363f70393587c Mon Sep 17 00:00:00 2001 From: Jonathan Cameron Date: Sun, 25 Apr 2021 17:31:54 +0100 Subject: dt-bindings:iio:adc:adi,ad7476: Add missing binding document This binding covers class of simple SPI ADCs which only provide data output - they don't have MOSI pin. The only real variation between them is over how many supplies they use and which one is used for the reference. Michael listed as maintainer for this one as it is his driver and falls under the catch all MAINTAINERS entry for ADI devices. Signed-off-by: Jonathan Cameron Cc: Michael Hennerich Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20210425163154.73209-3-jic23@kernel.org --- .../devicetree/bindings/iio/adc/adi,ad7476.yaml | 174 +++++++++++++++++++++ 1 file changed, 174 insertions(+) create mode 100644 Documentation/devicetree/bindings/iio/adc/adi,ad7476.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/iio/adc/adi,ad7476.yaml b/Documentation/devicetree/bindings/iio/adc/adi,ad7476.yaml new file mode 100644 index 000000000000..cf711082ad7d --- /dev/null +++ b/Documentation/devicetree/bindings/iio/adc/adi,ad7476.yaml @@ -0,0 +1,174 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +# Copyright 2019 Analog Devices Inc. +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iio/adc/adi,ad7476.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: AD7476 and similar simple SPI ADCs from multiple manufacturers. + +maintainers: + - Michael Hennerich + +description: | + A lot of simple SPI ADCs have very straight forward interfaces. + They typically don't provide a MOSI pin, simply reading out data + on MISO when the clock toggles. + +properties: + compatible: + enum: + - adi,ad7091 + - adi,ad7091r + - adi,ad7273 + - adi,ad7274 + - adi,ad7276 + - adi,ad7277 + - adi,ad7278 + - adi,ad7466 + - adi,ad7467 + - adi,ad7468 + - adi,ad7475 + - adi,ad7476 + - adi,ad7476a + - adi,ad7477 + - adi,ad7477a + - adi,ad7478 + - adi,ad7478a + - adi,ad7495 + - adi,ad7910 + - adi,ad7920 + - adi,ad7940 + - ti,adc081s + - ti,adc101s + - ti,adc121s + - ti,ads7866 + - ti,ads7867 + - ti,ads7868 + - lltc,ltc2314-14 + + reg: + maxItems: 1 + + vcc-supply: + description: + Main powersupply voltage for the chips, sometimes referred to as VDD on + datasheets. If there is no separate vref-supply, then this is needed + to establish channel scaling. + + vdrive-supply: + description: + Some devices have separate supply for their digital control side. + + vref-supply: + description: + Some devices have a specific reference voltage supplied on a different pin + to the other supplies. Needed to be able to establish channel scaling + unless there is also an internal reference available (e.g. ad7091r) + + spi-max-frequency: true + + adi,conversion-start-gpios: + description: A GPIO used to trigger the start of a conversion + maxItems: 1 + +required: + - compatible + - reg + +additionalProperties: false + +allOf: + # Devices where reference is vcc + - if: + properties: + compatible: + contains: + enum: + - adi,ad7091 + - adi,ad7276 + - adi,ad7277 + - adi,ad7278 + - adi,ad7466 + - adi,ad7467 + - adi,ad7468 + - adi,ad7940 + - ti,adc081s + - ti,adc101s + - ti,adc121s + - ti,ads7866 + - ti,ads7868 + required: + - vcc-supply + # Devices with a vref + - if: + properties: + compatible: + contains: + enum: + - adi,ad7091r + - adi,ad7273 + - adi,ad7274 + - adi,ad7475 + - lltc,ltc2314-14 + then: + properties: + vref-supply: true + else: + properties: + vref-supply: false + # Devices with a vref where it is not optional + - if: + properties: + compatible: + contains: + enum: + - adi,ad7273 + - adi,ad7274 + - adi,ad7475 + - lltc,ltc2314-14 + then: + required: + - vref-supply + - if: + properties: + compatible: + contains: + enum: + - adi,ad7475 + - adi,ad7495 + then: + properties: + vdrive-supply: true + else: + properties: + vdrive-supply: false + - if: + properties: + compatible: + contains: + enum: + - adi,ad7091 + - adi,ad7091r + then: + properties: + adi,conversion-start-gpios: true + else: + properties: + adi,conversion-start-gpios: false + +examples: + - | + spi { + #address-cells = <1>; + #size-cells = <0>; + + adc@0 { + compatible = "adi,ad7091r"; + reg = <0>; + spi-max-frequency = <5000000>; + vcc-supply = <&adc_vcc>; + vref-supply = <&adc_vref>; + }; + }; +... -- cgit v1.2.3 From 99422e2a670c517681c0c163f1627c17f69c3bfa Mon Sep 17 00:00:00 2001 From: Tomas Melin Date: Mon, 26 Apr 2021 11:10:40 +0300 Subject: dt-bindings: iio: accel: Add SCA3300 documentation initial DT bindings for Murata SCA3300 Accelerometer. Signed-off-by: Tomas Melin Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20210426081041.59807-2-tomas.melin@vaisala.com Signed-off-by: Jonathan Cameron --- .../bindings/iio/accel/murata,sca3300.yaml | 44 ++++++++++++++++++++++ 1 file changed, 44 insertions(+) create mode 100644 Documentation/devicetree/bindings/iio/accel/murata,sca3300.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/iio/accel/murata,sca3300.yaml b/Documentation/devicetree/bindings/iio/accel/murata,sca3300.yaml new file mode 100644 index 000000000000..55fd3548e3b6 --- /dev/null +++ b/Documentation/devicetree/bindings/iio/accel/murata,sca3300.yaml @@ -0,0 +1,44 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iio/accel/murata,sca3300.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Murata SCA3300 Accelerometer + +description: | + 3-axis industrial accelerometer with digital SPI interface + https://www.murata.com/en-global/products/sensor/accel/sca3300 + +maintainers: + - Tomas Melin + +properties: + compatible: + enum: + - murata,sca3300 + + reg: + maxItems: 1 + + spi-max-frequency: + maximum: 8000000 + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + spi { + #address-cells = <1>; + #size-cells = <0>; + accelerometer@0 { + compatible = "murata,sca3300"; + reg = <0x0>; + spi-max-frequency = <4000000>; + }; + }; +... -- cgit v1.2.3 From 69c93a7df74b2483016466ec4d25d5c3c3b91bdc Mon Sep 17 00:00:00 2001 From: Jonathan Cameron Date: Sun, 17 Jan 2021 15:38:10 +0000 Subject: iio:ABI docs: Fix up duplicate *_calibbias_* documentation for icm42600 This device has the unusual characteristic that the calibbias values have well defined units (more commonly they are tweaks to a DAC) Unfortunately the previous approach of having more specific documentation in sysfs-bus-iio-icm42600 results in warnings during the documentation build and random ordering in the resulting documentation. To avoid this, add a note to the main documentation on this special characteristic for the icm42600. The _available for calibbias was missing from the main sysfs-bus-iio docs so also add that, allowing us to drop the icm42600 specific file. Fixes $ scripts/get_abi.pl validate warning: Warning: /sys/bus/iio/devices/iio:deviceX/in_accel_x_calibbias is defined 2 times: ./Documentation/ABI/testing/sysfs-bus-iio-icm42600:0 ./Documentation/ABI/testing/sysfs-bus-iio:394 Warning: /sys/bus/iio/devices/iio:deviceX/in_accel_y_calibbias is defined 2 times: ./Documentation/ABI/testing/sysfs-bus-iio-icm42600:1 ./Documentation/ABI/testing/sysfs-bus-iio:395 Warning: /sys/bus/iio/devices/iio:deviceX/in_accel_z_calibbias is defined 2 times: ./Documentation/ABI/testing/sysfs-bus-iio-icm42600:2 ./Documentation/ABI/testing/sysfs-bus-iio:396 Warning: /sys/bus/iio/devices/iio:deviceX/in_anglvel_x_calibbias is defined 2 times: ./Documentation/ABI/testing/sysfs-bus-iio-icm42600:3 ./Documentation/ABI/testing/sysfs-bus-iio:397 Warning: /sys/bus/iio/devices/iio:deviceX/in_anglvel_y_calibbias is defined 2 times: ./Documentation/ABI/testing/sysfs-bus-iio-icm42600:4 ./Documentation/ABI/testing/sysfs-bus-iio:398 Warning: /sys/bus/iio/devices/iio:deviceX/in_anglvel_z_calibbias is defined 2 times: ./Documentation/ABI/testing/sysfs-bus-iio-icm42600:5 ./Documentation/ABI/testing/sysfs-bus-iio:399 Cc: Jean-Baptiste Maneyrol Reported-by: Mauro Carvalho Chehab Signed-off-by: Jonathan Cameron Link: https://lore.kernel.org/r/20210117153816.696693-2-jic23@kernel.org --- Documentation/ABI/testing/sysfs-bus-iio | 13 +++++++++++++ Documentation/ABI/testing/sysfs-bus-iio-icm42600 | 20 -------------------- 2 files changed, 13 insertions(+), 20 deletions(-) delete mode 100644 Documentation/ABI/testing/sysfs-bus-iio-icm42600 (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-bus-iio b/Documentation/ABI/testing/sysfs-bus-iio index 267973541e72..60788a58d08e 100644 --- a/Documentation/ABI/testing/sysfs-bus-iio +++ b/Documentation/ABI/testing/sysfs-bus-iio @@ -455,6 +455,19 @@ Contact: linux-iio@vger.kernel.org Description: Hardware applied calibration offset (assumed to fix production inaccuracies). + icm42600: For this device values are real physical offsets + expressed in SI units (m/s^2 for accelerometers and rad/s + for gyroscope)/ + +What: /sys/bus/iio/devices/iio:deviceX/in_accel_calibbias_available +What: /sys/bus/iio/devices/iio:deviceX/in_anglvel_calibbias_available +KernelVersion: 5.8 +Contact: linux-iio@vger.kernel.org +Description: + Available values of calibbias. Maybe expressed as either of: + + - a small discrete set of values like "0 2 4 6 8" + - a range specified as "[min step max]" What: /sys/bus/iio/devices/iio:deviceX/in_voltageY_calibscale What: /sys/bus/iio/devices/iio:deviceX/in_voltageY_supply_calibscale diff --git a/Documentation/ABI/testing/sysfs-bus-iio-icm42600 b/Documentation/ABI/testing/sysfs-bus-iio-icm42600 deleted file mode 100644 index 0bf1fd4f5bf1..000000000000 --- a/Documentation/ABI/testing/sysfs-bus-iio-icm42600 +++ /dev/null @@ -1,20 +0,0 @@ -What: /sys/bus/iio/devices/iio:deviceX/in_accel_x_calibbias -What: /sys/bus/iio/devices/iio:deviceX/in_accel_y_calibbias -What: /sys/bus/iio/devices/iio:deviceX/in_accel_z_calibbias -What: /sys/bus/iio/devices/iio:deviceX/in_anglvel_x_calibbias -What: /sys/bus/iio/devices/iio:deviceX/in_anglvel_y_calibbias -What: /sys/bus/iio/devices/iio:deviceX/in_anglvel_z_calibbias -KernelVersion: 5.8 -Contact: linux-iio@vger.kernel.org -Description: - Hardware applied calibration offset (assumed to fix production - inaccuracies). Values represent a real physical offset expressed - in SI units (m/s^2 for accelerometer and rad/s for gyroscope). - -What: /sys/bus/iio/devices/iio:deviceX/in_accel_calibbias_available -What: /sys/bus/iio/devices/iio:deviceX/in_anglvel_calibbias_available -KernelVersion: 5.8 -Contact: linux-iio@vger.kernel.org -Description: - Range of available values for hardware offset. Values in SI - units (m/s^2 for accelerometer and rad/s for gyroscope). -- cgit v1.2.3 From 3a879b29916a71e21db2a9ed10977d230fb30452 Mon Sep 17 00:00:00 2001 From: Jonathan Cameron Date: Sun, 17 Jan 2021 15:38:12 +0000 Subject: iio:ABI docs: Drop device specific docs for _powerdown for the adf4371 The interface is standard and the extra info provided on exactly what is being powered down is not of interest to most users. Hence this doesn't need it's own documentation and can rely on the docs in sysfs-bus-iio Fixes $ scripts/get_abi.pl validate Warning: /sys/bus/iio/devices/iio:deviceX/out_altvoltageY_powerdown is defined 2 times: ./Documentation/ABI/testing/sysfs-bus-iio-frequency-adf4371:36 ./Documentation/ABI/testing/sysfs-bus-iio:588 Cc: Alexandru Ardelean Reported-by: Mauro Carvalho Chehab Signed-off-by: Jonathan Cameron Link: https://lore.kernel.org/r/20210117153816.696693-4-jic23@kernel.org --- Documentation/ABI/testing/sysfs-bus-iio-frequency-adf4371 | 8 -------- 1 file changed, 8 deletions(-) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-bus-iio-frequency-adf4371 b/Documentation/ABI/testing/sysfs-bus-iio-frequency-adf4371 index 544548ee794c..457f75903963 100644 --- a/Documentation/ABI/testing/sysfs-bus-iio-frequency-adf4371 +++ b/Documentation/ABI/testing/sysfs-bus-iio-frequency-adf4371 @@ -34,11 +34,3 @@ Description: out_altvoltage2_name: RF16x out_altvoltage3_name: RF32x -What: /sys/bus/iio/devices/iio:deviceX/out_altvoltageY_powerdown -KernelVersion: -Contact: linux-iio@vger.kernel.org -Description: - This attribute allows the user to power down the PLL and it's - RFOut buffers. - Writing 1 causes the specified channel to power down. - Clearing returns to normal operation. -- cgit v1.2.3 From cff8431bf4426831a3083230514f814dc98c03ab Mon Sep 17 00:00:00 2001 From: Jonathan Cameron Date: Sun, 17 Jan 2021 15:38:13 +0000 Subject: iio:ABI docs: Fix issue around repeated definition of out_currentY_raw This one is challenging as both the places this appears in specific drivers are making 'unusual' uses of what looks like a simple output current channel. As a side note, this was particular bit of ABI occurs in other drivers where the use is much more straight forward e.g. dac/ad5421 This patch attempts to make a best effort of adding it to the main docs but retaining enough information. Both of these drivers probably need specific documents being written to describe their unusual interfaces, but those should be in the main documentation, not under Documentation/ABI. That is a non trivial job so left for another time. Fixes $ scripts/get_abi.pl validate Warning: /sys/bus/iio/devices/iio:deviceX/out_currentY_raw is defined 2 times: ./Documentation/ABI/testing/sysfs-bus-iio-light-lm3533-als:43 ./Documentation/ABI/testing/sysfs-bus-iio-health-afe440x:38 Reported-by: Mauro Carvalho Chehab Signed-off-by: Jonathan Cameron Link: https://lore.kernel.org/r/20210117153816.696693-5-jic23@kernel.org --- Documentation/ABI/testing/sysfs-bus-iio | 11 +++++++++++ Documentation/ABI/testing/sysfs-bus-iio-health-afe440x | 10 ++-------- Documentation/ABI/testing/sysfs-bus-iio-light-lm3533-als | 11 +++-------- 3 files changed, 16 insertions(+), 16 deletions(-) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-bus-iio b/Documentation/ABI/testing/sysfs-bus-iio index 60788a58d08e..2210042a11b9 100644 --- a/Documentation/ABI/testing/sysfs-bus-iio +++ b/Documentation/ABI/testing/sysfs-bus-iio @@ -676,6 +676,17 @@ Description: specified and unique if the output corresponds to a single channel. +What: /sys/bus/iio/devices/iio:deviceX/out_currentY_raw +Date: May 2012 +KernelVersion: 3.5 +Contact: Johan Hovold +Description: + Set/get output current for channel Y. Units after application + of scale and offset are milliamps. + For some devices current channels are used to specify + current supplied to elements used in taking a measurement + of a different type. E.g. LED currents. + What: /sys/bus/iio/devices/iio:deviceX/events KernelVersion: 2.6.35 Contact: linux-iio@vger.kernel.org diff --git a/Documentation/ABI/testing/sysfs-bus-iio-health-afe440x b/Documentation/ABI/testing/sysfs-bus-iio-health-afe440x index 66b621f10223..a8e04b41d9ff 100644 --- a/Documentation/ABI/testing/sysfs-bus-iio-health-afe440x +++ b/Documentation/ABI/testing/sysfs-bus-iio-health-afe440x @@ -18,6 +18,8 @@ Description: respectively which simply helper channels containing the calculated difference in the value of stage 1 - 2 and 3 - 4. The values are expressed in 24-bit twos complement. + The LED current for the stage is controlled via + out_currentY_raw. What: /sys/bus/iio/devices/iio:deviceX/in_intensityY_offset Date: May 2016 @@ -35,11 +37,3 @@ Contact: Andrew F. Davis Description: Get and set the resistance and the capacitance settings for the Transimpedance Amplifier during the associated stage. - -What: /sys/bus/iio/devices/iio:deviceX/out_currentY_raw -Date: May 2016 -KernelVersion: -Contact: Andrew F. Davis -Description: - Get and set the LED current for the specified LED active during - this stage. Y is the specific stage number. diff --git a/Documentation/ABI/testing/sysfs-bus-iio-light-lm3533-als b/Documentation/ABI/testing/sysfs-bus-iio-light-lm3533-als index 22c5ea670971..c476d48d0f82 100644 --- a/Documentation/ABI/testing/sysfs-bus-iio-light-lm3533-als +++ b/Documentation/ABI/testing/sysfs-bus-iio-light-lm3533-als @@ -41,14 +41,6 @@ Description: Get the current light zone (0..4) as defined by the in_illuminance0_threshY_{falling,rising} thresholds. -What: /sys/bus/iio/devices/iio:deviceX/out_currentY_raw -Date: May 2012 -KernelVersion: 3.5 -Contact: Johan Hovold -Description: - Get output current for channel Y (0..255), that is, - out_currentY_currentZ_raw, where Z is the current zone. - What: /sys/bus/iio/devices/iio:deviceX/out_currentY_currentZ_raw Date: May 2012 KernelVersion: 3.5 @@ -59,3 +51,6 @@ Description: These values correspond to the ALS-mapper target registers for ALS-mapper Y + 1. + + Note that out_currentY_raw provides the current for the + current zone. -- cgit v1.2.3 From 101af4c20c5a2d56b38d80743cc17d5691ef5506 Mon Sep 17 00:00:00 2001 From: Jonathan Cameron Date: Sun, 17 Jan 2021 15:38:16 +0000 Subject: iio:ABI docs: Move specific description of out_altvoltageX_frequency to main docs. The adf4371 has channels that are very closely coupled, so additional documentation is needed to express these constraints. Unfortunately having the same sysfs filename in multiple documentation does not work well when generating automated documentation. To avoid this issue, we add a new device specific description to the main docs and remove the one in the device specific file. Fixes $ scripts/get_abi.pl validate Warning: /sys/bus/iio/devices/iio:deviceX/out_altvoltageY_frequency is defined 2 times: ./Documentation/ABI/testing/sysfs-bus-iio-frequency-adf4371:0 ./Documentation/ABI/testing/sysfs-bus-iio:599 Cc: Alexandru Ardelean Reported-by: Mauro Carvalho Chehab Signed-off-by: Jonathan Cameron Link: https://lore.kernel.org/r/20210117153816.696693-8-jic23@kernel.org --- Documentation/ABI/testing/sysfs-bus-iio | 19 ++++++++++++++++ .../ABI/testing/sysfs-bus-iio-frequency-adf4371 | 25 ---------------------- 2 files changed, 19 insertions(+), 25 deletions(-) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-bus-iio b/Documentation/ABI/testing/sysfs-bus-iio index 2210042a11b9..587300b388a8 100644 --- a/Documentation/ABI/testing/sysfs-bus-iio +++ b/Documentation/ABI/testing/sysfs-bus-iio @@ -665,6 +665,25 @@ Description: Output frequency for channel Y in Hz. The number must always be specified and unique if the output corresponds to a single channel. + Some drivers have additional constraints: + ADF4371 has an integrated VCO with fundamendal output + frequency ranging from 4000000000 Hz 8000000000 Hz. + + out_altvoltage0_frequency: + A divide by 1, 2, 4, 8, 16, 32 or circuit generates + frequencies from 62500000 Hz to 8000000000 Hz. + out_altvoltage1_frequency: + This channel duplicates the channel 0 frequency + out_altvoltage2_frequency: + A frequency doubler generates frequencies from + 8000000000 Hz to 16000000000 Hz. + out_altvoltage3_frequency: + A frequency quadrupler generates frequencies from + 16000000000 Hz to 32000000000 Hz. + + Note: writes to one of the channels will affect the frequency of + all the other channels, since it involves changing the VCO + fundamental output frequency. What: /sys/bus/iio/devices/iio:deviceX/out_altvoltageY_phase KernelVersion: 3.4.0 diff --git a/Documentation/ABI/testing/sysfs-bus-iio-frequency-adf4371 b/Documentation/ABI/testing/sysfs-bus-iio-frequency-adf4371 index 457f75903963..7fe6935d1448 100644 --- a/Documentation/ABI/testing/sysfs-bus-iio-frequency-adf4371 +++ b/Documentation/ABI/testing/sysfs-bus-iio-frequency-adf4371 @@ -1,28 +1,3 @@ -What: /sys/bus/iio/devices/iio:deviceX/out_altvoltageY_frequency -KernelVersion: -Contact: linux-iio@vger.kernel.org -Description: - Stores the PLL frequency in Hz for channel Y. - Reading returns the actual frequency in Hz. - The ADF4371 has an integrated VCO with fundamendal output - frequency ranging from 4000000000 Hz 8000000000 Hz. - - out_altvoltage0_frequency: - A divide by 1, 2, 4, 8, 16, 32 or circuit generates - frequencies from 62500000 Hz to 8000000000 Hz. - out_altvoltage1_frequency: - This channel duplicates the channel 0 frequency - out_altvoltage2_frequency: - A frequency doubler generates frequencies from - 8000000000 Hz to 16000000000 Hz. - out_altvoltage3_frequency: - A frequency quadrupler generates frequencies from - 16000000000 Hz to 32000000000 Hz. - - Note: writes to one of the channels will affect the frequency of - all the other channels, since it involves changing the VCO - fundamental output frequency. - What: /sys/bus/iio/devices/iio:deviceX/out_altvoltageY_name KernelVersion: Contact: linux-iio@vger.kernel.org -- cgit v1.2.3 From 7dfc4dc385dc851d3247cee6f98afd5ebe580282 Mon Sep 17 00:00:00 2001 From: Tomasz Duszynski Date: Mon, 3 May 2021 08:00:14 +0200 Subject: dt-bindings: iio: chemical: sps30: update binding with serial example sps30 has gained support for serial communication so add example to the binding file. While at it remove reg property from list of required properties because it's no-op in case of serial communication. Signed-off-by: Tomasz Duszynski Signed-off-by: Jonathan Cameron --- .../devicetree/bindings/iio/chemical/sensirion,sps30.yaml | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/iio/chemical/sensirion,sps30.yaml b/Documentation/devicetree/bindings/iio/chemical/sensirion,sps30.yaml index a93d1972a5c2..967500b7e773 100644 --- a/Documentation/devicetree/bindings/iio/chemical/sensirion,sps30.yaml +++ b/Documentation/devicetree/bindings/iio/chemical/sensirion,sps30.yaml @@ -22,7 +22,6 @@ properties: required: - compatible - - reg additionalProperties: false @@ -37,5 +36,11 @@ examples: reg = <0x69>; }; }; + - | + serial { + air-pollution-sensor { + compatible = "sensirion,sps30"; + }; + }; ... -- cgit v1.2.3 From caf0fb3bb38a7e94beb77d31364b0d1ee42aed37 Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Tue, 27 Apr 2021 16:03:00 +0200 Subject: iio: Documentation: move incompatible ABI to obsolete Commit 63cd35f34d2e ("iio: Documentation: update definitions for bufferY and scan_elements") updated iio documentation in order to point to the newly per-buffer API, as it is now possible to support multi buffers. While the previous ABI will be kept forever, the best is for applications to use the 5.11+ ABI. So, move the legacy one ABI/obsolete. This fixes an issue with scripts/get_abi.pl, that doesn't accept two different Kernel version support for the same API set. Fixes: 63cd35f34d2e ("iio: Documentation: update definitions for bufferY and scan_elements") Signed-off-by: Mauro Carvalho Chehab Link: https://lore.kernel.org/r/a2c802049adee6a5710a58082cfdc1132c5e4c11.1619532170.git.mchehab+huawei@kernel.org Signed-off-by: Jonathan Cameron --- Documentation/ABI/obsolete/sysfs-bus-iio | 182 +++++++++++++++++++++++++++++++ Documentation/ABI/testing/sysfs-bus-iio | 82 -------------- 2 files changed, 182 insertions(+), 82 deletions(-) create mode 100644 Documentation/ABI/obsolete/sysfs-bus-iio (limited to 'Documentation') diff --git a/Documentation/ABI/obsolete/sysfs-bus-iio b/Documentation/ABI/obsolete/sysfs-bus-iio new file mode 100644 index 000000000000..c9531bb64816 --- /dev/null +++ b/Documentation/ABI/obsolete/sysfs-bus-iio @@ -0,0 +1,182 @@ +What: /sys/bus/iio/devices/iio:deviceX/buffer/length +KernelVersion: 2.6.35 +Contact: linux-iio@vger.kernel.org +Description: + Number of scans contained by the buffer. + + Since Kernel 5.11, multiple buffers are supported. + so, it is better to use, instead: + /sys/bus/iio/devices/iio:deviceX/bufferY/length + +What: /sys/bus/iio/devices/iio:deviceX/buffer/enable +KernelVersion: 2.6.35 +Contact: linux-iio@vger.kernel.org +Description: + Actually start the buffer capture up. Will start trigger + if first device and appropriate. + + Since Kernel 5.11, multiple buffers are supported. + so, it is better to use, instead: + /sys/bus/iio/devices/iio:deviceX/bufferY/enable + +What: /sys/bus/iio/devices/iio:deviceX/scan_elements +KernelVersion: 2.6.37 +Contact: linux-iio@vger.kernel.org +Description: + Directory containing interfaces for elements that will be + captured for a single triggered sample set in the buffer. + + Since kernel 5.11 the scan_elements attributes are merged into + the bufferY directory, to be configurable per buffer. + +What: /sys/.../iio:deviceX/scan_elements/in_accel_x_en +What: /sys/.../iio:deviceX/scan_elements/in_accel_y_en +What: /sys/.../iio:deviceX/scan_elements/in_accel_z_en +What: /sys/.../iio:deviceX/scan_elements/in_anglvel_x_en +What: /sys/.../iio:deviceX/scan_elements/in_anglvel_y_en +What: /sys/.../iio:deviceX/scan_elements/in_anglvel_z_en +What: /sys/.../iio:deviceX/scan_elements/in_magn_x_en +What: /sys/.../iio:deviceX/scan_elements/in_magn_y_en +What: /sys/.../iio:deviceX/scan_elements/in_magn_z_en +What: /sys/.../iio:deviceX/scan_elements/in_rot_from_north_magnetic_en +What: /sys/.../iio:deviceX/scan_elements/in_rot_from_north_true_en +What: /sys/.../iio:deviceX/scan_elements/in_rot_from_north_magnetic_tilt_comp_en +What: /sys/.../iio:deviceX/scan_elements/in_rot_from_north_true_tilt_comp_en +What: /sys/.../iio:deviceX/scan_elements/in_timestamp_en +What: /sys/.../iio:deviceX/scan_elements/in_voltageY_supply_en +What: /sys/.../iio:deviceX/scan_elements/in_voltageY_en +What: /sys/.../iio:deviceX/scan_elements/in_voltageY-voltageZ_en +What: /sys/.../iio:deviceX/scan_elements/in_voltageY_i_en +What: /sys/.../iio:deviceX/scan_elements/in_voltageY_q_en +What: /sys/.../iio:deviceX/scan_elements/in_voltage_i_en +What: /sys/.../iio:deviceX/scan_elements/in_voltage_q_en +What: /sys/.../iio:deviceX/scan_elements/in_incli_x_en +What: /sys/.../iio:deviceX/scan_elements/in_incli_y_en +What: /sys/.../iio:deviceX/scan_elements/in_pressureY_en +What: /sys/.../iio:deviceX/scan_elements/in_pressure_en +What: /sys/.../iio:deviceX/scan_elements/in_rot_quaternion_en +What: /sys/.../iio:deviceX/scan_elements/in_proximity_en +KernelVersion: 2.6.37 +Contact: linux-iio@vger.kernel.org +Description: + Scan element control for triggered data capture. + + Since kernel 5.11 the scan_elements attributes are merged into + the bufferY directory, to be configurable per buffer. + +What: /sys/.../iio:deviceX/scan_elements/in_accel_type +What: /sys/.../iio:deviceX/scan_elements/in_anglvel_type +What: /sys/.../iio:deviceX/scan_elements/in_magn_type +What: /sys/.../iio:deviceX/scan_elements/in_incli_type +What: /sys/.../iio:deviceX/scan_elements/in_voltageY_type +What: /sys/.../iio:deviceX/scan_elements/in_voltage_type +What: /sys/.../iio:deviceX/scan_elements/in_voltageY_supply_type +What: /sys/.../iio:deviceX/scan_elements/in_voltageY_i_type +What: /sys/.../iio:deviceX/scan_elements/in_voltageY_q_type +What: /sys/.../iio:deviceX/scan_elements/in_voltage_i_type +What: /sys/.../iio:deviceX/scan_elements/in_voltage_q_type +What: /sys/.../iio:deviceX/scan_elements/in_timestamp_type +What: /sys/.../iio:deviceX/scan_elements/in_pressureY_type +What: /sys/.../iio:deviceX/scan_elements/in_pressure_type +What: /sys/.../iio:deviceX/scan_elements/in_rot_quaternion_type +What: /sys/.../iio:deviceX/scan_elements/in_proximity_type +KernelVersion: 2.6.37 +Contact: linux-iio@vger.kernel.org +Description: + Description of the scan element data storage within the buffer + and hence the form in which it is read from user-space. + Form is [be|le]:[s|u]bits/storagebits[>>shift]. + be or le specifies big or little endian. s or u specifies if + signed (2's complement) or unsigned. bits is the number of bits + of data and storagebits is the space (after padding) that it + occupies in the buffer. shift if specified, is the shift that + needs to be applied prior to masking out unused bits. Some + devices put their data in the middle of the transferred elements + with additional information on both sides. Note that some + devices will have additional information in the unused bits + so to get a clean value, the bits value must be used to mask + the buffer output value appropriately. The storagebits value + also specifies the data alignment. So s48/64>>2 will be a + signed 48 bit integer stored in a 64 bit location aligned to + a 64 bit boundary. To obtain the clean value, shift right 2 + and apply a mask to zero the top 16 bits of the result. + For other storage combinations this attribute will be extended + appropriately. + + Since kernel 5.11 the scan_elements attributes are merged into + the bufferY directory, to be configurable per buffer. + +What: /sys/.../iio:deviceX/scan_elements/in_voltageY_index +What: /sys/.../iio:deviceX/scan_elements/in_voltageY_supply_index +What: /sys/.../iio:deviceX/scan_elements/in_voltageY_i_index +What: /sys/.../iio:deviceX/scan_elements/in_voltageY_q_index +What: /sys/.../iio:deviceX/scan_elements/in_voltage_i_index +What: /sys/.../iio:deviceX/scan_elements/in_voltage_q_index +What: /sys/.../iio:deviceX/scan_elements/in_accel_x_index +What: /sys/.../iio:deviceX/scan_elements/in_accel_y_index +What: /sys/.../iio:deviceX/scan_elements/in_accel_z_index +What: /sys/.../iio:deviceX/scan_elements/in_anglvel_x_index +What: /sys/.../iio:deviceX/scan_elements/in_anglvel_y_index +What: /sys/.../iio:deviceX/scan_elements/in_anglvel_z_index +What: /sys/.../iio:deviceX/scan_elements/in_magn_x_index +What: /sys/.../iio:deviceX/scan_elements/in_magn_y_index +What: /sys/.../iio:deviceX/scan_elements/in_magn_z_index +What: /sys/.../iio:deviceX/scan_elements/in_rot_from_north_magnetic_index +What: /sys/.../iio:deviceX/scan_elements/in_rot_from_north_true_index +What: /sys/.../iio:deviceX/scan_elements/in_rot_from_north_magnetic_tilt_comp_index +What: /sys/.../iio:deviceX/scan_elements/in_rot_from_north_true_tilt_comp_index +What: /sys/.../iio:deviceX/scan_elements/in_incli_x_index +What: /sys/.../iio:deviceX/scan_elements/in_incli_y_index +What: /sys/.../iio:deviceX/scan_elements/in_timestamp_index +What: /sys/.../iio:deviceX/scan_elements/in_pressureY_index +What: /sys/.../iio:deviceX/scan_elements/in_pressure_index +What: /sys/.../iio:deviceX/scan_elements/in_rot_quaternion_index +What: /sys/.../iio:deviceX/scan_elements/in_proximity_index +KernelVersion: 2.6.37 +Description: + A single positive integer specifying the position of this + scan element in the buffer. Note these are not dependent on + what is enabled and may not be contiguous. Thus for user-space + to establish the full layout these must be used in conjunction + with all _en attributes to establish which channels are present, + and the relevant _type attributes to establish the data storage + format. + + Since kernel 5.11 the scan_elements attributes are merged into + the bufferY directory, to be configurable per buffer. + +What: /sys/bus/iio/devices/iio:deviceX/buffer/watermark +KernelVersion: 4.2 +Contact: linux-iio@vger.kernel.org +Description: + A single positive integer specifying the maximum number of scan + elements to wait for. + + Poll will block until the watermark is reached. + + Blocking read will wait until the minimum between the requested + read amount or the low water mark is available. + + Non-blocking read will retrieve the available samples from the + buffer even if there are less samples then watermark level. This + allows the application to block on poll with a timeout and read + the available samples after the timeout expires and thus have a + maximum delay guarantee. + + Since Kernel 5.11, multiple buffers are supported. + so, it is better to use, instead: + /sys/bus/iio/devices/iio:deviceX/bufferY/watermark + +What: /sys/bus/iio/devices/iio:deviceX/buffer/data_available +KernelVersion: 4.16 +Contact: linux-iio@vger.kernel.org +Description: + A read-only value indicating the bytes of data available in the + buffer. In the case of an output buffer, this indicates the + amount of empty space available to write data to. In the case of + an input buffer, this indicates the amount of data available for + reading. + + Since Kernel 5.11, multiple buffers are supported. + so, it is better to use, instead: + /sys/bus/iio/devices/iio:deviceX/bufferY/data_available diff --git a/Documentation/ABI/testing/sysfs-bus-iio b/Documentation/ABI/testing/sysfs-bus-iio index 587300b388a8..29c1097c5722 100644 --- a/Documentation/ABI/testing/sysfs-bus-iio +++ b/Documentation/ABI/testing/sysfs-bus-iio @@ -1238,16 +1238,12 @@ Description: The name of the trigger source being used, as per string given in /sys/class/iio/triggerY/name. -What: /sys/bus/iio/devices/iio:deviceX/buffer/length -KernelVersion: 2.6.35 What: /sys/bus/iio/devices/iio:deviceX/bufferY/length KernelVersion: 5.11 Contact: linux-iio@vger.kernel.org Description: Number of scans contained by the buffer. -What: /sys/bus/iio/devices/iio:deviceX/buffer/enable -KernelVersion: 2.6.35 What: /sys/bus/iio/devices/iio:deviceX/bufferY/enable KernelVersion: 5.11 Contact: linux-iio@vger.kernel.org @@ -1255,8 +1251,6 @@ Description: Actually start the buffer capture up. Will start trigger if first device and appropriate. -What: /sys/bus/iio/devices/iio:deviceX/scan_elements -KernelVersion: 2.6.37 What: /sys/bus/iio/devices/iio:deviceX/bufferY KernelVersion: 5.11 Contact: linux-iio@vger.kernel.org @@ -1267,34 +1261,6 @@ Description: Since kernel 5.11 the scan_elements attributes are merged into the bufferY directory, to be configurable per buffer. -What: /sys/.../iio:deviceX/scan_elements/in_accel_x_en -What: /sys/.../iio:deviceX/scan_elements/in_accel_y_en -What: /sys/.../iio:deviceX/scan_elements/in_accel_z_en -What: /sys/.../iio:deviceX/scan_elements/in_anglvel_x_en -What: /sys/.../iio:deviceX/scan_elements/in_anglvel_y_en -What: /sys/.../iio:deviceX/scan_elements/in_anglvel_z_en -What: /sys/.../iio:deviceX/scan_elements/in_magn_x_en -What: /sys/.../iio:deviceX/scan_elements/in_magn_y_en -What: /sys/.../iio:deviceX/scan_elements/in_magn_z_en -What: /sys/.../iio:deviceX/scan_elements/in_rot_from_north_magnetic_en -What: /sys/.../iio:deviceX/scan_elements/in_rot_from_north_true_en -What: /sys/.../iio:deviceX/scan_elements/in_rot_from_north_magnetic_tilt_comp_en -What: /sys/.../iio:deviceX/scan_elements/in_rot_from_north_true_tilt_comp_en -What: /sys/.../iio:deviceX/scan_elements/in_timestamp_en -What: /sys/.../iio:deviceX/scan_elements/in_voltageY_supply_en -What: /sys/.../iio:deviceX/scan_elements/in_voltageY_en -What: /sys/.../iio:deviceX/scan_elements/in_voltageY-voltageZ_en -What: /sys/.../iio:deviceX/scan_elements/in_voltageY_i_en -What: /sys/.../iio:deviceX/scan_elements/in_voltageY_q_en -What: /sys/.../iio:deviceX/scan_elements/in_voltage_i_en -What: /sys/.../iio:deviceX/scan_elements/in_voltage_q_en -What: /sys/.../iio:deviceX/scan_elements/in_incli_x_en -What: /sys/.../iio:deviceX/scan_elements/in_incli_y_en -What: /sys/.../iio:deviceX/scan_elements/in_pressureY_en -What: /sys/.../iio:deviceX/scan_elements/in_pressure_en -What: /sys/.../iio:deviceX/scan_elements/in_rot_quaternion_en -What: /sys/.../iio:deviceX/scan_elements/in_proximity_en -KernelVersion: 2.6.37 What: /sys/.../iio:deviceX/bufferY/in_accel_x_en What: /sys/.../iio:deviceX/bufferY/in_accel_y_en What: /sys/.../iio:deviceX/bufferY/in_accel_z_en @@ -1327,23 +1293,6 @@ Contact: linux-iio@vger.kernel.org Description: Scan element control for triggered data capture. -What: /sys/.../iio:deviceX/scan_elements/in_accel_type -What: /sys/.../iio:deviceX/scan_elements/in_anglvel_type -What: /sys/.../iio:deviceX/scan_elements/in_magn_type -What: /sys/.../iio:deviceX/scan_elements/in_incli_type -What: /sys/.../iio:deviceX/scan_elements/in_voltageY_type -What: /sys/.../iio:deviceX/scan_elements/in_voltage_type -What: /sys/.../iio:deviceX/scan_elements/in_voltageY_supply_type -What: /sys/.../iio:deviceX/scan_elements/in_voltageY_i_type -What: /sys/.../iio:deviceX/scan_elements/in_voltageY_q_type -What: /sys/.../iio:deviceX/scan_elements/in_voltage_i_type -What: /sys/.../iio:deviceX/scan_elements/in_voltage_q_type -What: /sys/.../iio:deviceX/scan_elements/in_timestamp_type -What: /sys/.../iio:deviceX/scan_elements/in_pressureY_type -What: /sys/.../iio:deviceX/scan_elements/in_pressure_type -What: /sys/.../iio:deviceX/scan_elements/in_rot_quaternion_type -What: /sys/.../iio:deviceX/scan_elements/in_proximity_type -KernelVersion: 2.6.37 What: /sys/.../iio:deviceX/bufferY/in_accel_type What: /sys/.../iio:deviceX/bufferY/in_anglvel_type What: /sys/.../iio:deviceX/bufferY/in_magn_type @@ -1390,33 +1339,6 @@ Description: If the type parameter can take one of a small set of values, this attribute lists them. -What: /sys/.../iio:deviceX/scan_elements/in_voltageY_index -What: /sys/.../iio:deviceX/scan_elements/in_voltageY_supply_index -What: /sys/.../iio:deviceX/scan_elements/in_voltageY_i_index -What: /sys/.../iio:deviceX/scan_elements/in_voltageY_q_index -What: /sys/.../iio:deviceX/scan_elements/in_voltage_i_index -What: /sys/.../iio:deviceX/scan_elements/in_voltage_q_index -What: /sys/.../iio:deviceX/scan_elements/in_accel_x_index -What: /sys/.../iio:deviceX/scan_elements/in_accel_y_index -What: /sys/.../iio:deviceX/scan_elements/in_accel_z_index -What: /sys/.../iio:deviceX/scan_elements/in_anglvel_x_index -What: /sys/.../iio:deviceX/scan_elements/in_anglvel_y_index -What: /sys/.../iio:deviceX/scan_elements/in_anglvel_z_index -What: /sys/.../iio:deviceX/scan_elements/in_magn_x_index -What: /sys/.../iio:deviceX/scan_elements/in_magn_y_index -What: /sys/.../iio:deviceX/scan_elements/in_magn_z_index -What: /sys/.../iio:deviceX/scan_elements/in_rot_from_north_magnetic_index -What: /sys/.../iio:deviceX/scan_elements/in_rot_from_north_true_index -What: /sys/.../iio:deviceX/scan_elements/in_rot_from_north_magnetic_tilt_comp_index -What: /sys/.../iio:deviceX/scan_elements/in_rot_from_north_true_tilt_comp_index -What: /sys/.../iio:deviceX/scan_elements/in_incli_x_index -What: /sys/.../iio:deviceX/scan_elements/in_incli_y_index -What: /sys/.../iio:deviceX/scan_elements/in_timestamp_index -What: /sys/.../iio:deviceX/scan_elements/in_pressureY_index -What: /sys/.../iio:deviceX/scan_elements/in_pressure_index -What: /sys/.../iio:deviceX/scan_elements/in_rot_quaternion_index -What: /sys/.../iio:deviceX/scan_elements/in_proximity_index -KernelVersion: 2.6.37 What: /sys/.../iio:deviceX/bufferY/in_voltageY_index What: /sys/.../iio:deviceX/bufferY/in_voltageY_supply_index What: /sys/.../iio:deviceX/bufferY/in_voltageY_i_index @@ -1656,8 +1578,6 @@ Description: Specifies number of seconds in which we compute the steps that occur in order to decide if the consumer is making steps. -What: /sys/bus/iio/devices/iio:deviceX/buffer/watermark -KernelVersion: 4.2 What: /sys/bus/iio/devices/iio:deviceX/bufferY/watermark KernelVersion: 5.11 Contact: linux-iio@vger.kernel.org @@ -1676,8 +1596,6 @@ Description: the available samples after the timeout expires and thus have a maximum delay guarantee. -What: /sys/bus/iio/devices/iio:deviceX/buffer/data_available -KernelVersion: 4.16 What: /sys/bus/iio/devices/iio:deviceX/bufferY/data_available KernelVersion: 5.11 Contact: linux-iio@vger.kernel.org -- cgit v1.2.3 From f7e196fc0815dea074b861a97503bf0d330f7165 Mon Sep 17 00:00:00 2001 From: Oleksij Rempel Date: Wed, 28 Apr 2021 09:32:06 +0200 Subject: dt-bindings:iio:adc: add generic settling-time-us and oversampling-ratio channel properties Settling time and over sampling is a typical challenge for different IIO ADC devices. So, introduce channel specific settling-time-us and oversampling-ratio properties to cover this use case. Signed-off-by: Oleksij Rempel Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20210428073208.19570-2-o.rempel@pengutronix.de Signed-off-by: Jonathan Cameron --- Documentation/devicetree/bindings/iio/adc/adc.yaml | 12 ++++++++++++ 1 file changed, 12 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/iio/adc/adc.yaml b/Documentation/devicetree/bindings/iio/adc/adc.yaml index 912a7635edc4..db348fcbb52c 100644 --- a/Documentation/devicetree/bindings/iio/adc/adc.yaml +++ b/Documentation/devicetree/bindings/iio/adc/adc.yaml @@ -39,4 +39,16 @@ properties: The first value specifies the positive input pin, the second specifies the negative input pin. + settling-time-us: + description: + Time between enabling the channel and first stable readings. + + oversampling-ratio: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + Oversampling is used as replacement of or addition to the low-pass filter. + In some cases, the desired filtering characteristics are a function the + device design and can interact with other characteristics such as + settling time. + additionalProperties: true -- cgit v1.2.3 From 03f2193a6bea24c8cd280433f783b417cda4c2e5 Mon Sep 17 00:00:00 2001 From: Oleksij Rempel Date: Wed, 28 Apr 2021 09:32:07 +0200 Subject: dt-bindings:iio:adc: add documentation for TI TSC2046 controller Add a binding documentation for the TI TSC2046 touchscreen controllers ADC functionality. Signed-off-by: Oleksij Rempel Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20210428073208.19570-3-o.rempel@pengutronix.de Signed-off-by: Jonathan Cameron --- .../devicetree/bindings/iio/adc/ti,tsc2046.yaml | 115 +++++++++++++++++++++ 1 file changed, 115 insertions(+) create mode 100644 Documentation/devicetree/bindings/iio/adc/ti,tsc2046.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/iio/adc/ti,tsc2046.yaml b/Documentation/devicetree/bindings/iio/adc/ti,tsc2046.yaml new file mode 100644 index 000000000000..601d69971d84 --- /dev/null +++ b/Documentation/devicetree/bindings/iio/adc/ti,tsc2046.yaml @@ -0,0 +1,115 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iio/adc/ti,tsc2046.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Texas Instruments TSC2046 touch screen controller. + +maintainers: + - Oleksij Rempel + +description: | + TSC2046 is a touch screen controller with 8 channels ADC. + +properties: + compatible: + enum: + - ti,tsc2046e-adc + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + spi-max-frequency: true + + "#io-channel-cells": + const: 1 + + '#address-cells': + const: 1 + + '#size-cells': + const: 0 + +required: + - compatible + - reg + +patternProperties: + "^channel@[0-7]$": + $ref: "adc.yaml" + type: object + + properties: + reg: + description: | + The channel number. It can have up to 8 channels + items: + minimum: 0 + maximum: 7 + + settling-time-us: true + oversampling-ratio: true + + required: + - reg + + additionalProperties: false + +additionalProperties: false + +examples: + - | + #include + spi { + #address-cells = <1>; + #size-cells = <0>; + + adc@0 { + compatible = "ti,tsc2046e-adc"; + reg = <0>; + spi-max-frequency = <1000000>; + interrupts-extended = <&gpio3 20 IRQ_TYPE_LEVEL_LOW>; + #io-channel-cells = <1>; + + #address-cells = <1>; + #size-cells = <0>; + + channel@0 { + reg = <0>; + }; + channel@1 { + reg = <1>; + settling-time-us = <700>; + oversampling-ratio = <5>; + }; + channel@2 { + reg = <2>; + }; + channel@3 { + reg = <3>; + settling-time-us = <700>; + oversampling-ratio = <5>; + }; + channel@4 { + reg = <4>; + settling-time-us = <700>; + oversampling-ratio = <5>; + }; + channel@5 { + reg = <5>; + settling-time-us = <700>; + oversampling-ratio = <5>; + }; + channel@6 { + reg = <6>; + }; + channel@7 { + reg = <7>; + }; + }; + }; +... -- cgit v1.2.3 From 8cd401310bc4b95f2e39275370f8550a6d05cd93 Mon Sep 17 00:00:00 2001 From: Andy Shevchenko Date: Wed, 14 Apr 2021 22:54:54 +0300 Subject: dt-bindings: iio: st,st-sensors: Add LSM9DS0 compatible string Enumerate LSM9DS0 (accelerometer and magnetometer parts) via 'st,lsm9ds0-imu' compatible string. Signed-off-by: Andy Shevchenko Acked-by: Rob Herring Link: https://lore.kernel.org/r/20210414195454.84183-7-andriy.shevchenko@linux.intel.com Signed-off-by: Jonathan Cameron --- Documentation/devicetree/bindings/iio/st,st-sensors.yaml | 3 +++ 1 file changed, 3 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/iio/st,st-sensors.yaml b/Documentation/devicetree/bindings/iio/st,st-sensors.yaml index d7c274a4cdc3..b2a1e42c56fa 100644 --- a/Documentation/devicetree/bindings/iio/st,st-sensors.yaml +++ b/Documentation/devicetree/bindings/iio/st,st-sensors.yaml @@ -75,6 +75,9 @@ properties: - st,lps331ap-press - st,lps33hw - st,lps35hw + - description: IMUs + enum: + - st,lsm9ds0-imu - description: Deprecated bindings enum: - st,lis302dl-spi -- cgit v1.2.3 From ef8512b3b2c8f69d103d8910ea65879ab6bef7d9 Mon Sep 17 00:00:00 2001 From: Jonathan Cameron Date: Sat, 24 Apr 2021 18:30:15 +0100 Subject: dt-bindings:iio:dac:ad5755: txt to yaml format conversion. Straight forward conversion. Only fiddly bit is the XOR of spi-cpol and spi-cpha. Signed-off-by: Jonathan Cameron Cc: Sean Nyekjaer Link: https://lore.kernel.org/r/20201031184854.745828-40-jic23@kernel.org Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20210424173015.534941-1-jic23@kernel.org --- .../devicetree/bindings/iio/dac/ad5755.txt | 124 --------------- .../devicetree/bindings/iio/dac/adi,ad5755.yaml | 169 +++++++++++++++++++++ 2 files changed, 169 insertions(+), 124 deletions(-) delete mode 100644 Documentation/devicetree/bindings/iio/dac/ad5755.txt create mode 100644 Documentation/devicetree/bindings/iio/dac/adi,ad5755.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/iio/dac/ad5755.txt b/Documentation/devicetree/bindings/iio/dac/ad5755.txt deleted file mode 100644 index 502e1e55adbd..000000000000 --- a/Documentation/devicetree/bindings/iio/dac/ad5755.txt +++ /dev/null @@ -1,124 +0,0 @@ -* Analog Devices AD5755 IIO Multi-Channel DAC Linux Driver - -Required properties: - - compatible: Has to contain one of the following: - adi,ad5755 - adi,ad5755-1 - adi,ad5757 - adi,ad5735 - adi,ad5737 - - - reg: spi chip select number for the device - - spi-cpha or spi-cpol: is the only modes that is supported - -Recommended properties: - - spi-max-frequency: Definition as per - Documentation/devicetree/bindings/spi/spi-bus.txt - -Optional properties: -See include/dt-bindings/iio/ad5755.h - - adi,ext-dc-dc-compenstation-resistor: boolean set if the hardware have an - external resistor and thereby bypasses - the internal compensation resistor. - - adi,dc-dc-phase: - Valid values for DC DC Phase control is: - 0: All dc-to-dc converters clock on the same edge. - 1: Channel A and Channel B clock on the same edge, - Channel C and Channel D clock on opposite edges. - 2: Channel A and Channel C clock on the same edge, - Channel B and Channel D clock on opposite edges. - 3: Channel A, Channel B, Channel C, and Channel D - clock 90 degrees out of phase from each other. - - adi,dc-dc-freq-hz: - Valid values for DC DC frequency is [Hz]: - 250000 - 410000 - 650000 - - adi,dc-dc-max-microvolt: - Valid values for the maximum allowed Vboost voltage supplied by - the dc-to-dc converter is: - 23000000 - 24500000 - 27000000 - 29500000 - -Optional for every channel: - - adi,mode: - Valid values for DAC modes is: - 0: 0 V to 5 V voltage range. - 1: 0 V to 10 V voltage range. - 2: Plus minus 5 V voltage range. - 3: Plus minus 10 V voltage range. - 4: 4 mA to 20 mA current range. - 5: 0 mA to 20 mA current range. - 6: 0 mA to 24 mA current range. - - adi,ext-current-sense-resistor: boolean set if the hardware a external - current sense resistor. - - adi,enable-voltage-overrange: boolean enable voltage overrange - - adi,slew: Array of slewrate settings should contain 3 fields: - 1: Should be either 0 or 1 in order to enable or disable slewrate. - 2: Slew rate settings: - Valid values for the slew rate update frequency: - 64000 - 32000 - 16000 - 8000 - 4000 - 2000 - 1000 - 500 - 250 - 125 - 64 - 32 - 16 - 8 - 4 - 0 - 3: Slew step size: - Valid values for the step size LSBs: - 1 - 2 - 4 - 16 - 32 - 64 - 128 - 256 - -Example: -dac@0 { - #address-cells = <1>; - #size-cells = <0>; - compatible = "adi,ad5755"; - reg = <0>; - spi-max-frequency = <1000000>; - spi-cpha; - adi,dc-dc-phase = <0>; - adi,dc-dc-freq-hz = <410000>; - adi,dc-dc-max-microvolt = <23000000>; - channel@0 { - reg = <0>; - adi,mode = <4>; - adi,ext-current-sense-resistor; - adi,slew = <0 64000 1>; - }; - channel@1 { - reg = <1>; - adi,mode = <4>; - adi,ext-current-sense-resistor; - adi,slew = <0 64000 1>; - }; - channel@2 { - reg = <2>; - adi,mode = <4>; - adi,ext-current-sense-resistor; - adi,slew = <0 64000 1>; - }; - channel@3 { - reg = <3>; - adi,mode = <4>; - adi,ext-current-sense-resistor; - adi,slew = <0 64000 1>; - }; -}; diff --git a/Documentation/devicetree/bindings/iio/dac/adi,ad5755.yaml b/Documentation/devicetree/bindings/iio/dac/adi,ad5755.yaml new file mode 100644 index 000000000000..be419ac46caa --- /dev/null +++ b/Documentation/devicetree/bindings/iio/dac/adi,ad5755.yaml @@ -0,0 +1,169 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iio/dac/adi,ad5755.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Analog Devices AD5755 Multi-Channel DAC + +maintainers: + - Sean Nyekjaer + +properties: + compatible: + enum: + - adi,ad5755 + - adi,ad5755-1 + - adi,ad5757 + - adi,ad5735 + - adi,ad5737 + + reg: + maxItems: 1 + + spi-cpha: + description: Either this or spi-cpol but not both. + spi-cpol: true + + spi-max-frequency: true + + adi,ext-dc-dc-compenstation-resistor: + $ref: /schemas/types.yaml#/definitions/flag + description: + Set if the hardware have an external resistor and thereby bypasses + the internal compensation resistor. + + adi,dc-dc-phase: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1, 2, 3] + description: | + Valid values for DC DC Phase control is: + 0: All dc-to-dc converters clock on the same edge. + 1: Channel A and Channel B clock on the same edge, + Channel C and Channel D clock on opposite edges. + 2: Channel A and Channel C clock on the same edge, + Channel B and Channel D clock on opposite edges. + 3: Channel A, Channel B, Channel C, and Channel D + clock 90 degrees out of phase from each other. + + adi,dc-dc-freq-hz: + enum: [250000, 410000, 650000] + + adi,dc-dc-max-microvolt: + description: + Maximum allowed Vboost voltage supplied by the dc-to-dc converter. + enum: [23000000, 24500000, 27000000, 29500000] + + "#address-cells": + const: 1 + + "#size-cells": + const: 0 + + "#io-channel-cells": + const: 1 + +required: + - compatible + - reg + +additionalProperties: false + +patternProperties: + "^channel@[0-7]$": + type: object + description: Child node to describe a channel + properties: + reg: + maxItems: 1 + + adi,mode: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 6 + description: | + Valid values for DAC modes is: + 0: 0 V to 5 V voltage range. + 1: 0 V to 10 V voltage range. + 2: Plus minus 5 V voltage range. + 3: Plus minus 10 V voltage range. + 4: 4 mA to 20 mA current range. + 5: 0 mA to 20 mA current range. + 6: 0 mA to 24 mA current range. + + adi,ext-current-sense-resistor: + $ref: /schemas/types.yaml#/definitions/flag + description: + Set if the hardware has an external current sense resistor + + adi,enable-voltage-overrange: + $ref: /schemas/types.yaml#/definitions/flag + description: Enable voltage overrange + + adi,slew: + $ref: /schemas/types.yaml#/definitions/uint32-array + description: | + Array of slewrate settings should contain 3 fields: + 1: Should be either 0 or 1 in order to enable or disable slewrate. + 2: Slew rate update frequency + 3: Slew step size + items: + - enum: [0, 1] + - enum: [64000, 32000, 16000, 8000, 4000, 2000, 1000, 500, 250, 125, 64, 32, 16, 8, 4, 0] + - enum: [1, 2, 4, 16, 32, 64, 128, 256] + + required: + - reg + + additionalProperties: false + +oneOf: + - required: + - spi-cpha + - required: + - spi-cpol + +examples: + - | + #include + spi { + #address-cells = <1>; + #size-cells = <0>; + + dac@0 { + #address-cells = <1>; + #size-cells = <0>; + compatible = "adi,ad5755"; + reg = <0>; + spi-max-frequency = <1000000>; + spi-cpha; + adi,dc-dc-phase = <0>; + adi,dc-dc-freq-hz = <410000>; + adi,dc-dc-max-microvolt = <23000000>; + channel@0 { + reg = <0>; + adi,mode = <4>; + adi,ext-current-sense-resistor; + adi,slew = <0 64000 1>; + }; + channel@1 { + reg = <1>; + adi,mode = <4>; + adi,ext-current-sense-resistor; + adi,slew = <0 64000 1>; + }; + channel@2 { + reg = <2>; + adi,mode = <4>; + adi,ext-current-sense-resistor; + adi,slew = <0 64000 1>; + }; + channel@3 { + reg = <3>; + adi,mode = <4>; + adi,ext-current-sense-resistor; + adi,slew = <0 64000 1>; + }; + }; + }; +... -- cgit v1.2.3 From 7f36da1455730474b47f47712f37a3060fc2fe50 Mon Sep 17 00:00:00 2001 From: Sean Nyekjaer Date: Thu, 6 May 2021 09:09:36 +0200 Subject: dt-bindings: iio: accel: fxls8962af: add bindings Add devicetree binding for the NXP FXLS8962AF/FXLS8964AF accelerometer sensor. Signed-off-by: Sean Nyekjaer Reviewed-by: Rob Herring Signed-off-by: Jonathan Cameron --- .../bindings/iio/accel/nxp,fxls8962af.yaml | 80 ++++++++++++++++++++++ 1 file changed, 80 insertions(+) create mode 100644 Documentation/devicetree/bindings/iio/accel/nxp,fxls8962af.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/iio/accel/nxp,fxls8962af.yaml b/Documentation/devicetree/bindings/iio/accel/nxp,fxls8962af.yaml new file mode 100644 index 000000000000..ad529ab2c6e2 --- /dev/null +++ b/Documentation/devicetree/bindings/iio/accel/nxp,fxls8962af.yaml @@ -0,0 +1,80 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iio/accel/nxp,fxls8962af.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NXP FXLS8962AF/FXLS8964AF Accelerometer driver + +maintainers: + - Sean Nyekjaer + +description: | + NXP FXLS8962AF/FXLS8964AF Accelerometer driver that supports + SPI and I2C interface. + https://www.nxp.com/docs/en/data-sheet/FXLS8962AF.pdf + https://www.nxp.com/docs/en/data-sheet/FXLS8964AF.pdf + +properties: + compatible: + enum: + - nxp,fxls8962af + - nxp,fxls8964af + + reg: + maxItems: 1 + + vdd-supply: + description: phandle to the regulator that provides power to the accelerometer + + spi-max-frequency: true + + interrupts: + maxItems: 1 + + interrupt-names: + enum: + - INT1 + - INT2 + + drive-open-drain: + type: boolean + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + #include + i2c0 { + #address-cells = <1>; + #size-cells = <0>; + + /* Example for a I2C device node */ + accelerometer@62 { + compatible = "nxp,fxls8962af"; + reg = <0x62>; + interrupt-parent = <&gpio0>; + interrupts = <0 IRQ_TYPE_LEVEL_HIGH>; + interrupt-names = "INT1"; + }; + }; + - | + #include + spi0 { + #address-cells = <1>; + #size-cells = <0>; + + /* Example for a SPI device node */ + accelerometer@0 { + compatible = "nxp,fxls8962af"; + reg = <0>; + spi-max-frequency = <4000000>; + interrupt-parent = <&gpio0>; + interrupts = <0 IRQ_TYPE_LEVEL_HIGH>; + interrupt-names = "INT1"; + }; + }; -- cgit v1.2.3 From 347978983b3453bc4d5a917ea34d1cd53b5fea08 Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Thu, 6 May 2021 11:06:37 -0400 Subject: dt-bindings: iio: afe: current-sense-shunt: add io-channel-cells The current-sense-shunt is an IIO provider thus can be referenced by IIO consumers (via "io-channels" property in consumer device node). Such provider is required to describe number of cells used in phandle lookup with "io-channel-cells" property. This also fixes dtbs_check warnings like: arch/arm/boot/dts/s5pv210-fascinate4g.dt.yaml: current-sense-shunt: '#io-channel-cells' does not match any of the regexes: 'pinctrl-[0-9]+' Fixes: ce66e52b6c16 ("dt-bindings:iio:afe:current-sense-shunt: txt to yaml conversion.") Signed-off-by: Krzysztof Kozlowski Reviewed-by: Rob Herring Signed-off-by: Jonathan Cameron --- Documentation/devicetree/bindings/iio/afe/current-sense-shunt.yaml | 4 ++++ 1 file changed, 4 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/iio/afe/current-sense-shunt.yaml b/Documentation/devicetree/bindings/iio/afe/current-sense-shunt.yaml index 90439a8dc785..f8a112c9a822 100644 --- a/Documentation/devicetree/bindings/iio/afe/current-sense-shunt.yaml +++ b/Documentation/devicetree/bindings/iio/afe/current-sense-shunt.yaml @@ -24,6 +24,9 @@ properties: description: | Channel node of a voltage io-channel. + "#io-channel-cells": + const: 0 + shunt-resistor-micro-ohms: description: The shunt resistance. @@ -57,6 +60,7 @@ examples: sysi { compatible = "current-sense-shunt"; io-channels = <&tiadc 0>; + #io-channel-cells = <0>; /* Divide the voltage by 3300000/1000000 (or 3.3) for the current. */ shunt-resistor-micro-ohms = <3300000>; -- cgit v1.2.3 From 52d8e7f864283da43de0996f13f68ff4c187b547 Mon Sep 17 00:00:00 2001 From: Stephan Gerhold Date: Tue, 11 May 2021 16:24:00 +0200 Subject: dt-bindings: iio: kionix,kxcjk1013: Document kionix,kx023-1025 The KX023-1025 accelerometer uses similar register bits as kxcjk1023, so it can make use of the same driver. Document the new kionix,kx023-1025 compatible that is also supported by the kxcjk-1013 driver now. Reviewed-by: Hans de Goede Signed-off-by: Stephan Gerhold Acked-by: Rob Herring Signed-off-by: Jonathan Cameron --- Documentation/devicetree/bindings/iio/accel/kionix,kxcjk1013.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/iio/accel/kionix,kxcjk1013.yaml b/Documentation/devicetree/bindings/iio/accel/kionix,kxcjk1013.yaml index fbb714431e3d..52fa0f7c2d0e 100644 --- a/Documentation/devicetree/bindings/iio/accel/kionix,kxcjk1013.yaml +++ b/Documentation/devicetree/bindings/iio/accel/kionix,kxcjk1013.yaml @@ -16,6 +16,7 @@ properties: - kionix,kxcj91008 - kionix,kxtj21009 - kionix,kxtf9 + - kionix,kx023-1025 reg: maxItems: 1 -- cgit v1.2.3 From 867e6d38f367c5414c076f94c451da2f664b9c7e Mon Sep 17 00:00:00 2001 From: Wu XiangCheng Date: Mon, 17 May 2021 18:34:20 +0800 Subject: docs/zh_CN: Add translation zh_CN/maintainer/index.rst Add a new translation Documentation/translations/zh_CN/maintainer/index.rst and link it to zh_CN/index.rst Signed-off-by: Wu XiangCheng Reviewed-by: Yanteng Si Link: https://lore.kernel.org/r/224959c4cdcd4c6554035145d5cedcd244887552.1621243426.git.bobwxc@email.cn Signed-off-by: Jonathan Corbet --- Documentation/translations/zh_CN/index.rst | 2 +- Documentation/translations/zh_CN/maintainer/index.rst | 19 +++++++++++++++++++ 2 files changed, 20 insertions(+), 1 deletion(-) create mode 100644 Documentation/translations/zh_CN/maintainer/index.rst (limited to 'Documentation') diff --git a/Documentation/translations/zh_CN/index.rst b/Documentation/translations/zh_CN/index.rst index d56d6b7092e6..95c3f313cea1 100644 --- a/Documentation/translations/zh_CN/index.rst +++ b/Documentation/translations/zh_CN/index.rst @@ -72,11 +72,11 @@ TODOlist: dev-tools/index doc-guide/index kernel-hacking/index + maintainer/index TODOList: * trace/index -* maintainer/index * fault-injection/index * livepatch/index * rust/index diff --git a/Documentation/translations/zh_CN/maintainer/index.rst b/Documentation/translations/zh_CN/maintainer/index.rst new file mode 100644 index 000000000000..4ce27c12f370 --- /dev/null +++ b/Documentation/translations/zh_CN/maintainer/index.rst @@ -0,0 +1,19 @@ +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/maintainer/index.rst + +============== +内核维护者手册 +============== + +本文档本是内核维护者手册的首页。 +本手册还需要大量完善！请自由提出（和编写）本手册的补充内容。 +*译注：指英文原版* + +TODOList: + +- configure-git +- rebasing-and-merging +- pull-requests +- maintainer-entry-profile +- modifying-patches -- cgit v1.2.3 From 6ba8a96f4dbab7118d4c019bb30a41d74b2bda13 Mon Sep 17 00:00:00 2001 From: Wu XiangCheng Date: Mon, 17 May 2021 18:34:32 +0800 Subject: docs/zh_CN: Add translation zh_CN/maintainer/configure-git.rst Add a new translation Documentation/translations/zh_CN/maintainer/configure-git.rst and link it to zh_CN/maintainer/index.rst Signed-off-by: Wu XiangCheng Reviewed-by: Yanteng Si Link: https://lore.kernel.org/r/dcf6addd89eba3777b9b59d8b506fa162fbcd828.1621243426.git.bobwxc@email.cn Signed-off-by: Jonathan Corbet --- .../zh_CN/maintainer/configure-git.rst | 62 ++++++++++++++++++++++ .../translations/zh_CN/maintainer/index.rst | 6 ++- 2 files changed, 67 insertions(+), 1 deletion(-) create mode 100644 Documentation/translations/zh_CN/maintainer/configure-git.rst (limited to 'Documentation') diff --git a/Documentation/translations/zh_CN/maintainer/configure-git.rst b/Documentation/translations/zh_CN/maintainer/configure-git.rst new file mode 100644 index 000000000000..a45ea736f73b --- /dev/null +++ b/Documentation/translations/zh_CN/maintainer/configure-git.rst @@ -0,0 +1,62 @@ +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/maintainer/configure-git.rst + +:译者: + + 吴想成 Wu XiangCheng + +.. _configuregit_zh: + +Git配置 +======= + +本章讲述了维护者级别的git配置。 + +Documentation/maintainer/pull-requests.rst 中使用的标记分支应使用开发人员的 +GPG公钥进行签名。可以通过将 ``-u`` 标志传递给 ``git tag`` 来创建签名标记。 +但是，由于 *通常* 对同一项目使用同一个密钥，因此可以设置:: + + git config user.signingkey "keyname" + +或者手动编辑你的 ``.git/config`` 或 ``~/.gitconfig`` 文件:: + + [user] + name = Jane Developer + email = jd@domain.org + signingkey = jd@domain.org + +你可能需要告诉 ``git`` 去使用 ``gpg2``:: + + [gpg] + program = /path/to/gpg2 + +你可能也需要告诉 ``gpg`` 去使用哪个 ``tty`` （添加到你的shell rc文件中）:: + + export GPG_TTY=$(tty) + + +创建链接到lore.kernel.org的提交 +------------------------------- + +http://lore.kernel.org 网站是所有涉及或影响内核开发的邮件列表的总存档。在这里 +存储补丁存档是推荐的做法，当维护人员将补丁应用到子系统树时，最好提供一个指向 +lore存档链接的标签，以便浏览提交历史的人可以找到某个更改背后的相关讨论和基本 +原理。链接标签如下所示： + + Link: https://lore.kernel.org/r/ + +通过在git中添加以下钩子，可以将此配置为在发布 ``git am`` 时自动执行： + +.. code-block:: none + + $ git config am.messageid true + $ cat >.git/hooks/applypatch-msg <<'EOF' + #!/bin/sh + . git-sh-setup + perl -pi -e 's|^Message-Id:\s*]+)>?$|Link: https://lore.kernel.org/r/$1|g;' "$1" + test -x "$GIT_DIR/hooks/commit-msg" && + exec "$GIT_DIR/hooks/commit-msg" ${1+"$@"} + : + EOF + $ chmod a+x .git/hooks/applypatch-msg diff --git a/Documentation/translations/zh_CN/maintainer/index.rst b/Documentation/translations/zh_CN/maintainer/index.rst index 4ce27c12f370..e263315f5e7a 100644 --- a/Documentation/translations/zh_CN/maintainer/index.rst +++ b/Documentation/translations/zh_CN/maintainer/index.rst @@ -10,9 +10,13 @@ 本手册还需要大量完善！请自由提出（和编写）本手册的补充内容。 *译注：指英文原版* +.. toctree:: + :maxdepth: 2 + + configure-git + TODOList: -- configure-git - rebasing-and-merging - pull-requests - maintainer-entry-profile -- cgit v1.2.3 From b7198943af1709790e7a125ff911c529c12ccc3f Mon Sep 17 00:00:00 2001 From: Wu XiangCheng Date: Mon, 17 May 2021 18:34:46 +0800 Subject: docs/zh_CN: Add translation zh_CN/maintainer/rebasing-and-merging.rst Add a new translation Documentation/translations/zh_CN/maintainer/rebasing-and-merging.rst and link it to zh_CN/maintainer/index.rst Signed-off-by: Wu XiangCheng Reviewed-by: Yanteng Si Link: https://lore.kernel.org/r/040f93d0f773a0c9c8d6637701ba269d816a6385.1621243426.git.bobwxc@email.cn Signed-off-by: Jonathan Corbet --- .../translations/zh_CN/maintainer/index.rst | 2 +- .../zh_CN/maintainer/rebasing-and-merging.rst | 165 +++++++++++++++++++++ 2 files changed, 166 insertions(+), 1 deletion(-) create mode 100644 Documentation/translations/zh_CN/maintainer/rebasing-and-merging.rst (limited to 'Documentation') diff --git a/Documentation/translations/zh_CN/maintainer/index.rst b/Documentation/translations/zh_CN/maintainer/index.rst index e263315f5e7a..21ab7cebf78b 100644 --- a/Documentation/translations/zh_CN/maintainer/index.rst +++ b/Documentation/translations/zh_CN/maintainer/index.rst @@ -14,10 +14,10 @@ :maxdepth: 2 configure-git + rebasing-and-merging TODOList: -- rebasing-and-merging - pull-requests - maintainer-entry-profile - modifying-patches diff --git a/Documentation/translations/zh_CN/maintainer/rebasing-and-merging.rst b/Documentation/translations/zh_CN/maintainer/rebasing-and-merging.rst new file mode 100644 index 000000000000..83b7dabfe88b --- /dev/null +++ b/Documentation/translations/zh_CN/maintainer/rebasing-and-merging.rst @@ -0,0 +1,165 @@ +.. SPDX-License-Identifier: GPL-2.0 + +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/maintainer/rebasing-and-merging.rst + +:译者: + + 吴想成 Wu XiangCheng + +========== +变基与合并 +========== + +一般来说，维护子系统需要熟悉Git源代码管理系统。Git是一个功能强大的工具，有 +很多功能；就像这类工具常出现的情况一样，使用这些功能的方法有对有错。本文档 +特别介绍了变基与合并的用法。维护者经常在错误使用这些工具时遇到麻烦，但避免 +问题实际上并不那么困难。 + +总的来说，需要注意的一点是：与许多其他项目不同，内核社区并不害怕在其开发历史 +中看到合并提交。事实上，考虑到该项目的规模，避免合并几乎是不可能的。维护者会 +在希望避免合并时遇到一些问题，而过于频繁的合并也会带来另一些问题。 + +变基 +==== + +“变基（Rebase）”是更改存储库中一系列提交的历史记录的过程。有两种不同型的操作 +都被称为变基，因为这两种操作都使用 ``git rebase`` 命令，但它们之间存在显著 +差异： + + - 更改一系列补丁的父提交（起始提交）。例如，变基操作可以将基于上一内核版本 + 的一个补丁集重建到当前版本上。在下面的讨论中，我们将此操作称为“变根”。 + + - 通过修复（或删除）损坏的提交、添加补丁、添加标记以更改一系列补丁的历史， + 来提交变更日志或更改已应用提交的顺序。在下文中，这种类型的操作称为“历史 + 修改” + +术语“变基”将用于指代上述两种操作。如果使用得当，变基可以产生更清晰、更整洁的 +开发历史；如果使用不当，它可能会模糊历史并引入错误。 + +以下一些经验法则可以帮助开发者避免最糟糕的变基风险： + + - 已经发布到你私人系统之外世界的历史通常不应更改。其他人可能会拉取你的树 + 的副本，然后基于它进行工作；修改你的树会给他们带来麻烦。如果工作需要变基， + 这通常是表明它还没有准备好提交到公共存储库的信号。 + + 但是，总有例外。有些树（linux-next是一个典型的例子）由于它们的需要经常 + 变基，开发人员知道不要基于它们来工作。开发人员有时会公开一个不稳定的分支， + 供其他人或自动测试服务进行测试。如果您确实以这种方式公开了一个可能不稳定 + 的分支，请确保潜在使用者知道不要基于它来工作。 + + - 不要在包含由他人创建的历史的分支上变基。如果你从别的开发者的仓库拉取了变更， + 那你现在就成了他们历史记录的保管人。你不应该改变它，除了少数例外情况。例如 + 树中有问题的提交必须显式恢复（即通过另一个补丁修复），而不是通过修改历史而 + 消失。 + + - 没有合理理由，不要对树变根。仅为了切换到更新的基或避免与上游储存库的合并 + 通常不是合理理由。 + + - 如果你必须对储存库进行变根，请不要随机选取一个提交作为新基。在发布节点之间 + 内核通常处于一个相对不稳定的状态；基于其中某点进行开发会增加遇到意外错误的 + 几率。当一系列补丁必须移动到新基时，请选择移动到一个稳定节点（例如-rc版本 + 节点）。 + + - 请知悉对补丁系列进行变根（或做明显的历史修改）会改变它们的开发环境，且很 + 可能使做过的大部分测试失效。一般来说，变基后的补丁系列应当像新代码一样对 + 待，并重新测试。 + +合并窗口麻烦的一个常见原因是，Linus收到了一个明显在拉取请求发送之前不久才变根 +（通常是变根到随机的提交上）的补丁系列。这样一个系列被充分测试的可能性相对较 +低，拉取请求被接受的几率也同样较低。 + +相反，如果变基仅限于私有树、提交基于一个通用的起点、且经过充分测试，则引起 +麻烦的可能性就很低。 + +合并 +==== + +内核开发过程中，合并是一个很常见的操作；5.1版本开发周期中有超过1126个合并 +——差不多占了整体的9%。内核开发工作积累在100多个不同的子系统树中，每个 +子系统树都可能包含多个主题分支；每个分支通常独立于其他分支进行开发。因此 +在任何给定分支进入上游储存库之前，至少需要一次合并。 + +许多项目要求拉取请求中的分支基于当前主干，这样历史记录中就不会出现合并提交。 +内核并不是这样；任何为了避免合并而重新对分支变基都很可能导致麻烦。 + +子系统维护人员发现他们必须进行两种类型的合并：从较低层级的子系统树和从其他 +子系统树（同级树或主线）进行合并。这两种情况下要遵循的最佳实践是不同的。 + +合并较低层级树 +-------------- + +较大的子系统往往有多个级别的维护人员，较低级别的维护人员向较高级别发送拉取 +请求。合并这样的请求执行几乎肯定会生成一个合并提交；这也是应该的。实际上， +子系统维护人员可能希望在极少数快进合并情况下使用 ``-–no-ff`` 标志来强制添加 +合并提交，以便记录合并的原因。 **任何** 类型的合并的变更日志必须说明 +*为什么* 合并。对于较低级别的树，“为什么”通常是对该取所带来的变化的总结。 + +各级维护人员都应在他们的拉取请求上使用经签名的标签，上游维护人员应在拉取分支 +时验证标签。不这样做会威胁整个开发过程的安全。 + +根据上面列出的规则，一旦您将其他人的历史记录合并到树中，您就不得对该分支进行 +变基，即使您能够这样做。 + +合并同级树或上游树 +------------------ + +虽然来自下游的合并是常见且不起眼的，但当需要将一个分支推向上游时，其中来自 +其他树的合并往往是一个危险信号。这种合并需要仔细考虑并加以充分证明，否则后续 +的拉取请求很可能会被拒绝。 + +想要将主分支合并到存储库中是很自然的；这种类型的合并通常被称为“反向合并” +。反向合并有助于确保与并行的开发没有冲突，并且通常会给人一种温暖、舒服的 +感觉，即处于最新。但这种诱惑几乎总是应该避免的。 + +为什么呢？反向合并将搅乱你自己分支的开发历史。它们会大大增加你遇到来自社区 +其他地方的错误的机会，且使你很难确保你所管理的工作稳定并准备好合入上游。 +频繁的合并还可以掩盖树中开发过程中的问题；它们会隐藏与其他树的交互，而这些 +交互不应该（经常）发生在管理良好的分支中。 + +也就是说，偶尔需要进行反向合并；当这种情况发生时，一定要在提交信息中记录 +*为什么* 。同样，在一个众所周知的稳定点进行合并，而不是随机提交。即使这样， +你也不应该反向合并一棵比你的直接上游树更高层级的树；如果确实需要更高级别的 +反向合并，应首先在上游树进行。 + +导致合并相关问题最常见的原因之一是：在发送拉取请求之前维护者合并上游以解决 +合并冲突。同样，这种诱惑很容易理解，但绝对应该避免。对于最终拉取请求来说 +尤其如此：Linus坚信他更愿意看到合并冲突，而不是不必要的反向合并。看到冲突 +可以让他了解潜在的问题所在。他做过很多合并（在5.1版本开发周期中是382次）， +而且在解决冲突方面也很在行——通常比参与的开发人员要强。 + +那么，当他们的子系统分支和主线之间发生冲突时，维护人员应该怎么做呢？最重要 +的一步是在拉取请求中提示Linus会发生冲突；如果啥都没说则表明您的分支可以正常 +合入。对于特别困难的冲突，创建并推送一个 *独立* 分支来展示你将如何解决问题。 +在拉取请求中提到该分支，但是请求本身应该针对未合并的分支。 + +即使不存在已知冲突，在发送拉取请求之前进行合并测试也是个好主意。它可能会提醒 +您一些在linux-next树中没有发现的问题，并帮助您准确地理解您正在要求上游做什么。 + +合并上游树或另一个子系统树的另一个原因是解决依赖关系。这些依赖性问题有时确实 +会发生，而且有时与另一棵树交叉合并是解决这些问题的最佳方法；同样，在这种情况 +下，合并提交应该解释为什么要进行合并。花点时间把它做好；会有人阅读这些变更 +日志。 + +然而依赖性问题通常表明需要改变方法。合并另一个子系统树以解决依赖性风险会带来 +其他缺陷，几乎永远不应这样做。如果该子系统树无法被合到上游，那么它的任何问题 +也都会阻碍你的树合并。更可取的选择包括与维护人员达成一致意见，在其中一个树中 +同时进行两组更改；或者创建一个主题分支专门处理可以合并到两个树中的先决条件提交。 +如果依赖关系与主要的基础结构更改相关，正确的解决方案可能是将依赖提交保留一个 +开发周期，以便这些更改有时间在主线上稳定。 + +最后 +==== + +在开发周期的开头合并主线是比较常见的，可以获取树中其他地方的更改和修复。同样， +这样的合并应该选择一个众所周知的发布点，而不是一些随机点。如果在合并窗口期间 +上游分支已完全清空到主线中，则可以使用以下命令向前拉取它:: + + git merge v5.2-rc1^0 + +“^0”使Git执行快进合并（在这种情况下这应该可以），从而避免多余的虚假合并提交。 + +上面列出的就是指导方针了。总是会有一些情况需要不同的解决方案，这些指导原则 +不应阻止开发人员在需要时做正确的事情。但是，我们应该时刻考虑是否真的出现了 +这样的需求，并准备好解释为什么需要做一些不寻常的事情。 -- cgit v1.2.3 From 989cfaecbd2c06800d13f49206498602b1e769a8 Mon Sep 17 00:00:00 2001 From: Wu XiangCheng Date: Mon, 17 May 2021 18:35:05 +0800 Subject: docs/zh_CN: Add translation zh_CN/maintainer/pull-requests.rst Add a new translation Documentation/translations/zh_CN/maintainer/pull-requests.rst and link it to zh_CN/maintainer/index.rst Signed-off-by: Wu XiangCheng Reviewed-by: Yanteng Si Link: https://lore.kernel.org/r/4774d1b7976678ce97c4356bd71509df0cec1ffc.1621243426.git.bobwxc@email.cn Signed-off-by: Jonathan Corbet --- .../translations/zh_CN/maintainer/index.rst | 2 +- .../zh_CN/maintainer/pull-requests.rst | 148 +++++++++++++++++++++ 2 files changed, 149 insertions(+), 1 deletion(-) create mode 100644 Documentation/translations/zh_CN/maintainer/pull-requests.rst (limited to 'Documentation') diff --git a/Documentation/translations/zh_CN/maintainer/index.rst b/Documentation/translations/zh_CN/maintainer/index.rst index 21ab7cebf78b..1a1222b78715 100644 --- a/Documentation/translations/zh_CN/maintainer/index.rst +++ b/Documentation/translations/zh_CN/maintainer/index.rst @@ -15,9 +15,9 @@ configure-git rebasing-and-merging + pull-requests TODOList: -- pull-requests - maintainer-entry-profile - modifying-patches diff --git a/Documentation/translations/zh_CN/maintainer/pull-requests.rst b/Documentation/translations/zh_CN/maintainer/pull-requests.rst new file mode 100644 index 000000000000..f46d6f3f2498 --- /dev/null +++ b/Documentation/translations/zh_CN/maintainer/pull-requests.rst @@ -0,0 +1,148 @@ +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/maintainer/pull-requests.rst + +:译者: + + 吴想成 Wu XiangCheng + +.. _pullrequests_zh: + +如何创建拉取请求 +================ + +本章描述维护人员如何创建并向其他维护人员提交拉取请求。这对将更改从一个维护者 +树转移到另一个维护者树非常有用。 + +本文档由Tobin C. Harding（当时他尚不是一名经验丰富的维护人员）编写，内容主要 +来自Greg Kroah Hartman和Linus Torvalds在LKML上的评论。Jonathan Corbet和Mauro +Carvalho Chehab提出了一些建议和修改。错误不可避免，如有问题，请找Tobin C. +Harding 。 + +原始邮件线程:: + + http://lkml.kernel.org/r/20171114110500.GA21175@kroah.com + + +创建分支 +-------- + +首先，您需要将希望包含拉取请求里的所有更改都放在单独分支中。通常您将基于某开发 +人员树的一个分支，一般是打算向其发送拉取请求的开发人员。 + +为了创建拉取请求，您必须首先标记刚刚创建的分支。建议您选择一个有意义的标记名， +以即使过了一段时间您和他人仍能理解的方式。在名称中包含源子系统和目标内核版本 +的指示也是一个好的做法。 + +Greg提供了以下内容。对于一个含有drivers/char中混杂事项、将应用于4.15-rc1内核的 +拉取请求，可以命名为 ``char-misc-4.15-rc1`` 。如果要在 ``char-misc-next`` 分支 +上打上此标记，您可以使用以下命令:: + + git tag -s char-misc-4.15-rc1 char-misc-next + +这将在 ``char-misc-next`` 分支的最后一个提交上创建一个名为 ``char-misc-4.15-rc1`` +的标记，并用您的gpg密钥签名（参见 Documentation/maintainer/configure-git.rst ）。 + +Linus只接受基于签名过的标记的拉取请求。其他维护者可能会有所不同。 + +当您运行上述命令时 ``git`` 会打开编辑器要求你描述一下这个标记。在本例中您需要 +描述拉取请求，所以请概述一下包含的内容，为什么要合并，是否完成任何测试。所有 +这些信息都将留在标记中，然后在维护者合并拉取请求时保留在合并提交中。所以把它 +写好，它将永远留在内核中。 + +正如Linus所说:: + + 不管怎么样，至少对我来说，重要的是 *信息* 。我需要知道我在拉取什么、 + 为什么我要拉取。我也希望将此消息用于合并消息，因此它不仅应该对我有 + 意义，也应该可以成为一个有意义的历史记录。 + + 注意，如果拉取请求有一些不寻常的地方，请详细说明。如果你修改了并非 + 由你维护的文件，请解释 **为什么** 。我总会在差异中看到的，如果你不 + 提的话，我只会觉得分外可疑。当你在合并窗口后给我发新东西的时候， + （甚至是比较重大的错误修复），不仅需要解释做了什么、为什么这么做， + 还请解释一下 **时间问题** 。为什么错过了合并窗口…… + + 我会看你写在拉取请求邮件和签名标记里面的内容，所以根据你的工作流， + 你可以在签名标记里面描述工作内容（也会自动放进拉取请求邮件），也 + 可以只在标记里面放个占位符，稍后在你实际发给我拉取请求时描述工作内容。 + + 是的，我会编辑这些消息。部分因为我需要做一些琐碎的格式调整（整体缩进、 + 括号等），也因为此消息可能对我有意义（描述了冲突或一些个人问题）而对 + 合并提交信息上下文没啥意义，因此我需要尽力让它有意义起来。我也会 + 修复一些拼写和语法错误，特别是非母语者（母语者也是;^）。但我也会删掉 + 或增加一些内容。 + + Linus + +Greg给出了一个拉取请求的例子:: + + Char/Misc patches for 4.15-rc1 + + Here is the big char/misc patch set for the 4.15-rc1 merge window. + Contained in here is the normal set of new functions added to all + of these crazy drivers, as well as the following brand new + subsystems: + - time_travel_controller: Finally a set of drivers for the + latest time travel bus architecture that provides i/o to + the CPU before it asked for it, allowing uninterrupted + processing + - relativity_shifters: due to the affect that the + time_travel_controllers have on the overall system, there + was a need for a new set of relativity shifter drivers to + accommodate the newly formed black holes that would + threaten to suck CPUs into them. This subsystem handles + this in a way to successfully neutralize the problems. + There is a Kconfig option to force these to be enabled + when needed, so problems should not occur. + + All of these patches have been successfully tested in the latest + linux-next releases, and the original problems that it found have + all been resolved (apologies to anyone living near Canberra for the + lack of the Kconfig options in the earlier versions of the + linux-next tree creations.) + + Signed-off-by: Your-name-here + + +此标记消息格式就像一个git提交。顶部有一行“总结标题”， 一定要在下面sign-off。 + +现在您已经有了一个本地签名标记，您需要将它推送到可以被拉取的位置:: + + git push origin char-misc-4.15-rc1 + + +创建拉取请求 +------------ + +最后要做的是创建拉取请求消息。可以使用 ``git request-pull`` 命令让 ``git`` +为你做这件事，但它需要确定你想拉取什么，以及拉取针对的基础（显示正确的拉取 +更改和变更状态）。以下命令将生成一个拉取请求:: + + git request-pull master git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git/ char-misc-4.15-rc1 + +引用Greg的话:: + + 此命令要求git比较从“char-misc-4.15-rc1”标记位置到“master”分支头（上述 + 例子中指向了我从Linus的树分叉的地方，通常是-rc发布）的差异，并去使用 + git:// 协议拉取。如果你希望使用 https:// 协议，也可以用在这里（但是请 + 注意，部分人由于防火墙问题没法用https协议拉取）。 + + 如果char-misc-4.15-rc1标记没有出现在我要求拉取的仓库中，git会提醒 + 它不在那里，所以记得推送到公开地方。 + + “git request-pull”会包含git树的地址和需要拉取的特定标记，以及标记 + 描述全文（详尽描述标记）。同时它也会创建此拉取请求的差异状态和单个 + 提交的缩短日志。 + +Linus回复说他倾向于 ``git://`` 协议。其他维护者可能有不同的偏好。另外，请注意 +如果你创建的拉取请求没有签名标记， ``https://`` 可能是更好的选择。完整的讨论 +请看原邮件。 + + +提交拉取请求 +------------ + +拉取请求的提交方式与普通补丁相同。向维护人员发送内联电子邮件并抄送LKML以及 +任何必要特定子系统的列表。对Linus的拉取请求通常有如下主题行:: + + [GIT PULL] changes for v4.15-rc1 -- cgit v1.2.3 From 91643aba949347ab46b870524dd9348781fa8b1d Mon Sep 17 00:00:00 2001 From: Wu XiangCheng Date: Mon, 17 May 2021 18:35:33 +0800 Subject: docs/zh_CN: Add translation zh_CN/maintainer/maintainer-entry-profile.rst Add a new translation Documentation/translations/zh_CN/maintainer/maintainer-entry-profile.rst and link it to zh_CN/maintainer/index.rst Signed-off-by: Wu XiangCheng Reviewed-by: Yanteng Si Link: https://lore.kernel.org/r/e5b0838317cbc2f8fb3a9480f4604b6f099db975.1621243426.git.bobwxc@email.cn Signed-off-by: Jonathan Corbet --- .../translations/zh_CN/maintainer/index.rst | 2 +- .../zh_CN/maintainer/maintainer-entry-profile.rst | 92 ++++++++++++++++++++++ 2 files changed, 93 insertions(+), 1 deletion(-) create mode 100644 Documentation/translations/zh_CN/maintainer/maintainer-entry-profile.rst (limited to 'Documentation') diff --git a/Documentation/translations/zh_CN/maintainer/index.rst b/Documentation/translations/zh_CN/maintainer/index.rst index 1a1222b78715..18a820741f52 100644 --- a/Documentation/translations/zh_CN/maintainer/index.rst +++ b/Documentation/translations/zh_CN/maintainer/index.rst @@ -16,8 +16,8 @@ configure-git rebasing-and-merging pull-requests + maintainer-entry-profile TODOList: -- maintainer-entry-profile - modifying-patches diff --git a/Documentation/translations/zh_CN/maintainer/maintainer-entry-profile.rst b/Documentation/translations/zh_CN/maintainer/maintainer-entry-profile.rst new file mode 100644 index 000000000000..a1ee99c4786e --- /dev/null +++ b/Documentation/translations/zh_CN/maintainer/maintainer-entry-profile.rst @@ -0,0 +1,92 @@ +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/maintainer/maintainer-entry-profile.rst + +:译者: + + 吴想成 Wu XiangCheng + +.. _maintainerentryprofile_zh: + +维护者条目概要 +============== + +维护人员条目概要补充了顶层过程文档（提交补丁，提交驱动程序……），增加了子系 +统/设备驱动程序本地习惯以及有关补丁提交生命周期的相关内容。贡献者使用此文档 +来调整他们的期望和避免常见错误；维护人员可以使用这些信息超越子系统层面查看 +是否有机会汇聚到通用实践中。 + + +总览 +---- + +提供了子系统如何操作的介绍。MAINTAINERS文件告诉了贡献者应发送某文件的补丁到哪， +但它没有传达其他子系统的本地基础设施和机制以协助开发。 + +请考虑以下问题： + +- 当补丁被本地树接纳或合并到上游时是否有通知？ +- 子系统是否使用patchwork实例？Patchwork状态变更是否有通知？ +- 是否有任何机器人或CI基础设施监视列表，或子系统是否使用自动测试反馈以便把 + 控接纳补丁？ +- 被拉入-next的Git分支是哪个？ +- 贡献者应针对哪个分支提交？ +- 是否链接到其他维护者条目概要？例如一个设备驱动可能指向其父子系统的条目。 + 这使得贡献者意识到某维护者可能对提交链中其他维护者负有的义务。 + + +提交检查单补遗 +-------------- + +列出强制性和咨询性标准，超出通用标准“提交检查表，以便维护者检查一个补丁是否 +足够健康。例如：“通过checkpatch.pl，没有错误、没有警告。通过单元测试详见某处”。 + +提交检查单补遗还可以包括有关硬件规格状态的详细信息。例如，子系统接受补丁之前 +是否需要考虑在某个修订版上发布的规范。 + + +开发周期的关键日期 +------------------ + +提交者常常会误以为补丁可以在合并窗口关闭之前的任何时间发送，且下一个-rc1时仍 +可以。事实上，大多数补丁都需要在下一个合并窗口打开之前提前进入linux-next中。 +向提交者澄清关键日期（以-rc发布周为标志）以明确什么时候补丁会被考虑合并以及 +何时需要等待下一个-rc。 + +至少需要讲明： + +- 最后一个可以提交新功能的-rc： + 针对下一个合并窗口的新功能提交应该在此点之前首次发布以供考虑。在此时间点 + 之后提交的补丁应该明确他们的目标为下下个合并窗口，或者给出应加快进度被接受 + 的充足理由。通常新特性贡献者的提交应出现在-rc5之前。 + +- 最后合并-rc：合并决策的最后期限。 + 向贡献者指出尚未接受的补丁集需要等待下下个合并窗口。当然，维护者没有义务 + 接受所有给定的补丁集，但是如果审阅在此时间点尚未结束，那么希望贡献者应该 + 等待并在下一个合并窗口重新提交。 + +可选项： + +- 开发基线分支的首个-rc，列在概述部分，视为已为新提交做好准备。 + + +审阅节奏 +-------- + +贡献者最担心的问题之一是：补丁集已发布却未收到反馈，应在多久后发送提醒。除了 +指定在重新提交之前要等待多长时间，还可以指示更新的首选样式；例如，重新发送 +整个系列，或私下发送提醒邮件。本节也可以列出本区域的代码审阅方式，以及获取 +不能直接从维护者那里得到的反馈的方法。 + + +现有概要 +-------- + +这里列出了现有的维护人员条目概要；我们可能会想要在不久的将来做一些不同的事情。 + +.. toctree:: + :maxdepth: 1 + + ../doc-guide/maintainer-profile + ../../../nvdimm/maintainer-entry-profile + ../../../riscv/patch-acceptance -- cgit v1.2.3 From 55e0990231a980459393729e253c26759172744a Mon Sep 17 00:00:00 2001 From: Wu XiangCheng Date: Mon, 17 May 2021 18:35:47 +0800 Subject: docs/zh_CN: Add translation zh_CN/maintainer/modifying-patches.rst Add a new translation Documentation/translations/zh_CN/maintainer/modifying-patches.rst and link it to zh_CN/maintainer/index.rst Signed-off-by: Wu XiangCheng Reviewed-by: Yanteng Si Link: https://lore.kernel.org/r/35e6878cb634db61c573fc7fdc69ef4c5d8ae31c.1621243426.git.bobwxc@email.cn Signed-off-by: Jonathan Corbet --- .../translations/zh_CN/maintainer/index.rst | 4 +- .../zh_CN/maintainer/modifying-patches.rst | 51 ++++++++++++++++++++++ 2 files changed, 52 insertions(+), 3 deletions(-) create mode 100644 Documentation/translations/zh_CN/maintainer/modifying-patches.rst (limited to 'Documentation') diff --git a/Documentation/translations/zh_CN/maintainer/index.rst b/Documentation/translations/zh_CN/maintainer/index.rst index 18a820741f52..eb75ccea9a21 100644 --- a/Documentation/translations/zh_CN/maintainer/index.rst +++ b/Documentation/translations/zh_CN/maintainer/index.rst @@ -17,7 +17,5 @@ rebasing-and-merging pull-requests maintainer-entry-profile + modifying-patches -TODOList: - -- modifying-patches diff --git a/Documentation/translations/zh_CN/maintainer/modifying-patches.rst b/Documentation/translations/zh_CN/maintainer/modifying-patches.rst new file mode 100644 index 000000000000..7f6326137f6b --- /dev/null +++ b/Documentation/translations/zh_CN/maintainer/modifying-patches.rst @@ -0,0 +1,51 @@ +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/maintainer/modifying-patches.rst + +:译者: + + 吴想成 Wu XiangCheng + +.. _modifyingpatches_zh: + +修改补丁 +======== + +如果你是子系统或者分支的维护者，由于代码在你的和提交者的树中并不完全相同， +有时你需要稍微修改一下收到的补丁以合并它们。 + +如果你严格遵守开发者来源证书的规则（c），你应该要求提交者重做，但这完全是会 +适得其反的时间、精力浪费。规则（b）允许你调整代码，但这样修改提交者的代码并 +让他背书你的错误是非常不礼貌的。为解决此问题，建议在你之前最后一个 +Signed-off-by标签和你的之间添加一行，以指示更改的性质。这没有强制性要求，最 +好在描述前面加上你的邮件和/或姓名，用方括号括住整行，以明显指出你对最后一刻 +的更改负责。例如:: + + Signed-off-by: Random J Developer + [lucky@maintainer.example.org: struct foo moved from foo.c to foo.h] + Signed-off-by: Lucky K Maintainer + +如果您维护着一个稳定的分支，并希望同时明确贡献、跟踪更改、合并修复，并保护 +提交者免受责难，这种做法尤其有用。请注意，在任何情况下都不得更改作者的身份 +（From头），因为它会在变更日志中显示。 + +向后移植（back-port）人员特别要注意：为了便于跟踪，请在提交消息的顶部（即主题行 +之后）插入补丁的来源，这是一种常见而有用的做法。例如，我们可以在3.x稳定版本 +中看到以下内容:: + + Date: Tue Oct 7 07:26:38 2014 -0400 + + libata: Un-break ATA blacklist + + commit 1c40279960bcd7d52dbdf1d466b20d24b99176c8 upstream. + +下面是一个旧的内核在某补丁被向后移植后会出现的:: + + Date: Tue May 13 22:12:27 2008 +0200 + + wireless, airo: waitbusy() won't delay + + [backport of 2.6 commit b7acbdfbd1f277c1eb23f344f899cfa4cd0bf36a] + +不管什么格式，这些信息都为人们跟踪你的树，以及试图解决你树中的错误的人提供了 +有价值的帮助。 -- cgit v1.2.3 From 94c1fbd487b33a28ea7f0da076a2cba6d0f410cf Mon Sep 17 00:00:00 2001 From: Yanteng Si Date: Mon, 17 May 2021 16:46:13 +0800 Subject: docs/zh_CN: add core-api kernel-api.rst translation This patch translates Documentation/core-api/kernel-api.rst into Chinese. Signed-off-by: Yanteng Si Reviewed-by: Wu XiangCheng Reviewed-by: Alex Shi Link: https://lore.kernel.org/r/d79e2d1f37bae52ce6fce0efb2fa4a32a89165fb.1621239725.git.siyanteng@loongson.cn Signed-off-by: Jonathan Corbet --- .../translations/zh_CN/core-api/index.rst | 5 +- .../translations/zh_CN/core-api/kernel-api.rst | 369 +++++++++++++++++++++ 2 files changed, 373 insertions(+), 1 deletion(-) create mode 100644 Documentation/translations/zh_CN/core-api/kernel-api.rst (limited to 'Documentation') diff --git a/Documentation/translations/zh_CN/core-api/index.rst b/Documentation/translations/zh_CN/core-api/index.rst index f1fa71e45c77..60e1566d57eb 100644 --- a/Documentation/translations/zh_CN/core-api/index.rst +++ b/Documentation/translations/zh_CN/core-api/index.rst @@ -19,9 +19,12 @@ 来的大量 kerneldoc 信息；有朝一日，若有人有动力的话，应当把它们拆分 出来。 -Todolist: +.. toctree:: + :maxdepth: 1 kernel-api + +Todolist: workqueue printk-basics printk-formats diff --git a/Documentation/translations/zh_CN/core-api/kernel-api.rst b/Documentation/translations/zh_CN/core-api/kernel-api.rst new file mode 100644 index 000000000000..d6f815ec265b --- /dev/null +++ b/Documentation/translations/zh_CN/core-api/kernel-api.rst @@ -0,0 +1,369 @@ +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/core-api/kernel-api.rst +:Translator: Yanteng Si + +.. _cn_kernel-api.rst: + + +============ +Linux内核API +============ + + +列表管理函数 +============ + +该API在以下内核代码中: + +include/linux/list.h + +基本的C库函数 +============= + +在编写驱动程序时，一般不能使用C库中的例程。部分函数通常很有用，它们在 +下面被列出。这些函数的行为可能会与ANSI定义的略有不同，这些偏差会在文中 +注明。 + +字符串转换 +---------- + +该API在以下内核代码中: + +lib/vsprintf.c + +include/linux/kernel.h + +include/linux/kernel.h + +lib/kstrtox.c + +lib/string_helpers.c + +字符串处理 +---------- + +该API在以下内核代码中: + +lib/string.c + +include/linux/string.h + +mm/util.c + +基本的内核库函数 +================ + +Linux内核提供了很多实用的基本函数。 + +位运算 +------ + +该API在以下内核代码中: + +include/asm-generic/bitops/instrumented-atomic.h + +include/asm-generic/bitops/instrumented-non-atomic.h + +include/asm-generic/bitops/instrumented-lock.h + +位图运算 +-------- + +该API在以下内核代码中: + +lib/bitmap.c + +include/linux/bitmap.h + +include/linux/bitmap.h + +include/linux/bitmap.h + +lib/bitmap.c + +lib/bitmap.c + +include/linux/bitmap.h + +命令行解析 +---------- + +该API在以下内核代码中: + +lib/cmdline.c + +排序 +---- + +该API在以下内核代码中: + +lib/sort.c + +lib/list_sort.c + +文本检索 +-------- + +该API在以下内核代码中: + +lib/textsearch.c + +lib/textsearch.c + +include/linux/textsearch.h + +Linux中的CRC和数学函数 +====================== + + +CRC函数 +------- + +*译注：CRC，Cyclic Redundancy Check，循环冗余校验* + +该API在以下内核代码中: + +lib/crc4.c + +lib/crc7.c + +lib/crc8.c + +lib/crc16.c + +lib/crc32.c + +lib/crc-ccitt.c + +lib/crc-itu-t.c + +基数为2的对数和幂函数 +--------------------- + +该API在以下内核代码中: + +include/linux/log2.h + +整数幂函数 +---------- + +该API在以下内核代码中: + +lib/math/int_pow.c + +lib/math/int_sqrt.c + +除法函数 +-------- + +该API在以下内核代码中: + +include/asm-generic/div64.h + +include/linux/math64.h + +lib/math/div64.c + +lib/math/gcd.c + +UUID/GUID +--------- + +该API在以下内核代码中: + +lib/uuid.c + +内核IPC设备 +=========== + +IPC实用程序 +----------- + +该API在以下内核代码中: + +ipc/util.c + +FIFO 缓冲区 +=========== + +kfifo接口 +--------- + +该API在以下内核代码中: + +include/linux/kfifo.h + +转发接口支持 +============ + +转发接口支持旨在为工具和设备提供一种有效的机制，将大量数据从内核空间 +转发到用户空间。 + +转发接口 +-------- + +该API在以下内核代码中: + +kernel/relay.c + +kernel/relay.c + +模块支持 +======== + +模块加载 +-------- + +该API在以下内核代码中: + +kernel/kmod.c + +模块接口支持 +------------ + +更多信息请参考文件kernel/module.c。 + +硬件接口 +======== + + +该API在以下内核代码中: + +kernel/dma.c + +资源管理 +-------- + +该API在以下内核代码中: + +kernel/resource.c + +kernel/resource.c + +MTRR处理 +-------- + +该API在以下内核代码中: + +arch/x86/kernel/cpu/mtrr/mtrr.c + +安全框架 +======== + +该API在以下内核代码中: + +security/security.c + +security/inode.c + +审计接口 +======== + +该API在以下内核代码中: + +kernel/audit.c + +kernel/auditsc.c + +kernel/auditfilter.c + +核算框架 +======== + +该API在以下内核代码中: + +kernel/acct.c + +块设备 +====== + +该API在以下内核代码中: + +block/blk-core.c + +block/blk-core.c + +block/blk-map.c + +block/blk-sysfs.c + +block/blk-settings.c + +block/blk-exec.c + +block/blk-flush.c + +block/blk-lib.c + +block/blk-integrity.c + +kernel/trace/blktrace.c + +block/genhd.c + +block/genhd.c + +字符设备 +======== + +该API在以下内核代码中: + +fs/char_dev.c + +时钟框架 +======== + +时钟框架定义了编程接口，以支持系统时钟树的软件管理。该框架广泛用于系统级芯片（SOC）平 +台，以支持电源管理和各种可能需要自定义时钟速率的设备。请注意，这些 “时钟”与计时或实 +时时钟(RTC)无关，它们都有单独的框架。这些:c:type: `struct clk ` 实例可用于管理 +各种时钟信号，例如一个96理例如96MHz的时钟信号，该信号可被用于总线或外设的数据交换，或以 +其他方式触发系统硬件中的同步状态机转换。 + +通过明确的软件时钟门控来支持电源管理：未使用的时钟被禁用，因此系统不会因为改变不在使用 +中的晶体管的状态而浪费电源。在某些系统中，这可能是由硬件时钟门控支持的，其中时钟被门控 +而不在软件中被禁用。芯片的部分，在供电但没有时钟的情况下，可能会保留其最后的状态。这种 +低功耗状态通常被称为*保留模式*。这种模式仍然会产生漏电流，特别是在电路几何结构较细的情 +况下，但对于CMOS电路来说，电能主要是随着时钟翻转而被消耗的。 + +电源感知驱动程序只有在其管理的设备处于活动使用状态时才会启用时钟。此外，系统睡眠状态通 +常根据哪些时钟域处于活动状态而有所不同：“待机”状态可能允许从多个活动域中唤醒，而 +"mem"（暂停到RAM）状态可能需要更全面地关闭来自高速PLL和振荡器的时钟，从而限制了可能 +的唤醒事件源的数量。驱动器的暂停方法可能需要注意目标睡眠状态的系统特定时钟约束。 + +一些平台支持可编程时钟发生器。这些可以被各种外部芯片使用，如其他CPU、多媒体编解码器以 +及对接口时钟有严格要求的设备。 + +该API在以下内核代码中: + +include/linux/clk.h + +同步原语 +======== + +读-复制-更新（RCU） +------------------- + +该API在以下内核代码中: + +include/linux/rcupdate.h + +kernel/rcu/tree.c + +kernel/rcu/tree_exp.h + +kernel/rcu/update.c + +include/linux/srcu.h + +kernel/rcu/srcutree.c + +include/linux/rculist_bl.h + +include/linux/rculist.h + +include/linux/rculist_nulls.h + +include/linux/rcu_sync.h + +kernel/rcu/sync.c -- cgit v1.2.3 From 7c0066d132d237db6702804aa1fcb18fefcda00b Mon Sep 17 00:00:00 2001 From: Yanteng Si Date: Mon, 17 May 2021 16:46:14 +0800 Subject: docs/zh_CN: add core-api printk-basics.rst translation This patch translates Documentation/core-api/printk-basics.rst into Chinese. Signed-off-by: Yanteng Si Reviewed-by: Wu XiangCheng Reviewed-by: Alex Shi Reviewed-by: Jiaxun Yang Link: https://lore.kernel.org/r/1610df76720b69f3f81bff27403e70e86c0875c5.1621239725.git.siyanteng@loongson.cn Signed-off-by: Jonathan Corbet --- .../translations/zh_CN/core-api/index.rst | 2 +- .../translations/zh_CN/core-api/printk-basics.rst | 110 +++++++++++++++++++++ 2 files changed, 111 insertions(+), 1 deletion(-) create mode 100644 Documentation/translations/zh_CN/core-api/printk-basics.rst (limited to 'Documentation') diff --git a/Documentation/translations/zh_CN/core-api/index.rst b/Documentation/translations/zh_CN/core-api/index.rst index 60e1566d57eb..5ecb23e3ba8c 100644 --- a/Documentation/translations/zh_CN/core-api/index.rst +++ b/Documentation/translations/zh_CN/core-api/index.rst @@ -23,10 +23,10 @@ :maxdepth: 1 kernel-api + printk-basics Todolist: workqueue - printk-basics printk-formats symbol-namespaces diff --git a/Documentation/translations/zh_CN/core-api/printk-basics.rst b/Documentation/translations/zh_CN/core-api/printk-basics.rst new file mode 100644 index 000000000000..2b20f6303a82 --- /dev/null +++ b/Documentation/translations/zh_CN/core-api/printk-basics.rst @@ -0,0 +1,110 @@ +.. SPDX-License-Identifier: GPL-2.0 +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/core-api/printk-basics.rst +:Translator: Yanteng Si + +.. _cn_printk-basics.rst: + + +================== +使用printk记录消息 +================== + +printk()是Linux内核中最广为人知的函数之一。它是我们打印消息的标准工具，通常也是追踪和调试 +的最基本方法。如果你熟悉printf(3)，你就能够知道printk()是基于它的，尽管它在功能上有一些不 +同之处: + + - printk() 消息可以指定日志级别。 + + - 格式字符串虽然与C99基本兼容，但并不遵循完全相同的规范。它有一些扩展和一些限制（没 + 有 ``%n`` 或浮点转换指定符）。参见:ref: `如何正确地获得printk格式指定符` 。 + +所有的printk()消息都会被打印到内核日志缓冲区，这是一个通过/dev/kmsg输出到用户空间的环 +形缓冲区。读取它的通常方法是使用 ``dmesg`` 。 + +printk()的用法通常是这样的:: + + printk(KERN_INFO "Message: %s\n", arg); + +其中 ``KERN_INFO`` 是日志级别（注意，它与格式字符串连在一起，日志级别不是一个单独的参数）。 +可用的日志级别是： + + ++----------------+--------+-----------------------------------------------+ +| 名称 | 字符串 | 别名函数 | ++================+========+===============================================+ +| KERN_EMERG | "0" | pr_emerg() | ++----------------+--------+-----------------------------------------------+ +| KERN_ALERT | "1" | pr_alert() | ++----------------+--------+-----------------------------------------------+ +| KERN_CRIT | "2" | pr_crit() | ++----------------+--------+-----------------------------------------------+ +| KERN_ERR | "3" | pr_err() | ++----------------+--------+-----------------------------------------------+ +| KERN_WARNING | "4" | pr_warn() | ++----------------+--------+-----------------------------------------------+ +| KERN_NOTICE | "5" | pr_notice() | ++----------------+--------+-----------------------------------------------+ +| KERN_INFO | "6" | pr_info() | ++----------------+--------+-----------------------------------------------+ +| KERN_DEBUG | "7" | pr_debug() and pr_devel() 若定义了DEBUG | ++----------------+--------+-----------------------------------------------+ +| KERN_DEFAULT | "" | | ++----------------+--------+-----------------------------------------------+ +| KERN_CONT | "c" | pr_cont() | ++----------------+--------+-----------------------------------------------+ + + +日志级别指定了一条消息的重要性。内核根据日志级别和当前 *console_loglevel* （一个内核变量）决 +定是否立即显示消息（将其打印到当前控制台）。如果消息的优先级比 *console_loglevel* 高（日志级 +别值较低），消息将被打印到控制台。 + +如果省略了日志级别，则以 ``KERN_DEFAULT`` 级别打印消息。 + +你可以用以下方法检查当前的 *console_loglevel* :: + + $ cat /proc/sys/kernel/printk + 4 4 1 7 + +结果显示了 *current*, *default*, *minimum* 和 *boot-time-default* 日志级别 + +要改变当前的 console_loglevel，只需在 ``/proc/sys/kernel/printk`` 中写入所需的 +级别。例如，要打印所有的消息到控制台上:: + + # echo 8 > /proc/sys/kernel/printk + +另一种方式，使用 ``dmesg``:: + + # dmesg -n 5 + +设置 console_loglevel 打印 KERN_WARNING (4) 或更严重的消息到控制台。更多消息参 +见 ``dmesg(1)`` 。 + +作为printk()的替代方案，你可以使用 ``pr_*()`` 别名来记录日志。这个系列的宏在宏名中 +嵌入了日志级别。例如:: + + pr_info("Info message no. %d\n", msg_num); + +打印 ``KERN_INFO`` 消息。 + +除了比等效的printk()调用更简洁之外，它们还可以通过pr_fmt()宏为格式字符串使用一个通用 +的定义。例如，在源文件的顶部（在任何 ``#include`` 指令之前）定义这样的内容。:: + + #define pr_fmt(fmt) "%s:%s: " fmt, KBUILD_MODNAME, __func__ + +会在该文件中的每一条 pr_*() 消息前加上发起该消息的模块和函数名称。 + +为了调试，还有两个有条件编译的宏： +pr_debug()和pr_devel()，除非定义了 ``DEBUG`` (或者在pr_debug()的情况下定义了 +``CONFIG_DYNAMIC_DEBUG`` )，否则它们会被编译。 + + +函数接口 +======== + +该API在以下内核代码中: + +kernel/printk/printk.c + +include/linux/printk.h -- cgit v1.2.3 From eb2e708b9727806893e379c091184270c5468a6c Mon Sep 17 00:00:00 2001 From: Yanteng Si Date: Mon, 17 May 2021 16:46:15 +0800 Subject: docs/zh_CN: add core-api printk-formats.rst translation This patch translates Documentation/core-api/printk-formats.rst into Chinese. Signed-off-by: Yanteng Si Reviewed-by: Wu XiangCheng Reviewed-by: Alex Shi Reviewed-by: Jiaxun Yang Link: https://lore.kernel.org/r/b9dea1426e43d8848f1a8b7319c002418aebd3df.1621239725.git.siyanteng@loongson.cn Signed-off-by: Jonathan Corbet --- .../translations/zh_CN/core-api/index.rst | 2 +- .../translations/zh_CN/core-api/printk-formats.rst | 580 +++++++++++++++++++++ 2 files changed, 581 insertions(+), 1 deletion(-) create mode 100644 Documentation/translations/zh_CN/core-api/printk-formats.rst (limited to 'Documentation') diff --git a/Documentation/translations/zh_CN/core-api/index.rst b/Documentation/translations/zh_CN/core-api/index.rst index 5ecb23e3ba8c..c2d4614d9e68 100644 --- a/Documentation/translations/zh_CN/core-api/index.rst +++ b/Documentation/translations/zh_CN/core-api/index.rst @@ -24,10 +24,10 @@ kernel-api printk-basics + printk-formats Todolist: workqueue - printk-formats symbol-namespaces 数据结构和低级实用程序 diff --git a/Documentation/translations/zh_CN/core-api/printk-formats.rst b/Documentation/translations/zh_CN/core-api/printk-formats.rst new file mode 100644 index 000000000000..624a090e6ee5 --- /dev/null +++ b/Documentation/translations/zh_CN/core-api/printk-formats.rst @@ -0,0 +1,580 @@ +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/core-api/printk-formats.rst +:Translator: Yanteng Si + +.. _cn_printk-formats.rst: + + +============================== +如何获得正确的printk格式占位符 +============================== + + + +:作者: Randy Dunlap +:作者: Andrew Murray + + +整数类型 +======== + +:: + + 若变量类型是Type，则使用printk格式占位符。 + ------------------------------------------- + char %d 或 %x + unsigned char %u 或 %x + short int %d 或 %x + unsigned short int %u 或 %x + int %d 或 %x + unsigned int %u 或 %x + long %ld 或 %lx + unsigned long %lu 或 %lx + long long %lld 或 %llx + unsigned long long %llu 或 %llx + size_t %zu 或 %zx + ssize_t %zd 或 %zx + s8 %d 或 %x + u8 %u 或 %x + s16 %d 或 %x + u16 %u 或 %x + s32 %d 或 %x + u32 %u 或 %x + s64 %lld 或 %llx + u64 %llu 或 %llx + + +如果 的大小依赖于配置选项 (例如 sector_t, blkcnt_t) 或其大小依赖于架构 +(例如 tcflag_t)，则使用其可能的最大类型的格式占位符并显式强制转换为它。 + +例如 + +:: + + printk("test: sector number/total blocks: %llu/%llu\n", + (unsigned long long)sector, (unsigned long long)blockcount); + +提醒：sizeof()返回类型为size_t。 + +内核的printf不支持%n。显而易见，浮点格式(%e, %f, %g, %a)也不被识别。使用任何不 +支持的占位符或长度限定符都会导致一个WARN并且终止vsnprintf()执行。 + +指针类型 +======== + +一个原始指针值可以用%p打印，它将在打印前对地址进行哈希处理。内核也支持扩展占位符来打印 +不同类型的指针。 + +一些扩展占位符会打印给定地址上的数据，而不是打印地址本身。在这种情况下，以下错误消息可能 +会被打印出来，而不是无法访问的消息:: + + (null) data on plain NULL address + (efault) data on invalid address + (einval) invalid data on a valid address + +普通指针 +---------- + +:: + + %p abcdef12 or 00000000abcdef12 + +没有指定扩展名的指针（即没有修饰符的%p）被哈希（hash），以防止内核内存布局消息的泄露。这 +样还有一个额外的好处，就是提供一个唯一的标识符。在64位机器上，前32位被清零。当没有足够的 +熵进行散列处理时，内核将打印(ptrval)代替 + +如果可能的话，使用专门的修饰符，如%pS或%pB（如下所述），以避免打印一个必须事后解释的非哈 +希地址。如果不可能，而且打印地址的目的是为调试提供更多的消息，使用%p，并在调试过程中 +用 ``no_hash_pointers`` 参数启动内核，这将打印所有未修改的%p地址。如果你 *真的* 想知 +道未修改的地址，请看下面的%px。 + +如果（也只有在）你将地址作为虚拟文件的内容打印出来，例如在procfs或sysfs中（使用 +seq_printf()，而不是printk()）由用户空间进程读取，使用下面描述的%pK修饰符，不 +要用%p或%px。 + + +错误指针 +-------- + +:: + + %pe -ENOSPC + +用于打印错误指针(即IS_ERR()为真的指针)的符号错误名。不知道符号名的错误值会以十进制打印， +而作为%pe参数传递的非ERR_PTR会被视为普通的%p。 + +符号/函数指针 +------------- + +:: + + %pS versatile_init+0x0/0x110 + %ps versatile_init + %pSR versatile_init+0x9/0x110 + (with __builtin_extract_return_addr() translation) + %pB prev_fn_of_versatile_init+0x88/0x88 + + +``S`` 和 ``s`` 占位符用于打印符号格式的指针。它们的结果是符号名称带有(S)或不带有(s)偏移 +量。如果禁用KALLSYMS，则打印符号地址。 + +``B`` 占位符的结果是带有偏移量的符号名，在打印堆栈回溯时应该使用。占位符将考虑编译器优化 +的影响，当使用尾部调用并使用noreturn GCC属性标记时，可能会发生这种优化。 + +来自BPF / tracing追踪的探查指针 +---------------------------------- + +:: + + %pks kernel string + %pus user string + +``k`` 和 ``u`` 指定符用于打印来自内核内存(k)或用户内存(u)的先前探测的内存。后面的 ``s`` 指 +定符的结果是打印一个字符串。对于直接在常规的vsnprintf()中使用时，(k)和(u)注释被忽略，但是，当 +在BPF的bpf_trace_printk()之外使用时，它会读取它所指向的内存，不会出现错误。 + +内核指针 +-------- + +:: + + %pK 01234567 or 0123456789abcdef + +用于打印应该对非特权用户隐藏的内核指针。%pK的行为取决于kptr_restrict sysctl——详见 +Documentation/admin-guide/sysctl/kernel.rst。 + +未经修改的地址 +-------------- + +:: + + %px 01234567 or 0123456789abcdef + +对于打印指针，当你 *真的* 想打印地址时。在用%px打印指针之前，请考虑你是否泄露了内核内 +存布局的敏感消息。%px在功能上等同于%lx（或%lu）。%px是首选，因为它在grep查找时更唯一。 +如果将来我们需要修改内核处理打印指针的方式，我们将能更好地找到调用点。 + +在使用%px之前，请考虑使用%p并在调试过程中启用' ' no_hash_pointer ' '内核参数是否足 +够(参见上面的%p描述)。%px的一个有效场景可能是在panic发生之前立即打印消息，这样无论如何 +都可以防止任何敏感消息被利用，使用%px就不需要用no_hash_pointer来重现panic。 + +指针差异 +-------- + +:: + + %td 2560 + %tx a00 + +为了打印指针的差异，使用ptrdiff_t的%t修饰符。 + +例如:: + + printk("test: difference between pointers: %td\n", ptr2 - ptr1); + +结构体资源（Resources） +----------------------- + +:: + + %pr [mem 0x60000000-0x6fffffff flags 0x2200] or + [mem 0x0000000060000000-0x000000006fffffff flags 0x2200] + %pR [mem 0x60000000-0x6fffffff pref] or + [mem 0x0000000060000000-0x000000006fffffff pref] + +用于打印结构体资源。 ``R`` 和 ``r`` 占位符的结果是打印出的资源带有（R）或不带有（r）解码标志 +成员。 + +通过引用传递。 + +物理地址类型 phys_addr_t +------------------------ + +:: + + %pa[p] 0x01234567 or 0x0123456789abcdef + +用于打印phys_addr_t类型（以及它的衍生物，如resource_size_t），该类型可以根据构建选项而 +变化，无论CPU数据真实物理地址宽度如何。 + +通过引用传递。 + +DMA地址类型dma_addr_t +--------------------- + +:: + + %pad 0x01234567 or 0x0123456789abcdef + +用于打印dma_addr_t类型，该类型可以根据构建选项而变化，而不考虑CPU数据路径的宽度。 + +通过引用传递。 + +原始缓冲区为转义字符串 +---------------------- + +:: + + %*pE[achnops] + +用于将原始缓冲区打印成转义字符串。对于以下缓冲区:: + + 1b 62 20 5c 43 07 22 90 0d 5d + +几个例子展示了如何进行转换（不包括两端的引号）。:: + + %*pE "\eb \C\a"\220\r]" + %*pEhp "\x1bb \C\x07"\x90\x0d]" + %*pEa "\e\142\040\\\103\a\042\220\r\135" + +转换规则是根据可选的标志组合来应用的(详见:c:func:`string_escape_mem` 内核文档): + + - a - ESCAPE_ANY + - c - ESCAPE_SPECIAL + - h - ESCAPE_HEX + - n - ESCAPE_NULL + - o - ESCAPE_OCTAL + - p - ESCAPE_NP + - s - ESCAPE_SPACE + +默认情况下，使用 ESCAPE_ANY_NP。 + +ESCAPE_ANY_NP是许多情况下的明智选择，特别是对于打印SSID。 + +如果字段宽度被省略，那么将只转义1个字节。 + +原始缓冲区为十六进制字符串 +-------------------------- + +:: + + %*ph 00 01 02 ... 3f + %*phC 00:01:02: ... :3f + %*phD 00-01-02- ... -3f + %*phN 000102 ... 3f + +对于打印小的缓冲区（最长64个字节），可以用一定的分隔符作为一个 +十六进制字符串。对于较大的缓冲区，可以考虑使用 +:c:func:`print_hex_dump` 。 + +MAC/FDDI地址 +------------ + +:: + + %pM 00:01:02:03:04:05 + %pMR 05:04:03:02:01:00 + %pMF 00-01-02-03-04-05 + %pm 000102030405 + %pmR 050403020100 + +用于打印以十六进制表示的6字节MAC/FDDI地址。 ``M`` 和 ``m`` 占位符导致打印的 +地址有(M)或没有(m)字节分隔符。默认的字节分隔符是冒号（：）。 + +对于FDDI地址，可以在 ``M`` 占位符之后使用 ``F`` 说明，以使用破折号(——)分隔符 +代替默认的分隔符。 + +对于蓝牙地址， ``R`` 占位符应使用在 ``M`` 占位符之后，以使用反转的字节顺序，适 +合于以小尾端顺序的蓝牙地址的肉眼可见的解析。 + +通过引用传递。 + +IPv4地址 +-------- + +:: + + %pI4 1.2.3.4 + %pi4 001.002.003.004 + %p[Ii]4[hnbl] + +用于打印IPv4点分隔的十进制地址。 ``I4`` 和 ``i4`` 占位符的结果是打印的地址 +有(i4)或没有(I4)前导零。 + +附加的 ``h`` 、 ``n`` 、 ``b`` 和 ``l`` 占位符分别用于指定主机、网络、大 +尾端或小尾端地址。如果没有提供占位符，则使用默认的网络/大尾端顺序。 + +通过引用传递。 + +IPv6 地址 +--------- + +:: + + %pI6 0001:0002:0003:0004:0005:0006:0007:0008 + %pi6 00010002000300040005000600070008 + %pI6c 1:2:3:4:5:6:7:8 + +用于打印IPv6网络顺序的16位十六进制地址。 ``I6`` 和 ``i6`` 占位符的结果是 +打印的地址有(I6)或没有(i6)分号。始终使用前导零。 + +额外的 ``c`` 占位符可与 ``I`` 占位符一起使用，以打印压缩的IPv6地址，如 +https://tools.ietf.org/html/rfc5952 所述 + +通过引用传递。 + +IPv4/IPv6地址(generic, with port, flowinfo, scope) +-------------------------------------------------- + +:: + + %pIS 1.2.3.4 or 0001:0002:0003:0004:0005:0006:0007:0008 + %piS 001.002.003.004 or 00010002000300040005000600070008 + %pISc 1.2.3.4 or 1:2:3:4:5:6:7:8 + %pISpc 1.2.3.4:12345 or [1:2:3:4:5:6:7:8]:12345 + %p[Ii]S[pfschnbl] + +用于打印一个IP地址，不需要区分它的类型是AF_INET还是AF_INET6。一个指向有效结构 +体sockaddr的指针，通过 ``IS`` 或 ``IS`` 指定，可以传递给这个格式占位符。 + +附加的 ``p`` 、 ``f`` 和 ``s`` 占位符用于指定port(IPv4, IPv6)、 +flowinfo (IPv6)和sope(IPv6)。port有一个 ``:`` 前缀，flowinfo是 ``/`` 和 +范围是 ``%`` ，每个后面都跟着实际的值。 + +对于IPv6地址，如果指定了额外的指定符 ``c`` ，则使用 +https://tools.ietf.org/html/rfc5952 描述的压缩IPv6地址。 +如https://tools.ietf.org/html/draft-ietf-6man-text-addr-representation-07 +所建议的，IPv6地址由'['，']'包围，以防止出现额外的占位符 ``p`` ， ``f`` 或 ``s`` 。 + +对于IPv4地址，也可以使用额外的 ``h`` ， ``n`` ， ``b`` 和 ``l`` 说 +明符，但对于IPv6地址则忽略。 + +通过引用传递。 + +更多例子:: + + %pISfc 1.2.3.4 or [1:2:3:4:5:6:7:8]/123456789 + %pISsc 1.2.3.4 or [1:2:3:4:5:6:7:8]%1234567890 + %pISpfc 1.2.3.4:12345 or [1:2:3:4:5:6:7:8]:12345/123456789 + +UUID/GUID地址 +------------- + +:: + + %pUb 00010203-0405-0607-0809-0a0b0c0d0e0f + %pUB 00010203-0405-0607-0809-0A0B0C0D0E0F + %pUl 03020100-0504-0706-0809-0a0b0c0e0e0f + %pUL 03020100-0504-0706-0809-0A0B0C0E0E0F + +用于打印16字节的UUID/GUIDs地址。附加的 ``l`` , ``L`` , ``b`` 和 ``B`` 占位符用 +于指定小写(l)或大写(L)十六进制表示法中的小尾端顺序，以及小写(b)或大写(B)十六进制表 +示法中的大尾端顺序。 + +如果没有使用额外的占位符，则将打印带有小写十六进制表示法的默认大端顺序。 + +通过引用传递。 + +目录项（dentry）的名称 +---------------------- + +:: + + %pd{,2,3,4} + %pD{,2,3,4} + +用于打印dentry名称；如果我们用 :c:func:`d_move` 和它比较，名称可能是新旧混合的，但 +不会oops。 %pd dentry比较安全，其相当于我们以前用的%s dentry->d_name.name，%pd打 +印 ``n`` 最后的组件。 %pD对结构文件做同样的事情。 + + +通过引用传递。 + +块设备（block_device）名称 +-------------------------- + +:: + + %pg sda, sda1 or loop0p1 + +用于打印block_device指针的名称。 + +va_format结构体 +--------------- + +:: + + %pV + +用于打印结构体va_format。这些结构包含一个格式字符串 +和va_list如下 + +:: + + struct va_format { + const char *fmt; + va_list *va; + }; + +实现 "递归vsnprintf"。 + +如果没有一些机制来验证格式字符串和va_list参数的正确性，请不要使用这个功能。 + +通过引用传递。 + +设备树节点 +---------- + +:: + + %pOF[fnpPcCF] + + +用于打印设备树节点结构。默认行为相当于%pOFf。 + + - f - 设备节点全称 + - n - 设备节点名 + - p - 设备节点句柄 + - P - 设备节点路径规范(名称+@单位) + - F - 设备节点标志 + - c - 主要兼容字符串 + - C - 全兼容字符串 + +当使用多个参数时，分隔符是':'。 + +例如 + +:: + + %pOF /foo/bar@0 - Node full name + %pOFf /foo/bar@0 - Same as above + %pOFfp /foo/bar@0:10 - Node full name + phandle + %pOFfcF /foo/bar@0:foo,device:--P- - Node full name + + major compatible string + + node flags + D - dynamic + d - detached + P - Populated + B - Populated bus + +通过引用传递。 + +Fwnode handles +-------------- + +:: + + %pfw[fP] + +用于打印fwnode_handles的消息。默认情况下是打印完整的节点名称，包括路径。 +这些修饰符在功能上等同于上面的%pOF。 + + - f - 节点的全名，包括路径。 + - P - 节点名称，包括地址（如果有的话）。 + +例如 (ACPI) + +:: + + %pfwf \_SB.PCI0.CIO2.port@1.endpoint@0 - Full node name + %pfwP endpoint@0 - Node name + +例如 (OF) + +:: + + %pfwf /ocp@68000000/i2c@48072000/camera@10/port/endpoint - Full name + %pfwP endpoint - Node name + +时间和日期 +---------- + +:: + + %pt[RT] YYYY-mm-ddTHH:MM:SS + %pt[RT]d YYYY-mm-dd + %pt[RT]t HH:MM:SS + %pt[RT][dt][r] + +用于打印日期和时间:: + + R struct rtc_time structure + T time64_t type + +以我们（人类）可读的格式。 + +默认情况下，年将以1900为单位递增，月将以1为单位递增。 使用%pt[RT]r (raw) +来抑制这种行为。 + +通过引用传递。 + +clk结构体 +--------- + +:: + + %pC pll1 + %pCn pll1 + +用于打印clk结构。%pC 和 %pCn 打印时钟的名称（通用时钟框架）或唯一的32位 +ID（传统时钟框架）。 + +通过引用传递。 + +位图及其衍生物，如cpumask和nodemask +----------------------------------- + +:: + + %*pb 0779 + %*pbl 0,3-6,8-10 + +对于打印位图（bitmap）及其派生的cpumask和nodemask，%*pb输出以字段宽度为位数的位图， +%*pbl输出以字段宽度为位数的范围列表。 + +字段宽度用值传递，位图用引用传递。可以使用辅助宏cpumask_pr_args()和 +nodemask_pr_args()来方便打印cpumask和nodemask。 + +标志位字段，如页标志、gfp_flags +------------------------------- + +:: + + %pGp referenced|uptodate|lru|active|private|node=0|zone=2|lastcpupid=0x1fffff + %pGg GFP_USER|GFP_DMA32|GFP_NOWARN + %pGv read|exec|mayread|maywrite|mayexec|denywrite + +将flags位字段打印为构造值的符号常量集合。标志的类型由第三个字符给出。目前支持的 +是[p]age flags， [v]ma_flags(都期望 ``unsigned long *`` )和 +[g]fp_flags(期望 ``gfp_t *`` )。标志名称和打印顺序取决于特定的类型。 + +注意，这种格式不应该直接用于跟踪点的:c:func:`TP_printk()` 部分。相反，应使 +用 中的show_*_flags()函数。 + +通过引用传递。 + +网络设备特性 +------------ + +:: + + %pNF 0x000000000000c000 + +用于打印netdev_features_t。 + +通过引用传递。 + +V4L2和DRM FourCC代码(像素格式) +------------------------------ + +:: + + %p4cc + +打印V4L2或DRM使用的FourCC代码，包括格式端序及其十六进制的数值。 + +通过引用传递。 + +例如:: + + %p4cc BG12 little-endian (0x32314742) + %p4cc Y10 little-endian (0x20303159) + %p4cc NV12 big-endian (0xb231564e) + +谢谢 +==== + +如果您添加了其他%p扩展，请在可行的情况下，用一个或多个测试用例扩展。 + +谢谢你的合作和关注。 -- cgit v1.2.3 From b345b9ab1d0c7811f96d87cfb87a6cda01624b16 Mon Sep 17 00:00:00 2001 From: Yanteng Si Date: Mon, 17 May 2021 21:29:27 +0800 Subject: docs/zh_CN: add core-api workqueue.rst translation This patch translates Documentation/core-api/workqueue.rst into Chinese. Signed-off-by: Yanteng Si Reviewed-by: Alex Shi Link: https://lore.kernel.org/r/20210517132927.3461185-1-siyanteng@loongson.cn Signed-off-by: Jonathan Corbet --- .../translations/zh_CN/core-api/index.rst | 2 +- .../translations/zh_CN/core-api/workqueue.rst | 337 +++++++++++++++++++++ 2 files changed, 338 insertions(+), 1 deletion(-) create mode 100644 Documentation/translations/zh_CN/core-api/workqueue.rst (limited to 'Documentation') diff --git a/Documentation/translations/zh_CN/core-api/index.rst b/Documentation/translations/zh_CN/core-api/index.rst index c2d4614d9e68..34be9b25cfa1 100644 --- a/Documentation/translations/zh_CN/core-api/index.rst +++ b/Documentation/translations/zh_CN/core-api/index.rst @@ -25,9 +25,9 @@ kernel-api printk-basics printk-formats + workqueue Todolist: - workqueue symbol-namespaces 数据结构和低级实用程序 diff --git a/Documentation/translations/zh_CN/core-api/workqueue.rst b/Documentation/translations/zh_CN/core-api/workqueue.rst new file mode 100644 index 000000000000..0b8f730db6c0 --- /dev/null +++ b/Documentation/translations/zh_CN/core-api/workqueue.rst @@ -0,0 +1,337 @@ +.. SPDX-License-Identifier: GPL-2.0 +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/core-api/workqueue.rst +:Translator: Yanteng Si + +.. _cn_workqueue.rst: + + +========================= +并发管理的工作队列 (cmwq) +========================= + +:日期: September, 2010 +:作者: Tejun Heo +:作者: Florian Mickler + + +简介 +==== + +在很多情况下，需要一个异步进程的执行环境，工作队列（wq）API是这种情况下 +最常用的机制。 + +当需要这样一个异步执行上下文时，一个描述将要执行的函数的工作项（work， +即一个待执行的任务）被放在队列中。一个独立的线程作为异步执行环境。该队 +列被称为workqueue，线程被称为工作者（worker，即执行这一队列的线程）。 + +当工作队列上有工作项时，工作者会一个接一个地执行与工作项相关的函数。当 +工作队列中没有任何工作项时，工作者就会变得空闲。当一个新的工作项被排入 +队列时，工作者又开始执行。 + + +为什么要cmwq? +============= + +在最初的wq实现中，多线程（MT）wq在每个CPU上有一个工作者线程，而单线程 +（ST）wq在全系统有一个工作者线程。一个MT wq需要保持与CPU数量相同的工 +作者数量。这些年来，内核增加了很多MT wq的用户，随着CPU核心数量的不断 +增加，一些系统刚启动就达到了默认的32k PID的饱和空间。 + +尽管MT wq浪费了大量的资源，但所提供的并发性水平却不能令人满意。这个限 +制在ST和MT wq中都有，只是在MT中没有那么严重。每个wq都保持着自己独立的 +工作者池。一个MT wq只能为每个CPU提供一个执行环境，而一个ST wq则为整个 +系统提供一个。工作项必须竞争这些非常有限的执行上下文，从而导致各种问题， +包括在单一执行上下文周围容易发生死锁。 + +(MT wq)所提供的并发性水平和资源使用之间的矛盾也迫使其用户做出不必要的权衡，比 +如libata选择使用ST wq来轮询PIO，并接受一个不必要的限制，即没有两个轮 +询PIO可以同时进行。由于MT wq并没有提供更好的并发性，需要更高层次的并 +发性的用户，如async或fscache，不得不实现他们自己的线程池。 + +并发管理工作队列（cmwq）是对wq的重新实现，重点是以下目标。 + +* 保持与原始工作队列API的兼容性。 + +* 使用由所有wq共享的每CPU统一的工作者池，在不浪费大量资源的情况下按 +* 需提供灵活的并发水平。 + +* 自动调节工作者池和并发水平，使API用户不需要担心这些细节。 + + +设计 +==== + +为了简化函数的异步执行，引入了一个新的抽象概念，即工作项。 + +一个工作项是一个简单的结构，它持有一个指向将被异步执行的函数的指针。 +每当一个驱动程序或子系统希望一个函数被异步执行时，它必须建立一个指 +向该函数的工作项，并在工作队列中排队等待该工作项。（就是挂到workqueue +队列里面去） + +特定目的线程，称为工作线程（工作者），一个接一个地执行队列中的功能。 +如果没有工作项排队，工作者线程就会闲置。这些工作者线程被管理在所谓 +的工作者池中。 + +cmwq设计区分了面向用户的工作队列，子系统和驱动程序在上面排队工作， +以及管理工作者池和处理排队工作项的后端机制。 + +每个可能的CPU都有两个工作者池，一个用于正常的工作项，另一个用于高 +优先级的工作项，还有一些额外的工作者池，用于服务未绑定工作队列的工 +作项目——这些后备池的数量是动态的。 + +当他们认为合适的时候，子系统和驱动程序可以通过特殊的 +``workqueue API`` 函数创建和排队工作项。他们可以通过在工作队列上 +设置标志来影响工作项执行方式的某些方面，他们把工作项放在那里。这些 +标志包括诸如CPU定位、并发限制、优先级等等。要获得详细的概述，请参 +考下面的 ``alloc_workqueue()`` 的 API 描述。 + +当一个工作项被排入一个工作队列时，目标工作池将根据队列参数和工作队 +列属性确定，并被附加到工作池的共享工作列表上。例如，除非特别重写， +否则一个绑定的工作队列的工作项将被排在与发起线程运行的CPU相关的普 +通或高级工作工作者池的工作项列表中。 + +对于任何工作者池的实施，管理并发水平（有多少执行上下文处于活动状 +态）是一个重要问题。最低水平是为了节省资源，而饱和水平是指系统被 +充分使用。 + +每个与实际CPU绑定的worker-pool通过钩住调度器来实现并发管理。每当 +一个活动的工作者被唤醒或睡眠时，工作者池就会得到通知，并跟踪当前可 +运行的工作者的数量。一般来说，工作项不会占用CPU并消耗很多周期。这 +意味着保持足够的并发性以防止工作处理停滞应该是最优的。只要CPU上有 +一个或多个可运行的工作者，工作者池就不会开始执行新的工作，但是，当 +最后一个运行的工作者进入睡眠状态时，它会立即安排一个新的工作者，这 +样CPU就不会在有待处理的工作项目时闲置。这允许在不损失执行带宽的情 +况下使用最少的工作者。 + +除了kthreads的内存空间外，保留空闲的工作者并没有其他成本，所以cmwq +在杀死它们之前会保留一段时间的空闲。 + +对于非绑定的工作队列，后备池的数量是动态的。可以使用 +``apply_workqueue_attrs()`` 为非绑定工作队列分配自定义属性， +workqueue将自动创建与属性相匹配的后备工作者池。调节并发水平的责任在 +用户身上。也有一个标志可以将绑定的wq标记为忽略并发管理。 +详情请参考API部分。 + +前进进度的保证依赖于当需要更多的执行上下文时可以创建工作者，这也是 +通过使用救援工作者来保证的。所有可能在处理内存回收的代码路径上使用 +的工作项都需要在wq上排队，wq上保留了一个救援工作者，以便在内存有压 +力的情况下下执行。否则，工作者池就有可能出现死锁，等待执行上下文释 +放出来。 + + +应用程序编程接口 (API) +====================== + +``alloc_workqueue()`` 分配了一个wq。原来的 ``create_*workqueue()`` +函数已被废弃，并计划删除。 ``alloc_workqueue()`` 需要三个 +参数 - ``@name`` , ``@flags`` 和 ``@max_active`` 。 +``@name`` 是wq的名称，如果有的话，也用作救援线程的名称。 + +一个wq不再管理执行资源，而是作为前进进度保证、刷新(flush)和 +工作项属性的域。 ``@flags`` 和 ``@max_active`` 控制着工作 +项如何被分配执行资源、安排和执行。 + + +``flags`` +--------- + +``WQ_UNBOUND`` + 排队到非绑定wq的工作项由特殊的工作者池提供服务，这些工作者不 + 绑定在任何特定的CPU上。这使得wq表现得像一个简单的执行环境提 + 供者，没有并发管理。非绑定工作者池试图尽快开始执行工作项。非 + 绑定的wq牺牲了局部性，但在以下情况下是有用的。 + + * 预计并发水平要求会有很大的波动，使用绑定的wq最终可能会在不 + 同的CPU上产生大量大部分未使用的工作者，因为发起线程在不同 + 的CPU上跳转。 + + * 长期运行的CPU密集型工作负载，可以由系统调度器更好地管理。 + +``WQ_FREEZABLE`` + 一个可冻结的wq参与了系统暂停操作的冻结阶段。wq上的工作项被 + 排空，在解冻之前没有新的工作项开始执行。 + +``WQ_MEM_RECLAIM`` + 所有可能在内存回收路径中使用的wq都必须设置这个标志。无论内 + 存压力如何，wq都能保证至少有一个执行上下文。 + +``WQ_HIGHPRI`` + 高优先级wq的工作项目被排到目标cpu的高优先级工作者池中。高 + 优先级的工作者池由具有较高级别的工作者线程提供服务。 + + 请注意，普通工作者池和高优先级工作者池之间并不相互影响。他 + 们各自维护其独立的工作者池，并在其工作者之间实现并发管理。 + +``WQ_CPU_INTENSIVE`` + CPU密集型wq的工作项对并发水平没有贡献。换句话说，可运行的 + CPU密集型工作项不会阻止同一工作者池中的其他工作项开始执行。 + 这对于那些预计会占用CPU周期的绑定工作项很有用，这样它们的 + 执行就会受到系统调度器的监管。 + + 尽管CPU密集型工作项不会对并发水平做出贡献，但它们的执行开 + 始仍然受到并发管理的管制，可运行的非CPU密集型工作项会延迟 + CPU密集型工作项的执行。 + + 这个标志对于未绑定的wq来说是没有意义的。 + +请注意，标志 ``WQ_NON_REENTRANT`` 不再存在，因为现在所有的工作 +队列都是不可逆的——任何工作项都保证在任何时间内最多被整个系统的一 +个工作者执行。 + + +``max_active`` +-------------- + +``@max_active`` 决定了每个CPU可以分配给wq的工作项的最大执行上 +下文数量。例如，如果 ``@max_active为16`` ，每个CPU最多可以同 +时执行16个wq的工作项。 + +目前，对于一个绑定的wq， ``@max_active`` 的最大限制是512，当指 +定为0时使用的默认值是256。对于非绑定的wq，其限制是512和 +4 * ``num_possible_cpus()`` 中的较高值。这些值被选得足够高，所 +以它们不是限制性因素，同时会在失控情况下提供保护。 + +一个wq的活动工作项的数量通常由wq的用户来调节，更具体地说，是由用 +户在同一时间可以排列多少个工作项来调节。除非有特定的需求来控制活动 +工作项的数量，否则建议指定 为"0"。 + +一些用户依赖于ST wq的严格执行顺序。 ``@max_active`` 为1和 ``WQ_UNBOUND`` +的组合用来实现这种行为。这种wq上的工作项目总是被排到未绑定的工作池 +中，并且在任何时候都只有一个工作项目处于活动状态，从而实现与ST wq相 +同的排序属性。 + +在目前的实现中，上述配置只保证了特定NUMA节点内的ST行为。相反， +``alloc_ordered_queue()`` 应该被用来实现全系统的ST行为。 + + +执行场景示例 +============ + +下面的示例执行场景试图说明cmwq在不同配置下的行为。 + + 工作项w0、w1、w2被排到同一个CPU上的一个绑定的wq q0上。w0 + 消耗CPU 5ms，然后睡眠10ms，然后在完成之前再次消耗CPU 5ms。 + +忽略所有其他的任务、工作和处理开销，并假设简单的FIFO调度， +下面是一个高度简化的原始wq的可能事件序列的版本。:: + + TIME IN MSECS EVENT + 0 w0 starts and burns CPU + 5 w0 sleeps + 15 w0 wakes up and burns CPU + 20 w0 finishes + 20 w1 starts and burns CPU + 25 w1 sleeps + 35 w1 wakes up and finishes + 35 w2 starts and burns CPU + 40 w2 sleeps + 50 w2 wakes up and finishes + +And with cmwq with ``@max_active`` >= 3, :: + + TIME IN MSECS EVENT + 0 w0 starts and burns CPU + 5 w0 sleeps + 5 w1 starts and burns CPU + 10 w1 sleeps + 10 w2 starts and burns CPU + 15 w2 sleeps + 15 w0 wakes up and burns CPU + 20 w0 finishes + 20 w1 wakes up and finishes + 25 w2 wakes up and finishes + +如果 ``@max_active`` == 2, :: + + TIME IN MSECS EVENT + 0 w0 starts and burns CPU + 5 w0 sleeps + 5 w1 starts and burns CPU + 10 w1 sleeps + 15 w0 wakes up and burns CPU + 20 w0 finishes + 20 w1 wakes up and finishes + 20 w2 starts and burns CPU + 25 w2 sleeps + 35 w2 wakes up and finishes + +现在，我们假设w1和w2被排到了不同的wq q1上，这个wq q1 +有 ``WQ_CPU_INTENSIVE`` 设置:: + + TIME IN MSECS EVENT + 0 w0 starts and burns CPU + 5 w0 sleeps + 5 w1 and w2 start and burn CPU + 10 w1 sleeps + 15 w2 sleeps + 15 w0 wakes up and burns CPU + 20 w0 finishes + 20 w1 wakes up and finishes + 25 w2 wakes up and finishes + + +指南 +==== + +* 如果一个wq可能处理在内存回收期间使用的工作项目，请不 + 要忘记使用 ``WQ_MEM_RECLAIM`` 。每个设置了 + ``WQ_MEM_RECLAIM`` 的wq都有一个为其保留的执行环境。 + 如果在内存回收过程中使用的多个工作项之间存在依赖关系， + 它们应该被排在不同的wq中，每个wq都有 ``WQ_MEM_RECLAIM`` 。 + +* 除非需要严格排序，否则没有必要使用ST wq。 + +* 除非有特殊需要，建议使用0作为@max_active。在大多数使用情 + 况下，并发水平通常保持在默认限制之下。 + +* 一个wq作为前进进度保证（WQ_MEM_RECLAIM，冲洗（flush）和工 + 作项属性的域。不涉及内存回收的工作项，不需要作为工作项组的一 + 部分被刷新，也不需要任何特殊属性，可以使用系统中的一个wq。使 + 用专用wq和系统wq在执行特性上没有区别。 + +* 除非工作项预计会消耗大量的CPU周期，否则使用绑定的wq通常是有 + 益的，因为wq操作和工作项执行中的定位水平提高了。 + + +调试 +==== + +因为工作函数是由通用的工作者线程执行的，所以需要一些手段来揭示一些行为不端的工作队列用户。 + +工作者线程在进程列表中显示为: :: + + root 5671 0.0 0.0 0 0 ? S 12:07 0:00 [kworker/0:1] + root 5672 0.0 0.0 0 0 ? S 12:07 0:00 [kworker/1:2] + root 5673 0.0 0.0 0 0 ? S 12:12 0:00 [kworker/0:0] + root 5674 0.0 0.0 0 0 ? S 12:13 0:00 [kworker/1:0] + +如果kworkers失控了（使用了太多的cpu），有两类可能的问题: + + 1. 正在迅速调度的事情 + 2. 一个消耗大量cpu周期的工作项。 + +第一个可以用追踪的方式进行跟踪: :: + + $ echo workqueue:workqueue_queue_work > /sys/kernel/debug/tracing/set_event + $ cat /sys/kernel/debug/tracing/trace_pipe > out.txt + (wait a few secs) + +如果有什么东西在工作队列上忙着做循环，它就会主导输出，可以用工作项函数确定违规者。 + +对于第二类问题，应该可以只检查违规工作者线程的堆栈跟踪。 :: + + $ cat /proc/THE_OFFENDING_KWORKER/stack + +工作项函数在堆栈追踪中应该是微不足道的。 + + +内核内联文档参考 +================ + +该API在以下内核代码中: + +include/linux/workqueue.h + +kernel/workqueue.c -- cgit v1.2.3 From 6586f2d8cec186ef0af7cf6a0738293fea048ed8 Mon Sep 17 00:00:00 2001 From: Yanteng Si Date: Mon, 17 May 2021 21:37:48 +0800 Subject: docs/zh_CN: add core api kobject translation This patch translates Documentation/core-api/kobject.rst into Chinese. Signed-off-by: Yanteng Si Reviewed-by: Alex Shi Reviewed-by: Wu XiangCheng Link: https://lore.kernel.org/r/20210517133748.3461357-1-siyanteng@loongson.cn Signed-off-by: Jonathan Corbet --- .../translations/zh_CN/core-api/index.rst | 6 +- .../translations/zh_CN/core-api/kobject.rst | 378 +++++++++++++++++++++ 2 files changed, 383 insertions(+), 1 deletion(-) create mode 100644 Documentation/translations/zh_CN/core-api/kobject.rst (limited to 'Documentation') diff --git a/Documentation/translations/zh_CN/core-api/index.rst b/Documentation/translations/zh_CN/core-api/index.rst index 34be9b25cfa1..a1dd792e46f7 100644 --- a/Documentation/translations/zh_CN/core-api/index.rst +++ b/Documentation/translations/zh_CN/core-api/index.rst @@ -35,9 +35,13 @@ Todolist: 在整个内核中使用的函数库。 -Todolist: +.. toctree:: + :maxdepth: 1 kobject + +Todolist: + kref assoc_array xarray diff --git a/Documentation/translations/zh_CN/core-api/kobject.rst b/Documentation/translations/zh_CN/core-api/kobject.rst new file mode 100644 index 000000000000..f0e6a4aeb372 --- /dev/null +++ b/Documentation/translations/zh_CN/core-api/kobject.rst @@ -0,0 +1,378 @@ +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/core-api/kobject.rst +:Translator: Yanteng Si + +.. _cn_core_api_kobject.rst: + +======================================================= +关于kobjects、ksets和ktypes的一切你没想过需要了解的东西 +======================================================= + +:作者: Greg Kroah-Hartman +:最后一次更新: December 19, 2007 + +根据Jon Corbet于2003年10月1日为lwn.net撰写的原创文章改编，网址是： +https://lwn.net/Articles/51437/ + +理解驱动模型和建立在其上的kobject抽象的部分的困难在于，没有明显的切入点。 +处理kobjects需要理解一些不同的类型，所有这些类型都会相互引用。为了使事情 +变得更简单，我们将多路并进，从模糊的术语开始，并逐渐增加细节。那么，先来 +了解一些我们将要使用的术语的简明定义吧。 + + - 一个kobject是一个kobject结构体类型的对象。Kobjects有一个名字和一个 + 引用计数。一个kobject也有一个父指针（允许对象被排列成层次结构），一个 + 特定的类型，并且，通常在sysfs虚拟文件系统中表示。 + + Kobjects本身通常并不引人关注；相反它们常常被嵌入到其他包含真正引人注目 + 的代码的结构体中。 + + 任何结构体都 **不应该** 有一个以上的kobject嵌入其中。如果有的话，对象的引用计 + 数肯定会被打乱，而且不正确，你的代码就会出现错误。所以不要这样做。 + + - ktype是嵌入一个kobject的对象的类型。每个嵌入kobject的结构体都需要一个 + 相应的ktype。ktype控制着kobject在被创建和销毁时的行为。 + + - 一个kset是一组kobjects。这些kobjects可以是相同的ktype或者属于不同的 + ktype。kset是kobjects集合的基本容器类型。Ksets包含它们自己的kobjects， + 但你可以安全地忽略这个实现细节，因为kset的核心代码会自动处理这个kobject。 + + 当你看到一个下面全是其他目录的sysfs目录时，通常这些目录中的每一个都对应 + 于同一个kset中的一个kobject。 + + 我们将研究如何创建和操作所有这些类型。将采取一种自下而上的方法，所以我们 + 将回到kobjects。 + + +嵌入kobjects +============= + +内核代码很少创建孤立的kobject，只有一个主要的例外，下面会解释。相反， +kobjects被用来控制对一个更大的、特定领域的对象的访问。为此，kobjects会被 +嵌入到其他结构中。如果你习惯于用面向对象的术语来思考问题，那么kobjects可 +以被看作是一个顶级的抽象类，其他的类都是从它派生出来的。一个kobject实现了 +一系列的功能，这些功能本身并不特别有用，但在其他对象中却很好用。C语言不允 +许直接表达继承，所以必须使用其他技术——比如结构体嵌入。 + +（对于那些熟悉内核链表实现的人来说，这类似于“list_head”结构本身很少有用， +但总是被嵌入到感兴趣的更大的对象中）。 + +例如， ``drivers/uio/uio.c`` 中的IO代码有一个结构体，定义了与uio设备相 +关的内存区域:: + + struct uio_map { + struct kobject kobj; + struct uio_mem *mem; + }; + +如果你有一个uio_map结构体，找到其嵌入的kobject只是一个使用kobj成员的问题。 +然而，与kobjects一起工作的代码往往会遇到相反的问题：给定一个结构体kobject +的指针，指向包含结构体的指针是什么？你必须避免使用一些技巧（比如假设 +kobject在结构的开头），相反，你得使用container_of()宏，其可以在 ```` +中找到:: + + container_of(ptr, type, member) + +其中: + + * ``ptr`` 是一个指向嵌入kobject的指针， + * ``type`` 是包含结构体的类型， + * ``member`` 是 ``指针`` 所指向的结构体域的名称。 + +container_of()的返回值是一个指向相应容器类型的指针。因此，例如，一个嵌入到 +uio_map结构 **中** 的kobject结构体的指针kp可以被转换为一个指向 **包含** uio_map +结构体的指针，方法是:: + + struct uio_map *u_map = container_of(kp, struct uio_map, kobj); + +为了方便起见，程序员经常定义一个简单的宏，用于将kobject指针 **反推** 到包含 +类型。在早期的 ``drivers/uio/uio.c`` 中正是如此，你可以在这里看到:: + + struct uio_map { + struct kobject kobj; + struct uio_mem *mem; + }; + + #define to_map(map) container_of(map, struct uio_map, kobj) + +其中宏的参数“map”是一个指向有关的kobject结构体的指针。该宏随后被调用:: + + struct uio_map *map = to_map(kobj); + + +kobjects的初始化 +================ + +当然，创建kobject的代码必须初始化该对象。一些内部字段是通过（强制）调用kobject_init() +来设置的:: + + void kobject_init(struct kobject *kobj, struct kobj_type *ktype); + +ktype是正确创建kobject的必要条件，因为每个kobject都必须有一个相关的kobj_type。 +在调用kobject_init()后，为了向sysfs注册kobject，必须调用函数kobject_add():: + + int kobject_add(struct kobject *kobj, struct kobject *parent, + const char *fmt, ...); + +这将正确设置kobject的父级和kobject的名称。如果该kobject要与一个特定的kset相关 +联，在调用kobject_add()之前必须分配kobj->kset。如果kset与kobject相关联，则 +kobject的父级可以在调用kobject_add()时被设置为NULL，则kobject的父级将是kset +本身。 + +由于kobject的名字是在它被添加到内核时设置的，所以kobject的名字不应该被直接操作。 +如果你必须改变kobject的名字，请调用kobject_rename():: + + int kobject_rename(struct kobject *kobj, const char *new_name); + +kobject_rename()函数不会执行任何锁定操作，也不会对name进行可靠性检查，所以调用 +者自己检查和串行化操作是明智的选择 + +有一个叫kobject_set_name()的函数，但那是历史遗产，正在被删除。如果你的代码需 +要调用这个函数，那么它是不正确的，需要被修复。 + +要正确访问kobject的名称，请使用函数kobject_name():: + + const char *kobject_name(const struct kobject * kobj); + +有一个辅助函数可以同时初始化和添加kobject到内核中，令人惊讶的是，该函数被称为 +kobject_init_and_add():: + + int kobject_init_and_add(struct kobject *kobj, struct kobj_type *ktype, + struct kobject *parent, const char *fmt, ...); + +参数与上面描述的单个kobject_init()和kobject_add()函数相同。 + + +Uevents +======= + +当一个kobject被注册到kobject核心后，你需要向全世界宣布它已经被创建了。这可以通 +过调用kobject_uevent()来实现:: + + int kobject_uevent(struct kobject *kobj, enum kobject_action action); + +当kobject第一次被添加到内核时，使用 *KOBJ_ADD* 动作。这应该在该kobject的任 +何属性或子对象被正确初始化后进行，因为当这个调用发生时，用户空间会立即开始寻 +找它们。 + +当kobject从内核中移除时（关于如何做的细节在下面）， **KOBJ_REMOVE** 的uevent +将由kobject核心自动创建，所以调用者不必担心手动操作。 + + +引用计数 +======== + +kobject的关键功能之一是作为它所嵌入的对象的一个引用计数器。只要对该对象的引用 +存在，该对象（以及支持它的代码）就必须继续存在。用于操作kobject的引用计数的低 +级函数是:: + + struct kobject *kobject_get(struct kobject *kobj); + void kobject_put(struct kobject *kobj); + +对kobject_get()的成功调用将增加kobject的引用计数器值并返回kobject的指针。 + +当引用被释放时，对kobject_put()的调用将递减引用计数值，并可能释放该对象。请注 +意，kobject_init()将引用计数设置为1，所以设置kobject的代码最终需要kobject_put() +来释放该引用。 + +因为kobjects是动态的，所以它们不能以静态方式或在堆栈中声明，而总是以动态方式分 +配。未来版本的内核将包含对静态创建的kobjects的运行时检查，并将警告开发者这种不 +当的使用。 + +如果你使用struct kobject只是为了给你的结构体提供一个引用计数器，请使用struct kref +来代替；kobject是多余的。关于如何使用kref结构体的更多信息，请参见Linux内核源代 +码树中的文件Documentation/core-api/kref.rst + + +创建“简单的”kobjects +==================== + +有时，开发者想要的只是在sysfs层次结构中创建一个简单的目录，而不必去搞那些复杂 +的ksets、显示和存储函数，以及其他细节。这是一个应该创建单个kobject的例外。要 +创建这样一个条目（即简单的目录），请使用函数:: + + struct kobject *kobject_create_and_add(const char *name, struct kobject *parent); + +这个函数将创建一个kobject，并将其放在sysfs中指定的父kobject下面的位置。要创 +建与此kobject相关的简单属性，请使用:: + + int sysfs_create_file(struct kobject *kobj, const struct attribute *attr); + +或者:: + + int sysfs_create_group(struct kobject *kobj, const struct attribute_group *grp); + +这里使用的两种类型的属性，与已经用kobject_create_and_add()创建的kobject， +都可以是kobj_attribute类型，所以不需要创建特殊的自定义属性。 + +参见示例模块， ``samples/kobject/kobject-example.c`` ，以了解一个简单的 +kobject和属性的实现。 + + + +ktypes和释放方法 +================ + +以上讨论中还缺少一件重要的事情，那就是当一个kobject的引用次数达到零的时候 +会发生什么。创建kobject的代码通常不知道何时会发生这种情况；首先，如果它知 +道，那么使用kobject就没有什么意义。当sysfs被引入时，即使是可预测的对象生命 +周期也会变得更加复杂，因为内核的其他部分可以获得在系统中注册的任何kobject +的引用。 + +最终的结果是，一个由kobject保护的结构体在其引用计数归零之前不能被释放。引 +用计数不受创建kobject的代码的直接控制。因此，每当它的一个kobjects的最后一 +个引用消失时，必须异步通知该代码。 + +一旦你通过kobject_add()注册了你的kobject，你绝对不能使用kfree()来直接释 +放它。唯一安全的方法是使用kobject_put()。在kobject_init()之后总是使用 +kobject_put()以避免错误的发生是一个很好的做法。 + +这个通知是通过kobject的release()方法完成的。通常这样的方法有如下形式:: + + void my_object_release(struct kobject *kobj) + { + struct my_object *mine = container_of(kobj, struct my_object, kobj); + + /* Perform any additional cleanup on this object, then... */ + kfree(mine); + } + +有一点很重要：每个kobject都必须有一个release()方法，而且这个kobject必 +须持续存在（处于一致的状态），直到这个方法被调用。如果这些约束条件没有 +得到满足，那么代码就是有缺陷的。注意，如果你忘记提供release()方法，内 +核会警告你。不要试图通过提供一个“空”的释放函数来摆脱这个警告。 + +如果你的清理函数只需要调用kfree()，那么你必须创建一个包装函数，该函数 +使用container_of()来向上造型到正确的类型（如上面的例子所示），然后在整个 +结构体上调用kfree()。 + +注意，kobject的名字在release函数中是可用的，但它不能在这个回调中被改 +变。否则，在kobject核心中会出现内存泄漏，这让人很不爽。 + +有趣的是，release()方法并不存储在kobject本身；相反，它与ktype相关。 +因此，让我们引入结构体kobj_type:: + + struct kobj_type { + void (*release)(struct kobject *kobj); + const struct sysfs_ops *sysfs_ops; + struct attribute **default_attrs; + const struct attribute_group **default_groups; + const struct kobj_ns_type_operations *(*child_ns_type)(struct kobject *kobj); + const void *(*namespace)(struct kobject *kobj); + void (*get_ownership)(struct kobject *kobj, kuid_t *uid, kgid_t *gid); + }; + +这个结构提用来描述一个特定类型的kobject（或者更正确地说，包含对象的 +类型）。每个kobject都需要有一个相关的kobj_type结构；当你调用 +kobject_init()或kobject_init_and_add()时必须指定一个指向该结构的 +指针。 + +当然，kobj_type结构中的release字段是指向这种类型的kobject的release() +方法的一个指针。另外两个字段（sysfs_ops 和 default_attrs）控制这种 +类型的对象如何在 sysfs 中被表示；它们超出了本文的范围。 + +default_attrs 指针是一个默认属性的列表，它将为任何用这个 ktype 注册 +的 kobject 自动创建。 + + +ksets +===== + +一个kset仅仅是一个希望相互关联的kobjects的集合。没有限制它们必须是相 +同的ktype，但是如果它们不是相同的，就要非常小心。 + +一个kset有以下功能: + + - 它像是一个包含一组对象的袋子。一个kset可以被内核用来追踪“所有块 + 设备”或“所有PCI设备驱动”。 + + - kset也是sysfs中的一个子目录，与kset相关的kobjects可以在这里显示 + 出来。每个kset都包含一个kobject，它可以被设置为其他kobject的父对象； + sysfs层次结构的顶级目录就是以这种方式构建的。 + + - Ksets可以支持kobjects的 "热插拔"，并影响uevent事件如何被报告给 + 用户空间。 + + 在面向对象的术语中，“kset”是顶级的容器类；ksets包含它们自己的kobject， + 但是这个kobject是由kset代码管理的，不应该被任何其他用户所操纵。 + + kset在一个标准的内核链表中保存它的子对象。Kobjects通过其kset字段指向其 + 包含的kset。在几乎所有的情况下，属于一个kset的kobjects在它们的父 + 对象中都有那个kset（或者，严格地说，它的嵌入kobject）。 + + 由于kset中包含一个kobject，它应该总是被动态地创建，而不是静态地 + 或在堆栈中声明。要创建一个新的kset，请使用:: + + struct kset *kset_create_and_add(const char *name, + const struct kset_uevent_ops *uevent_ops, + struct kobject *parent_kobj); + +当你完成对kset的处理后，调用:: + + void kset_unregister(struct kset *k); + +来销毁它。这将从sysfs中删除该kset并递减其引用计数值。当引用计数 +为零时，该kset将被释放。因为对该kset的其他引用可能仍然存在， +释放可能发生在kset_unregister()返回之后。 + +一个使用kset的例子可以在内核树中的 ``samples/kobject/kset-example.c`` +文件中看到。 + +如果一个kset希望控制与它相关的kobjects的uevent操作，它可以使用 +结构体kset_uevent_ops来处理它:: + + struct kset_uevent_ops { + int (* const filter)(struct kset *kset, struct kobject *kobj); + const char *(* const name)(struct kset *kset, struct kobject *kobj); + int (* const uevent)(struct kset *kset, struct kobject *kobj, + struct kobj_uevent_env *env); + }; + + +过滤器函数允许kset阻止一个特定kobject的uevent被发送到用户空间。 +如果该函数返回0，该uevent将不会被发射出去。 + +name函数将被调用以覆盖uevent发送到用户空间的kset的默认名称。默 +认情况下，该名称将与kset本身相同，但这个函数，如果存在，可以覆盖 +该名称。 + +当uevent即将被发送至用户空间时，uevent函数将被调用，以允许更多 +的环境变量被添加到uevent中。 + +有人可能会问，鉴于没有提出执行该功能的函数，究竟如何将一个kobject +添加到一个kset中。答案是这个任务是由kobject_add()处理的。当一个 +kobject被传递给kobject_add()时，它的kset成员应该指向这个kobject +所属的kset。 kobject_add()将处理剩下的部分。 + +如果属于一个kset的kobject没有父kobject集，它将被添加到kset的目 +录中。并非所有的kset成员都必须住在kset目录中。如果在添加kobject +之前分配了一个明确的父kobject，那么该kobject将被注册到kset中， +但是被添加到父kobject下面。 + + +移除Kobject +=========== + +当一个kobject在kobject核心注册成功后，在代码使用完它时，必须将其 +清理掉。要做到这一点，请调用kobject_put()。通过这样做，kobject核 +心会自动清理这个kobject分配的所有内存。如果为这个对象发送了 ``KOBJ_ADD`` +uevent，那么相应的 ``KOBJ_REMOVE`` uevent也将被发送，任何其他的 +sysfs内务将被正确处理。 + +如果你需要分两次对kobject进行删除（比如说在你要销毁对象时无权睡眠）， +那么调用kobject_del()将从sysfs中取消kobject的注册。这使得kobject +“不可见”，但它并没有被清理掉，而且该对象的引用计数仍然是一样的。在稍 +后的时间调用kobject_put()来完成与该kobject相关的内存的清理。 + +kobject_del()可以用来放弃对父对象的引用，如果循环引用被构建的话。 +在某些情况下，一个父对象引用一个子对象是有效的。循环引用必须通过明 +确调用kobject_del()来打断，这样一个释放函数就会被调用，前一个循环 +中的对象会相互释放。 + + +示例代码出处 +============ + +关于正确使用ksets和kobjects的更完整的例子，请参见示例程序 +``samples/kobject/{kobject-example.c,kset-example.c}`` ，如果 +您选择 ``CONFIG_SAMPLE_KOBJECT`` ，它们将被构建为可加载模块。 -- cgit v1.2.3 From 35f1fceaa288ee0954ced2d740b95211aef4cc80 Mon Sep 17 00:00:00 2001 From: Chun-Hung Tseng Date: Sun, 16 May 2021 18:59:55 +0800 Subject: Documentation: scheduler: fixed 2 typos in sched-nice-design.rst This patch fixed 2 spelling errors in the documentation. Signed-off-by: Chun-Hung Tseng Link: https://lore.kernel.org/r/20210516105955.120651-1-henrybear327@gmail.com Signed-off-by: Jonathan Corbet --- Documentation/scheduler/sched-nice-design.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/scheduler/sched-nice-design.rst b/Documentation/scheduler/sched-nice-design.rst index 0571f1b47e64..889bf2b737dc 100644 --- a/Documentation/scheduler/sched-nice-design.rst +++ b/Documentation/scheduler/sched-nice-design.rst @@ -60,7 +60,7 @@ within the constraints of HZ and jiffies and their nasty design level coupling to timeslices and granularity it was not really viable. The second (less frequent but still periodically occurring) complaint -about Linux's nice level support was its assymetry around the origo +about Linux's nice level support was its asymmetry around the origin (which you can see demonstrated in the picture above), or more accurately: the fact that nice level behavior depended on the _absolute_ nice level as well, while the nice API itself is fundamentally -- cgit v1.2.3 From f9da1c9d7fb5e26272a060089c19823f748aab73 Mon Sep 17 00:00:00 2001 From: Ezequiel Garcia Date: Mon, 17 May 2021 12:40:36 -0300 Subject: dt-bindings: net: rockchip-dwmac: add rk3568 compatible string Add compatible string for RK3568 gmac, and constrain it to be compatible with Synopsys dwmac 4.20a. Signed-off-by: Ezequiel Garcia Signed-off-by: David S. Miller --- .../devicetree/bindings/net/rockchip-dwmac.yaml | 30 +++++++++++++--------- 1 file changed, 18 insertions(+), 12 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/rockchip-dwmac.yaml b/Documentation/devicetree/bindings/net/rockchip-dwmac.yaml index 34a660ad6b30..083623c8d718 100644 --- a/Documentation/devicetree/bindings/net/rockchip-dwmac.yaml +++ b/Documentation/devicetree/bindings/net/rockchip-dwmac.yaml @@ -24,6 +24,7 @@ select: - rockchip,rk3366-gmac - rockchip,rk3368-gmac - rockchip,rk3399-gmac + - rockchip,rk3568-gmac - rockchip,rv1108-gmac required: - compatible @@ -33,18 +34,23 @@ allOf: properties: compatible: - items: - - enum: - - rockchip,px30-gmac - - rockchip,rk3128-gmac - - rockchip,rk3228-gmac - - rockchip,rk3288-gmac - - rockchip,rk3308-gmac - - rockchip,rk3328-gmac - - rockchip,rk3366-gmac - - rockchip,rk3368-gmac - - rockchip,rk3399-gmac - - rockchip,rv1108-gmac + oneOf: + - items: + - enum: + - rockchip,px30-gmac + - rockchip,rk3128-gmac + - rockchip,rk3228-gmac + - rockchip,rk3288-gmac + - rockchip,rk3308-gmac + - rockchip,rk3328-gmac + - rockchip,rk3366-gmac + - rockchip,rk3368-gmac + - rockchip,rk3399-gmac + - rockchip,rv1108-gmac + - items: + - enum: + - rockchip,rk3568-gmac + - const: snps,dwmac-4.20a clocks: minItems: 5 -- cgit v1.2.3 From d0413118bbc306070d97c6a218960c39cb92ab5d Mon Sep 17 00:00:00 2001 From: Luca Ceresoli Date: Wed, 12 May 2021 17:23:11 +0200 Subject: docs: dt: remove stale property-units.txt, link to current schema property-units.txt is not maintained anymore. New suffixes are now supported that have not been added here. To avoid people incorrectly think a given suffix is not in the list remove the file entirely and point to the authoritative place where the recommended suffixes are maintained. Signed-off-by: Luca Ceresoli Link: https://lore.kernel.org/r/20210512152311.7399-1-luca@lucaceresoli.net Signed-off-by: Rob Herring --- .../devicetree/bindings/property-units.txt | 48 ---------------------- .../devicetree/bindings/writing-bindings.rst | 3 +- 2 files changed, 2 insertions(+), 49 deletions(-) delete mode 100644 Documentation/devicetree/bindings/property-units.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/property-units.txt b/Documentation/devicetree/bindings/property-units.txt deleted file mode 100644 index 218f99fa311f..000000000000 --- a/Documentation/devicetree/bindings/property-units.txt +++ /dev/null @@ -1,48 +0,0 @@ -Standard Unit Suffixes for Property names - -Properties which have a unit of measure are recommended to have a unit -suffix appended to the property name. The list below contains the -recommended suffixes. Other variations exist in bindings, but should not -be used in new bindings or added here. The inconsistency in the unit -prefixes is due to selecting the most commonly used variants. - -It is also recommended to use the units listed here and not add additional -unit prefixes. - -Time/Frequency ----------------------------------------- --mhz : megahertz --hz : hertz (preferred) --sec : second --ms : millisecond --us : microsecond --ns : nanosecond --ps : picosecond - -Distance ----------------------------------------- --mm : millimeter - -Electricity ----------------------------------------- --microamp : microampere --microamp-hours : microampere hour --ohms : ohm --micro-ohms : microohm --microwatt-hours: microwatt hour --microvolt : microvolt --picofarads : picofarad --femtofarads : femtofarad - -Temperature ----------------------------------------- --celsius : degree Celsius --millicelsius : millidegree Celsius - -Pressure ----------------------------------------- --kpascal : kilopascal - -Throughput ----------------------------------------- --kBps : kilobytes per second diff --git a/Documentation/devicetree/bindings/writing-bindings.rst b/Documentation/devicetree/bindings/writing-bindings.rst index 45ff426d0019..f7dfb98c156e 100644 --- a/Documentation/devicetree/bindings/writing-bindings.rst +++ b/Documentation/devicetree/bindings/writing-bindings.rst @@ -52,7 +52,8 @@ Properties constraints specific to the device. - DO use common property unit suffixes for properties with scientific units. - See property-units.txt. + Recommended suffixes are listed at + https://github.com/devicetree-org/dt-schema/blob/master/schemas/property-units.yaml - DO define properties in terms of constraints. How many entries? What are possible values? What is the order? -- cgit v1.2.3 From bb63744b02e91df8bdc0d3025c7d9f48b77f6c75 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Rafa=C5=82=20Mi=C5=82ecki?= Date: Wed, 12 May 2021 18:02:53 +0200 Subject: dt-bindings: pwm: brcm,iproc-pwm: convert to the json-schema MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit This helps validating DTS files. Signed-off-by: Rafał Miłecki Link: https://lore.kernel.org/r/20210512160253.15000-1-zajec5@gmail.com Signed-off-by: Rob Herring --- .../devicetree/bindings/pwm/brcm,iproc-pwm.txt | 21 ---------- .../devicetree/bindings/pwm/brcm,iproc-pwm.yaml | 45 ++++++++++++++++++++++ 2 files changed, 45 insertions(+), 21 deletions(-) delete mode 100644 Documentation/devicetree/bindings/pwm/brcm,iproc-pwm.txt create mode 100644 Documentation/devicetree/bindings/pwm/brcm,iproc-pwm.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pwm/brcm,iproc-pwm.txt b/Documentation/devicetree/bindings/pwm/brcm,iproc-pwm.txt deleted file mode 100644 index 655f6cd4ef46..000000000000 --- a/Documentation/devicetree/bindings/pwm/brcm,iproc-pwm.txt +++ /dev/null @@ -1,21 +0,0 @@ -Broadcom iProc PWM controller device tree bindings - -This controller has 4 channels. - -Required Properties : -- compatible: must be "brcm,iproc-pwm" -- reg: physical base address and length of the controller's registers -- clocks: phandle + clock specifier pair for the external clock -- #pwm-cells: Should be 3. See pwm.yaml in this directory for a - description of the cells format. - -Refer to clocks/clock-bindings.txt for generic clock consumer properties. - -Example: - -pwm: pwm@18031000 { - compatible = "brcm,iproc-pwm"; - reg = <0x18031000 0x28>; - clocks = <&osc>; - #pwm-cells = <3>; -}; diff --git a/Documentation/devicetree/bindings/pwm/brcm,iproc-pwm.yaml b/Documentation/devicetree/bindings/pwm/brcm,iproc-pwm.yaml new file mode 100644 index 000000000000..218ab06c34d1 --- /dev/null +++ b/Documentation/devicetree/bindings/pwm/brcm,iproc-pwm.yaml @@ -0,0 +1,45 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pwm/brcm,iproc-pwm.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Broadcom iProc PWM controller + +maintainers: + - Rafał Miłecki + +description: + This controller has 4 channels. + +allOf: + - $ref: pwm.yaml# + +properties: + compatible: + const: brcm,iproc-pwm + + reg: + maxItems: 1 + + clocks: + description: external clock + maxItems: 1 + + "#pwm-cells": + const: 3 + +unevaluatedProperties: false + +required: + - reg + - clocks + +examples: + - | + pwm@18031000 { + compatible = "brcm,iproc-pwm"; + reg = <0x18031000 0x28>; + clocks = <&osc>; + #pwm-cells = <3>; + }; -- cgit v1.2.3 From fcb501704554eebfd27e3220b0540997fd2b24a8 Mon Sep 17 00:00:00 2001 From: Mel Gorman Date: Wed, 12 May 2021 12:40:35 +0100 Subject: delayacct: Document task_delayacct sysctl Update sysctl/kernel.rst. Signed-off-by: Mel Gorman Signed-off-by: Peter Zijlstra (Intel) Link: https://lkml.kernel.org/r/20210512114035.GH3672@suse.de --- Documentation/admin-guide/sysctl/kernel.rst | 7 +++++++ 1 file changed, 7 insertions(+) (limited to 'Documentation') diff --git a/Documentation/admin-guide/sysctl/kernel.rst b/Documentation/admin-guide/sysctl/kernel.rst index 1d56a6b73a4e..ebd2f993d608 100644 --- a/Documentation/admin-guide/sysctl/kernel.rst +++ b/Documentation/admin-guide/sysctl/kernel.rst @@ -1087,6 +1087,13 @@ Model available). If your platform happens to meet the requirements for EAS but you do not want to use it, change this value to 0. +task_delayacct +=============== + +Enables/disables task delay accounting (see +:doc:`accounting/delay-accounting.rst`). Enabling this feature incurs +a small amount of overhead in the scheduler but is useful for debugging +and performance tuning. It is required by some tools such as iotop. sched_schedstats ================ -- cgit v1.2.3 From f96e6c0ef63b981d295547ef624f4da7c820e097 Mon Sep 17 00:00:00 2001 From: Andy Shevchenko Date: Mon, 17 May 2021 17:03:50 +0300 Subject: spi: pxa2xx: Update documentation to point out that it's outdated Update documentation by pointing out that it's applicable mostly for a legacy platform. While at it, add couple of points with regard to ACPI, Device Tree, and automatic DMA enablement. Signed-off-by: Andy Shevchenko Link: https://lore.kernel.org/r/20210517140351.901-9-andriy.shevchenko@linux.intel.com Signed-off-by: Mark Brown --- Documentation/spi/pxa2xx.rst | 58 ++++++++++++++++++++++++-------------------- 1 file changed, 32 insertions(+), 26 deletions(-) (limited to 'Documentation') diff --git a/Documentation/spi/pxa2xx.rst b/Documentation/spi/pxa2xx.rst index 882d3cc72cc2..6312968acfe9 100644 --- a/Documentation/spi/pxa2xx.rst +++ b/Documentation/spi/pxa2xx.rst @@ -2,43 +2,47 @@ PXA2xx SPI on SSP driver HOWTO ============================== -This a mini howto on the pxa2xx_spi driver. The driver turns a PXA2xx -synchronous serial port into a SPI master controller +This a mini HOWTO on the pxa2xx_spi driver. The driver turns a PXA2xx +synchronous serial port into an SPI master controller (see Documentation/spi/spi-summary.rst). The driver has the following features -- Support for any PXA2xx SSP +- Support for any PXA2xx and compatible SSP. - SSP PIO and SSP DMA data transfers. - External and Internal (SSPFRM) chip selects. - Per slave device (chip) configuration. - Full suspend, freeze, resume support. -The driver is built around a "spi_message" fifo serviced by workqueue and a -tasklet. The workqueue, "pump_messages", drives message fifo and the tasklet -(pump_transfer) is responsible for queuing SPI transactions and setting up and -launching the dma/interrupt driven transfers. +The driver is built around a &struct spi_message FIFO serviced by kernel +thread. The kernel thread, spi_pump_messages(), drives message FIFO and +is responsible for queuing SPI transactions and setting up and launching +the DMA or interrupt driven transfers. Declaring PXA2xx Master Controllers ----------------------------------- -Typically a SPI master is defined in the arch/.../mach-*/board-*.c as a -"platform device". The master configuration is passed to the driver via a table -found in include/linux/spi/pxa2xx_spi.h:: +Typically, for a legacy platform, an SPI master is defined in the +arch/.../mach-*/board-*.c as a "platform device". The master configuration +is passed to the driver via a table found in include/linux/spi/pxa2xx_spi.h:: struct pxa2xx_spi_controller { u16 num_chipselect; u8 enable_dma; + ... }; The "pxa2xx_spi_controller.num_chipselect" field is used to determine the number of slave device (chips) attached to this SPI master. The "pxa2xx_spi_controller.enable_dma" field informs the driver that SSP DMA should -be used. This caused the driver to acquire two DMA channels: rx_channel and -tx_channel. The rx_channel has a higher DMA service priority the tx_channel. +be used. This caused the driver to acquire two DMA channels: Rx channel and +Tx channel. The Rx channel has a higher DMA service priority than the Tx channel. See the "PXA2xx Developer Manual" section "DMA Controller". +For the new platforms the description of the controller and peripheral devices +comes from Device Tree or ACPI. + NSSP MASTER SAMPLE ------------------ -Below is a sample configuration using the PXA255 NSSP:: +Below is a sample configuration using the PXA255 NSSP for a legacy platform:: static struct resource pxa_spi_nssp_resources[] = { [0] = { @@ -79,9 +83,10 @@ Below is a sample configuration using the PXA255 NSSP:: Declaring Slave Devices ----------------------- -Typically each SPI slave (chip) is defined in the arch/.../mach-*/board-*.c -using the "spi_board_info" structure found in "linux/spi/spi.h". See -"Documentation/spi/spi-summary.rst" for additional information. +Typically, for a legacy platform, each SPI slave (chip) is defined in the +arch/.../mach-*/board-*.c using the "spi_board_info" structure found in +"linux/spi/spi.h". See "Documentation/spi/spi-summary.rst" for additional +information. Each slave device attached to the PXA must provide slave specific configuration information via the structure "pxa2xx_spi_chip" found in @@ -101,9 +106,9 @@ device. All fields are optional. }; The "pxa2xx_spi_chip.tx_threshold" and "pxa2xx_spi_chip.rx_threshold" fields are -used to configure the SSP hardware fifo. These fields are critical to the +used to configure the SSP hardware FIFO. These fields are critical to the performance of pxa2xx_spi driver and misconfiguration will result in rx -fifo overruns (especially in PIO mode transfers). Good default values are:: +FIFO overruns (especially in PIO mode transfers). Good default values are:: .tx_threshold = 8, .rx_threshold = 8, @@ -118,7 +123,7 @@ use a value of 8. The driver will determine a reasonable default if dma_burst_size == 0. The "pxa2xx_spi_chip.timeout" fields is used to efficiently handle -trailing bytes in the SSP receiver fifo. The correct value for this field is +trailing bytes in the SSP receiver FIFO. The correct value for this field is dependent on the SPI bus speed ("spi_board_info.max_speed_hz") and the specific slave device. Please note that the PXA2xx SSP 1 does not support trailing byte timeouts and must busy-wait any trailing bytes. @@ -131,19 +136,19 @@ testing. The "pxa2xx_spi_chip.cs_control" field is used to point to a board specific function for asserting/deasserting a slave device chip select. If the field is NULL, the pxa2xx_spi master controller driver assumes that the SSP port is -configured to use SSPFRM instead. +configured to use GPIO or SSPFRM instead. NOTE: the SPI driver cannot control the chip select if SSPFRM is used, so the chipselect is dropped after each spi_transfer. Most devices need chip select -asserted around the complete message. Use SSPFRM as a GPIO (through cs_control) +asserted around the complete message. Use SSPFRM as a GPIO (through a descriptor) to accommodate these chips. NSSP SLAVE SAMPLE ----------------- -The pxa2xx_spi_chip structure is passed to the pxa2xx_spi driver in the -"spi_board_info.controller_data" field. Below is a sample configuration using -the PXA255 NSSP. +For a legacy platform or in some other cases, the pxa2xx_spi_chip structure +is passed to the pxa2xx_spi driver in the "spi_board_info.controller_data" +field. Below is a sample configuration using the PXA255 NSSP. :: @@ -212,7 +217,9 @@ DMA and PIO I/O Support ----------------------- The pxa2xx_spi driver supports both DMA and interrupt driven PIO message transfers. The driver defaults to PIO mode and DMA transfers must be enabled -by setting the "enable_dma" flag in the "pxa2xx_spi_controller" structure. The DMA +by setting the "enable_dma" flag in the "pxa2xx_spi_controller" structure. +For the newer platforms, that are known to support DMA, the driver will enable +it automatically and try it first with a possible fallback to PIO. The DMA mode supports both coherent and stream based DMA mappings. The following logic is used to determine the type of I/O to be used on @@ -236,5 +243,4 @@ a per "spi_transfer" basis:: THANKS TO --------- - David Brownell and others for mentoring the development of this driver. -- cgit v1.2.3 From 1897907cca5aa22cdfcdb7fb8f0644a6add0877d Mon Sep 17 00:00:00 2001 From: Fenghua Yu Date: Mon, 19 Apr 2021 21:49:55 +0000 Subject: Documentation/x86: Add buslock.rst Add buslock.rst to explain bus lock problem and how to detect and handle it. [ tglx: Included it into index.rst and added the missing include ... ] Signed-off-by: Fenghua Yu Signed-off-by: Thomas Gleixner Reviewed-by: Tony Luck Link: https://lore.kernel.org/r/20210419214958.4035512-2-fenghua.yu@intel.com --- Documentation/x86/buslock.rst | 104 ++++++++++++++++++++++++++++++++++++++++++ Documentation/x86/index.rst | 1 + 2 files changed, 105 insertions(+) create mode 100644 Documentation/x86/buslock.rst (limited to 'Documentation') diff --git a/Documentation/x86/buslock.rst b/Documentation/x86/buslock.rst new file mode 100644 index 000000000000..159ff6ba830e --- /dev/null +++ b/Documentation/x86/buslock.rst @@ -0,0 +1,104 @@ +.. SPDX-License-Identifier: GPL-2.0 + +.. include:: + +=============================== +Bus lock detection and handling +=============================== + +:Copyright: |copy| 2021 Intel Corporation +:Authors: - Fenghua Yu + - Tony Luck + +Problem +======= + +A split lock is any atomic operation whose operand crosses two cache lines. +Since the operand spans two cache lines and the operation must be atomic, +the system locks the bus while the CPU accesses the two cache lines. + +A bus lock is acquired through either split locked access to writeback (WB) +memory or any locked access to non-WB memory. This is typically thousands of +cycles slower than an atomic operation within a cache line. It also disrupts +performance on other cores and brings the whole system to its knees. + +Detection +========= + +Intel processors may support either or both of the following hardware +mechanisms to detect split locks and bus locks. + +#AC exception for split lock detection +-------------------------------------- + +Beginning with the Tremont Atom CPU split lock operations may raise an +Alignment Check (#AC) exception when a split lock operation is attemped. + +#DB exception for bus lock detection +------------------------------------ + +Some CPUs have the ability to notify the kernel by an #DB trap after a user +instruction acquires a bus lock and is executed. This allows the kernel to +terminate the application or to enforce throttling. + +Software handling +================= + +The kernel #AC and #DB handlers handle bus lock based on the kernel +parameter "split_lock_detect". Here is a summary of different options: + ++------------------+----------------------------+-----------------------+ +|split_lock_detect=|#AC for split lock |#DB for bus lock | ++------------------+----------------------------+-----------------------+ +|off |Do nothing |Do nothing | ++------------------+----------------------------+-----------------------+ +|warn |Kernel OOPs |Warn once per task and | +|(default) |Warn once per task and |and continues to run. | +| |disable future checking | | +| |When both features are | | +| |supported, warn in #AC | | ++------------------+----------------------------+-----------------------+ +|fatal |Kernel OOPs |Send SIGBUS to user. | +| |Send SIGBUS to user | | +| |When both features are | | +| |supported, fatal in #AC | | ++------------------+----------------------------+-----------------------+ + +Usages +====== + +Detecting and handling bus lock may find usages in various areas: + +It is critical for real time system designers who build consolidated real +time systems. These systems run hard real time code on some cores and run +"untrusted" user processes on other cores. The hard real time cannot afford +to have any bus lock from the untrusted processes to hurt real time +performance. To date the designers have been unable to deploy these +solutions as they have no way to prevent the "untrusted" user code from +generating split lock and bus lock to block the hard real time code to +access memory during bus locking. + +It's also useful for general computing to prevent guests or user +applications from slowing down the overall system by executing instructions +with bus lock. + + +Guidance +======== +off +--- + +Disable checking for split lock and bus lock. This option can be useful if +there are legacy applications that trigger these events at a low rate so +that mitigation is not needed. + +warn +---- + +A warning is emitted when a bus lock is detected which allows to identify +the offending application. This is the default behavior. + +fatal +----- + +In this case, the bus lock is not tolerated and the process is killed. diff --git a/Documentation/x86/index.rst b/Documentation/x86/index.rst index 4693e192b447..0004f5d2283e 100644 --- a/Documentation/x86/index.rst +++ b/Documentation/x86/index.rst @@ -29,6 +29,7 @@ x86-specific Documentation microcode resctrl tsx_async_abort + buslock usb-legacy-support i386/index x86_64/index -- cgit v1.2.3 From 9d839c280b64817345c2fa462c0027a9bd742361 Mon Sep 17 00:00:00 2001 From: Fenghua Yu Date: Mon, 19 Apr 2021 21:49:57 +0000 Subject: Documentation/admin-guide: Add bus lock ratelimit Since bus lock rate limit changes the split_lock_detect parameter, update the documentation for the change. Signed-off-by: Fenghua Yu Signed-off-by: Thomas Gleixner Reviewed-by: Tony Luck Link: https://lore.kernel.org/r/20210419214958.4035512-4-fenghua.yu@intel.com --- Documentation/admin-guide/kernel-parameters.txt | 8 ++++++++ 1 file changed, 8 insertions(+) (limited to 'Documentation') diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index cb89dbdedc46..ca94624438b9 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -5283,6 +5283,14 @@ exception. Default behavior is by #AC if both features are enabled in hardware. + ratelimit:N - + Set system wide rate limit to N bus locks + per second for bus lock detection. + 0 < N <= 1000. + + N/A for split lock detection. + + If an #AC exception is hit in the kernel or in firmware (i.e. not while executing in user mode) the kernel will oops in either "warn" or "fatal" -- cgit v1.2.3 From d28397eaf4c27947a1ffc720d42e8b3a33ae1e2a Mon Sep 17 00:00:00 2001 From: Fenghua Yu Date: Mon, 19 Apr 2021 21:49:58 +0000 Subject: Documentation/x86: Add ratelimit in buslock.rst ratelimit is a new command line option for bus lock handling. Add proper documentation. [ tglx: Massaged documentation ] Signed-off-by: Fenghua Yu Signed-off-by: Thomas Gleixner Reviewed-by: Tony Luck Link: https://lore.kernel.org/r/20210419214958.4035512-5-fenghua.yu@intel.com --- Documentation/x86/buslock.rst | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+) (limited to 'Documentation') diff --git a/Documentation/x86/buslock.rst b/Documentation/x86/buslock.rst index 159ff6ba830e..7c051e714943 100644 --- a/Documentation/x86/buslock.rst +++ b/Documentation/x86/buslock.rst @@ -63,6 +63,11 @@ parameter "split_lock_detect". Here is a summary of different options: | |When both features are | | | |supported, fatal in #AC | | +------------------+----------------------------+-----------------------+ +|ratelimit:N |Do nothing |Limit bus lock rate to | +|(0 < N <= 1000) | |N bus locks per second | +| | |system wide and warn on| +| | |bus locks. | ++------------------+----------------------------+-----------------------+ Usages ====== @@ -102,3 +107,20 @@ fatal ----- In this case, the bus lock is not tolerated and the process is killed. + +ratelimit +--------- + +A system wide bus lock rate limit N is specified where 0 < N <= 1000. This +allows a bus lock rate up to N bus locks per second. When the bus lock rate +is exceeded then any task which is caught via the buslock #DB exception is +throttled by enforced sleeps until the rate goes under the limit again. + +This is an effective mitigation in cases where a minimal impact can be +tolerated, but an eventual Denial of Service attack has to be prevented. It +allows to identify the offending processes and analyze whether they are +malicious or just badly written. + +Selecting a rate limit of 1000 allows the bus to be locked for up to about +seven million cycles each second (assuming 7000 cycles for each bus +lock). On a 2 GHz processor that would be about 0.35% system slowdown. -- cgit v1.2.3 From b67f7599c90ae36a5174826132f7690fa13d462c Mon Sep 17 00:00:00 2001 From: Dafna Hirschfeld Date: Tue, 18 May 2021 16:19:26 +0200 Subject: dt-bindings: display: add google, cros-ec-anx7688.yaml ChromeOS EC ANX7688 is a display bridge that converts HDMI 2.0 to DisplayPort 1.3 Ultra-HDi (4096x2160p60). It is an Analogix ANX7688 chip which is connected to and operated by the ChromeOS Embedded Controller (See google,cros-ec.yaml). It is accessed using I2C tunneling through the EC and therefore its node should be a child of an EC I2C tunnel node (See google,cros-ec-i2c-tunnel.yaml). ChromOS EC ANX7688 is found on Acer Chromebook R13 (elm) Signed-off-by: Dafna Hirschfeld Reviewed-by: Rob Herring Signed-off-by: Robert Foss Link: https://patchwork.freedesktop.org/patch/msgid/20210518141927.24795-2-dafna.hirschfeld@collabora.com --- .../display/bridge/google,cros-ec-anx7688.yaml | 82 ++++++++++++++++++++++ 1 file changed, 82 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/bridge/google,cros-ec-anx7688.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/bridge/google,cros-ec-anx7688.yaml b/Documentation/devicetree/bindings/display/bridge/google,cros-ec-anx7688.yaml new file mode 100644 index 000000000000..9f7cc6b757cb --- /dev/null +++ b/Documentation/devicetree/bindings/display/bridge/google,cros-ec-anx7688.yaml @@ -0,0 +1,82 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/bridge/google,cros-ec-anx7688.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: ChromeOS EC ANX7688 HDMI to DP Converter through Type-C Port + +maintainers: + - Nicolas Boichat + - Enric Balletbo i Serra + +description: | + ChromeOS EC ANX7688 is a display bridge that converts HDMI 2.0 to + DisplayPort 1.3 Ultra-HDi (4096x2160p60). It is an Analogix ANX7688 chip + which is connected to and operated by the ChromeOS Embedded Controller + (See google,cros-ec.yaml). It is accessed using I2C tunneling through + the EC and therefore its node should be a child of an EC I2C tunnel node + (See google,cros-ec-i2c-tunnel.yaml). + +properties: + compatible: + const: google,cros-ec-anx7688 + + reg: + maxItems: 1 + description: I2C address of the device. + + ports: + $ref: /schemas/graph.yaml#/properties/ports + + properties: + port@0: + $ref: /schemas/graph.yaml#/properties/port + description: Video port for HDMI input. + + port@1: + $ref: /schemas/graph.yaml#/properties/port + description: USB Type-c connector. + + required: + - port@0 + - port@1 + +required: + - compatible + - reg + - ports + +additionalProperties: false + +examples: + - | + i2c_tunnel_b: i2c-tunnel1 { + compatible = "google,cros-ec-i2c-tunnel"; + google,remote-bus = <1>; + #address-cells = <1>; + #size-cells = <0>; + + anx7688: anx7688@2c { + compatible = "google,cros-ec-anx7688"; + reg = <0x2c>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + port@0 { + reg = <0>; + anx7688_in: endpoint { + remote-endpoint = <&hdmi0_out>; + }; + }; + port@1 { + reg = <1>; + anx7688_out: endpoint { + remote-endpoint = <&typec_connector>; + }; + }; + }; + }; + }; + -- cgit v1.2.3 From 92ed3675574723a963152abbbe527b47f659340f Mon Sep 17 00:00:00 2001 From: Chukun Pan Date: Mon, 17 May 2021 00:35:23 +0800 Subject: dt-bindings: arm: Add NanoPi R1S H5 Add the bindings for NanoPi R1S H5 board. Signed-off-by: Chukun Pan Acked-by: Rob Herring Signed-off-by: Maxime Ripard Link: https://lore.kernel.org/r/20210516163523.9484-3-amadeus@jmu.edu.cn --- Documentation/devicetree/bindings/arm/sunxi.yaml | 5 +++++ 1 file changed, 5 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/sunxi.yaml b/Documentation/devicetree/bindings/arm/sunxi.yaml index ec8108483b49..889128acf49a 100644 --- a/Documentation/devicetree/bindings/arm/sunxi.yaml +++ b/Documentation/devicetree/bindings/arm/sunxi.yaml @@ -275,6 +275,11 @@ properties: - const: friendlyarm,nanopi-r1 - const: allwinner,sun8i-h3 + - description: FriendlyARM NanoPi R1S H5 + items: + - const: friendlyarm,nanopi-r1s-h5 + - const: allwinner,sun50i-h5 + - description: FriendlyARM ZeroPi items: - const: friendlyarm,zeropi -- cgit v1.2.3 From cd8d60399ac5634513199b76c7dbd43092e29b1b Mon Sep 17 00:00:00 2001 From: Tobias Schramm Date: Thu, 13 May 2021 22:35:26 +0200 Subject: dt-bindings: pwm: allwinner: add v3s pwm compatible The Allwinner V3s pwm peripheral is compatible with the pwm peripheral inside the Allwinner A20. This patch adds a compatible string for it. Signed-off-by: Tobias Schramm Reviewed-by: Andre Przywara Acked-by: Rob Herring Signed-off-by: Maxime Ripard Link: https://lore.kernel.org/r/20210513203527.2072090-2-t.schramm@manjaro.org --- Documentation/devicetree/bindings/pwm/allwinner,sun4i-a10-pwm.yaml | 3 +++ 1 file changed, 3 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pwm/allwinner,sun4i-a10-pwm.yaml b/Documentation/devicetree/bindings/pwm/allwinner,sun4i-a10-pwm.yaml index 7dcab2bf8128..04ff708fdc86 100644 --- a/Documentation/devicetree/bindings/pwm/allwinner,sun4i-a10-pwm.yaml +++ b/Documentation/devicetree/bindings/pwm/allwinner,sun4i-a10-pwm.yaml @@ -24,6 +24,9 @@ properties: - items: - const: allwinner,sun8i-a83t-pwm - const: allwinner,sun8i-h3-pwm + - items: + - const: allwinner,sun8i-v3s-pwm + - const: allwinner,sun7i-a20-pwm - items: - const: allwinner,sun50i-a64-pwm - const: allwinner,sun5i-a13-pwm -- cgit v1.2.3 From 78e8db071b684f4b3975653fd31ffabc8c204501 Mon Sep 17 00:00:00 2001 From: Tobias Schramm Date: Fri, 14 May 2021 15:44:02 +0200 Subject: ASoC: dt-bindings: sun8i-a23-codec-analog: add compatible for Allwinner V3 The analog codec frontend of the Allwinner V3 is compatible with the analog codec frontend used on the Allwinner H3. This patch adds a compatible string for the analog codec frontend on the Allwinner V3 SoC. Signed-off-by: Tobias Schramm Reviewed-by: Rob Herring Signed-off-by: Maxime Ripard Link: https://lore.kernel.org/r/20210514134405.2097464-5-t.schramm@manjaro.org --- .../bindings/sound/allwinner,sun8i-a23-codec-analog.yaml | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/allwinner,sun8i-a23-codec-analog.yaml b/Documentation/devicetree/bindings/sound/allwinner,sun8i-a23-codec-analog.yaml index 9718358826ab..26eca21e1f0f 100644 --- a/Documentation/devicetree/bindings/sound/allwinner,sun8i-a23-codec-analog.yaml +++ b/Documentation/devicetree/bindings/sound/allwinner,sun8i-a23-codec-analog.yaml @@ -12,12 +12,15 @@ maintainers: properties: compatible: - enum: + oneOf: # FIXME: This is documented in the PRCM binding, but needs to be # migrated here at some point # - allwinner,sun8i-a23-codec-analog - - allwinner,sun8i-h3-codec-analog - - allwinner,sun8i-v3s-codec-analog + - const: allwinner,sun8i-h3-codec-analog + - items: + - const: allwinner,sun8i-v3-codec-analog + - const: allwinner,sun8i-h3-codec-analog + - const: allwinner,sun8i-v3s-codec-analog reg: maxItems: 1 -- cgit v1.2.3 From ce09d1a6800df7ce0f73ae4d4b3ad4975cb31498 Mon Sep 17 00:00:00 2001 From: Tobias Schramm Date: Fri, 14 May 2021 15:44:04 +0200 Subject: dt-bindings: sound: sun4i-i2s: add Allwinner V3 I2S compatible The I2S peripheral of the Allwinner V3 SoC is compatible with the one found in the Allwinner H3 SoC. This patch adds a compatible string for it. Signed-off-by: Tobias Schramm Reviewed-by: Rob Herring Signed-off-by: Maxime Ripard Link: https://lore.kernel.org/r/20210514134405.2097464-7-t.schramm@manjaro.org --- Documentation/devicetree/bindings/sound/allwinner,sun4i-a10-i2s.yaml | 3 +++ 1 file changed, 3 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/allwinner,sun4i-a10-i2s.yaml b/Documentation/devicetree/bindings/sound/allwinner,sun4i-a10-i2s.yaml index a16e37b01e1d..39b66e9ce3e3 100644 --- a/Documentation/devicetree/bindings/sound/allwinner,sun4i-a10-i2s.yaml +++ b/Documentation/devicetree/bindings/sound/allwinner,sun4i-a10-i2s.yaml @@ -20,6 +20,9 @@ properties: - const: allwinner,sun6i-a31-i2s - const: allwinner,sun8i-a83t-i2s - const: allwinner,sun8i-h3-i2s + - items: + - const: allwinner,sun8i-v3-i2s + - const: allwinner,sun8i-h3-i2s - const: allwinner,sun50i-a64-codec-i2s - items: - const: allwinner,sun50i-a64-i2s -- cgit v1.2.3 From ea0484644e5b8486c8335f677fc1e2a4a5d76d3f Mon Sep 17 00:00:00 2001 From: "Paul E. McKenney" Date: Thu, 4 Mar 2021 16:04:09 -0800 Subject: kcsan: Add pointer to access-marking.txt to data_race() bullet This commit references tools/memory-model/Documentation/access-marking.txt in the bullet introducing data_race(). The access-marking.txt file gives advice on when data_race() should and should not be used. Suggested-by: Akira Yokosawa Signed-off-by: Paul E. McKenney --- Documentation/dev-tools/kcsan.rst | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/dev-tools/kcsan.rst b/Documentation/dev-tools/kcsan.rst index d85ce238ace7..80894664a44c 100644 --- a/Documentation/dev-tools/kcsan.rst +++ b/Documentation/dev-tools/kcsan.rst @@ -106,7 +106,9 @@ the below options are available: * KCSAN understands the ``data_race(expr)`` annotation, which tells KCSAN that any data races due to accesses in ``expr`` should be ignored and resulting - behaviour when encountering a data race is deemed safe. + behaviour when encountering a data race is deemed safe. Please see + ``tools/memory-model/Documentation/access-marking.txt`` in the kernel source + tree for more information. * Disabling data race detection for entire functions can be accomplished by using the function attribute ``__no_kcsan``:: -- cgit v1.2.3 From b930226f3db870cfb683c2744aeb0d29deb4cddc Mon Sep 17 00:00:00 2001 From: Marco Elver Date: Wed, 14 Apr 2021 13:28:25 +0200 Subject: kcsan: Document "value changed" line Update the example reports based on the latest reports generated by kcsan_test module, which now include the "value changed" line. Add a brief description of the "value changed" line. Signed-off-by: Marco Elver Signed-off-by: Paul E. McKenney --- Documentation/dev-tools/kcsan.rst | 88 ++++++++++++++++----------------------- 1 file changed, 35 insertions(+), 53 deletions(-) (limited to 'Documentation') diff --git a/Documentation/dev-tools/kcsan.rst b/Documentation/dev-tools/kcsan.rst index 80894664a44c..d1efd9cef6a2 100644 --- a/Documentation/dev-tools/kcsan.rst +++ b/Documentation/dev-tools/kcsan.rst @@ -27,75 +27,57 @@ Error reports A typical data race report looks like this:: ================================================================== - BUG: KCSAN: data-race in generic_permission / kernfs_refresh_inode - - write to 0xffff8fee4c40700c of 4 bytes by task 175 on cpu 4: - kernfs_refresh_inode+0x70/0x170 - kernfs_iop_permission+0x4f/0x90 - inode_permission+0x190/0x200 - link_path_walk.part.0+0x503/0x8e0 - path_lookupat.isra.0+0x69/0x4d0 - filename_lookup+0x136/0x280 - user_path_at_empty+0x47/0x60 - vfs_statx+0x9b/0x130 - __do_sys_newlstat+0x50/0xb0 - __x64_sys_newlstat+0x37/0x50 - do_syscall_64+0x85/0x260 - entry_SYSCALL_64_after_hwframe+0x44/0xa9 - - read to 0xffff8fee4c40700c of 4 bytes by task 166 on cpu 6: - generic_permission+0x5b/0x2a0 - kernfs_iop_permission+0x66/0x90 - inode_permission+0x190/0x200 - link_path_walk.part.0+0x503/0x8e0 - path_lookupat.isra.0+0x69/0x4d0 - filename_lookup+0x136/0x280 - user_path_at_empty+0x47/0x60 - do_faccessat+0x11a/0x390 - __x64_sys_access+0x3c/0x50 - do_syscall_64+0x85/0x260 - entry_SYSCALL_64_after_hwframe+0x44/0xa9 + BUG: KCSAN: data-race in test_kernel_read / test_kernel_write + + write to 0xffffffffc009a628 of 8 bytes by task 487 on cpu 0: + test_kernel_write+0x1d/0x30 + access_thread+0x89/0xd0 + kthread+0x23e/0x260 + ret_from_fork+0x22/0x30 + + read to 0xffffffffc009a628 of 8 bytes by task 488 on cpu 6: + test_kernel_read+0x10/0x20 + access_thread+0x89/0xd0 + kthread+0x23e/0x260 + ret_from_fork+0x22/0x30 + + value changed: 0x00000000000009a6 -> 0x00000000000009b2 Reported by Kernel Concurrency Sanitizer on: - CPU: 6 PID: 166 Comm: systemd-journal Not tainted 5.3.0-rc7+ #1 - Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 + CPU: 6 PID: 488 Comm: access_thread Not tainted 5.12.0-rc2+ #1 + Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014 ================================================================== The header of the report provides a short summary of the functions involved in the race. It is followed by the access types and stack traces of the 2 threads -involved in the data race. +involved in the data race. If KCSAN also observed a value change, the observed +old value and new value are shown on the "value changed" line respectively. The other less common type of data race report looks like this:: ================================================================== - BUG: KCSAN: data-race in e1000_clean_rx_irq+0x551/0xb10 - - race at unknown origin, with read to 0xffff933db8a2ae6c of 1 bytes by interrupt on cpu 0: - e1000_clean_rx_irq+0x551/0xb10 - e1000_clean+0x533/0xda0 - net_rx_action+0x329/0x900 - __do_softirq+0xdb/0x2db - irq_exit+0x9b/0xa0 - do_IRQ+0x9c/0xf0 - ret_from_intr+0x0/0x18 - default_idle+0x3f/0x220 - arch_cpu_idle+0x21/0x30 - do_idle+0x1df/0x230 - cpu_startup_entry+0x14/0x20 - rest_init+0xc5/0xcb - arch_call_rest_init+0x13/0x2b - start_kernel+0x6db/0x700 + BUG: KCSAN: data-race in test_kernel_rmw_array+0x71/0xd0 + + race at unknown origin, with read to 0xffffffffc009bdb0 of 8 bytes by task 515 on cpu 2: + test_kernel_rmw_array+0x71/0xd0 + access_thread+0x89/0xd0 + kthread+0x23e/0x260 + ret_from_fork+0x22/0x30 + + value changed: 0x0000000000002328 -> 0x0000000000002329 Reported by Kernel Concurrency Sanitizer on: - CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.3.0-rc7+ #2 - Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 + CPU: 2 PID: 515 Comm: access_thread Not tainted 5.12.0-rc2+ #1 + Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014 ================================================================== This report is generated where it was not possible to determine the other racing thread, but a race was inferred due to the data value of the watched -memory location having changed. These can occur either due to missing -instrumentation or e.g. DMA accesses. These reports will only be generated if -``CONFIG_KCSAN_REPORT_RACE_UNKNOWN_ORIGIN=y`` (selected by default). +memory location having changed. These reports always show a "value changed" +line. A common reason for reports of this type are missing instrumentation in +the racing thread, but could also occur due to e.g. DMA accesses. Such reports +are shown only if ``CONFIG_KCSAN_REPORT_RACE_UNKNOWN_ORIGIN=y``, which is +enabled by default. Selective analysis ~~~~~~~~~~~~~~~~~~ -- cgit v1.2.3 From 117232c0b9126e254d84f38ccaf9e576ccfcd990 Mon Sep 17 00:00:00 2001 From: Akira Yokosawa Date: Thu, 13 May 2021 10:49:41 -0700 Subject: kcsan: Use URL link for pointing access-marking.txt For consistency within kcsan.rst, use a URL link as the same as in section "Data Races". Acked-by: Marco Elver Signed-off-by: Akira Yokosawa Signed-off-by: Paul E. McKenney --- Documentation/dev-tools/kcsan.rst | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/dev-tools/kcsan.rst b/Documentation/dev-tools/kcsan.rst index d1efd9cef6a2..6a600cf8430b 100644 --- a/Documentation/dev-tools/kcsan.rst +++ b/Documentation/dev-tools/kcsan.rst @@ -89,8 +89,7 @@ the below options are available: * KCSAN understands the ``data_race(expr)`` annotation, which tells KCSAN that any data races due to accesses in ``expr`` should be ignored and resulting behaviour when encountering a data race is deemed safe. Please see - ``tools/memory-model/Documentation/access-marking.txt`` in the kernel source - tree for more information. + `"Marking Shared-Memory Accesses" in the LKMM`_ for more information. * Disabling data race detection for entire functions can be accomplished by using the function attribute ``__no_kcsan``:: @@ -112,6 +111,8 @@ the below options are available: KCSAN_SANITIZE := n +.. _"Marking Shared-Memory Accesses" in the LKMM: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/memory-model/Documentation/access-marking.txt + Furthermore, it is possible to tell KCSAN to show or hide entire classes of data races, depending on preferences. These can be changed via the following Kconfig options: -- cgit v1.2.3 From ce5c9c20d364f156c885efed8c71fca2945db00f Mon Sep 17 00:00:00 2001 From: Ido Schimmel Date: Mon, 17 May 2021 21:15:18 +0300 Subject: ipv4: Add a sysctl to control multipath hash fields A subsequent patch will add a new multipath hash policy where the packet fields used for multipath hash calculation are determined by user space. This patch adds a sysctl that allows user space to set these fields. The packet fields are represented using a bitmask and are common between IPv4 and IPv6 to allow user space to use the same numbering across both protocols. For example, to hash based on standard 5-tuple: # sysctl -w net.ipv4.fib_multipath_hash_fields=0x0037 net.ipv4.fib_multipath_hash_fields = 0x0037 The kernel rejects unknown fields, for example: # sysctl -w net.ipv4.fib_multipath_hash_fields=0x1000 sysctl: setting key "net.ipv4.fib_multipath_hash_fields": Invalid argument More fields can be added in the future, if needed. Signed-off-by: Ido Schimmel Reviewed-by: David Ahern Signed-off-by: David S. Miller --- Documentation/networking/ip-sysctl.rst | 27 +++++++++++++++++++++++++++ 1 file changed, 27 insertions(+) (limited to 'Documentation') diff --git a/Documentation/networking/ip-sysctl.rst b/Documentation/networking/ip-sysctl.rst index c2ecc9894fd0..47494798d03b 100644 --- a/Documentation/networking/ip-sysctl.rst +++ b/Documentation/networking/ip-sysctl.rst @@ -100,6 +100,33 @@ fib_multipath_hash_policy - INTEGER - 1 - Layer 4 - 2 - Layer 3 or inner Layer 3 if present +fib_multipath_hash_fields - UNSIGNED INTEGER + When fib_multipath_hash_policy is set to 3 (custom multipath hash), the + fields used for multipath hash calculation are determined by this + sysctl. + + This value is a bitmask which enables various fields for multipath hash + calculation. + + Possible fields are: + + ====== ============================ + 0x0001 Source IP address + 0x0002 Destination IP address + 0x0004 IP protocol + 0x0008 Unused (Flow Label) + 0x0010 Source port + 0x0020 Destination port + 0x0040 Inner source IP address + 0x0080 Inner destination IP address + 0x0100 Inner IP protocol + 0x0200 Inner Flow Label + 0x0400 Inner source port + 0x0800 Inner destination port + ====== ============================ + + Default: 0x0007 (source IP, destination IP and IP protocol) + fib_sync_mem - UNSIGNED INTEGER Amount of dirty memory from fib entries that can be backlogged before synchronize_rcu is forced. -- cgit v1.2.3 From 4253b4986f98da4bfcb6a24d3fc6ff19f28e8420 Mon Sep 17 00:00:00 2001 From: Ido Schimmel Date: Mon, 17 May 2021 21:15:19 +0300 Subject: ipv4: Add custom multipath hash policy Add a new multipath hash policy where the packet fields used for hash calculation are determined by user space via the fib_multipath_hash_fields sysctl that was introduced in the previous patch. The current set of available packet fields includes both outer and inner fields, which requires two invocations of the flow dissector. Avoid unnecessary dissection of the outer or inner flows by skipping dissection if none of the outer or inner fields are required. In accordance with the existing policies, when an skb is not available, packet fields are extracted from the provided flow key. In which case, only outer fields are considered. Signed-off-by: Ido Schimmel Reviewed-by: David Ahern Signed-off-by: David S. Miller --- Documentation/networking/ip-sysctl.rst | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/networking/ip-sysctl.rst b/Documentation/networking/ip-sysctl.rst index 47494798d03b..afdcdc0691d6 100644 --- a/Documentation/networking/ip-sysctl.rst +++ b/Documentation/networking/ip-sysctl.rst @@ -99,6 +99,8 @@ fib_multipath_hash_policy - INTEGER - 0 - Layer 3 - 1 - Layer 4 - 2 - Layer 3 or inner Layer 3 if present + - 3 - Custom multipath hash. Fields used for multipath hash calculation + are determined by fib_multipath_hash_fields sysctl fib_multipath_hash_fields - UNSIGNED INTEGER When fib_multipath_hash_policy is set to 3 (custom multipath hash), the -- cgit v1.2.3 From ed13923f980ef84dde0b9010b9e09052dc31a909 Mon Sep 17 00:00:00 2001 From: Ido Schimmel Date: Mon, 17 May 2021 21:15:22 +0300 Subject: ipv6: Add a sysctl to control multipath hash fields A subsequent patch will add a new multipath hash policy where the packet fields used for multipath hash calculation are determined by user space. This patch adds a sysctl that allows user space to set these fields. The packet fields are represented using a bitmask and are common between IPv4 and IPv6 to allow user space to use the same numbering across both protocols. For example, to hash based on standard 5-tuple: # sysctl -w net.ipv6.fib_multipath_hash_fields=0x0037 net.ipv6.fib_multipath_hash_fields = 0x0037 To avoid introducing holes in 'struct netns_sysctl_ipv6', move the 'bindv6only' field after the multipath hash fields. The kernel rejects unknown fields, for example: # sysctl -w net.ipv6.fib_multipath_hash_fields=0x1000 sysctl: setting key "net.ipv6.fib_multipath_hash_fields": Invalid argument Signed-off-by: Ido Schimmel Reviewed-by: David Ahern Signed-off-by: David S. Miller --- Documentation/networking/ip-sysctl.rst | 27 +++++++++++++++++++++++++++ 1 file changed, 27 insertions(+) (limited to 'Documentation') diff --git a/Documentation/networking/ip-sysctl.rst b/Documentation/networking/ip-sysctl.rst index afdcdc0691d6..4246cc4ae35b 100644 --- a/Documentation/networking/ip-sysctl.rst +++ b/Documentation/networking/ip-sysctl.rst @@ -1773,6 +1773,33 @@ fib_multipath_hash_policy - INTEGER - 1 - Layer 4 (standard 5-tuple) - 2 - Layer 3 or inner Layer 3 if present +fib_multipath_hash_fields - UNSIGNED INTEGER + When fib_multipath_hash_policy is set to 3 (custom multipath hash), the + fields used for multipath hash calculation are determined by this + sysctl. + + This value is a bitmask which enables various fields for multipath hash + calculation. + + Possible fields are: + + ====== ============================ + 0x0001 Source IP address + 0x0002 Destination IP address + 0x0004 IP protocol + 0x0008 Flow Label + 0x0010 Source port + 0x0020 Destination port + 0x0040 Inner source IP address + 0x0080 Inner destination IP address + 0x0100 Inner IP protocol + 0x0200 Inner Flow Label + 0x0400 Inner source port + 0x0800 Inner destination port + ====== ============================ + + Default: 0x0007 (source IP, destination IP and IP protocol) + anycast_src_echo_reply - BOOLEAN Controls the use of anycast addresses as source addresses for ICMPv6 echo reply -- cgit v1.2.3 From 73c2c5cbb15a8a82d5bea52594b0beb038963bcc Mon Sep 17 00:00:00 2001 From: Ido Schimmel Date: Mon, 17 May 2021 21:15:23 +0300 Subject: ipv6: Add custom multipath hash policy Add a new multipath hash policy where the packet fields used for hash calculation are determined by user space via the fib_multipath_hash_fields sysctl that was introduced in the previous patch. The current set of available packet fields includes both outer and inner fields, which requires two invocations of the flow dissector. Avoid unnecessary dissection of the outer or inner flows by skipping dissection if none of the outer or inner fields are required. In accordance with the existing policies, when an skb is not available, packet fields are extracted from the provided flow key. In which case, only outer fields are considered. Signed-off-by: Ido Schimmel Reviewed-by: David Ahern Signed-off-by: David S. Miller --- Documentation/networking/ip-sysctl.rst | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/networking/ip-sysctl.rst b/Documentation/networking/ip-sysctl.rst index 4246cc4ae35b..a5c250044500 100644 --- a/Documentation/networking/ip-sysctl.rst +++ b/Documentation/networking/ip-sysctl.rst @@ -1772,6 +1772,8 @@ fib_multipath_hash_policy - INTEGER - 0 - Layer 3 (source and destination addresses plus flow label) - 1 - Layer 4 (standard 5-tuple) - 2 - Layer 3 or inner Layer 3 if present + - 3 - Custom multipath hash. Fields used for multipath hash calculation + are determined by fib_multipath_hash_fields sysctl fib_multipath_hash_fields - UNSIGNED INTEGER When fib_multipath_hash_policy is set to 3 (custom multipath hash), the -- cgit v1.2.3 From ac5f8197d15cf37d7ae37ff5b6438abe6c8509a6 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Rafa=C5=82=20Mi=C5=82ecki?= Date: Wed, 21 Apr 2021 20:20:41 +0200 Subject: dt-bindings: pinctrl: convert Broadcom Northstar to the json-schema MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Important: this change converts the binding as it is. It includes dependency on undocumented CRU that must be refactored. CRU must get documented and offset property has to be reworked. Above can (and will be) be handled once every CRU MFD subdevice gets documented properly (including the pinmux). Signed-off-by: Rafał Miłecki Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20210421182041.22636-1-zajec5@gmail.com Signed-off-by: Linus Walleij --- .../bindings/pinctrl/brcm,bcm4708-pinmux.txt | 55 ------------- .../bindings/pinctrl/brcm,ns-pinmux.yaml | 94 ++++++++++++++++++++++ 2 files changed, 94 insertions(+), 55 deletions(-) delete mode 100644 Documentation/devicetree/bindings/pinctrl/brcm,bcm4708-pinmux.txt create mode 100644 Documentation/devicetree/bindings/pinctrl/brcm,ns-pinmux.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pinctrl/brcm,bcm4708-pinmux.txt b/Documentation/devicetree/bindings/pinctrl/brcm,bcm4708-pinmux.txt deleted file mode 100644 index 8ab2d468dbdb..000000000000 --- a/Documentation/devicetree/bindings/pinctrl/brcm,bcm4708-pinmux.txt +++ /dev/null @@ -1,55 +0,0 @@ -Broadcom Northstar pins mux controller - -Some of Northstar SoCs's pins can be used for various purposes thanks to the mux -controller. This binding allows describing mux controller and listing available -functions. They can be referenced later by other bindings to let system -configure controller correctly. - -A list of pins varies across chipsets so few bindings are available. - -Node of the pinmux must be nested in the CRU (Central Resource Unit) "syscon" -noce. - -Required properties: -- compatible: must be one of: - "brcm,bcm4708-pinmux" - "brcm,bcm4709-pinmux" - "brcm,bcm53012-pinmux" -- offset: offset of pin registers in the CRU block - -Functions and their groups available for all chipsets: -- "spi": "spi_grp" -- "i2c": "i2c_grp" -- "pwm": "pwm0_grp", "pwm1_grp", "pwm2_grp", "pwm3_grp" -- "uart1": "uart1_grp" - -Additionally available on BCM4709 and BCM53012: -- "mdio": "mdio_grp" -- "uart2": "uart2_grp" -- "sdio": "sdio_pwr_grp", "sdio_1p8v_grp" - -For documentation of subnodes see: -Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt - -Example: - dmu@1800c000 { - compatible = "simple-bus"; - ranges = <0 0x1800c000 0x1000>; - #address-cells = <1>; - #size-cells = <1>; - - cru@100 { - compatible = "syscon", "simple-mfd"; - reg = <0x100 0x1a4>; - - pinctrl { - compatible = "brcm,bcm4708-pinmux"; - offset = <0xc0>; - - spi-pins { - function = "spi"; - groups = "spi_grp"; - }; - }; - }; - }; diff --git a/Documentation/devicetree/bindings/pinctrl/brcm,ns-pinmux.yaml b/Documentation/devicetree/bindings/pinctrl/brcm,ns-pinmux.yaml new file mode 100644 index 000000000000..470aff599c27 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/brcm,ns-pinmux.yaml @@ -0,0 +1,94 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pinctrl/brcm,ns-pinmux.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Broadcom Northstar pins mux controller + +maintainers: + - Rafał Miłecki + +description: + Some of Northstar SoCs's pins can be used for various purposes thanks to the + mux controller. This binding allows describing mux controller and listing + available functions. They can be referenced later by other bindings to let + system configure controller correctly. + + A list of pins varies across chipsets so few bindings are available. + + Node of the pinmux must be nested in the CRU (Central Resource Unit) "syscon" + node. + +properties: + compatible: + enum: + - brcm,bcm4708-pinmux + - brcm,bcm4709-pinmux + - brcm,bcm53012-pinmux + + offset: + description: offset of pin registers in the CRU block + maxItems: 1 + $ref: /schemas/types.yaml#/definitions/uint32-array + +patternProperties: + '-pins$': + type: object + description: pin node + $ref: pinmux-node.yaml# + + properties: + function: + enum: [ spi, i2c, pwm, uart1, mdio, uart2, sdio ] + groups: + minItems: 1 + maxItems: 4 + items: + enum: [ spi_grp, i2c_grp, pwm0_grp, pwm1_grp, pwm2_grp, pwm3_grp, + uart1_grp, mdio_grp, uart2_grp, sdio_pwr_grp, sdio_1p8v_grp ] + + required: + - function + - groups + + additionalProperties: false + +allOf: + - if: + properties: + compatible: + contains: + const: brcm,bcm4708-pinmux + then: + patternProperties: + '-pins$': + properties: + function: + enum: [ spi, i2c, pwm, uart1 ] + groups: + items: + enum: [ spi_grp, i2c_grp, pwm0_grp, pwm1_grp, pwm2_grp, pwm3_grp, + uart1_grp ] + +required: + - offset + +additionalProperties: false + +examples: + - | + cru@1800c100 { + compatible = "syscon", "simple-mfd"; + reg = <0x1800c100 0x1a4>; + + pinctrl { + compatible = "brcm,bcm4708-pinmux"; + offset = <0xc0>; + + spi-pins { + function = "spi"; + groups = "spi_grp"; + }; + }; + }; -- cgit v1.2.3 From 969ef42b1ae094da99b8acbf14864f94d37f6e58 Mon Sep 17 00:00:00 2001 From: Bjorn Andersson Date: Wed, 28 Apr 2021 17:37:51 -0700 Subject: pinctrl: qcom: spmi-mpp: Add compatible for pmi8994 The PMI8994 has 4 multi-purpose-pins, add a compatible for this hardware block to the MPP driver. Signed-off-by: Bjorn Andersson Acked-by: Rob Herring Link: https://lore.kernel.org/r/20210429003751.224232-1-bjorn.andersson@linaro.org Signed-off-by: Linus Walleij --- Documentation/devicetree/bindings/pinctrl/qcom,pmic-mpp.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,pmic-mpp.txt b/Documentation/devicetree/bindings/pinctrl/qcom,pmic-mpp.txt index 0ba07bc96c55..5363d44cbb74 100644 --- a/Documentation/devicetree/bindings/pinctrl/qcom,pmic-mpp.txt +++ b/Documentation/devicetree/bindings/pinctrl/qcom,pmic-mpp.txt @@ -21,6 +21,7 @@ of PMIC's from Qualcomm. "qcom,pmi8950-mpp", "qcom,pm8994-mpp", "qcom,pma8084-mpp", + "qcom,pmi8994-mpp", And must contain either "qcom,spmi-mpp" or "qcom,ssbi-mpp" if the device is on an spmi bus or an ssbi bus respectively. -- cgit v1.2.3 From 67a7e53d5b21f3a84efc03a4e62db7caf97841ef Mon Sep 17 00:00:00 2001 From: Jernej Skrabec Date: Tue, 27 Apr 2021 09:15:54 +0200 Subject: media: hevc: Fix dependent slice segment flags Dependent slice segment flag for PPS control is misnamed. It should have "enabled" at the end. It only tells if this flag is present in slice header or not and not the actual value. Fix this by renaming the PPS flag and introduce another flag for slice control which tells actual value. Signed-off-by: Jernej Skrabec Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab --- Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst index b0de4e6e7ebd..514b334470ea 100644 --- a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst +++ b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst @@ -3053,7 +3053,7 @@ enum v4l2_mpeg_video_hevc_size_of_length_field - :stub-columns: 0 :widths: 1 1 2 - * - ``V4L2_HEVC_PPS_FLAG_DEPENDENT_SLICE_SEGMENT`` + * - ``V4L2_HEVC_PPS_FLAG_DEPENDENT_SLICE_SEGMENT_ENABLED`` - 0x00000001 - * - ``V4L2_HEVC_PPS_FLAG_OUTPUT_FLAG_PRESENT`` @@ -3277,6 +3277,9 @@ enum v4l2_mpeg_video_hevc_size_of_length_field - * - ``V4L2_HEVC_SLICE_PARAMS_FLAG_SLICE_LOOP_FILTER_ACROSS_SLICES_ENABLED`` - 0x00000100 - + * - ``V4L2_HEVC_SLICE_PARAMS_FLAG_DEPENDENT_SLICE_SEGMENT`` + - 0x00000200 + - .. raw:: latex -- cgit v1.2.3 From 0d705395afa4b4fa7d0fae86b9c04cfe50a03ace Mon Sep 17 00:00:00 2001 From: Emil Velikov Date: Thu, 1 Apr 2021 16:43:34 +0200 Subject: media: dt-bindings: Document SAMA5D4 VDEC bindings Add devicetree binding documentation for the Hantro G1/G2 VDEC on the Microchip SAMAS5D4 SoC. Acked-by: Nicolas Ferre Signed-off-by: Emil Velikov Reviewed-by: Rob Herring Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab --- .../bindings/media/microchip,sama5d4-vdec.yaml | 47 ++++++++++++++++++++++ 1 file changed, 47 insertions(+) create mode 100644 Documentation/devicetree/bindings/media/microchip,sama5d4-vdec.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/media/microchip,sama5d4-vdec.yaml b/Documentation/devicetree/bindings/media/microchip,sama5d4-vdec.yaml new file mode 100644 index 000000000000..4b77103ca913 --- /dev/null +++ b/Documentation/devicetree/bindings/media/microchip,sama5d4-vdec.yaml @@ -0,0 +1,47 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) + +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/media/microchip,sama5d4-vdec.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: Hantro G1 VPU codec implemented on Microchip SAMA5D4 SoCs + +maintainers: + - Emil Velikov + +description: + Hantro G1 video decode accelerator present on Microchip SAMA5D4 SoCs. + +properties: + compatible: + const: microchip,sama5d4-vdec + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + +required: + - compatible + - reg + - interrupts + - clocks + +additionalProperties: false + +examples: + - | + #include + #include + + vdec0: vdec@300000 { + compatible = "microchip,sama5d4-vdec"; + reg = <0x00300000 0x100000>; + interrupts = <19 IRQ_TYPE_LEVEL_HIGH 4>; + clocks = <&pmc PMC_TYPE_PERIPHERAL 19>; + }; -- cgit v1.2.3 From 1c33bb0507508af24fd754dd7123bd8e997fab2f Mon Sep 17 00:00:00 2001 From: "Chang S. Bae" Date: Tue, 18 May 2021 13:03:17 -0700 Subject: x86/elf: Support a new ELF aux vector AT_MINSIGSTKSZ Historically, signal.h defines MINSIGSTKSZ (2KB) and SIGSTKSZ (8KB), for use by all architectures with sigaltstack(2). Over time, the hardware state size grew, but these constants did not evolve. Today, literal use of these constants on several architectures may result in signal stack overflow, and thus user data corruption. A few years ago, the ARM team addressed this issue by establishing getauxval(AT_MINSIGSTKSZ). This enables the kernel to supply a value at runtime that is an appropriate replacement on current and future hardware. Add getauxval(AT_MINSIGSTKSZ) support to x86, analogous to the support added for ARM in 94b07c1f8c39 ("arm64: signal: Report signal frame size to userspace via auxv"). Also, include a documentation to describe x86-specific auxiliary vectors. Signed-off-by: Chang S. Bae Signed-off-by: Borislav Petkov Reviewed-by: Len Brown Acked-by: Thomas Gleixner Link: https://lkml.kernel.org/r/20210518200320.17239-4-chang.seok.bae@intel.com --- Documentation/x86/elf_auxvec.rst | 53 ++++++++++++++++++++++++++++++++++++++++ Documentation/x86/index.rst | 1 + 2 files changed, 54 insertions(+) create mode 100644 Documentation/x86/elf_auxvec.rst (limited to 'Documentation') diff --git a/Documentation/x86/elf_auxvec.rst b/Documentation/x86/elf_auxvec.rst new file mode 100644 index 000000000000..18e4744717f9 --- /dev/null +++ b/Documentation/x86/elf_auxvec.rst @@ -0,0 +1,53 @@ +.. SPDX-License-Identifier: GPL-2.0 + +================================== +x86-specific ELF Auxiliary Vectors +================================== + +This document describes the semantics of the x86 auxiliary vectors. + +Introduction +============ + +ELF Auxiliary vectors enable the kernel to efficiently provide +configuration-specific parameters to userspace. In this example, a program +allocates an alternate stack based on the kernel-provided size:: + + #include + #include + #include + #include + #include + #include + + #ifndef AT_MINSIGSTKSZ + #define AT_MINSIGSTKSZ 51 + #endif + + .... + stack_t ss; + + ss.ss_sp = malloc(ss.ss_size); + assert(ss.ss_sp); + + ss.ss_size = getauxval(AT_MINSIGSTKSZ) + SIGSTKSZ; + ss.ss_flags = 0; + + if (sigaltstack(&ss, NULL)) + err(1, "sigaltstack"); + + +The exposed auxiliary vectors +============================= + +AT_SYSINFO is used for locating the vsyscall entry point. It is not +exported on 64-bit mode. + +AT_SYSINFO_EHDR is the start address of the page containing the vDSO. + +AT_MINSIGSTKSZ denotes the minimum stack size required by the kernel to +deliver a signal to user-space. AT_MINSIGSTKSZ comprehends the space +consumed by the kernel to accommodate the user context for the current +hardware configuration. It does not comprehend subsequent user-space stack +consumption, which must be added by the user. (e.g. Above, user-space adds +SIGSTKSZ to AT_MINSIGSTKSZ.) diff --git a/Documentation/x86/index.rst b/Documentation/x86/index.rst index 4693e192b447..d58614d5cde6 100644 --- a/Documentation/x86/index.rst +++ b/Documentation/x86/index.rst @@ -35,3 +35,4 @@ x86-specific Documentation sva sgx features + elf_auxvec -- cgit v1.2.3 From 11480dbfe1d59eaa6382864acc476e7621b1da4c Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Rafa=C5=82=20Mi=C5=82ecki?= Date: Wed, 12 May 2021 22:59:26 +0200 Subject: ASoC: wm8750: convert to the json-schema MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit This helps validating DTS files. Signed-off-by: Rafał Miłecki Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20210512205926.780-1-zajec5@gmail.com Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/sound/wm8750.txt | 18 ---------- .../devicetree/bindings/sound/wm8750.yaml | 42 ++++++++++++++++++++++ 2 files changed, 42 insertions(+), 18 deletions(-) delete mode 100644 Documentation/devicetree/bindings/sound/wm8750.txt create mode 100644 Documentation/devicetree/bindings/sound/wm8750.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/wm8750.txt b/Documentation/devicetree/bindings/sound/wm8750.txt deleted file mode 100644 index 682f221f6f38..000000000000 --- a/Documentation/devicetree/bindings/sound/wm8750.txt +++ /dev/null @@ -1,18 +0,0 @@ -WM8750 and WM8987 audio CODECs - -These devices support both I2C and SPI (configured with pin strapping -on the board). - -Required properties: - - - compatible : "wlf,wm8750" or "wlf,wm8987" - - - reg : the I2C address of the device for I2C, the chip select - number for SPI. - -Example: - -wm8750: codec@1a { - compatible = "wlf,wm8750"; - reg = <0x1a>; -}; diff --git a/Documentation/devicetree/bindings/sound/wm8750.yaml b/Documentation/devicetree/bindings/sound/wm8750.yaml new file mode 100644 index 000000000000..24246ac7bbdf --- /dev/null +++ b/Documentation/devicetree/bindings/sound/wm8750.yaml @@ -0,0 +1,42 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/wm8750.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: WM8750 and WM8987 audio CODECs + +description: | + These devices support both I2C and SPI (configured with pin strapping + on the board). + +maintainers: + - Mark Brown + +properties: + compatible: + enum: + - wlf,wm8750 + - wlf,wm8987 + + reg: + description: + The I2C address of the device for I2C, the chip select number for SPI + maxItems: 1 + +additionalProperties: false + +required: + - reg + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + codec@1a { + compatible = "wlf,wm8750"; + reg = <0x1a>; + }; + }; -- cgit v1.2.3 From 9cc52f5a533a321136b9e447042ad9f8224f738c Mon Sep 17 00:00:00 2001 From: Stephan Gerhold Date: Wed, 19 May 2021 11:16:12 +0200 Subject: dt-bindings: net: nfc: s3fwrn5: Add optional clock On some systems, S3FWRN5 depends on having an external clock enabled to function correctly. Allow declaring that clock in the device tree. Signed-off-by: Stephan Gerhold Reviewed-by: Krzysztof Kozlowski Signed-off-by: David S. Miller --- Documentation/devicetree/bindings/net/nfc/samsung,s3fwrn5.yaml | 5 +++++ 1 file changed, 5 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/nfc/samsung,s3fwrn5.yaml b/Documentation/devicetree/bindings/net/nfc/samsung,s3fwrn5.yaml index 477066e2b821..081742c2b726 100644 --- a/Documentation/devicetree/bindings/net/nfc/samsung,s3fwrn5.yaml +++ b/Documentation/devicetree/bindings/net/nfc/samsung,s3fwrn5.yaml @@ -27,6 +27,9 @@ properties: reg: maxItems: 1 + clocks: + maxItems: 1 + wake-gpios: maxItems: 1 description: @@ -80,6 +83,8 @@ examples: en-gpios = <&gpf1 4 GPIO_ACTIVE_HIGH>; wake-gpios = <&gpj0 2 GPIO_ACTIVE_HIGH>; + + clocks = <&rpmcc 20>; }; }; # UART example on Raspberry Pi -- cgit v1.2.3 From 4006f986c091cda1a66067f77b6f5704a9618562 Mon Sep 17 00:00:00 2001 From: DENG Qingfang Date: Wed, 19 May 2021 11:32:01 +0800 Subject: dt-bindings: net: dsa: add MT7530 interrupt controller binding Add device tree binding to support MT7530 interrupt controller. Signed-off-by: DENG Qingfang Reviewed-by: Andrew Lunn Reviewed-by: Florian Fainelli Acked-by: Rob Herring Signed-off-by: David S. Miller --- Documentation/devicetree/bindings/net/dsa/mt7530.txt | 6 ++++++ 1 file changed, 6 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/dsa/mt7530.txt b/Documentation/devicetree/bindings/net/dsa/mt7530.txt index de04626a8e9d..18247ebfc487 100644 --- a/Documentation/devicetree/bindings/net/dsa/mt7530.txt +++ b/Documentation/devicetree/bindings/net/dsa/mt7530.txt @@ -81,6 +81,12 @@ Optional properties: - gpio-controller: Boolean; if defined, MT7530's LED controller will run on GPIO mode. - #gpio-cells: Must be 2 if gpio-controller is defined. +- interrupt-controller: Boolean; Enables the internal interrupt controller. + +If interrupt-controller is defined, the following properties are required. + +- #interrupt-cells: Must be 1. +- interrupts: Parent interrupt for the interrupt controller. See Documentation/devicetree/bindings/net/dsa/dsa.txt for a list of additional required, optional properties and how the integrated switch subnodes must -- cgit v1.2.3 From f9fb145b27cd7700399075c0897e6918a4d5dabe Mon Sep 17 00:00:00 2001 From: satya priya Date: Wed, 12 May 2021 16:43:07 +0530 Subject: dt-bindings: pinctrl: qcom-pmic-gpio: Add pm7325 support Add compatible string for PM7325 pmic GPIO support to the Qualcomm PMIC GPIO binding. Signed-off-by: satya priya Acked-by: Rob Herring Link: https://lore.kernel.org/r/1620817988-18809-3-git-send-email-skakit@codeaurora.org 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 f6a9760558a6..161216daf463 100644 --- a/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.txt +++ b/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.txt @@ -31,6 +31,7 @@ PMIC's from Qualcomm. "qcom,pm8350b-gpio" "qcom,pm8350c-gpio" "qcom,pmk8350-gpio" + "qcom,pm7325-gpio" "qcom,pmr735a-gpio" "qcom,pmr735b-gpio" "qcom,pm6150-gpio" @@ -120,6 +121,7 @@ to specify in a pin configuration subnode: gpio1-gpio8 for pm8350b gpio1-gpio9 for pm8350c gpio1-gpio4 for pmk8350 + gpio1-gpio10 for pm7325 gpio1-gpio4 for pmr735a gpio1-gpio4 for pmr735b gpio1-gpio10 for pm6150 -- cgit v1.2.3 From 32f9402d56d876055ce0b75f41130de33072d5a7 Mon Sep 17 00:00:00 2001 From: Anusha Srivatsa Date: Tue, 18 May 2021 14:34:44 -0700 Subject: drm/i915/dmc: s/intel_csr.c/intel_dmc.c and s/intel_csr.h/intel_dmc.h Finally, rename the header and source file from csr to dmc. v2: Add file rename in Documentation. - Place headers in orders. (Jani) Cc: Jani Nikula Signed-off-by: Anusha Srivatsa Reviewed-by: Lucas De Marchi Signed-off-by: Lucas De Marchi Link: https://patchwork.freedesktop.org/patch/msgid/20210518213444.11420-6-anusha.srivatsa@intel.com --- Documentation/gpu/i915.rst | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) (limited to 'Documentation') diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst index 486c720f3890..42ce0196930a 100644 --- a/Documentation/gpu/i915.rst +++ b/Documentation/gpu/i915.rst @@ -210,13 +210,13 @@ DPIO .. kernel-doc:: drivers/gpu/drm/i915/display/intel_dpio_phy.c :doc: DPIO -CSR firmware support for DMC ----------------------------- +DMC Firmware Support +-------------------- -.. kernel-doc:: drivers/gpu/drm/i915/display/intel_csr.c - :doc: csr support for dmc +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_dmc.c + :doc: DMC Firmware Support -.. kernel-doc:: drivers/gpu/drm/i915/display/intel_csr.c +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_dmc.c :internal: Video BIOS Table (VBT) @@ -537,7 +537,7 @@ The HuC FW layout is the same as the GuC one, see `GuC Firmware Layout`_ DMC --- -See `CSR firmware support for DMC`_ +See `DMC Firmware Support`_ Tracing ======= -- cgit v1.2.3 From 88bf5a85fe9840c9b49c5f6c625cdccd11233943 Mon Sep 17 00:00:00 2001 From: Sudeep Holla Date: Mon, 17 May 2021 16:54:58 +0100 Subject: dt-bindings: dvfs: Add support for generic performance domains The CLKSCREW attack [0] exposed security vulnerabilities in energy management implementations where untrusted software had direct access to clock and voltage hardware controls. In this attack, the malicious software was able to place the platform into unsafe overclocked or undervolted configurations. Such configurations then enabled the injection of predictable faults to reveal secrets. Many Arm-based systems used to or still use voltage regulator and clock frameworks in the kernel. These frameworks allow callers to independently manipulate frequency and voltage settings. Such implementations can render systems susceptible to this form of attack. Attacks such as CLKSCREW are now being mitigated by not having direct and independent control of clock and voltage in the kernel and moving that control to a trusted entity, such as the SCP firmware or secure world firmware/software which are to perform sanity checking on the requested performance levels, thereby preventing any attempted malicious programming. With the advent of such an abstraction, there is a need to replace the generic clock and regulator bindings used by such devices with a generic performance domains bindings. [0] https://www.usenix.org/conference/usenixsecurity17/technical-sessions/presentation/tang Cc: Rob Herring Acked-by: Viresh Kumar Signed-off-by: Sudeep Holla Reviewed-by: Rob Herring Signed-off-by: Viresh Kumar --- Documentation/devicetree/bindings/arm/cpus.yaml | 7 ++ .../bindings/dvfs/performance-domain.yaml | 74 ++++++++++++++++++++++ 2 files changed, 81 insertions(+) create mode 100644 Documentation/devicetree/bindings/dvfs/performance-domain.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/cpus.yaml b/Documentation/devicetree/bindings/arm/cpus.yaml index f3c7249c73d6..9a2432a88074 100644 --- a/Documentation/devicetree/bindings/arm/cpus.yaml +++ b/Documentation/devicetree/bindings/arm/cpus.yaml @@ -257,6 +257,13 @@ properties: where voltage is in V, frequency is in MHz. + performance-domains: + maxItems: 1 + description: + List of phandles and performance domain specifiers, as defined by + bindings of the performance domain provider. See also + dvfs/performance-domain.yaml. + power-domains: description: List of phandles and PM domain specifiers, as defined by bindings of the diff --git a/Documentation/devicetree/bindings/dvfs/performance-domain.yaml b/Documentation/devicetree/bindings/dvfs/performance-domain.yaml new file mode 100644 index 000000000000..c8b91207f34d --- /dev/null +++ b/Documentation/devicetree/bindings/dvfs/performance-domain.yaml @@ -0,0 +1,74 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/dvfs/performance-domain.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Generic performance domains + +maintainers: + - Sudeep Holla + +description: |+ + This binding is intended for performance management of groups of devices or + CPUs that run in the same performance domain. Performance domains must not + be confused with power domains. A performance domain is defined by a set + of devices that always have to run at the same performance level. For a given + performance domain, there is a single point of control that affects all the + devices in the domain, making it impossible to set the performance level of + an individual device in the domain independently from other devices in + that domain. For example, a set of CPUs that share a voltage domain, and + have a common frequency control, is said to be in the same performance + domain. + + This device tree binding can be used to bind performance domain consumer + devices with their performance domains provided by performance domain + providers. A performance domain provider can be represented by any node in + the device tree and can provide one or more performance domains. A consumer + node can refer to the provider by a phandle and a set of phandle arguments + (so called performance domain specifiers) of length specified by the + \#performance-domain-cells property in the performance domain provider node. + +select: true + +properties: + "#performance-domain-cells": + description: + Number of cells in a performance domain specifier. Typically 0 for nodes + representing a single performance domain and 1 for nodes providing + multiple performance domains (e.g. performance controllers), but can be + any value as specified by device tree binding documentation of particular + provider. + enum: [ 0, 1 ] + + performance-domains: + $ref: '/schemas/types.yaml#/definitions/phandle-array' + maxItems: 1 + description: + A phandle and performance domain specifier as defined by bindings of the + performance controller/provider specified by phandle. + +additionalProperties: true + +examples: + - | + performance: performance-controller@12340000 { + compatible = "qcom,cpufreq-hw"; + reg = <0x12340000 0x1000>; + #performance-domain-cells = <1>; + }; + + // The node above defines a performance controller that is a performance + // domain provider and expects one cell as its phandle argument. + + cpus { + #address-cells = <2>; + #size-cells = <0>; + + cpu@0 { + device_type = "cpu"; + compatible = "arm,cortex-a57"; + reg = <0x0 0x0>; + performance-domains = <&performance 1>; + }; + }; -- cgit v1.2.3 From f985b0b6e1db4d5301379c5207606de915f9c4d0 Mon Sep 17 00:00:00 2001 From: Neil Armstrong Date: Tue, 18 May 2021 09:58:31 +0200 Subject: dt-bindings: serial: amlogic, meson-uart: add fifo-size property On most of the Amlogic SoCs, the first UART controller in the "Everything-Else" power domain has 128bytes of RX & TX FIFO, so add an optional property to describe a different FIFO size from the other ports (64bytes). Reviewed-by: Martin Blumenstingl Reviewed-by: Rob Herring Signed-off-by: Neil Armstrong Link: https://lore.kernel.org/r/20210518075833.3736038-2-narmstrong@baylibre.com Signed-off-by: Greg Kroah-Hartman --- Documentation/devicetree/bindings/serial/amlogic,meson-uart.yaml | 5 +++++ 1 file changed, 5 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/serial/amlogic,meson-uart.yaml b/Documentation/devicetree/bindings/serial/amlogic,meson-uart.yaml index 75ebc9952a99..7487aa6ef849 100644 --- a/Documentation/devicetree/bindings/serial/amlogic,meson-uart.yaml +++ b/Documentation/devicetree/bindings/serial/amlogic,meson-uart.yaml @@ -55,6 +55,11 @@ properties: - const: pclk - const: baud + fifo-size: + description: The fifo size supported by the UART channel. + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [64, 128] + required: - compatible - reg -- cgit v1.2.3 From 92e06e12212abe4b27ff18445a0f88e6b5236331 Mon Sep 17 00:00:00 2001 From: Lad Prabhakar Date: Fri, 14 May 2021 20:22:11 +0100 Subject: dt-bindings: serial: renesas,scif: Document r9a07g044 bindings Document R9A07G044 SoC variants, common compatiable string "renesas,scif-r9a07g044" is added for RZ/G2L and RZ/G2LC SoC. Signed-off-by: Lad Prabhakar Reviewed-by: Biju Das Acked-by: Rob Herring Link: https://lore.kernel.org/r/20210514192218.13022-10-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Greg Kroah-Hartman --- Documentation/devicetree/bindings/serial/renesas,scif.yaml | 4 ++++ 1 file changed, 4 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/serial/renesas,scif.yaml b/Documentation/devicetree/bindings/serial/renesas,scif.yaml index 22d76829f7ae..6b8731f7f2fb 100644 --- a/Documentation/devicetree/bindings/serial/renesas,scif.yaml +++ b/Documentation/devicetree/bindings/serial/renesas,scif.yaml @@ -64,6 +64,10 @@ properties: - const: renesas,rcar-gen3-scif # R-Car Gen3 and RZ/G2 - const: renesas,scif # generic SCIF compatible UART + - items: + - enum: + - renesas,scif-r9a07g044 # RZ/G2{L,LC} + reg: maxItems: 1 -- cgit v1.2.3 From 1d751b04a49dd7c2c7a07388074d262225f4de74 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Andreas=20F=C3=A4rber?= Date: Mon, 17 May 2021 01:05:44 +0200 Subject: dt-bindings: serial: snps-dw-apb-uart: Add Rockchip RK1808 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Add a Rockchip RK1808 compatible. Signed-off-by: Andreas Färber Acked-by: Rob Herring Link: https://lore.kernel.org/r/20210516230551.12469-3-afaerber@suse.de Signed-off-by: Greg Kroah-Hartman --- Documentation/devicetree/bindings/serial/snps-dw-apb-uart.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/serial/snps-dw-apb-uart.yaml b/Documentation/devicetree/bindings/serial/snps-dw-apb-uart.yaml index 88bf4adf1067..b49fda5e608f 100644 --- a/Documentation/devicetree/bindings/serial/snps-dw-apb-uart.yaml +++ b/Documentation/devicetree/bindings/serial/snps-dw-apb-uart.yaml @@ -23,6 +23,7 @@ properties: - items: - enum: - rockchip,px30-uart + - rockchip,rk1808-uart - rockchip,rk3036-uart - rockchip,rk3066-uart - rockchip,rk3188-uart -- cgit v1.2.3 From 4bc2bd5aefd60a2837a20b1e88e89eaaa677d229 Mon Sep 17 00:00:00 2001 From: Stafford Horne Date: Mon, 17 May 2021 20:54:52 +0900 Subject: serial: liteuart: Add support for earlycon Most litex boards using RISC-V soft cores us the sbi earlycon, however this is not available for non RISC-V litex SoC's. This patch enables earlycon for liteuart which is available on all Litex SoC's making support for earycon debugging more widely available. Cc: Florent Kermarrec Cc: Mateusz Holenko Cc: Joel Stanley Cc: Gabriel L. Somlo Reviewed-and-tested-by: Gabriel Somlo Reviewed-by: Jiri Slaby Reviewed-by: Joel Stanley Signed-off-by: Stafford Horne Link: https://lore.kernel.org/r/20210517115453.24365-1-shorne@gmail.com Signed-off-by: Greg Kroah-Hartman --- Documentation/admin-guide/kernel-parameters.txt | 5 +++++ 1 file changed, 5 insertions(+) (limited to 'Documentation') diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index cb89dbdedc46..17bdf5df404c 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -1092,6 +1092,11 @@ the driver will use only 32-bit accessors to read/write the device registers. + liteuart, + Start an early console on a litex serial port at the + specified address. The serial port must already be + setup and configured. Options are not yet supported. + meson, Start an early, polled-mode console on a meson serial port at the specified address. The serial port must -- cgit v1.2.3 From 623cd9cfcac522647e3624e48bf0661a39e8502a Mon Sep 17 00:00:00 2001 From: Shengjiu Wang Date: Mon, 17 May 2021 18:31:27 +0800 Subject: ASoC: dt-bindings: imx-card: Add binding doc for imx sound card Imx-card is a new added machine driver for supporting ak4458/ak5558/ak5552/ak4497 codec on i.MX platforms. But these DAC/ADCs are not only supported codecs. This machine driver is designed to be a more common machine driver for i.MX platform, it can support widely cpu dai interface and codec dai interface. Signed-off-by: Shengjiu Wang Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/1621247488-21412-1-git-send-email-shengjiu.wang@nxp.com Signed-off-by: Mark Brown --- .../devicetree/bindings/sound/imx-audio-card.yaml | 122 +++++++++++++++++++++ 1 file changed, 122 insertions(+) create mode 100644 Documentation/devicetree/bindings/sound/imx-audio-card.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/imx-audio-card.yaml b/Documentation/devicetree/bindings/sound/imx-audio-card.yaml new file mode 100644 index 000000000000..d1816dd061cf --- /dev/null +++ b/Documentation/devicetree/bindings/sound/imx-audio-card.yaml @@ -0,0 +1,122 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/imx-audio-card.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NXP i.MX audio sound card. + +maintainers: + - Shengjiu Wang + +properties: + compatible: + enum: + - fsl,imx-audio-card + + model: + $ref: /schemas/types.yaml#/definitions/string + description: User specified audio sound card name + + audio-routing: + $ref: /schemas/types.yaml#/definitions/non-unique-string-array + description: + A list of the connections between audio components. Each entry is a + pair of strings, the first being the connection's sink, the second + being the connection's source. Valid names could be power supplies, + MicBias of codec and the jacks on the board. + +patternProperties: + ".*-dai-link$": + description: + Each subnode represents a dai link. Subnodes of each dai links would be + cpu/codec dais. + + type: object + + properties: + link-name: + description: Indicates dai-link name and PCM stream name. + $ref: /schemas/types.yaml#/definitions/string + maxItems: 1 + + format: + description: audio format. + items: + enum: + - i2s + - dsp_b + + dai-tdm-slot-num: + description: see tdm-slot.txt. + $ref: /schemas/types.yaml#/definitions/uint32 + + dai-tdm-slot-width: + description: see tdm-slot.txt. + $ref: /schemas/types.yaml#/definitions/uint32 + + cpu: + description: Holds subnode which indicates cpu dai. + type: object + properties: + sound-dai: true + + codec: + description: Holds subnode which indicates codec dai. + type: object + properties: + sound-dai: true + + fsl,mclk-equal-bclk: + description: Indicates mclk can be equal to bclk, especially for sai interface + $ref: /schemas/types.yaml#/definitions/flag + + required: + - link-name + - cpu + + additionalProperties: false + +required: + - compatible + - model + +additionalProperties: false + +examples: + - | + sound-ak4458 { + compatible = "fsl,imx-audio-card"; + model = "ak4458-audio"; + pri-dai-link { + link-name = "akcodec"; + format = "i2s"; + fsl,mclk-equal-bclk; + cpu { + sound-dai = <&sai1>; + }; + codec { + sound-dai = <&ak4458_1>, <&ak4458_2>; + }; + }; + fe-dai-link { + link-name = "HiFi-ASRC-FE"; + format = "i2s"; + cpu { + sound-dai = <&easrc>; + }; + }; + be-dai-link { + link-name = "HiFi-ASRC-BE"; + format = "dsp_b"; + dai-tdm-slot-num = <8>; + dai-tdm-slot-width = <32>; + fsl,mclk-equal-bclk; + cpu { + sound-dai = <&sai1>; + }; + codec { + sound-dai = <&ak4458_1>, <&ak4458_2>; + }; + }; + }; -- cgit v1.2.3 From e437c1a3e7137c0da035a2804bf6b4cc007d4f5e Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Wed, 19 May 2021 10:51:39 +0200 Subject: docs: vcpu-requests.rst: fix reference for atomic ops Changeset f0400a77ebdc ("atomic: Delete obsolete documentation") got rid of atomic_ops.rst, pointing that this was superseded by Documentation/atomic_*.txt. Update its reference accordingly. Fixes: f0400a77ebdc ("atomic: Delete obsolete documentation") Signed-off-by: Mauro Carvalho Chehab Link: https://lore.kernel.org/r/703af756ac26a06c2185c05dfe6d902253f11161.1621413933.git.mchehab+huawei@kernel.org Signed-off-by: Jonathan Corbet --- Documentation/virt/kvm/vcpu-requests.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/virt/kvm/vcpu-requests.rst b/Documentation/virt/kvm/vcpu-requests.rst index 5feb3706a7ae..5f8798e7fdf8 100644 --- a/Documentation/virt/kvm/vcpu-requests.rst +++ b/Documentation/virt/kvm/vcpu-requests.rst @@ -302,6 +302,6 @@ VCPU returns from the call. References ========== -.. [atomic-ops] Documentation/core-api/atomic_ops.rst +.. [atomic-ops] Documentation/atomic_bitops.txt and Documentation/atomic_t.txt .. [memory-barriers] Documentation/memory-barriers.txt .. [lwn-mb] https://lwn.net/Articles/573436/ -- cgit v1.2.3 From 50bd52fef16dc806be11ba86f406364366f3f23b Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Wed, 19 May 2021 10:51:40 +0200 Subject: docs: translations/zh_CN: fix a typo at 8.Conclusion.rst transaltions -> translations Signed-off-by: Mauro Carvalho Chehab Acked-by: Wu XiangCheng Link: https://lore.kernel.org/r/40b3d5c983fb06d8a58d1f613c175a98e0631677.1621413933.git.mchehab+huawei@kernel.org Signed-off-by: Jonathan Corbet --- Documentation/translations/zh_CN/process/8.Conclusion.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/translations/zh_CN/process/8.Conclusion.rst b/Documentation/translations/zh_CN/process/8.Conclusion.rst index 71c3e30efc6f..4707f0101964 100644 --- a/Documentation/translations/zh_CN/process/8.Conclusion.rst +++ b/Documentation/translations/zh_CN/process/8.Conclusion.rst @@ -19,7 +19,7 @@ :ref:`Documentation/translations/zh_CN/process/howto.rst ` 文件是一个重要的起点； :ref:`Documentation/translations/zh_CN/process/submitting-patches.rst ` -和 :ref:`Documentation/transaltions/zh_CN/process/submitting-drivers.rst ` +和 :ref:`Documentation/translations/zh_CN/process/submitting-drivers.rst ` 也是所有内核开发人员都应该阅读的内容。许多内部内核API都是使用kerneldoc机制 记录的；“make htmldocs”或“make pdfdocs”可用于以HTML或PDF格式生成这些文档 （尽管某些发行版提供的tex版本会遇到内部限制，无法正确处理文档）。 -- cgit v1.2.3 From 716c9d9403d061d02c419a6f63a4f3fd01278cae Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Wed, 19 May 2021 10:51:41 +0200 Subject: docs: sched-bwc.rst: fix a typo on a doc name cgroupv2.rst -> cgroup-v2.rst Signed-off-by: Mauro Carvalho Chehab Link: https://lore.kernel.org/r/1dc0203bd7df375ef45832f0c88566e22c4138ff.1621413933.git.mchehab+huawei@kernel.org Signed-off-by: Jonathan Corbet --- Documentation/scheduler/sched-bwc.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/scheduler/sched-bwc.rst b/Documentation/scheduler/sched-bwc.rst index 845eee659199..1fc73555f5c4 100644 --- a/Documentation/scheduler/sched-bwc.rst +++ b/Documentation/scheduler/sched-bwc.rst @@ -29,7 +29,7 @@ Quota and period are managed within the cpu subsystem via cgroupfs. .. note:: The cgroupfs files described in this section are only applicable to cgroup v1. For cgroup v2, see - :ref:`Documentation/admin-guide/cgroupv2.rst `. + :ref:`Documentation/admin-guide/cgroup-v2.rst `. - cpu.cfs_quota_us: the total available run-time within a period (in microseconds) -- cgit v1.2.3 From 0a5fab9f085880dbd7f9b0055c74936ca8b64fc1 Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Wed, 19 May 2021 10:51:43 +0200 Subject: docs: virt: api.rst: fix a pointer to SGX documentation The document which describes the SGX kernel architecture was added at commit 3fa97bf00126 ("Documentation/x86: Document SGX kernel architecture") but the reference at virt/kvm/api.rst is pointing to some non-existing document. Signed-off-by: Mauro Carvalho Chehab Link: https://lore.kernel.org/r/138c24633c6e4edf862a2b4d77033c603fc10406.1621413933.git.mchehab+huawei@kernel.org Signed-off-by: Jonathan Corbet --- Documentation/virt/kvm/api.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst index 22d077562149..e86fe3481574 100644 --- a/Documentation/virt/kvm/api.rst +++ b/Documentation/virt/kvm/api.rst @@ -6360,7 +6360,7 @@ system fingerprint. To prevent userspace from circumventing such restrictions by running an enclave in a VM, KVM prevents access to privileged attributes by default. -See Documentation/x86/sgx/2.Kernel-internals.rst for more details. +See Documentation/x86/sgx.rst for more details. 8. Other capabilities. ====================== -- cgit v1.2.3 From 5286bd25e2095d71d248fbfd2a55ca4333dfd77e Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Wed, 19 May 2021 10:51:44 +0200 Subject: docs: ABI: iommu: remove duplicated definition for sysfs-kernel-iommu_groups ./scripts/get_abi.pl is reporting a duplicated definition for /sys/kernel/iommu_groups/reserved_regions, both at the same file: Warning: /sys/kernel/iommu_groups/reserved_regions is defined 2 times: Documentation/ABI/testing/sysfs-kernel-iommu_groups:15 Documentation/ABI/testing/sysfs-kernel-iommu_groups:27 Fix it by merging those into an unified entry. Signed-off-by: Mauro Carvalho Chehab Link: https://lore.kernel.org/r/ec33e8e9b8f120232ffb3b9fcc99c97b87f242e3.1621413933.git.mchehab+huawei@kernel.org Signed-off-by: Jonathan Corbet --- Documentation/ABI/testing/sysfs-kernel-iommu_groups | 12 ++++-------- 1 file changed, 4 insertions(+), 8 deletions(-) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-kernel-iommu_groups b/Documentation/ABI/testing/sysfs-kernel-iommu_groups index 0fedbb0f94e4..eae2f1c1e11e 100644 --- a/Documentation/ABI/testing/sysfs-kernel-iommu_groups +++ b/Documentation/ABI/testing/sysfs-kernel-iommu_groups @@ -25,14 +25,10 @@ Description: /sys/kernel/iommu_groups/reserved_regions list IOVA the base IOVA, the second is the end IOVA and the third field describes the type of the region. -What: /sys/kernel/iommu_groups/reserved_regions -Date: June 2019 -KernelVersion: v5.3 -Contact: Eric Auger -Description: In case an RMRR is used only by graphics or USB devices - it is now exposed as "direct-relaxable" instead of "direct". - In device assignment use case, for instance, those RMRR - are considered to be relaxable and safe. + Since kernel 5.3, in case an RMRR is used only by graphics or + USB devices it is now exposed as "direct-relaxable" instead + of "direct". In device assignment use case, for instance, + those RMRR are considered to be relaxable and safe. What: /sys/kernel/iommu_groups//type Date: November 2020 -- cgit v1.2.3 From 13d6f96750c89f7fc282788bd058559381ccec29 Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Wed, 19 May 2021 10:51:45 +0200 Subject: docs: ABI: sysfs-class-backlight: unify ambient light zone nodes ./scripts/get_abi.pl is warning about duplicated symbol definition: Warning: /sys/class/backlight//l1_daylight_max is defined 2 times: ./Documentation/ABI/testing/sysfs-class-backlight-driver-adp8870:4 ./Documentation/ABI/testing/sysfs-class-backlight-adp8860:12 What happens is that 3 drivers use the same pattern to report max and dim setting for different ambient light zones. It should be noticed that the adp8870 doc was missing an entry for l1_daylight_dim, which was fixed on this patch. While the ambient light zone is device-specific, the sysfs definition is actually common. So, unify them at: Documentation/ABI/testing/sysfs-class-backlight and use as the contact point, the e-mail reported by get_maintainers.pl for the subsystem. Signed-off-by: Mauro Carvalho Chehab Link: https://lore.kernel.org/r/c13c6ebd03cd04a0d15d89018f8d529918fc0a73.1621413933.git.mchehab+huawei@kernel.org Signed-off-by: Jonathan Corbet --- Documentation/ABI/testing/sysfs-class-backlight | 100 +++++++++++++++++++++ .../ABI/testing/sysfs-class-backlight-adp5520 | 31 ------- .../ABI/testing/sysfs-class-backlight-adp8860 | 37 -------- .../testing/sysfs-class-backlight-driver-adp8870 | 32 ------- 4 files changed, 100 insertions(+), 100 deletions(-) delete mode 100644 Documentation/ABI/testing/sysfs-class-backlight-adp5520 delete mode 100644 Documentation/ABI/testing/sysfs-class-backlight-adp8860 delete mode 100644 Documentation/ABI/testing/sysfs-class-backlight-driver-adp8870 (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-class-backlight b/Documentation/ABI/testing/sysfs-class-backlight index 1fc86401bf95..c453646b06e2 100644 --- a/Documentation/ABI/testing/sysfs-class-backlight +++ b/Documentation/ABI/testing/sysfs-class-backlight @@ -84,3 +84,103 @@ Description: It can be enabled by writing the value stored in /sys/class/backlight//max_brightness to /sys/class/backlight//brightness. + +What: /sys/class/backlight//_max +Date: Sep, 2009 +KernelVersion: v2.6.32 +Contact: device-drivers-devel@blackfin.uclinux.org +Description: + Control the maximum brightness for + on this . Values are between 0 and 127. This file + will also show the brightness level stored for this + . + + The is device-driver specific: + + For ADP5520 and ADP5501, can be: + + =========== ================================================ + Ambient sysfs entry + light zone + =========== ================================================ + daylight /sys/class/backlight//daylight_max + office /sys/class/backlight//office_max + dark /sys/class/backlight//dark_max + =========== ================================================ + + For ADP8860, can be: + + =========== ================================================ + Ambient sysfs entry + light zone + =========== ================================================ + l1_daylight /sys/class/backlight//l1_daylight_max + l2_office /sys/class/backlight//l2_office_max + l3_dark /sys/class/backlight//l3_dark_max + =========== ================================================ + + For ADP8870, can be: + + =========== ================================================ + Ambient sysfs entry + light zone + =========== ================================================ + l1_daylight /sys/class/backlight//l1_daylight_max + l2_bright /sys/class/backlight//l2_bright_max + l3_office /sys/class/backlight//l3_office_max + l4_indoor /sys/class/backlight//l4_indoor_max + l5_dark /sys/class/backlight//l5_dark_max + =========== ================================================ + + See also: /sys/class/backlight//ambient_light_zone. + +What: /sys/class/backlight//_dim +Date: Sep, 2009 +KernelVersion: v2.6.32 +Contact: device-drivers-devel@blackfin.uclinux.org +Description: + Control the dim brightness for + on this . Values are between 0 and 127, typically + set to 0. Full off when the backlight is disabled. + This file will also show the dim brightness level stored for + this . + + The is device-driver specific: + + For ADP5520 and ADP5501, can be: + + =========== ================================================ + Ambient sysfs entry + light zone + =========== ================================================ + daylight /sys/class/backlight//daylight_dim + office /sys/class/backlight//office_dim + dark /sys/class/backlight//dark_dim + =========== ================================================ + + For ADP8860, can be: + + =========== ================================================ + Ambient sysfs entry + light zone + =========== ================================================ + l1_daylight /sys/class/backlight//l1_daylight_dim + l2_office /sys/class/backlight//l2_office_dim + l3_dark /sys/class/backlight//l3_dark_dim + =========== ================================================ + + For ADP8870, can be: + + =========== ================================================ + Ambient sysfs entry + light zone + =========== ================================================ + l1_daylight /sys/class/backlight//l1_daylight_dim + l2_bright /sys/class/backlight//l2_bright_dim + l3_office /sys/class/backlight//l3_office_dim + l4_indoor /sys/class/backlight//l4_indoor_dim + l5_dark /sys/class/backlight//l5_dark_dim + =========== ================================================ + + See also: /sys/class/backlight//ambient_light_zone. + diff --git a/Documentation/ABI/testing/sysfs-class-backlight-adp5520 b/Documentation/ABI/testing/sysfs-class-backlight-adp5520 deleted file mode 100644 index 34b6ebafa210..000000000000 --- a/Documentation/ABI/testing/sysfs-class-backlight-adp5520 +++ /dev/null @@ -1,31 +0,0 @@ -sysfs interface for analog devices adp5520(01) backlight driver ---------------------------------------------------------------- - -The backlight brightness control operates at three different levels for the -adp5520 and adp5501 devices: daylight (level 1), office (level 2) and dark -(level 3). By default the brightness operates at the daylight brightness level. - -What: /sys/class/backlight//daylight_max -What: /sys/class/backlight//office_max -What: /sys/class/backlight//dark_max -Date: Sep, 2009 -KernelVersion: v2.6.32 -Contact: Michael Hennerich -Description: - (RW) Maximum current setting for the backlight when brightness - is at one of the three levels (daylight, office or dark). This - is an input code between 0 and 127, which is transformed to a - value between 0 mA and 30 mA using linear or non-linear - algorithms. - -What: /sys/class/backlight//daylight_dim -What: /sys/class/backlight//office_dim -What: /sys/class/backlight//dark_dim -Date: Sep, 2009 -KernelVersion: v2.6.32 -Contact: Michael Hennerich -Description: - (RW) Dim current setting for the backlight when brightness is at - one of the three levels (daylight, office or dark). This is an - input code between 0 and 127, which is transformed to a value - between 0 mA and 30 mA using linear or non-linear algorithms. diff --git a/Documentation/ABI/testing/sysfs-class-backlight-adp8860 b/Documentation/ABI/testing/sysfs-class-backlight-adp8860 deleted file mode 100644 index 6610ac73f9ba..000000000000 --- a/Documentation/ABI/testing/sysfs-class-backlight-adp8860 +++ /dev/null @@ -1,37 +0,0 @@ -sysfs interface for analog devices adp8860 backlight driver ------------------------------------------------------------ - -The backlight brightness control operates at three different levels for the -adp8860, adp8861 and adp8863 devices: daylight (level 1), office (level 2) and -dark (level 3). By default the brightness operates at the daylight brightness -level. - -See also /sys/class/backlight//ambient_light_level and -/sys/class/backlight//ambient_light_zone. - - -What: /sys/class/backlight//l1_daylight_max -What: /sys/class/backlight//l2_office_max -What: /sys/class/backlight//l3_dark_max -Date: Apr, 2010 -KernelVersion: v2.6.35 -Contact: Michael Hennerich -Description: - (RW) Maximum current setting for the backlight when brightness - is at one of the three levels (daylight, office or dark). This - is an input code between 0 and 127, which is transformed to a - value between 0 mA and 30 mA using linear or non-linear - algorithms. - - -What: /sys/class/backlight//l1_daylight_dim -What: /sys/class/backlight//l2_office_dim -What: /sys/class/backlight//l3_dark_dim -Date: Apr, 2010 -KernelVersion: v2.6.35 -Contact: Michael Hennerich -Description: - (RW) Dim current setting for the backlight when brightness is at - one of the three levels (daylight, office or dark). This is an - input code between 0 and 127, which is transformed to a value - between 0 mA and 30 mA using linear or non-linear algorithms. diff --git a/Documentation/ABI/testing/sysfs-class-backlight-driver-adp8870 b/Documentation/ABI/testing/sysfs-class-backlight-driver-adp8870 deleted file mode 100644 index b08ca912cad4..000000000000 --- a/Documentation/ABI/testing/sysfs-class-backlight-driver-adp8870 +++ /dev/null @@ -1,32 +0,0 @@ -See also /sys/class/backlight//ambient_light_level and -/sys/class/backlight//ambient_light_zone. - -What: /sys/class/backlight//_max -What: /sys/class/backlight//l1_daylight_max -What: /sys/class/backlight//l2_bright_max -What: /sys/class/backlight//l3_office_max -What: /sys/class/backlight//l4_indoor_max -What: /sys/class/backlight//l5_dark_max -Date: May 2011 -KernelVersion: 3.0 -Contact: device-drivers-devel@blackfin.uclinux.org -Description: - Control the maximum brightness for - on this . Values are between 0 and 127. This file - will also show the brightness level stored for this - . - -What: /sys/class/backlight//_dim -What: /sys/class/backlight//l2_bright_dim -What: /sys/class/backlight//l3_office_dim -What: /sys/class/backlight//l4_indoor_dim -What: /sys/class/backlight//l5_dark_dim -Date: May 2011 -KernelVersion: 3.0 -Contact: device-drivers-devel@blackfin.uclinux.org -Description: - Control the dim brightness for - on this . Values are between 0 and 127, typically - set to 0. Full off when the backlight is disabled. - This file will also show the dim brightness level stored for - this . -- cgit v1.2.3 From 1ca5d41c371e6abe788439e6eaecfa76baaf6979 Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Wed, 19 May 2021 10:51:46 +0200 Subject: docs: ABI: sysfs-class-led-trigger-pattern: remove repeat duplication As reported by scripts/get_abi.pl: Warning: /sys/class/leds//repeat is defined 2 times: Documentation/ABI/testing/sysfs-class-led-driver-el15203000:0 Documentation/ABI/testing/sysfs-class-led-trigger-pattern:28 The definition for the EL15203000 is just a special case of the sysfs led class. So, drop it and mentions the possible exception at the class definition. Signed-off-by: Mauro Carvalho Chehab Link: https://lore.kernel.org/r/394580bd2e007ffb640f97212973a772ed8f0409.1621413933.git.mchehab+huawei@kernel.org Signed-off-by: Jonathan Corbet --- Documentation/ABI/testing/sysfs-class-led-driver-el15203000 | 9 --------- Documentation/ABI/testing/sysfs-class-led-trigger-pattern | 3 +++ 2 files changed, 3 insertions(+), 9 deletions(-) delete mode 100644 Documentation/ABI/testing/sysfs-class-led-driver-el15203000 (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-class-led-driver-el15203000 b/Documentation/ABI/testing/sysfs-class-led-driver-el15203000 deleted file mode 100644 index 04f3ffdc5936..000000000000 --- a/Documentation/ABI/testing/sysfs-class-led-driver-el15203000 +++ /dev/null @@ -1,9 +0,0 @@ -What: /sys/class/leds//repeat -Date: September 2019 -KernelVersion: 5.5 -Description: - EL15203000 supports only indefinitely patterns, - so this file should always store -1. - - For more info, please see: - Documentation/ABI/testing/sysfs-class-led-trigger-pattern diff --git a/Documentation/ABI/testing/sysfs-class-led-trigger-pattern b/Documentation/ABI/testing/sysfs-class-led-trigger-pattern index d91a07767adf..8c57d2780554 100644 --- a/Documentation/ABI/testing/sysfs-class-led-trigger-pattern +++ b/Documentation/ABI/testing/sysfs-class-led-trigger-pattern @@ -35,3 +35,6 @@ Description: This file will always return the originally written repeat number. + + It should be noticed that some leds, like EL15203000 may + only support indefinitely patterns, so they always store -1. -- cgit v1.2.3 From cc3496bf8685a5bd0bdd79b23ef06e85184f8863 Mon Sep 17 00:00:00 2001 From: Wei Ming Chen Date: Sat, 15 May 2021 23:51:42 +0800 Subject: docs: Use fallthrough pseudo-keyword Replace /* fall through */ comment with fallthrough, make it align with original process/coding-style.rst Signed-off-by: Wei Ming Chen Link: https://lore.kernel.org/r/20210515155142.2490-1-jj251510319013@gmail.com Signed-off-by: Jonathan Corbet --- Documentation/translations/it_IT/process/coding-style.rst | 2 +- Documentation/translations/zh_CN/process/coding-style.rst | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/translations/it_IT/process/coding-style.rst b/Documentation/translations/it_IT/process/coding-style.rst index 95f2e7c985e2..ecc74ba50d3e 100644 --- a/Documentation/translations/it_IT/process/coding-style.rst +++ b/Documentation/translations/it_IT/process/coding-style.rst @@ -62,7 +62,7 @@ i ``case``. Un esempio.: case 'K': case 'k': mem <<= 10; - /* fall through */ + fallthrough; default: break; } diff --git a/Documentation/translations/zh_CN/process/coding-style.rst b/Documentation/translations/zh_CN/process/coding-style.rst index 406d43a02c02..b8c484a84d10 100644 --- a/Documentation/translations/zh_CN/process/coding-style.rst +++ b/Documentation/translations/zh_CN/process/coding-style.rst @@ -61,7 +61,7 @@ Linux 内核代码风格 case 'K': case 'k': mem <<= 10; - /* fall through */ + fallthrough; default: break; } -- cgit v1.2.3 From 76001b8bbf48517e1cb64f5cddcbc4d1369aab0b Mon Sep 17 00:00:00 2001 From: Dwaipayan Ray Date: Sat, 15 May 2021 18:53:48 +0530 Subject: docs: Add more message type documentations for checkpatch - Document a couple of more checkpatch message types. - Add a blank line before all `See:` lines to improve the rst output. - Create a new subsection `Permissions` and move a few types to it. Signed-off-by: Dwaipayan Ray Acked-by: Lukas Bulwahn Link: https://lore.kernel.org/r/20210515132348.19082-1-dwaipayanray1@gmail.com Signed-off-by: Jonathan Corbet --- Documentation/dev-tools/checkpatch.rst | 170 +++++++++++++++++++++++++++++++-- 1 file changed, 163 insertions(+), 7 deletions(-) (limited to 'Documentation') diff --git a/Documentation/dev-tools/checkpatch.rst b/Documentation/dev-tools/checkpatch.rst index 51fed1bd72ec..e409f27f48b6 100644 --- a/Documentation/dev-tools/checkpatch.rst +++ b/Documentation/dev-tools/checkpatch.rst @@ -246,6 +246,7 @@ Allocation style The first argument for kcalloc or kmalloc_array should be the number of elements. sizeof() as the first argument is generally wrong. + See: https://www.kernel.org/doc/html/latest/core-api/memory-allocation.html **ALLOC_SIZEOF_STRUCT** @@ -264,6 +265,7 @@ Allocation style **ALLOC_WITH_MULTIPLY** Prefer kmalloc_array/kcalloc over kmalloc/kzalloc with a sizeof multiply. + See: https://www.kernel.org/doc/html/latest/core-api/memory-allocation.html @@ -284,6 +286,7 @@ API usage BUG() or BUG_ON() should be avoided totally. Use WARN() and WARN_ON() instead, and handle the "impossible" error condition as gracefully as possible. + See: https://www.kernel.org/doc/html/latest/process/deprecated.html#bug-and-bug-on **CONSIDER_KSTRTO** @@ -292,12 +295,23 @@ API usage may lead to unexpected results in callers. The respective kstrtol(), kstrtoll(), kstrtoul(), and kstrtoull() functions tend to be the correct replacements. + See: https://www.kernel.org/doc/html/latest/process/deprecated.html#simple-strtol-simple-strtoll-simple-strtoul-simple-strtoull + **IN_ATOMIC** + in_atomic() is not for driver use so any such use is reported as an ERROR. + Also in_atomic() is often used to determine if we may sleep, but it is not + reliable in this use model therefore its use is strongly discouraged. + + However, in_atomic() is ok for core kernel use. + + See: https://lore.kernel.org/lkml/20080320201723.b87b3732.akpm@linux-foundation.org/ + **LOCKDEP** The lockdep_no_validate class was added as a temporary measure to prevent warnings on conversion of device->sem to device->mutex. It should not be used for any other purpose. + See: https://lore.kernel.org/lkml/1268959062.9440.467.camel@laptop/ **MALFORMED_INCLUDE** @@ -308,11 +322,18 @@ API usage **USE_LOCKDEP** lockdep_assert_held() annotations should be preferred over assertions based on spin_is_locked() + See: https://www.kernel.org/doc/html/latest/locking/lockdep-design.html#annotations **UAPI_INCLUDE** No #include statements in include/uapi should use a uapi/ path. + **USLEEP_RANGE** + usleep_range() should be preferred over udelay(). The proper way of + using usleep_range() is mentioned in the kernel docs. + + See: https://www.kernel.org/doc/html/latest/timers/timers-howto.html#delays-information-on-the-various-kernel-delay-sleep-mechanisms + Comment style ------------- @@ -338,6 +359,7 @@ Comment style **C99_COMMENTS** C99 style single line comments (//) should not be used. Prefer the block comment style instead. + See: https://www.kernel.org/doc/html/latest/process/coding-style.html#commenting @@ -347,6 +369,7 @@ Commit message **BAD_SIGN_OFF** The signed-off-by line does not fall in line with the standards specified by the community. + See: https://www.kernel.org/doc/html/latest/process/submitting-patches.html#developer-s-certificate-of-origin-1-1 **BAD_STABLE_ADDRESS_STYLE** @@ -368,12 +391,26 @@ Commit message **COMMIT_MESSAGE** The patch is missing a commit description. A brief description of the changes made by the patch should be added. + See: https://www.kernel.org/doc/html/latest/process/submitting-patches.html#describe-your-changes + **FROM_SIGN_OFF_MISMATCH** + The author's email does not match with that in the Signed-off-by: + line(s). This can be sometimes caused due to an improperly configured + email client. + + This message is emitted due to any of the following reasons:: + + - The email names do not match. + - The email addresses do not match. + - The email subaddresses do not match. + - The email comments do not match. + **MISSING_SIGN_OFF** The patch is missing a Signed-off-by line. A signed-off-by line should be added according to Developer's certificate of Origin. + See: https://www.kernel.org/doc/html/latest/process/submitting-patches.html#sign-your-work-the-developer-s-certificate-of-origin **NO_AUTHOR_SIGN_OFF** @@ -382,6 +419,7 @@ Commit message end of explanation of the patch to denote that the author has written it or otherwise has the rights to pass it on as an open source patch. + See: https://www.kernel.org/doc/html/latest/process/submitting-patches.html#sign-your-work-the-developer-s-certificate-of-origin **DIFF_IN_COMMIT_MSG** @@ -389,6 +427,7 @@ Commit message This causes problems when one tries to apply a file containing both the changelog and the diff because patch(1) tries to apply the diff which it found in the changelog. + See: https://lore.kernel.org/lkml/20150611134006.9df79a893e3636019ad2759e@linux-foundation.org/ **GERRIT_CHANGE_ID** @@ -431,6 +470,7 @@ Comparison style **BOOL_COMPARISON** Comparisons of A to true and false are better written as A and !A. + See: https://lore.kernel.org/lkml/1365563834.27174.12.camel@joe-AO722/ **COMPARISON_TO_NULL** @@ -492,6 +532,7 @@ Macros, Attributes and Symbols The kernel does *not* use the ``__DATE__`` and ``__TIME__`` macros, and enables warnings if they are used as they can lead to non-deterministic builds. + See: https://www.kernel.org/doc/html/latest/kbuild/reproducible-builds.html#timestamps **DEFINE_ARCH_HAS** @@ -502,6 +543,7 @@ Macros, Attributes and Symbols want architectures able to override them with optimized ones, we should either use weak functions (appropriate for some cases), or the symbol that protects them should be the same symbol we use. + See: https://lore.kernel.org/lkml/CA+55aFycQ9XJvEOsiM3txHL5bjUc8CeKWJNR_H+MiicaddB42Q@mail.gmail.com/ **INIT_ATTRIBUTE** @@ -528,6 +570,20 @@ Macros, Attributes and Symbols ... } + **MISPLACED_INIT** + It is possible to use section markers on variables in a way + which gcc doesn't understand (or at least not the way the + developer intended):: + + static struct __initdata samsung_pll_clock exynos4_plls[nr_plls] = { + + does not put exynos4_plls in the .initdata section. The __initdata + marker can be virtually anywhere on the line, except right after + "struct". The preferred location is before the "=" sign if there is + one, or before the trailing ";" otherwise. + + See: https://lore.kernel.org/lkml/1377655732.3619.19.camel@joe-AO722/ + **MULTISTATEMENT_MACRO_USE_DO_WHILE** Macros with multiple statements should be enclosed in a do - while block. Same should also be the case for macros @@ -541,6 +597,10 @@ Macros, Attributes and Symbols See: https://www.kernel.org/doc/html/latest/process/coding-style.html#macros-enums-and-rtl + **PREFER_FALLTHROUGH** + Use the `fallthrough;` pseudo keyword instead of + `/* fallthrough */` like comments. + **WEAK_DECLARATION** Using weak declarations like __attribute__((weak)) or __weak can have unintended link defects. Avoid using them. @@ -551,6 +611,7 @@ Functions and Variables **CAMELCASE** Avoid CamelCase Identifiers. + See: https://www.kernel.org/doc/html/latest/process/coding-style.html#naming **FUNCTION_WITHOUT_ARGS** @@ -583,6 +644,27 @@ Functions and Variables return bar; +Permissions +----------- + + **EXECUTE_PERMISSIONS** + There is no reason for source files to be executable. The executable + bit can be removed safely. + + **EXPORTED_WORLD_WRITABLE** + Exporting world writable sysfs/debugfs files is usually a bad thing. + When done arbitrarily they can introduce serious security bugs. + In the past, some of the debugfs vulnerabilities would seemingly allow + any local user to write arbitrary values into device registers - a + situation from which little good can be expected to emerge. + + See: https://lore.kernel.org/linux-arm-kernel/cover.1296818921.git.segoon@openwall.com/ + + **NON_OCTAL_PERMISSIONS** + Permission bits should use 4 digit octal permissions (like 0700 or 0444). + Avoid using any other base like decimal. + + Spacing and Brackets -------------------- @@ -616,7 +698,7 @@ Spacing and Brackets 1. With a type on the left:: - ;int [] a; + int [] a; 2. At the beginning of a line for slice initialisers:: @@ -630,6 +712,7 @@ Spacing and Brackets Code indent should use tabs instead of spaces. Outside of comments, documentation and Kconfig, spaces are never used for indentation. + See: https://www.kernel.org/doc/html/latest/process/coding-style.html#indentation **CONCATENATED_STRING** @@ -644,17 +727,20 @@ Spacing and Brackets **ELSE_AFTER_BRACE** `else {` should follow the closing block `}` on the same line. + See: https://www.kernel.org/doc/html/latest/process/coding-style.html#placing-braces-and-spaces **LINE_SPACING** Vertical space is wasted given the limited number of lines an editor window can display when multiple blank lines are used. + See: https://www.kernel.org/doc/html/latest/process/coding-style.html#spaces **OPEN_BRACE** The opening brace should be following the function definitions on the next line. For any non-functional block it should be on the same line as the last construct. + See: https://www.kernel.org/doc/html/latest/process/coding-style.html#placing-braces-and-spaces **POINTER_LOCATION** @@ -671,6 +757,7 @@ Spacing and Brackets **SPACING** Whitespace style used in the kernel sources is described in kernel docs. + See: https://www.kernel.org/doc/html/latest/process/coding-style.html#spaces **SWITCH_CASE_INDENT_LEVEL** @@ -700,8 +787,40 @@ Spacing and Brackets Trailing whitespace should always be removed. Some editors highlight the trailing whitespace and cause visual distractions when editing files. + See: https://www.kernel.org/doc/html/latest/process/coding-style.html#spaces + **UNNECESSARY_PARENTHESES** + Parentheses are not required in the following cases:: + + 1. Function pointer uses:: + + (foo->bar)(); + + could be:: + + foo->bar(); + + 2. Comparisons in if:: + + if ((foo->bar) && (foo->baz)) + if ((foo == bar)) + + could be:: + + if (foo->bar && foo->baz) + if (foo == bar) + + 3. addressof/dereference single Lvalues:: + + &(foo->bar) + *(foo->bar) + + could be:: + + &foo->bar + *foo->bar + **WHILE_AFTER_BRACE** while should follow the closing bracket on the same line:: @@ -727,13 +846,40 @@ Others For DOS-formatted patches, there are extra ^M symbols at the end of the line. These should be removed. - **EXECUTE_PERMISSIONS** - There is no reason for source files to be executable. The executable - bit can be removed safely. + **FSF_MAILING_ADDRESS** + Kernel maintainers reject new instances of the GPL boilerplate paragraph + directing people to write to the FSF for a copy of the GPL, since the + FSF has moved in the past and may do so again. + So do not write paragraphs about writing to the Free Software Foundation's + mailing address. - **NON_OCTAL_PERMISSIONS** - Permission bits should use 4 digit octal permissions (like 0700 or 0444). - Avoid using any other base like decimal. + See: https://lore.kernel.org/lkml/20131006222342.GT19510@leaf/ + + **LONG_LINE** + The line has exceeded the specified maximum length. Consider refactoring + it. + To use a different maximum line length, the --max-line-length=n option + may be added while invoking checkpatch. + + See: https://www.kernel.org/doc/html/latest/process/coding-style.html#breaking-long-lines-and-strings + + **LONG_LINE_STRING** + A string starts before but extends beyond the maximum line length. + To use a different maximum line length, the --max-line-length=n option + may be added while invoking checkpatch. + + See: https://www.kernel.org/doc/html/latest/process/coding-style.html#breaking-long-lines-and-strings + + **LONG_LINE_COMMENT** + A comment starts before but extends beyond the maximum line length. + To use a different maximum line length, the --max-line-length=n option + may be added while invoking checkpatch. + + See: https://www.kernel.org/doc/html/latest/process/coding-style.html#breaking-long-lines-and-strings + + **MEMSET** + The memset use appears to be incorrect. This may be caused due to + badly ordered parameters. Please recheck the usage. **NOT_UNIFIED_DIFF** The patch file does not appear to be in unified-diff format. Please @@ -742,6 +888,13 @@ Others **PRINTF_0XDECIMAL** Prefixing 0x with decimal output is defective and should be corrected. + **SPDX_LICENSE_TAG** + The source file is missing or has an improper SPDX identifier tag. + The Linux kernel requires the precise SPDX identifier in all source files, + and it is thoroughly documented in the kernel docs. + + See: https://www.kernel.org/doc/html/latest/process/license-rules.html + **TRAILING_STATEMENTS** Trailing statements (for example after any conditional) should be on the next line. @@ -753,3 +906,6 @@ Others if (x == y) break; + + **TYPO_SPELLING** + Some words may have been misspelled. Consider reviewing them. -- cgit v1.2.3 From fa5b8fef20b12bc7135e69a1b3689b1d677534de Mon Sep 17 00:00:00 2001 From: Yanteng Si Date: Wed, 12 May 2021 16:20:57 +0800 Subject: docs/zh_CN: add parisc index translation This patch translates Documentation/parisc/index.rst into Chinese. Signed-off-by: Yanteng Si Reviewed-by: Wu XiangCheng Link: https://lore.kernel.org/r/c13ce34b11a65e1f18c4e37566509ead82f2c15f.1620805100.git.siyanteng@loongson.cn Signed-off-by: Jonathan Corbet --- Documentation/translations/zh_CN/index.rst | 2 +- Documentation/translations/zh_CN/parisc/index.rst | 24 +++++++++++++++++++++++ 2 files changed, 25 insertions(+), 1 deletion(-) create mode 100644 Documentation/translations/zh_CN/parisc/index.rst (limited to 'Documentation') diff --git a/Documentation/translations/zh_CN/index.rst b/Documentation/translations/zh_CN/index.rst index 95c3f313cea1..a736057da41f 100644 --- a/Documentation/translations/zh_CN/index.rst +++ b/Documentation/translations/zh_CN/index.rst @@ -153,6 +153,7 @@ TODOList: arm64/index riscv/index openrisc/index + parisc/index TODOList: @@ -160,7 +161,6 @@ TODOList: * ia64/index * m68k/index * nios2/index -* parisc/index * powerpc/index * s390/index * sh/index diff --git a/Documentation/translations/zh_CN/parisc/index.rst b/Documentation/translations/zh_CN/parisc/index.rst new file mode 100644 index 000000000000..ef232d46b1ba --- /dev/null +++ b/Documentation/translations/zh_CN/parisc/index.rst @@ -0,0 +1,24 @@ +.. SPDX-License-Identifier: GPL-2.0 +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/parisc/index.rst +:Translator: Yanteng Si + +.. _cn_parisc_index: + +==================== +PA-RISC体系架构 +==================== + +Todolist: + + debugging + registers + features + +.. only:: subproject and html + + Indices + ======= + + * :ref:`genindex` -- cgit v1.2.3 From b24247ded3e3616d225769bdeaf8782c244c80ee Mon Sep 17 00:00:00 2001 From: Yanteng Si Date: Wed, 12 May 2021 16:20:58 +0800 Subject: docs/zh_CN: add parisc debugging.rst translation This patch translates Documentation/parisc/debugging.rst into Chinese. Signed-off-by: Yanteng Si Link: https://lore.kernel.org/r/32661b39374f012442b760444ef149afcc0d22af.1620805100.git.siyanteng@loongson.cn Signed-off-by: Jonathan Corbet --- .../translations/zh_CN/parisc/debugging.rst | 42 ++++++++++++++++++++++ Documentation/translations/zh_CN/parisc/index.rst | 6 +++- 2 files changed, 47 insertions(+), 1 deletion(-) create mode 100644 Documentation/translations/zh_CN/parisc/debugging.rst (limited to 'Documentation') diff --git a/Documentation/translations/zh_CN/parisc/debugging.rst b/Documentation/translations/zh_CN/parisc/debugging.rst new file mode 100644 index 000000000000..c21beb986e15 --- /dev/null +++ b/Documentation/translations/zh_CN/parisc/debugging.rst @@ -0,0 +1,42 @@ +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/parisc/debugging.rst +:Translator: Yanteng Si + +.. _cn_parisc_debugging: + +================= +调试PA-RISC +================= + +好吧，这里有一些关于调试linux/parisc的较底层部分的信息。 + + +1. 绝对地址 +===================== + +很多汇编代码目前运行在实模式下，这意味着会使用绝对地址，而不是像内核其他 +部分那样使用虚拟地址。要将绝对地址转换为虚拟地址，你可以在System.map中查 +找，添加__PAGE_OFFSET（目前是0x10000000）。 + + +2. HPMCs +======== + +当实模式的代码试图访问不存在的内存时，会出现HPMC（high priority machine +check）而不是内核oops。若要调试HPMC，请尝试找到系统响应程序/请求程序地址。 +系统请求程序地址应该与（某）处理器的HPA（I/O范围内的高地址）相匹配；系统响应程 +序地址是实模式代码试图访问的地址。 + +系统响应程序地址的典型值是大于__PAGE_OFFSET （0x10000000）的地址，这意味着 +在实模式试图访问它之前，虚拟地址没有被翻译成物理地址。 + + +3. 有趣的Q位 +============ + +某些非常关键的代码必须清除PSW中的Q位。当Q位被清除时，CPU不会更新中断处理 +程序所读取的寄存器，以找出机器被中断的位置——所以如果你在清除Q位的指令和再 +次设置Q位的RFI之间遇到中断，你不知道它到底发生在哪里。如果你幸运的话，IAOQ +会指向清除Q位的指令，如果你不幸运的话，它会指向任何地方。通常Q位的问题会 +表现为无法解释的系统挂起或物理内存越界。 diff --git a/Documentation/translations/zh_CN/parisc/index.rst b/Documentation/translations/zh_CN/parisc/index.rst index ef232d46b1ba..b913d664e735 100644 --- a/Documentation/translations/zh_CN/parisc/index.rst +++ b/Documentation/translations/zh_CN/parisc/index.rst @@ -10,9 +10,13 @@ PA-RISC体系架构 ==================== -Todolist: +.. toctree:: + :maxdepth: 2 debugging + +Todolist: + registers features -- cgit v1.2.3 From 5fb82175a2aeb44d174ec60d264e54cb6e1e55f4 Mon Sep 17 00:00:00 2001 From: Yanteng Si Date: Wed, 12 May 2021 16:20:59 +0800 Subject: docs/zh_CN: add parisc registers.rst translation This patch translates Documentation/parisc/registers.rst into Chinese. Signed-off-by: Yanteng Si Reviewed-by: Wu XiangCheng Link: https://lore.kernel.org/r/b8375b5cd2c5163691691fe4757511ce984f3b83.1620805100.git.siyanteng@loongson.cn Signed-off-by: Jonathan Corbet --- Documentation/translations/zh_CN/parisc/index.rst | 2 +- .../translations/zh_CN/parisc/registers.rst | 153 +++++++++++++++++++++ 2 files changed, 154 insertions(+), 1 deletion(-) create mode 100644 Documentation/translations/zh_CN/parisc/registers.rst (limited to 'Documentation') diff --git a/Documentation/translations/zh_CN/parisc/index.rst b/Documentation/translations/zh_CN/parisc/index.rst index b913d664e735..a47454ebe32e 100644 --- a/Documentation/translations/zh_CN/parisc/index.rst +++ b/Documentation/translations/zh_CN/parisc/index.rst @@ -14,10 +14,10 @@ PA-RISC体系架构 :maxdepth: 2 debugging + registers Todolist: - registers features .. only:: subproject and html diff --git a/Documentation/translations/zh_CN/parisc/registers.rst b/Documentation/translations/zh_CN/parisc/registers.rst new file mode 100644 index 000000000000..71e2404cd103 --- /dev/null +++ b/Documentation/translations/zh_CN/parisc/registers.rst @@ -0,0 +1,153 @@ +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/parisc/registers.rst +:Translator: Yanteng Si + +.. _cn_parisc_registers: + +========================= +Linux/PA-RISC的寄存器用法 +========================= + +[ 用星号表示目前尚未实现的计划用途。 ] + +ABI约定的通用寄存器 +=================== + +控制寄存器 +---------- + +============================ ================================= +CR 0 (恢复计数器) 用于ptrace +CR 1-CR 7(无定义) 未使用 +CR 8 (Protection ID) 每进程值* +CR 9, 12, 13 (PIDS) 未使用 +CR10 (CCR) FPU延迟保存* +CR11 按照ABI的规定（SAR） +CR14 (中断向量) 初始化为 fault_vector +CR15 (EIEM) 所有位初始化为1* +CR16 (间隔计时器) 读取周期数/写入开始时间间隔计时器 +CR17-CR22 中断参数 +CR19 中断指令寄存器 +CR20 中断空间寄存器 +CR21 中断偏移量寄存器 +CR22 中断 PSW +CR23 (EIRR) 读取未决中断/写入清除位 +CR24 (TR 0) 内核空间页目录指针 +CR25 (TR 1) 用户空间页目录指针 +CR26 (TR 2) 不使用 +CR27 (TR 3) 线程描述符指针 +CR28 (TR 4) 不使用 +CR29 (TR 5) 不使用 +CR30 (TR 6) 当前 / 0 +CR31 (TR 7) 临时寄存器，在不同地方使用 +============================ ================================= + +空间寄存器（内核模式） +---------------------- + +======== ============================== +SR0 临时空间寄存器 +SR4-SR7 设置为0 +SR1 临时空间寄存器 +SR2 内核不应该破坏它 +SR3 用于用户空间访问（当前进程） +======== ============================== + +空间寄存器（用户模式） +---------------------- + +======== ============================ +SR0 临时空间寄存器 +SR1 临时空间寄存器 +SR2 保存Linux gateway page的空间 +SR3 在内核中保存用户地址空间的值 +SR4-SR7 定义了用户/内核的短地址空间 +======== ============================ + + +处理器状态字 +------------ + +====================== ================================================ +W （64位地址） 0 +E （小尾端） 0 +S （安全间隔计时器） 0 +T （产生分支陷阱） 0 +H （高特权级陷阱） 0 +L （低特权级陷阱） 0 +N （撤销下一条指令） 被C代码使用 +X （数据存储中断禁用） 0 +B （产生分支） 被C代码使用 +C （代码地址转译） 1, 在执行实模式代码时为0 +V （除法步长校正） 被C代码使用 +M （HPMC 掩码） 0, 在执行HPMC操作*时为1 +C/B （进/借 位） 被C代码使用 +O （有序引用） 1* +F （性能监视器） 0 +R （回收计数器陷阱） 0 +Q （收集中断状态） 1 （在rfi之前的代码中为0） +P （保护标识符） 1* +D （数据地址转译） 1, 在执行实模式代码时为0 +I （外部中断掩码） 由cli()/sti()宏使用。 +====================== ================================================ + +“隐形”寄存器（影子寄存器） +--------------------------- + +============= =================== +PSW W 默认值 0 +PSW E 默认值 0 +影子寄存器 被中断处理代码使用 +TOC启用位 1 +============= =================== + +---------------------------------------------------------- + +PA-RISC架构定义了7个寄存器作为“影子寄存器”。这些寄存器在 +RETURN FROM INTERRUPTION AND RESTORE指令中使用，通过消 +除中断处理程序中对一般寄存器（GR）的保存和恢复的需要来减 +少状态保存和恢复时间。影子寄存器是GRs 1, 8, 9, 16, 17, +24和25。 + +------------------------------------------------------------------------- + +寄存器使用说明，最初由John Marvin提供，并由Randolph Chung提供一些补充说明。 + +对于通用寄存器: + +r1,r2,r19-r26,r28,r29 & r31可以在不保存它们的情况下被使用。当然，如果你 +关心它们，在调用另一个程序之前，你也需要保存它们。上面的一些寄存器确实 +有特殊的含义，你应该注意一下: + + r1: + addil指令是硬性规定将其结果放在r1中，所以如果你使用这条指令要 + 注意这点。 + + r2: + 这就是返回指针。一般来说，你不想使用它，因为你需要这个指针来返 + 回给你的调用者。然而，它与这组寄存器组合在一起，因为调用者不能 + 依赖你返回时的值是相同的，也就是说，你可以将r2复制到另一个寄存 + 器，并在作废r2后通过该寄存器返回，这应该不会给调用程序带来问题。 + + r19-r22: + 这些通常被认为是临时寄存器。 + 请注意，在64位中它们是arg7-arg4。 + + r23-r26: + 这些是arg3-arg0，也就是说，如果你不再关心传入的值，你可以使用 + 它们。 + + r28,r29: + 这俩是ret0和ret1。它们是你传入返回值的地方。r28是主返回值。当返回 + 小结构体时，r29也可以用来将数据传回给调用程序。 + + r30: + 栈指针 + + r31: + ble指令将返回指针放在这里。 + + + r3-r18,r27,r30需要被保存和恢复。r3-r18只是一般用途的寄存器。 + r27是数据指针，用来使对全局变量的引用更容易。r30是栈指针。 -- cgit v1.2.3 From 1d92d5569cca0c2c659afb451f2874d9643dda26 Mon Sep 17 00:00:00 2001 From: Marek Vasut Date: Tue, 18 May 2021 00:43:36 +0200 Subject: dt-bindings: display: Fix spacing in lvds.yaml Add missing spaces to make the diagrams readable, no functional change. Signed-off-by: Marek Vasut Cc: Sam Ravnborg Cc: devicetree@vger.kernel.org To: dri-devel@lists.freedesktop.org Reviewed-by: Laurent Pinchart Link: https://lore.kernel.org/r/20210517224336.409301-1-marex@denx.de Signed-off-by: Rob Herring --- .../devicetree/bindings/display/panel/lvds.yaml | 46 +++++++++++----------- 1 file changed, 23 insertions(+), 23 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/panel/lvds.yaml b/Documentation/devicetree/bindings/display/panel/lvds.yaml index 31164608ba1d..49460c9dceea 100644 --- a/Documentation/devicetree/bindings/display/panel/lvds.yaml +++ b/Documentation/devicetree/bindings/display/panel/lvds.yaml @@ -51,37 +51,37 @@ properties: - "jeida-18" - 18-bit data mapping compatible with the [JEIDA], [LDI] and [VESA] specifications. Data are transferred as follows on 3 LVDS lanes. - Slot 0 1 2 3 4 5 6 - ________________ _________________ - Clock \_______________________/ - ______ ______ ______ ______ ______ ______ ______ - DATA0 ><__G0__><__R5__><__R4__><__R3__><__R2__><__R1__><__R0__>< - DATA1 ><__B1__><__B0__><__G5__><__G4__><__G3__><__G2__><__G1__>< - DATA2 ><_CTL2_><_CTL1_><_CTL0_><__B5__><__B4__><__B3__><__B2__>< + Slot 0 1 2 3 4 5 6 + ________________ _________________ + Clock \_______________________/ + ______ ______ ______ ______ ______ ______ ______ + DATA0 ><__G0__><__R5__><__R4__><__R3__><__R2__><__R1__><__R0__>< + DATA1 ><__B1__><__B0__><__G5__><__G4__><__G3__><__G2__><__G1__>< + DATA2 ><_CTL2_><_CTL1_><_CTL0_><__B5__><__B4__><__B3__><__B2__>< - "jeida-24" - 24-bit data mapping compatible with the [DSIM] and [LDI] specifications. Data are transferred as follows on 4 LVDS lanes. - Slot 0 1 2 3 4 5 6 - ________________ _________________ - Clock \_______________________/ - ______ ______ ______ ______ ______ ______ ______ - DATA0 ><__G2__><__R7__><__R6__><__R5__><__R4__><__R3__><__R2__>< - DATA1 ><__B3__><__B2__><__G7__><__G6__><__G5__><__G4__><__G3__>< - DATA2 ><_CTL2_><_CTL1_><_CTL0_><__B7__><__B6__><__B5__><__B4__>< - DATA3 ><_CTL3_><__B1__><__B0__><__G1__><__G0__><__R1__><__R0__>< + Slot 0 1 2 3 4 5 6 + ________________ _________________ + Clock \_______________________/ + ______ ______ ______ ______ ______ ______ ______ + DATA0 ><__G2__><__R7__><__R6__><__R5__><__R4__><__R3__><__R2__>< + DATA1 ><__B3__><__B2__><__G7__><__G6__><__G5__><__G4__><__G3__>< + DATA2 ><_CTL2_><_CTL1_><_CTL0_><__B7__><__B6__><__B5__><__B4__>< + DATA3 ><_CTL3_><__B1__><__B0__><__G1__><__G0__><__R1__><__R0__>< - "vesa-24" - 24-bit data mapping compatible with the [VESA] specification. Data are transferred as follows on 4 LVDS lanes. - Slot 0 1 2 3 4 5 6 - ________________ _________________ - Clock \_______________________/ - ______ ______ ______ ______ ______ ______ ______ - DATA0 ><__G0__><__R5__><__R4__><__R3__><__R2__><__R1__><__R0__>< - DATA1 ><__B1__><__B0__><__G5__><__G4__><__G3__><__G2__><__G1__>< - DATA2 ><_CTL2_><_CTL1_><_CTL0_><__B5__><__B4__><__B3__><__B2__>< - DATA3 ><_CTL3_><__B7__><__B6__><__G7__><__G6__><__R7__><__R6__>< + Slot 0 1 2 3 4 5 6 + ________________ _________________ + Clock \_______________________/ + ______ ______ ______ ______ ______ ______ ______ + DATA0 ><__G0__><__R5__><__R4__><__R3__><__R2__><__R1__><__R0__>< + DATA1 ><__B1__><__B0__><__G5__><__G4__><__G3__><__G2__><__G1__>< + DATA2 ><_CTL2_><_CTL1_><_CTL0_><__B5__><__B4__><__B3__><__B2__>< + DATA3 ><_CTL3_><__B7__><__B6__><__G7__><__G6__><__R7__><__R6__>< Control signals are mapped as follows. -- cgit v1.2.3 From 50e02e9a030a9ae3feab54dc1bb8f8926786e994 Mon Sep 17 00:00:00 2001 From: Geert Uytterhoeven Date: Thu, 20 May 2021 16:45:23 +0200 Subject: dt-bindings: timer: arm,twd: Convert to json-schema Convert the ARM Timer-Watchdog Device Tree binding documentation to json-schema. As the old binding document actually contained two bindings, it is split in two document: one for the timer part, and one for the watchdog part. Document missing properties. Update examples to match reality. Signed-off-by: Geert Uytterhoeven Link: https://lore.kernel.org/r/3ccc0cf5319f56e230ee3b8a009f8d63afb114c1.1621521847.git.geert+renesas@glider.be [robh: Fix up node names] Signed-off-by: Rob Herring --- .../devicetree/bindings/arm/ux500/boards.txt | 2 +- .../devicetree/bindings/timer/arm,twd-timer.yaml | 56 ++++++++++++++++++++++ .../devicetree/bindings/timer/arm,twd.txt | 53 -------------------- .../devicetree/bindings/watchdog/arm,twd-wdt.yaml | 50 +++++++++++++++++++ 4 files changed, 107 insertions(+), 54 deletions(-) create mode 100644 Documentation/devicetree/bindings/timer/arm,twd-timer.yaml delete mode 100644 Documentation/devicetree/bindings/timer/arm,twd.txt create mode 100644 Documentation/devicetree/bindings/watchdog/arm,twd-wdt.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/ux500/boards.txt b/Documentation/devicetree/bindings/arm/ux500/boards.txt index 89408de55bfd..5a7e6f712623 100644 --- a/Documentation/devicetree/bindings/arm/ux500/boards.txt +++ b/Documentation/devicetree/bindings/arm/ux500/boards.txt @@ -26,7 +26,7 @@ interrupt-controller: see binding for interrupt-controller/arm,gic.txt timer: - see binding for timer/arm,twd.txt + see binding for timer/arm,twd-timer.yaml clocks: see binding for clocks/ux500.txt diff --git a/Documentation/devicetree/bindings/timer/arm,twd-timer.yaml b/Documentation/devicetree/bindings/timer/arm,twd-timer.yaml new file mode 100644 index 000000000000..5684df6448ef --- /dev/null +++ b/Documentation/devicetree/bindings/timer/arm,twd-timer.yaml @@ -0,0 +1,56 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/timer/arm,twd-timer.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: ARM Timer-Watchdog Timer + +maintainers: + - Rob Herring + +description: + ARM 11MP, Cortex-A5 and Cortex-A9 are often associated with a per-core + Timer-Watchdog (aka TWD), which provides both a per-cpu local timer + and watchdog. + + The TWD is usually attached to a GIC to deliver its two per-processor + interrupts. + +properties: + compatible: + enum: + - arm,cortex-a9-twd-timer + - arm,cortex-a5-twd-timer + - arm,arm11mp-twd-timer + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + + always-on: + description: + If present, the timer is powered through an always-on power domain, + therefore it never loses context. + +required: + - compatible + - reg + - interrupts + +additionalProperties: false + +examples: + - | + #include + + timer@2c000600 { + compatible = "arm,arm11mp-twd-timer"; + reg = <0x2c000600 0x20>; + interrupts = ; + }; diff --git a/Documentation/devicetree/bindings/timer/arm,twd.txt b/Documentation/devicetree/bindings/timer/arm,twd.txt deleted file mode 100644 index 383ea19c2bf0..000000000000 --- a/Documentation/devicetree/bindings/timer/arm,twd.txt +++ /dev/null @@ -1,53 +0,0 @@ -* ARM Timer Watchdog - -ARM 11MP, Cortex-A5 and Cortex-A9 are often associated with a per-core -Timer-Watchdog (aka TWD), which provides both a per-cpu local timer -and watchdog. - -The TWD is usually attached to a GIC to deliver its two per-processor -interrupts. - -** Timer node required properties: - -- compatible : Should be one of: - "arm,cortex-a9-twd-timer" - "arm,cortex-a5-twd-timer" - "arm,arm11mp-twd-timer" - -- interrupts : One interrupt to each core - -- reg : Specify the base address and the size of the TWD timer - register window. - -Optional - -- always-on : a boolean property. If present, the timer is powered through - an always-on power domain, therefore it never loses context. - -Example: - - twd-timer@2c000600 { - compatible = "arm,arm11mp-twd-timer""; - reg = <0x2c000600 0x20>; - interrupts = <1 13 0xf01>; - }; - -** Watchdog node properties: - -- compatible : Should be one of: - "arm,cortex-a9-twd-wdt" - "arm,cortex-a5-twd-wdt" - "arm,arm11mp-twd-wdt" - -- interrupts : One interrupt to each core - -- reg : Specify the base address and the size of the TWD watchdog - register window. - -Example: - - twd-watchdog@2c000620 { - compatible = "arm,arm11mp-twd-wdt"; - reg = <0x2c000620 0x20>; - interrupts = <1 14 0xf01>; - }; diff --git a/Documentation/devicetree/bindings/watchdog/arm,twd-wdt.yaml b/Documentation/devicetree/bindings/watchdog/arm,twd-wdt.yaml new file mode 100644 index 000000000000..bb8901854222 --- /dev/null +++ b/Documentation/devicetree/bindings/watchdog/arm,twd-wdt.yaml @@ -0,0 +1,50 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/watchdog/arm,twd-wdt.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: ARM Timer-Watchdog Watchdog + +maintainers: + - Rob Herring + +description: + ARM 11MP, Cortex-A5 and Cortex-A9 are often associated with a per-core + Timer-Watchdog (aka TWD), which provides both a per-cpu local timer + and watchdog. + + The TWD is usually attached to a GIC to deliver its two per-processor + interrupts. + +properties: + compatible: + enum: + - arm,cortex-a9-twd-wdt + - arm,cortex-a5-twd-wdt + - arm,arm11mp-twd-wdt + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + #include + + watchdog@2c000620 { + compatible = "arm,arm11mp-twd-wdt"; + reg = <0x2c000620 0x20>; + interrupts = ; + }; -- cgit v1.2.3 From 2e684660e56dffa37fc5b92d76a84291a2f1cc87 Mon Sep 17 00:00:00 2001 From: Geert Uytterhoeven Date: Thu, 20 May 2021 17:03:40 +0200 Subject: dt-bindings: arm: scu: Convert to json-schema Convert the ARM Snoop Control Unit (SCU) Device Tree binding documentation to json-schema. Document required properties. Signed-off-by: Geert Uytterhoeven Link: https://lore.kernel.org/r/c5c36fb952675df4b9c9834d53a21fb58f391e86.1621522979.git.geert+renesas@glider.be Signed-off-by: Rob Herring --- Documentation/devicetree/bindings/arm/arm,scu.yaml | 46 ++++++++++++++++++++++ Documentation/devicetree/bindings/arm/scu.txt | 28 ------------- .../devicetree/bindings/arm/ux500/boards.txt | 2 +- 3 files changed, 47 insertions(+), 29 deletions(-) create mode 100644 Documentation/devicetree/bindings/arm/arm,scu.yaml delete mode 100644 Documentation/devicetree/bindings/arm/scu.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/arm,scu.yaml b/Documentation/devicetree/bindings/arm/arm,scu.yaml new file mode 100644 index 000000000000..dae2aa27e641 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/arm,scu.yaml @@ -0,0 +1,46 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/arm/arm,scu.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: ARM Snoop Control Unit (SCU) + +maintainers: + - Linus Walleij + +description: | + As part of the MPCore complex, Cortex-A5 and Cortex-A9 are provided + with a Snoop Control Unit. The register range is usually 256 (0x100) + bytes. + + References: + - Cortex-A9: see DDI0407E Cortex-A9 MPCore Technical Reference Manual + Revision r2p0 + - Cortex-A5: see DDI0434B Cortex-A5 MPCore Technical Reference Manual + Revision r0p1 + - ARM11 MPCore: see DDI0360F ARM 11 MPCore Processor Technical Reference + Manial Revision r2p0 + +properties: + compatible: + enum: + - arm,cortex-a9-scu + - arm,cortex-a5-scu + - arm,arm11mp-scu + + reg: + maxItems: 1 + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + scu@a0410000 { + compatible = "arm,cortex-a9-scu"; + reg = <0xa0410000 0x100>; + }; diff --git a/Documentation/devicetree/bindings/arm/scu.txt b/Documentation/devicetree/bindings/arm/scu.txt deleted file mode 100644 index 74d0a780ce51..000000000000 --- a/Documentation/devicetree/bindings/arm/scu.txt +++ /dev/null @@ -1,28 +0,0 @@ -* ARM Snoop Control Unit (SCU) - -As part of the MPCore complex, Cortex-A5 and Cortex-A9 are provided -with a Snoop Control Unit. The register range is usually 256 (0x100) -bytes. - -References: - -- Cortex-A9: see DDI0407E Cortex-A9 MPCore Technical Reference Manual - Revision r2p0 -- Cortex-A5: see DDI0434B Cortex-A5 MPCore Technical Reference Manual - Revision r0p1 -- ARM11 MPCore: see DDI0360F ARM 11 MPCore Processor Technical Reference - Manial Revision r2p0 - -- compatible : Should be: - "arm,cortex-a9-scu" - "arm,cortex-a5-scu" - "arm,arm11mp-scu" - -- reg : Specify the base address and the size of the SCU register window. - -Example: - -scu@a0410000 { - compatible = "arm,cortex-a9-scu"; - reg = <0xa0410000 0x100>; -}; diff --git a/Documentation/devicetree/bindings/arm/ux500/boards.txt b/Documentation/devicetree/bindings/arm/ux500/boards.txt index 5a7e6f712623..18d55532d31e 100644 --- a/Documentation/devicetree/bindings/arm/ux500/boards.txt +++ b/Documentation/devicetree/bindings/arm/ux500/boards.txt @@ -20,7 +20,7 @@ during retention, system won't boot without this): compatible = "ste,dbx500-backupram" scu: - see binding for arm/scu.txt + see binding for arm/arm,scu.yaml interrupt-controller: see binding for interrupt-controller/arm,gic.txt -- cgit v1.2.3 From 2bc602cb0e0d92afec57967cf2212b66cba42ea5 Mon Sep 17 00:00:00 2001 From: Yue Hu Date: Thu, 20 May 2021 15:42:25 +0800 Subject: docs: block: blk-mq.rst: correct drive -> driver It is 'driver' to complete the request. Also remove a redundant space. Signed-off-by: Yue Hu Link: https://lore.kernel.org/r/20210520074225.1989-1-zbestahu@gmail.com Signed-off-by: Jonathan Corbet --- Documentation/block/blk-mq.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/block/blk-mq.rst b/Documentation/block/blk-mq.rst index a980d23af48c..d96118c73954 100644 --- a/Documentation/block/blk-mq.rst +++ b/Documentation/block/blk-mq.rst @@ -62,7 +62,7 @@ queue, to be sent in the future, when the hardware is able. Software staging queues ~~~~~~~~~~~~~~~~~~~~~~~ -The block IO subsystem adds requests in the software staging queues +The block IO subsystem adds requests in the software staging queues (represented by struct blk_mq_ctx) in case that they weren't sent directly to the driver. A request is one or more BIOs. They arrived at the block layer through the data structure struct bio. The block layer @@ -132,7 +132,7 @@ In order to indicate which request has been completed, every request is identified by an integer, ranging from 0 to the dispatch queue size. This tag is generated by the block layer and later reused by the device driver, removing the need to create a redundant identifier. When a request is completed in the -drive, the tag is sent back to the block layer to notify it of the finalization. +driver, the tag is sent back to the block layer to notify it of the finalization. This removes the need to do a linear search to find out which IO has been completed. -- cgit v1.2.3 From 0e7c52da1ab82338fc91021cc34e8f2fdaf73de4 Mon Sep 17 00:00:00 2001 From: Andrew Jeffery Date: Thu, 20 May 2021 19:09:49 +0930 Subject: Documentation: checkpatch: Tweak BIT() macro include While include/linux/bitops.h brings in the BIT() macro, it was moved to include/linux/bits.h in commit 8bd9cb51daac ("locking/atomics, asm-generic: Move some macros from to a new file"). Since that commit BIT() has moved again into include/vdso/bits.h via commit 3945ff37d2f4 ("linux/bits.h: Extract common header for vDSO"). I think the move to the vDSO header can be considered an implementation detail, so for now update the checkpatch documentation to recommend use of include/linux/bits.h. Signed-off-by: Andrew Jeffery Acked-by: Jiri Slaby Acked-by: Lukas Bulwahn Acked-by: Dwaipayan Ray Cc: Jiri Slaby Link: https://lore.kernel.org/r/20210520093949.511471-1-andrew@aj.id.au Signed-off-by: Jonathan Corbet --- Documentation/dev-tools/checkpatch.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/dev-tools/checkpatch.rst b/Documentation/dev-tools/checkpatch.rst index e409f27f48b6..87b859f321de 100644 --- a/Documentation/dev-tools/checkpatch.rst +++ b/Documentation/dev-tools/checkpatch.rst @@ -512,7 +512,7 @@ Macros, Attributes and Symbols **BIT_MACRO** Defines like: 1 << could be BIT(digit). - The BIT() macro is defined in include/linux/bitops.h:: + The BIT() macro is defined via include/linux/bits.h:: #define BIT(nr) (1UL << (nr)) -- cgit v1.2.3 From 3f87443b4ee6710e682a1ef48cc09316e025257d Mon Sep 17 00:00:00 2001 From: Andre Przywara Date: Wed, 19 May 2021 11:41:44 +0100 Subject: dt-bindings: usb: sunxi-musb: Add H616 compatible string The H616 MUSB peripheral is compatible to the H3 one (8 endpoints). Signed-off-by: Andre Przywara Acked-by: Maxime Ripard Acked-by: Rob Herring Link: https://lore.kernel.org/r/20210519104152.21119-10-andre.przywara@arm.com Signed-off-by: Greg Kroah-Hartman --- Documentation/devicetree/bindings/usb/allwinner,sun4i-a10-musb.yaml | 3 +++ 1 file changed, 3 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/usb/allwinner,sun4i-a10-musb.yaml b/Documentation/devicetree/bindings/usb/allwinner,sun4i-a10-musb.yaml index 0f520f17735e..933fa356d2ce 100644 --- a/Documentation/devicetree/bindings/usb/allwinner,sun4i-a10-musb.yaml +++ b/Documentation/devicetree/bindings/usb/allwinner,sun4i-a10-musb.yaml @@ -22,6 +22,9 @@ properties: - allwinner,sun8i-a83t-musb - allwinner,sun50i-h6-musb - const: allwinner,sun8i-a33-musb + - items: + - const: allwinner,sun50i-h616-musb + - const: allwinner,sun8i-h3-musb reg: maxItems: 1 -- cgit v1.2.3 From c63fef4c4302f5d41945f5362ff0cf556cb6db19 Mon Sep 17 00:00:00 2001 From: Andre Przywara Date: Wed, 19 May 2021 11:41:43 +0100 Subject: dt-bindings: usb: Add H616 compatible string The H616 has four PHYs as the H3, along with their respective clock gates and resets, so the property description is identical. However the PHYs itself need some special bits, so we need a new compatible string for it. Signed-off-by: Andre Przywara Acked-by: Rob Herring Link: https://lore.kernel.org/r/20210519104152.21119-9-andre.przywara@arm.com Signed-off-by: Greg Kroah-Hartman --- Documentation/devicetree/bindings/phy/allwinner,sun8i-h3-usb-phy.yaml | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/phy/allwinner,sun8i-h3-usb-phy.yaml b/Documentation/devicetree/bindings/phy/allwinner,sun8i-h3-usb-phy.yaml index f80431060803..e288450e0844 100644 --- a/Documentation/devicetree/bindings/phy/allwinner,sun8i-h3-usb-phy.yaml +++ b/Documentation/devicetree/bindings/phy/allwinner,sun8i-h3-usb-phy.yaml @@ -15,7 +15,9 @@ properties: const: 1 compatible: - const: allwinner,sun8i-h3-usb-phy + enum: + - allwinner,sun8i-h3-usb-phy + - allwinner,sun50i-h616-usb-phy reg: items: -- cgit v1.2.3 From fd6ec5d79507f99639c94f107e8a98550c9e1cf6 Mon Sep 17 00:00:00 2001 From: Luiz Sampaio Date: Wed, 19 May 2021 19:30:45 -0300 Subject: w1: ds2438: adding support for reading page1 Added a sysfs entry to support reading the page1 registers. This registers contain Elapsed Time Meter (ETM) data, which shows for how long the chip is on, as well as an Offset Register data, which can be used to calibrate the current measurement of the chip. Signed-off-by: Luiz Sampaio Link: https://lore.kernel.org/r/20210519223046.13798-6-sampaio.ime@gmail.com Signed-off-by: Greg Kroah-Hartman --- Documentation/ABI/stable/sysfs-driver-w1_ds2438 | 6 ++++++ Documentation/w1/slaves/w1_ds2438.rst | 8 ++++++++ 2 files changed, 14 insertions(+) create mode 100644 Documentation/ABI/stable/sysfs-driver-w1_ds2438 (limited to 'Documentation') diff --git a/Documentation/ABI/stable/sysfs-driver-w1_ds2438 b/Documentation/ABI/stable/sysfs-driver-w1_ds2438 new file mode 100644 index 000000000000..fa47437c11d9 --- /dev/null +++ b/Documentation/ABI/stable/sysfs-driver-w1_ds2438 @@ -0,0 +1,6 @@ +What: /sys/bus/w1/devices/.../page1 +Date: April 2021 +Contact: Luiz Sampaio +Description: read the contents of the page1 of the DS2438 + see Documentation/w1/slaves/w1_ds2438.rst for detailed information +Users: any user space application which wants to communicate with DS2438 diff --git a/Documentation/w1/slaves/w1_ds2438.rst b/Documentation/w1/slaves/w1_ds2438.rst index a29309a3f8e5..ac8d0d4b0d0e 100644 --- a/Documentation/w1/slaves/w1_ds2438.rst +++ b/Documentation/w1/slaves/w1_ds2438.rst @@ -44,6 +44,14 @@ Internally when this file is read, the additional CRC byte is also obtained from the slave device. If it is correct, the 8 bytes page data are passed to userspace, otherwise an I/O error is returned. +"page1" +------- +This file provides full 8 bytes of the chip Page 1 (01h). +This page contains the ICA, elapsed time meter and current offset data of the DS2438. +Internally when this file is read, the additional CRC byte is also obtained +from the slave device. If it is correct, the 8 bytes page data are passed +to userspace, otherwise an I/O error is returned. + "temperature" ------------- Opening and reading this file initiates the CONVERT_T (temperature conversion) -- cgit v1.2.3 From c999fbbdcf778c2ea77f59e26d7448a1ab8fa8a2 Mon Sep 17 00:00:00 2001 From: Luiz Sampaio Date: Wed, 19 May 2021 19:30:46 -0300 Subject: w1: ds2438: support for writing to offset register Added a sysfs entry to support writing to the offset register on page1. This register is used to calibrate the chip canceling offset errors in the current ADC. This means that, over time, reading the IAD register will not return the correct current measurement, it will have an offset. Writing to the offset register if the two's complement of the current register while passing zero current to the load will calibrate the measurements. This change was tested on real hardware and it was able to calibrate the chip correctly. Signed-off-by: Luiz Sampaio Link: https://lore.kernel.org/r/20210519223046.13798-7-sampaio.ime@gmail.com Signed-off-by: Greg Kroah-Hartman --- Documentation/ABI/stable/sysfs-driver-w1_ds2438 | 7 +++++++ Documentation/w1/slaves/w1_ds2438.rst | 11 ++++++++++- 2 files changed, 17 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/ABI/stable/sysfs-driver-w1_ds2438 b/Documentation/ABI/stable/sysfs-driver-w1_ds2438 index fa47437c11d9..d2e7681cc287 100644 --- a/Documentation/ABI/stable/sysfs-driver-w1_ds2438 +++ b/Documentation/ABI/stable/sysfs-driver-w1_ds2438 @@ -4,3 +4,10 @@ Contact: Luiz Sampaio Description: read the contents of the page1 of the DS2438 see Documentation/w1/slaves/w1_ds2438.rst for detailed information Users: any user space application which wants to communicate with DS2438 + +What: /sys/bus/w1/devices/.../offset +Date: April 2021 +Contact: Luiz Sampaio +Description: write the contents to the offset register of the DS2438 + see Documentation/w1/slaves/w1_ds2438.rst for detailed information +Users: any user space application which wants to communicate with DS2438 diff --git a/Documentation/w1/slaves/w1_ds2438.rst b/Documentation/w1/slaves/w1_ds2438.rst index ac8d0d4b0d0e..5c5573991351 100644 --- a/Documentation/w1/slaves/w1_ds2438.rst +++ b/Documentation/w1/slaves/w1_ds2438.rst @@ -22,7 +22,7 @@ is also often used in weather stations and applications such as: rain gauge, wind speed/direction measuring, humidity sensing, etc. Current support is provided through the following sysfs files (all files -except "iad" are readonly): +except "iad" and "offset" are readonly): "iad" ----- @@ -52,6 +52,15 @@ Internally when this file is read, the additional CRC byte is also obtained from the slave device. If it is correct, the 8 bytes page data are passed to userspace, otherwise an I/O error is returned. +"offset" +------- +This file controls the 2-byte Offset Register of the chip. +Writing a 2-byte value will change the Offset Register, which changes the +current measurement done by the chip. Changing this register to the two's complement +of the current register while forcing zero current through the load will calibrate +the chip, canceling offset errors in the current ADC. + + "temperature" ------------- Opening and reading this file initiates the CONVERT_T (temperature conversion) -- cgit v1.2.3 From 58c08df5751d823332ccdb49f1d5795479097119 Mon Sep 17 00:00:00 2001 From: Arnd Bergmann Date: Wed, 21 Apr 2021 15:58:40 +0200 Subject: media: rc: remove tango ir driver and keymap The tango platform was removed, so the driver is no longer needed. Cc: Marc Gonzalez Acked-by: Rob Herring Acked-by: Mans Rullgard Signed-off-by: Arnd Bergmann Signed-off-by: Sean Young Signed-off-by: Mauro Carvalho Chehab --- Documentation/devicetree/bindings/media/rc.yaml | 1 - .../devicetree/bindings/media/tango-ir.txt | 21 --------------------- 2 files changed, 22 deletions(-) delete mode 100644 Documentation/devicetree/bindings/media/tango-ir.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/media/rc.yaml b/Documentation/devicetree/bindings/media/rc.yaml index af9e7e59e5a1..12d838b05632 100644 --- a/Documentation/devicetree/bindings/media/rc.yaml +++ b/Documentation/devicetree/bindings/media/rc.yaml @@ -125,7 +125,6 @@ properties: - rc-snapstream-firefly - rc-streamzap - rc-su3000 - - rc-tango - rc-tanix-tx3mini - rc-tanix-tx5max - rc-tbs-nec diff --git a/Documentation/devicetree/bindings/media/tango-ir.txt b/Documentation/devicetree/bindings/media/tango-ir.txt deleted file mode 100644 index a9f00c2bf897..000000000000 --- a/Documentation/devicetree/bindings/media/tango-ir.txt +++ /dev/null @@ -1,21 +0,0 @@ -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 1a60317bc83f51ac6bca53f9551945971cf4a5d2 Mon Sep 17 00:00:00 2001 From: Fabien Parent Date: Thu, 20 May 2021 13:16:55 +0200 Subject: dt-bindings: rng: mediatek: convert to yaml schema Convert the RNG binding for MediaTek to use YAML schema. Signed-off-by: Fabien Parent Link: https://lore.kernel.org/r/20210520111656.66017-1-fparent@baylibre.com Signed-off-by: Rob Herring --- Documentation/devicetree/bindings/rng/mtk-rng.txt | 22 --------- Documentation/devicetree/bindings/rng/mtk-rng.yaml | 53 ++++++++++++++++++++++ 2 files changed, 53 insertions(+), 22 deletions(-) delete mode 100644 Documentation/devicetree/bindings/rng/mtk-rng.txt create mode 100644 Documentation/devicetree/bindings/rng/mtk-rng.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/rng/mtk-rng.txt b/Documentation/devicetree/bindings/rng/mtk-rng.txt deleted file mode 100644 index dfdcb5cd2ea8..000000000000 --- a/Documentation/devicetree/bindings/rng/mtk-rng.txt +++ /dev/null @@ -1,22 +0,0 @@ -Device-Tree bindings for Mediatek random number generator -found in MediaTek SoC family - -Required properties: -- compatible : Should be - "mediatek,mt7622-rng", "mediatek,mt7623-rng" : for MT7622 - "mediatek,mt7629-rng", "mediatek,mt7623-rng" : for MT7629 - "mediatek,mt7623-rng" : for MT7623 - "mediatek,mt8516-rng", "mediatek,mt7623-rng" : for MT8516 -- clocks : list of clock specifiers, corresponding to - entries in clock-names property; -- clock-names : Should contain "rng" entries; -- reg : Specifies base physical address and size of the registers - -Example: - -rng: rng@1020f000 { - compatible = "mediatek,mt7623-rng"; - reg = <0 0x1020f000 0 0x1000>; - clocks = <&infracfg CLK_INFRA_TRNG>; - clock-names = "rng"; -}; diff --git a/Documentation/devicetree/bindings/rng/mtk-rng.yaml b/Documentation/devicetree/bindings/rng/mtk-rng.yaml new file mode 100644 index 000000000000..4be5fc3c1409 --- /dev/null +++ b/Documentation/devicetree/bindings/rng/mtk-rng.yaml @@ -0,0 +1,53 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/rng/mtk-rng.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: MediaTek Random number generator + +maintainers: + - Sean Wang + +properties: + $nodename: + pattern: "^rng@[0-9a-f]+$" + + compatible: + oneOf: + - enum: + - mediatek,mt7623-rng + - items: + - enum: + - mediatek,mt7622-rng + - mediatek,mt7629-rng + - mediatek,mt8516-rng + - const: mediatek,mt7623-rng + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + + clock-names: + items: + - const: rng + +required: + - compatible + - reg + - clocks + - clock-names + +additionalProperties: false + +examples: + - | + #include + rng: rng@1020f000 { + compatible = "mediatek,mt7623-rng"; + reg = <0x1020f000 0x1000>; + clocks = <&infracfg CLK_INFRA_TRNG>; + clock-names = "rng"; + }; -- cgit v1.2.3 From 70c1fc34f3c67ee8abc363a25803f47bfcec889f Mon Sep 17 00:00:00 2001 From: Fabien Parent Date: Thu, 20 May 2021 13:16:56 +0200 Subject: dt-bindings: rng: mediatek: add mt8365 to mtk rng binding Add RNG binding for MT8365 SoC. Signed-off-by: Fabien Parent Link: https://lore.kernel.org/r/20210520111656.66017-2-fparent@baylibre.com Signed-off-by: Rob Herring --- Documentation/devicetree/bindings/rng/mtk-rng.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/rng/mtk-rng.yaml b/Documentation/devicetree/bindings/rng/mtk-rng.yaml index 4be5fc3c1409..61888e07bda0 100644 --- a/Documentation/devicetree/bindings/rng/mtk-rng.yaml +++ b/Documentation/devicetree/bindings/rng/mtk-rng.yaml @@ -21,6 +21,7 @@ properties: - enum: - mediatek,mt7622-rng - mediatek,mt7629-rng + - mediatek,mt8365-rng - mediatek,mt8516-rng - const: mediatek,mt7623-rng -- cgit v1.2.3 From c3d175e4852bfdfd1e4021dff8715fc407dedd98 Mon Sep 17 00:00:00 2001 From: "Rafael J. Wysocki" Date: Wed, 12 May 2021 16:15:48 +0200 Subject: cpufreq: intel_pstate: hybrid: Avoid exposing two global attributes The turbo_pct and num_pstates sysfs attributes represent CPU properties that may be different for differenty types of CPUs in a hybrid processor, so avoid exposing them in that case. Signed-off-by: Rafael J. Wysocki --- Documentation/admin-guide/pm/intel_pstate.rst | 6 ++++++ 1 file changed, 6 insertions(+) (limited to 'Documentation') diff --git a/Documentation/admin-guide/pm/intel_pstate.rst b/Documentation/admin-guide/pm/intel_pstate.rst index df29b4f1f219..235f1025a7e6 100644 --- a/Documentation/admin-guide/pm/intel_pstate.rst +++ b/Documentation/admin-guide/pm/intel_pstate.rst @@ -365,6 +365,9 @@ argument is passed to the kernel in the command line. inclusive) including both turbo and non-turbo P-states (see `Turbo P-states Support`_). + This attribute is present only if the value exposed by it is the same + for all of the CPUs in the system. + The value of this attribute is not affected by the ``no_turbo`` setting described `below `_. @@ -374,6 +377,9 @@ argument is passed to the kernel in the command line. Ratio of the `turbo range `_ size to the size of the entire range of supported P-states, in percent. + This attribute is present only if the value exposed by it is the same + for all of the CPUs in the system. + This attribute is read-only. .. _no_turbo_attr: -- cgit v1.2.3 From 9acc89d31f0c94c8e573ed61f3e4340bbd526d0c Mon Sep 17 00:00:00 2001 From: Roberto Sassu Date: Fri, 14 May 2021 17:27:44 +0200 Subject: evm: Refuse EVM_ALLOW_METADATA_WRITES only if an HMAC key is loaded EVM_ALLOW_METADATA_WRITES is an EVM initialization flag that can be set to temporarily disable metadata verification until all xattrs/attrs necessary to verify an EVM portable signature are copied to the file. This flag is cleared when EVM is initialized with an HMAC key, to avoid that the HMAC is calculated on unverified xattrs/attrs. Currently EVM unnecessarily denies setting this flag if EVM is initialized with a public key, which is not a concern as it cannot be used to trust xattrs/attrs updates. This patch removes this limitation. Fixes: ae1ba1676b88e ("EVM: Allow userland to permit modification of EVM-protected metadata") Signed-off-by: Roberto Sassu Cc: stable@vger.kernel.org # 4.16.x Signed-off-by: Mimi Zohar --- Documentation/ABI/testing/evm | 26 ++++++++++++++++++++++++-- 1 file changed, 24 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/evm b/Documentation/ABI/testing/evm index 3c477ba48a31..2243b72e4110 100644 --- a/Documentation/ABI/testing/evm +++ b/Documentation/ABI/testing/evm @@ -49,8 +49,30 @@ Description: modification of EVM-protected metadata and disable all further modification of policy - Note that once a key has been loaded, it will no longer be - possible to enable metadata modification. + Echoing a value is additive, the new value is added to the + existing initialization flags. + + For example, after:: + + echo 2 >/evm + + another echo can be performed:: + + echo 1 >/evm + + and the resulting value will be 3. + + Note that once an HMAC key has been loaded, it will no longer + be possible to enable metadata modification. Signaling that an + HMAC key has been loaded will clear the corresponding flag. + For example, if the current value is 6 (2 and 4 set):: + + echo 1 >/evm + + will set the new value to 3 (4 cleared). + + Loading an HMAC key is the only way to disable metadata + modification. Until key loading has been signaled EVM can not create or validate the 'security.evm' xattr, but returns -- cgit v1.2.3 From e7a990e00cb13ce66d4008e3b77e8507be0c2e27 Mon Sep 17 00:00:00 2001 From: Rui Miguel Silva Date: Thu, 13 May 2021 09:47:16 +0100 Subject: dt-bindings: usb: nxp,isp1760: add bindings The nxp,isp1760 driver is old in the tree, but did not had a bindings entry, since I am extend it to support isp1763 in the same family, use this to add a proper yaml bindings file. Reviewed-by: Rob Herring Signed-off-by: Rui Miguel Silva Link: https://lore.kernel.org/r/20210513084717.2487366-9-rui.silva@linaro.org Signed-off-by: Greg Kroah-Hartman --- .../devicetree/bindings/usb/nxp,isp1760.yaml | 69 ++++++++++++++++++++++ 1 file changed, 69 insertions(+) create mode 100644 Documentation/devicetree/bindings/usb/nxp,isp1760.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/usb/nxp,isp1760.yaml b/Documentation/devicetree/bindings/usb/nxp,isp1760.yaml new file mode 100644 index 000000000000..a88f99adfe8e --- /dev/null +++ b/Documentation/devicetree/bindings/usb/nxp,isp1760.yaml @@ -0,0 +1,69 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/usb/nxp,isp1760.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NXP ISP1760 family controller bindings + +maintainers: + - Sebastian Siewior + - Laurent Pinchart + +description: | + NXP ISP1760 family, which includes ISP1760/1761/1763 devicetree controller + bindings + +properties: + compatible: + enum: + - nxp,usb-isp1760 + - nxp,usb-isp1761 + - nxp,usb-isp1763 + reg: + maxItems: 1 + + interrupts: + minItems: 1 + maxItems: 2 + items: + - description: Host controller interrupt + - description: Device controller interrupt in isp1761 + + interrupt-names: + minItems: 1 + maxItems: 2 + items: + - const: host + - const: peripheral + + bus-width: + description: + Number of data lines. + enum: [8, 16, 32] + default: 32 + + dr_mode: + enum: + - host + - peripheral + +required: + - compatible + - reg + - interrupts + +additionalProperties: false + +examples: + - | + #include + usb@40200000 { + compatible = "nxp,usb-isp1763"; + reg = <0x40200000 0x100000>; + interrupts = ; + bus-width = <16>; + dr_mode = "host"; + }; + +... -- cgit v1.2.3 From 56d426146cdfa08dc56cda0d0897af4e5090ffcf Mon Sep 17 00:00:00 2001 From: Tobias Schramm Date: Fri, 14 May 2021 17:00:42 +0200 Subject: dt-bindings: usb: dwc2: add compatible for RK3308 USB controller The USB controller in the RK3308 is compatible with the RK3066 USB controller. This patch adds a compatible string for it. Signed-off-by: Tobias Schramm Acked-by: Rob Herring Link: https://lore.kernel.org/r/20210514150044.2099298-4-t.schramm@manjaro.org Signed-off-by: Greg Kroah-Hartman --- Documentation/devicetree/bindings/usb/dwc2.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/usb/dwc2.yaml b/Documentation/devicetree/bindings/usb/dwc2.yaml index e5ee51b7b470..10c7d9b6cc53 100644 --- a/Documentation/devicetree/bindings/usb/dwc2.yaml +++ b/Documentation/devicetree/bindings/usb/dwc2.yaml @@ -24,6 +24,7 @@ properties: - rockchip,rk3188-usb - rockchip,rk3228-usb - rockchip,rk3288-usb + - rockchip,rk3308-usb - rockchip,rk3328-usb - rockchip,rk3368-usb - rockchip,rv1108-usb -- cgit v1.2.3 From 393b06383fb77a006a29eb1574474d468e8c868b Mon Sep 17 00:00:00 2001 From: Greg Kroah-Hartman Date: Fri, 21 May 2021 20:45:19 +0200 Subject: debugfs: remove return value of debugfs_create_bool() No one checks the return value of debugfs_create_bool(), as it's not needed, so make the return value void, so that no one tries to do so in the future. Link: https://lore.kernel.org/r/20210521184519.1356639-1-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman --- Documentation/filesystems/debugfs.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/filesystems/debugfs.rst b/Documentation/filesystems/debugfs.rst index 0f2292e367e6..71b1fee56d2a 100644 --- a/Documentation/filesystems/debugfs.rst +++ b/Documentation/filesystems/debugfs.rst @@ -120,8 +120,8 @@ and hexadecimal:: Boolean values can be placed in debugfs with:: - struct dentry *debugfs_create_bool(const char *name, umode_t mode, - struct dentry *parent, bool *value); + void debugfs_create_bool(const char *name, umode_t mode, + struct dentry *parent, bool *value); A read on the resulting file will yield either Y (for non-zero values) or N, followed by a newline. If written to, it will accept either upper- or -- cgit v1.2.3 From 35c32e3095d396c750f5cdfdaa94cba83d9b23c6 Mon Sep 17 00:00:00 2001 From: Dan Williams Date: Thu, 20 May 2021 12:52:20 -0700 Subject: cxl/docs: Fix "Title underline too short" warning When "Bus" was renamed to "Core" the header underline update was missed. Reported-by: Stephen Rothwell Fixes: 5f653f7590ab ("cxl/core: Rename bus.c to core.c") Reviewed-by: Vishal Verma Link: https://lore.kernel.org/r/162154034053.1995075.17047445540000243300.stgit@dwillia2-desk3.amr.corp.intel.com Signed-off-by: Dan Williams --- Documentation/driver-api/cxl/memory-devices.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/driver-api/cxl/memory-devices.rst b/Documentation/driver-api/cxl/memory-devices.rst index 71495ed77069..73f6b246c583 100644 --- a/Documentation/driver-api/cxl/memory-devices.rst +++ b/Documentation/driver-api/cxl/memory-devices.rst @@ -29,7 +29,7 @@ CXL Memory Device :internal: CXL Core -------- +-------- .. kernel-doc:: drivers/cxl/core.c :doc: cxl core -- cgit v1.2.3 From 11dbc62a73a7da9f3697e8ce83d07503c11dcabb Mon Sep 17 00:00:00 2001 From: Daniel Latypov Date: Wed, 14 Apr 2021 15:22:56 -0700 Subject: Documentation: kunit: add tips for running KUnit This is long overdue. There are several things that aren't nailed down (in-tree .kunitconfig's), or partially broken (GCOV on UML), but having them documented, warts and all, is better than having nothing. This covers a bunch of the more recent features * kunit_filter_glob * kunit.py run --kunitconfig * slightly more detail on building tests as modules * CONFIG_KUNIT_DEBUGFS By my count, the only headline features now not mentioned are the KASAN integration and KernelCI json output support (kunit.py run --json). And then it also discusses how to get code coverage reports under UML and non-UML since this is a question people have repeatedly asked. Non-UML coverage collection is no different from normal, but we should probably explicitly call this out. As for UML, I was able to get it working again with two small hacks.* E.g. with CONFIG_KUNIT=y && CONFIG_KUNIT_ALL_TESTS=y Overall coverage rate: lines......: 15.1% (18294 of 120776 lines) functions..: 16.8% (1860 of 11050 functions) Note: this doesn't document --alltests since this is not stable yet. Hopefully being run more frequently as part of KernelCI will help... *Using gcc/gcov-6 and not using uml_abort() in os_dump_core(). I've documented these hacks in "Notes" but left TODOs for brendanhiggins@google.com who tracked down the runtime issue in GCC. To be clear: these are not issues specific to KUnit, but rather to UML. Signed-off-by: Daniel Latypov Reviewed-by: David Gow Reviewed-by: Brendan Higgins Signed-off-by: Shuah Khan --- Documentation/dev-tools/kunit/index.rst | 1 + Documentation/dev-tools/kunit/running_tips.rst | 259 +++++++++++++++++++++++++ Documentation/dev-tools/kunit/start.rst | 2 + 3 files changed, 262 insertions(+) create mode 100644 Documentation/dev-tools/kunit/running_tips.rst (limited to 'Documentation') diff --git a/Documentation/dev-tools/kunit/index.rst b/Documentation/dev-tools/kunit/index.rst index 848478838347..7f7cf8d2ab20 100644 --- a/Documentation/dev-tools/kunit/index.rst +++ b/Documentation/dev-tools/kunit/index.rst @@ -14,6 +14,7 @@ KUnit - Unit Testing for the Linux Kernel style faq tips + running_tips What is KUnit? ============== diff --git a/Documentation/dev-tools/kunit/running_tips.rst b/Documentation/dev-tools/kunit/running_tips.rst new file mode 100644 index 000000000000..7d99386cf94a --- /dev/null +++ b/Documentation/dev-tools/kunit/running_tips.rst @@ -0,0 +1,259 @@ +.. SPDX-License-Identifier: GPL-2.0 + +============================ +Tips For Running KUnit Tests +============================ + +Using ``kunit.py run`` ("kunit tool") +===================================== + +Running from any directory +-------------------------- + +It can be handy to create a bash function like: + +.. code-block:: bash + + function run_kunit() { + ( cd "$(git rev-parse --show-toplevel)" && ./tools/testing/kunit/kunit.py run $@ ) + } + +.. note:: + Early versions of ``kunit.py`` (before 5.6) didn't work unless run from + the kernel root, hence the use of a subshell and ``cd``. + +Running a subset of tests +------------------------- + +``kunit.py run`` accepts an optional glob argument to filter tests. Currently +this only matches against suite names, but this may change in the future. + +Say that we wanted to run the sysctl tests, we could do so via: + +.. code-block:: bash + + $ echo -e 'CONFIG_KUNIT=y\nCONFIG_KUNIT_ALL_TESTS=y' > .kunit/.kunitconfig + $ ./tools/testing/kunit/kunit.py run 'sysctl*' + +We're paying the cost of building more tests than we need this way, but it's +easier than fiddling with ``.kunitconfig`` files or commenting out +``kunit_suite``'s. + +However, if we wanted to define a set of tests in a less ad hoc way, the next +tip is useful. + +Defining a set of tests +----------------------- + +``kunit.py run`` (along with ``build``, and ``config``) supports a +``--kunitconfig`` flag. So if you have a set of tests that you want to run on a +regular basis (especially if they have other dependencies), you can create a +specific ``.kunitconfig`` for them. + +E.g. kunit has one for its tests: + +.. code-block:: bash + + $ ./tools/testing/kunit/kunit.py run --kunitconfig=lib/kunit/.kunitconfig + +Alternatively, if you're following the convention of naming your +file ``.kunitconfig``, you can just pass in the dir, e.g. + +.. code-block:: bash + + $ ./tools/testing/kunit/kunit.py run --kunitconfig=lib/kunit + +.. note:: + This is a relatively new feature (5.12+) so we don't have any + conventions yet about on what files should be checked in versus just + kept around locally. It's up to you and your maintainer to decide if a + config is useful enough to submit (and therefore have to maintain). + +.. note:: + Having ``.kunitconfig`` fragments in a parent and child directory is + iffy. There's discussion about adding an "import" statement in these + files to make it possible to have a top-level config run tests from all + child directories. But that would mean ``.kunitconfig`` files are no + longer just simple .config fragments. + + One alternative would be to have kunit tool recursively combine configs + automagically, but tests could theoretically depend on incompatible + options, so handling that would be tricky. + +Generating code coverage reports under UML +------------------------------------------ + +.. note:: + TODO(brendanhiggins@google.com): There are various issues with UML and + versions of gcc 7 and up. You're likely to run into missing ``.gcda`` + files or compile errors. We know one `faulty GCC commit + `_ + but not how we'd go about getting this fixed. The compile errors still + need some investigation. + +.. note:: + TODO(brendanhiggins@google.com): for recent versions of Linux + (5.10-5.12, maybe earlier), there's a bug with gcov counters not being + flushed in UML. This translates to very low (<1%) reported coverage. This is + related to the above issue and can be worked around by replacing the + one call to ``uml_abort()`` (it's in ``os_dump_core()``) with a plain + ``exit()``. + + +This is different from the "normal" way of getting coverage information that is +documented in Documentation/dev-tools/gcov.rst. + +Instead of enabling ``CONFIG_GCOV_KERNEL=y``, we can set these options: + +.. code-block:: none + + CONFIG_DEBUG_KERNEL=y + CONFIG_DEBUG_INFO=y + CONFIG_GCOV=y + + +Putting it together into a copy-pastable sequence of commands: + +.. code-block:: bash + + # Append coverage options to the current config + $ echo -e "CONFIG_DEBUG_KERNEL=y\nCONFIG_DEBUG_INFO=y\nCONFIG_GCOV=y" >> .kunit/.kunitconfig + $ ./tools/testing/kunit/kunit.py run + # Extract the coverage information from the build dir (.kunit/) + $ lcov -t "my_kunit_tests" -o coverage.info -c -d .kunit/ + + # From here on, it's the same process as with CONFIG_GCOV_KERNEL=y + # E.g. can generate an HTML report in a tmp dir like so: + $ genhtml -o /tmp/coverage_html coverage.info + + +If your installed version of gcc doesn't work, you can tweak the steps: + +.. code-block:: bash + + $ ./tools/testing/kunit/kunit.py run --make_options=CC=/usr/bin/gcc-6 + $ lcov -t "my_kunit_tests" -o coverage.info -c -d .kunit/ --gcov-tool=/usr/bin/gcov-6 + + +Running tests manually +====================== + +Running tests without using ``kunit.py run`` is also an important use case. +Currently it's your only option if you want to test on architectures other than +UML. + +As running the tests under UML is fairly straightforward (configure and compile +the kernel, run the ``./linux`` binary), this section will focus on testing +non-UML architectures. + + +Running built-in tests +---------------------- + +When setting tests to ``=y``, the tests will run as part of boot and print +results to dmesg in TAP format. So you just need to add your tests to your +``.config``, build and boot your kernel as normal. + +So if we compiled our kernel with: + +.. code-block:: none + + CONFIG_KUNIT=y + CONFIG_KUNIT_EXAMPLE_TEST=y + +Then we'd see output like this in dmesg signaling the test ran and passed: + +.. code-block:: none + + TAP version 14 + 1..1 + # Subtest: example + 1..1 + # example_simple_test: initializing + ok 1 - example_simple_test + ok 1 - example + +Running tests as modules +------------------------ + +Depending on the tests, you can build them as loadable modules. + +For example, we'd change the config options from before to + +.. code-block:: none + + CONFIG_KUNIT=y + CONFIG_KUNIT_EXAMPLE_TEST=m + +Then after booting into our kernel, we can run the test via + +.. code-block:: none + + $ modprobe kunit-example-test + +This will then cause it to print TAP output to stdout. + +.. note:: + The ``modprobe`` will *not* have a non-zero exit code if any test + failed (as of 5.13). But ``kunit.py parse`` would, see below. + +.. note:: + You can set ``CONFIG_KUNIT=m`` as well, however, some features will not + work and thus some tests might break. Ideally tests would specify they + depend on ``KUNIT=y`` in their ``Kconfig``'s, but this is an edge case + most test authors won't think about. + As of 5.13, the only difference is that ``current->kunit_test`` will + not exist. + +Pretty-printing results +----------------------- + +You can use ``kunit.py parse`` to parse dmesg for test output and print out +results in the same familiar format that ``kunit.py run`` does. + +.. code-block:: bash + + $ ./tools/testing/kunit/kunit.py parse /var/log/dmesg + + +Retrieving per suite results +---------------------------- + +Regardless of how you're running your tests, you can enable +``CONFIG_KUNIT_DEBUGFS`` to expose per-suite TAP-formatted results: + +.. code-block:: none + + CONFIG_KUNIT=y + CONFIG_KUNIT_EXAMPLE_TEST=m + CONFIG_KUNIT_DEBUGFS=y + +The results for each suite will be exposed under +``/sys/kernel/debug/kunit//results``. +So using our example config: + +.. code-block:: bash + + $ modprobe kunit-example-test > /dev/null + $ cat /sys/kernel/debug/kunit/example/results + ... ... + + # After removing the module, the corresponding files will go away + $ modprobe -r kunit-example-test + $ cat /sys/kernel/debug/kunit/example/results + /sys/kernel/debug/kunit/example/results: No such file or directory + +Generating code coverage reports +-------------------------------- + +See Documentation/dev-tools/gcov.rst for details on how to do this. + +The only vaguely KUnit-specific advice here is that you probably want to build +your tests as modules. That way you can isolate the coverage from tests from +other code executed during boot, e.g. + +.. code-block:: bash + + # Reset coverage counters before running the test. + $ echo 0 > /sys/kernel/debug/gcov/reset + $ modprobe kunit-example-test diff --git a/Documentation/dev-tools/kunit/start.rst b/Documentation/dev-tools/kunit/start.rst index 0e65cabe08eb..aa56d7ca6bfb 100644 --- a/Documentation/dev-tools/kunit/start.rst +++ b/Documentation/dev-tools/kunit/start.rst @@ -236,5 +236,7 @@ Next Steps ========== * Check out the :doc:`tips` page for tips on writing idiomatic KUnit tests. +* Check out the :doc:`running_tips` page for tips on + how to make running KUnit tests easier. * Optional: see the :doc:`usage` page for a more in-depth explanation of KUnit. -- cgit v1.2.3 From d7eab3df8f39b116d934bc17f8070861e18cfb62 Mon Sep 17 00:00:00 2001 From: David Gow Date: Fri, 16 Apr 2021 20:45:53 -0700 Subject: Documentation: kunit: Update kunit_tool page The kunit_tool documentation page was pretty minimal, and a bit outdated. Update it and flesh it out a bit. In particular, - Mention that .kunitconfig is now in the build directory - Describe the use of --kunitconfig to specify a different config framgent - Mention the split functionality (i.e., commands other than 'run') - Describe --raw_output and kunit.py parse - Mention the globbing support - Provide a quick overview of other options, including --build_dir and --alltests Note that this does overlap a little with the new running_tips page. I don't think it's a problem having both: this page is supposed to be a bit more of a reference, rather than a list of useful tips, so the fact that they both describe the same features isn't a problem. Signed-off-by: David Gow Reviewed-by: Daniel Latypov Signed-off-by: Shuah Khan --- Documentation/dev-tools/kunit/kunit-tool.rst | 140 +++++++++++++++++++++++++-- 1 file changed, 132 insertions(+), 8 deletions(-) (limited to 'Documentation') diff --git a/Documentation/dev-tools/kunit/kunit-tool.rst b/Documentation/dev-tools/kunit/kunit-tool.rst index 29ae2fee8123..4247b7420e3b 100644 --- a/Documentation/dev-tools/kunit/kunit-tool.rst +++ b/Documentation/dev-tools/kunit/kunit-tool.rst @@ -22,14 +22,19 @@ not require any virtualization support: it is just a regular program. What is a .kunitconfig? ======================= -It's just a defconfig that kunit_tool looks for in the base directory. -kunit_tool uses it to generate a .config as you might expect. In addition, it -verifies that the generated .config contains the CONFIG options in the -.kunitconfig; the reason it does this is so that it is easy to be sure that a -CONFIG that enables a test actually ends up in the .config. +It's just a defconfig that kunit_tool looks for in the build directory +(``.kunit`` by default). kunit_tool uses it to generate a .config as you might +expect. In addition, it verifies that the generated .config contains the CONFIG +options in the .kunitconfig; the reason it does this is so that it is easy to +be sure that a CONFIG that enables a test actually ends up in the .config. -How do I use kunit_tool? -======================== +It's also possible to pass a separate .kunitconfig fragment to kunit_tool, +which is useful if you have several different groups of tests you wish +to run independently, or if you want to use pre-defined test configs for +certain subsystems. + +Getting Started with kunit_tool +=============================== If a kunitconfig is present at the root directory, all you have to do is: @@ -48,10 +53,129 @@ However, you most likely want to use it with the following options: .. note:: This command will work even without a .kunitconfig file: if no - .kunitconfig is present, a default one will be used instead. + .kunitconfig is present, a default one will be used instead. + +If you wish to use a different .kunitconfig file (such as one provided for +testing a particular subsystem), you can pass it as an option. + +.. code-block:: bash + + ./tools/testing/kunit/kunit.py run --kunitconfig=fs/ext4/.kunitconfig For a list of all the flags supported by kunit_tool, you can run: .. code-block:: bash ./tools/testing/kunit/kunit.py run --help + +Configuring, Building, and Running Tests +======================================== + +It's also possible to run just parts of the KUnit build process independently, +which is useful if you want to make manual changes to part of the process. + +A .config can be generated from a .kunitconfig by using the ``config`` argument +when running kunit_tool: + +.. code-block:: bash + + ./tools/testing/kunit/kunit.py config + +Similarly, if you just want to build a KUnit kernel from the current .config, +you can use the ``build`` argument: + +.. code-block:: bash + + ./tools/testing/kunit/kunit.py build + +And, if you already have a built UML kernel with built-in KUnit tests, you can +run the kernel and display the test results with the ``exec`` argument: + +.. code-block:: bash + + ./tools/testing/kunit/kunit.py exec + +The ``run`` command which is discussed above is equivalent to running all three +of these in sequence. + +All of these commands accept a number of optional command-line arguments. The +``--help`` flag will give a complete list of these, or keep reading this page +for a guide to some of the more useful ones. + +Parsing Test Results +==================== + +KUnit tests output their results in TAP (Test Anything Protocol) format. +kunit_tool will, when running tests, parse this output and print a summary +which is much more pleasant to read. If you wish to look at the raw test +results in TAP format, you can pass the ``--raw_output`` argument. + +.. code-block:: bash + + ./tools/testing/kunit/kunit.py run --raw_output + +.. note:: + The raw output from test runs may contain other, non-KUnit kernel log + lines. + +If you have KUnit results in their raw TAP format, you can parse them and print +the human-readable summary with the ``parse`` command for kunit_tool. This +accepts a filename for an argument, or will read from standard input. + +.. code-block:: bash + + # Reading from a file + ./tools/testing/kunit/kunit.py parse /var/log/dmesg + # Reading from stdin + dmesg | ./tools/testing/kunit/kunit.py parse + +This is very useful if you wish to run tests in a configuration not supported +by kunit_tool (such as on real hardware, or an unsupported architecture). + +Filtering Tests +=============== + +It's possible to run only a subset of the tests built into a kernel by passing +a filter to the ``exec`` or ``run`` commands. For example, if you only wanted +to run KUnit resource tests, you could use: + +.. code-block:: bash + + ./tools/testing/kunit/kunit.py run 'kunit-resource*' + +This uses the standard glob format for wildcards. + +Other Useful Options +==================== + +kunit_tool has a number of other command-line arguments which can be useful +when adapting it to fit your environment or needs. + +Some of the more useful ones are: + +``--help`` + Lists all of the available options. Note that different commands + (``config``, ``build``, ``run``, etc) will have different supported + options. Place ``--help`` before the command to list common options, + and after the command for options specific to that command. + +``--build_dir`` + Specifies the build directory that kunit_tool will use. This is where + the .kunitconfig file is located, as well as where the .config and + compiled kernel will be placed. Defaults to ``.kunit``. + +``--make_options`` + Specifies additional options to pass to ``make`` when compiling a + kernel (with the ``build`` or ``run`` commands). For example, to enable + compiler warnings, you can pass ``--make_options W=1``. + +``--alltests`` + Builds a UML kernel with all config options enabled using ``make + allyesconfig``. This allows you to run as many tests as is possible, + but is very slow and prone to breakage as new options are added or + modified. In most cases, enabling all tests which have satisfied + dependencies by adding ``CONFIG_KUNIT_ALL_TESTS=1`` to your + .kunitconfig is preferable. + +There are several other options (and new ones are often added), so do check +``--help`` if you're looking for something not mentioned here. -- cgit v1.2.3 From 91cdb2b0e6306253fc50d9da5c1dc0636b395a9b Mon Sep 17 00:00:00 2001 From: Corentin Labbe Date: Wed, 19 May 2021 20:35:45 +0000 Subject: dt-bindings: display: convert faraday,tve200 Converts display/faraday,tve200.txt to yaml. Signed-off-by: Corentin Labbe Reviewed-by: Rob Herring Signed-off-by: Linus Walleij Link: https://patchwork.freedesktop.org/patch/msgid/20210519203547.837237-1-clabbe@baylibre.com --- .../devicetree/bindings/display/faraday,tve200.txt | 54 ----------------- .../bindings/display/faraday,tve200.yaml | 68 ++++++++++++++++++++++ 2 files changed, 68 insertions(+), 54 deletions(-) delete mode 100644 Documentation/devicetree/bindings/display/faraday,tve200.txt create mode 100644 Documentation/devicetree/bindings/display/faraday,tve200.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/faraday,tve200.txt b/Documentation/devicetree/bindings/display/faraday,tve200.txt deleted file mode 100644 index 82e3bc0b7485..000000000000 --- a/Documentation/devicetree/bindings/display/faraday,tve200.txt +++ /dev/null @@ -1,54 +0,0 @@ -* 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>; - }; - }; -}; diff --git a/Documentation/devicetree/bindings/display/faraday,tve200.yaml b/Documentation/devicetree/bindings/display/faraday,tve200.yaml new file mode 100644 index 000000000000..e2ee77767321 --- /dev/null +++ b/Documentation/devicetree/bindings/display/faraday,tve200.yaml @@ -0,0 +1,68 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/faraday,tve200.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Faraday TV Encoder TVE200 + +maintainers: + - Linus Walleij + +properties: + compatible: + oneOf: + - const: faraday,tve200 + - items: + - const: cortina,gemini-tvc + - const: faraday,tve200 + + reg: + maxItems: 1 + + interrupts: + minItems: 1 + + clock-names: + items: + - const: PCLK + - const: TVE + + clocks: + minItems: 2 + + resets: + minItems: 1 + + port: + $ref: /schemas/graph.yaml#/properties/port + +required: + - compatible + - reg + - interrupts + - clock-names + - clocks + +additionalProperties: false + +examples: + - | + #include + #include + #include + display-controller@6a000000 { + 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 { + display_out: endpoint { + remote-endpoint = <&panel_in>; + }; + }; + }; -- cgit v1.2.3 From 7486d6df6179a28c0dc7baf74b122e50d95bab61 Mon Sep 17 00:00:00 2001 From: Dillon Min Date: Tue, 4 May 2021 13:09:50 +0800 Subject: dt-bindings: add dasheng vendor prefix Add vendor prefix for DaSheng, Inc. Signed-off-by: Dillon Min Reviewed-by: Krzysztof Kozlowski Acked-by: Rob Herring Signed-off-by: Shawn Guo --- Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index b868cefc7c55..71ca69ca9142 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -315,6 +315,8 @@ patternProperties: description: DPTechnics "^dragino,.*": description: Dragino Technology Co., Limited + "^ds,.*": + description: DaSheng, Inc. "^dserve,.*": description: dServe Technology B.V. "^dynaimage,.*": -- cgit v1.2.3 From db34eb5cc488457a02f74370f128362d34cf7a8b Mon Sep 17 00:00:00 2001 From: Dillon Min Date: Tue, 4 May 2021 13:09:51 +0800 Subject: dt-bindings: arm: imx: Add i.mx6q DaSheng COM-9XX SBC The DaSheng Com-9xx is and ARM based signle board computer (SBC) featuring: - i.MX6Q - 2GiB LPDDR3 DRAM - 8GiB eMMC 5.0 FLASH - 4MiB SPI Flash - USB 2.0 Host/Device - Multiple multi-protocol RS232/RS485 Serial ports - microSD socket - 5V DC power input - HDMI1.4a,1080p@60 - RGMIIx1 Gigabit Ethernet - CSI0x1, connect with ov2659 Signed-off-by: Dillon Min Reviewed-by: Krzysztof Kozlowski Acked-by: Rob Herring Signed-off-by: Shawn Guo --- Documentation/devicetree/bindings/arm/fsl.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml index eacbc1f8d466..fce2a8670b49 100644 --- a/Documentation/devicetree/bindings/arm/fsl.yaml +++ b/Documentation/devicetree/bindings/arm/fsl.yaml @@ -197,6 +197,7 @@ properties: - boundary,imx6q-nitrogen6x - compulab,cm-fx6 # CompuLab CM-FX6 - dmo,imx6q-edmqmx6 # Data Modul eDM-QMX6 Board + - ds,imx6q-sbc # Da Sheng COM-9XX Modules - embest,imx6q-marsboard # Embest MarS Board i.MX6Dual - emtrion,emcon-mx6 # emCON-MX6D or emCON-MX6Q SoM - emtrion,emcon-mx6-avari # emCON-MX6D or emCON-MX6Q SoM on Avari Base -- cgit v1.2.3 From 7ba861fff0cd3c34ca3401067a95eb12a6a581a6 Mon Sep 17 00:00:00 2001 From: Lucas Stach Date: Mon, 10 May 2021 12:00:40 +0800 Subject: dt-bindings: imx: gpcv2: add support for optional resets For some domains the resets of the devices in the domain are not automatically triggered. Add an optional resets property to allow the GPC driver to trigger those resets explicitly. The resets belong to devices located inside the power domain, which need to be held in reset across the power-up sequence. So we have no means to specify what each reset is in a generic power-domain binding. Same situation as with the clocks in this binding actually. Tested-by: Frieder Schrempf Signed-off-by: Lucas Stach Signed-off-by: Peng Fan Reviewed-by: Rob Herring Signed-off-by: Shawn Guo --- Documentation/devicetree/bindings/power/fsl,imx-gpcv2.yaml | 10 ++++++++++ 1 file changed, 10 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/power/fsl,imx-gpcv2.yaml b/Documentation/devicetree/bindings/power/fsl,imx-gpcv2.yaml index a96e6dbf1858..eb248f24dce6 100644 --- a/Documentation/devicetree/bindings/power/fsl,imx-gpcv2.yaml +++ b/Documentation/devicetree/bindings/power/fsl,imx-gpcv2.yaml @@ -66,6 +66,16 @@ properties: power-supply: true + resets: + description: | + A number of phandles to resets that need to be asserted during + power-up sequencing of the domain. The resets belong to devices + located inside the power domain, which need to be held in reset + across the power-up sequence. So no means to specify what each + reset is in a generic power-domain binding. + minItems: 1 + maxItems: 4 + required: - '#power-domain-cells' - reg -- cgit v1.2.3 From 118f3e1562f2b15e30ed65a2718cd9ed710054b1 Mon Sep 17 00:00:00 2001 From: Ezequiel Garcia Date: Thu, 29 Apr 2021 16:48:09 +0200 Subject: media: uapi: mpeg2: Rename "quantization" to "quantisation" The MPEG-2 specification refers to the quantisation matrices using the word "quantisation". Make the V4L2 interface more ergonomic by matching the MPEG-2 spec. Signed-off-by: Ezequiel Garcia Tested-by: Jernej Skrabec Reviewed-by: Jernej Skrabec Tested-by: Daniel Almeida Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab --- .../userspace-api/media/v4l/ext-ctrls-codec.rst | 16 ++++++++-------- .../userspace-api/media/v4l/pixfmt-compressed.rst | 4 ++-- .../userspace-api/media/v4l/vidioc-queryctrl.rst | 6 +++--- .../userspace-api/media/videodev2.h.rst.exceptions | 2 +- 4 files changed, 14 insertions(+), 14 deletions(-) (limited to 'Documentation') diff --git a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst index 514b334470ea..2835ce739478 100644 --- a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst +++ b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst @@ -1755,8 +1755,8 @@ enum v4l2_mpeg_video_h264_hierarchical_coding_type - \normalsize -``V4L2_CID_MPEG_VIDEO_MPEG2_QUANTIZATION (struct)`` - Specifies quantization matrices (as extracted from the bitstream) for the +``V4L2_CID_MPEG_VIDEO_MPEG2_QUANTISATION (struct)`` + Specifies quantisation matrices (as extracted from the bitstream) for the associated MPEG-2 slice data. .. note:: @@ -1764,7 +1764,7 @@ enum v4l2_mpeg_video_h264_hierarchical_coding_type - This compound control is not yet part of the public kernel API and it is expected to change. -.. c:type:: v4l2_ctrl_mpeg2_quantization +.. c:type:: v4l2_ctrl_mpeg2_quantisation .. tabularcolumns:: |p{0.8cm}|p{8.0cm}|p{8.5cm}| @@ -1774,7 +1774,7 @@ enum v4l2_mpeg_video_h264_hierarchical_coding_type - \small -.. flat-table:: struct v4l2_ctrl_mpeg2_quantization +.. flat-table:: struct v4l2_ctrl_mpeg2_quantisation :header-rows: 0 :stub-columns: 0 :widths: 1 1 2 @@ -1798,24 +1798,24 @@ enum v4l2_mpeg_video_h264_hierarchical_coding_type - YUV formats. * - __u8 - ``intra_quantiser_matrix[64]`` - - The quantization matrix coefficients for intra-coded frames, in zigzag + - The quantisation matrix coefficients for intra-coded frames, in zigzag scanning order. It is relevant for both luma and chroma components, although it can be superseded by the chroma-specific matrix for non-4:2:0 YUV formats. * - __u8 - ``non_intra_quantiser_matrix[64]`` - - The quantization matrix coefficients for non-intra-coded frames, in + - The quantisation matrix coefficients for non-intra-coded frames, in zigzag scanning order. It is relevant for both luma and chroma components, although it can be superseded by the chroma-specific matrix for non-4:2:0 YUV formats. * - __u8 - ``chroma_intra_quantiser_matrix[64]`` - - The quantization matrix coefficients for the chominance component of + - The quantisation matrix coefficients for the chominance component of intra-coded frames, in zigzag scanning order. Only relevant for non-4:2:0 YUV formats. * - __u8 - ``chroma_non_intra_quantiser_matrix[64]`` - - The quantization matrix coefficients for the chrominance component of + - The quantisation matrix coefficients for the chrominance component of non-intra-coded frames, in zigzag scanning order. Only relevant for non-4:2:0 YUV formats. diff --git a/Documentation/userspace-api/media/v4l/pixfmt-compressed.rst b/Documentation/userspace-api/media/v4l/pixfmt-compressed.rst index 6dba70da822b..cba607f789f0 100644 --- a/Documentation/userspace-api/media/v4l/pixfmt-compressed.rst +++ b/Documentation/userspace-api/media/v4l/pixfmt-compressed.rst @@ -115,8 +115,8 @@ Compressed Formats MPEG-2 pipeline (using the :ref:`mem2mem` and :ref:`media-request-api`). Metadata associated with the frame to decode is required to be passed through the ``V4L2_CID_MPEG_VIDEO_MPEG2_SLICE_PARAMS`` control and - quantization matrices can optionally be specified through the - ``V4L2_CID_MPEG_VIDEO_MPEG2_QUANTIZATION`` control. + quantisation matrices can optionally be specified through the + ``V4L2_CID_MPEG_VIDEO_MPEG2_QUANTISATION`` control. See the :ref:`associated Codec Control IDs `. Exactly one output and one capture buffer must be provided for use with this pixel format. The output buffer must contain the appropriate number diff --git a/Documentation/userspace-api/media/v4l/vidioc-queryctrl.rst b/Documentation/userspace-api/media/v4l/vidioc-queryctrl.rst index 8a285daedc6a..4362945fd39b 100644 --- a/Documentation/userspace-api/media/v4l/vidioc-queryctrl.rst +++ b/Documentation/userspace-api/media/v4l/vidioc-queryctrl.rst @@ -423,12 +423,12 @@ See also the examples in :ref:`control`. - n/a - A struct :c:type:`v4l2_ctrl_mpeg2_slice_params`, containing MPEG-2 slice parameters for stateless video decoders. - * - ``V4L2_CTRL_TYPE_MPEG2_QUANTIZATION`` + * - ``V4L2_CTRL_TYPE_MPEG2_QUANTISATION`` - n/a - n/a - n/a - - A struct :c:type:`v4l2_ctrl_mpeg2_quantization`, containing MPEG-2 - quantization matrices for stateless video decoders. + - A struct :c:type:`v4l2_ctrl_mpeg2_quantisation`, containing MPEG-2 + quantisation matrices for stateless video decoders. * - ``V4L2_CTRL_TYPE_AREA`` - n/a - n/a diff --git a/Documentation/userspace-api/media/videodev2.h.rst.exceptions b/Documentation/userspace-api/media/videodev2.h.rst.exceptions index f59940352faa..5b2ebaa35d24 100644 --- a/Documentation/userspace-api/media/videodev2.h.rst.exceptions +++ b/Documentation/userspace-api/media/videodev2.h.rst.exceptions @@ -135,7 +135,7 @@ replace symbol V4L2_CTRL_TYPE_U16 :c:type:`v4l2_ctrl_type` replace symbol V4L2_CTRL_TYPE_U32 :c:type:`v4l2_ctrl_type` replace symbol V4L2_CTRL_TYPE_U8 :c:type:`v4l2_ctrl_type` replace symbol V4L2_CTRL_TYPE_MPEG2_SLICE_PARAMS :c:type:`v4l2_ctrl_type` -replace symbol V4L2_CTRL_TYPE_MPEG2_QUANTIZATION :c:type:`v4l2_ctrl_type` +replace symbol V4L2_CTRL_TYPE_MPEG2_QUANTISATION :c:type:`v4l2_ctrl_type` replace symbol V4L2_CTRL_TYPE_H264_SPS :c:type:`v4l2_ctrl_type` replace symbol V4L2_CTRL_TYPE_H264_PPS :c:type:`v4l2_ctrl_type` replace symbol V4L2_CTRL_TYPE_H264_SCALING_MATRIX :c:type:`v4l2_ctrl_type` -- cgit v1.2.3 From 81bbb65f19819440b42270e1f033d9b14279540c Mon Sep 17 00:00:00 2001 From: Ezequiel Garcia Date: Thu, 29 Apr 2021 16:48:10 +0200 Subject: media: uapi: mpeg2: rework quantisation matrices semantics As stated in the MPEG-2 specification, section 6.3.7 "Quant matrix extension": Each quantisation matrix has a default set of values. When a sequence_header_code is decoded all matrices shall be reset to their default values. User defined matrices may be downloaded and this can occur in a sequence_header() or in a quant_matrix_extension(). The load_intra_quantiser_matrix syntax elements are transmitted in the bitstream headers, signalling that a quantisation matrix needs to be loaded and used for pictures transmitted afterwards (until the matrices are reset). This "load" semantics are implemented in the V4L2 interface without the need of any "load" flags: passing the control is effectively a load. Therefore, rework the V4L2_CID_MPEG_VIDEO_MPEG2_QUANTISATION semantics to match the MPEG-2 semantics. Quantisation matrices values are now initialized by the V4L2 control core to their reset default value, and applications are expected to reset their values as specified. The quantisation control is therefore optional, and used to load bitstream-defined values in the quantisation matrices. Signed-off-by: Ezequiel Garcia Co-developed-by: Nicolas Dufresne Signed-off-by: Nicolas Dufresne Tested-by: Jernej Skrabec Reviewed-by: Jernej Skrabec Tested-by: Daniel Almeida Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab --- .../userspace-api/media/v4l/ext-ctrls-codec.rst | 17 ----------------- 1 file changed, 17 deletions(-) (limited to 'Documentation') diff --git a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst index 2835ce739478..bfbc5fda9f9b 100644 --- a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst +++ b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst @@ -1779,23 +1779,6 @@ enum v4l2_mpeg_video_h264_hierarchical_coding_type - :stub-columns: 0 :widths: 1 1 2 - * - __u8 - - ``load_intra_quantiser_matrix`` - - One bit to indicate whether to load the ``intra_quantiser_matrix`` data. - * - __u8 - - ``load_non_intra_quantiser_matrix`` - - One bit to indicate whether to load the ``non_intra_quantiser_matrix`` - data. - * - __u8 - - ``load_chroma_intra_quantiser_matrix`` - - One bit to indicate whether to load the - ``chroma_intra_quantiser_matrix`` data, only relevant for non-4:2:0 YUV - formats. - * - __u8 - - ``load_chroma_non_intra_quantiser_matrix`` - - One bit to indicate whether to load the - ``chroma_non_intra_quantiser_matrix`` data, only relevant for non-4:2:0 - YUV formats. * - __u8 - ``intra_quantiser_matrix[64]`` - The quantisation matrix coefficients for intra-coded frames, in zigzag -- cgit v1.2.3 From 88e78409a83a579fde7f150be7ebeefab0e1f774 Mon Sep 17 00:00:00 2001 From: Ezequiel Garcia Date: Thu, 29 Apr 2021 16:48:11 +0200 Subject: media: uapi: mpeg2: Cleanup flags Our current MPEG-2 uAPI uses 1-byte fields for MPEG-2 boolean syntax elements. Clean these by adding a 'flags' field and flag macro for each boolean syntax element. A follow-up change will refactor this uAPI so we don't need to add padding fields just yet. Signed-off-by: Ezequiel Garcia Tested-by: Jonas Karlman Tested-by: Jernej Skrabec Reviewed-by: Jernej Skrabec Tested-by: Daniel Almeida Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab --- .../userspace-api/media/v4l/ext-ctrls-codec.rst | 77 +++++++++++++++------- 1 file changed, 54 insertions(+), 23 deletions(-) (limited to 'Documentation') diff --git a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst index bfbc5fda9f9b..aa11346e7e27 100644 --- a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst +++ b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst @@ -1687,13 +1687,28 @@ enum v4l2_mpeg_video_h264_hierarchical_coding_type - - ``profile_and_level_indication`` - The current profile and level indication as extracted from the bitstream. - * - __u8 - - ``progressive_sequence`` - - Indication that all the frames for the sequence are progressive instead - of interlaced. * - __u8 - ``chroma_format`` - The chrominance sub-sampling format (1: 4:2:0, 2: 4:2:2, 3: 4:4:4). + * - __u32 + - ``flags`` + - See :ref:`MPEG-2 Sequence Flags `. + +.. _mpeg2_sequence_flags: + +``MPEG-2 Sequence Flags`` + +.. cssclass:: longtable + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + :widths: 1 1 2 + + * - ``V4L2_MPEG2_SEQ_FLAG_PROGRESSIVE`` + - 0x00000001 + - Indication that all the frames for the sequence are progressive instead + of interlaced. .. c:type:: v4l2_mpeg2_picture @@ -1726,29 +1741,45 @@ enum v4l2_mpeg_video_h264_hierarchical_coding_type - - ``picture_structure`` - Picture structure (1: interlaced top field, 2: interlaced bottom field, 3: progressive frame). - * - __u8 - - ``top_field_first`` - - If set to 1 and interlaced stream, top field is output first. - * - __u8 - - ``frame_pred_frame_dct`` - - If set to 1, only frame-DCT and frame prediction are used. - * - __u8 - - ``concealment_motion_vectors`` - - If set to 1, motion vectors are coded for intra macroblocks. - * - __u8 - - ``q_scale_type`` + * - __u32 + - ``flags`` + - See :ref:`MPEG-2 Picture Flags `. + + +.. _mpeg2_picture_flags: + +``MPEG-2 Picture Flags`` + +.. cssclass:: longtable + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + :widths: 1 1 2 + + * - ``V4L2_MPEG2_PIC_FLAG_TOP_FIELD_FIRST`` + - 0x00000001 + - If set and it's an interlaced stream, top field is output first. + * - ``V4L2_MPEG2_PIC_FLAG_FRAME_PRED_DCT`` + - 0x00000002 + - If set only frame-DCT and frame prediction are used. + * - ``V4L2_MPEG2_PIC_FLAG_CONCEALMENT_MV`` + - 0x00000004 + - If set motion vectors are coded for intra macroblocks. + * - ``V4L2_MPEG2_PIC_FLAG_Q_SCALE_TYPE`` + - 0x00000008 - This flag affects the inverse quantization process. - * - __u8 - - ``intra_vlc_format`` + * - ``V4L2_MPEG2_PIC_FLAG_INTRA_VLC`` + - 0x00000010 - This flag affects the decoding of transform coefficient data. - * - __u8 - - ``alternate_scan`` + * - ``V4L2_MPEG2_PIC_FLAG_ALT_SCAN`` + - 0x00000020 - This flag affects the decoding of transform coefficient data. - * - __u8 - - ``repeat_first_field`` + * - ``V4L2_MPEG2_PIC_FLAG_REPEAT_FIRST`` + - 0x00000040 - This flag affects the decoding process of progressive frames. - * - __u16 - - ``progressive_frame`` + * - ``V4L2_MPEG2_PIC_FLAG_PROGRESSIVE`` + - 0x00000080 - Indicates whether the current frame is progressive. .. raw:: latex -- cgit v1.2.3 From f329e21e9dadc5c8ee37c781b30fe63bf7217201 Mon Sep 17 00:00:00 2001 From: Ezequiel Garcia Date: Thu, 29 Apr 2021 16:48:12 +0200 Subject: media: uapi: mpeg2: Split sequence and picture parameters Typically, bitstreams are composed of a sequence header, followed by a number of picture header and picture coding extension headers. Each picture can be composed of a number of slices. Let's split the MPEG-2 uAPI to follow these semantics more closely, allowing more usage flexibility. Having these controls split up allows applications to set a sequence control at the beginning of a sequence, and then set a picture control for each frame. While here add padding fields where needed, and document the uAPI header thoroughly. Note that the V4L2_CTRL_TYPE_{} defines had to be moved because it clashes with existing ones. This is not really an issue since they will be re-defined when the controls are moved out of staging. Signed-off-by: Ezequiel Garcia Tested-by: Jonas Karlman Tested-by: Jernej Skrabec Reviewed-by: Jernej Skrabec Tested-by: Daniel Almeida Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab --- .../userspace-api/media/v4l/ext-ctrls-codec.rst | 64 ++++++++++++++-------- .../userspace-api/media/v4l/pixfmt-compressed.rst | 5 +- .../userspace-api/media/v4l/vidioc-queryctrl.rst | 12 ++++ .../userspace-api/media/videodev2.h.rst.exceptions | 2 + 4 files changed, 59 insertions(+), 24 deletions(-) (limited to 'Documentation') diff --git a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst index aa11346e7e27..f96a2dcb22cc 100644 --- a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst +++ b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst @@ -1636,14 +1636,6 @@ enum v4l2_mpeg_video_h264_hierarchical_coding_type - * - __u32 - ``data_bit_offset`` - Offset (in bits) to the video data in the current slice data. - * - struct :c:type:`v4l2_mpeg2_sequence` - - ``sequence`` - - Structure with MPEG-2 sequence metadata, merging relevant fields from - the sequence header and sequence extension parts of the bitstream. - * - struct :c:type:`v4l2_mpeg2_picture` - - ``picture`` - - Structure with MPEG-2 picture metadata, merging relevant fields from - the picture header and picture coding extension parts of the bitstream. * - __u64 - ``backward_ref_ts`` - Timestamp of the V4L2 capture buffer to use as backward reference, used @@ -1661,14 +1653,28 @@ enum v4l2_mpeg_video_h264_hierarchical_coding_type - * - __u32 - ``quantiser_scale_code`` - Code used to determine the quantization scale to use for the IDCT. + * - __u8 + - ``reserved`` + - Applications and drivers must set this to zero. -.. c:type:: v4l2_mpeg2_sequence +``V4L2_CID_MPEG_VIDEO_MPEG2_SEQUENCE (struct)`` + Specifies the sequence parameters (as extracted from the bitstream) for the + associated MPEG-2 slice data. This includes fields matching the syntax + elements from the sequence header and sequence extension parts of the + bitstream as specified by :ref:`mpeg2part2`. + + .. note:: + + This compound control is not yet part of the public kernel API and + it is expected to change. + +.. c:type:: v4l2_ctrl_mpeg2_sequence .. cssclass:: longtable .. tabularcolumns:: |p{1.4cm}|p{6.5cm}|p{9.4cm}| -.. flat-table:: struct v4l2_mpeg2_sequence +.. flat-table:: struct v4l2_ctrl_mpeg2_sequence :header-rows: 0 :stub-columns: 0 :widths: 1 1 2 @@ -1690,7 +1696,7 @@ enum v4l2_mpeg_video_h264_hierarchical_coding_type - * - __u8 - ``chroma_format`` - The chrominance sub-sampling format (1: 4:2:0, 2: 4:2:2, 3: 4:4:4). - * - __u32 + * - __u8 - ``flags`` - See :ref:`MPEG-2 Sequence Flags `. @@ -1706,11 +1712,22 @@ enum v4l2_mpeg_video_h264_hierarchical_coding_type - :widths: 1 1 2 * - ``V4L2_MPEG2_SEQ_FLAG_PROGRESSIVE`` - - 0x00000001 + - 0x01 - Indication that all the frames for the sequence are progressive instead of interlaced. -.. c:type:: v4l2_mpeg2_picture +``V4L2_CID_MPEG_VIDEO_MPEG2_PICTURE (struct)`` + Specifies the picture parameters (as extracted from the bitstream) for the + associated MPEG-2 slice data. This includes fields matching the syntax + elements from the picture header and picture coding extension parts of the + bitstream as specified by :ref:`mpeg2part2`. + + .. note:: + + This compound control is not yet part of the public kernel API and + it is expected to change. + +.. c:type:: v4l2_ctrl_mpeg2_picture .. raw:: latex @@ -1720,30 +1737,33 @@ enum v4l2_mpeg_video_h264_hierarchical_coding_type - .. tabularcolumns:: |p{1.0cm}|p{5.6cm}|p{10.7cm}| -.. flat-table:: struct v4l2_mpeg2_picture +.. flat-table:: struct v4l2_ctrl_mpeg2_picture :header-rows: 0 :stub-columns: 0 :widths: 1 1 2 + * - __u32 + - ``flags`` + - See :ref:`MPEG-2 Picture Flags `. + * - __u8 + - ``f_code[2][2]`` + - Motion vector codes. * - __u8 - ``picture_coding_type`` - Picture coding type for the frame covered by the current slice (V4L2_MPEG2_PICTURE_CODING_TYPE_I, V4L2_MPEG2_PICTURE_CODING_TYPE_P or V4L2_MPEG2_PICTURE_CODING_TYPE_B). * - __u8 - - ``f_code[2][2]`` - - Motion vector codes. + - ``picture_structure`` + - Picture structure (1: interlaced top field, 2: interlaced bottom field, + 3: progressive frame). * - __u8 - ``intra_dc_precision`` - Precision of Discrete Cosine transform (0: 8 bits precision, 1: 9 bits precision, 2: 10 bits precision, 3: 11 bits precision). * - __u8 - - ``picture_structure`` - - Picture structure (1: interlaced top field, 2: interlaced bottom field, - 3: progressive frame). - * - __u32 - - ``flags`` - - See :ref:`MPEG-2 Picture Flags `. + - ``reserved[5]`` + - Applications and drivers must set this to zero. .. _mpeg2_picture_flags: diff --git a/Documentation/userspace-api/media/v4l/pixfmt-compressed.rst b/Documentation/userspace-api/media/v4l/pixfmt-compressed.rst index cba607f789f0..bbbacbd65d6f 100644 --- a/Documentation/userspace-api/media/v4l/pixfmt-compressed.rst +++ b/Documentation/userspace-api/media/v4l/pixfmt-compressed.rst @@ -114,8 +114,9 @@ Compressed Formats This format is adapted for stateless video decoders that implement a MPEG-2 pipeline (using the :ref:`mem2mem` and :ref:`media-request-api`). Metadata associated with the frame to decode is required to be passed - through the ``V4L2_CID_MPEG_VIDEO_MPEG2_SLICE_PARAMS`` control and - quantisation matrices can optionally be specified through the + through the ``V4L2_CID_MPEG_VIDEO_MPEG2_SEQUENCE``, + ``V4L2_CID_MPEG_VIDEO_MPEG2_PICTURE``, and ``V4L2_CID_MPEG_VIDEO_MPEG2_SLICE_PARAMS`` + controls. Quantisation matrices can optionally be specified through the ``V4L2_CID_MPEG_VIDEO_MPEG2_QUANTISATION`` control. See the :ref:`associated Codec Control IDs `. Exactly one output and one capture buffer must be provided for use with diff --git a/Documentation/userspace-api/media/v4l/vidioc-queryctrl.rst b/Documentation/userspace-api/media/v4l/vidioc-queryctrl.rst index 4362945fd39b..afc1505a3a7e 100644 --- a/Documentation/userspace-api/media/v4l/vidioc-queryctrl.rst +++ b/Documentation/userspace-api/media/v4l/vidioc-queryctrl.rst @@ -429,6 +429,18 @@ See also the examples in :ref:`control`. - n/a - A struct :c:type:`v4l2_ctrl_mpeg2_quantisation`, containing MPEG-2 quantisation matrices for stateless video decoders. + * - ``V4L2_CTRL_TYPE_MPEG2_SEQUENCE`` + - n/a + - n/a + - n/a + - A struct :c:type:`v4l2_ctrl_mpeg2_sequence`, containing MPEG-2 + sequence parameters for stateless video decoders. + * - ``V4L2_CTRL_TYPE_MPEG2_PICTURE`` + - n/a + - n/a + - n/a + - A struct :c:type:`v4l2_ctrl_mpeg2_picture`, containing MPEG-2 + picture parameters for stateless video decoders. * - ``V4L2_CTRL_TYPE_AREA`` - n/a - n/a diff --git a/Documentation/userspace-api/media/videodev2.h.rst.exceptions b/Documentation/userspace-api/media/videodev2.h.rst.exceptions index 5b2ebaa35d24..928fdc419ee3 100644 --- a/Documentation/userspace-api/media/videodev2.h.rst.exceptions +++ b/Documentation/userspace-api/media/videodev2.h.rst.exceptions @@ -134,6 +134,8 @@ replace symbol V4L2_CTRL_TYPE_STRING :c:type:`v4l2_ctrl_type` replace symbol V4L2_CTRL_TYPE_U16 :c:type:`v4l2_ctrl_type` replace symbol V4L2_CTRL_TYPE_U32 :c:type:`v4l2_ctrl_type` replace symbol V4L2_CTRL_TYPE_U8 :c:type:`v4l2_ctrl_type` +replace symbol V4L2_CTRL_TYPE_MPEG2_SEQUENCE :c:type:`v4l2_ctrl_type` +replace symbol V4L2_CTRL_TYPE_MPEG2_PICTURE :c:type:`v4l2_ctrl_type` replace symbol V4L2_CTRL_TYPE_MPEG2_SLICE_PARAMS :c:type:`v4l2_ctrl_type` replace symbol V4L2_CTRL_TYPE_MPEG2_QUANTISATION :c:type:`v4l2_ctrl_type` replace symbol V4L2_CTRL_TYPE_H264_SPS :c:type:`v4l2_ctrl_type` -- cgit v1.2.3 From b6d7e8031c9c17462935329ca8b37f0da2f99da0 Mon Sep 17 00:00:00 2001 From: Ezequiel Garcia Date: Thu, 29 Apr 2021 16:48:13 +0200 Subject: media: uapi: mpeg2: Move reference buffer fields The forward and backwards references are specified per-picture and not per-slice. Move it to V4L2_CID_MPEG_VIDEO_MPEG2_PICTURE. Signed-off-by: Ezequiel Garcia Tested-by: Jernej Skrabec Reviewed-by: Jernej Skrabec Tested-by: Daniel Almeida Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab --- .../userspace-api/media/v4l/ext-ctrls-codec.rst | 28 +++++++++++----------- 1 file changed, 14 insertions(+), 14 deletions(-) (limited to 'Documentation') diff --git a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst index f96a2dcb22cc..1765b2a1129d 100644 --- a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst +++ b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst @@ -1636,20 +1636,6 @@ enum v4l2_mpeg_video_h264_hierarchical_coding_type - * - __u32 - ``data_bit_offset`` - Offset (in bits) to the video data in the current slice data. - * - __u64 - - ``backward_ref_ts`` - - Timestamp of the V4L2 capture buffer to use as backward reference, used - with B-coded and P-coded frames. The timestamp refers to the - ``timestamp`` field in struct :c:type:`v4l2_buffer`. Use the - :c:func:`v4l2_timeval_to_ns()` function to convert the struct - :c:type:`timeval` in struct :c:type:`v4l2_buffer` to a __u64. - * - __u64 - - ``forward_ref_ts`` - - Timestamp for the V4L2 capture buffer to use as forward reference, used - with B-coded frames. The timestamp refers to the ``timestamp`` field in - struct :c:type:`v4l2_buffer`. Use the :c:func:`v4l2_timeval_to_ns()` - function to convert the struct :c:type:`timeval` in struct - :c:type:`v4l2_buffer` to a __u64. * - __u32 - ``quantiser_scale_code`` - Code used to determine the quantization scale to use for the IDCT. @@ -1742,6 +1728,20 @@ enum v4l2_mpeg_video_h264_hierarchical_coding_type - :stub-columns: 0 :widths: 1 1 2 + * - __u64 + - ``backward_ref_ts`` + - Timestamp of the V4L2 capture buffer to use as backward reference, used + with B-coded and P-coded frames. The timestamp refers to the + ``timestamp`` field in struct :c:type:`v4l2_buffer`. Use the + :c:func:`v4l2_timeval_to_ns()` function to convert the struct + :c:type:`timeval` in struct :c:type:`v4l2_buffer` to a __u64. + * - __u64 + - ``forward_ref_ts`` + - Timestamp for the V4L2 capture buffer to use as forward reference, used + with B-coded frames. The timestamp refers to the ``timestamp`` field in + struct :c:type:`v4l2_buffer`. Use the :c:func:`v4l2_timeval_to_ns()` + function to convert the struct :c:type:`timeval` in struct + :c:type:`v4l2_buffer` to a __u64. * - __u32 - ``flags`` - See :ref:`MPEG-2 Picture Flags `. -- cgit v1.2.3 From 45f97ba1ce8059632c6f1518fda1faedd7db55fb Mon Sep 17 00:00:00 2001 From: Ezequiel Garcia Date: Thu, 29 Apr 2021 16:48:15 +0200 Subject: media: uapi: mpeg2: Remove V4L2_CID_MPEG_VIDEO_MPEG2_SLICE_PARAMS The Hantro and Cedrus drivers work in frame-mode, meaning they expect all the slices in a picture (either frame or field structure) to be passed in each OUTPUT buffer. These two are the only V4L2 MPEG-2 stateless decoders currently supported. Given the VA-API drivers also work per-frame, coalescing all the MPEG-2 slices in a buffer before the decoding operation, it makes sense to not expect slice-mode drivers and therefore remove V4L2_CID_MPEG_VIDEO_MPEG2_SLICE_PARAMS. This is done to avoid carrying an unused interface. If needed, this control can be added without breaking backwards compatibility. Note that this would mean introducing a enumerator control to specify the decoding mode (see V4L2_CID_STATELESS_H264_DECODE_MODE). Signed-off-by: Ezequiel Garcia Co-developed-by: Nicolas Dufresne Signed-off-by: Nicolas Dufresne Tested-by: Jernej Skrabec Reviewed-by: Jernej Skrabec Tested-by: Daniel Almeida Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab --- .../userspace-api/media/v4l/ext-ctrls-codec.rst | 35 ---------------------- .../userspace-api/media/v4l/pixfmt-compressed.rst | 6 ++-- .../userspace-api/media/v4l/vidioc-queryctrl.rst | 6 ---- .../userspace-api/media/videodev2.h.rst.exceptions | 1 - 4 files changed, 3 insertions(+), 45 deletions(-) (limited to 'Documentation') diff --git a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst index 1765b2a1129d..f10b04fba229 100644 --- a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst +++ b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst @@ -1608,41 +1608,6 @@ enum v4l2_mpeg_video_h264_hierarchical_coding_type - .. _v4l2-mpeg-mpeg2: -``V4L2_CID_MPEG_VIDEO_MPEG2_SLICE_PARAMS (struct)`` - Specifies the slice parameters (as extracted from the bitstream) for the - associated MPEG-2 slice data. This includes the necessary parameters for - configuring a stateless hardware decoding pipeline for MPEG-2. - The bitstream parameters are defined according to :ref:`mpeg2part2`. - - .. note:: - - This compound control is not yet part of the public kernel API and - it is expected to change. - -.. c:type:: v4l2_ctrl_mpeg2_slice_params - -.. tabularcolumns:: |p{5.6cm}|p{4.6cm}|p{7.1cm}| - -.. cssclass:: longtable - -.. flat-table:: struct v4l2_ctrl_mpeg2_slice_params - :header-rows: 0 - :stub-columns: 0 - :widths: 1 1 2 - - * - __u32 - - ``bit_size`` - - Size (in bits) of the current slice data. - * - __u32 - - ``data_bit_offset`` - - Offset (in bits) to the video data in the current slice data. - * - __u32 - - ``quantiser_scale_code`` - - Code used to determine the quantization scale to use for the IDCT. - * - __u8 - - ``reserved`` - - Applications and drivers must set this to zero. - ``V4L2_CID_MPEG_VIDEO_MPEG2_SEQUENCE (struct)`` Specifies the sequence parameters (as extracted from the bitstream) for the associated MPEG-2 slice data. This includes fields matching the syntax diff --git a/Documentation/userspace-api/media/v4l/pixfmt-compressed.rst b/Documentation/userspace-api/media/v4l/pixfmt-compressed.rst index bbbacbd65d6f..6c10a062adac 100644 --- a/Documentation/userspace-api/media/v4l/pixfmt-compressed.rst +++ b/Documentation/userspace-api/media/v4l/pixfmt-compressed.rst @@ -114,9 +114,9 @@ Compressed Formats This format is adapted for stateless video decoders that implement a MPEG-2 pipeline (using the :ref:`mem2mem` and :ref:`media-request-api`). Metadata associated with the frame to decode is required to be passed - through the ``V4L2_CID_MPEG_VIDEO_MPEG2_SEQUENCE``, - ``V4L2_CID_MPEG_VIDEO_MPEG2_PICTURE``, and ``V4L2_CID_MPEG_VIDEO_MPEG2_SLICE_PARAMS`` - controls. Quantisation matrices can optionally be specified through the + through the ``V4L2_CID_MPEG_VIDEO_MPEG2_SEQUENCE`` and + ``V4L2_CID_MPEG_VIDEO_MPEG2_PICTURE`` controls. + Quantisation matrices can optionally be specified through the ``V4L2_CID_MPEG_VIDEO_MPEG2_QUANTISATION`` control. See the :ref:`associated Codec Control IDs `. Exactly one output and one capture buffer must be provided for use with diff --git a/Documentation/userspace-api/media/v4l/vidioc-queryctrl.rst b/Documentation/userspace-api/media/v4l/vidioc-queryctrl.rst index afc1505a3a7e..07e54029e1e9 100644 --- a/Documentation/userspace-api/media/v4l/vidioc-queryctrl.rst +++ b/Documentation/userspace-api/media/v4l/vidioc-queryctrl.rst @@ -417,12 +417,6 @@ See also the examples in :ref:`control`. - any - An unsigned 32-bit valued control ranging from minimum to maximum inclusive. The step value indicates the increment between values. - * - ``V4L2_CTRL_TYPE_MPEG2_SLICE_PARAMS`` - - n/a - - n/a - - n/a - - A struct :c:type:`v4l2_ctrl_mpeg2_slice_params`, containing MPEG-2 - slice parameters for stateless video decoders. * - ``V4L2_CTRL_TYPE_MPEG2_QUANTISATION`` - n/a - n/a diff --git a/Documentation/userspace-api/media/videodev2.h.rst.exceptions b/Documentation/userspace-api/media/videodev2.h.rst.exceptions index 928fdc419ee3..2217b56c2686 100644 --- a/Documentation/userspace-api/media/videodev2.h.rst.exceptions +++ b/Documentation/userspace-api/media/videodev2.h.rst.exceptions @@ -136,7 +136,6 @@ replace symbol V4L2_CTRL_TYPE_U32 :c:type:`v4l2_ctrl_type` replace symbol V4L2_CTRL_TYPE_U8 :c:type:`v4l2_ctrl_type` replace symbol V4L2_CTRL_TYPE_MPEG2_SEQUENCE :c:type:`v4l2_ctrl_type` replace symbol V4L2_CTRL_TYPE_MPEG2_PICTURE :c:type:`v4l2_ctrl_type` -replace symbol V4L2_CTRL_TYPE_MPEG2_SLICE_PARAMS :c:type:`v4l2_ctrl_type` replace symbol V4L2_CTRL_TYPE_MPEG2_QUANTISATION :c:type:`v4l2_ctrl_type` replace symbol V4L2_CTRL_TYPE_H264_SPS :c:type:`v4l2_ctrl_type` replace symbol V4L2_CTRL_TYPE_H264_PPS :c:type:`v4l2_ctrl_type` -- cgit v1.2.3 From f4815b399111d992c1118c708f464a847dfd29e2 Mon Sep 17 00:00:00 2001 From: Ezequiel Garcia Date: Thu, 29 Apr 2021 16:48:18 +0200 Subject: media: uapi: move MPEG-2 stateless controls out of staging Until now, the MPEG-2 V4L2 API was not exported as a public API, and only defined in a private media header (media/mpeg2-ctrls.h). After reviewing the MPEG-2 specification in detail, and reworking the controls so they match the MPEG-2 semantics properly, we can consider it ready. Signed-off-by: Ezequiel Garcia Tested-by: Jernej Skrabec Reviewed-by: Jernej Skrabec Tested-by: Daniel Almeida Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab --- .../media/v4l/ext-ctrls-codec-stateless.rst | 214 ++++++++++++++++++++ .../userspace-api/media/v4l/ext-ctrls-codec.rst | 216 --------------------- .../userspace-api/media/v4l/pixfmt-compressed.rst | 10 +- .../userspace-api/media/v4l/vidioc-g-ext-ctrls.rst | 12 ++ 4 files changed, 231 insertions(+), 221 deletions(-) (limited to 'Documentation') diff --git a/Documentation/userspace-api/media/v4l/ext-ctrls-codec-stateless.rst b/Documentation/userspace-api/media/v4l/ext-ctrls-codec-stateless.rst index 3fc04daa9ffb..2aa508ffb6b9 100644 --- a/Documentation/userspace-api/media/v4l/ext-ctrls-codec-stateless.rst +++ b/Documentation/userspace-api/media/v4l/ext-ctrls-codec-stateless.rst @@ -1244,3 +1244,217 @@ FWHT Flags * - __u8 - ``padding[3]`` - Applications and drivers must set this to zero. + +.. _v4l2-codec-stateless-mpeg2: + +``V4L2_CID_STATELESS_MPEG2_SEQUENCE (struct)`` + Specifies the sequence parameters (as extracted from the bitstream) for the + associated MPEG-2 slice data. This includes fields matching the syntax + elements from the sequence header and sequence extension parts of the + bitstream as specified by :ref:`mpeg2part2`. + +.. c:type:: v4l2_ctrl_mpeg2_sequence + +.. raw:: latex + + \small + +.. cssclass:: longtable + +.. tabularcolumns:: |p{1.4cm}|p{6.5cm}|p{9.4cm}| + +.. flat-table:: struct v4l2_ctrl_mpeg2_sequence + :header-rows: 0 + :stub-columns: 0 + :widths: 1 1 2 + + * - __u16 + - ``horizontal_size`` + - The width of the displayable part of the frame's luminance component. + * - __u16 + - ``vertical_size`` + - The height of the displayable part of the frame's luminance component. + * - __u32 + - ``vbv_buffer_size`` + - Used to calculate the required size of the video buffering verifier, + defined (in bits) as: 16 * 1024 * vbv_buffer_size. + * - __u16 + - ``profile_and_level_indication`` + - The current profile and level indication as extracted from the + bitstream. + * - __u8 + - ``chroma_format`` + - The chrominance sub-sampling format (1: 4:2:0, 2: 4:2:2, 3: 4:4:4). + * - __u8 + - ``flags`` + - See :ref:`MPEG-2 Sequence Flags `. + +.. _mpeg2_sequence_flags: + +``MPEG-2 Sequence Flags`` + +.. cssclass:: longtable + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + :widths: 1 1 2 + + * - ``V4L2_MPEG2_SEQ_FLAG_PROGRESSIVE`` + - 0x01 + - Indication that all the frames for the sequence are progressive instead + of interlaced. + +.. raw:: latex + + \normalsize + +``V4L2_CID_STATELESS_MPEG2_PICTURE (struct)`` + Specifies the picture parameters (as extracted from the bitstream) for the + associated MPEG-2 slice data. This includes fields matching the syntax + elements from the picture header and picture coding extension parts of the + bitstream as specified by :ref:`mpeg2part2`. + +.. c:type:: v4l2_ctrl_mpeg2_picture + +.. raw:: latex + + \small + +.. cssclass:: longtable + +.. tabularcolumns:: |p{1.0cm}|p{5.6cm}|p{10.7cm}| + +.. flat-table:: struct v4l2_ctrl_mpeg2_picture + :header-rows: 0 + :stub-columns: 0 + :widths: 1 1 2 + + * - __u64 + - ``backward_ref_ts`` + - Timestamp of the V4L2 capture buffer to use as backward reference, used + with B-coded and P-coded frames. The timestamp refers to the + ``timestamp`` field in struct :c:type:`v4l2_buffer`. Use the + :c:func:`v4l2_timeval_to_ns()` function to convert the struct + :c:type:`timeval` in struct :c:type:`v4l2_buffer` to a __u64. + * - __u64 + - ``forward_ref_ts`` + - Timestamp for the V4L2 capture buffer to use as forward reference, used + with B-coded frames. The timestamp refers to the ``timestamp`` field in + struct :c:type:`v4l2_buffer`. Use the :c:func:`v4l2_timeval_to_ns()` + function to convert the struct :c:type:`timeval` in struct + :c:type:`v4l2_buffer` to a __u64. + * - __u32 + - ``flags`` + - See :ref:`MPEG-2 Picture Flags `. + * - __u8 + - ``f_code[2][2]`` + - Motion vector codes. + * - __u8 + - ``picture_coding_type`` + - Picture coding type for the frame covered by the current slice + (V4L2_MPEG2_PICTURE_CODING_TYPE_I, V4L2_MPEG2_PICTURE_CODING_TYPE_P or + V4L2_MPEG2_PICTURE_CODING_TYPE_B). + * - __u8 + - ``picture_structure`` + - Picture structure (1: interlaced top field, 2: interlaced bottom field, + 3: progressive frame). + * - __u8 + - ``intra_dc_precision`` + - Precision of Discrete Cosine transform (0: 8 bits precision, + 1: 9 bits precision, 2: 10 bits precision, 3: 11 bits precision). + * - __u8 + - ``reserved[5]`` + - Applications and drivers must set this to zero. + +.. _mpeg2_picture_flags: + +``MPEG-2 Picture Flags`` + +.. cssclass:: longtable + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + :widths: 1 1 2 + + * - ``V4L2_MPEG2_PIC_FLAG_TOP_FIELD_FIRST`` + - 0x00000001 + - If set and it's an interlaced stream, top field is output first. + * - ``V4L2_MPEG2_PIC_FLAG_FRAME_PRED_DCT`` + - 0x00000002 + - If set only frame-DCT and frame prediction are used. + * - ``V4L2_MPEG2_PIC_FLAG_CONCEALMENT_MV`` + - 0x00000004 + - If set motion vectors are coded for intra macroblocks. + * - ``V4L2_MPEG2_PIC_FLAG_Q_SCALE_TYPE`` + - 0x00000008 + - This flag affects the inverse quantization process. + * - ``V4L2_MPEG2_PIC_FLAG_INTRA_VLC`` + - 0x00000010 + - This flag affects the decoding of transform coefficient data. + * - ``V4L2_MPEG2_PIC_FLAG_ALT_SCAN`` + - 0x00000020 + - This flag affects the decoding of transform coefficient data. + * - ``V4L2_MPEG2_PIC_FLAG_REPEAT_FIRST`` + - 0x00000040 + - This flag affects the decoding process of progressive frames. + * - ``V4L2_MPEG2_PIC_FLAG_PROGRESSIVE`` + - 0x00000080 + - Indicates whether the current frame is progressive. + +.. raw:: latex + + \normalsize + +``V4L2_CID_STATELESS_MPEG2_QUANTISATION (struct)`` + Specifies quantisation matrices, in zigzag scanning order, for the + associated MPEG-2 slice data. This control is initialized by the kernel + to the matrices default values. If a bitstream transmits a user-defined + quantisation matrices load, applications are expected to use this control. + Applications are also expected to set the control loading the default + values, if the quantisation matrices need to be reset, for instance on a + sequence header. This process is specified by section 6.3.7. + "Quant matrix extension" of the specification. + +.. c:type:: v4l2_ctrl_mpeg2_quantisation + +.. tabularcolumns:: |p{0.8cm}|p{8.0cm}|p{8.5cm}| + +.. cssclass:: longtable + +.. raw:: latex + + \small + +.. flat-table:: struct v4l2_ctrl_mpeg2_quantisation + :header-rows: 0 + :stub-columns: 0 + :widths: 1 1 2 + + * - __u8 + - ``intra_quantiser_matrix[64]`` + - The quantisation matrix coefficients for intra-coded frames, in zigzag + scanning order. It is relevant for both luma and chroma components, + although it can be superseded by the chroma-specific matrix for + non-4:2:0 YUV formats. + * - __u8 + - ``non_intra_quantiser_matrix[64]`` + - The quantisation matrix coefficients for non-intra-coded frames, in + zigzag scanning order. It is relevant for both luma and chroma + components, although it can be superseded by the chroma-specific matrix + for non-4:2:0 YUV formats. + * - __u8 + - ``chroma_intra_quantiser_matrix[64]`` + - The quantisation matrix coefficients for the chominance component of + intra-coded frames, in zigzag scanning order. Only relevant for + non-4:2:0 YUV formats. + * - __u8 + - ``chroma_non_intra_quantiser_matrix[64]`` + - The quantisation matrix coefficients for the chrominance component of + non-intra-coded frames, in zigzag scanning order. Only relevant for + non-4:2:0 YUV formats. + +.. raw:: latex + + \normalsize diff --git a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst index f10b04fba229..0b8061666c57 100644 --- a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst +++ b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst @@ -1606,222 +1606,6 @@ enum v4l2_mpeg_video_h264_hierarchical_coding_type - ``V4L2_CID_MPEG_VIDEO_H264_HIER_CODING_L6_BR (integer)`` Indicates bit rate (bps) for hierarchical coding layer 6 for H264 encoder. -.. _v4l2-mpeg-mpeg2: - -``V4L2_CID_MPEG_VIDEO_MPEG2_SEQUENCE (struct)`` - Specifies the sequence parameters (as extracted from the bitstream) for the - associated MPEG-2 slice data. This includes fields matching the syntax - elements from the sequence header and sequence extension parts of the - bitstream as specified by :ref:`mpeg2part2`. - - .. note:: - - This compound control is not yet part of the public kernel API and - it is expected to change. - -.. c:type:: v4l2_ctrl_mpeg2_sequence - -.. cssclass:: longtable - -.. tabularcolumns:: |p{1.4cm}|p{6.5cm}|p{9.4cm}| - -.. flat-table:: struct v4l2_ctrl_mpeg2_sequence - :header-rows: 0 - :stub-columns: 0 - :widths: 1 1 2 - - * - __u16 - - ``horizontal_size`` - - The width of the displayable part of the frame's luminance component. - * - __u16 - - ``vertical_size`` - - The height of the displayable part of the frame's luminance component. - * - __u32 - - ``vbv_buffer_size`` - - Used to calculate the required size of the video buffering verifier, - defined (in bits) as: 16 * 1024 * vbv_buffer_size. - * - __u16 - - ``profile_and_level_indication`` - - The current profile and level indication as extracted from the - bitstream. - * - __u8 - - ``chroma_format`` - - The chrominance sub-sampling format (1: 4:2:0, 2: 4:2:2, 3: 4:4:4). - * - __u8 - - ``flags`` - - See :ref:`MPEG-2 Sequence Flags `. - -.. _mpeg2_sequence_flags: - -``MPEG-2 Sequence Flags`` - -.. cssclass:: longtable - -.. flat-table:: - :header-rows: 0 - :stub-columns: 0 - :widths: 1 1 2 - - * - ``V4L2_MPEG2_SEQ_FLAG_PROGRESSIVE`` - - 0x01 - - Indication that all the frames for the sequence are progressive instead - of interlaced. - -``V4L2_CID_MPEG_VIDEO_MPEG2_PICTURE (struct)`` - Specifies the picture parameters (as extracted from the bitstream) for the - associated MPEG-2 slice data. This includes fields matching the syntax - elements from the picture header and picture coding extension parts of the - bitstream as specified by :ref:`mpeg2part2`. - - .. note:: - - This compound control is not yet part of the public kernel API and - it is expected to change. - -.. c:type:: v4l2_ctrl_mpeg2_picture - -.. raw:: latex - - \small - -.. cssclass:: longtable - -.. tabularcolumns:: |p{1.0cm}|p{5.6cm}|p{10.7cm}| - -.. flat-table:: struct v4l2_ctrl_mpeg2_picture - :header-rows: 0 - :stub-columns: 0 - :widths: 1 1 2 - - * - __u64 - - ``backward_ref_ts`` - - Timestamp of the V4L2 capture buffer to use as backward reference, used - with B-coded and P-coded frames. The timestamp refers to the - ``timestamp`` field in struct :c:type:`v4l2_buffer`. Use the - :c:func:`v4l2_timeval_to_ns()` function to convert the struct - :c:type:`timeval` in struct :c:type:`v4l2_buffer` to a __u64. - * - __u64 - - ``forward_ref_ts`` - - Timestamp for the V4L2 capture buffer to use as forward reference, used - with B-coded frames. The timestamp refers to the ``timestamp`` field in - struct :c:type:`v4l2_buffer`. Use the :c:func:`v4l2_timeval_to_ns()` - function to convert the struct :c:type:`timeval` in struct - :c:type:`v4l2_buffer` to a __u64. - * - __u32 - - ``flags`` - - See :ref:`MPEG-2 Picture Flags `. - * - __u8 - - ``f_code[2][2]`` - - Motion vector codes. - * - __u8 - - ``picture_coding_type`` - - Picture coding type for the frame covered by the current slice - (V4L2_MPEG2_PICTURE_CODING_TYPE_I, V4L2_MPEG2_PICTURE_CODING_TYPE_P or - V4L2_MPEG2_PICTURE_CODING_TYPE_B). - * - __u8 - - ``picture_structure`` - - Picture structure (1: interlaced top field, 2: interlaced bottom field, - 3: progressive frame). - * - __u8 - - ``intra_dc_precision`` - - Precision of Discrete Cosine transform (0: 8 bits precision, - 1: 9 bits precision, 2: 10 bits precision, 3: 11 bits precision). - * - __u8 - - ``reserved[5]`` - - Applications and drivers must set this to zero. - - -.. _mpeg2_picture_flags: - -``MPEG-2 Picture Flags`` - -.. cssclass:: longtable - -.. flat-table:: - :header-rows: 0 - :stub-columns: 0 - :widths: 1 1 2 - - * - ``V4L2_MPEG2_PIC_FLAG_TOP_FIELD_FIRST`` - - 0x00000001 - - If set and it's an interlaced stream, top field is output first. - * - ``V4L2_MPEG2_PIC_FLAG_FRAME_PRED_DCT`` - - 0x00000002 - - If set only frame-DCT and frame prediction are used. - * - ``V4L2_MPEG2_PIC_FLAG_CONCEALMENT_MV`` - - 0x00000004 - - If set motion vectors are coded for intra macroblocks. - * - ``V4L2_MPEG2_PIC_FLAG_Q_SCALE_TYPE`` - - 0x00000008 - - This flag affects the inverse quantization process. - * - ``V4L2_MPEG2_PIC_FLAG_INTRA_VLC`` - - 0x00000010 - - This flag affects the decoding of transform coefficient data. - * - ``V4L2_MPEG2_PIC_FLAG_ALT_SCAN`` - - 0x00000020 - - This flag affects the decoding of transform coefficient data. - * - ``V4L2_MPEG2_PIC_FLAG_REPEAT_FIRST`` - - 0x00000040 - - This flag affects the decoding process of progressive frames. - * - ``V4L2_MPEG2_PIC_FLAG_PROGRESSIVE`` - - 0x00000080 - - Indicates whether the current frame is progressive. - -.. raw:: latex - - \normalsize - -``V4L2_CID_MPEG_VIDEO_MPEG2_QUANTISATION (struct)`` - Specifies quantisation matrices (as extracted from the bitstream) for the - associated MPEG-2 slice data. - - .. note:: - - This compound control is not yet part of the public kernel API and - it is expected to change. - -.. c:type:: v4l2_ctrl_mpeg2_quantisation - -.. tabularcolumns:: |p{0.8cm}|p{8.0cm}|p{8.5cm}| - -.. cssclass:: longtable - -.. raw:: latex - - \small - -.. flat-table:: struct v4l2_ctrl_mpeg2_quantisation - :header-rows: 0 - :stub-columns: 0 - :widths: 1 1 2 - - * - __u8 - - ``intra_quantiser_matrix[64]`` - - The quantisation matrix coefficients for intra-coded frames, in zigzag - scanning order. It is relevant for both luma and chroma components, - although it can be superseded by the chroma-specific matrix for - non-4:2:0 YUV formats. - * - __u8 - - ``non_intra_quantiser_matrix[64]`` - - The quantisation matrix coefficients for non-intra-coded frames, in - zigzag scanning order. It is relevant for both luma and chroma - components, although it can be superseded by the chroma-specific matrix - for non-4:2:0 YUV formats. - * - __u8 - - ``chroma_intra_quantiser_matrix[64]`` - - The quantisation matrix coefficients for the chominance component of - intra-coded frames, in zigzag scanning order. Only relevant for - non-4:2:0 YUV formats. - * - __u8 - - ``chroma_non_intra_quantiser_matrix[64]`` - - The quantisation matrix coefficients for the chrominance component of - non-intra-coded frames, in zigzag scanning order. Only relevant for - non-4:2:0 YUV formats. - -.. raw:: latex - - \normalsize - ``V4L2_CID_FWHT_I_FRAME_QP (integer)`` Quantization parameter for an I frame for FWHT. Valid range: from 1 to 31. diff --git a/Documentation/userspace-api/media/v4l/pixfmt-compressed.rst b/Documentation/userspace-api/media/v4l/pixfmt-compressed.rst index 6c10a062adac..0ede39907ee2 100644 --- a/Documentation/userspace-api/media/v4l/pixfmt-compressed.rst +++ b/Documentation/userspace-api/media/v4l/pixfmt-compressed.rst @@ -112,13 +112,13 @@ Compressed Formats - 'MG2S' - MPEG-2 parsed slice data, as extracted from the MPEG-2 bitstream. This format is adapted for stateless video decoders that implement a - MPEG-2 pipeline (using the :ref:`mem2mem` and :ref:`media-request-api`). + MPEG-2 pipeline with the :ref:`stateless_decoder`. Metadata associated with the frame to decode is required to be passed - through the ``V4L2_CID_MPEG_VIDEO_MPEG2_SEQUENCE`` and - ``V4L2_CID_MPEG_VIDEO_MPEG2_PICTURE`` controls. + through the ``V4L2_CID_STATELESS_MPEG2_SEQUENCE`` and + ``V4L2_CID_STATELESS_MPEG2_PICTURE`` controls. Quantisation matrices can optionally be specified through the - ``V4L2_CID_MPEG_VIDEO_MPEG2_QUANTISATION`` control. - See the :ref:`associated Codec Control IDs `. + ``V4L2_CID_STATELESS_MPEG2_QUANTISATION`` control. + See the :ref:`associated Codec Control IDs `. Exactly one output and one capture buffer must be provided for use with this pixel format. The output buffer must contain the appropriate number of macroblocks to decode a full corresponding frame to the matching diff --git a/Documentation/userspace-api/media/v4l/vidioc-g-ext-ctrls.rst b/Documentation/userspace-api/media/v4l/vidioc-g-ext-ctrls.rst index 3ba22983d21f..2d6bc8d94380 100644 --- a/Documentation/userspace-api/media/v4l/vidioc-g-ext-ctrls.rst +++ b/Documentation/userspace-api/media/v4l/vidioc-g-ext-ctrls.rst @@ -221,6 +221,18 @@ still cause this situation. - ``p_vp8_frame`` - A pointer to a struct :c:type:`v4l2_ctrl_vp8_frame`. Valid if this control is of type ``V4L2_CTRL_TYPE_VP8_FRAME``. + * - struct :c:type:`v4l2_ctrl_mpeg2_sequence` * + - ``p_mpeg2_sequence`` + - A pointer to a struct :c:type:`v4l2_ctrl_mpeg2_sequence`. Valid if this control is + of type ``V4L2_CTRL_TYPE_MPEG2_SEQUENCE``. + * - struct :c:type:`v4l2_ctrl_mpeg2_picture` * + - ``p_mpeg2_picture`` + - A pointer to a struct :c:type:`v4l2_ctrl_mpeg2_picture`. Valid if this control is + of type ``V4L2_CTRL_TYPE_MPEG2_PICTURE``. + * - struct :c:type:`v4l2_ctrl_mpeg2_quantisation` * + - ``p_mpeg2_quantisation`` + - A pointer to a struct :c:type:`v4l2_ctrl_mpeg2_quantisation`. Valid if this control is + of type ``V4L2_CTRL_TYPE_MPEG2_QUANTISATION``. * - struct :c:type:`v4l2_ctrl_hdr10_cll_info` * - ``p_hdr10_cll`` - A pointer to a struct :c:type:`v4l2_ctrl_hdr10_cll_info`. Valid if this control is -- cgit v1.2.3 From 85b62ff2cb971c53a9a0cfafd31b07a92bb0fa19 Mon Sep 17 00:00:00 2001 From: Laurent Pinchart Date: Sun, 18 Apr 2021 22:15:56 +0200 Subject: media: dt-bindings: media: nxp,imx7-mipi-csi2: Add i.MX8MM support The i.MX8MM integrates a newer version of the CSIS CSI-2 receiver as the i.MX7 family. Differences in integration are are: - An additional clock is required - Up to 4 data lanes are supported - No reset or PHY supply is present Support it in the DT binding. Signed-off-by: Laurent Pinchart Acked-by: Rui Miguel Silva Reviewed-by: Rob Herring Signed-off-by: Mauro Carvalho Chehab --- .../bindings/media/nxp,imx7-mipi-csi2.yaml | 109 ++++++++++++++++++--- 1 file changed, 95 insertions(+), 14 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/media/nxp,imx7-mipi-csi2.yaml b/Documentation/devicetree/bindings/media/nxp,imx7-mipi-csi2.yaml index d8ed480482b9..7c09eec78ce5 100644 --- a/Documentation/devicetree/bindings/media/nxp,imx7-mipi-csi2.yaml +++ b/Documentation/devicetree/bindings/media/nxp,imx7-mipi-csi2.yaml @@ -4,15 +4,17 @@ $id: http://devicetree.org/schemas/media/nxp,imx7-mipi-csi2.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# -title: NXP i.MX7 MIPI CSI-2 receiver +title: NXP i.MX7 and i.MX8 MIPI CSI-2 receiver maintainers: - Rui Miguel Silva + - Laurent Pinchart description: |- - The NXP i.MX7 SoC family includes a MIPI CSI-2 receiver IP core, documented - as "CSIS V3.3". The IP core seems to originate from Samsung, and may be - compatible with some of the Exynos4 ad S5P SoCs. + The NXP i.MX7 and i.MX8 families contain SoCs that include a MIPI CSI-2 + receiver IP core named CSIS. The IP core originates from Samsung, and may be + compatible with some of the Exynos4 and S5P SoCs. i.MX7 SoCs use CSIS version + 3.3, and i.MX8 SoCs use CSIS version 3.6.3. While the CSI-2 receiver is separate from the MIPI D-PHY IP core, the PHY is completely wrapped by the CSIS and doesn't expose a control interface of its @@ -20,7 +22,9 @@ description: |- properties: compatible: - const: fsl,imx7-mipi-csi2 + enum: + - fsl,imx7-mipi-csi2 + - fsl,imx8mm-mipi-csi2 reg: maxItems: 1 @@ -29,16 +33,20 @@ properties: maxItems: 1 clocks: + minItems: 3 items: - description: The peripheral clock (a.k.a. APB clock) - description: The external clock (optionally used as the pixel clock) - description: The MIPI D-PHY clock + - description: The AXI clock clock-names: + minItems: 3 items: - const: pclk - const: wrap - const: phy + - const: axi power-domains: maxItems: 1 @@ -71,16 +79,30 @@ properties: properties: data-lanes: - oneOf: - - items: - - const: 1 - - items: - - const: 1 - - const: 2 + items: + minItems: 1 + maxItems: 4 + items: + - const: 1 + - const: 2 + - const: 3 + - const: 4 required: - data-lanes + allOf: + - if: + properties: + compatible: + contains: + const: fsl,imx7-mipi-csi2 + then: + properties: + data-lanes: + items: + maxItems: 2 + port@1: $ref: /schemas/graph.yaml#/properties/port description: @@ -93,12 +115,29 @@ required: - clocks - clock-names - power-domains - - phy-supply - - resets - ports additionalProperties: false +allOf: + - if: + properties: + compatible: + contains: + const: fsl,imx7-mipi-csi2 + then: + required: + - phy-supply + - resets + else: + properties: + clocks: + minItems: 4 + clock-names: + minItems: 4 + phy-supply: false + resets: false + examples: - | #include @@ -106,7 +145,7 @@ examples: #include #include - mipi_csi: mipi-csi@30750000 { + mipi-csi@30750000 { compatible = "fsl,imx7-mipi-csi2"; reg = <0x30750000 0x10000>; interrupts = ; @@ -144,4 +183,46 @@ examples: }; }; + - | + #include + #include + #include + + mipi-csi@32e30000 { + compatible = "fsl,imx8mm-mipi-csi2"; + reg = <0x32e30000 0x1000>; + interrupts = ; + clock-frequency = <333000000>; + clocks = <&clk IMX8MM_CLK_DISP_APB_ROOT>, + <&clk IMX8MM_CLK_CSI1_ROOT>, + <&clk IMX8MM_CLK_CSI1_PHY_REF>, + <&clk IMX8MM_CLK_DISP_AXI_ROOT>; + clock-names = "pclk", "wrap", "phy", "axi"; + power-domains = <&mipi_pd>; + + status = "disabled"; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + + imx8mm_mipi_csi_in: endpoint { + remote-endpoint = <&imx477_out>; + data-lanes = <1 2 3 4>; + }; + }; + + port@1 { + reg = <1>; + + imx8mm_mipi_csi_out: endpoint { + remote-endpoint = <&csi_in>; + }; + }; + }; + }; + ... -- cgit v1.2.3 From 17c2d247ddd231199e682b0a7fda42fe46c2c07b Mon Sep 17 00:00:00 2001 From: Kuninori Morimoto Date: Mon, 24 May 2021 15:12:04 +0900 Subject: ASoC: dt-bindings: renesas: rsnd: tidyup properties 1) resets/reset-names needs minItems 2) It can use ports, not only port 3) It is not using audio-graph properties Without this patch, we will get warnings Signed-off-by: Kuninori Morimoto Link: https://lore.kernel.org/r/87wnrooe2z.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/sound/renesas,rsnd.yaml | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/renesas,rsnd.yaml b/Documentation/devicetree/bindings/sound/renesas,rsnd.yaml index 605de3a5847f..ee936d1aa724 100644 --- a/Documentation/devicetree/bindings/sound/renesas,rsnd.yaml +++ b/Documentation/devicetree/bindings/sound/renesas,rsnd.yaml @@ -86,9 +86,11 @@ properties: power-domains: true resets: + minItems: 1 maxItems: 11 reset-names: + minItems: 1 maxItems: 11 clocks: @@ -110,6 +112,13 @@ properties: - pattern: '^dvc\.[0-1]$' - pattern: '^clk_(a|b|c|i)$' + ports: + $ref: /schemas/graph.yaml#/properties/ports + properties: + port(@[0-9a-f]+)?: + $ref: audio-graph-port.yaml# + unevaluatedProperties: false + port: $ref: audio-graph-port.yaml# unevaluatedProperties: false @@ -257,7 +266,6 @@ required: - "#sound-dai-cells" allOf: - - $ref: audio-graph.yaml# - if: properties: compatible: -- cgit v1.2.3 From 17ba36b704692a433d38cb230e99ec333ecd14a2 Mon Sep 17 00:00:00 2001 From: Stephan Gerhold Date: Thu, 13 May 2021 12:41:28 +0200 Subject: ASoC: dt-bindings: codecs: Add bindings for nxp, tfa989x NXP/Goodix TFA989X (TFA1) amplifiers are controlled via an I2C bus. Add simple device tree bindings that describe how to set them up in the device tree. Right now only nxp,tfa9895 is supported but this will be extended to at least nxp,tfa9897 in the near future. Signed-off-by: Stephan Gerhold Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20210513104129.36583-1-stephan@gerhold.net Signed-off-by: Mark Brown --- .../devicetree/bindings/sound/nxp,tfa989x.yaml | 54 ++++++++++++++++++++++ 1 file changed, 54 insertions(+) create mode 100644 Documentation/devicetree/bindings/sound/nxp,tfa989x.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/nxp,tfa989x.yaml b/Documentation/devicetree/bindings/sound/nxp,tfa989x.yaml new file mode 100644 index 000000000000..45db5776550c --- /dev/null +++ b/Documentation/devicetree/bindings/sound/nxp,tfa989x.yaml @@ -0,0 +1,54 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/nxp,tfa989x.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NXP/Goodix TFA989X (TFA1) Audio Amplifiers + +maintainers: + - Stephan Gerhold + +properties: + compatible: + enum: + - nxp,tfa9895 + + reg: + maxItems: 1 + + '#sound-dai-cells': + const: 0 + + sound-name-prefix: + $ref: /schemas/types.yaml#/definitions/string + description: + Used as prefix for sink/source names of the component. Must be a + unique string among multiple instances of the same component. + +required: + - compatible + - reg + - '#sound-dai-cells' + +additionalProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + audio-codec@34 { + compatible = "nxp,tfa9895"; + reg = <0x34>; + sound-name-prefix = "Speaker Left"; + #sound-dai-cells = <0>; + }; + audio-codec@36 { + compatible = "nxp,tfa9895"; + reg = <0x36>; + sound-name-prefix = "Speaker Right"; + #sound-dai-cells = <0>; + }; + }; -- cgit v1.2.3 From 082152aacd04069fe050be4706e57263fee64336 Mon Sep 17 00:00:00 2001 From: Mateusz Kwiatkowski Date: Thu, 20 May 2021 17:03:42 +0200 Subject: dt-bindings: display: bcm2835-vec: Add BCM2711 compatible The BCM2711 VEC uses a slightly different, incompatible, setup than the one used for the earlier SoC. Add a new compatible for it. Signed-off-by: Mateusz Kwiatkowski Signed-off-by: Maxime Ripard Acked-by: Dave Stevenson Link: https://patchwork.freedesktop.org/patch/msgid/20210520150344.273900-3-maxime@cerno.tech --- Documentation/devicetree/bindings/display/brcm,bcm2835-vec.yaml | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/brcm,bcm2835-vec.yaml b/Documentation/devicetree/bindings/display/brcm,bcm2835-vec.yaml index d900cc57b4ec..9b24081a0dbd 100644 --- a/Documentation/devicetree/bindings/display/brcm,bcm2835-vec.yaml +++ b/Documentation/devicetree/bindings/display/brcm,bcm2835-vec.yaml @@ -11,7 +11,9 @@ maintainers: properties: compatible: - const: brcm,bcm2835-vec + enum: + - brcm,bcm2711-vec + - brcm,bcm2835-vec reg: maxItems: 1 -- cgit v1.2.3 From 51fd43e2801054b1321b1d81b91dc37efdff5127 Mon Sep 17 00:00:00 2001 From: "zhangyi (F)" Date: Sat, 13 Mar 2021 11:01:46 +0800 Subject: block_dump: remove comments in docs Now block_dump feature is gone, remove all comments in docs. Signed-off-by: zhangyi (F) Reviewed-by: Jan Kara Reviewed-by: Christoph Hellwig Link: https://lore.kernel.org/r/20210313030146.2882027-4-yi.zhang@huawei.com Signed-off-by: Jens Axboe --- Documentation/admin-guide/laptops/laptop-mode.rst | 11 ----------- Documentation/admin-guide/sysctl/vm.rst | 8 -------- 2 files changed, 19 deletions(-) (limited to 'Documentation') diff --git a/Documentation/admin-guide/laptops/laptop-mode.rst b/Documentation/admin-guide/laptops/laptop-mode.rst index c984c4262f2e..b61cc601d298 100644 --- a/Documentation/admin-guide/laptops/laptop-mode.rst +++ b/Documentation/admin-guide/laptops/laptop-mode.rst @@ -101,17 +101,6 @@ this results in concentration of disk activity in a small time interval which occurs only once every 10 minutes, or whenever the disk is forced to spin up by a cache miss. The disk can then be spun down in the periods of inactivity. -If you want to find out which process caused the disk to spin up, you can -gather information by setting the flag /proc/sys/vm/block_dump. When this flag -is set, Linux reports all disk read and write operations that take place, and -all block dirtyings done to files. This makes it possible to debug why a disk -needs to spin up, and to increase battery life even more. The output of -block_dump is written to the kernel output, and it can be retrieved using -"dmesg". When you use block_dump and your kernel logging level also includes -kernel debugging messages, you probably want to turn off klogd, otherwise -the output of block_dump will be logged, causing disk activity that is not -normally there. - Configuration ------------- diff --git a/Documentation/admin-guide/sysctl/vm.rst b/Documentation/admin-guide/sysctl/vm.rst index 586cd4b86428..3ca6679f16ea 100644 --- a/Documentation/admin-guide/sysctl/vm.rst +++ b/Documentation/admin-guide/sysctl/vm.rst @@ -25,7 +25,6 @@ files can be found in mm/swap.c. Currently, these files are in /proc/sys/vm: - admin_reserve_kbytes -- block_dump - compact_memory - compaction_proactiveness - compact_unevictable_allowed @@ -106,13 +105,6 @@ On x86_64 this is about 128MB. Changing this takes effect whenever an application requests memory. -block_dump -========== - -block_dump enables block I/O debugging when set to a nonzero value. More -information on block I/O debugging is in Documentation/admin-guide/laptops/laptop-mode.rst. - - compact_memory ============== -- cgit v1.2.3 From f765e349c3e1f2e676ad4bd61197216b26976022 Mon Sep 17 00:00:00 2001 From: Sebastian Reichel Date: Thu, 29 Apr 2021 00:29:49 +0200 Subject: rtc: m41t80: add support for fixed clock Congatec's QMX6 system on module (SoM) uses a m41t62 as RTC. The modules SQW clock output defaults to 32768 Hz. This behaviour is used to provide the i.MX6 CKIL clock. Once the RTC driver is probed, the clock is disabled and all i.MX6 functionality depending on the 32 KHz clock has undefined behaviour. For example when using the hardware watchdog the system will likely do arbitrary reboots. Referencing the m41t62 directly results in a deadlock. The kernel will see, that i.MX6 system clock needs the RTC clock and do probe deferral. But the i.MX6 I2C module never becomes usable without the i.MX6 CKIL clock and thus the RTC's clock will not be probed. So from the kernel's perspective this is a chicken-and-egg problem. Technically everything is fine by not touching anything, since the RTC clock correctly enables the clock on reset (i.e. on battery backup power loss) and also the bootloader enables it in case an something (e.g. an unpatched kernel) disabled this incorrectly. A workaround for this issue is describing the square wave pin as fixed-clock, which is registered early and basically how this pin is used on the i.MX6. Suggested-by: Saravana Kannan Signed-off-by: Sebastian Reichel Reviewed-by: Saravana Kannan Reviewed-by: Rob Herring Signed-off-by: Alexandre Belloni Link: https://lore.kernel.org/r/20210428222953.235280-2-sebastian.reichel@collabora.com --- Documentation/devicetree/bindings/rtc/rtc-m41t80.txt | 9 +++++++++ 1 file changed, 9 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/rtc/rtc-m41t80.txt b/Documentation/devicetree/bindings/rtc/rtc-m41t80.txt index c746cb221210..cdd196b1e9bd 100644 --- a/Documentation/devicetree/bindings/rtc/rtc-m41t80.txt +++ b/Documentation/devicetree/bindings/rtc/rtc-m41t80.txt @@ -21,10 +21,19 @@ Optional properties: clock name - wakeup-source: Enables wake up of host system on alarm +Optional child node: +- clock: Provide this if the square wave pin is used as boot-enabled fixed clock. + Example: rtc@68 { compatible = "st,m41t80"; reg = <0x68>; interrupt-parent = <&UIC0>; interrupts = <0x9 0x8>; + + clock { + compatible = "fixed-clock"; + #clock-cells = <0>; + clock-frequency = <32768>; + }; }; -- cgit v1.2.3 From 8df65d4adca654180a5c05ecb853c15d1d74e410 Mon Sep 17 00:00:00 2001 From: Corentin Labbe Date: Mon, 10 May 2021 18:25:05 +0000 Subject: dt-bindings: convert rtc/faraday,ftrtc01 to yaml Converts rtc/faraday,ftrtc01.txt to yaml. This permits to detect some missing properties: reg, resets, interrupts Reviewed-by: Linus Walleij Signed-off-by: Corentin Labbe Reviewed-by: Rob Herring Signed-off-by: Alexandre Belloni Link: https://lore.kernel.org/r/20210510182505.3968936-1-clabbe@baylibre.com --- .../devicetree/bindings/rtc/faraday,ftrtc010.txt | 28 ---------- .../devicetree/bindings/rtc/faraday,ftrtc010.yaml | 59 ++++++++++++++++++++++ 2 files changed, 59 insertions(+), 28 deletions(-) delete mode 100644 Documentation/devicetree/bindings/rtc/faraday,ftrtc010.txt create mode 100644 Documentation/devicetree/bindings/rtc/faraday,ftrtc010.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/rtc/faraday,ftrtc010.txt b/Documentation/devicetree/bindings/rtc/faraday,ftrtc010.txt deleted file mode 100644 index e3938f5e0b6c..000000000000 --- a/Documentation/devicetree/bindings/rtc/faraday,ftrtc010.txt +++ /dev/null @@ -1,28 +0,0 @@ -* Faraday Technology FTRTC010 Real Time Clock - -This RTC appears in for example the Storlink Gemini family of -SoCs. - -Required properties: -- compatible : Should be one of: - "faraday,ftrtc010" - "cortina,gemini-rtc", "faraday,ftrtc010" - -Optional properties: -- clocks: when present should contain clock references to the - PCLK and EXTCLK clocks. Faraday calls the later CLK1HZ and - says the clock should be 1 Hz, but implementers actually seem - to choose different clocks here, like Cortina who chose - 32768 Hz (a typical low-power clock). -- clock-names: should name the clocks "PCLK" and "EXTCLK" - respectively. - -Examples: - -rtc@45000000 { - compatible = "cortina,gemini-rtc"; - reg = <0x45000000 0x100>; - interrupts = <17 IRQ_TYPE_LEVEL_HIGH>; - clocks = <&foo 0>, <&foo 1>; - clock-names = "PCLK", "EXTCLK"; -}; diff --git a/Documentation/devicetree/bindings/rtc/faraday,ftrtc010.yaml b/Documentation/devicetree/bindings/rtc/faraday,ftrtc010.yaml new file mode 100644 index 000000000000..657c13b62b67 --- /dev/null +++ b/Documentation/devicetree/bindings/rtc/faraday,ftrtc010.yaml @@ -0,0 +1,59 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/rtc/faraday,ftrtc010.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Faraday Technology FTRTC010 Real Time Clock + +maintainers: + - Linus Walleij + +description: | + This RTC appears in for example the Storlink Gemini family of SoCs. + +properties: + compatible: + oneOf: + - const: faraday,ftrtc010 + - items: + - const: cortina,gemini-rtc + - const: faraday,ftrtc010 + + resets: + maxItems: 1 + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + minItems: 2 + items: + - description: PCLK clocks + - description: EXTCLK clocks. Faraday calls it CLK1HZ and says the clock + should be 1 Hz, but implementers actually seem to choose different + clocks here, like Cortina who chose 32768 Hz (a typical low-power clock). + + clock-names: + items: + - const: "PCLK" + - const: "EXTCLK" + +required: + - compatible + +additionalProperties: false + +examples: + - | + #include + rtc@45000000 { + compatible = "cortina,gemini-rtc", "faraday,ftrtc010"; + reg = <0x45000000 0x100>; + interrupts = <17 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&foo 0>, <&foo 1>; + clock-names = "PCLK", "EXTCLK"; + }; -- cgit v1.2.3 From 3d7a0dd8f39bcc9b17700dafb5f40b17e92109ee Mon Sep 17 00:00:00 2001 From: Krishna Manikandan Date: Mon, 24 May 2021 17:14:10 +0530 Subject: dt-bindings: msm: disp: add yaml schemas for DPU bindings MSM Mobile Display Subsystem (MDSS) encapsulates sub-blocks like DPU display controller, DSI etc. Add YAML schema for DPU device tree bindings. Signed-off-by: Krishna Manikandan Reviewed-by: Rob Herring Reviewed-by: Bjorn Andersson Reviewed-by: Stephen Boyd Link: https://lore.kernel.org/r/1621856653-10649-1-git-send-email-mkrishn@codeaurora.org Signed-off-by: Rob Clark --- .../bindings/display/msm/dpu-sc7180.yaml | 228 +++++++++++++++++++++ .../bindings/display/msm/dpu-sdm845.yaml | 212 +++++++++++++++++++ .../devicetree/bindings/display/msm/dpu.txt | 141 ------------- 3 files changed, 440 insertions(+), 141 deletions(-) create mode 100644 Documentation/devicetree/bindings/display/msm/dpu-sc7180.yaml create mode 100644 Documentation/devicetree/bindings/display/msm/dpu-sdm845.yaml delete mode 100644 Documentation/devicetree/bindings/display/msm/dpu.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/msm/dpu-sc7180.yaml b/Documentation/devicetree/bindings/display/msm/dpu-sc7180.yaml new file mode 100644 index 000000000000..12a86b1ec1bc --- /dev/null +++ b/Documentation/devicetree/bindings/display/msm/dpu-sc7180.yaml @@ -0,0 +1,228 @@ +# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/msm/dpu-sc7180.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Display DPU dt properties for SC7180 target + +maintainers: + - Krishna Manikandan + +description: | + Device tree bindings for MSM Mobile Display Subsystem(MDSS) that encapsulates + sub-blocks like DPU display controller, DSI and DP interfaces etc. Device tree + bindings of MDSS and DPU are mentioned for SC7180 target. + +properties: + compatible: + items: + - const: qcom,sc7180-mdss + + reg: + maxItems: 1 + + reg-names: + const: mdss + + power-domains: + maxItems: 1 + + clocks: + items: + - description: Display AHB clock from gcc + - description: Display AHB clock from dispcc + - description: Display core clock + + clock-names: + items: + - const: iface + - const: ahb + - const: core + + interrupts: + maxItems: 1 + + interrupt-controller: true + + "#address-cells": true + + "#size-cells": true + + "#interrupt-cells": + const: 1 + + iommus: + items: + - description: Phandle to apps_smmu node with SID mask for Hard-Fail port0 + + ranges: true + + interconnects: + items: + - description: Interconnect path specifying the port ids for data bus + + interconnect-names: + const: mdp0-mem + +patternProperties: + "^display-controller@[0-9a-f]+$": + type: object + description: Node containing the properties of DPU. + + properties: + compatible: + items: + - const: qcom,sc7180-dpu + + reg: + items: + - description: Address offset and size for mdp register set + - description: Address offset and size for vbif register set + + reg-names: + items: + - const: mdp + - const: vbif + + clocks: + items: + - description: Display hf axi clock + - description: Display ahb clock + - description: Display rotator clock + - description: Display lut clock + - description: Display core clock + - description: Display vsync clock + + clock-names: + items: + - const: bus + - const: iface + - const: rot + - const: lut + - const: core + - const: vsync + + interrupts: + maxItems: 1 + + power-domains: + maxItems: 1 + + operating-points-v2: true + + ports: + $ref: /schemas/graph.yaml#/properties/ports + description: | + Contains the list of output ports from DPU device. These ports + connect to interfaces that are external to the DPU hardware, + such as DSI, DP etc. Each output port contains an endpoint that + describes how it is connected to an external interface. + + properties: + port@0: + $ref: /schemas/graph.yaml#/properties/port + description: DPU_INTF1 (DSI1) + + port@2: + $ref: /schemas/graph.yaml#/properties/port + description: DPU_INTF0 (DP) + + required: + - port@0 + + required: + - compatible + - reg + - reg-names + - clocks + - interrupts + - power-domains + - operating-points-v2 + - ports + +required: + - compatible + - reg + - reg-names + - power-domains + - clocks + - interrupts + - interrupt-controller + - iommus + - ranges + +additionalProperties: false + +examples: + - | + #include + #include + #include + #include + #include + + display-subsystem@ae00000 { + #address-cells = <1>; + #size-cells = <1>; + compatible = "qcom,sc7180-mdss"; + reg = <0xae00000 0x1000>; + reg-names = "mdss"; + power-domains = <&dispcc MDSS_GDSC>; + clocks = <&gcc GCC_DISP_AHB_CLK>, + <&dispcc DISP_CC_MDSS_AHB_CLK>, + <&dispcc DISP_CC_MDSS_MDP_CLK>; + clock-names = "iface", "ahb", "core"; + + interrupts = ; + interrupt-controller; + #interrupt-cells = <1>; + + interconnects = <&mmss_noc MASTER_MDP0 &mc_virt SLAVE_EBI1>; + interconnect-names = "mdp0-mem"; + + iommus = <&apps_smmu 0x800 0x2>; + ranges; + + display-controller@ae01000 { + compatible = "qcom,sc7180-dpu"; + reg = <0x0ae01000 0x8f000>, + <0x0aeb0000 0x2008>; + + reg-names = "mdp", "vbif"; + + clocks = <&gcc GCC_DISP_HF_AXI_CLK>, + <&dispcc DISP_CC_MDSS_AHB_CLK>, + <&dispcc DISP_CC_MDSS_ROT_CLK>, + <&dispcc DISP_CC_MDSS_MDP_LUT_CLK>, + <&dispcc DISP_CC_MDSS_MDP_CLK>, + <&dispcc DISP_CC_MDSS_VSYNC_CLK>; + clock-names = "bus", "iface", "rot", "lut", "core", + "vsync"; + + interrupt-parent = <&mdss>; + interrupts = <0>; + power-domains = <&rpmhpd SC7180_CX>; + operating-points-v2 = <&mdp_opp_table>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + dpu_intf1_out: endpoint { + remote-endpoint = <&dsi0_in>; + }; + }; + + port@2 { + reg = <2>; + dpu_intf0_out: endpoint { + remote-endpoint = <&dp_in>; + }; + }; + }; + }; + }; +... diff --git a/Documentation/devicetree/bindings/display/msm/dpu-sdm845.yaml b/Documentation/devicetree/bindings/display/msm/dpu-sdm845.yaml new file mode 100644 index 000000000000..b4ea7c92fb3d --- /dev/null +++ b/Documentation/devicetree/bindings/display/msm/dpu-sdm845.yaml @@ -0,0 +1,212 @@ +# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/msm/dpu-sdm845.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Display DPU dt properties for SDM845 target + +maintainers: + - Krishna Manikandan + +description: | + Device tree bindings for MSM Mobile Display Subsystem(MDSS) that encapsulates + sub-blocks like DPU display controller, DSI and DP interfaces etc. Device tree + bindings of MDSS and DPU are mentioned for SDM845 target. + +properties: + compatible: + items: + - const: qcom,sdm845-mdss + + reg: + maxItems: 1 + + reg-names: + const: mdss + + power-domains: + maxItems: 1 + + clocks: + items: + - description: Display AHB clock from gcc + - description: Display AXI clock + - description: Display core clock + + clock-names: + items: + - const: iface + - const: bus + - const: core + + interrupts: + maxItems: 1 + + interrupt-controller: true + + "#address-cells": true + + "#size-cells": true + + "#interrupt-cells": + const: 1 + + iommus: + items: + - description: Phandle to apps_smmu node with SID mask for Hard-Fail port0 + - description: Phandle to apps_smmu node with SID mask for Hard-Fail port1 + + ranges: true + +patternProperties: + "^display-controller@[0-9a-f]+$": + type: object + description: Node containing the properties of DPU. + + properties: + compatible: + items: + - const: qcom,sdm845-dpu + + reg: + items: + - description: Address offset and size for mdp register set + - description: Address offset and size for vbif register set + + reg-names: + items: + - const: mdp + - const: vbif + + clocks: + items: + - description: Display ahb clock + - description: Display axi clock + - description: Display core clock + - description: Display vsync clock + + clock-names: + items: + - const: iface + - const: bus + - const: core + - const: vsync + + interrupts: + maxItems: 1 + + power-domains: + maxItems: 1 + + operating-points-v2: true + ports: + $ref: /schemas/graph.yaml#/properties/ports + description: | + Contains the list of output ports from DPU device. These ports + connect to interfaces that are external to the DPU hardware, + such as DSI, DP etc. Each output port contains an endpoint that + describes how it is connected to an external interface. + + properties: + port@0: + $ref: /schemas/graph.yaml#/properties/port + description: DPU_INTF1 (DSI1) + + port@1: + $ref: /schemas/graph.yaml#/properties/port + description: DPU_INTF2 (DSI2) + + required: + - port@0 + - port@1 + + required: + - compatible + - reg + - reg-names + - clocks + - interrupts + - power-domains + - operating-points-v2 + - ports + +required: + - compatible + - reg + - reg-names + - power-domains + - clocks + - interrupts + - interrupt-controller + - iommus + - ranges + +additionalProperties: false + +examples: + - | + #include + #include + #include + #include + + display-subsystem@ae00000 { + #address-cells = <1>; + #size-cells = <1>; + compatible = "qcom,sdm845-mdss"; + reg = <0x0ae00000 0x1000>; + reg-names = "mdss"; + power-domains = <&dispcc MDSS_GDSC>; + + clocks = <&gcc GCC_DISP_AHB_CLK>, + <&gcc GCC_DISP_AXI_CLK>, + <&dispcc DISP_CC_MDSS_MDP_CLK>; + clock-names = "iface", "bus", "core"; + + interrupts = ; + interrupt-controller; + #interrupt-cells = <1>; + + iommus = <&apps_smmu 0x880 0x8>, + <&apps_smmu 0xc80 0x8>; + ranges; + + display-controller@ae01000 { + compatible = "qcom,sdm845-dpu"; + reg = <0x0ae01000 0x8f000>, + <0x0aeb0000 0x2008>; + reg-names = "mdp", "vbif"; + + clocks = <&dispcc DISP_CC_MDSS_AHB_CLK>, + <&dispcc DISP_CC_MDSS_AXI_CLK>, + <&dispcc DISP_CC_MDSS_MDP_CLK>, + <&dispcc DISP_CC_MDSS_VSYNC_CLK>; + clock-names = "iface", "bus", "core", "vsync"; + + interrupt-parent = <&mdss>; + interrupts = <0>; + power-domains = <&rpmhpd SDM845_CX>; + operating-points-v2 = <&mdp_opp_table>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + dpu_intf1_out: endpoint { + remote-endpoint = <&dsi0_in>; + }; + }; + + port@1 { + reg = <1>; + dpu_intf2_out: endpoint { + remote-endpoint = <&dsi1_in>; + }; + }; + }; + }; + }; +... diff --git a/Documentation/devicetree/bindings/display/msm/dpu.txt b/Documentation/devicetree/bindings/display/msm/dpu.txt deleted file mode 100644 index 586e6eac5b08..000000000000 --- a/Documentation/devicetree/bindings/display/msm/dpu.txt +++ /dev/null @@ -1,141 +0,0 @@ -Qualcomm Technologies, Inc. DPU KMS - -Description: - -Device tree bindings for MSM Mobile Display Subsystem(MDSS) that encapsulates -sub-blocks like DPU display controller, DSI and DP interfaces etc. -The DPU display controller is found in SDM845 SoC. - -MDSS: -Required properties: -- compatible: "qcom,sdm845-mdss", "qcom,sc7180-mdss" -- reg: physical base address and length of controller's registers. -- reg-names: register region names. The following region is required: - * "mdss" -- power-domains: a power domain consumer specifier according to - Documentation/devicetree/bindings/power/power_domain.txt -- clocks: list of clock specifiers for clocks needed by the device. -- clock-names: device clock names, must be in same order as clocks property. - The following clocks are required: - * "iface" - * "bus" - * "core" -- interrupts: interrupt signal from MDSS. -- interrupt-controller: identifies the node as an interrupt controller. -- #interrupt-cells: specifies the number of cells needed to encode an interrupt - source, should be 1. -- iommus: phandle of iommu device node. -- #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. -- interconnects : interconnect path specifier for MDSS according to - Documentation/devicetree/bindings/interconnect/interconnect.txt. Should be - 2 paths corresponding to 2 AXI ports. -- interconnect-names : MDSS will have 2 port names to differentiate between the - 2 interconnect paths defined with interconnect specifier. - -Optional properties: -- assigned-clocks: list of clock specifiers for clocks needing rate assignment -- assigned-clock-rates: list of clock frequencies sorted in the same order as - the assigned-clocks property. - -MDP: -Required properties: -- compatible: "qcom,sdm845-dpu", "qcom,sc7180-dpu" -- reg: physical base address and length of controller's registers. -- reg-names : register region names. The following region is required: - * "mdp" - * "vbif" -- clocks: list of clock specifiers for clocks needed by the device. -- clock-names: device clock names, must be in same order as clocks property. - The following clocks are required. - * "bus" - * "iface" - * "core" - * "vsync" -- interrupts: interrupt line from DPU to MDSS. -- ports: contains the list of output ports from DPU device. These ports connect - to interfaces that are external to the DPU hardware, such as DSI, DP etc. - - Each output port contains an endpoint that describes how it is connected to an - external interface. These are described by the standard properties documented - here: - Documentation/devicetree/bindings/graph.txt - Documentation/devicetree/bindings/media/video-interfaces.txt - - Port 0 -> DPU_INTF1 (DSI1) - Port 1 -> DPU_INTF2 (DSI2) - -Optional properties: -- assigned-clocks: list of clock specifiers for clocks needing rate assignment -- assigned-clock-rates: list of clock frequencies sorted in the same order as - the assigned-clocks property. - -Example: - - mdss: mdss@ae00000 { - compatible = "qcom,sdm845-mdss"; - reg = <0xae00000 0x1000>; - reg-names = "mdss"; - - power-domains = <&clock_dispcc 0>; - - clocks = <&gcc GCC_DISP_AHB_CLK>, <&gcc GCC_DISP_AXI_CLK>, - <&clock_dispcc DISP_CC_MDSS_MDP_CLK>; - clock-names = "iface", "bus", "core"; - - assigned-clocks = <&clock_dispcc DISP_CC_MDSS_MDP_CLK>; - assigned-clock-rates = <300000000>; - - interrupts = ; - interrupt-controller; - #interrupt-cells = <1>; - - interconnects = <&rsc_hlos MASTER_MDP0 &rsc_hlos SLAVE_EBI1>, - <&rsc_hlos MASTER_MDP1 &rsc_hlos SLAVE_EBI1>; - - interconnect-names = "mdp0-mem", "mdp1-mem"; - - iommus = <&apps_iommu 0>; - - #address-cells = <2>; - #size-cells = <1>; - ranges = <0 0 0xae00000 0xb2008>; - - mdss_mdp: mdp@ae01000 { - compatible = "qcom,sdm845-dpu"; - reg = <0 0x1000 0x8f000>, <0 0xb0000 0x2008>; - reg-names = "mdp", "vbif"; - - clocks = <&clock_dispcc DISP_CC_MDSS_AHB_CLK>, - <&clock_dispcc DISP_CC_MDSS_AXI_CLK>, - <&clock_dispcc DISP_CC_MDSS_MDP_CLK>, - <&clock_dispcc DISP_CC_MDSS_VSYNC_CLK>; - clock-names = "iface", "bus", "core", "vsync"; - - assigned-clocks = <&clock_dispcc DISP_CC_MDSS_MDP_CLK>, - <&clock_dispcc DISP_CC_MDSS_VSYNC_CLK>; - assigned-clock-rates = <0 0 300000000 19200000>; - - interrupts = <0 IRQ_TYPE_LEVEL_HIGH>; - - ports { - #address-cells = <1>; - #size-cells = <0>; - - port@0 { - reg = <0>; - dpu_intf1_out: endpoint { - remote-endpoint = <&dsi0_in>; - }; - }; - - port@1 { - reg = <1>; - dpu_intf2_out: endpoint { - remote-endpoint = <&dsi1_in>; - }; - }; - }; - }; - }; -- cgit v1.2.3 From 4dbe55c9774179da9630498e647c718d1c910bca Mon Sep 17 00:00:00 2001 From: Krishna Manikandan Date: Mon, 24 May 2021 17:14:11 +0530 Subject: dt-bindings: msm: dsi: add yaml schemas for DSI bindings Add YAML schema for the device tree bindings for DSI Signed-off-by: Krishna Manikandan Reviewed-by: Bjorn Andersson Reviewed-by: Stephen Boyd Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/1621856653-10649-2-git-send-email-mkrishn@codeaurora.org Signed-off-by: Rob Clark --- .../bindings/display/msm/dsi-controller-main.yaml | 185 +++++++++++++++ .../devicetree/bindings/display/msm/dsi.txt | 249 --------------------- 2 files changed, 185 insertions(+), 249 deletions(-) create mode 100644 Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml delete mode 100644 Documentation/devicetree/bindings/display/msm/dsi.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml b/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml new file mode 100644 index 000000000000..76348b71f736 --- /dev/null +++ b/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml @@ -0,0 +1,185 @@ +# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/msm/dsi-controller-main.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Display DSI controller + +maintainers: + - Krishna Manikandan + +allOf: + - $ref: "../dsi-controller.yaml#" + +properties: + compatible: + items: + - const: qcom,mdss-dsi-ctrl + + reg: + maxItems: 1 + + reg-names: + const: dsi_ctrl + + interrupts: + maxItems: 1 + + clocks: + items: + - description: Display byte clock + - description: Display byte interface clock + - description: Display pixel clock + - description: Display escape clock + - description: Display AHB clock + - description: Display AXI clock + + clock-names: + items: + - const: byte + - const: byte_intf + - const: pixel + - const: core + - const: iface + - const: bus + + phys: + maxItems: 1 + + phy-names: + const: dsi + + "#address-cells": true + + "#size-cells": true + + syscon-sfpb: + description: A phandle to mmss_sfpb syscon node (only for DSIv2). + $ref: "/schemas/types.yaml#/definitions/phandle" + + qcom,dual-dsi-mode: + type: boolean + description: | + Indicates if the DSI controller is driving a panel which needs + 2 DSI links. + + power-domains: + maxItems: 1 + + operating-points-v2: true + + ports: + $ref: "/schemas/graph.yaml#/properties/ports" + description: | + Contains DSI controller input and output ports as children, each + containing one endpoint subnode. + + properties: + port@0: + $ref: "/schemas/graph.yaml#/properties/port" + description: | + Input endpoints of the controller. + properties: + endpoint: + $ref: /schemas/media/video-interfaces.yaml# + unevaluatedProperties: false + properties: + data-lanes: + maxItems: 4 + minItems: 4 + items: + enum: [ 0, 1, 2, 3 ] + + port@1: + $ref: "/schemas/graph.yaml#/properties/port" + description: | + Output endpoints of the controller. + properties: + endpoint: + $ref: /schemas/media/video-interfaces.yaml# + unevaluatedProperties: false + properties: + data-lanes: + maxItems: 4 + minItems: 4 + items: + enum: [ 0, 1, 2, 3 ] + + required: + - port@0 + - port@1 + +required: + - compatible + - reg + - reg-names + - interrupts + - clocks + - clock-names + - phys + - phy-names + - power-domains + - operating-points-v2 + - ports + +additionalProperties: false + +examples: + - | + #include + #include + #include + #include + + dsi@ae94000 { + compatible = "qcom,mdss-dsi-ctrl"; + reg = <0x0ae94000 0x400>; + reg-names = "dsi_ctrl"; + + #address-cells = <1>; + #size-cells = <0>; + + interrupt-parent = <&mdss>; + interrupts = <4>; + + clocks = <&dispcc DISP_CC_MDSS_BYTE0_CLK>, + <&dispcc DISP_CC_MDSS_BYTE0_INTF_CLK>, + <&dispcc DISP_CC_MDSS_PCLK0_CLK>, + <&dispcc DISP_CC_MDSS_ESC0_CLK>, + <&dispcc DISP_CC_MDSS_AHB_CLK>, + <&dispcc DISP_CC_MDSS_AXI_CLK>; + clock-names = "byte", + "byte_intf", + "pixel", + "core", + "iface", + "bus"; + + phys = <&dsi0_phy>; + phy-names = "dsi"; + + power-domains = <&rpmhpd SC7180_CX>; + operating-points-v2 = <&dsi_opp_table>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + dsi0_in: endpoint { + remote-endpoint = <&dpu_intf1_out>; + }; + }; + + port@1 { + reg = <1>; + dsi0_out: endpoint { + remote-endpoint = <&sn65dsi86_in>; + data-lanes = <0 1 2 3>; + }; + }; + }; + }; +... diff --git a/Documentation/devicetree/bindings/display/msm/dsi.txt b/Documentation/devicetree/bindings/display/msm/dsi.txt deleted file mode 100644 index b9a64d3ff184..000000000000 --- a/Documentation/devicetree/bindings/display/msm/dsi.txt +++ /dev/null @@ -1,249 +0,0 @@ -Qualcomm Technologies Inc. adreno/snapdragon DSI output - -DSI Controller: -Required properties: -- compatible: - * "qcom,mdss-dsi-ctrl" -- reg: Physical base address and length of the registers of controller -- reg-names: The names of register regions. The following regions are required: - * "dsi_ctrl" -- interrupts: The interrupt signal from the DSI block. -- power-domains: Should be <&mmcc MDSS_GDSC>. -- clocks: Phandles to device clocks. -- clock-names: the following clocks are required: - * "mdp_core" - * "iface" - * "bus" - * "core_mmss" - * "byte" - * "pixel" - * "core" - For DSIv2, we need an additional clock: - * "src" - For DSI6G v2.0 onwards, we need also need the clock: - * "byte_intf" -- 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 -- vddio-supply: phandle to vdd-io regulator device node -- vdda-supply: phandle to vdda regulator device node -- phys: phandle to DSI PHY device node -- phy-names: the name of the corresponding PHY device -- syscon-sfpb: A phandle to mmss_sfpb syscon node (only for DSIv2) -- ports: Contains 2 DSI controller ports as child nodes. Each port contains - an endpoint subnode as defined in [2] and [3]. - -Optional properties: -- panel@0: Node of panel connected to this DSI controller. - See files in [4] for each supported panel. -- qcom,dual-dsi-mode: Boolean value indicating if the DSI controller is - driving a panel which needs 2 DSI links. -- qcom,master-dsi: Boolean value indicating if the DSI controller is driving - the master link of the 2-DSI panel. -- qcom,sync-dual-dsi: Boolean value indicating if the DSI controller is - driving a 2-DSI panel whose 2 links need receive command simultaneously. -- pinctrl-names: the pin control state names; should contain "default" -- pinctrl-0: the default pinctrl state (active) -- pinctrl-n: the "sleep" pinctrl state -- ports: contains DSI controller input and output ports as children, each - containing one endpoint subnode. - - DSI Endpoint properties: - - remote-endpoint: For port@0, set to phandle of the connected panel/bridge's - input endpoint. For port@1, set to the MDP interface output. See [2] for - device graph info. - - - data-lanes: this describes how the physical DSI data lanes are mapped - to the logical lanes on the given platform. The value contained in - index n describes what physical lane is mapped to the logical lane n - (DATAn, where n lies between 0 and 3). The clock lane position is fixed - and can't be changed. Hence, they aren't a part of the DT bindings. See - [3] for more info on the data-lanes property. - - For example: - - data-lanes = <3 0 1 2>; - - The above mapping describes that the logical data lane DATA0 is mapped to - the physical data lane DATA3, logical DATA1 to physical DATA0, logic DATA2 - to phys DATA1 and logic DATA3 to phys DATA2. - - There are only a limited number of physical to logical mappings possible: - <0 1 2 3> - <1 2 3 0> - <2 3 0 1> - <3 0 1 2> - <0 3 2 1> - <1 0 3 2> - <2 1 0 3> - <3 2 1 0> - -DSI PHY: -Required properties: -- compatible: Could be the following - * "qcom,dsi-phy-28nm-hpm" - * "qcom,dsi-phy-28nm-lp" - * "qcom,dsi-phy-20nm" - * "qcom,dsi-phy-28nm-8960" - * "qcom,dsi-phy-14nm" - * "qcom,dsi-phy-14nm-660" - * "qcom,dsi-phy-10nm" - * "qcom,dsi-phy-10nm-8998" - * "qcom,dsi-phy-7nm" - * "qcom,dsi-phy-7nm-8150" -- reg: Physical base address and length of the registers of PLL, PHY. Some - revisions require the PHY regulator base address, whereas others require the - PHY lane base address. See below for each PHY revision. -- reg-names: The names of register regions. The following regions are required: - For DSI 28nm HPM/LP/8960 PHYs and 20nm PHY: - * "dsi_pll" - * "dsi_phy" - * "dsi_phy_regulator" - For DSI 14nm, 10nm and 7nm PHYs: - * "dsi_pll" - * "dsi_phy" - * "dsi_phy_lane" -- clock-cells: Must be 1. The DSI PHY block acts as a clock provider, creating - 2 clocks: A byte clock (index 0), and a pixel clock (index 1). -- 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" - * "ref" (only required for new DTS files/entries) - For 28nm HPM/LP, 28nm 8960 PHYs: -- vddio-supply: phandle to vdd-io regulator device node - For 20nm PHY: -- vddio-supply: phandle to vdd-io regulator device node -- vcca-supply: phandle to vcca regulator device node - For 14nm PHY: -- vcca-supply: phandle to vcca regulator device node - For 10nm and 7nm PHY: -- vdds-supply: phandle to vdds regulator device node - -Optional properties: -- qcom,dsi-phy-regulator-ldo-mode: Boolean value indicating if the LDO mode PHY - regulator is wanted. -- qcom,mdss-mdp-transfer-time-us: Specifies the dsi transfer time for command mode - panels in microseconds. Driver uses this number to adjust - the clock rate according to the expected transfer time. - Increasing this value would slow down the mdp processing - and can result in slower performance. - Decreasing this value can speed up the mdp processing, - but this can also impact power consumption. - As a rule this time should not be higher than the time - that would be expected with the processing at the - dsi link rate since anyways this would be the maximum - transfer time that could be achieved. - If ping pong split is enabled, this time should not be higher - than two times the dsi link rate time. - If the property is not specified, then the default value is 14000 us. - -[1] Documentation/devicetree/bindings/clock/clock-bindings.txt -[2] Documentation/devicetree/bindings/graph.txt -[3] Documentation/devicetree/bindings/media/video-interfaces.txt -[4] Documentation/devicetree/bindings/display/panel/ - -Example: - dsi0: dsi@fd922800 { - compatible = "qcom,mdss-dsi-ctrl"; - qcom,dsi-host-index = <0>; - interrupt-parent = <&mdp>; - interrupts = <4 0>; - reg-names = "dsi_ctrl"; - reg = <0xfd922800 0x200>; - power-domains = <&mmcc MDSS_GDSC>; - clock-names = - "bus", - "byte", - "core", - "core_mmss", - "iface", - "mdp_core", - "pixel"; - clocks = - <&mmcc MDSS_AXI_CLK>, - <&mmcc MDSS_BYTE0_CLK>, - <&mmcc MDSS_ESC0_CLK>, - <&mmcc MMSS_MISC_AHB_CLK>, - <&mmcc MDSS_AHB_CLK>, - <&mmcc MDSS_MDP_CLK>, - <&mmcc MDSS_PCLK0_CLK>; - - assigned-clocks = - <&mmcc BYTE0_CLK_SRC>, - <&mmcc PCLK0_CLK_SRC>; - assigned-clock-parents = - <&dsi_phy0 0>, - <&dsi_phy0 1>; - - vdda-supply = <&pma8084_l2>; - vdd-supply = <&pma8084_l22>; - vddio-supply = <&pma8084_l12>; - - phys = <&dsi_phy0>; - phy-names ="dsi-phy"; - - qcom,dual-dsi-mode; - qcom,master-dsi; - qcom,sync-dual-dsi; - - qcom,mdss-mdp-transfer-time-us = <12000>; - - pinctrl-names = "default", "sleep"; - pinctrl-0 = <&dsi_active>; - pinctrl-1 = <&dsi_suspend>; - - ports { - #address-cells = <1>; - #size-cells = <0>; - - port@0 { - reg = <0>; - dsi0_in: endpoint { - remote-endpoint = <&mdp_intf1_out>; - }; - }; - - port@1 { - reg = <1>; - dsi0_out: endpoint { - remote-endpoint = <&panel_in>; - data-lanes = <0 1 2 3>; - }; - }; - }; - - panel: panel@0 { - compatible = "sharp,lq101r1sx01"; - reg = <0>; - link2 = <&secondary>; - - power-supply = <...>; - backlight = <...>; - - port { - panel_in: endpoint { - remote-endpoint = <&dsi0_out>; - }; - }; - }; - }; - - dsi_phy0: dsi-phy@fd922a00 { - compatible = "qcom,dsi-phy-28nm-hpm"; - qcom,dsi-phy-index = <0>; - reg-names = - "dsi_pll", - "dsi_phy", - "dsi_phy_regulator"; - reg = <0xfd922a00 0xd4>, - <0xfd922b00 0x2b0>, - <0xfd922d80 0x7b>; - clock-names = "iface"; - clocks = <&mmcc MDSS_AHB_CLK>; - #clock-cells = <1>; - vddio-supply = <&pma8084_l12>; - - qcom,dsi-phy-regulator-ldo-mode; - }; -- cgit v1.2.3 From 8fc939e72ff80116c090aaf03952253a124d2a8e Mon Sep 17 00:00:00 2001 From: Krishna Manikandan Date: Mon, 24 May 2021 17:14:12 +0530 Subject: dt-bindings: msm: dsi: add yaml schemas for DSI PHY bindings Add YAML schema for the device tree bindings for DSI PHY. Signed-off-by: Krishna Manikandan Reviewed-by: Bjorn Andersson Reviewed-by: Stephen Boyd Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/1621856653-10649-3-git-send-email-mkrishn@codeaurora.org Signed-off-by: Rob Clark --- .../bindings/display/msm/dsi-phy-10nm.yaml | 68 +++++++++++++++++++++ .../bindings/display/msm/dsi-phy-14nm.yaml | 66 ++++++++++++++++++++ .../bindings/display/msm/dsi-phy-20nm.yaml | 71 ++++++++++++++++++++++ .../bindings/display/msm/dsi-phy-28nm.yaml | 68 +++++++++++++++++++++ .../bindings/display/msm/dsi-phy-common.yaml | 40 ++++++++++++ 5 files changed, 313 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/msm/dsi-phy-10nm.yaml create mode 100644 Documentation/devicetree/bindings/display/msm/dsi-phy-14nm.yaml create mode 100644 Documentation/devicetree/bindings/display/msm/dsi-phy-20nm.yaml create mode 100644 Documentation/devicetree/bindings/display/msm/dsi-phy-28nm.yaml create mode 100644 Documentation/devicetree/bindings/display/msm/dsi-phy-common.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/msm/dsi-phy-10nm.yaml b/Documentation/devicetree/bindings/display/msm/dsi-phy-10nm.yaml new file mode 100644 index 000000000000..4a26bef19360 --- /dev/null +++ b/Documentation/devicetree/bindings/display/msm/dsi-phy-10nm.yaml @@ -0,0 +1,68 @@ +# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/msm/dsi-phy-10nm.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Display DSI 10nm PHY + +maintainers: + - Krishna Manikandan + +allOf: + - $ref: dsi-phy-common.yaml# + +properties: + compatible: + oneOf: + - const: qcom,dsi-phy-10nm + - const: qcom,dsi-phy-10nm-8998 + + reg: + items: + - description: dsi phy register set + - description: dsi phy lane register set + - description: dsi pll register set + + reg-names: + items: + - const: dsi_phy + - const: dsi_phy_lane + - const: dsi_pll + + vdds-supply: + description: | + Connected to DSI0_MIPI_DSI_PLL_VDDA0P9 pin for sc7180 target and + connected to VDDA_MIPI_DSI_0_PLL_0P9 pin for sdm845 target + +required: + - compatible + - reg + - reg-names + - vdds-supply + +unevaluatedProperties: false + +examples: + - | + #include + #include + + dsi-phy@ae94400 { + compatible = "qcom,dsi-phy-10nm"; + reg = <0x0ae94400 0x200>, + <0x0ae94600 0x280>, + <0x0ae94a00 0x1e0>; + reg-names = "dsi_phy", + "dsi_phy_lane", + "dsi_pll"; + + #clock-cells = <1>; + #phy-cells = <0>; + + vdds-supply = <&vdda_mipi_dsi0_pll>; + clocks = <&dispcc DISP_CC_MDSS_AHB_CLK>, + <&rpmhcc RPMH_CXO_CLK>; + clock-names = "iface", "ref"; + }; +... diff --git a/Documentation/devicetree/bindings/display/msm/dsi-phy-14nm.yaml b/Documentation/devicetree/bindings/display/msm/dsi-phy-14nm.yaml new file mode 100644 index 000000000000..72a00cce0147 --- /dev/null +++ b/Documentation/devicetree/bindings/display/msm/dsi-phy-14nm.yaml @@ -0,0 +1,66 @@ +# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/msm/dsi-phy-14nm.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Display DSI 14nm PHY + +maintainers: + - Krishna Manikandan + +allOf: + - $ref: dsi-phy-common.yaml# + +properties: + compatible: + oneOf: + - const: qcom,dsi-phy-14nm + - const: qcom,dsi-phy-14nm-660 + + reg: + items: + - description: dsi phy register set + - description: dsi phy lane register set + - description: dsi pll register set + + reg-names: + items: + - const: dsi_phy + - const: dsi_phy_lane + - const: dsi_pll + + vcca-supply: + description: Phandle to vcca regulator device node. + +required: + - compatible + - reg + - reg-names + - vcca-supply + +unevaluatedProperties: false + +examples: + - | + #include + #include + + dsi-phy@ae94400 { + compatible = "qcom,dsi-phy-14nm"; + reg = <0x0ae94400 0x200>, + <0x0ae94600 0x280>, + <0x0ae94a00 0x1e0>; + reg-names = "dsi_phy", + "dsi_phy_lane", + "dsi_pll"; + + #clock-cells = <1>; + #phy-cells = <0>; + + vcca-supply = <&vcca_reg>; + clocks = <&dispcc DISP_CC_MDSS_AHB_CLK>, + <&rpmhcc RPMH_CXO_CLK>; + clock-names = "iface", "ref"; + }; +... diff --git a/Documentation/devicetree/bindings/display/msm/dsi-phy-20nm.yaml b/Documentation/devicetree/bindings/display/msm/dsi-phy-20nm.yaml new file mode 100644 index 000000000000..743806d61afe --- /dev/null +++ b/Documentation/devicetree/bindings/display/msm/dsi-phy-20nm.yaml @@ -0,0 +1,71 @@ +# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/msm/dsi-phy-20nm.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Display DSI 20nm PHY + +maintainers: + - Krishna Manikandan + +allOf: + - $ref: dsi-phy-common.yaml# + +properties: + compatible: + oneOf: + - const: qcom,dsi-phy-20nm + + reg: + items: + - description: dsi pll register set + - description: dsi phy register set + - description: dsi phy regulator register set + + reg-names: + items: + - const: dsi_pll + - const: dsi_phy + - const: dsi_phy_regulator + + vcca-supply: + description: Phandle to vcca regulator device node. + + vddio-supply: + description: Phandle to vdd-io regulator device node. + +required: + - compatible + - reg + - reg-names + - vddio-supply + - vcca-supply + +unevaluatedProperties: false + +examples: + - | + #include + #include + + dsi-phy@fd922a00 { + compatible = "qcom,dsi-phy-20nm"; + reg = <0xfd922a00 0xd4>, + <0xfd922b00 0x2b0>, + <0xfd922d80 0x7b>; + reg-names = "dsi_pll", + "dsi_phy", + "dsi_phy_regulator"; + + #clock-cells = <1>; + #phy-cells = <0>; + + vcca-supply = <&vcca_reg>; + vddio-supply = <&vddio_reg>; + + clocks = <&dispcc DISP_CC_MDSS_AHB_CLK>, + <&rpmhcc RPMH_CXO_CLK>; + clock-names = "iface", "ref"; + }; +... diff --git a/Documentation/devicetree/bindings/display/msm/dsi-phy-28nm.yaml b/Documentation/devicetree/bindings/display/msm/dsi-phy-28nm.yaml new file mode 100644 index 000000000000..b106007116b4 --- /dev/null +++ b/Documentation/devicetree/bindings/display/msm/dsi-phy-28nm.yaml @@ -0,0 +1,68 @@ +# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/msm/dsi-phy-28nm.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Display DSI 28nm PHY + +maintainers: + - Krishna Manikandan + +allOf: + - $ref: dsi-phy-common.yaml# + +properties: + compatible: + oneOf: + - const: qcom,dsi-phy-28nm-hpm + - const: qcom,dsi-phy-28nm-lp + - const: qcom,dsi-phy-28nm-8960 + + reg: + items: + - description: dsi pll register set + - description: dsi phy register set + - description: dsi phy regulator register set + + reg-names: + items: + - const: dsi_pll + - const: dsi_phy + - const: dsi_phy_regulator + + vddio-supply: + description: Phandle to vdd-io regulator device node. + +required: + - compatible + - reg + - reg-names + - vddio-supply + +unevaluatedProperties: false + +examples: + - | + #include + #include + + dsi-phy@fd922a00 { + compatible = "qcom,dsi-phy-28nm-lp"; + reg = <0xfd922a00 0xd4>, + <0xfd922b00 0x2b0>, + <0xfd922d80 0x7b>; + reg-names = "dsi_pll", + "dsi_phy", + "dsi_phy_regulator"; + + #clock-cells = <1>; + #phy-cells = <0>; + + vddio-supply = <&vddio_reg>; + + clocks = <&dispcc DISP_CC_MDSS_AHB_CLK>, + <&rpmhcc RPMH_CXO_CLK>; + clock-names = "iface", "ref"; + }; +... diff --git a/Documentation/devicetree/bindings/display/msm/dsi-phy-common.yaml b/Documentation/devicetree/bindings/display/msm/dsi-phy-common.yaml new file mode 100644 index 000000000000..502bdda90235 --- /dev/null +++ b/Documentation/devicetree/bindings/display/msm/dsi-phy-common.yaml @@ -0,0 +1,40 @@ +# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/msm/dsi-phy-common.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Description of Qualcomm Display DSI PHY common dt properties + +maintainers: + - Krishna Manikandan + +description: | + This defines the DSI PHY dt properties which are common for all + dsi phy versions. + +properties: + "#clock-cells": + const: 1 + + "#phy-cells": + const: 0 + + clocks: + items: + - description: Display AHB clock + - description: Board XO source + + clock-names: + items: + - const: iface + - const: ref + +required: + - clocks + - clock-names + - "#clock-cells" + - "#phy-cells" + +additionalProperties: true +... -- cgit v1.2.3 From 665a69611a73656343049f4e6f21d0ca5ca08526 Mon Sep 17 00:00:00 2001 From: Krishna Manikandan Date: Mon, 24 May 2021 17:14:13 +0530 Subject: dt-bindings: msm/dp: Add bindings of MSM DisplayPort controller Add bindings for Snapdragon DisplayPort controller driver. Signed-off-by: Chandan Uddaraju Signed-off-by: Vara Reddy Signed-off-by: Tanmay Shah Signed-off-by: Kuogee Hsieh Signed-off-by: Krishna Manikandan Reviewed-by: Bjorn Andersson Reviewed-by: Rob Herring Reviewed-by: Stephen Boyd Link: https://lore.kernel.org/r/1621856653-10649-4-git-send-email-mkrishn@codeaurora.org Signed-off-by: Rob Clark --- .../bindings/display/msm/dp-controller.yaml | 146 +++++++++++++++++++++ 1 file changed, 146 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/msm/dp-controller.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml new file mode 100644 index 000000000000..64d8d9e5e47a --- /dev/null +++ b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml @@ -0,0 +1,146 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/msm/dp-controller.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: MSM Display Port Controller + +maintainers: + - Kuogee Hsieh + +description: | + Device tree bindings for DisplayPort host controller for MSM targets + that are compatible with VESA DisplayPort interface specification. + +properties: + compatible: + enum: + - qcom,sc7180-dp + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + items: + - description: AHB clock to enable register access + - description: Display Port AUX clock + - description: Display Port Link clock + - description: Link interface clock between DP and PHY + - description: Display Port Pixel clock + + clock-names: + items: + - const: core_iface + - const: core_aux + - const: ctrl_link + - const: ctrl_link_iface + - const: stream_pixel + + assigned-clocks: + items: + - description: link clock source + - description: pixel clock source + + assigned-clock-parents: + items: + - description: phy 0 parent + - description: phy 1 parent + + phys: + maxItems: 1 + + phy-names: + items: + - const: dp + + operating-points-v2: + maxItems: 1 + + power-domains: + maxItems: 1 + + "#sound-dai-cells": + const: 0 + + ports: + $ref: /schemas/graph.yaml#/properties/ports + properties: + port@0: + $ref: /schemas/graph.yaml#/properties/port + description: Input endpoint of the controller + + port@1: + $ref: /schemas/graph.yaml#/properties/port + description: Output endpoint of the controller + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + - phys + - phy-names + - "#sound-dai-cells" + - power-domains + - ports + +additionalProperties: false + +examples: + - | + #include + #include + #include + #include + + displayport-controller@ae90000 { + compatible = "qcom,sc7180-dp"; + reg = <0xae90000 0x1400>; + interrupt-parent = <&mdss>; + interrupts = <12>; + clocks = <&dispcc DISP_CC_MDSS_AHB_CLK>, + <&dispcc DISP_CC_MDSS_DP_AUX_CLK>, + <&dispcc DISP_CC_MDSS_DP_LINK_CLK>, + <&dispcc DISP_CC_MDSS_DP_LINK_INTF_CLK>, + <&dispcc DISP_CC_MDSS_DP_PIXEL_CLK>; + clock-names = "core_iface", "core_aux", + "ctrl_link", + "ctrl_link_iface", "stream_pixel"; + + assigned-clocks = <&dispcc DISP_CC_MDSS_DP_LINK_CLK_SRC>, + <&dispcc DISP_CC_MDSS_DP_PIXEL_CLK_SRC>; + + assigned-clock-parents = <&dp_phy 0>, <&dp_phy 1>; + + phys = <&dp_phy>; + phy-names = "dp"; + + #sound-dai-cells = <0>; + + power-domains = <&rpmhpd SC7180_CX>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + endpoint { + remote-endpoint = <&dpu_intf0_out>; + }; + }; + + port@1 { + reg = <1>; + endpoint { + remote-endpoint = <&typec>; + }; + }; + }; + }; +... -- cgit v1.2.3 From 71c689dc2e732d4cb190aaf0edea73116b1611bd Mon Sep 17 00:00:00 2001 From: Hans Verkuil Date: Tue, 27 Apr 2021 14:07:03 +0200 Subject: media: v4l2-ctrls: split up into four source files The v4l2-ctrls.c source has become much too big, so split it up into four separate parts: v4l2-ctrls-core.c: contains the core framework code v4l2-ctrls-api.c: contains the uAPI interface to the framework v4l2-ctrls-defs.c: contains the control definitions v4l2-ctrls-request.c: contains the Request API helpers And it adds a new v4l2-ctrls-priv.h. No code was changed, but a number of checkpatch.pl warnings were fixed (alignment, f == NULL -> !f, long comment block coding style, unsigned -> unsigned int). The copyright statements were updated as well since they were quite out of date. Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab --- Documentation/userspace-api/media/v4l/ext-ctrls-codec-stateless.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/userspace-api/media/v4l/ext-ctrls-codec-stateless.rst b/Documentation/userspace-api/media/v4l/ext-ctrls-codec-stateless.rst index 2aa508ffb6b9..72f5e85b4f34 100644 --- a/Documentation/userspace-api/media/v4l/ext-ctrls-codec-stateless.rst +++ b/Documentation/userspace-api/media/v4l/ext-ctrls-codec-stateless.rst @@ -1353,8 +1353,8 @@ FWHT Flags * - __u8 - ``picture_coding_type`` - Picture coding type for the frame covered by the current slice - (V4L2_MPEG2_PICTURE_CODING_TYPE_I, V4L2_MPEG2_PICTURE_CODING_TYPE_P or - V4L2_MPEG2_PICTURE_CODING_TYPE_B). + (V4L2_MPEG2_PIC_CODING_TYPE_I, V4L2_MPEG2_PIC_CODING_TYPE_P or + V4L2_MPEG2_PIC_CODING_TYPE_B). * - __u8 - ``picture_structure`` - Picture structure (1: interlaced top field, 2: interlaced bottom field, -- cgit v1.2.3 From 710071479cf8c6127791427561a6ba4ee916c07f Mon Sep 17 00:00:00 2001 From: Mark Kettenis Date: Thu, 20 May 2021 19:13:06 +0200 Subject: dt-bindings: pinctrl: Add DT bindings for apple, pinctrl The Apple GPIO controller is a simple combined pin and GPIO conroller present on Apple ARM SoC platforms, including various iPhone and iPad devices and the "Apple Silicon" Macs. Signed-off-by: Mark Kettenis Link: https://lore.kernel.org/r/20210520171310.772-2-mark.kettenis@xs4all.nl Signed-off-by: Linus Walleij --- .../devicetree/bindings/pinctrl/apple,pinctrl.yaml | 106 +++++++++++++++++++++ 1 file changed, 106 insertions(+) create mode 100644 Documentation/devicetree/bindings/pinctrl/apple,pinctrl.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pinctrl/apple,pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/apple,pinctrl.yaml new file mode 100644 index 000000000000..d50571affd1f --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/apple,pinctrl.yaml @@ -0,0 +1,106 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pinctrl/apple,pinctrl.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Apple GPIO controller + +maintainers: + - Mark Kettenis + +description: | + The Apple GPIO controller is a simple combined pin and GPIO + controller present on Apple ARM SoC platforms, including various + iPhone and iPad devices and the "Apple Silicon" Macs. + +properties: + compatible: + items: + - const: apple,t8103-pinctrl + - const: apple,pinctrl + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + + gpio-controller: true + + '#gpio-cells': + const: 2 + + gpio-ranges: + maxItems: 1 + + interrupts: + description: One interrupt for each of the (up to 7) interrupt + groups supported by the controller sorted by interrupt group + number in ascending order. + minItems: 1 + maxItems: 7 + + interrupt-controller: true + +patternProperties: + '-pins$': + type: object + $ref: pinmux-node.yaml# + + properties: + pinmux: + description: + Values are constructed from pin number and alternate function + configuration number using the APPLE_PINMUX() helper macro + defined in include/dt-bindings/pinctrl/apple.h. + + required: + - pinmux + + additionalProperties: false + +required: + - compatible + - reg + - gpio-controller + - '#gpio-cells' + - gpio-ranges + +additionalProperties: false + +examples: + - | + #include + #include + + soc { + #address-cells = <2>; + #size-cells = <2>; + + pinctrl: pinctrl@23c100000 { + compatible = "apple,t8103-pinctrl", "apple,pinctrl"; + reg = <0x2 0x3c100000 0x0 0x100000>; + clocks = <&gpio_clk>; + + gpio-controller; + #gpio-cells = <2>; + gpio-ranges = <&pinctrl 0 0 212>; + + interrupt-controller; + interrupt-parent = <&aic>; + interrupts = , + , + , + , + , + , + ; + + pcie_pins: pcie-pins { + pinmux = , + , + ; + }; + }; + }; -- cgit v1.2.3 From ca940790d2ddc91e976f1e9e685052a54a1c50cf Mon Sep 17 00:00:00 2001 From: Mark Brown Date: Wed, 12 May 2021 17:23:50 +0100 Subject: arm64: Document requirement for access to FEAT_HCX v8.7 of the architecture introduced FEAT_HCX which adds an additional hypervisor configuration register HCRX_EL2. Even though Linux does not currently make use of this feature let's document that the EL3 trap for access to the register should be disabled so that we are able to make use of it in future. Signed-off-by: Mark Brown Acked-by: Catalin Marinas Link: https://lore.kernel.org/r/20210512162350.20349-1-broonie@kernel.org Signed-off-by: Will Deacon --- Documentation/arm64/booting.rst | 6 ++++++ 1 file changed, 6 insertions(+) (limited to 'Documentation') diff --git a/Documentation/arm64/booting.rst b/Documentation/arm64/booting.rst index 18b8cc1bf32c..a9192e7a231b 100644 --- a/Documentation/arm64/booting.rst +++ b/Documentation/arm64/booting.rst @@ -277,6 +277,12 @@ Before jumping into the kernel, the following conditions must be met: - SCR_EL3.FGTEn (bit 27) must be initialised to 0b1. + For CPUs with support for HCRX_EL2 (FEAT_HCX) present: + + - If EL3 is present and the kernel is entered at EL2: + + - SCR_EL3.HXEn (bit 38) must be initialised to 0b1. + For CPUs with Advanced SIMD and floating point support: - If EL3 is present: -- cgit v1.2.3 From 469668a58b68933ca48f616325be09685407adcb Mon Sep 17 00:00:00 2001 From: Liang Chen Date: Thu, 29 Apr 2021 16:11:42 +0800 Subject: dt-bindings: i2c: i2c-rk3x: add description for rk3568 add "rockchip,rk3568-i2c", "rockchip,rk3399-i2c" for i2c nodes on a rk3568 platform to i2c-rk3x.yaml. Signed-off-by: Liang Chen Acked-by: Rob Herring Signed-off-by: Wolfram Sang --- Documentation/devicetree/bindings/i2c/i2c-rk3x.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/i2c/i2c-rk3x.yaml b/Documentation/devicetree/bindings/i2c/i2c-rk3x.yaml index 7f254d79558c..5339dd4fc370 100644 --- a/Documentation/devicetree/bindings/i2c/i2c-rk3x.yaml +++ b/Documentation/devicetree/bindings/i2c/i2c-rk3x.yaml @@ -36,6 +36,7 @@ properties: - rockchip,px30-i2c - rockchip,rk3308-i2c - rockchip,rk3328-i2c + - rockchip,rk3568-i2c - const: rockchip,rk3399-i2c reg: -- cgit v1.2.3 From e653312b5b77d758796f90bb602068068ca1afa2 Mon Sep 17 00:00:00 2001 From: Jonathan Marek Date: Thu, 13 May 2021 13:55:17 -0400 Subject: i2c: qcom-cci: add sm8250 compatible SM8250 CCI is the same as SDM845, add an equivalent compatible for SM8250. Signed-off-by: Jonathan Marek Reviewed-by: Loic Poulain Reviewed-by: Vinod Koul Acked-by: Rob Herring Signed-off-by: Wolfram Sang --- Documentation/devicetree/bindings/i2c/i2c-qcom-cci.txt | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/i2c/i2c-qcom-cci.txt b/Documentation/devicetree/bindings/i2c/i2c-qcom-cci.txt index c6668b7c66e6..7b9fc0c22eaf 100644 --- a/Documentation/devicetree/bindings/i2c/i2c-qcom-cci.txt +++ b/Documentation/devicetree/bindings/i2c/i2c-qcom-cci.txt @@ -9,6 +9,7 @@ PROPERTIES: "qcom,msm8916-cci" "qcom,msm8996-cci" "qcom,sdm845-cci" + "qcom,sm8250-cci" - reg Usage: required @@ -41,8 +42,8 @@ PROPERTIES: SUBNODES: -The CCI provides I2C masters for one (msm8916) or two i2c busses (msm8996 and -sdm845), described as subdevices named "i2c-bus@0" and "i2c-bus@1". +The CCI provides I2C masters for one (msm8916) or two i2c busses (msm8996, +sdm845 and sm8250), described as subdevices named "i2c-bus@0" and "i2c-bus@1". PROPERTIES: -- cgit v1.2.3 From 168290fb26757d3f9732a466c59a5c45a01974f9 Mon Sep 17 00:00:00 2001 From: Alain Volmat Date: Wed, 5 May 2021 15:14:38 +0200 Subject: i2c: add binding to mark a bus as supporting SMBus-Alert Since SMBus-Alert is an optional feature of SMBUS which requires an additional pin, the smbus binding cannot be used to indicate its support. Add an additional smbus-alert binding specific for it and update the description text of smbus to avoid mentioning SMBus-Alert Signed-off-by: Alain Volmat Acked-by: Rob Herring Signed-off-by: Wolfram Sang --- Documentation/devicetree/bindings/i2c/i2c.txt | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/i2c/i2c.txt b/Documentation/devicetree/bindings/i2c/i2c.txt index df41f72afc87..b864916e087f 100644 --- a/Documentation/devicetree/bindings/i2c/i2c.txt +++ b/Documentation/devicetree/bindings/i2c/i2c.txt @@ -89,8 +89,11 @@ wants to support one of the below features, it should adapt these bindings. - smbus states that additional SMBus restrictions and features apply to this bus. - Examples of features are SMBusHostNotify and SMBusAlert. Examples of - restrictions are more reserved addresses and timeout definitions. + An example of feature is SMBusHostNotify. Examples of restrictions are + more reserved addresses and timeout definitions. + +- smbus-alert + states that the optional SMBus-Alert feature apply to this bus. Required properties (per child device) -------------------------------------- -- cgit v1.2.3 From c1d4544d0233bbccbc785bf7f45a9c66287b73c6 Mon Sep 17 00:00:00 2001 From: Martin Botka Date: Sun, 23 May 2021 23:15:54 +0200 Subject: dt-bindings: soc: qcom: smd-rpm: Document SM6125 compatible Add the SM6125 compatible to the documentation Signed-off-by: Martin Botka Link: https://lore.kernel.org/r/20210523211556.731976-3-martin.botka@somainline.org Signed-off-by: Bjorn Andersson --- Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.yaml index 2684f22a1d85..bcf6a0536d3b 100644 --- a/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.yaml +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.yaml @@ -38,6 +38,7 @@ properties: - qcom,rpm-msm8996 - qcom,rpm-msm8998 - qcom,rpm-sdm660 + - qcom,rpm-sm6125 - qcom,rpm-qcs404 qcom,smd-channels: -- cgit v1.2.3 From dfa3d406e2ab1136333d6d0f13723a0467206d1a Mon Sep 17 00:00:00 2001 From: Bjorn Andersson Date: Wed, 20 Jan 2021 14:50:36 -0800 Subject: dt-bindings: power: rpmpd: Add SC8180X to rpmpd binding Add compatible and constants for the power domains exposed by the RPMH in the Qualcomm SC8180X platform. Reviewed-by: Shawn Guo Reviewed-by: Vinod Koul Acked-by: Rob Herring Link: https://lore.kernel.org/r/20210120225037.1611353-1-bjorn.andersson@linaro.org Signed-off-by: Bjorn Andersson --- Documentation/devicetree/bindings/power/qcom,rpmpd.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml b/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml index ff21bfef8204..c01bb5f0d6ea 100644 --- a/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml +++ b/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml @@ -26,6 +26,7 @@ properties: - qcom,sdm660-rpmpd - qcom,sc7180-rpmhpd - qcom,sc7280-rpmhpd + - qcom,sc8180x-rpmhpd - qcom,sdm845-rpmhpd - qcom,sdx55-rpmhpd - qcom,sm8150-rpmhpd -- cgit v1.2.3 From 83aacfbcbd42eec3882423bbafcb8b3190376ed8 Mon Sep 17 00:00:00 2001 From: Greg Kroah-Hartman Date: Mon, 24 May 2021 10:18:15 +0200 Subject: w1: fix build warning in w1_ds2438.rst commit c999fbbdcf77 ("w1: ds2438: support for writing to offset register") added more documentation, but had a one-off line for the header of a section which caused the build warning: Documentation/w1/slaves/w1_ds2438.rst:56: WARNING: Title underline too short. Resolve this by fixing the underline to be long enough. Reported-by: Stephen Rothwell Link: https://lore.kernel.org/r/YKthRzCGan9WEcmP@kroah.com Signed-off-by: Greg Kroah-Hartman --- Documentation/w1/slaves/w1_ds2438.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/w1/slaves/w1_ds2438.rst b/Documentation/w1/slaves/w1_ds2438.rst index 5c5573991351..4fa671fbc93f 100644 --- a/Documentation/w1/slaves/w1_ds2438.rst +++ b/Documentation/w1/slaves/w1_ds2438.rst @@ -53,7 +53,7 @@ from the slave device. If it is correct, the 8 bytes page data are passed to userspace, otherwise an I/O error is returned. "offset" -------- +-------- This file controls the 2-byte Offset Register of the chip. Writing a 2-byte value will change the Offset Register, which changes the current measurement done by the chip. Changing this register to the two's complement -- cgit v1.2.3 From 6b562738a22cfdbfedaaac7db5f83c11700ebb15 Mon Sep 17 00:00:00 2001 From: Miquel Raynal Date: Mon, 10 May 2021 19:18:00 +0200 Subject: dt-binding: mtd: nand: Document the cs-gpios property To reach higher capacities, arrays of chips are now pretty common. Unfortunately, most of the controllers have been designed a decade ago and did not all anticipate the need for several chip-selects. The new cs-gpios property allows to workaround this limitation by adding as many GPIO chip-select as needed. Signed-off-by: Miquel Raynal Reviewed-by: Rob Herring Link: https://lore.kernel.org/linux-mtd/20210510171800.27225-1-miquel.raynal@bootlin.com --- .../devicetree/bindings/mtd/nand-controller.yaml | 18 +++++++++++++++++- 1 file changed, 17 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mtd/nand-controller.yaml b/Documentation/devicetree/bindings/mtd/nand-controller.yaml index 678b39952502..bd217e6f5018 100644 --- a/Documentation/devicetree/bindings/mtd/nand-controller.yaml +++ b/Documentation/devicetree/bindings/mtd/nand-controller.yaml @@ -38,6 +38,17 @@ properties: ranges: true + cs-gpios: + minItems: 1 + maxItems: 8 + description: + Array of chip-select available to the controller. The first + entries are a 1:1 mapping of the available chip-select on the + NAND controller (even if they are not used). As many additional + chip-select as needed may follow and should be phandles of GPIO + lines. 'reg' entries of the NAND chip subnodes become indexes of + this array when this property is present. + patternProperties: "^nand@[a-f0-9]$": type: object @@ -164,14 +175,19 @@ examples: nand-controller { #address-cells = <1>; #size-cells = <0>; + cs-gpios = <0>, <&gpioA 1>; /* A single native CS is available */ /* controller specific properties */ nand@0 { - reg = <0>; + reg = <0>; /* Native CS */ nand-use-soft-ecc-engine; nand-ecc-algo = "bch"; /* controller specific properties */ }; + + nand@1 { + reg = <1>; /* GPIO CS */ + }; }; -- cgit v1.2.3 From bc3aca5393c4d61d7f5ab1dd61b7f2b0536efec6 Mon Sep 17 00:00:00 2001 From: Grygorii Strashko Date: Tue, 25 May 2021 20:58:58 +0300 Subject: dt-bindings: gpio: omap: Convert to json-schema Convert the OMAP GPIO Device Tree binding documentation to json-schema. The GPIO hogs node names defined to end with a 'hog' suffix. Signed-off-by: Grygorii Strashko Reviewed-by: Rob Herring Signed-off-by: Bartosz Golaszewski --- .../devicetree/bindings/gpio/gpio-omap.txt | 45 --------- .../devicetree/bindings/gpio/ti,omap-gpio.yaml | 108 +++++++++++++++++++++ 2 files changed, 108 insertions(+), 45 deletions(-) delete mode 100644 Documentation/devicetree/bindings/gpio/gpio-omap.txt create mode 100644 Documentation/devicetree/bindings/gpio/ti,omap-gpio.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/gpio/gpio-omap.txt b/Documentation/devicetree/bindings/gpio/gpio-omap.txt deleted file mode 100644 index e57b2cb28f6c..000000000000 --- a/Documentation/devicetree/bindings/gpio/gpio-omap.txt +++ /dev/null @@ -1,45 +0,0 @@ -OMAP GPIO controller bindings - -Required properties: -- compatible: - - "ti,omap2-gpio" for OMAP2 controllers - - "ti,omap3-gpio" for OMAP3 controllers - - "ti,omap4-gpio" for OMAP4 controllers -- reg : Physical base address of the controller and length of memory mapped - region. -- gpio-controller : Marks the device node as a GPIO controller. -- #gpio-cells : Should be two. - - first cell is the pin number - - second cell is used to specify optional parameters (unused) -- interrupt-controller: Mark the device node as an interrupt controller. -- #interrupt-cells : Should be 2. - The first cell is the GPIO number. - The second cell is used to specify flags: - bits[3:0] trigger type and level flags: - 1 = low-to-high edge triggered. - 2 = high-to-low edge triggered. - 4 = active high level-sensitive. - 8 = active low level-sensitive. -- interrupts : The interrupt the controller is rising as output when an - interrupt occures - -OMAP specific properties: -- ti,hwmods: Name of the hwmod associated to the GPIO: - "gpio", being the 1-based instance number - from the HW spec. -- ti,gpio-always-on: Indicates if a GPIO bank is always powered and - so will never lose its logic state. - - -Example: - -gpio0: gpio@44e07000 { - compatible = "ti,omap4-gpio"; - reg = <0x44e07000 0x1000>; - ti,hwmods = "gpio1"; - gpio-controller; - #gpio-cells = <2>; - interrupt-controller; - #interrupt-cells = <2>; - interrupts = <96>; -}; diff --git a/Documentation/devicetree/bindings/gpio/ti,omap-gpio.yaml b/Documentation/devicetree/bindings/gpio/ti,omap-gpio.yaml new file mode 100644 index 000000000000..7087e4a5013f --- /dev/null +++ b/Documentation/devicetree/bindings/gpio/ti,omap-gpio.yaml @@ -0,0 +1,108 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/gpio/ti,omap-gpio.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: OMAP GPIO controller bindings + +maintainers: + - Grygorii Strashko + +description: | + The general-purpose interface combines general-purpose input/output (GPIO) banks. + Each GPIO banks provides up to 32 dedicated general-purpose pins with input + and output capabilities; interrupt generation in active mode and wake-up + request generation in idle mode upon the detection of external events. + +properties: + compatible: + oneOf: + - enum: + - ti,omap2-gpio + - ti,omap3-gpio + - ti,omap4-gpio + - items: + - const: ti,am4372-gpio + - const: ti,omap4-gpio + + reg: + maxItems: 1 + + gpio-controller: true + + '#gpio-cells': + const: 2 + + interrupt-controller: true + + '#interrupt-cells': + const: 2 + + interrupts: + maxItems: 1 + + gpio-ranges: true + + gpio-line-names: + minItems: 1 + maxItems: 32 + + ti,gpio-always-on: + $ref: /schemas/types.yaml#/definitions/flag + description: + Indicates if a GPIO bank is always powered and will never lose its logic state. + + ti,hwmods: + $ref: /schemas/types.yaml#/definitions/string + deprecated: true + description: + Name of the hwmod associated with the GPIO. Needed on some legacy OMAP + SoCs which have not been converted to the ti,sysc interconnect hierarachy. + + ti,no-reset-on-init: + $ref: /schemas/types.yaml#/definitions/flag + deprecated: true + description: + Do not reset on init. Used with ti,hwmods on some legacy OMAP SoCs which + have not been converted to the ti,sysc interconnect hierarachy. + +patternProperties: + "^(.+-hog(-[0-9]+)?)$": + type: object + + required: + - gpio-hog + +required: + - compatible + - reg + - gpio-controller + - "#gpio-cells" + - interrupt-controller + - "#interrupt-cells" + - interrupts + +additionalProperties: false + +examples: + - | + #include + + gpio0: gpio@0 { + compatible = "ti,omap4-gpio"; + reg = <0x0 0x1000>; + gpio-controller; + #gpio-cells = <2>; + interrupt-controller; + #interrupt-cells = <2>; + interrupts = <96>; + ti,gpio-always-on; + + ls-buf-en-hog { + gpio-hog; + gpios = <10 GPIO_ACTIVE_HIGH>; + output-high; + line-name = "LS_BUF_EN"; + }; + }; -- cgit v1.2.3 From 8939a8489ca64b56f49428b0d882709080a928d4 Mon Sep 17 00:00:00 2001 From: Chao Yu Date: Wed, 12 May 2021 10:07:19 +0800 Subject: f2fs: atgc: export entries for better tunability via sysfs This patch export below sysfs entries for better ATGC tunability. /sys/fs/f2fs//atgc_candidate_ratio /sys/fs/f2fs//atgc_candidate_count /sys/fs/f2fs//atgc_age_weight /sys/fs/f2fs//atgc_age_threshold Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim --- Documentation/ABI/testing/sysfs-fs-f2fs | 28 ++++++++++++++++++++++++++++ 1 file changed, 28 insertions(+) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-fs-f2fs b/Documentation/ABI/testing/sysfs-fs-f2fs index 4849b8e84e42..5088281e312e 100644 --- a/Documentation/ABI/testing/sysfs-fs-f2fs +++ b/Documentation/ABI/testing/sysfs-fs-f2fs @@ -438,3 +438,31 @@ Description: Show the count of inode newly enabled for compression since mount. Note that when the compression is disabled for the files, this count doesn't decrease. If you write "0" here, you can initialize compr_new_inode to "0". + +What: /sys/fs/f2fs//atgc_candidate_ratio +Date: May 2021 +Contact: "Chao Yu" +Description: When ATGC is on, it controls candidate ratio in order to limit total + number of potential victim in all candidates, the value should be in + range of [0, 100], by default it was initialized as 20(%). + +What: /sys/fs/f2fs//atgc_candidate_count +Date: May 2021 +Contact: "Chao Yu" +Description: When ATGC is on, it controls candidate count in order to limit total + number of potential victim in all candidates, by default it was + initialized as 10 (sections). + +What: /sys/fs/f2fs//atgc_age_weight +Date: May 2021 +Contact: "Chao Yu" +Description: When ATGC is on, it controls age weight to balance weight proportion + in between aging and valid blocks, the value should be in range of + [0, 100], by default it was initialized as 60(%). + +What: /sys/fs/f2fs//atgc_age_threshold +Date: May 2021 +Contact: "Chao Yu" +Description: When ATGC is on, it controls age threshold to bypass GCing young + candidates whose age is not beyond the threshold, by default it was + initialized as 604800 seconds (equals to 7 days). -- cgit v1.2.3 From 21e9f76733a8c152b794cba5463ff9bf2db919d4 Mon Sep 17 00:00:00 2001 From: Ben Widawsky Date: Wed, 26 May 2021 10:44:13 -0700 Subject: cxl: Rename mem to pci As the driver has undergone development, it's become clear that the majority [entirety?] of the current functionality in mem.c is actually a layer encapsulating functionality exposed through PCI based interactions. This layer can be used either in isolation or to provide functionality for higher level functionality. CXL capabilities exist in a parallel domain to PCIe. CXL devices are enumerable and controllable via "legacy" PCIe mechanisms; however, their CXL capabilities are a superset of PCIe. For example, a CXL device may be connected to a non-CXL capable PCIe root port, and therefore will not be able to participate in CXL.mem or CXL.cache operations, but can still be accessed through PCIe mechanisms for CXL.io operations. To properly represent the PCI nature of this driver, and in preparation for introducing a new driver for the CXL.mem / HDM decoder (Host-managed Device Memory) capabilities of a CXL memory expander, rename mem.c to pci.c so that mem.c is available for this new driver. The result of the change is that there is a clear layering distinction in the driver, and a systems administrator may load only the cxl_pci module and gain access to such operations as, firmware update, offline provisioning of devices, and error collection. In addition to freeing up the file name for another purpose, there are two primary reasons this is useful, 1. Acting upon devices which don't have full CXL capabilities. This may happen for instance if the CXL device is connected in a CXL unaware part of the platform topology. 2. Userspace-first provisioning for devices without kernel driver interference. This may be useful when provisioning a new device in a specific manner that might otherwise be blocked or prevented by the real CXL mem driver. Reviewed-by: Dan Williams Signed-off-by: Ben Widawsky Link: https://lore.kernel.org/r/20210526174413.802913-1-ben.widawsky@intel.com Signed-off-by: Dan Williams --- Documentation/driver-api/cxl/memory-devices.rst | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/driver-api/cxl/memory-devices.rst b/Documentation/driver-api/cxl/memory-devices.rst index 73f6b246c583..44c8ddbc8415 100644 --- a/Documentation/driver-api/cxl/memory-devices.rst +++ b/Documentation/driver-api/cxl/memory-devices.rst @@ -22,10 +22,10 @@ This section covers the driver infrastructure for a CXL memory device. CXL Memory Device ----------------- -.. kernel-doc:: drivers/cxl/mem.c - :doc: cxl mem +.. kernel-doc:: drivers/cxl/pci.c + :doc: cxl pci -.. kernel-doc:: drivers/cxl/mem.c +.. kernel-doc:: drivers/cxl/pci.c :internal: CXL Core -- cgit v1.2.3 From 30af8513bdb59a3e57f58f51c340130b6328b59e Mon Sep 17 00:00:00 2001 From: Lucas Stach Date: Mon, 10 May 2021 12:00:42 +0800 Subject: dt-bindings: power: add defines for i.MX8MM power domains Adding defines for i.MX8MM GPC power domains. Tested-by: Frieder Schrempf Acked-by: Rob Herring Signed-off-by: Lucas Stach Signed-off-by: Peng Fan Signed-off-by: Shawn Guo --- Documentation/devicetree/bindings/power/fsl,imx-gpcv2.yaml | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/power/fsl,imx-gpcv2.yaml b/Documentation/devicetree/bindings/power/fsl,imx-gpcv2.yaml index a96e6dbf1858..cac2869af3d0 100644 --- a/Documentation/devicetree/bindings/power/fsl,imx-gpcv2.yaml +++ b/Documentation/devicetree/bindings/power/fsl,imx-gpcv2.yaml @@ -26,6 +26,7 @@ properties: enum: - fsl,imx7d-gpc - fsl,imx8mq-gpc + - fsl,imx8mm-gpc reg: maxItems: 1 @@ -54,6 +55,7 @@ properties: Power domain index. Valid values are defined in include/dt-bindings/power/imx7-power.h for fsl,imx7d-gpc and include/dt-bindings/power/imx8m-power.h for fsl,imx8mq-gpc + include/dt-bindings/power/imx8mm-power.h for fsl,imx8mm-gpc maxItems: 1 clocks: -- cgit v1.2.3 From 70f400d4d957c2453c8689552ff212bc59f88938 Mon Sep 17 00:00:00 2001 From: Rajat Jain Date: Mon, 24 May 2021 10:18:11 -0700 Subject: driver core: Move the "removable" attribute from USB to core Move the "removable" attribute from USB to core in order to allow it to be supported by other subsystem / buses. Individual buses that want to support this attribute can populate the removable property of the device while enumerating it with the 3 possible values - - "unknown" - "fixed" - "removable" Leaving the field unchanged (i.e. "not supported") would mean that the attribute would not show up in sysfs for that device. The UAPI (location, symantics etc) for the attribute remains unchanged. Move the "removable" attribute from USB to the device core so it can be used by other subsystems / buses. By default, devices do not have a "removable" attribute in sysfs. If a subsystem or bus driver wants to support a "removable" attribute, it should call device_set_removable() before calling device_register() or device_add(), e.g.: device_set_removable(dev, DEVICE_REMOVABLE); device_register(dev); The possible values and the resulting sysfs attribute contents are: DEVICE_REMOVABLE_UNKNOWN -> "unknown" DEVICE_REMOVABLE -> "removable" DEVICE_FIXED -> "fixed" Convert the USB "removable" attribute to use this new device core functionality. There should be no user-visible change in the location or semantics of attribute for USB devices. Reviewed-by: Bjorn Helgaas Signed-off-by: Rajat Jain Link: https://lore.kernel.org/r/20210524171812.18095-1-rajatja@google.com Signed-off-by: Greg Kroah-Hartman --- Documentation/ABI/testing/sysfs-bus-usb | 11 ----------- Documentation/ABI/testing/sysfs-devices-removable | 17 +++++++++++++++++ 2 files changed, 17 insertions(+), 11 deletions(-) create mode 100644 Documentation/ABI/testing/sysfs-devices-removable (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-bus-usb b/Documentation/ABI/testing/sysfs-bus-usb index bf2c1968525f..73eb23bc1f34 100644 --- a/Documentation/ABI/testing/sysfs-bus-usb +++ b/Documentation/ABI/testing/sysfs-bus-usb @@ -154,17 +154,6 @@ Description: files hold a string value (enable or disable) indicating whether or not USB3 hardware LPM U1 or U2 is enabled for the device. -What: /sys/bus/usb/devices/.../removable -Date: February 2012 -Contact: Matthew Garrett -Description: - Some information about whether a given USB device is - physically fixed to the platform can be inferred from a - combination of hub descriptor bits and platform-specific data - such as ACPI. This file will read either "removable" or - "fixed" if the information is available, and "unknown" - otherwise. - What: /sys/bus/usb/devices/.../ltm_capable Date: July 2012 Contact: Sarah Sharp diff --git a/Documentation/ABI/testing/sysfs-devices-removable b/Documentation/ABI/testing/sysfs-devices-removable new file mode 100644 index 000000000000..acf7766e800b --- /dev/null +++ b/Documentation/ABI/testing/sysfs-devices-removable @@ -0,0 +1,17 @@ +What: /sys/devices/.../removable +Date: May 2021 +Contact: Rajat Jain +Description: + Information about whether a given device can be removed from the + platform by the user. This is determined by its subsystem in a + bus / platform-specific way. This attribute is only present for + devices that can support determining such information: + + "removable": device can be removed from the platform by the user + "fixed": device is fixed to the platform / cannot be removed + by the user. + "unknown": The information is unavailable / cannot be deduced. + + Currently this is only supported by USB (which infers the + information from a combination of hub descriptor bits and + platform-specific data such as ACPI). -- cgit v1.2.3 From c037b6c818c30b6afa11dc70018fc4a075f26028 Mon Sep 17 00:00:00 2001 From: Rajat Jain Date: Mon, 24 May 2021 10:18:12 -0700 Subject: PCI: Add sysfs "removable" attribute A PCI device is "external_facing" if it's a Root Port with the ACPI "ExternalFacingPort" property or if it has the DT "external-facing" property. We consider everything downstream from such a device to be removable by user. We're mainly concerned with consumer platforms with user accessible Thunderbolt ports that are vulnerable to DMA attacks, and we expect those ports to be identified by firmware as "ExternalFacingPort". Devices in traditional hotplug slots can technically be removed, but the expectation is that unless the port is marked with "ExternalFacingPort", such devices are less accessible to user / may not be removed by end user, and thus not exposed as "removable" to userspace. This can be used to implement userspace policies tailored for user removable devices. Eg usage: https://chromium-review.googlesource.com/c/chromiumos/platform2/+/2591812 https://chromium-review.googlesource.com/c/chromiumos/platform2/+/2795038 (code uses such an attribute to remove external PCI devices or disable features on them as needed by the policy desired) Acked-by: Bjorn Helgaas Signed-off-by: Rajat Jain Link: https://lore.kernel.org/r/20210524171812.18095-2-rajatja@google.com Signed-off-by: Greg Kroah-Hartman --- Documentation/ABI/testing/sysfs-devices-removable | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-devices-removable b/Documentation/ABI/testing/sysfs-devices-removable index acf7766e800b..bda6c320c8d3 100644 --- a/Documentation/ABI/testing/sysfs-devices-removable +++ b/Documentation/ABI/testing/sysfs-devices-removable @@ -14,4 +14,5 @@ Description: Currently this is only supported by USB (which infers the information from a combination of hub descriptor bits and - platform-specific data such as ACPI). + platform-specific data such as ACPI) and PCI (which gets this + from ACPI / device tree). -- cgit v1.2.3 From 75a78026ea1307ef6d6924cc22be3ce9bf453c63 Mon Sep 17 00:00:00 2001 From: Geert Uytterhoeven Date: Thu, 6 May 2021 19:55:53 +0200 Subject: dt-bindings: can: rcar_can: Convert to json-schema Convert the Renesas R-Car CAN Controller Device Tree binding documentation to json-schema. Document missing properties. Update the example to match reality. Link: https://lore.kernel.org/r/561c35648e22a3c1e3b5477ae27fd1a50da7fe98.1620323639.git.geert+renesas@glider.be Signed-off-by: Geert Uytterhoeven Reviewed-by: Ulrich Hecht Signed-off-by: Marc Kleine-Budde --- .../devicetree/bindings/net/can/rcar_can.txt | 80 ------------ .../bindings/net/can/renesas,rcar-can.yaml | 139 +++++++++++++++++++++ 2 files changed, 139 insertions(+), 80 deletions(-) delete mode 100644 Documentation/devicetree/bindings/net/can/rcar_can.txt create mode 100644 Documentation/devicetree/bindings/net/can/renesas,rcar-can.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/can/rcar_can.txt b/Documentation/devicetree/bindings/net/can/rcar_can.txt deleted file mode 100644 index 90ac4fef23f5..000000000000 --- a/Documentation/devicetree/bindings/net/can/rcar_can.txt +++ /dev/null @@ -1,80 +0,0 @@ -Renesas R-Car CAN controller Device Tree Bindings -------------------------------------------------- - -Required properties: -- compatible: "renesas,can-r8a7742" if CAN controller is a part of R8A7742 SoC. - "renesas,can-r8a7743" if CAN controller is a part of R8A7743 SoC. - "renesas,can-r8a7744" if CAN controller is a part of R8A7744 SoC. - "renesas,can-r8a7745" if CAN controller is a part of R8A7745 SoC. - "renesas,can-r8a77470" if CAN controller is a part of R8A77470 SoC. - "renesas,can-r8a774a1" if CAN controller is a part of R8A774A1 SoC. - "renesas,can-r8a774b1" if CAN controller is a part of R8A774B1 SoC. - "renesas,can-r8a774c0" if CAN controller is a part of R8A774C0 SoC. - "renesas,can-r8a774e1" if CAN controller is a part of R8A774E1 SoC. - "renesas,can-r8a7778" if CAN controller is a part of R8A7778 SoC. - "renesas,can-r8a7779" if CAN controller is a part of R8A7779 SoC. - "renesas,can-r8a7790" if CAN controller is a part of R8A7790 SoC. - "renesas,can-r8a7791" if CAN controller is a part of R8A7791 SoC. - "renesas,can-r8a7792" if CAN controller is a part of R8A7792 SoC. - "renesas,can-r8a7793" if CAN controller is a part of R8A7793 SoC. - "renesas,can-r8a7794" if CAN controller is a part of R8A7794 SoC. - "renesas,can-r8a7795" if CAN controller is a part of R8A7795 SoC. - "renesas,can-r8a7796" if CAN controller is a part of R8A77960 SoC. - "renesas,can-r8a77961" if CAN controller is a part of R8A77961 SoC. - "renesas,can-r8a77965" if CAN controller is a part of R8A77965 SoC. - "renesas,can-r8a77990" if CAN controller is a part of R8A77990 SoC. - "renesas,can-r8a77995" if CAN controller is a part of R8A77995 SoC. - "renesas,rcar-gen1-can" for a generic R-Car Gen1 compatible device. - "renesas,rcar-gen2-can" for a generic R-Car Gen2 or RZ/G1 - compatible device. - "renesas,rcar-gen3-can" for a generic R-Car Gen3 or RZ/G2 - compatible device. - When compatible with the generic version, nodes must list the - SoC-specific version corresponding to the platform first - followed by the generic version. - -- reg: physical base address and size of the R-Car CAN register map. -- interrupts: interrupt specifier for the sole interrupt. -- clocks: phandles and clock specifiers for 3 CAN clock inputs. -- clock-names: 3 clock input name strings: "clkp1", "clkp2", and "can_clk". -- pinctrl-0: pin control group to be used for this controller. -- pinctrl-names: must be "default". - -Required properties for R8A774A1, R8A774B1, R8A774C0, R8A774E1, R8A7795, -R8A77960, R8A77961, R8A77965, R8A77990, and R8A77995: -For the denoted SoCs, "clkp2" can be CANFD clock. This is a div6 clock and can -be used by both CAN and CAN FD controller at the same time. It needs to be -scaled to maximum frequency if any of these controllers use it. This is done -using the below properties: - -- assigned-clocks: phandle of clkp2(CANFD) clock. -- assigned-clock-rates: maximum frequency of this clock. - -Optional properties: -- renesas,can-clock-select: R-Car CAN Clock Source Select. Valid values are: - <0x0> (default) : Peripheral clock (clkp1) - <0x1> : Peripheral clock (clkp2) - <0x3> : External input clock - -Example -------- - -SoC common .dtsi file: - - can0: can@e6e80000 { - compatible = "renesas,can-r8a7791", "renesas,rcar-gen2-can"; - reg = <0 0xe6e80000 0 0x1000>; - interrupts = <0 186 IRQ_TYPE_LEVEL_HIGH>; - clocks = <&mstp9_clks R8A7791_CLK_RCAN0>, - <&cpg_clocks R8A7791_CLK_RCAN>, <&can_clk>; - clock-names = "clkp1", "clkp2", "can_clk"; - status = "disabled"; - }; - -Board specific .dts file: - -&can0 { - pinctrl-0 = <&can0_pins>; - pinctrl-names = "default"; - status = "okay"; -}; diff --git a/Documentation/devicetree/bindings/net/can/renesas,rcar-can.yaml b/Documentation/devicetree/bindings/net/can/renesas,rcar-can.yaml new file mode 100644 index 000000000000..fadc871fd6b0 --- /dev/null +++ b/Documentation/devicetree/bindings/net/can/renesas,rcar-can.yaml @@ -0,0 +1,139 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/can/renesas,rcar-can.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Renesas R-Car CAN Controller + +maintainers: + - Sergei Shtylyov + +properties: + compatible: + oneOf: + - items: + - enum: + - renesas,can-r8a7778 # R-Car M1-A + - renesas,can-r8a7779 # R-Car H1 + - const: renesas,rcar-gen1-can # R-Car Gen1 + + - items: + - enum: + - renesas,can-r8a7742 # RZ/G1H + - renesas,can-r8a7743 # RZ/G1M + - renesas,can-r8a7744 # RZ/G1N + - renesas,can-r8a7745 # RZ/G1E + - renesas,can-r8a77470 # RZ/G1C + - renesas,can-r8a7790 # R-Car H2 + - renesas,can-r8a7791 # R-Car M2-W + - renesas,can-r8a7792 # R-Car V2H + - renesas,can-r8a7793 # R-Car M2-N + - renesas,can-r8a7794 # R-Car E2 + - const: renesas,rcar-gen2-can # R-Car Gen2 and RZ/G1 + + - items: + - enum: + - renesas,can-r8a774a1 # RZ/G2M + - renesas,can-r8a774b1 # RZ/G2N + - renesas,can-r8a774c0 # RZ/G2E + - renesas,can-r8a774e1 # RZ/G2H + - renesas,can-r8a7795 # R-Car H3 + - renesas,can-r8a7796 # R-Car M3-W + - renesas,can-r8a77961 # R-Car M3-W+ + - renesas,can-r8a77965 # R-Car M3-N + - renesas,can-r8a77990 # R-Car E3 + - renesas,can-r8a77995 # R-Car D3 + - const: renesas,rcar-gen3-can # R-Car Gen3 and RZ/G2 + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 3 + + clock-names: + items: + - const: clkp1 + - const: clkp2 + - const: can_clk + + power-domains: + maxItems: 1 + + resets: + maxItems: 1 + + renesas,can-clock-select: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [ 0, 1, 3 ] + default: 0 + description: | + R-Car CAN Clock Source Select. Valid values are: + <0x0> (default) : Peripheral clock (clkp1) + <0x1> : Peripheral clock (clkp2) + <0x3> : External input clock + + assigned-clocks: + description: + Reference to the clkp2 (CANFD) clock. + On R-Car Gen3 and RZ/G2 SoCs, "clkp2" is the CANFD clock. This is a div6 + clock and can be used by both CAN and CAN FD controllers at the same + time. It needs to be scaled to maximum frequency if any of these + controllers use it. + + assigned-clock-rates: + description: Maximum frequency of the CANFD clock. + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + - power-domains + +allOf: + - $ref: can-controller.yaml# + + - if: + not: + properties: + compatible: + contains: + const: renesas,rcar-gen1-can + then: + required: + - resets + + - if: + properties: + compatible: + contains: + const: renesas,rcar-gen3-can + then: + required: + - assigned-clocks + - assigned-clock-rates + +unevaluatedProperties: false + +examples: + - | + #include + #include + #include + + can0: can@e6e80000 { + compatible = "renesas,can-r8a7791", "renesas,rcar-gen2-can"; + reg = <0xe6e80000 0x1000>; + interrupts = ; + clocks = <&cpg CPG_MOD 916>, + <&cpg CPG_CORE R8A7791_CLK_RCAN>, <&can_clk>; + clock-names = "clkp1", "clkp2", "can_clk"; + power-domains = <&sysc R8A7791_PD_ALWAYS_ON>; + resets = <&cpg 916>; + }; -- cgit v1.2.3 From 8a5e7d19c8c747e3e7bfa0283a54742b103afcb5 Mon Sep 17 00:00:00 2001 From: Geert Uytterhoeven Date: Thu, 6 May 2021 19:55:54 +0200 Subject: dt-bindings: can: rcar_canfd: Convert to json-schema Convert the Renesas R-Car CAN FD Controller Device Tree binding documentation to json-schema. Document missing properties. The CANFD clock needs to be configured for the maximum frequency on R-Car V3M and V3H, too. Update the example to match reality. Link: https://lore.kernel.org/r/905134c87f72e2d8e37c309e0ce28ecd7d4f3992.1620323639.git.geert+renesas@glider.be Signed-off-by: Geert Uytterhoeven Reviewed-by: Ulrich Hecht Signed-off-by: Marc Kleine-Budde --- .../devicetree/bindings/net/can/rcar_canfd.txt | 107 ------------------ .../bindings/net/can/renesas,rcar-canfd.yaml | 122 +++++++++++++++++++++ 2 files changed, 122 insertions(+), 107 deletions(-) delete mode 100644 Documentation/devicetree/bindings/net/can/rcar_canfd.txt create mode 100644 Documentation/devicetree/bindings/net/can/renesas,rcar-canfd.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/can/rcar_canfd.txt b/Documentation/devicetree/bindings/net/can/rcar_canfd.txt deleted file mode 100644 index 248c4ed97a0a..000000000000 --- a/Documentation/devicetree/bindings/net/can/rcar_canfd.txt +++ /dev/null @@ -1,107 +0,0 @@ -Renesas R-Car CAN FD controller Device Tree Bindings ----------------------------------------------------- - -Required properties: -- compatible: Must contain one or more of the following: - - "renesas,rcar-gen3-canfd" for R-Car Gen3 and RZ/G2 compatible controllers. - - "renesas,r8a774a1-canfd" for R8A774A1 (RZ/G2M) compatible controller. - - "renesas,r8a774b1-canfd" for R8A774B1 (RZ/G2N) compatible controller. - - "renesas,r8a774c0-canfd" for R8A774C0 (RZ/G2E) compatible controller. - - "renesas,r8a774e1-canfd" for R8A774E1 (RZ/G2H) compatible controller. - - "renesas,r8a7795-canfd" for R8A7795 (R-Car H3) compatible controller. - - "renesas,r8a7796-canfd" for R8A7796 (R-Car M3-W) compatible controller. - - "renesas,r8a77965-canfd" for R8A77965 (R-Car M3-N) compatible controller. - - "renesas,r8a77970-canfd" for R8A77970 (R-Car V3M) compatible controller. - - "renesas,r8a77980-canfd" for R8A77980 (R-Car V3H) compatible controller. - - "renesas,r8a77990-canfd" for R8A77990 (R-Car E3) compatible controller. - - "renesas,r8a77995-canfd" for R8A77995 (R-Car D3) compatible controller. - - When compatible with the generic version, nodes must list the - SoC-specific version corresponding to the platform first, followed by the - family-specific and/or generic versions. - -- reg: physical base address and size of the R-Car CAN FD register map. -- interrupts: interrupt specifiers for the Channel & Global interrupts -- clocks: phandles and clock specifiers for 3 clock inputs. -- clock-names: 3 clock input name strings: "fck", "canfd", "can_clk". -- pinctrl-0: pin control group to be used for this controller. -- pinctrl-names: must be "default". - -Required child nodes: -The controller supports two channels and each is represented as a child node. -The name of the child nodes are "channel0" and "channel1" respectively. Each -child node supports the "status" property only, which is used to -enable/disable the respective channel. - -Required properties for R8A774A1, R8A774B1, R8A774C0, R8A774E1, R8A7795, -R8A7796, R8A77965, R8A77990, and R8A77995: -In the denoted SoCs, canfd clock is a div6 clock and can be used by both CAN -and CAN FD controller at the same time. It needs to be scaled to maximum -frequency if any of these controllers use it. This is done using the below -properties: - -- assigned-clocks: phandle of canfd clock. -- assigned-clock-rates: maximum frequency of this clock. - -Optional property: -The controller can operate in either CAN FD only mode (default) or -Classical CAN only mode. The mode is global to both the channels. In order to -enable the later, define the following optional property. - - renesas,no-can-fd: puts the controller in Classical CAN only mode. - -Example -------- - -SoC common .dtsi file: - - canfd: can@e66c0000 { - compatible = "renesas,r8a7795-canfd", - "renesas,rcar-gen3-canfd"; - reg = <0 0xe66c0000 0 0x8000>; - interrupts = , - ; - clocks = <&cpg CPG_MOD 914>, - <&cpg CPG_CORE R8A7795_CLK_CANFD>, - <&can_clk>; - clock-names = "fck", "canfd", "can_clk"; - assigned-clocks = <&cpg CPG_CORE R8A7795_CLK_CANFD>; - assigned-clock-rates = <40000000>; - power-domains = <&cpg>; - status = "disabled"; - - channel0 { - status = "disabled"; - }; - - channel1 { - status = "disabled"; - }; - }; - -Board specific .dts file: - -E.g. below enables Channel 1 alone in the board in Classical CAN only mode. - -&canfd { - pinctrl-0 = <&canfd1_pins>; - pinctrl-names = "default"; - renesas,no-can-fd; - status = "okay"; - - channel1 { - status = "okay"; - }; -}; - -E.g. below enables Channel 0 alone in the board using External clock -as fCAN clock. - -&canfd { - pinctrl-0 = <&canfd0_pins>, <&can_clk_pins>; - pinctrl-names = "default"; - status = "okay"; - - channel0 { - status = "okay"; - }; -}; diff --git a/Documentation/devicetree/bindings/net/can/renesas,rcar-canfd.yaml b/Documentation/devicetree/bindings/net/can/renesas,rcar-canfd.yaml new file mode 100644 index 000000000000..0b33ba9ccb47 --- /dev/null +++ b/Documentation/devicetree/bindings/net/can/renesas,rcar-canfd.yaml @@ -0,0 +1,122 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/can/renesas,rcar-canfd.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Renesas R-Car CAN FD Controller + +maintainers: + - Fabrizio Castro + +allOf: + - $ref: can-controller.yaml# + +properties: + compatible: + oneOf: + - items: + - enum: + - renesas,r8a774a1-canfd # RZ/G2M + - renesas,r8a774b1-canfd # RZ/G2N + - renesas,r8a774c0-canfd # RZ/G2E + - renesas,r8a774e1-canfd # RZ/G2H + - renesas,r8a7795-canfd # R-Car H3 + - renesas,r8a7796-canfd # R-Car M3-W + - renesas,r8a77965-canfd # R-Car M3-N + - renesas,r8a77970-canfd # R-Car V3M + - renesas,r8a77980-canfd # R-Car V3H + - renesas,r8a77990-canfd # R-Car E3 + - renesas,r8a77995-canfd # R-Car D3 + - const: renesas,rcar-gen3-canfd # R-Car Gen3 and RZ/G2 + + reg: + maxItems: 1 + + interrupts: + items: + - description: Channel interrupt + - description: Global interrupt + + clocks: + maxItems: 3 + + clock-names: + items: + - const: fck + - const: canfd + - const: can_clk + + power-domains: + maxItems: 1 + + resets: + maxItems: 1 + + renesas,no-can-fd: + $ref: /schemas/types.yaml#/definitions/flag + description: + The controller can operate in either CAN FD only mode (default) or + Classical CAN only mode. The mode is global to both the channels. + Specify this property to put the controller in Classical CAN only mode. + + assigned-clocks: + description: + Reference to the CANFD clock. The CANFD clock is a div6 clock and can be + used by both CAN (if present) and CAN FD controllers at the same time. + It needs to be scaled to maximum frequency if any of these controllers + use it. + + assigned-clock-rates: + description: Maximum frequency of the CANFD clock. + +patternProperties: + "^channel[01]$": + type: object + description: + The controller supports two channels and each is represented as a child + node. Each child node supports the "status" property only, which + is used to enable/disable the respective channel. + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + - power-domains + - resets + - assigned-clocks + - assigned-clock-rates + - channel0 + - channel1 + +unevaluatedProperties: false + +examples: + - | + #include + #include + #include + + canfd: can@e66c0000 { + compatible = "renesas,r8a7795-canfd", + "renesas,rcar-gen3-canfd"; + reg = <0xe66c0000 0x8000>; + interrupts = , + ; + clocks = <&cpg CPG_MOD 914>, + <&cpg CPG_CORE R8A7795_CLK_CANFD>, + <&can_clk>; + clock-names = "fck", "canfd", "can_clk"; + assigned-clocks = <&cpg CPG_CORE R8A7795_CLK_CANFD>; + assigned-clock-rates = <40000000>; + power-domains = <&sysc R8A7795_PD_ALWAYS_ON>; + resets = <&cpg 914>; + + channel0 { + }; + + channel1 { + }; + }; -- cgit v1.2.3 From ab5891a8350f1a612f2aef225bff0a589bf4a395 Mon Sep 17 00:00:00 2001 From: Oleksij Rempel Date: Fri, 14 May 2021 07:17:41 +0200 Subject: dt-bindings: vendor-prefixes: Add an entry for OpenEmbed Add "openembed" entry for https://www.openembed.com/ Signed-off-by: Oleksij Rempel Acked-by: Rob Herring Signed-off-by: Thomas Bogendoerfer --- Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index b868cefc7c55..9cb628ec960b 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -830,6 +830,8 @@ patternProperties: description: Opal Kelly Incorporated "^opencores,.*": description: OpenCores.org + "^openembed,.*": + description: OpenEmbed "^openrisc,.*": description: OpenRISC.io "^option,.*": -- cgit v1.2.3 From 7652dd2c5cb7b656471cc801d619fe24120643a3 Mon Sep 17 00:00:00 2001 From: Alan Stern Date: Wed, 26 May 2021 11:32:44 -0400 Subject: USB: core: Check buffer length matches wLength for control transfers A type of inconsistency that can show up in control URBs is when the setup packet's wLength value does not match the URB's transfer_buffer_length field. The two should always be equal; differences could lead to information leaks or undefined behavior for OUT transfers or overruns for IN transfers. This patch adds a test for such mismatches during URB submission. If the test fails, the submission is rejected with a -EBADR error code (which is not used elsewhere in the USB core), and a debugging message is logged for people interested in tracking down these errors. Reviewed-by: Johan Hovold Signed-off-by: Alan Stern Link: https://lore.kernel.org/r/20210526153244.GA1400430@rowland.harvard.edu Signed-off-by: Greg Kroah-Hartman --- Documentation/driver-api/usb/error-codes.rst | 3 +++ 1 file changed, 3 insertions(+) (limited to 'Documentation') diff --git a/Documentation/driver-api/usb/error-codes.rst b/Documentation/driver-api/usb/error-codes.rst index a3e84bfac776..8f9790c2d6f8 100644 --- a/Documentation/driver-api/usb/error-codes.rst +++ b/Documentation/driver-api/usb/error-codes.rst @@ -61,6 +61,9 @@ USB-specific: (c) requested data transfer length is invalid: negative or too large for the host controller. +``-EBADR`` The wLength value in a control URB's setup packet does + not match the URB's transfer_buffer_length. + ``-ENOSPC`` This request would overcommit the usb bandwidth reserved for periodic transfers (interrupt, isochronous). -- cgit v1.2.3 From f2b0fe4b121e25bacdcfebd8a9dfd307b87142e7 Mon Sep 17 00:00:00 2001 From: Zhen Lei Date: Thu, 20 May 2021 19:54:39 +0800 Subject: dt-bindings: serial: pl011: Delete an incorrect compatible string The compatible strings "zte,zx296702-uart" and "arm,primecell" are a combination, but commit 89d4f98ae90d ("ARM: remove zte zx platform") removes only the former. It is incorrect to match driver pl011 based only on the remaining "arm,primecell". Delete it. Signed-off-by: Zhen Lei Reviewed-by: Rob Herring Documentation/devicetree/bindings/serial/pl011.yaml | 9 +++------ 1 file changed, 3 insertions(+), 6 deletions(-) Link: https://lore.kernel.org/r/20210520115440.8259-2-thunder.leizhen@huawei.com Signed-off-by: Greg Kroah-Hartman --- Documentation/devicetree/bindings/serial/pl011.yaml | 9 +++------ 1 file changed, 3 insertions(+), 6 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/serial/pl011.yaml b/Documentation/devicetree/bindings/serial/pl011.yaml index 142187337c76..5ea00f8a283d 100644 --- a/Documentation/devicetree/bindings/serial/pl011.yaml +++ b/Documentation/devicetree/bindings/serial/pl011.yaml @@ -24,12 +24,9 @@ select: properties: compatible: - oneOf: - - items: - - const: arm,pl011 - - const: arm,primecell - - items: - - const: arm,primecell + items: + - const: arm,pl011 + - const: arm,primecell reg: maxItems: 1 -- cgit v1.2.3 From 0d71f80b1898311420b4d07183a1e693c9b20c9e Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?= Date: Tue, 25 May 2021 12:00:42 +0200 Subject: driver core: auxiliary bus: Fix typo in the docs MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit My editor's spell checker noticed that one while I read through the document. Signed-off-by: Uwe Kleine-König Link: https://lore.kernel.org/r/20210525100042.951717-1-u.kleine-koenig@pengutronix.de Signed-off-by: Greg Kroah-Hartman --- Documentation/driver-api/auxiliary_bus.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/driver-api/auxiliary_bus.rst b/Documentation/driver-api/auxiliary_bus.rst index fff96c7ba7a8..ef902daf0d68 100644 --- a/Documentation/driver-api/auxiliary_bus.rst +++ b/Documentation/driver-api/auxiliary_bus.rst @@ -11,7 +11,7 @@ too complex for a single device to be managed by a monolithic driver (e.g. Sound Open Firmware), multiple devices might implement a common intersection of functionality (e.g. NICs + RDMA), or a driver may want to export an interface for another subsystem to drive (e.g. SIOV Physical Function -export Virtual Function management). A split of the functinoality into child- +export Virtual Function management). A split of the functionality into child- devices representing sub-domains of functionality makes it possible to compartmentalize, layer, and distribute domain-specific concerns via a Linux device-driver model. -- cgit v1.2.3 From 39b27e89a76f3827ad93aed9213a6daf2b91f819 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?= Date: Tue, 25 May 2021 12:37:11 +0200 Subject: driver core: Drop helper devm_platform_ioremap_resource_wc() MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Since the macro was introduced in 2019 (commit bb6243b4f73d ("drivers: platform: provide devm_platform_ioremap_resource_wc()") there is only a single user which hardly justifies the function for the small task it provides. So drop the helper and open-code it in the only user. Adapt the non-wc case accordingly. For a all-mod-config build on amd64 this change introduces the following changes according to bloat-o-meter: add/remove: 0/1 grow/shrink: 1/0 up/down: 20/-252 (-232) Function old new delta devm_platform_ioremap_resource_wc 252 - -252 sram_probe 796 816 +20 Signed-off-by: Uwe Kleine-König Link: https://lore.kernel.org/r/20210525103711.956438-1-u.kleine-koenig@pengutronix.de Signed-off-by: Greg Kroah-Hartman --- Documentation/driver-api/driver-model/devres.rst | 1 - 1 file changed, 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/driver-api/driver-model/devres.rst b/Documentation/driver-api/driver-model/devres.rst index e0814d214048..0fe1fffa295e 100644 --- a/Documentation/driver-api/driver-model/devres.rst +++ b/Documentation/driver-api/driver-model/devres.rst @@ -314,7 +314,6 @@ IOMAP devm_ioremap_resource() : checks resource, requests memory region, ioremaps devm_ioremap_resource_wc() devm_platform_ioremap_resource() : calls devm_ioremap_resource() for platform device - devm_platform_ioremap_resource_wc() devm_platform_ioremap_resource_byname() devm_platform_get_and_ioremap_resource() devm_iounmap() -- cgit v1.2.3 From 8b4c397d88d97d4fd9c3f3527aa66688b1a3387a Mon Sep 17 00:00:00 2001 From: Fabien Parent Date: Wed, 19 May 2021 18:24:06 +0200 Subject: dt-bindings: pinctrl: mt65xx: add mt8365 SoC binding Add binding documentation for MT8365 Pin controller. Signed-off-by: Fabien Parent Acked-by: Rob Herring Link: https://lore.kernel.org/r/20210519162409.3755679-1-fparent@baylibre.com Signed-off-by: Linus Walleij --- Documentation/devicetree/bindings/pinctrl/pinctrl-mt65xx.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-mt65xx.txt b/Documentation/devicetree/bindings/pinctrl/pinctrl-mt65xx.txt index 360e59c9301a..5fe2c26c28bf 100644 --- a/Documentation/devicetree/bindings/pinctrl/pinctrl-mt65xx.txt +++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-mt65xx.txt @@ -12,6 +12,7 @@ Required properties: "mediatek,mt8135-pinctrl", compatible with mt8135 pinctrl. "mediatek,mt8167-pinctrl", compatible with mt8167 pinctrl. "mediatek,mt8173-pinctrl", compatible with mt8173 pinctrl. + "mediatek,mt8365-pinctrl", compatible with mt8365 pinctrl. "mediatek,mt8516-pinctrl", compatible with mt8516 pinctrl. - pins-are-numbered: Specify the subnodes are using numbered pinmux to specify pins. -- cgit v1.2.3 From f7ebe6b76940f873645ff110192b08e64334a112 Mon Sep 17 00:00:00 2001 From: Akira Yokosawa Date: Wed, 26 May 2021 00:25:39 +0900 Subject: docs: Activate exCJK only in CJK chapters Activating xeCJK in English and Italian-translation documents results in sub-optimal typesetting with wide-looking apostrophes and quotation marks. The xeCJK package provides macros for enabling and disabling its effect in the middle of a document, namely \makexeCJKactive and \makexeCJKinactive. So the goal of this change is to activate xeCJK in the relevant chapters in translations. To do this: o Define custom macros in the preamble depending on the availability of the "Noto Sans CJK" font so that those macros can be used regardless of the use of xeCJK package. o Patch \sphinxtableofcontents so that xeCJK is inactivated after table of contents. o Embed those custom macros in each language's index.rst file as a ".. raw:: latex" construct. Note: A CJK chapter needs \kerneldocCJKon in front of its chapter heading, while a non-CJK chapter should have \kerneldocCJKoff below its chapter heading. This is to make sure the CJK font is available to CJK chapter's heading and ending page's footer. Tested against Sphinx versions 2.4.4 and 4.0.2. Signed-off-by: Akira Yokosawa Tested-by: Wu XiangCheng Reviewed-by: Mauro Carvalho Chehab Link: https://lore.kernel.org/lkml/2061da0a-6ab1-35f3-99c1-dbc415444f37@gmail.com Link: https://lore.kernel.org/r/83208ddc-5de9-b283-3fd6-92c635348ca0@gmail.com Signed-off-by: Jonathan Corbet --- Documentation/conf.py | 13 +++++++++++++ Documentation/translations/index.rst | 4 ++++ Documentation/translations/it_IT/index.rst | 4 ++++ Documentation/translations/ja_JP/index.rst | 5 +++-- Documentation/translations/ko_KR/index.rst | 5 +++-- Documentation/translations/zh_CN/index.rst | 1 + 6 files changed, 28 insertions(+), 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/conf.py b/Documentation/conf.py index 879e86dbea66..25aa00c707b0 100644 --- a/Documentation/conf.py +++ b/Documentation/conf.py @@ -371,6 +371,19 @@ if cjk_cmd.find("Noto Sans CJK SC") >= 0: % This is needed for translations \\usepackage{xeCJK} \\setCJKmainfont{Noto Sans CJK SC} + % Define custom macros to on/off CJK + \\newcommand{\\kerneldocCJKon}{\\makexeCJKactive} + \\newcommand{\\kerneldocCJKoff}{\\makexeCJKinactive} + % To customize \sphinxtableofcontents + \\usepackage{etoolbox} + % Inactivate CJK after tableofcontents + \\apptocmd{\\sphinxtableofcontents}{\\kerneldocCJKoff}{}{} + ''' +else: + latex_elements['preamble'] += ''' + % Custom macros to on/off CJK (Dummy) + \\newcommand{\\kerneldocCJKon}{} + \\newcommand{\\kerneldocCJKoff}{} ''' # Fix reference escape troubles with Sphinx 1.4.x diff --git a/Documentation/translations/index.rst b/Documentation/translations/index.rst index e446e5ed00a6..556b050884fc 100644 --- a/Documentation/translations/index.rst +++ b/Documentation/translations/index.rst @@ -18,6 +18,10 @@ Translations Disclaimer ---------- +.. raw:: latex + + \kerneldocCJKoff + Translation's purpose is to ease reading and understanding in languages other than English. Its aim is to help people who do not understand English or have doubts about its interpretation. Additionally, some people prefer to read diff --git a/Documentation/translations/it_IT/index.rst b/Documentation/translations/it_IT/index.rst index bb8fa7346939..e80a3097aa57 100644 --- a/Documentation/translations/it_IT/index.rst +++ b/Documentation/translations/it_IT/index.rst @@ -4,6 +4,10 @@ Traduzione italiana =================== +.. raw:: latex + + \kerneldocCJKoff + :manutentore: Federico Vaga .. _it_disclaimer: diff --git a/Documentation/translations/ja_JP/index.rst b/Documentation/translations/ja_JP/index.rst index 2f91b895e3c2..f94ba62d41c3 100644 --- a/Documentation/translations/ja_JP/index.rst +++ b/Documentation/translations/ja_JP/index.rst @@ -1,7 +1,8 @@ .. raw:: latex - \renewcommand\thesection* - \renewcommand\thesubsection* + \renewcommand\thesection* + \renewcommand\thesubsection* + \kerneldocCJKon Japanese translations ===================== diff --git a/Documentation/translations/ko_KR/index.rst b/Documentation/translations/ko_KR/index.rst index b9e27d20b039..6ae258118bdf 100644 --- a/Documentation/translations/ko_KR/index.rst +++ b/Documentation/translations/ko_KR/index.rst @@ -1,7 +1,8 @@ .. raw:: latex - \renewcommand\thesection* - \renewcommand\thesubsection* + \renewcommand\thesection* + \renewcommand\thesubsection* + \kerneldocCJKon 한국어 번역 =========== diff --git a/Documentation/translations/zh_CN/index.rst b/Documentation/translations/zh_CN/index.rst index a736057da41f..1f953d3439a5 100644 --- a/Documentation/translations/zh_CN/index.rst +++ b/Documentation/translations/zh_CN/index.rst @@ -4,6 +4,7 @@ \renewcommand\thesection* \renewcommand\thesubsection* + \kerneldocCJKon .. _linux_doc_zh: -- cgit v1.2.3 From b77e4c4e655b455c4aba196838d1102c0e3414a4 Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Tue, 25 May 2021 14:23:52 +0200 Subject: iio: ABI: sysfs-bus-iio: fix a typo Descrption -> Description This causes some errors when parsed via scripts/get_abi.pl. Signed-off-by: Mauro Carvalho Chehab Acked-by: Jonathan Cameron Link: https://lore.kernel.org/r/fa90a2deebac80da42b1ad4cf570c4ace436577d.1621944866.git.mchehab+huawei@kernel.org Signed-off-by: Jonathan Corbet --- Documentation/ABI/testing/sysfs-bus-iio | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-bus-iio b/Documentation/ABI/testing/sysfs-bus-iio index 267973541e72..433fe0ab74be 100644 --- a/Documentation/ABI/testing/sysfs-bus-iio +++ b/Documentation/ABI/testing/sysfs-bus-iio @@ -786,7 +786,7 @@ What: /sys/.../events/in_capacitanceY_adaptive_thresh_rising_en What: /sys/.../events/in_capacitanceY_adaptive_thresh_falling_en KernelVersion: 5.13 Contact: linux-iio@vger.kernel.org -Descrption: +Description: Adaptive thresholds are similar to normal fixed thresholds but the value is expressed as an offset from a value which provides a low frequency approximation of the channel itself. @@ -798,7 +798,7 @@ What: /sys/.../in_capacitanceY_adaptive_thresh_rising_timeout What: /sys/.../in_capacitanceY_adaptive_thresh_falling_timeout KernelVersion: 5.11 Contact: linux-iio@vger.kernel.org -Descrption: +Description: When adaptive thresholds are used, the tracking signal may adjust too slowly to step changes in the raw signal. *_timeout (in seconds) specifies a time for which the -- cgit v1.2.3 From 1e03fe240512621605ec47f93dc29994026a2984 Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Tue, 25 May 2021 14:23:53 +0200 Subject: iio: ABI: sysfs-bus-iio: avoid a warning when doc is built The description of those vars produce this warning: Documentation/ABI/testing/sysfs-bus-iio:799: WARNING: Inline emphasis start-string without end-string. Due to an asterisk, which is the markup for emphasis. One possible fix would be to use ``*_timeout`` to avoid it, but looking at the descriptions of other fields in this file, a common pattern is to refer to "these" when talking about the API calls that are described. So, change the text in order to preserve the meaning while avoiding the need of using an asterisk there. Reported-by: Jonathan Corbet Reported-by: Matthew Wilcox Signed-off-by: Mauro Carvalho Chehab Acked-by: Jonathan Cameron Link: https://lore.kernel.org/r/dbf0d94f85217f103d77dc8389c8db272f5702d2.1621944866.git.mchehab+huawei@kernel.org [jc fixed specifiy->specify] Signed-off-by: Jonathan Corbet --- Documentation/ABI/testing/sysfs-bus-iio | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-bus-iio b/Documentation/ABI/testing/sysfs-bus-iio index 433fe0ab74be..6f98b6a9b785 100644 --- a/Documentation/ABI/testing/sysfs-bus-iio +++ b/Documentation/ABI/testing/sysfs-bus-iio @@ -801,7 +801,7 @@ Contact: linux-iio@vger.kernel.org Description: When adaptive thresholds are used, the tracking signal may adjust too slowly to step changes in the raw signal. - *_timeout (in seconds) specifies a time for which the + Thus these specify the time in seconds for which the difference between the slow tracking signal and the raw signal is allowed to remain out-of-range before a reset event occurs in which the tracking signal is made equal -- cgit v1.2.3 From 544ef682c60484151292eb04183e44a9dd6bb0de Mon Sep 17 00:00:00 2001 From: Barry Song Date: Mon, 24 May 2021 17:17:15 +1200 Subject: docs: kernel-parameters: mark numa=off is supported by a bundle of architectures risc-v and arm64 support numa=off by common arch_numa_init() in drivers/base/arch_numa.c. x86, ppc, mips, sparc support it by arch-level early_param. numa=off is widely used in linux distributions. it is better to document it. Signed-off-by: Barry Song Link: https://lore.kernel.org/r/20210524051715.13604-1-song.bao.hua@hisilicon.com Signed-off-by: Jonathan Corbet --- 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 cb89dbdedc46..a388fbdaa2ec 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -3513,6 +3513,9 @@ nr_uarts= [SERIAL] maximum number of UARTs to be registered. + numa=off [KNL, ARM64, PPC, RISCV, SPARC, X86] Disable NUMA, Only + set up a single NUMA node spanning all memory. + numa_balancing= [KNL,ARM64,PPC,RISCV,S390,X86] Enable or disable automatic NUMA balancing. Allowed values are enable and disable -- cgit v1.2.3 From 811c3c4723cc2309654c58e8615c775d41ac53ef Mon Sep 17 00:00:00 2001 From: Yanteng Si Date: Mon, 24 May 2021 10:40:16 +0800 Subject: docs/zh_CN:add core-api refcount-vs-atomic.rst translation. Translate Documentation/core-api/refcount-vs-atomic.rst into Chinese. Signed-off-by: Yanteng Si Reviewed-by: Wu XiangCheng Link: https://lore.kernel.org/r/cbdd1d8b23b8ce6dff0a98a0d89b78673365aa28.1621823299.git.siyanteng@loongson.cn Signed-off-by: Jonathan Corbet --- .../translations/zh_CN/core-api/index.rst | 3 +- .../zh_CN/core-api/refcount-vs-atomic.rst | 154 +++++++++++++++++++++ 2 files changed, 156 insertions(+), 1 deletion(-) create mode 100644 Documentation/translations/zh_CN/core-api/refcount-vs-atomic.rst (limited to 'Documentation') diff --git a/Documentation/translations/zh_CN/core-api/index.rst b/Documentation/translations/zh_CN/core-api/index.rst index a1dd792e46f7..90c9a72a4b0e 100644 --- a/Documentation/translations/zh_CN/core-api/index.rst +++ b/Documentation/translations/zh_CN/core-api/index.rst @@ -65,10 +65,11 @@ Linux如何让一切同时发生。 详情请参阅 :maxdepth: 1 irq/index + refcount-vs-atomic + Todolist: - refcount-vs-atomic local_ops padata ../RCU/index diff --git a/Documentation/translations/zh_CN/core-api/refcount-vs-atomic.rst b/Documentation/translations/zh_CN/core-api/refcount-vs-atomic.rst new file mode 100644 index 000000000000..ea834e38d2f6 --- /dev/null +++ b/Documentation/translations/zh_CN/core-api/refcount-vs-atomic.rst @@ -0,0 +1,154 @@ +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/core-api/refcount-vs-atomic.rst +:Translator: Yanteng Si + +.. _cn_refcount-vs-atomic: + + +======================================= +与atomic_t相比，refcount_t的API是这样的 +======================================= + +.. contents:: :local: + +简介 +==== + +refcount_t API的目标是为实现对象的引用计数器提供一个最小的API。虽然来自 +lib/refcount.c的独立于架构的通用实现在下面使用了原子操作，但一些 ``refcount_*()`` +和 ``atomic_*()`` 函数在内存顺序保证方面有很多不同。本文档概述了这些差异，并 +提供了相应的例子，以帮助开发者根据这些内存顺序保证的变化来验证他们的代码。 + +本文档中使用的术语尽量遵循tools/memory-model/Documentation/explanation.txt +中定义的正式LKMM。 + +memory-barriers.txt和atomic_t.txt提供了更多关于内存顺序的背景，包括通用的 +和针对原子操作的。 + +内存顺序的相关类型 +================== + +.. note:: 下面的部分只涵盖了本文使用的与原子操作和引用计数器有关的一些内存顺 + 序类型。如果想了解更广泛的情况，请查阅memory-barriers.txt文件。 + +在没有任何内存顺序保证的情况下（即完全无序），atomics和refcounters只提供原 +子性和程序顺序（program order, po）关系（在同一个CPU上）。它保证每个 +``atomic_* ()`` 和 ``refcount_*()`` 操作都是原子性的，指令在单个CPU上按程序 +顺序执行。这是用READ_ONCE()/WRITE_ONCE()和比较并交换原语实现的。 + +强（完全）内存顺序保证在同一CPU上的所有较早加载和存储的指令（所有程序顺序较早 +[po-earlier]指令）在执行任何程序顺序较后指令（po-later）之前完成。它还保证 +同一CPU上储存的程序优先较早的指令和来自其他CPU传播的指令必须在该CPU执行任何 +程序顺序较后指令之前传播到其他CPU（A-累积属性）。这是用smp_mb()实现的。 + +RELEASE内存顺序保证了在同一CPU上所有较早加载和存储的指令（所有程序顺序较早 +指令）在此操作前完成。它还保证同一CPU上储存的程序优先较早的指令和来自其他CPU +传播的指令必须在释放（release）操作之前传播到所有其他CPU（A-累积属性）。这是用 +smp_store_release()实现的。 + +ACQUIRE内存顺序保证了同一CPU上的所有后加载和存储的指令（所有程序顺序较后 +指令）在获取（acquire）操作之后完成。它还保证在获取操作执行后，同一CPU上 +储存的所有程序顺序较后指令必须传播到所有其他CPU。这是用 +smp_acquire__after_ctrl_dep()实现的。 + +对Refcounters的控制依赖（取决于成功）保证了如果一个对象的引用被成功获得（引用计数 +器的增量或增加行为发生了，函数返回true），那么进一步的存储是针对这个操作的命令。对存 +储的控制依赖没有使用任何明确的屏障来实现，而是依赖于CPU不对存储进行猜测。这只是 +一个单一的CPU关系，对其他CPU不提供任何保证。 + + +函数的比较 +========== + +情况1） - 非 “读/修改/写”（RMW）操作 +------------------------------------ + +函数变化: + + * atomic_set() --> refcount_set() + * atomic_read() --> refcount_read() + +内存顺序保证变化: + + * none (两者都是完全无序的) + + +情况2） - 基于增量的操作，不返回任何值 +-------------------------------------- + +函数变化: + + * atomic_inc() --> refcount_inc() + * atomic_add() --> refcount_add() + +内存顺序保证变化: + + * none (两者都是完全无序的) + +情况3） - 基于递减的RMW操作，没有返回值 +--------------------------------------- + +函数变化: + + * atomic_dec() --> refcount_dec() + +内存顺序保证变化: + + * 完全无序的 --> RELEASE顺序 + + +情况4） - 基于增量的RMW操作，返回一个值 +--------------------------------------- + +函数变化: + + * atomic_inc_not_zero() --> refcount_inc_not_zero() + * 无原子性对应函数 --> refcount_add_not_zero() + +内存顺序保证变化: + + * 完全有序的 --> 控制依赖于存储的成功 + +.. note:: 此处 **假设** 了，必要的顺序是作为获得对象指针的结果而提供的。 + + +情况 5） - 基于Dec/Sub递减的通用RMW操作，返回一个值 +--------------------------------------------------- + +函数变化: + + * atomic_dec_and_test() --> refcount_dec_and_test() + * atomic_sub_and_test() --> refcount_sub_and_test() + +内存顺序保证变化: + + * 完全有序的 --> RELEASE顺序 + 成功后ACQUIRE顺序 + + +情况6）其他基于递减的RMW操作，返回一个值 +---------------------------------------- + +函数变化: + + * 无原子性对应函数 --> refcount_dec_if_one() + * ``atomic_add_unless(&var, -1, 1)`` --> ``refcount_dec_not_one(&var)`` + +内存顺序保证变化: + + * 完全有序的 --> RELEASE顺序 + 控制依赖 + +.. note:: atomic_add_unless()只在执行成功时提供完整的顺序。 + + +情况7）--基于锁的RMW +-------------------- + +函数变化: + + * atomic_dec_and_lock() --> refcount_dec_and_lock() + * atomic_dec_and_mutex_lock() --> refcount_dec_and_mutex_lock() + +内存顺序保证变化: + + * 完全有序 --> RELEASE顺序 + 控制依赖 + 持有 -- cgit v1.2.3 From 8de8fe4f5db6b6bdaf23977f4d165f8c4e94f4ce Mon Sep 17 00:00:00 2001 From: Yanteng Si Date: Mon, 24 May 2021 10:40:17 +0800 Subject: docs/zh_CN: add core api local_ops.rst translation Translate Documentation/core-api/local_ops.rst into Chinese. Signed-off-by: Yanteng Si Reviewed-by: Wu XiangCheng Link: https://lore.kernel.org/r/11da5738679fbab9e875f434745d16db1f167f90.1621823299.git.siyanteng@loongson.cn Signed-off-by: Jonathan Corbet --- .../translations/zh_CN/core-api/index.rst | 3 +- .../translations/zh_CN/core-api/local_ops.rst | 194 +++++++++++++++++++++ 2 files changed, 195 insertions(+), 2 deletions(-) create mode 100644 Documentation/translations/zh_CN/core-api/local_ops.rst (limited to 'Documentation') diff --git a/Documentation/translations/zh_CN/core-api/index.rst b/Documentation/translations/zh_CN/core-api/index.rst index 90c9a72a4b0e..4b7efb7edb18 100644 --- a/Documentation/translations/zh_CN/core-api/index.rst +++ b/Documentation/translations/zh_CN/core-api/index.rst @@ -66,11 +66,10 @@ Linux如何让一切同时发生。 详情请参阅 irq/index refcount-vs-atomic - + local_ops Todolist: - local_ops padata ../RCU/index diff --git a/Documentation/translations/zh_CN/core-api/local_ops.rst b/Documentation/translations/zh_CN/core-api/local_ops.rst new file mode 100644 index 000000000000..ee67379b6869 --- /dev/null +++ b/Documentation/translations/zh_CN/core-api/local_ops.rst @@ -0,0 +1,194 @@ +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/core-api/local_ops.rst +:Translator: Yanteng Si + +.. _cn_local_ops: + + +======================== +本地原子操作的语义和行为 +======================== + +:作者: Mathieu Desnoyers + + +本文解释了本地原子操作的目的，如何为任何给定的架构实现这些操作，并说明了 +如何正确使用这些操作。它还强调了在内存写入顺序很重要的情况下，跨CPU读取 +这些本地变量时必须采取的预防措施。 + +.. note:: + + 注意，基于 ``local_t`` 的操作不建议用于一般内核操作。请使用 ``this_cpu`` + 操作来代替使用，除非真的有特殊目的。大多数内核中使用的 ``local_t`` 已 + 经被 ``this_cpu`` 操作所取代。 ``this_cpu`` 操作在一条指令中结合了重 + 定位和类似 ``local_t`` 的语义，产生了更紧凑和更快的执行代码。 + + +本地原子操作的目的 +================== + +本地原子操作的目的是提供快速和高度可重入的每CPU计数器。它们通过移除LOCK前 +缀和通常需要在CPU间同步的内存屏障，将标准原子操作的性能成本降到最低。 + +在许多情况下，拥有快速的每CPU原子计数器是很有吸引力的：它不需要禁用中断来保护中 +断处理程序，它允许在NMI（Non Maskable Interrupt）处理程序中使用连贯的计数器。 +它对追踪目的和各种性能监测计数器特别有用。 + +本地原子操作只保证在拥有数据的CPU上的变量修改的原子性。因此，必须注意确保只 +有一个CPU写到 ``local_t`` 的数据。这是通过使用每CPU的数据来实现的，并确 +保我们在一个抢占式安全上下文中修改它。然而，从任何一个CPU读取 ``local_t`` +数据都是允许的：这样它就会显得与所有者CPU的其他内存写入顺序不一致。 + + +针对特定架构的实现 +================== + +这可以通过稍微修改标准的原子操作来实现：只有它们的UP变体必须被保留。这通常 +意味着删除LOCK前缀（在i386和x86_64上）和任何SMP同步屏障。如果架构在SMP和 +UP之间没有不同的行为，在你的架构的 ``local.h`` 中包括 ``asm-generic/local.h`` +就足够了。 + +通过在一个结构体中嵌入一个 ``atomic_long_t`` ， ``local_t`` 类型被定义为 +一个不透明的 ``signed long`` 。这样做的目的是为了使从这个类型到 +``long`` 的转换失败。该定义看起来像:: + + typedef struct { atomic_long_t a; } local_t; + + +使用本地原子操作时应遵循的规则 +============================== + +* 被本地操作触及的变量必须是每cpu的变量。 + +* *只有* 这些变量的CPU所有者才可以写入这些变量。 + +* 这个CPU可以从任何上下文（进程、中断、软中断、nmi...）中使用本地操作来更新 + 它的local_t变量。 + +* 当在进程上下文中使用本地操作时，必须禁用抢占（或中断），以确保进程在获得每 + CPU变量和进行实际的本地操作之间不会被迁移到不同的CPU。 + +* 当在中断上下文中使用本地操作时，在主线内核上不需要特别注意，因为它们将在局 + 部CPU上运行，并且已经禁用了抢占。然而，我建议无论如何都要明确地禁用抢占， + 以确保它在-rt内核上仍能正确工作。 + +* 读取本地cpu变量将提供该变量的当前拷贝。 + +* 对这些变量的读取可以从任何CPU进行，因为对 “ ``long`` ”，对齐的变量的更新 + 总是原子的。由于写入程序的CPU没有进行内存同步，所以在读取 *其他* cpu的变 + 量时，可以读取该变量的过期副本。 + + +如何使用本地原子操作 +==================== + +:: + + #include + #include + + static DEFINE_PER_CPU(local_t, counters) = LOCAL_INIT(0); + + +计数器 +====== + +计数是在一个signed long的所有位上进行的。 + +在可抢占的上下文中，围绕本地原子操作使用 ``get_cpu_var()`` 和 +``put_cpu_var()`` ：它确保在对每个cpu变量进行写访问时，抢占被禁用。比如 +说:: + + local_inc(&get_cpu_var(counters)); + put_cpu_var(counters); + +如果你已经在一个抢占安全上下文中，你可以使用 ``this_cpu_ptr()`` 代替:: + + local_inc(this_cpu_ptr(&counters)); + + + +读取计数器 +========== + +那些本地计数器可以从外部的CPU中读取，以求得计数的总和。请注意，local_read +所看到的跨CPU的数据必须被认为是相对于拥有该数据的CPU上发生的其他内存写入来 +说不符合顺序的:: + + long sum = 0; + for_each_online_cpu(cpu) + sum += local_read(&per_cpu(counters, cpu)); + +如果你想使用远程local_read来同步CPU之间对资源的访问，必须在写入者和读取者 +的CPU上分别使用显式的 ``smp_wmb()`` 和 ``smp_rmb()`` 内存屏障。如果你使 +用 ``local_t`` 变量作为写在缓冲区中的字节的计数器，就会出现这种情况：在缓 +冲区写和计数器增量之间应该有一个 ``smp_wmb()`` ，在计数器读和缓冲区读之间 +也应有一个 ``smp_rmb()`` 。 + +下面是一个使用 ``local.h`` 实现每个cpu基本计数器的示例模块:: + + /* test-local.c + * + * Sample module for local.h usage. + */ + + + #include + #include + #include + + static DEFINE_PER_CPU(local_t, counters) = LOCAL_INIT(0); + + static struct timer_list test_timer; + + /* IPI called on each CPU. */ + static void test_each(void *info) + { + /* Increment the counter from a non preemptible context */ + printk("Increment on cpu %d\n", smp_processor_id()); + local_inc(this_cpu_ptr(&counters)); + + /* This is what incrementing the variable would look like within a + * preemptible context (it disables preemption) : + * + * local_inc(&get_cpu_var(counters)); + * put_cpu_var(counters); + */ + } + + static void do_test_timer(unsigned long data) + { + int cpu; + + /* Increment the counters */ + on_each_cpu(test_each, NULL, 1); + /* Read all the counters */ + printk("Counters read from CPU %d\n", smp_processor_id()); + for_each_online_cpu(cpu) { + printk("Read : CPU %d, count %ld\n", cpu, + local_read(&per_cpu(counters, cpu))); + } + mod_timer(&test_timer, jiffies + 1000); + } + + static int __init test_init(void) + { + /* initialize the timer that will increment the counter */ + timer_setup(&test_timer, do_test_timer, 0); + mod_timer(&test_timer, jiffies + 1); + + return 0; + } + + static void __exit test_exit(void) + { + del_timer_sync(&test_timer); + } + + module_init(test_init); + module_exit(test_exit); + + MODULE_LICENSE("GPL"); + MODULE_AUTHOR("Mathieu Desnoyers"); + MODULE_DESCRIPTION("Local Atomic Ops"); -- cgit v1.2.3 From c8237760cc56c79e04a6a47696ef8bb0aab8c77a Mon Sep 17 00:00:00 2001 From: Yanteng Si Date: Mon, 24 May 2021 10:23:08 +0800 Subject: docs: zh_CN: update Chinese translations Two new commits were added to the original document: commit ddba35031db2ea89facc91c745e5ad55ba2e0e7f commit 20bc8c1e972f29afcac85e524e430c11a6df5f58 translate them into Chinese. Signed-off-by: Yanteng Si Reviewed-by: Wu XiangCheng Link: https://lore.kernel.org/r/20210524022308.1216098-1-siyanteng@loongson.cn Signed-off-by: Jonathan Corbet --- .../translations/zh_CN/core-api/printk-formats.rst | 17 ++++++++++++++++- 1 file changed, 16 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/translations/zh_CN/core-api/printk-formats.rst b/Documentation/translations/zh_CN/core-api/printk-formats.rst index 624a090e6ee5..a680c8f164c3 100644 --- a/Documentation/translations/zh_CN/core-api/printk-formats.rst +++ b/Documentation/translations/zh_CN/core-api/printk-formats.rst @@ -122,6 +122,17 @@ seq_printf()，而不是printk()）由用户空间进程读取，使用下面描 ``B`` 占位符的结果是带有偏移量的符号名，在打印堆栈回溯时应该使用。占位符将考虑编译器优化 的影响，当使用尾部调用并使用noreturn GCC属性标记时，可能会发生这种优化。 +如果指针在一个模块内，模块名称和可选的构建ID将被打印在符号名称之后，并在说明符的末尾添加 +一个额外的 ``b`` 。 + +:: + + %pS versatile_init+0x0/0x110 [module_name] + %pSb versatile_init+0x0/0x110 [module_name ed5019fdf5e53be37cb1ba7899292d7e143b259e] + %pSRb versatile_init+0x9/0x110 [module_name ed5019fdf5e53be37cb1ba7899292d7e143b259e] + (with __builtin_extract_return_addr() translation) + %pBb prev_fn_of_versatile_init+0x88/0x88 [module_name ed5019fdf5e53be37cb1ba7899292d7e143b259e] + 来自BPF / tracing追踪的探查指针 ---------------------------------- @@ -483,9 +494,10 @@ Fwnode handles :: %pt[RT] YYYY-mm-ddTHH:MM:SS + %pt[RT]s YYYY-mm-dd HH:MM:SS %pt[RT]d YYYY-mm-dd %pt[RT]t HH:MM:SS - %pt[RT][dt][r] + %pt[RT][dt][r][s] 用于打印日期和时间:: @@ -497,6 +509,9 @@ Fwnode handles 默认情况下，年将以1900为单位递增，月将以1为单位递增。 使用%pt[RT]r (raw) 来抑制这种行为。 +%pt[RT]s（空格）将覆盖ISO 8601的分隔符，在日期和时间之间使用''（空格）而 +不是'T'（大写T）。当日期或时间被省略时，它不会有任何影响。 + 通过引用传递。 clk结构体 -- cgit v1.2.3 From 89be5957e7ec300cae7af4059db69a0e1f45662d Mon Sep 17 00:00:00 2001 From: Steven Lee Date: Tue, 25 May 2021 13:53:05 +0800 Subject: dt-bindings: pinctrl: Update enum for adding SGPM2 and SGPS2 AST2600 has 2 SGPIO master interfaces one with 128 pins and another one has 80 pins. It also supports 2 SGPIO slave interfaces. In the current bindings, there are only SGPM1 and SGPS1 defined in enum, SGPM2 and SGPS2 should also be added in the bindings. Signed-off-by: Steven Lee Reviewed-by: Andrew Jeffery Link: https://lore.kernel.org/r/20210525055308.31069-2-steven_lee@aspeedtech.com Signed-off-by: Linus Walleij --- .../devicetree/bindings/pinctrl/aspeed,ast2600-pinctrl.yaml | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pinctrl/aspeed,ast2600-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/aspeed,ast2600-pinctrl.yaml index ad91c0bc54da..ad2866c99738 100644 --- a/Documentation/devicetree/bindings/pinctrl/aspeed,ast2600-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/aspeed,ast2600-pinctrl.yaml @@ -46,8 +46,8 @@ patternProperties: PWM9, RGMII1, RGMII2, RGMII3, RGMII4, RMII1, RMII2, RMII3, RMII4, RXD1, RXD2, RXD3, RXD4, SALT1, SALT10, SALT11, SALT12, SALT13, SALT14, SALT15, SALT16, SALT2, SALT3, SALT4, SALT5, SALT6, SALT7, SALT8, - SALT9, SD1, SD2, SGPM1, SGPS1, SIOONCTRL, SIOPBI, SIOPBO, SIOPWREQ, - SIOPWRGD, SIOS3, SIOS5, SIOSCI, SPI1, SPI1ABR, SPI1CS1, SPI1WP, SPI2, + SALT9, SD1, SD2, SGPM1, SGPM2, SGPS1, SGPS2, SIOONCTRL, SIOPBI, SIOPBO, + SIOPWREQ, SIOPWRGD, SIOS3, SIOS5, SIOSCI, SPI1, SPI1ABR, SPI1CS1, SPI1WP, SPI2, SPI2CS1, SPI2CS2, TACH0, TACH1, TACH10, TACH11, TACH12, TACH13, TACH14, TACH15, TACH2, TACH3, TACH4, TACH5, TACH6, TACH7, TACH8, TACH9, THRU0, THRU1, THRU2, THRU3, TXD1, TXD2, TXD3, TXD4, UART10, UART11, UART12, @@ -74,9 +74,9 @@ patternProperties: RXD1, RXD2, RXD3, RXD4, SALT1, SALT10G0, SALT10G1, SALT11G0, SALT11G1, SALT12G0, SALT12G1, SALT13G0, SALT13G1, SALT14G0, SALT14G1, SALT15G0, SALT15G1, SALT16G0, SALT16G1, SALT2, SALT3, SALT4, SALT5, SALT6, - SALT7, SALT8, SALT9G0, SALT9G1, SD1, SD2, SD3, SGPM1, SGPS1, SIOONCTRL, - SIOPBI, SIOPBO, SIOPWREQ, SIOPWRGD, SIOS3, SIOS5, SIOSCI, SPI1, SPI1ABR, - SPI1CS1, SPI1WP, SPI2, SPI2CS1, SPI2CS2, TACH0, TACH1, TACH10, TACH11, + SALT7, SALT8, SALT9G0, SALT9G1, SD1, SD2, SD3, SGPM1, SGPM2, SGPS1, SGPS2, + SIOONCTRL, SIOPBI, SIOPBO, SIOPWREQ, SIOPWRGD, SIOS3, SIOS5, SIOSCI, SPI1, + SPI1ABR, SPI1CS1, SPI1WP, SPI2, SPI2CS1, SPI2CS2, TACH0, TACH1, TACH10, TACH11, TACH12, TACH13, TACH14, TACH15, TACH2, TACH3, TACH4, TACH5, TACH6, TACH7, TACH8, TACH9, THRU0, THRU1, THRU2, THRU3, TXD1, TXD2, TXD3, TXD4, UART10, UART11, UART12G0, UART12G1, UART13G0, UART13G1, UART6, -- cgit v1.2.3 From 07d5136f9bf1fa6abe70a1f88b04c1216fbf87a2 Mon Sep 17 00:00:00 2001 From: Dario Binacchi Date: Thu, 27 May 2021 22:13:09 +0200 Subject: docs/pinctrl: fix the reference to the u300 platform With commit ce1380c9f4bc ("ARM: remove u300 platform") it is wrong to use arch/arm/mach-u300/Kconfig file as example. Since the u300 platform has been replaced by the u8500, let's use its Kconfig as example. Signed-off-by: Dario Binacchi Link: https://lore.kernel.org/r/20210527201309.13308-1-dariobin@libero.it Signed-off-by: Linus Walleij --- Documentation/driver-api/pin-control.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/driver-api/pin-control.rst b/Documentation/driver-api/pin-control.rst index e2474425fb0c..71eefe5a023f 100644 --- a/Documentation/driver-api/pin-control.rst +++ b/Documentation/driver-api/pin-control.rst @@ -95,7 +95,7 @@ this in our driver:: To enable the pinctrl subsystem and the subgroups for PINMUX and PINCONF and selected drivers, you need to select them from your machine's Kconfig entry, since these are so tightly integrated with the machines they are used on. -See for example arch/arm/mach-u300/Kconfig for an example. +See for example arch/arm/mach-ux500/Kconfig for an example. Pins usually have fancier names than this. You can find these in the datasheet for your chip. Notice that the core pinctrl.h file provides a fancy macro -- cgit v1.2.3 From c16ced60f3bf4aeba85e638f2186c468d7892ee0 Mon Sep 17 00:00:00 2001 From: Suman Anna Date: Sat, 27 Mar 2021 09:31:16 -0500 Subject: dt-bindings: remoteproc: k3-r5f: Update bindings for AM64x SoCs The K3 AM64x SoCs have two dual-core Arm R5F clusters/subsystems, with 2 R5F cores each, both in the MAIN voltage domain. These clusters are a revised IP version compared to those present on J721E and J7200 SoCs, and supports a new "Single-CPU" mode instead of LockStep mode. Update the K3 R5F remoteproc bindings with the compatible info relevant to these R5F clusters/subsystems on K3 AM64x SoCs. Reviewed-by: Mathieu Poirier Signed-off-by: Suman Anna Link: https://lore.kernel.org/r/20210327143117.1840-2-s-anna@ti.com Signed-off-by: Bjorn Andersson --- .../bindings/remoteproc/ti,k3-r5f-rproc.yaml | 31 ++++++++++++++++++---- 1 file changed, 26 insertions(+), 5 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/remoteproc/ti,k3-r5f-rproc.yaml b/Documentation/devicetree/bindings/remoteproc/ti,k3-r5f-rproc.yaml index d905d614502b..130fbaacc4b1 100644 --- a/Documentation/devicetree/bindings/remoteproc/ti,k3-r5f-rproc.yaml +++ b/Documentation/devicetree/bindings/remoteproc/ti,k3-r5f-rproc.yaml @@ -14,8 +14,12 @@ description: | processor subsystems/clusters (R5FSS). The dual core cluster can be used either in a LockStep mode providing safety/fault tolerance features or in a Split mode providing two individual compute cores for doubling the compute - capacity. These are used together with other processors present on the SoC - to achieve various system level goals. + capacity on most SoCs. These are used together with other processors present + on the SoC to achieve various system level goals. + + AM64x SoCs do not support LockStep mode, but rather a new non-safety mode + called "Single-CPU" mode, where only Core0 is used, but with ability to use + Core1's TCMs as well. Each Dual-Core R5F sub-system is represented as a single DTS node representing the cluster, with a pair of child DT nodes representing @@ -33,6 +37,7 @@ properties: - ti,am654-r5fss - ti,j721e-r5fss - ti,j7200-r5fss + - ti,am64-r5fss power-domains: description: | @@ -56,11 +61,12 @@ properties: ti,cluster-mode: $ref: /schemas/types.yaml#/definitions/uint32 - enum: [0, 1] description: | Configuration Mode for the Dual R5F cores within the R5F cluster. - Should be either a value of 1 (LockStep mode) or 0 (Split mode), - default is LockStep mode if omitted. + Should be either a value of 1 (LockStep mode) or 0 (Split mode) on + most SoCs (AM65x, J721E, J7200), default is LockStep mode if omitted; + and should be either a value of 0 (Split mode) or 2 (Single-CPU mode) + on AM64x SoCs, default is Split mode if omitted. # R5F Processor Child Nodes: # ========================== @@ -97,6 +103,7 @@ patternProperties: - ti,am654-r5f - ti,j721e-r5f - ti,j7200-r5f + - ti,am64-r5f reg: items: @@ -198,6 +205,20 @@ patternProperties: unevaluatedProperties: false +if: + properties: + compatible: + enum: + - ti,am64-r5fss +then: + properties: + ti,cluster-mode: + enum: [0, 2] +else: + properties: + ti,cluster-mode: + enum: [0, 1] + required: - compatible - power-domains -- cgit v1.2.3 From f9e784dcb63f56157f7d12abdab584cc393515b1 Mon Sep 17 00:00:00 2001 From: Wilken Gottwalt Date: Sun, 14 Mar 2021 10:30:49 +0100 Subject: dt-bindings: hwlock: add sun6i_hwspinlock Adds documentation on how to use the sun6i_hwspinlock driver for sun6i compatible series SoCs. Reviewed-by: Samuel Holland Acked-by: Maxime Ripard Signed-off-by: Wilken Gottwalt Link: https://lore.kernel.org/r/b7a1f5532e0ae474473858055fd9bbabff9e1449.1615713499.git.wilken.gottwalt@posteo.net Signed-off-by: Bjorn Andersson --- .../hwlock/allwinner,sun6i-a31-hwspinlock.yaml | 45 ++++++++++++++++++++++ 1 file changed, 45 insertions(+) create mode 100644 Documentation/devicetree/bindings/hwlock/allwinner,sun6i-a31-hwspinlock.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/hwlock/allwinner,sun6i-a31-hwspinlock.yaml b/Documentation/devicetree/bindings/hwlock/allwinner,sun6i-a31-hwspinlock.yaml new file mode 100644 index 000000000000..733c3d01e56c --- /dev/null +++ b/Documentation/devicetree/bindings/hwlock/allwinner,sun6i-a31-hwspinlock.yaml @@ -0,0 +1,45 @@ +# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/hwlock/allwinner,sun6i-hwspinlock.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: SUN6I hardware spinlock driver for Allwinner sun6i compatible SoCs + +maintainers: + - Wilken Gottwalt + +description: + The hardware unit provides semaphores between the ARM cores and the embedded + companion core on the SoC. + +properties: + compatible: + const: allwinner,sun6i-a31-hwspinlock + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + + resets: + maxItems: 1 + +required: + - compatible + - reg + - clocks + - resets + +additionalProperties: false + +examples: + - | + hwlock@1c18000 { + compatible = "allwinner,sun6i-a31-hwspinlock"; + reg = <0x01c18000 0x1000>; + clocks = <&ccu CLK_BUS_SPINLOCK>; + resets = <&ccu RST_BUS_SPINLOCK>; + }; +... -- cgit v1.2.3 From cf107e98d024590fe2d0616862a3cc283da61501 Mon Sep 17 00:00:00 2001 From: Manivannan Sadhasivam Date: Wed, 5 May 2021 13:52:00 +0530 Subject: dt-bindings: remoteproc: qcom: pas: Convert binding to YAML Convert Qualcomm ADSP Remoteproc devicetree binding to YAML. Reviewed-by: Rob Herring Signed-off-by: Manivannan Sadhasivam Link: https://lore.kernel.org/r/20210505082200.32635-1-manivannan.sadhasivam@linaro.org Signed-off-by: Bjorn Andersson --- .../devicetree/bindings/remoteproc/qcom,adsp.txt | 228 --------- .../devicetree/bindings/remoteproc/qcom,adsp.yaml | 534 +++++++++++++++++++++ 2 files changed, 534 insertions(+), 228 deletions(-) delete mode 100644 Documentation/devicetree/bindings/remoteproc/qcom,adsp.txt create mode 100644 Documentation/devicetree/bindings/remoteproc/qcom,adsp.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,adsp.txt b/Documentation/devicetree/bindings/remoteproc/qcom,adsp.txt deleted file mode 100644 index 229f908fd831..000000000000 --- a/Documentation/devicetree/bindings/remoteproc/qcom,adsp.txt +++ /dev/null @@ -1,228 +0,0 @@ -Qualcomm ADSP Peripheral Image Loader - -This document defines the binding for a component that loads and boots firmware -on the Qualcomm ADSP Hexagon core. - -- compatible: - Usage: required - Value type: - Definition: must be one of: - "qcom,msm8974-adsp-pil" - "qcom,msm8996-adsp-pil" - "qcom,msm8996-slpi-pil" - "qcom,msm8998-adsp-pas" - "qcom,msm8998-slpi-pas" - "qcom,qcs404-adsp-pas" - "qcom,qcs404-cdsp-pas" - "qcom,qcs404-wcss-pas" - "qcom,sc7180-mpss-pas" - "qcom,sdm845-adsp-pas" - "qcom,sdm845-cdsp-pas" - "qcom,sdx55-mpss-pas" - "qcom,sm8150-adsp-pas" - "qcom,sm8150-cdsp-pas" - "qcom,sm8150-mpss-pas" - "qcom,sm8150-slpi-pas" - "qcom,sm8250-adsp-pas" - "qcom,sm8250-cdsp-pas" - "qcom,sm8250-slpi-pas" - "qcom,sm8350-adsp-pas" - "qcom,sm8350-cdsp-pas" - "qcom,sm8350-slpi-pas" - "qcom,sm8350-mpss-pas" - -- interrupts-extended: - Usage: required - Value type: - Definition: reference to the interrupts that match interrupt-names - -- interrupt-names: - Usage: required - Value type: - Definition: The interrupts needed depends on the compatible - string: - qcom,msm8974-adsp-pil: - qcom,msm8996-adsp-pil: - qcom,msm8996-slpi-pil: - qcom,msm8998-adsp-pas: - qcom,msm8998-slpi-pas: - qcom,qcs404-adsp-pas: - qcom,qcs404-cdsp-pas: - qcom,sdm845-adsp-pas: - qcom,sdm845-cdsp-pas: - qcom,sm8150-adsp-pas: - qcom,sm8150-cdsp-pas: - qcom,sm8150-slpi-pas: - qcom,sm8250-adsp-pas: - qcom,sm8250-cdsp-pas: - qcom,sm8250-slpi-pas: - qcom,sm8350-adsp-pas: - qcom,sm8350-cdsp-pas: - qcom,sm8350-slpi-pas: - must be "wdog", "fatal", "ready", "handover", "stop-ack" - qcom,qcs404-wcss-pas: - qcom,sc7180-mpss-pas: - qcom,sdx55-mpss-pas: - qcom,sm8150-mpss-pas: - qcom,sm8350-mpss-pas: - must be "wdog", "fatal", "ready", "handover", "stop-ack", - "shutdown-ack" - -- firmware-name: - Usage: optional - Value type: - Definition: must list the relative firmware image path for the - Hexagon Core. - -- clocks: - Usage: required - Value type: - Definition: reference to the xo clock and optionally aggre2 clock to be - held on behalf of the booting Hexagon core - -- clock-names: - Usage: required - Value type: - Definition: must be "xo" and optionally include "aggre2" - -- cx-supply: - Usage: required - Value type: - Definition: reference to the regulator to be held on behalf of the - booting Hexagon core - -- px-supply: - Usage: required - Value type: - Definition: reference to the px regulator to be held on behalf of the - booting Hexagon core - -- power-domains: - Usage: required - Value type: - Definition: reference to power-domains that match the power-domain-names - -- power-domain-names: - Usage: required - Value type: - Definition: The power-domains needed depend on the compatible string: - qcom,msm8974-adsp-pil: - qcom,msm8996-adsp-pil: - qcom,msm8998-adsp-pas: - must be "cx" - qcom,msm8996-slpi-pil: - must be "ss_cx" - qcom,msm8998-slpi-pas: - must be "ssc_cx" - qcom,qcs404-adsp-pas: - must be "lpi_cx" - qcom,qcs404-cdsp-pas: - qcom,qcs404-wcss-pas: - must be "mx" - qcom,sdm845-adsp-pas: - qcom,sdm845-cdsp-pas: - qcom,sm8150-adsp-pas: - qcom,sm8150-cdsp-pas: - qcom,sm8250-cdsp-pas: - qcom,sm8350-cdsp-pas: - must be "cx", "load_state" - qcom,sc7180-mpss-pas: - qcom,sm8150-mpss-pas: - qcom,sm8350-mpss-pas: - must be "cx", "load_state", "mss" - qcom,sdx55-mpss-pas: - must be "cx", "mss" - qcom,sm8250-adsp-pas: - qcom,sm8350-adsp-pas: - qcom,sm8150-slpi-pas: - qcom,sm8250-slpi-pas: - qcom,sm8350-slpi-pas: - must be "lcx", "lmx", "load_state" - -- memory-region: - Usage: required - Value type: - Definition: reference to the reserved-memory for the ADSP - -- qcom,smem-states: - Usage: required - Value type: - Definition: reference to the smem state for requesting the ADSP to - shut down - -- qcom,smem-state-names: - Usage: required - Value type: - Definition: must be "stop" - - -= SUBNODES -The adsp node may have an subnode named either "smd-edge" or "glink-edge" that -describes the communication edge, channels and devices related to the ADSP. -See ../soc/qcom/qcom,smd.txt and ../soc/qcom/qcom,glink.txt for details on how -to describe these. - - -= EXAMPLE -The following example describes the resources needed to boot control the -ADSP, as it is found on MSM8974 boards. - - adsp { - compatible = "qcom,msm8974-adsp-pil"; - - interrupts-extended = <&intc 0 162 IRQ_TYPE_EDGE_RISING>, - <&adsp_smp2p_in 0 IRQ_TYPE_EDGE_RISING>, - <&adsp_smp2p_in 1 IRQ_TYPE_EDGE_RISING>, - <&adsp_smp2p_in 2 IRQ_TYPE_EDGE_RISING>, - <&adsp_smp2p_in 3 IRQ_TYPE_EDGE_RISING>; - interrupt-names = "wdog", - "fatal", - "ready", - "handover", - "stop-ack"; - - clocks = <&rpmcc RPM_CXO_CLK>; - clock-names = "xo"; - - cx-supply = <&pm8841_s2>; - - memory-region = <&adsp_region>; - - qcom,smem-states = <&adsp_smp2p_out 0>; - qcom,smem-state-names = "stop"; - - smd-edge { - interrupts = <0 156 IRQ_TYPE_EDGE_RISING>; - - qcom,ipc = <&apcs 8 8>; - qcom,smd-edge = <1>; - }; - }; - -The following example describes the resources needed to boot control the -SLPI, as it is found on MSM8996 boards. - - slpi { - compatible = "qcom,msm8996-slpi-pil"; - interrupts-extended = <&intc 0 390 IRQ_TYPE_EDGE_RISING>, - <&slpi_smp2p_in 0 IRQ_TYPE_EDGE_RISING>, - <&slpi_smp2p_in 1 IRQ_TYPE_EDGE_RISING>, - <&slpi_smp2p_in 2 IRQ_TYPE_EDGE_RISING>, - <&slpi_smp2p_in 3 IRQ_TYPE_EDGE_RISING>; - interrupt-names = "wdog", - "fatal", - "ready", - "handover", - "stop-ack"; - - clocks = <&rpmcc MSM8996_RPM_SMD_XO_CLK_SRC>, - <&rpmcc MSM8996_RPM_SMD_AGGR2_NOC_CLK>; - clock-names = "xo", "aggre2"; - - cx-supply = <&pm8994_l26>; - px-supply = <&pm8994_lvs2>; - - memory-region = <&slpi_region>; - qcom,smem-states = <&slpi_smp2p_out 0>; - qcom,smem-state-names = "stop"; - }; diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,adsp.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,adsp.yaml new file mode 100644 index 000000000000..9c07cfce0383 --- /dev/null +++ b/Documentation/devicetree/bindings/remoteproc/qcom,adsp.yaml @@ -0,0 +1,534 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/remoteproc/qcom,adsp.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm ADSP Peripheral Image Loader binding + +maintainers: + - Manivannan Sadhasivam + +description: + This document defines the binding for a component that loads and boots + firmware on the Qualcomm ADSP Hexagon core. + +properties: + compatible: + enum: + - qcom,msm8974-adsp-pil + - qcom,msm8996-adsp-pil + - qcom,msm8996-slpi-pil + - qcom,msm8998-adsp-pas + - qcom,msm8998-slpi-pas + - qcom,qcs404-adsp-pas + - qcom,qcs404-cdsp-pas + - qcom,qcs404-wcss-pas + - qcom,sc7180-mpss-pas + - qcom,sdm845-adsp-pas + - qcom,sdm845-cdsp-pas + - qcom,sdx55-mpss-pas + - qcom,sm8150-adsp-pas + - qcom,sm8150-cdsp-pas + - qcom,sm8150-mpss-pas + - qcom,sm8150-slpi-pas + - qcom,sm8250-adsp-pas + - qcom,sm8250-cdsp-pas + - qcom,sm8250-slpi-pas + - qcom,sm8350-adsp-pas + - qcom,sm8350-cdsp-pas + - qcom,sm8350-slpi-pas + - qcom,sm8350-mpss-pas + + reg: + maxItems: 1 + + clocks: + minItems: 1 + maxItems: 8 + + clock-names: + minItems: 1 + maxItems: 8 + + interrupts: + minItems: 5 + maxItems: 6 + + interrupt-names: + minItems: 5 + maxItems: 6 + + resets: + minItems: 1 + maxItems: 3 + + reset-names: + minItems: 1 + maxItems: 3 + + cx-supply: + description: Phandle to the CX regulator + + px-supply: + description: Phandle to the PX regulator + + power-domains: + minItems: 1 + maxItems: 3 + + power-domain-names: + minItems: 1 + maxItems: 3 + + firmware-name: + $ref: /schemas/types.yaml#/definitions/string + description: Firmware name for the Hexagon core + + memory-region: + maxItems: 1 + description: Reference to the reserved-memory for the Hexagon core + + qcom,smem-states: + $ref: /schemas/types.yaml#/definitions/phandle-array + description: States used by the AP to signal the Hexagon core + items: + - description: Stop the modem + + qcom,smem-state-names: + $ref: /schemas/types.yaml#/definitions/string-array + description: The names of the state bits used for SMP2P output + items: + - const: stop + + qcom,halt-regs: + $ref: /schemas/types.yaml#/definitions/phandle-array + description: + Phandle reference to a syscon representing TCSR followed by the + three offsets within syscon for q6, modem and nc halt registers. + + smd-edge: + type: object + description: + Qualcomm Shared Memory subnode which represents communication edge, + channels and devices related to the ADSP. + + glink-edge: + type: object + description: + Qualcomm G-Link subnode which represents communication edge, channels + and devices related to the ADSP. + +required: + - compatible + - clocks + - clock-names + - interrupts + - interrupt-names + - memory-region + - qcom,smem-states + - qcom,smem-state-names + +additionalProperties: false + +allOf: + - if: + properties: + compatible: + contains: + enum: + - qcom,msm8974-adsp-pil + - qcom,msm8996-adsp-pil + - qcom,msm8996-slpi-pil + - qcom,msm8998-adsp-pas + - qcom,qcs404-adsp-pas + - qcom,qcs404-wcss-pas + - qcom,sdm845-adsp-pas + - qcom,sdm845-cdsp-pas + - qcom,sm8150-adsp-pas + - qcom,sm8150-cdsp-pas + - qcom,sm8150-mpss-pas + - qcom,sm8150-slpi-pas + - qcom,sm8250-adsp-pas + - qcom,sm8250-cdsp-pas + - qcom,sm8250-slpi-pas + - qcom,sm8350-adsp-pas + - qcom,sm8350-cdsp-pas + - qcom,sm8350-slpi-pas + - qcom,sm8350-mpss-pas + then: + properties: + clocks: + items: + - description: XO clock + clock-names: + items: + - const: xo + + - if: + properties: + compatible: + contains: + enum: + - qcom,msm8998-slpi-pas + then: + properties: + clocks: + items: + - description: XO clock + - description: AGGRE2 clock + clock-names: + items: + - const: xo + - const: aggre2 + + - if: + properties: + compatible: + contains: + enum: + - qcom,qcs404-cdsp-pas + then: + properties: + clocks: + items: + - description: XO clock + - description: SWAY clock + - description: TBU clock + - description: BIMC clock + - description: AHB AON clock + - description: Q6SS SLAVE clock + - description: Q6SS MASTER clock + - description: Q6 AXIM clock + clock-names: + items: + - const: xo + - const: sway + - const: tbu + - const: bimc + - const: ahb_aon + - const: q6ss_slave + - const: q6ss_master + - const: q6_axim + + - if: + properties: + compatible: + contains: + enum: + - qcom,sc7180-mpss-pas + then: + properties: + clocks: + items: + - description: XO clock + - description: IFACE clock + - description: BUS clock + - description: NAC clock + - description: SNOC AXI clock + - description: MNOC AXI clock + clock-names: + items: + - const: xo + - const: iface + - const: bus + - const: nav + - const: snoc_axi + - const: mnoc_axi + + - if: + properties: + compatible: + contains: + enum: + - qcom,msm8974-adsp-pil + - qcom,msm8996-adsp-pil + - qcom,msm8996-slpi-pil + - qcom,msm8998-adsp-pas + - qcom,msm8998-slpi-pas + - qcom,qcs404-adsp-pas + - qcom,qcs404-cdsp-pas + - qcom,qcs404-wcss-pas + - qcom,sdm845-adsp-pas + - qcom,sdm845-cdsp-pas + - qcom,sm8150-adsp-pas + - qcom,sm8150-cdsp-pas + - qcom,sm8150-slpi-pas + - qcom,sm8250-adsp-pas + - qcom,sm8250-cdsp-pas + - qcom,sm8250-slpi-pas + - qcom,sm8350-adsp-pas + - qcom,sm8350-cdsp-pas + - qcom,sm8350-slpi-pas + then: + properties: + interrupts: + items: + - description: Watchdog interrupt + - description: Fatal interrupt + - description: Ready interrupt + - description: Handover interrupt + - description: Stop acknowledge interrupt + interrupt-names: + items: + - const: wdog + - const: fatal + - const: ready + - const: handover + - const: stop-ack + + - if: + properties: + compatible: + contains: + enum: + - qcom,sc7180-mpss-pas + - qcom,sdx55-mpss-pas + - qcom,sm8150-mpss-pas + - qcom,sm8350-mpss-pas + then: + properties: + interrupts: + items: + - description: Watchdog interrupt + - description: Fatal interrupt + - description: Ready interrupt + - description: Handover interrupt + - description: Stop acknowledge interrupt + - description: Shutdown acknowledge interrupt + interrupt-names: + items: + - const: wdog + - const: fatal + - const: ready + - const: handover + - const: stop-ack + - const: shutdown-ack + + - if: + properties: + compatible: + contains: + enum: + - qcom,msm8974-adsp-pil + then: + required: + - cx-supply + + - if: + properties: + compatible: + contains: + enum: + - qcom,msm8998-adsp-pas + then: + properties: + power-domains: + items: + - description: CX power domain + power-domain-names: + items: + - const: cx + + - if: + properties: + compatible: + contains: + enum: + - qcom,msm8998-slpi-pas + then: + properties: + power-domains: + items: + - description: SSC-CX power domain + power-domain-names: + items: + - const: ssc_cx + required: + - px-supply + + - if: + properties: + compatible: + contains: + enum: + - qcom,sc7180-mpss-pas + then: + properties: + power-domains: + items: + - description: Load State power domain + - description: CX power domain + - description: MX power domain + - description: MSS power domain + power-domain-names: + items: + - const: load_state + - const: cx + - const: mx + - const: mss + + - if: + properties: + compatible: + contains: + enum: + - qcom,sm8150-adsp-pas + - qcom,sm8150-cdsp-pas + then: + properties: + power-domains: + items: + - description: Load State power domain + - description: CX power domain + power-domain-names: + items: + - const: load_state + - const: cx + + - if: + properties: + compatible: + contains: + enum: + - qcom,sm8150-mpss-pas + - qcom,sm8350-mpss-pas + then: + properties: + power-domains: + items: + - description: Load State power domain + - description: CX power domain + - description: MSS power domain + power-domain-names: + items: + - const: load_state + - const: cx + - const: mss + + - if: + properties: + compatible: + contains: + enum: + - qcom,sdx55-mpss-pas + then: + properties: + power-domains: + items: + - description: CX power domain + - description: MSS power domain + power-domain-names: + items: + - const: cx + - const: mss + + - if: + properties: + compatible: + contains: + enum: + - qcom,sm8150-slpi-pas + - qcom,sm8250-adsp-pas + - qcom,sm8250-slpi-pas + - qcom,sm8350-adsp-pas + - qcom,sm8350-slpi-pas + then: + properties: + power-domains: + items: + - description: Load State power domain + - description: LCX power domain + - description: LMX power domain + power-domain-names: + items: + - const: load_state + - const: lcx + - const: lmx + + - if: + properties: + compatible: + contains: + enum: + - qcom,sm8350-cdsp-pas + then: + properties: + power-domains: + items: + - description: Load State power domain + - description: CX power domain + - description: MXC power domain + power-domain-names: + items: + - const: load_state + - const: cx + - const: mxc + + - if: + properties: + compatible: + contains: + enum: + - qcom,qcs404-cdsp-pas + then: + properties: + resets: + items: + - description: CDSP restart + reset-names: + items: + - const: restart + + - if: + properties: + compatible: + contains: + enum: + - qcom,sc7180-mpss-pas + then: + properties: + resets: + items: + - description: MSS restart + - description: PDC reset + reset-names: + items: + - const: mss_restart + - const: pdc_reset + +examples: + - | + #include + #include + adsp { + compatible = "qcom,msm8974-adsp-pil"; + + interrupts-extended = <&intc 0 162 IRQ_TYPE_EDGE_RISING>, + <&adsp_smp2p_in 0 IRQ_TYPE_EDGE_RISING>, + <&adsp_smp2p_in 1 IRQ_TYPE_EDGE_RISING>, + <&adsp_smp2p_in 2 IRQ_TYPE_EDGE_RISING>, + <&adsp_smp2p_in 3 IRQ_TYPE_EDGE_RISING>; + interrupt-names = "wdog", + "fatal", + "ready", + "handover", + "stop-ack"; + + clocks = <&rpmcc RPM_CXO_CLK>; + clock-names = "xo"; + + cx-supply = <&pm8841_s2>; + + memory-region = <&adsp_region>; + + qcom,smem-states = <&adsp_smp2p_out 0>; + qcom,smem-state-names = "stop"; + + smd-edge { + interrupts = <0 156 IRQ_TYPE_EDGE_RISING>; + + qcom,ipc = <&apcs 8 8>; + qcom,smd-edge = <1>; + }; + }; -- cgit v1.2.3 From e50f4bda7539c165f3c8d880b670140ce09a50cf Mon Sep 17 00:00:00 2001 From: Yassine Oudjana Date: Thu, 6 May 2021 21:18:31 +0000 Subject: dt-bindings: remoteproc: qcom: pas: Add power domains for MSM8996 Add MSM8996 compatible strings to CX and SSC-CX power domains. This depends on: "dt-bindings: remoteproc: qcom: pas: Convert binding to YAML" https://lore.kernel.org/linux-arm-msm/20210505082200.32635-1-manivannan.sadhasivam@linaro.org/T/#u Acked-by: Rob Herring Signed-off-by: Yassine Oudjana Link: https://lore.kernel.org/r/lRf8M7F6Qo9s7tlx6vuAWHThg26ls3u6SvQn1PLrAdI@cp4-web-038.plabs.ch Signed-off-by: Bjorn Andersson --- Documentation/devicetree/bindings/remoteproc/qcom,adsp.yaml | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,adsp.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,adsp.yaml index 9c07cfce0383..6c11812385ca 100644 --- a/Documentation/devicetree/bindings/remoteproc/qcom,adsp.yaml +++ b/Documentation/devicetree/bindings/remoteproc/qcom,adsp.yaml @@ -320,6 +320,7 @@ allOf: compatible: contains: enum: + - qcom,msm8996-adsp-pil - qcom,msm8998-adsp-pas then: properties: @@ -335,6 +336,7 @@ allOf: compatible: contains: enum: + - qcom,msm8996-slpi-pil - qcom,msm8998-slpi-pas then: properties: -- cgit v1.2.3 From cd90e95820d569c7215abb9b7830a83212ed1273 Mon Sep 17 00:00:00 2001 From: Geert Uytterhoeven Date: Tue, 4 May 2021 16:35:54 +0200 Subject: dt-bindings: i2c: renesas,i2c: Drop "renesas,i2c-rcar" The compatible value "renesas,i2c-rcar" was deprecated in commit ad4a8dc3fec6485b ("i2c: rcar: Add per-Generation fallback bindings"), and never had any users in upstream Linux. Drop its description from the DT bindings. Signed-off-by: Geert Uytterhoeven Acked-by: Rob Herring Signed-off-by: Wolfram Sang --- Documentation/devicetree/bindings/i2c/renesas,i2c.txt | 1 - 1 file changed, 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/i2c/renesas,i2c.txt b/Documentation/devicetree/bindings/i2c/renesas,i2c.txt index 5762d2d1ab9c..f4240fcf28bb 100644 --- a/Documentation/devicetree/bindings/i2c/renesas,i2c.txt +++ b/Documentation/devicetree/bindings/i2c/renesas,i2c.txt @@ -32,7 +32,6 @@ Required properties: device. "renesas,rcar-gen3-i2c" for a generic R-Car Gen3 or RZ/G2 compatible device. - "renesas,i2c-rcar" (deprecated) When compatible with the generic version, nodes must list the SoC-specific version corresponding to the platform first followed -- cgit v1.2.3 From 524f6fdfa6375b75fb910ac80a9aa4a7c6091d9e Mon Sep 17 00:00:00 2001 From: Geert Uytterhoeven Date: Tue, 4 May 2021 16:35:55 +0200 Subject: dt-bindings: i2c: renesas,i2c: Convert to json-schema Convert the Renesas R-Car I2C Controller Device Tree binding documentation to json-schema. Document missing properties. Make the clocks property required. DMA is supported on R-Car Gen3 and RZ/G2 only. Update the example to match reality. Signed-off-by: Geert Uytterhoeven Reviewed-by: Rob Herring Signed-off-by: Wolfram Sang --- .../devicetree/bindings/i2c/renesas,i2c.txt | 66 --------- .../devicetree/bindings/i2c/renesas,rcar-i2c.yaml | 158 +++++++++++++++++++++ 2 files changed, 158 insertions(+), 66 deletions(-) delete mode 100644 Documentation/devicetree/bindings/i2c/renesas,i2c.txt create mode 100644 Documentation/devicetree/bindings/i2c/renesas,rcar-i2c.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/i2c/renesas,i2c.txt b/Documentation/devicetree/bindings/i2c/renesas,i2c.txt deleted file mode 100644 index f4240fcf28bb..000000000000 --- a/Documentation/devicetree/bindings/i2c/renesas,i2c.txt +++ /dev/null @@ -1,66 +0,0 @@ -I2C for R-Car platforms - -Required properties: -- compatible: - "renesas,i2c-r8a7742" if the device is a part of a R8A7742 SoC. - "renesas,i2c-r8a7743" if the device is a part of a R8A7743 SoC. - "renesas,i2c-r8a7744" if the device is a part of a R8A7744 SoC. - "renesas,i2c-r8a7745" if the device is a part of a R8A7745 SoC. - "renesas,i2c-r8a77470" if the device is a part of a R8A77470 SoC. - "renesas,i2c-r8a774a1" if the device is a part of a R8A774A1 SoC. - "renesas,i2c-r8a774b1" if the device is a part of a R8A774B1 SoC. - "renesas,i2c-r8a774c0" if the device is a part of a R8A774C0 SoC. - "renesas,i2c-r8a774e1" if the device is a part of a R8A774E1 SoC. - "renesas,i2c-r8a7778" if the device is a part of a R8A7778 SoC. - "renesas,i2c-r8a7779" if the device is a part of a R8A7779 SoC. - "renesas,i2c-r8a7790" if the device is a part of a R8A7790 SoC. - "renesas,i2c-r8a7791" if the device is a part of a R8A7791 SoC. - "renesas,i2c-r8a7792" if the device is a part of a R8A7792 SoC. - "renesas,i2c-r8a7793" if the device is a part of a R8A7793 SoC. - "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 R8A77960 SoC. - "renesas,i2c-r8a77961" if the device is a part of a R8A77961 SoC. - "renesas,i2c-r8a77965" if the device is a part of a R8A77965 SoC. - "renesas,i2c-r8a77970" if the device is a part of a R8A77970 SoC. - "renesas,i2c-r8a77980" if the device is a part of a R8A77980 SoC. - "renesas,i2c-r8a77990" if the device is a part of a R8A77990 SoC. - "renesas,i2c-r8a77995" if the device is a part of a R8A77995 SoC. - "renesas,i2c-r8a779a0" if the device is a part of a R8A779A0 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. - "renesas,rcar-gen3-i2c" for a generic R-Car Gen3 or RZ/G2 compatible - device. - - When compatible with the generic version, nodes must list the - SoC-specific version corresponding to the platform first followed - by the generic version. - -- reg: physical base address of the controller and length of memory mapped - region. -- interrupts: interrupt specifier. - -Optional properties: -- clock-frequency: desired I2C bus clock frequency in Hz. The absence of this - property indicates the default frequency 100 kHz. -- clocks: clock specifier. -- dmas: Must contain a list of two references to DMA specifiers, one for - transmission, and one for reception. -- dma-names: Must contain a list of two DMA names, "tx" and "rx". - -- i2c-scl-falling-time-ns: see i2c.txt -- i2c-scl-internal-delay-ns: see i2c.txt -- i2c-scl-rising-time-ns: see i2c.txt - -Examples : - -i2c0: i2c@e6508000 { - #address-cells = <1>; - #size-cells = <0>; - compatible = "renesas,i2c-r8a7791", "renesas,rcar-gen2-i2c"; - reg = <0 0xe6508000 0 0x40>; - interrupts = <0 287 IRQ_TYPE_LEVEL_HIGH>; - clocks = <&mstp9_clks R8A7791_CLK_I2C0>; - clock-frequency = <400000>; -}; diff --git a/Documentation/devicetree/bindings/i2c/renesas,rcar-i2c.yaml b/Documentation/devicetree/bindings/i2c/renesas,rcar-i2c.yaml new file mode 100644 index 000000000000..052aad44e781 --- /dev/null +++ b/Documentation/devicetree/bindings/i2c/renesas,rcar-i2c.yaml @@ -0,0 +1,158 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/i2c/renesas,rcar-i2c.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Renesas R-Car I2C Controller + +maintainers: + - Wolfram Sang + +properties: + compatible: + oneOf: + - items: + - enum: + - renesas,i2c-r8a7778 # R-Car M1A + - renesas,i2c-r8a7779 # R-Car H1 + - const: renesas,rcar-gen1-i2c # R-Car Gen1 + + - items: + - enum: + - renesas,i2c-r8a7742 # RZ/G1H + - renesas,i2c-r8a7743 # RZ/G1M + - renesas,i2c-r8a7744 # RZ/G1N + - renesas,i2c-r8a7745 # RZ/G1E + - renesas,i2c-r8a77470 # RZ/G1C + - renesas,i2c-r8a7790 # R-Car H2 + - renesas,i2c-r8a7791 # R-Car M2-W + - renesas,i2c-r8a7792 # R-Car V2H + - renesas,i2c-r8a7793 # R-Car M2-N + - renesas,i2c-r8a7794 # R-Car E2 + - const: renesas,rcar-gen2-i2c # R-Car Gen2 and RZ/G1 + + - items: + - enum: + - renesas,i2c-r8a774a1 # RZ/G2M + - renesas,i2c-r8a774b1 # RZ/G2N + - renesas,i2c-r8a774c0 # RZ/G2E + - renesas,i2c-r8a774e1 # RZ/G2H + - renesas,i2c-r8a7795 # R-Car H3 + - renesas,i2c-r8a7796 # R-Car M3-W + - renesas,i2c-r8a77961 # R-Car M3-W+ + - renesas,i2c-r8a77965 # R-Car M3-N + - renesas,i2c-r8a77970 # R-Car V3M + - renesas,i2c-r8a77980 # R-Car V3H + - renesas,i2c-r8a77990 # R-Car E3 + - renesas,i2c-r8a77995 # R-Car D3 + - renesas,i2c-r8a779a0 # R-Car V3U + - const: renesas,rcar-gen3-i2c # R-Car Gen3 and RZ/G2 + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clock-frequency: + description: + Desired I2C bus clock frequency in Hz. The absence of this property + indicates the default frequency 100 kHz. + + clocks: + maxItems: 1 + + power-domains: + maxItems: 1 + + resets: + maxItems: 1 + + dmas: + minItems: 2 + maxItems: 4 + description: + Must contain a list of pairs of references to DMA specifiers, one for + transmission, and one for reception. + + dma-names: + minItems: 2 + maxItems: 4 + items: + enum: + - tx + - rx + + i2c-scl-falling-time-ns: + default: 35 + description: + Number of nanoseconds the SCL signal takes to fall; t(f) in the I2C + specification. + + i2c-scl-internal-delay-ns: + default: 50 + description: + Number of nanoseconds the IP core additionally needs to setup SCL. + + i2c-scl-rising-time-ns: + default: 200 + description: + Number of nanoseconds the SCL signal takes to rise; t(r) in the I2C + specification. + +required: + - compatible + - reg + - interrupts + - clocks + - power-domains + - '#address-cells' + - '#size-cells' + +allOf: + - $ref: /schemas/i2c/i2c-controller.yaml# + + - if: + properties: + compatible: + contains: + enum: + - renesas,rcar-gen1-i2c + - renesas,rcar-gen2-i2c + then: + properties: + dmas: false + dma-names: false + + - if: + properties: + compatible: + contains: + enum: + - renesas,rcar-gen2-i2c + - renesas,rcar-gen3-i2c + then: + required: + - resets + +unevaluatedProperties: false + +examples: + - | + #include + #include + #include + + i2c0: i2c@e6508000 { + #address-cells = <1>; + #size-cells = <0>; + compatible = "renesas,i2c-r8a7791", "renesas,rcar-gen2-i2c"; + reg = <0xe6508000 0x40>; + interrupts = ; + clock-frequency = <400000>; + clocks = <&cpg CPG_MOD 931>; + power-domains = <&sysc R8A7791_PD_ALWAYS_ON>; + resets = <&cpg 931>; + i2c-scl-internal-delay-ns = <6>; + }; -- cgit v1.2.3 From 6221a93475f35fe7aade9d66211661bb82755da5 Mon Sep 17 00:00:00 2001 From: Geert Uytterhoeven Date: Tue, 4 May 2021 16:35:58 +0200 Subject: dt-bindings: i2c: renesas,iic-emev2: Convert to json-schema Convert the Renesas EMMA Mobile EV2 IIC Interface (IIC) Device Tree binding documentation to json-schema. Document missing properties. Update the example to match reality. Signed-off-by: Geert Uytterhoeven Reviewed-by: Rob Herring Signed-off-by: Wolfram Sang --- .../devicetree/bindings/i2c/renesas,iic-emev2.txt | 22 --------- .../devicetree/bindings/i2c/renesas,iic-emev2.yaml | 54 ++++++++++++++++++++++ 2 files changed, 54 insertions(+), 22 deletions(-) delete mode 100644 Documentation/devicetree/bindings/i2c/renesas,iic-emev2.txt create mode 100644 Documentation/devicetree/bindings/i2c/renesas,iic-emev2.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/i2c/renesas,iic-emev2.txt b/Documentation/devicetree/bindings/i2c/renesas,iic-emev2.txt deleted file mode 100644 index 5ed1ea1c7e14..000000000000 --- a/Documentation/devicetree/bindings/i2c/renesas,iic-emev2.txt +++ /dev/null @@ -1,22 +0,0 @@ -Device tree configuration for Renesas EMEV2 IIC controller - -Required properties: -- compatible : "renesas,iic-emev2" -- reg : address start and address range size of device -- interrupts : specifier for the IIC controller interrupt -- clocks : phandle to the IP core SCLK -- clock-names : must be "sclk" -- #address-cells : should be <1> -- #size-cells : should be <0> - -Example: - - iic0: i2c@e0070000 { - #address-cells = <1>; - #size-cells = <0>; - compatible = "renesas,iic-emev2"; - reg = <0xe0070000 0x28>; - interrupts = <0 32 IRQ_TYPE_EDGE_RISING>; - clocks = <&iic0_sclk>; - clock-names = "sclk"; - }; diff --git a/Documentation/devicetree/bindings/i2c/renesas,iic-emev2.yaml b/Documentation/devicetree/bindings/i2c/renesas,iic-emev2.yaml new file mode 100644 index 000000000000..17c1102562be --- /dev/null +++ b/Documentation/devicetree/bindings/i2c/renesas,iic-emev2.yaml @@ -0,0 +1,54 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/i2c/renesas,iic-emev2.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Renesas EMMA Mobile EV2 IIC Interface + +maintainers: + - Wolfram Sang + +allOf: + - $ref: /schemas/i2c/i2c-controller.yaml# + +properties: + compatible: + const: renesas,iic-emev2 + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + + clock-names: + const: sclk + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + - '#address-cells' + - '#size-cells' + +unevaluatedProperties: false + +examples: + - | + #include + + iic0: i2c@e0070000 { + #address-cells = <1>; + #size-cells = <0>; + compatible = "renesas,iic-emev2"; + reg = <0xe0070000 0x28>; + interrupts = ; + clocks = <&iic0_sclk>; + clock-names = "sclk"; + }; -- cgit v1.2.3 From c53ab8f96af1f1fcaa0c1bc851a7704ae4b413d2 Mon Sep 17 00:00:00 2001 From: Neil Armstrong Date: Fri, 14 May 2021 16:32:54 +0200 Subject: dt-bindings: arm: amlogic: add Banana PI M5 bindings Add bindings for the Banana PI M5 board. Signed-off-by: Neil Armstrong Reviewed-by: Martin Blumenstingl Acked-by: Rob Herring Link: https://lore.kernel.org/r/20210514143255.3352774-3-narmstrong@baylibre.com --- Documentation/devicetree/bindings/arm/amlogic.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/amlogic.yaml b/Documentation/devicetree/bindings/arm/amlogic.yaml index 97fb96266344..6423377710ee 100644 --- a/Documentation/devicetree/bindings/arm/amlogic.yaml +++ b/Documentation/devicetree/bindings/arm/amlogic.yaml @@ -167,6 +167,7 @@ properties: - description: Boards with the Amlogic Meson SM1 S905X3/D3/Y3 SoC items: - enum: + - bananapi,bpi-m5 - hardkernel,odroid-c4 - hardkernel,odroid-hc4 - khadas,vim3l -- cgit v1.2.3 From 92b7716f4c54cb61b30e4680ea436a9e0cc6f4de Mon Sep 17 00:00:00 2001 From: Geert Uytterhoeven Date: Fri, 28 May 2021 11:19:48 +0200 Subject: dt-bindings: i2c: renesas,riic: Convert to json-schema Convert the Renesas RZ/A I2C Bus Interface (RIIC) Device Tree binding documentation to json-schema. Document missing properties. Update the example to match reality. Signed-off-by: Geert Uytterhoeven Reviewed-by: Rob Herring Signed-off-by: Wolfram Sang --- .../devicetree/bindings/i2c/renesas,riic.txt | 32 --------- .../devicetree/bindings/i2c/renesas,riic.yaml | 82 ++++++++++++++++++++++ 2 files changed, 82 insertions(+), 32 deletions(-) delete mode 100644 Documentation/devicetree/bindings/i2c/renesas,riic.txt create mode 100644 Documentation/devicetree/bindings/i2c/renesas,riic.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/i2c/renesas,riic.txt b/Documentation/devicetree/bindings/i2c/renesas,riic.txt deleted file mode 100644 index e26fe3ad86a9..000000000000 --- a/Documentation/devicetree/bindings/i2c/renesas,riic.txt +++ /dev/null @@ -1,32 +0,0 @@ -Device tree configuration for Renesas RIIC driver - -Required properties: -- compatible : - "renesas,riic-r7s72100" if the device is a part of a R7S72100 SoC. - "renesas,riic-r7s9210" if the device is a part of a R7S9210 SoC. - "renesas,riic-rz" for a generic RZ/A compatible device. -- reg : address start and address range size of device -- interrupts : 8 interrupts (TEI, RI, TI, SPI, STI, NAKI, ALI, TMOI) -- clock-frequency : frequency of bus clock in Hz -- #address-cells : should be <1> -- #size-cells : should be <0> - -Pinctrl properties might be needed, too. See there. - -Example: - - i2c0: i2c@fcfee000 { - compatible = "renesas,riic-r7s72100", "renesas,riic-rz"; - reg = <0xfcfee000 0x44>; - interrupts = <0 157 IRQ_TYPE_LEVEL_HIGH>, - <0 158 IRQ_TYPE_EDGE_RISING>, - <0 159 IRQ_TYPE_EDGE_RISING>, - <0 160 IRQ_TYPE_LEVEL_HIGH>, - <0 161 IRQ_TYPE_LEVEL_HIGH>, - <0 162 IRQ_TYPE_LEVEL_HIGH>, - <0 163 IRQ_TYPE_LEVEL_HIGH>, - <0 164 IRQ_TYPE_LEVEL_HIGH>; - clock-frequency = <100000>; - #address-cells = <1>; - #size-cells = <0>; - }; diff --git a/Documentation/devicetree/bindings/i2c/renesas,riic.yaml b/Documentation/devicetree/bindings/i2c/renesas,riic.yaml new file mode 100644 index 000000000000..2d6378164958 --- /dev/null +++ b/Documentation/devicetree/bindings/i2c/renesas,riic.yaml @@ -0,0 +1,82 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/i2c/renesas,riic.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Renesas RZ/A I2C Bus Interface (RIIC) + +maintainers: + - Chris Brandt + - Wolfram Sang + +allOf: + - $ref: /schemas/i2c/i2c-controller.yaml# + +properties: + compatible: + items: + - enum: + - renesas,riic-r7s72100 # RZ/A1H + - renesas,riic-r7s9210 # RZ/A2M + - const: renesas,riic-rz # RZ/A + + reg: + maxItems: 1 + + interrupts: + items: + - description: Transmit End Interrupt (TEI) + - description: Receive Data Full Interrupt (RI) + - description: Transmit Data Empty Interrupt (TI) + - description: Stop Condition Detection Interrupt (SPI) + - description: Start Condition Detection Interrupt (STI) + - description: NACK Reception Interrupt (NAKI) + - description: Arbitration-Lost Interrupt (ALI) + - description: Timeout Interrupt (TMOI) + + clock-frequency: + description: + Desired I2C bus clock frequency in Hz. The absence of this property + indicates the default frequency 100 kHz. + + clocks: + maxItems: 1 + + power-domains: + maxItems: 1 + +required: + - compatible + - reg + - interrupts + - clocks + - clock-frequency + - power-domains + - '#address-cells' + - '#size-cells' + +unevaluatedProperties: false + +examples: + - | + #include + #include + + i2c0: i2c@fcfee000 { + compatible = "renesas,riic-r7s72100", "renesas,riic-rz"; + reg = <0xfcfee000 0x44>; + interrupts = , + , + , + , + , + , + , + ; + clocks = <&mstp9_clks R7S72100_CLK_I2C0>; + clock-frequency = <100000>; + power-domains = <&cpg_clocks>; + #address-cells = <1>; + #size-cells = <0>; + }; -- cgit v1.2.3 From c021087c43c8f9b0bb070a85d49f2e3ac450c43e Mon Sep 17 00:00:00 2001 From: Hsin-Yi Wang Date: Thu, 27 May 2021 15:55:54 +0800 Subject: dt-binding: i2c: mt65xx: add vbus-supply property Add vbus-supply property for mt65xx. The regulator can be passed into core and turned off during suspend/sleep to reduce power consumption. Signed-off-by: Hsin-Yi Wang Acked-by: Rob Herring Signed-off-by: Wolfram Sang --- Documentation/devicetree/bindings/i2c/i2c-mt65xx.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/i2c/i2c-mt65xx.txt b/Documentation/devicetree/bindings/i2c/i2c-mt65xx.txt index 7f0194fdd0cc..2c45647e9f0b 100644 --- a/Documentation/devicetree/bindings/i2c/i2c-mt65xx.txt +++ b/Documentation/devicetree/bindings/i2c/i2c-mt65xx.txt @@ -32,6 +32,7 @@ Optional properties: - mediatek,have-pmic: platform can control i2c form special pmic side. Only mt6589 and mt8135 support this feature. - mediatek,use-push-pull: IO config use push-pull mode. + - vbus-supply: phandle to the regulator that provides power to SCL/SDA. Example: -- cgit v1.2.3 From fc8c262e0eb5aa248af5051377e4ff3348841ac5 Mon Sep 17 00:00:00 2001 From: Yonghong Song Date: Wed, 26 May 2021 08:24:57 -0700 Subject: bpf, docs: Add llvm_reloc.rst to explain llvm bpf relocations LLVM upstream commit https://reviews.llvm.org/D102712 made some changes to bpf relocations to make them llvm linker lld friendly. The scope of existing relocations R_BPF_64_{64,32} is narrowed and new relocations R_BPF_64_{ABS32,ABS64,NODYLD32} are introduced. Let us add some documentation about llvm bpf relocations so people can understand how to resolve them properly in their respective tools. Signed-off-by: Yonghong Song Signed-off-by: Daniel Borkmann Acked-by: John Fastabend Link: https://lore.kernel.org/bpf/20210526152457.335210-1-yhs@fb.com --- Documentation/bpf/index.rst | 1 + Documentation/bpf/llvm_reloc.rst | 240 +++++++++++++++++++++++++++++++++++++++ 2 files changed, 241 insertions(+) create mode 100644 Documentation/bpf/llvm_reloc.rst (limited to 'Documentation') diff --git a/Documentation/bpf/index.rst b/Documentation/bpf/index.rst index a702f67dd45f..93e8cf12a6d4 100644 --- a/Documentation/bpf/index.rst +++ b/Documentation/bpf/index.rst @@ -84,6 +84,7 @@ Other :maxdepth: 1 ringbuf + llvm_reloc .. Links: .. _networking-filter: ../networking/filter.rst diff --git a/Documentation/bpf/llvm_reloc.rst b/Documentation/bpf/llvm_reloc.rst new file mode 100644 index 000000000000..ca8957d5b671 --- /dev/null +++ b/Documentation/bpf/llvm_reloc.rst @@ -0,0 +1,240 @@ +.. SPDX-License-Identifier: (LGPL-2.1 OR BSD-2-Clause) + +==================== +BPF LLVM Relocations +==================== + +This document describes LLVM BPF backend relocation types. + +Relocation Record +================= + +LLVM BPF backend records each relocation with the following 16-byte +ELF structure:: + + typedef struct + { + Elf64_Addr r_offset; // Offset from the beginning of section. + Elf64_Xword r_info; // Relocation type and symbol index. + } Elf64_Rel; + +For example, for the following code:: + + int g1 __attribute__((section("sec"))); + int g2 __attribute__((section("sec"))); + static volatile int l1 __attribute__((section("sec"))); + static volatile int l2 __attribute__((section("sec"))); + int test() { + return g1 + g2 + l1 + l2; + } + +Compiled with ``clang -target bpf -O2 -c test.c``, the following is +the code with ``llvm-objdump -dr test.o``:: + + 0: 18 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 r1 = 0 ll + 0000000000000000: R_BPF_64_64 g1 + 2: 61 11 00 00 00 00 00 00 r1 = *(u32 *)(r1 + 0) + 3: 18 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 r2 = 0 ll + 0000000000000018: R_BPF_64_64 g2 + 5: 61 20 00 00 00 00 00 00 r0 = *(u32 *)(r2 + 0) + 6: 0f 10 00 00 00 00 00 00 r0 += r1 + 7: 18 01 00 00 08 00 00 00 00 00 00 00 00 00 00 00 r1 = 8 ll + 0000000000000038: R_BPF_64_64 sec + 9: 61 11 00 00 00 00 00 00 r1 = *(u32 *)(r1 + 0) + 10: 0f 10 00 00 00 00 00 00 r0 += r1 + 11: 18 01 00 00 0c 00 00 00 00 00 00 00 00 00 00 00 r1 = 12 ll + 0000000000000058: R_BPF_64_64 sec + 13: 61 11 00 00 00 00 00 00 r1 = *(u32 *)(r1 + 0) + 14: 0f 10 00 00 00 00 00 00 r0 += r1 + 15: 95 00 00 00 00 00 00 00 exit + +There are four relations in the above for four ``LD_imm64`` instructions. +The following ``llvm-readelf -r test.o`` shows the binary values of the four +relocations:: + + Relocation section '.rel.text' at offset 0x190 contains 4 entries: + Offset Info Type Symbol's Value Symbol's Name + 0000000000000000 0000000600000001 R_BPF_64_64 0000000000000000 g1 + 0000000000000018 0000000700000001 R_BPF_64_64 0000000000000004 g2 + 0000000000000038 0000000400000001 R_BPF_64_64 0000000000000000 sec + 0000000000000058 0000000400000001 R_BPF_64_64 0000000000000000 sec + +Each relocation is represented by ``Offset`` (8 bytes) and ``Info`` (8 bytes). +For example, the first relocation corresponds to the first instruction +(Offset 0x0) and the corresponding ``Info`` indicates the relocation type +of ``R_BPF_64_64`` (type 1) and the entry in the symbol table (entry 6). +The following is the symbol table with ``llvm-readelf -s test.o``:: + + Symbol table '.symtab' contains 8 entries: + Num: Value Size Type Bind Vis Ndx Name + 0: 0000000000000000 0 NOTYPE LOCAL DEFAULT UND + 1: 0000000000000000 0 FILE LOCAL DEFAULT ABS test.c + 2: 0000000000000008 4 OBJECT LOCAL DEFAULT 4 l1 + 3: 000000000000000c 4 OBJECT LOCAL DEFAULT 4 l2 + 4: 0000000000000000 0 SECTION LOCAL DEFAULT 4 sec + 5: 0000000000000000 128 FUNC GLOBAL DEFAULT 2 test + 6: 0000000000000000 4 OBJECT GLOBAL DEFAULT 4 g1 + 7: 0000000000000004 4 OBJECT GLOBAL DEFAULT 4 g2 + +The 6th entry is global variable ``g1`` with value 0. + +Similarly, the second relocation is at ``.text`` offset ``0x18``, instruction 3, +for global variable ``g2`` which has a symbol value 4, the offset +from the start of ``.data`` section. + +The third and fourth relocations refers to static variables ``l1`` +and ``l2``. From ``.rel.text`` section above, it is not clear +which symbols they really refers to as they both refers to +symbol table entry 4, symbol ``sec``, which has ``STT_SECTION`` type +and represents a section. So for static variable or function, +the section offset is written to the original insn +buffer, which is called ``A`` (addend). Looking at +above insn ``7`` and ``11``, they have section offset ``8`` and ``12``. +From symbol table, we can find that they correspond to entries ``2`` +and ``3`` for ``l1`` and ``l2``. + +In general, the ``A`` is 0 for global variables and functions, +and is the section offset or some computation result based on +section offset for static variables/functions. The non-section-offset +case refers to function calls. See below for more details. + +Different Relocation Types +========================== + +Six relocation types are supported. The following is an overview and +``S`` represents the value of the symbol in the symbol table:: + + Enum ELF Reloc Type Description BitSize Offset Calculation + 0 R_BPF_NONE None + 1 R_BPF_64_64 ld_imm64 insn 32 r_offset + 4 S + A + 2 R_BPF_64_ABS64 normal data 64 r_offset S + A + 3 R_BPF_64_ABS32 normal data 32 r_offset S + A + 4 R_BPF_64_NODYLD32 .BTF[.ext] data 32 r_offset S + A + 10 R_BPF_64_32 call insn 32 r_offset + 4 (S + A) / 8 - 1 + +For example, ``R_BPF_64_64`` relocation type is used for ``ld_imm64`` instruction. +The actual to-be-relocated data (0 or section offset) +is stored at ``r_offset + 4`` and the read/write +data bitsize is 32 (4 bytes). The relocation can be resolved with +the symbol value plus implicit addend. Note that the ``BitSize`` is 32 which +means the section offset must be less than or equal to ``UINT32_MAX`` and this +is enforced by LLVM BPF backend. + +In another case, ``R_BPF_64_ABS64`` relocation type is used for normal 64-bit data. +The actual to-be-relocated data is stored at ``r_offset`` and the read/write data +bitsize is 64 (8 bytes). The relocation can be resolved with +the symbol value plus implicit addend. + +Both ``R_BPF_64_ABS32`` and ``R_BPF_64_NODYLD32`` types are for 32-bit data. +But ``R_BPF_64_NODYLD32`` specifically refers to relocations in ``.BTF`` and +``.BTF.ext`` sections. For cases like bcc where llvm ``ExecutionEngine RuntimeDyld`` +is involved, ``R_BPF_64_NODYLD32`` types of relocations should not be resolved +to actual function/variable address. Otherwise, ``.BTF`` and ``.BTF.ext`` +become unusable by bcc and kernel. + +Type ``R_BPF_64_32`` is used for call instruction. The call target section +offset is stored at ``r_offset + 4`` (32bit) and calculated as +``(S + A) / 8 - 1``. + +Examples +======== + +Types ``R_BPF_64_64`` and ``R_BPF_64_32`` are used to resolve ``ld_imm64`` +and ``call`` instructions. For example:: + + __attribute__((noinline)) __attribute__((section("sec1"))) + int gfunc(int a, int b) { + return a * b; + } + static __attribute__((noinline)) __attribute__((section("sec1"))) + int lfunc(int a, int b) { + return a + b; + } + int global __attribute__((section("sec2"))); + int test(int a, int b) { + return gfunc(a, b) + lfunc(a, b) + global; + } + +Compiled with ``clang -target bpf -O2 -c test.c``, we will have +following code with `llvm-objdump -dr test.o``:: + + Disassembly of section .text: + + 0000000000000000 : + 0: bf 26 00 00 00 00 00 00 r6 = r2 + 1: bf 17 00 00 00 00 00 00 r7 = r1 + 2: 85 10 00 00 ff ff ff ff call -1 + 0000000000000010: R_BPF_64_32 gfunc + 3: bf 08 00 00 00 00 00 00 r8 = r0 + 4: bf 71 00 00 00 00 00 00 r1 = r7 + 5: bf 62 00 00 00 00 00 00 r2 = r6 + 6: 85 10 00 00 02 00 00 00 call 2 + 0000000000000030: R_BPF_64_32 sec1 + 7: 0f 80 00 00 00 00 00 00 r0 += r8 + 8: 18 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 r1 = 0 ll + 0000000000000040: R_BPF_64_64 global + 10: 61 11 00 00 00 00 00 00 r1 = *(u32 *)(r1 + 0) + 11: 0f 10 00 00 00 00 00 00 r0 += r1 + 12: 95 00 00 00 00 00 00 00 exit + + Disassembly of section sec1: + + 0000000000000000 : + 0: bf 20 00 00 00 00 00 00 r0 = r2 + 1: 2f 10 00 00 00 00 00 00 r0 *= r1 + 2: 95 00 00 00 00 00 00 00 exit + + 0000000000000018 : + 3: bf 20 00 00 00 00 00 00 r0 = r2 + 4: 0f 10 00 00 00 00 00 00 r0 += r1 + 5: 95 00 00 00 00 00 00 00 exit + +The first relocation corresponds to ``gfunc(a, b)`` where ``gfunc`` has a value of 0, +so the ``call`` instruction offset is ``(0 + 0)/8 - 1 = -1``. +The second relocation corresponds to ``lfunc(a, b)`` where ``lfunc`` has a section +offset ``0x18``, so the ``call`` instruction offset is ``(0 + 0x18)/8 - 1 = 2``. +The third relocation corresponds to ld_imm64 of ``global``, which has a section +offset ``0``. + +The following is an example to show how R_BPF_64_ABS64 could be generated:: + + int global() { return 0; } + struct t { void *g; } gbl = { global }; + +Compiled with ``clang -target bpf -O2 -g -c test.c``, we will see a +relocation below in ``.data`` section with command +``llvm-readelf -r test.o``:: + + Relocation section '.rel.data' at offset 0x458 contains 1 entries: + Offset Info Type Symbol's Value Symbol's Name + 0000000000000000 0000000700000002 R_BPF_64_ABS64 0000000000000000 global + +The relocation says the first 8-byte of ``.data`` section should be +filled with address of ``global`` variable. + +With ``llvm-readelf`` output, we can see that dwarf sections have a bunch of +``R_BPF_64_ABS32`` and ``R_BPF_64_ABS64`` relocations:: + + Relocation section '.rel.debug_info' at offset 0x468 contains 13 entries: + Offset Info Type Symbol's Value Symbol's Name + 0000000000000006 0000000300000003 R_BPF_64_ABS32 0000000000000000 .debug_abbrev + 000000000000000c 0000000400000003 R_BPF_64_ABS32 0000000000000000 .debug_str + 0000000000000012 0000000400000003 R_BPF_64_ABS32 0000000000000000 .debug_str + 0000000000000016 0000000600000003 R_BPF_64_ABS32 0000000000000000 .debug_line + 000000000000001a 0000000400000003 R_BPF_64_ABS32 0000000000000000 .debug_str + 000000000000001e 0000000200000002 R_BPF_64_ABS64 0000000000000000 .text + 000000000000002b 0000000400000003 R_BPF_64_ABS32 0000000000000000 .debug_str + 0000000000000037 0000000800000002 R_BPF_64_ABS64 0000000000000000 gbl + 0000000000000040 0000000400000003 R_BPF_64_ABS32 0000000000000000 .debug_str + ...... + +The .BTF/.BTF.ext sections has R_BPF_64_NODYLD32 relocations:: + + Relocation section '.rel.BTF' at offset 0x538 contains 1 entries: + Offset Info Type Symbol's Value Symbol's Name + 0000000000000084 0000000800000004 R_BPF_64_NODYLD32 0000000000000000 gbl + + Relocation section '.rel.BTF.ext' at offset 0x548 contains 2 entries: + Offset Info Type Symbol's Value Symbol's Name + 000000000000002c 0000000200000004 R_BPF_64_NODYLD32 0000000000000000 .text + 0000000000000040 0000000200000004 R_BPF_64_NODYLD32 0000000000000000 .text -- cgit v1.2.3 From 744ee14054c8ca5ad0fe3ab9172709c17d8a240a Mon Sep 17 00:00:00 2001 From: Matthieu Baerts Date: Thu, 27 May 2021 16:54:30 -0700 Subject: mptcp: restrict values of 'enabled' sysctl To avoid confusions, it seems better to parse this sysctl parameter as a boolean. We use it as a boolean, no need to parse an integer and bring confusions if we see a value different from 0 and 1, especially with this parameter name: enabled. It seems fine to do this modification because the default value is 1 (enabled). Then the only other interesting value to set is 0 (disabled). All other values would not have changed the default behaviour. Suggested-by: Florian Westphal Acked-by: Florian Westphal Signed-off-by: Matthieu Baerts Signed-off-by: Mat Martineau Signed-off-by: Jakub Kicinski --- Documentation/networking/mptcp-sysctl.rst | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/networking/mptcp-sysctl.rst b/Documentation/networking/mptcp-sysctl.rst index 6af0196c4297..3b352e5f6300 100644 --- a/Documentation/networking/mptcp-sysctl.rst +++ b/Documentation/networking/mptcp-sysctl.rst @@ -7,13 +7,13 @@ MPTCP Sysfs variables /proc/sys/net/mptcp/* Variables =============================== -enabled - INTEGER +enabled - BOOLEAN Control whether MPTCP sockets can be created. - MPTCP sockets can be created if the value is nonzero. This is - a per-namespace sysctl. + MPTCP sockets can be created if the value is 1. This is a + per-namespace sysctl. - Default: 1 + Default: 1 (enabled) add_addr_timeout - INTEGER (seconds) Set the timeout after which an ADD_ADDR control message will be -- cgit v1.2.3 From 04a82a13f12d15b611e7363e6e060a9f130a94c8 Mon Sep 17 00:00:00 2001 From: Manivannan Sadhasivam Date: Tue, 27 Apr 2021 12:23:58 +0530 Subject: dt-bindings: phy: qcom,qmp: Add binding for SDX55 PCIe PHY Add devicetree binding for PCIe PHY found in Qcom SDX55 platform. Signed-off-by: Manivannan Sadhasivam Reviewed-by: Bjorn Andersson Acked-by: Rob Herring Link: https://lore.kernel.org/r/20210427065400.18958-2-manivannan.sadhasivam@linaro.org Signed-off-by: Vinod Koul --- Documentation/devicetree/bindings/phy/qcom,qmp-phy.yaml | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/phy/qcom,qmp-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,qmp-phy.yaml index b8e1a33fd0df..0f14de02e45b 100644 --- a/Documentation/devicetree/bindings/phy/qcom,qmp-phy.yaml +++ b/Documentation/devicetree/bindings/phy/qcom,qmp-phy.yaml @@ -46,6 +46,7 @@ properties: - qcom,sm8350-qmp-ufs-phy - qcom,sm8350-qmp-usb3-phy - qcom,sm8350-qmp-usb3-uni-phy + - qcom,sdx55-qmp-pcie-phy - qcom,sdx55-qmp-usb3-uni-phy reg: @@ -328,6 +329,7 @@ allOf: enum: - qcom,sdm845-qhp-pcie-phy - qcom,sdm845-qmp-pcie-phy + - qcom,sdx55-qmp-pcie-phy - qcom,sm8250-qmp-gen3x1-pcie-phy - qcom,sm8250-qmp-gen3x2-pcie-phy - qcom,sm8250-qmp-modem-pcie-phy -- cgit v1.2.3 From fab6216fafdd74cd84de929ffe7b787976d32cff Mon Sep 17 00:00:00 2001 From: Xiongwei Song Date: Mon, 24 May 2021 23:05:45 +0800 Subject: locking/lockdep,doc: Improve readability of the block matrix The block condition matrix is using 'E' as the writer notation, however, the writer reminder below the matrix is using 'W', to make them consistent and make the matrix more readable, we'd better to use 'W' to represent writer. Suggested-by: Waiman Long Suggested-by: Boqun Feng Signed-off-by: Xiongwei Song Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Boqun Feng Link: https://lkml.kernel.org/r/1621868745-23311-1-git-send-email-sxwjean@me.com --- Documentation/locking/lockdep-design.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/locking/lockdep-design.rst b/Documentation/locking/lockdep-design.rst index 9f3cfca9f8a4..82f36cab61bd 100644 --- a/Documentation/locking/lockdep-design.rst +++ b/Documentation/locking/lockdep-design.rst @@ -453,9 +453,9 @@ There are simply four block conditions: Block condition matrix, Y means the row blocks the column, and N means otherwise. +---+---+---+---+ - | | E | r | R | + | | W | r | R | +---+---+---+---+ - | E | Y | Y | Y | + | W | Y | Y | Y | +---+---+---+---+ | r | Y | Y | N | +---+---+---+---+ -- cgit v1.2.3 From 436b6403db532e3d29cff554a95f448f7f11a165 Mon Sep 17 00:00:00 2001 From: Amelie Delaunay Date: Mon, 17 May 2021 14:08:20 +0200 Subject: dt-bindings: phy: add vbus-supply optional property to phy-stm32-usbphyc This patch adds vbus-supply optional property to phy sub-nodes using connector node. A regulator for USB VBUS may be needed for host mode. Reviewed-by: Rob Herring Signed-off-by: Amelie Delaunay Link: https://lore.kernel.org/r/20210517120821.26466-2-amelie.delaunay@foss.st.com Signed-off-by: Vinod Koul --- Documentation/devicetree/bindings/phy/phy-stm32-usbphyc.yaml | 11 +++++++++++ 1 file changed, 11 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/phy/phy-stm32-usbphyc.yaml b/Documentation/devicetree/bindings/phy/phy-stm32-usbphyc.yaml index 018cc1246ee1..3329f1d33a4f 100644 --- a/Documentation/devicetree/bindings/phy/phy-stm32-usbphyc.yaml +++ b/Documentation/devicetree/bindings/phy/phy-stm32-usbphyc.yaml @@ -74,6 +74,13 @@ patternProperties: "#phy-cells": enum: [ 0x0, 0x1 ] + connector: + type: object + allOf: + - $ref: ../connector/usb-connector.yaml + properties: + vbus-supply: true + allOf: - if: properties: @@ -130,6 +137,10 @@ examples: reg = <0>; phy-supply = <&vdd_usb>; #phy-cells = <0>; + connector { + compatible = "usb-a-connector"; + vbus-supply = <&vbus_sw>; + }; }; usbphyc_port1: usb-phy@1 { -- cgit v1.2.3 From 74478ab503b0554b8a296abc89248f7ee5a45366 Mon Sep 17 00:00:00 2001 From: Tobias Schramm Date: Fri, 14 May 2021 17:00:40 +0200 Subject: dt-bindings: phy: rockchip-inno-usb2: add compatible for rk3308 USB phy The RK3308 features a slightly different USB phy than other Rockchip SoCs. This patch adds a compatible string for it. Signed-off-by: Tobias Schramm Acked-by: Rob Herring Link: https://lore.kernel.org/r/20210514150044.2099298-2-t.schramm@manjaro.org Signed-off-by: Vinod Koul --- Documentation/devicetree/bindings/phy/phy-rockchip-inno-usb2.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/phy/phy-rockchip-inno-usb2.yaml b/Documentation/devicetree/bindings/phy/phy-rockchip-inno-usb2.yaml index fb29ad807b68..a5b027a6e70f 100644 --- a/Documentation/devicetree/bindings/phy/phy-rockchip-inno-usb2.yaml +++ b/Documentation/devicetree/bindings/phy/phy-rockchip-inno-usb2.yaml @@ -14,6 +14,7 @@ properties: enum: - rockchip,px30-usb2phy - rockchip,rk3228-usb2phy + - rockchip,rk3308-usb2phy - rockchip,rk3328-usb2phy - rockchip,rk3366-usb2phy - rockchip,rk3399-usb2phy -- cgit v1.2.3 From 46923bdb14c2a51fb1e1bb917c5e16781d089d2e Mon Sep 17 00:00:00 2001 From: Johan Jonker Date: Tue, 18 May 2021 18:56:55 +0200 Subject: dt-bindings: phy: convert rockchip-usb-phy.txt to YAML Current dts files with Rockchip 'usbphy' nodes are manually verified. In order to automate this process rockchip-usb-phy.txt has to be converted to YAML. Signed-off-by: Johan Jonker Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20210518165658.12764-2-jbx6244@gmail.com Signed-off-by: Vinod Koul --- .../devicetree/bindings/phy/rockchip-usb-phy.txt | 52 -------------- .../devicetree/bindings/phy/rockchip-usb-phy.yaml | 81 ++++++++++++++++++++++ 2 files changed, 81 insertions(+), 52 deletions(-) delete mode 100644 Documentation/devicetree/bindings/phy/rockchip-usb-phy.txt create mode 100644 Documentation/devicetree/bindings/phy/rockchip-usb-phy.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/phy/rockchip-usb-phy.txt b/Documentation/devicetree/bindings/phy/rockchip-usb-phy.txt deleted file mode 100644 index 4ed569046daf..000000000000 --- a/Documentation/devicetree/bindings/phy/rockchip-usb-phy.txt +++ /dev/null @@ -1,52 +0,0 @@ -ROCKCHIP USB2 PHY - -Required properties: - - compatible: matching the soc type, one of - "rockchip,rk3066a-usb-phy" - "rockchip,rk3188-usb-phy" - "rockchip,rk3288-usb-phy" - - #address-cells: should be 1 - - #size-cells: should be 0 - -Deprecated properties: - - rockchip,grf : phandle to the syscon managing the "general - register files" - phy should be a child of the GRF instead - -Sub-nodes: -Each PHY should be represented as a sub-node. - -Sub-nodes -required properties: -- #phy-cells: should be 0 -- reg: PHY configure reg address offset in GRF - "0x320" - for PHY attach to OTG controller - "0x334" - for PHY attach to HOST0 controller - "0x348" - for PHY attach to HOST1 controller - -Optional Properties: -- clocks : phandle + clock specifier for the phy clocks -- clock-names: string, clock name, must be "phyclk" -- #clock-cells: for users of the phy-pll, should be 0 -- reset-names: Only allow the following entries: - - phy-reset -- resets: Must contain an entry for each entry in reset-names. -- vbus-supply: power-supply phandle for vbus power source - -Example: - -grf: syscon@ff770000 { - compatible = "rockchip,rk3288-grf", "syscon", "simple-mfd"; - -... - - usbphy: phy { - compatible = "rockchip,rk3288-usb-phy"; - #address-cells = <1>; - #size-cells = <0>; - - usbphy0: usb-phy0 { - #phy-cells = <0>; - reg = <0x320>; - }; - }; -}; diff --git a/Documentation/devicetree/bindings/phy/rockchip-usb-phy.yaml b/Documentation/devicetree/bindings/phy/rockchip-usb-phy.yaml new file mode 100644 index 000000000000..f0fc8275dcd0 --- /dev/null +++ b/Documentation/devicetree/bindings/phy/rockchip-usb-phy.yaml @@ -0,0 +1,81 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/phy/rockchip-usb-phy.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Rockchip USB2.0 phy + +maintainers: + - Heiko Stuebner + +properties: + compatible: + oneOf: + - const: rockchip,rk3288-usb-phy + - items: + - enum: + - rockchip,rk3066a-usb-phy + - rockchip,rk3188-usb-phy + - const: rockchip,rk3288-usb-phy + + "#address-cells": + const: 1 + + "#size-cells": + const: 0 + +required: + - compatible + - "#address-cells" + - "#size-cells" + +additionalProperties: false + +patternProperties: + "usb-phy@[0-9a-f]+$": + type: object + + properties: + reg: + maxItems: 1 + + "#phy-cells": + const: 0 + + clocks: + maxItems: 1 + + clock-names: + const: phyclk + + "#clock-cells": + const: 0 + + resets: + maxItems: 1 + + reset-names: + const: phy-reset + + vbus-supply: + description: phandle for vbus power source + + required: + - reg + - "#phy-cells" + + additionalProperties: false + +examples: + - | + usbphy: usbphy { + compatible = "rockchip,rk3288-usb-phy"; + #address-cells = <1>; + #size-cells = <0>; + + usbphy0: usb-phy@320 { + reg = <0x320>; + #phy-cells = <0>; + }; + }; -- cgit v1.2.3 From 2ed2732ef28aefdc3b495409fbd05cc388a73c62 Mon Sep 17 00:00:00 2001 From: Johan Jonker Date: Wed, 12 May 2021 14:23:44 +0200 Subject: dt-bindings: soc: rockchip: convert grf.txt to YAML Current dts files with 'grf' nodes are manually verified. In order to automate this process grf.txt has to be converted to YAML. Most compatibility strings are in use with "simple-mfd" added. Changed compatibles: "rockchip,rk3066-grf", "syscon", "simple-mfd" "rockchip,rk3188-grf", "syscon", "simple-mfd" Add description already in use: "rockchip,rv1108-pmugrf", "syscon" Add new descriptions for: "rockchip,rk3568-grf", "syscon", "simple-mfd" "rockchip,rk3568-pmugrf", "syscon", "simple-mfd" Signed-off-by: Johan Jonker Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20210512122346.9463-3-jbx6244@gmail.com Signed-off-by: Heiko Stuebner --- .../devicetree/bindings/soc/rockchip/grf.txt | 61 ----- .../devicetree/bindings/soc/rockchip/grf.yaml | 260 +++++++++++++++++++++ 2 files changed, 260 insertions(+), 61 deletions(-) delete mode 100644 Documentation/devicetree/bindings/soc/rockchip/grf.txt create mode 100644 Documentation/devicetree/bindings/soc/rockchip/grf.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/soc/rockchip/grf.txt b/Documentation/devicetree/bindings/soc/rockchip/grf.txt deleted file mode 100644 index f96511aa3897..000000000000 --- a/Documentation/devicetree/bindings/soc/rockchip/grf.txt +++ /dev/null @@ -1,61 +0,0 @@ -* Rockchip General Register Files (GRF) - -The general register file will be used to do static set by software, which -is composed of many registers for system control. - -From RK3368 SoCs, the GRF is divided into two sections, -- GRF, used for general non-secure system, -- SGRF, used for general secure system, -- PMUGRF, used for always on system - -On RK3328 SoCs, the GRF adds a section for USB2PHYGRF, - -ON RK3308 SoC, the GRF is divided into four sections: -- GRF, used for general non-secure system, -- SGRF, used for general secure system, -- DETECTGRF, used for audio codec system, -- COREGRF, used for pvtm, - -Required Properties: - -- compatible: GRF should be one of the following: - - "rockchip,px30-grf", "syscon": for px30 - - "rockchip,rk3036-grf", "syscon": for rk3036 - - "rockchip,rk3066-grf", "syscon": for rk3066 - - "rockchip,rk3188-grf", "syscon": for rk3188 - - "rockchip,rk3228-grf", "syscon": for rk3228 - - "rockchip,rk3288-grf", "syscon": for rk3288 - - "rockchip,rk3308-grf", "syscon": for rk3308 - - "rockchip,rk3328-grf", "syscon": for rk3328 - - "rockchip,rk3368-grf", "syscon": for rk3368 - - "rockchip,rk3399-grf", "syscon": for rk3399 - - "rockchip,rv1108-grf", "syscon": for rv1108 -- compatible: DETECTGRF should be one of the following: - - "rockchip,rk3308-detect-grf", "syscon": for rk3308 -- compatilbe: COREGRF should be one of the following: - - "rockchip,rk3308-core-grf", "syscon": for rk3308 -- compatible: PMUGRF should be one of the following: - - "rockchip,px30-pmugrf", "syscon": for px30 - - "rockchip,rk3368-pmugrf", "syscon": for rk3368 - - "rockchip,rk3399-pmugrf", "syscon": for rk3399 -- compatible: SGRF should be one of the following: - - "rockchip,rk3288-sgrf", "syscon": for rk3288 -- compatible: USB2PHYGRF should be one of the following: - - "rockchip,px30-usb2phy-grf", "syscon": for px30 - - "rockchip,rk3328-usb2phy-grf", "syscon": for rk3328 -- compatible: USBGRF should be one of the following: - - "rockchip,rv1108-usbgrf", "syscon": for rv1108 -- reg: physical base address of the controller and length of memory mapped - region. - -Example: GRF and PMUGRF of RK3399 SoCs - - pmugrf: syscon@ff320000 { - compatible = "rockchip,rk3399-pmugrf", "syscon"; - reg = <0x0 0xff320000 0x0 0x1000>; - }; - - grf: syscon@ff770000 { - compatible = "rockchip,rk3399-grf", "syscon"; - reg = <0x0 0xff770000 0x0 0x10000>; - }; diff --git a/Documentation/devicetree/bindings/soc/rockchip/grf.yaml b/Documentation/devicetree/bindings/soc/rockchip/grf.yaml new file mode 100644 index 000000000000..84bdaf88d5a6 --- /dev/null +++ b/Documentation/devicetree/bindings/soc/rockchip/grf.yaml @@ -0,0 +1,260 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/soc/rockchip/grf.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Rockchip General Register Files (GRF) + +maintainers: + - Heiko Stuebner + +properties: + compatible: + oneOf: + - items: + - enum: + - rockchip,rk3288-sgrf + - rockchip,rv1108-pmugrf + - rockchip,rv1108-usbgrf + - const: syscon + - items: + - enum: + - rockchip,px30-grf + - rockchip,px30-pmugrf + - rockchip,px30-usb2phy-grf + - rockchip,rk3036-grf + - rockchip,rk3066-grf + - rockchip,rk3188-grf + - rockchip,rk3228-grf + - rockchip,rk3288-grf + - rockchip,rk3308-core-grf + - rockchip,rk3308-detect-grf + - rockchip,rk3308-grf + - rockchip,rk3328-grf + - rockchip,rk3328-usb2phy-grf + - rockchip,rk3368-grf + - rockchip,rk3368-pmugrf + - rockchip,rk3399-grf + - rockchip,rk3399-pmugrf + - rockchip,rk3568-grf + - rockchip,rk3568-pmugrf + - rockchip,rv1108-grf + - const: syscon + - const: simple-mfd + + reg: + maxItems: 1 + + "#address-cells": + const: 1 + + "#size-cells": + const: 1 + +required: + - compatible + - reg + +additionalProperties: + type: object + +allOf: + - if: + properties: + compatible: + contains: + const: rockchip,px30-grf + + then: + properties: + lvds: + description: + Documentation/devicetree/bindings/display/rockchip/rockchip-lvds.txt + + - if: + properties: + compatible: + contains: + const: rockchip,rk3288-grf + + then: + properties: + edp-phy: + description: + Documentation/devicetree/bindings/phy/rockchip-dp-phy.txt + + - if: + properties: + compatible: + contains: + enum: + - rockchip,rk3066-grf + - rockchip,rk3188-grf + - rockchip,rk3288-grf + + then: + properties: + usbphy: + type: object + + $ref: "/schemas/phy/rockchip-usb-phy.yaml#" + + unevaluatedProperties: false + + - if: + properties: + compatible: + contains: + const: rockchip,rk3328-grf + + then: + properties: + gpio: + type: object + + $ref: "/schemas/gpio/rockchip,rk3328-grf-gpio.yaml#" + + unevaluatedProperties: false + + power-controller: + type: object + + $ref: "/schemas/power/rockchip,power-controller.yaml#" + + unevaluatedProperties: false + + - if: + properties: + compatible: + contains: + const: rockchip,rk3399-grf + + then: + properties: + mipi-dphy-rx0: + type: object + + $ref: "/schemas/phy/rockchip-mipi-dphy-rx0.yaml#" + + unevaluatedProperties: false + + pcie-phy: + description: + Documentation/devicetree/bindings/phy/rockchip-pcie-phy.txt + + patternProperties: + "phy@[0-9a-f]+$": + description: + Documentation/devicetree/bindings/phy/rockchip-emmc-phy.txt + + - if: + properties: + compatible: + contains: + enum: + - rockchip,px30-pmugrf + - rockchip,rk3036-grf + - rockchip,rk3308-grf + - rockchip,rk3368-pmugrf + + then: + properties: + reboot-mode: + type: object + + $ref: "/schemas/power/reset/syscon-reboot-mode.yaml#" + + unevaluatedProperties: false + + - if: + properties: + compatible: + contains: + enum: + - rockchip,px30-usb2phy-grf + - rockchip,rk3228-grf + - rockchip,rk3328-usb2phy-grf + - rockchip,rk3399-grf + - rockchip,rv1108-grf + + then: + required: + - "#address-cells" + - "#size-cells" + + patternProperties: + "usb2-phy@[0-9a-f]+$": + type: object + + $ref: "/schemas/phy/phy-rockchip-inno-usb2.yaml#" + + unevaluatedProperties: false + + - if: + properties: + compatible: + contains: + enum: + - rockchip,px30-pmugrf + - rockchip,px30-grf + - rockchip,rk3228-grf + - rockchip,rk3288-grf + - rockchip,rk3328-grf + - rockchip,rk3368-pmugrf + - rockchip,rk3368-grf + - rockchip,rk3399-pmugrf + - rockchip,rk3399-grf + + then: + properties: + io-domains: + description: + Documentation/devicetree/bindings/power/rockchip-io-domain.txt + +examples: + - | + #include + #include + #include + grf: syscon@ff770000 { + compatible = "rockchip,rk3399-grf", "syscon", "simple-mfd"; + reg = <0xff770000 0x10000>; + #address-cells = <1>; + #size-cells = <1>; + + mipi_dphy_rx0: mipi-dphy-rx0 { + compatible = "rockchip,rk3399-mipi-dphy-rx0"; + clocks = <&cru SCLK_MIPIDPHY_REF>, + <&cru SCLK_DPHY_RX0_CFG>, + <&cru PCLK_VIO_GRF>; + clock-names = "dphy-ref", "dphy-cfg", "grf"; + power-domains = <&power RK3399_PD_VIO>; + #phy-cells = <0>; + }; + + u2phy0: usb2-phy@e450 { + compatible = "rockchip,rk3399-usb2phy"; + reg = <0xe450 0x10>; + clocks = <&cru SCLK_USB2PHY0_REF>; + clock-names = "phyclk"; + #clock-cells = <0>; + clock-output-names = "clk_usbphy0_480m"; + #phy-cells = <0>; + + u2phy0_host: host-port { + #phy-cells = <0>; + interrupts = ; + interrupt-names = "linestate"; + }; + + u2phy0_otg: otg-port { + #phy-cells = <0>; + interrupts = , + , + ; + interrupt-names = "otg-bvalid", "otg-id", + "linestate"; + }; + }; + }; -- cgit v1.2.3 From 68977e61ab9e3fbb8ebbb1c7e8c772762d232f7c Mon Sep 17 00:00:00 2001 From: Mika Westerberg Date: Mon, 12 Apr 2021 14:12:47 +0300 Subject: Documentation / thunderbolt: Clean up entries Align the "What" entries along with the rest and move nvm_authenticate_on_disconnect to correct place. Signed-off-by: Mika Westerberg --- Documentation/ABI/testing/sysfs-bus-thunderbolt | 44 ++++++++++++------------- 1 file changed, 22 insertions(+), 22 deletions(-) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-bus-thunderbolt b/Documentation/ABI/testing/sysfs-bus-thunderbolt index c41c68f64693..05afeee05538 100644 --- a/Documentation/ABI/testing/sysfs-bus-thunderbolt +++ b/Documentation/ABI/testing/sysfs-bus-thunderbolt @@ -1,4 +1,4 @@ -What: /sys/bus/thunderbolt/devices/.../domainX/boot_acl +What: /sys/bus/thunderbolt/devices/.../domainX/boot_acl Date: Jun 2018 KernelVersion: 4.17 Contact: thunderbolt-software@lists.01.org @@ -21,7 +21,7 @@ Description: Holds a comma separated list of device unique_ids that If a device is authorized automatically during boot its boot attribute is set to 1. -What: /sys/bus/thunderbolt/devices/.../domainX/deauthorization +What: /sys/bus/thunderbolt/devices/.../domainX/deauthorization Date: May 2021 KernelVersion: 5.12 Contact: Mika Westerberg @@ -30,7 +30,7 @@ Description: This attribute tells whether the system supports de-authorize PCIe tunnel by writing 0 to authorized attribute under each device. -What: /sys/bus/thunderbolt/devices/.../domainX/iommu_dma_protection +What: /sys/bus/thunderbolt/devices/.../domainX/iommu_dma_protection Date: Mar 2019 KernelVersion: 4.21 Contact: thunderbolt-software@lists.01.org @@ -39,7 +39,7 @@ Description: This attribute tells whether the system uses IOMMU it is not (DMA protection is solely based on Thunderbolt security levels). -What: /sys/bus/thunderbolt/devices/.../domainX/security +What: /sys/bus/thunderbolt/devices/.../domainX/security Date: Sep 2017 KernelVersion: 4.13 Contact: thunderbolt-software@lists.01.org @@ -61,7 +61,7 @@ Description: This attribute holds current Thunderbolt security level the BIOS. ======= ================================================== -What: /sys/bus/thunderbolt/devices/.../authorized +What: /sys/bus/thunderbolt/devices/.../authorized Date: Sep 2017 KernelVersion: 4.13 Contact: thunderbolt-software@lists.01.org @@ -95,14 +95,14 @@ Description: This attribute is used to authorize Thunderbolt devices EKEYREJECTED if the challenge response did not match. == ======================================================== -What: /sys/bus/thunderbolt/devices/.../boot +What: /sys/bus/thunderbolt/devices/.../boot Date: Jun 2018 KernelVersion: 4.17 Contact: thunderbolt-software@lists.01.org Description: This attribute contains 1 if Thunderbolt device was already authorized on boot and 0 otherwise. -What: /sys/bus/thunderbolt/devices/.../generation +What: /sys/bus/thunderbolt/devices/.../generation Date: Jan 2020 KernelVersion: 5.5 Contact: Christian Kellner @@ -110,7 +110,7 @@ Description: This attribute contains the generation of the Thunderbolt controller associated with the device. It will contain 4 for USB4. -What: /sys/bus/thunderbolt/devices/.../key +What: /sys/bus/thunderbolt/devices/.../key Date: Sep 2017 KernelVersion: 4.13 Contact: thunderbolt-software@lists.01.org @@ -226,6 +226,20 @@ Description: When new NVM image is written to the non-active NVM based mailbox before the device is power cycled. Writing 0 here clears the status. +What: /sys/bus/thunderbolt/devices/.../nvm_authenticate_on_disconnect +Date: Oct 2020 +KernelVersion: v5.9 +Contact: Mario Limonciello +Description: For supported devices, automatically authenticate the new Thunderbolt + image when the device is disconnected from the host system. + + This file will accept writing values "1" or "2" + + - Writing "1" will flush the image to the storage + area and prepare the device for authentication on disconnect. + - Writing "2" will run some basic validation on the image + and flush it to the storage area. + What: /sys/bus/thunderbolt/devices/./key Date: Jan 2018 KernelVersion: 4.15 @@ -308,17 +322,3 @@ Date: Oct 2020 KernelVersion: v5.9 Contact: Mika Westerberg Description: Retimer vendor identifier read from the hardware. - -What: /sys/bus/thunderbolt/devices/.../nvm_authenticate_on_disconnect -Date: Oct 2020 -KernelVersion: v5.9 -Contact: Mario Limonciello -Description: For supported devices, automatically authenticate the new Thunderbolt - image when the device is disconnected from the host system. - - This file will accept writing values "1" or "2" - - - Writing "1" will flush the image to the storage - area and prepare the device for authentication on disconnect. - - Writing "2" will run some basic validation on the image - and flush it to the storage area. -- cgit v1.2.3 From c58e7ed28b4534ed073371843d03c433d6a9fe34 Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Wed, 26 May 2021 12:22:51 -0400 Subject: PM: runtime: document common mistake with pm_runtime_get_sync() pm_runtime_get_sync(), contradictory to intuition, does not drop the runtime PM usage counter on errors which lead to several wrong usages in drivers (missing the put). pm_runtime_resume_and_get() was added as a better implementation so document the preference of using it, hoping it will stop bad patterns. Suggested-by: Marek Szyprowski Signed-off-by: Krzysztof Kozlowski [ rjw: Documentation change edits ] Signed-off-by: Rafael J. Wysocki --- Documentation/power/runtime_pm.rst | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/power/runtime_pm.rst b/Documentation/power/runtime_pm.rst index 18ae21bf7f92..b48cac5f9048 100644 --- a/Documentation/power/runtime_pm.rst +++ b/Documentation/power/runtime_pm.rst @@ -378,7 +378,11 @@ drivers/base/power/runtime.c and include/linux/pm_runtime.h: `int pm_runtime_get_sync(struct device *dev);` - increment the device's usage counter, run pm_runtime_resume(dev) and - return its result + return its result; + note that it does not drop the device's usage counter on errors, so + consider using pm_runtime_resume_and_get() instead of it, especially + if its return value is checked by the caller, as this is likely to + result in cleaner code. `int pm_runtime_get_if_in_use(struct device *dev);` - return -EINVAL if 'power.disable_depth' is nonzero; otherwise, if the -- cgit v1.2.3 From c4a41429951890d0bf7c1ef49b1fa1c8dfb1a034 Mon Sep 17 00:00:00 2001 From: Dmitry Osipenko Date: Sun, 16 May 2021 19:30:41 +0300 Subject: dt-bindings: clock: tegra: Convert to schema Convert NVIDIA Tegra clock bindings to schema. Reviewed-by: Rob Herring Signed-off-by: Dmitry Osipenko Signed-off-by: Thierry Reding --- .../bindings/clock/nvidia,tegra114-car.txt | 63 ----------- .../bindings/clock/nvidia,tegra124-car.txt | 107 ------------------- .../bindings/clock/nvidia,tegra124-car.yaml | 115 +++++++++++++++++++++ .../bindings/clock/nvidia,tegra20-car.txt | 63 ----------- .../bindings/clock/nvidia,tegra20-car.yaml | 69 +++++++++++++ .../bindings/clock/nvidia,tegra210-car.txt | 56 ---------- .../bindings/clock/nvidia,tegra30-car.txt | 63 ----------- 7 files changed, 184 insertions(+), 352 deletions(-) delete mode 100644 Documentation/devicetree/bindings/clock/nvidia,tegra114-car.txt delete mode 100644 Documentation/devicetree/bindings/clock/nvidia,tegra124-car.txt create mode 100644 Documentation/devicetree/bindings/clock/nvidia,tegra124-car.yaml delete mode 100644 Documentation/devicetree/bindings/clock/nvidia,tegra20-car.txt create mode 100644 Documentation/devicetree/bindings/clock/nvidia,tegra20-car.yaml delete mode 100644 Documentation/devicetree/bindings/clock/nvidia,tegra210-car.txt delete mode 100644 Documentation/devicetree/bindings/clock/nvidia,tegra30-car.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/nvidia,tegra114-car.txt b/Documentation/devicetree/bindings/clock/nvidia,tegra114-car.txt deleted file mode 100644 index 9acea9d93160..000000000000 --- a/Documentation/devicetree/bindings/clock/nvidia,tegra114-car.txt +++ /dev/null @@ -1,63 +0,0 @@ -NVIDIA Tegra114 Clock And Reset Controller - -This binding uses the common clock binding: -Documentation/devicetree/bindings/clock/clock-bindings.txt - -The CAR (Clock And Reset) Controller on Tegra is the HW module responsible -for muxing and gating Tegra's clocks, and setting their rates. - -Required properties : -- compatible : Should be "nvidia,tegra114-car" -- reg : Should contain CAR registers location and length -- clocks : Should contain phandle and clock specifiers for two clocks: - the 32 KHz "32k_in", and the board-specific oscillator "osc". -- #clock-cells : Should be 1. - In clock consumers, this cell represents the clock ID exposed by the - CAR. The assignments may be found in header file - . -- #reset-cells : Should be 1. - In clock consumers, this cell represents the bit number in the CAR's - array of CLK_RST_CONTROLLER_RST_DEVICES_* registers. - -Example SoC include file: - -/ { - tegra_car: clock { - compatible = "nvidia,tegra114-car"; - reg = <0x60006000 0x1000>; - #clock-cells = <1>; - #reset-cells = <1>; - }; - - usb@c5004000 { - clocks = <&tegra_car TEGRA114_CLK_USB2>; - }; -}; - -Example board file: - -/ { - clocks { - compatible = "simple-bus"; - #address-cells = <1>; - #size-cells = <0>; - - osc: clock@0 { - compatible = "fixed-clock"; - reg = <0>; - #clock-cells = <0>; - clock-frequency = <12000000>; - }; - - clk_32k: clock@1 { - compatible = "fixed-clock"; - reg = <1>; - #clock-cells = <0>; - clock-frequency = <32768>; - }; - }; - - &tegra_car { - clocks = <&clk_32k> <&osc>; - }; -}; diff --git a/Documentation/devicetree/bindings/clock/nvidia,tegra124-car.txt b/Documentation/devicetree/bindings/clock/nvidia,tegra124-car.txt deleted file mode 100644 index 7f02fb4ca4ad..000000000000 --- a/Documentation/devicetree/bindings/clock/nvidia,tegra124-car.txt +++ /dev/null @@ -1,107 +0,0 @@ -NVIDIA Tegra124 and Tegra132 Clock And Reset Controller - -This binding uses the common clock binding: -Documentation/devicetree/bindings/clock/clock-bindings.txt - -The CAR (Clock And Reset) Controller on Tegra is the HW module responsible -for muxing and gating Tegra's clocks, and setting their rates. - -Required properties : -- compatible : Should be "nvidia,tegra124-car" or "nvidia,tegra132-car" -- reg : Should contain CAR registers location and length -- clocks : Should contain phandle and clock specifiers for two clocks: - the 32 KHz "32k_in", and the board-specific oscillator "osc". -- #clock-cells : Should be 1. - In clock consumers, this cell represents the clock ID exposed by the - CAR. The assignments may be found in the header files - (which covers IDs common - to Tegra124 and Tegra132) and - (for Tegra124-specific clocks). -- #reset-cells : Should be 1. - In clock consumers, this cell represents the bit number in the CAR's - array of CLK_RST_CONTROLLER_RST_DEVICES_* registers. -- nvidia,external-memory-controller : phandle of the EMC driver. - -The node should contain a "emc-timings" subnode for each supported RAM type (see -field RAM_CODE in register PMC_STRAPPING_OPT_A). - -Required properties for "emc-timings" nodes : -- nvidia,ram-code : Should contain the value of RAM_CODE this timing set - is used for. - -Each "emc-timings" node should contain a "timing" subnode for every supported -EMC clock rate. - -Required properties for "timing" nodes : -- clock-frequency : Should contain the memory clock rate to which this timing -relates. -- nvidia,parent-clock-frequency : Should contain the rate at which the current -parent of the EMC clock should be running at this timing. -- clocks : Must contain an entry for each entry in clock-names. - See ../clocks/clock-bindings.txt for details. -- clock-names : Must include the following entries: - - emc-parent : the clock that should be the parent of the EMC clock at this -timing. - -Example SoC include file: - -/ { - tegra_car: clock@60006000 { - compatible = "nvidia,tegra124-car"; - reg = <0x60006000 0x1000>; - #clock-cells = <1>; - #reset-cells = <1>; - nvidia,external-memory-controller = <&emc>; - }; - - usb@c5004000 { - clocks = <&tegra_car TEGRA124_CLK_USB2>; - }; -}; - -Example board file: - -/ { - clocks { - compatible = "simple-bus"; - #address-cells = <1>; - #size-cells = <0>; - - osc: clock@0 { - compatible = "fixed-clock"; - reg = <0>; - #clock-cells = <0>; - clock-frequency = <112400000>; - }; - - clk_32k: clock@1 { - compatible = "fixed-clock"; - reg = <1>; - #clock-cells = <0>; - clock-frequency = <32768>; - }; - }; - - &tegra_car { - clocks = <&clk_32k> <&osc>; - }; - - clock@60006000 { - emc-timings-3 { - nvidia,ram-code = <3>; - - timing-12750000 { - clock-frequency = <12750000>; - nvidia,parent-clock-frequency = <408000000>; - clocks = <&tegra_car TEGRA124_CLK_PLL_P>; - clock-names = "emc-parent"; - }; - timing-20400000 { - clock-frequency = <20400000>; - nvidia,parent-clock-frequency = <408000000>; - clocks = <&tegra_car TEGRA124_CLK_PLL_P>; - clock-names = "emc-parent"; - }; - }; - }; -}; diff --git a/Documentation/devicetree/bindings/clock/nvidia,tegra124-car.yaml b/Documentation/devicetree/bindings/clock/nvidia,tegra124-car.yaml new file mode 100644 index 000000000000..ec7ab1483652 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/nvidia,tegra124-car.yaml @@ -0,0 +1,115 @@ +# SPDX-License-Identifier: (GPL-2.0+ OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/nvidia,tegra124-car.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NVIDIA Tegra Clock and Reset Controller + +maintainers: + - Jon Hunter + - Thierry Reding + +description: | + The Clock and Reset (CAR) is the HW module responsible for muxing and gating + Tegra's clocks, and setting their rates. It comprises CLKGEN and RSTGEN units. + + CLKGEN provides the registers to program the PLLs. It controls most of + the clock source programming and most of the clock dividers. + + CLKGEN input signals include the external clock for the reference frequency + (12 MHz, 26 MHz) and the external clock for the Real Time Clock (32.768 KHz). + + Outputs from CLKGEN are inputs clock of the h/w blocks in the Tegra system. + + RSTGEN provides the registers needed to control resetting of each block in + the Tegra system. + +properties: + compatible: + const: nvidia,tegra124-car + + reg: + maxItems: 1 + + '#clock-cells': + const: 1 + + "#reset-cells": + const: 1 + + nvidia,external-memory-controller: + $ref: /schemas/types.yaml#/definitions/phandle + description: + phandle of the external memory controller node + +patternProperties: + "^emc-timings-[0-9]+$": + type: object + properties: + nvidia,ram-code: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + value of the RAM_CODE field in the PMC_STRAPPING_OPT_A register that + this timing set is used for + + patternProperties: + "^timing-[0-9]+$": + type: object + properties: + clock-frequency: + description: + external memory clock rate in Hz + minimum: 1000000 + maximum: 1000000000 + + nvidia,parent-clock-frequency: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + rate of parent clock in Hz + minimum: 1000000 + maximum: 1000000000 + + clocks: + items: + - description: parent clock of EMC + + clock-names: + items: + - const: emc-parent + + required: + - clock-frequency + - nvidia,parent-clock-frequency + - clocks + - clock-names + + additionalProperties: false + + additionalProperties: false + +required: + - compatible + - reg + - '#clock-cells' + - "#reset-cells" + +additionalProperties: false + +examples: + - | + #include + + car: clock-controller@60006000 { + compatible = "nvidia,tegra124-car"; + reg = <0x60006000 0x1000>; + #clock-cells = <1>; + #reset-cells = <1>; + }; + + usb-controller@c5004000 { + compatible = "nvidia,tegra20-ehci"; + reg = <0xc5004000 0x4000>; + clocks = <&car TEGRA124_CLK_USB2>; + resets = <&car TEGRA124_CLK_USB2>; + }; diff --git a/Documentation/devicetree/bindings/clock/nvidia,tegra20-car.txt b/Documentation/devicetree/bindings/clock/nvidia,tegra20-car.txt deleted file mode 100644 index 6c5901b503d0..000000000000 --- a/Documentation/devicetree/bindings/clock/nvidia,tegra20-car.txt +++ /dev/null @@ -1,63 +0,0 @@ -NVIDIA Tegra20 Clock And Reset Controller - -This binding uses the common clock binding: -Documentation/devicetree/bindings/clock/clock-bindings.txt - -The CAR (Clock And Reset) Controller on Tegra is the HW module responsible -for muxing and gating Tegra's clocks, and setting their rates. - -Required properties : -- compatible : Should be "nvidia,tegra20-car" -- reg : Should contain CAR registers location and length -- clocks : Should contain phandle and clock specifiers for two clocks: - the 32 KHz "32k_in", and the board-specific oscillator "osc". -- #clock-cells : Should be 1. - In clock consumers, this cell represents the clock ID exposed by the - CAR. The assignments may be found in header file - . -- #reset-cells : Should be 1. - In clock consumers, this cell represents the bit number in the CAR's - array of CLK_RST_CONTROLLER_RST_DEVICES_* registers. - -Example SoC include file: - -/ { - tegra_car: clock { - compatible = "nvidia,tegra20-car"; - reg = <0x60006000 0x1000>; - #clock-cells = <1>; - #reset-cells = <1>; - }; - - usb@c5004000 { - clocks = <&tegra_car TEGRA20_CLK_USB2>; - }; -}; - -Example board file: - -/ { - clocks { - compatible = "simple-bus"; - #address-cells = <1>; - #size-cells = <0>; - - osc: clock@0 { - compatible = "fixed-clock"; - reg = <0>; - #clock-cells = <0>; - clock-frequency = <12000000>; - }; - - clk_32k: clock@1 { - compatible = "fixed-clock"; - reg = <1>; - #clock-cells = <0>; - clock-frequency = <32768>; - }; - }; - - &tegra_car { - clocks = <&clk_32k> <&osc>; - }; -}; diff --git a/Documentation/devicetree/bindings/clock/nvidia,tegra20-car.yaml b/Documentation/devicetree/bindings/clock/nvidia,tegra20-car.yaml new file mode 100644 index 000000000000..459d2a525393 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/nvidia,tegra20-car.yaml @@ -0,0 +1,69 @@ +# SPDX-License-Identifier: (GPL-2.0+ OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/nvidia,tegra20-car.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NVIDIA Tegra Clock and Reset Controller + +maintainers: + - Jon Hunter + - Thierry Reding + +description: | + The Clock and Reset (CAR) is the HW module responsible for muxing and gating + Tegra's clocks, and setting their rates. It comprises CLKGEN and RSTGEN units. + + CLKGEN provides the registers to program the PLLs. It controls most of + the clock source programming and most of the clock dividers. + + CLKGEN input signals include the external clock for the reference frequency + (12 MHz, 26 MHz) and the external clock for the Real Time Clock (32.768 KHz). + + Outputs from CLKGEN are inputs clock of the h/w blocks in the Tegra system. + + RSTGEN provides the registers needed to control resetting of each block in + the Tegra system. + +properties: + compatible: + enum: + - nvidia,tegra20-car + - nvidia,tegra30-car + - nvidia,tegra114-car + - nvidia,tegra210-car + + reg: + maxItems: 1 + + '#clock-cells': + const: 1 + + "#reset-cells": + const: 1 + +required: + - compatible + - reg + - '#clock-cells' + - "#reset-cells" + +additionalProperties: false + +examples: + - | + #include + + car: clock-controller@60006000 { + compatible = "nvidia,tegra20-car"; + reg = <0x60006000 0x1000>; + #clock-cells = <1>; + #reset-cells = <1>; + }; + + usb-controller@c5004000 { + compatible = "nvidia,tegra20-ehci"; + reg = <0xc5004000 0x4000>; + clocks = <&car TEGRA20_CLK_USB2>; + resets = <&car TEGRA20_CLK_USB2>; + }; diff --git a/Documentation/devicetree/bindings/clock/nvidia,tegra210-car.txt b/Documentation/devicetree/bindings/clock/nvidia,tegra210-car.txt deleted file mode 100644 index 26f237f641b7..000000000000 --- a/Documentation/devicetree/bindings/clock/nvidia,tegra210-car.txt +++ /dev/null @@ -1,56 +0,0 @@ -NVIDIA Tegra210 Clock And Reset Controller - -This binding uses the common clock binding: -Documentation/devicetree/bindings/clock/clock-bindings.txt - -The CAR (Clock And Reset) Controller on Tegra is the HW module responsible -for muxing and gating Tegra's clocks, and setting their rates. - -Required properties : -- compatible : Should be "nvidia,tegra210-car" -- reg : Should contain CAR registers location and length -- clocks : Should contain phandle and clock specifiers for two clocks: - the 32 KHz "32k_in". -- #clock-cells : Should be 1. - In clock consumers, this cell represents the clock ID exposed by the - CAR. The assignments may be found in header file - . -- #reset-cells : Should be 1. - In clock consumers, this cell represents the bit number in the CAR's - array of CLK_RST_CONTROLLER_RST_DEVICES_* registers. - -Example SoC include file: - -/ { - tegra_car: clock { - compatible = "nvidia,tegra210-car"; - reg = <0x60006000 0x1000>; - #clock-cells = <1>; - #reset-cells = <1>; - }; - - usb@c5004000 { - clocks = <&tegra_car TEGRA210_CLK_USB2>; - }; -}; - -Example board file: - -/ { - clocks { - compatible = "simple-bus"; - #address-cells = <1>; - #size-cells = <0>; - - clk_32k: clock@1 { - compatible = "fixed-clock"; - reg = <1>; - #clock-cells = <0>; - clock-frequency = <32768>; - }; - }; - - &tegra_car { - clocks = <&clk_32k>; - }; -}; diff --git a/Documentation/devicetree/bindings/clock/nvidia,tegra30-car.txt b/Documentation/devicetree/bindings/clock/nvidia,tegra30-car.txt deleted file mode 100644 index 63618cde12df..000000000000 --- a/Documentation/devicetree/bindings/clock/nvidia,tegra30-car.txt +++ /dev/null @@ -1,63 +0,0 @@ -NVIDIA Tegra30 Clock And Reset Controller - -This binding uses the common clock binding: -Documentation/devicetree/bindings/clock/clock-bindings.txt - -The CAR (Clock And Reset) Controller on Tegra is the HW module responsible -for muxing and gating Tegra's clocks, and setting their rates. - -Required properties : -- compatible : Should be "nvidia,tegra30-car" -- reg : Should contain CAR registers location and length -- clocks : Should contain phandle and clock specifiers for two clocks: - the 32 KHz "32k_in", and the board-specific oscillator "osc". -- #clock-cells : Should be 1. - In clock consumers, this cell represents the clock ID exposed by the - CAR. The assignments may be found in header file - . -- #reset-cells : Should be 1. - In clock consumers, this cell represents the bit number in the CAR's - array of CLK_RST_CONTROLLER_RST_DEVICES_* registers. - -Example SoC include file: - -/ { - tegra_car: clock { - compatible = "nvidia,tegra30-car"; - reg = <0x60006000 0x1000>; - #clock-cells = <1>; - #reset-cells = <1>; - }; - - usb@c5004000 { - clocks = <&tegra_car TEGRA30_CLK_USB2>; - }; -}; - -Example board file: - -/ { - clocks { - compatible = "simple-bus"; - #address-cells = <1>; - #size-cells = <0>; - - osc: clock@0 { - compatible = "fixed-clock"; - reg = <0>; - #clock-cells = <0>; - clock-frequency = <12000000>; - }; - - clk_32k: clock@1 { - compatible = "fixed-clock"; - reg = <1>; - #clock-cells = <0>; - clock-frequency = <32768>; - }; - }; - - &tegra_car { - clocks = <&clk_32k> <&osc>; - }; -}; -- cgit v1.2.3 From 17bf8dfa2ac7a49e09e6d1a29bd3ac881e947386 Mon Sep 17 00:00:00 2001 From: Rajendra Nayak Date: Thu, 29 Apr 2021 11:10:26 +0530 Subject: dt-bindings: arm: qcom: Document google,senor board Document the google,senor board based on sc7280 SoC Acked-by: Rob Herring Reviewed-by: Matthias Kaehlcke Reviewed-by: Douglas Anderson Signed-off-by: Rajendra Nayak Link: https://lore.kernel.org/r/1619674827-26650-1-git-send-email-rnayak@codeaurora.org Signed-off-by: Bjorn Andersson --- Documentation/devicetree/bindings/arm/qcom.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml index 9b27e991bddc..2babb95de354 100644 --- a/Documentation/devicetree/bindings/arm/qcom.yaml +++ b/Documentation/devicetree/bindings/arm/qcom.yaml @@ -178,6 +178,7 @@ properties: - items: - enum: - qcom,sc7280-idp + - google,senor - const: qcom,sc7280 - items: -- cgit v1.2.3 From 193e507067a2fd669c2f78f5c12bd735d0f1ff2c Mon Sep 17 00:00:00 2001 From: Bartosz Dudziak Date: Sun, 2 May 2021 14:20:24 +0200 Subject: dt-bindings: soc: qcom: smd-rpm: Add MSM8226 compatible Add the dt-binding for the rpm on the Qualcomm MSM8226 SoC platform. Acked-by: Rob Herring Signed-off-by: Bartosz Dudziak Link: https://lore.kernel.org/r/20210502122027.9351-2-bartosz.dudziak@snejp.pl Signed-off-by: Bjorn Andersson --- Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.yaml index bcf6a0536d3b..d511f01fcac6 100644 --- a/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.yaml +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.yaml @@ -32,6 +32,7 @@ properties: enum: - qcom,rpm-apq8084 - qcom,rpm-ipq6018 + - qcom,rpm-msm8226 - qcom,rpm-msm8916 - qcom,rpm-msm8974 - qcom,rpm-msm8976 -- cgit v1.2.3 From 54c29086195fd72b6a290ef367e71f73fa657b1f Mon Sep 17 00:00:00 2001 From: Hannes Reinecke Date: Tue, 27 Apr 2021 10:30:20 +0200 Subject: scsi: core: Drop the now obsolete driver_byte definitions The driver_byte field in the result is now unused, so we can drop the definitions. Link: https://lore.kernel.org/r/20210427083046.31620-15-hare@suse.de Reviewed-by: Bart Van Assche Reviewed-by: Christoph Hellwig Signed-off-by: Hannes Reinecke Signed-off-by: Martin K. Petersen --- Documentation/scsi/scsi_mid_low_api.rst | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/scsi/scsi_mid_low_api.rst b/Documentation/scsi/scsi_mid_low_api.rst index 096ffe9cae0e..b99b4e418ba9 100644 --- a/Documentation/scsi/scsi_mid_low_api.rst +++ b/Documentation/scsi/scsi_mid_low_api.rst @@ -1174,8 +1174,7 @@ Members of interest: target device). 'result' is a 32 bit unsigned integer that can be viewed as 4 related bytes. The SCSI status value is in the LSB. See include/scsi/scsi.h status_byte(), - msg_byte(), host_byte() and driver_byte() macros and - related constants. + msg_byte() and host_byte() macros and related constants. sense_buffer - an array (maximum size: SCSI_SENSE_BUFFERSIZE bytes) that should be written when the SCSI status (LSB of 'result') -- cgit v1.2.3 From a7479a8477e61420df43e1e8964986d90764efca Mon Sep 17 00:00:00 2001 From: Hannes Reinecke Date: Tue, 27 Apr 2021 10:30:44 +0200 Subject: scsi: core: Kill message byte Remove last vestiges of SCSI status message bytes. Link: https://lore.kernel.org/r/20210427083046.31620-39-hare@suse.de Reviewed-by: Bart Van Assche Signed-off-by: Hannes Reinecke Signed-off-by: Martin K. Petersen --- Documentation/scsi/scsi_mid_low_api.rst | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/scsi/scsi_mid_low_api.rst b/Documentation/scsi/scsi_mid_low_api.rst index b99b4e418ba9..63ddea2b9640 100644 --- a/Documentation/scsi/scsi_mid_low_api.rst +++ b/Documentation/scsi/scsi_mid_low_api.rst @@ -1172,9 +1172,9 @@ Members of interest: of 0 implies a successfully completed command (and all data (if any) has been transferred to or from the SCSI target device). 'result' is a 32 bit unsigned integer that - can be viewed as 4 related bytes. The SCSI status value is - in the LSB. See include/scsi/scsi.h status_byte(), - msg_byte() and host_byte() macros and related constants. + can be viewed as 2 related bytes. The SCSI status value is + in the LSB. See include/scsi/scsi.h status_byte() and + host_byte() macros and related constants. sense_buffer - an array (maximum size: SCSI_SENSE_BUFFERSIZE bytes) that should be written when the SCSI status (LSB of 'result') -- cgit v1.2.3 From cae5f5151d76635f6b5c08133184c48048346e63 Mon Sep 17 00:00:00 2001 From: Mika Westerberg Date: Thu, 1 Apr 2021 17:34:20 +0300 Subject: thunderbolt: Add USB4 port devices Create devices for each USB4 port. This is needed when we add retimer access when there is no device connected but may be useful for other purposes too following what USB subsystem does. This exports a single attribute "link" that shows the type of the USB4 link (or "none" if there is no cable connected). Signed-off-by: Mika Westerberg Reviewed-by: Greg Kroah-Hartman --- Documentation/ABI/testing/sysfs-bus-thunderbolt | 7 +++++++ 1 file changed, 7 insertions(+) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-bus-thunderbolt b/Documentation/ABI/testing/sysfs-bus-thunderbolt index 05afeee05538..3537ba1ba892 100644 --- a/Documentation/ABI/testing/sysfs-bus-thunderbolt +++ b/Documentation/ABI/testing/sysfs-bus-thunderbolt @@ -290,6 +290,13 @@ Contact: thunderbolt-software@lists.01.org Description: This contains XDomain service specific settings as bitmask. Format: %x +What: /sys/bus/thunderbolt/devices/usb4_portX/link +Date: Sep 2021 +KernelVersion: v5.14 +Contact: Mika Westerberg +Description: Returns the current link mode. Possible values are + "usb4", "tbt" and "none". + What: /sys/bus/thunderbolt/devices/:./device Date: Oct 2020 KernelVersion: v5.9 -- cgit v1.2.3 From 3fb10ea4ce86d4d06622be894099c59872e92c57 Mon Sep 17 00:00:00 2001 From: Rajmohan Mani Date: Thu, 1 Apr 2021 18:42:38 +0300 Subject: thunderbolt: Add support for retimer NVM upgrade when there is no link With help from platform firmware (ACPI) it is possible to power on retimers even when there is no USB4 link (e.g nothing is connected to the USB4 ports). This allows us to bring the USB4 sideband up so that we can access retimers and upgrade their NVM firmware. If the platform has support for this, we expose two additional attributes under USB4 ports: offline and rescan. These can be used to bring the port offline, rescan for the retimers and put the port online again. The retimer NVM upgrade itself works the same way than with cable connected. Signed-off-by: Rajmohan Mani Co-developed-by: Mika Westerberg Signed-off-by: Mika Westerberg Reviewed-by: Greg Kroah-Hartman --- Documentation/ABI/testing/sysfs-bus-thunderbolt | 26 ++++++++++++++++++++++ Documentation/admin-guide/thunderbolt.rst | 29 +++++++++++++++++++++++++ 2 files changed, 55 insertions(+) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-bus-thunderbolt b/Documentation/ABI/testing/sysfs-bus-thunderbolt index 3537ba1ba892..f6743dc33aac 100644 --- a/Documentation/ABI/testing/sysfs-bus-thunderbolt +++ b/Documentation/ABI/testing/sysfs-bus-thunderbolt @@ -297,6 +297,32 @@ Contact: Mika Westerberg Description: Returns the current link mode. Possible values are "usb4", "tbt" and "none". +What: /sys/bus/thunderbolt/devices/usb4_portX/offline +Date: Sep 2021 +KernelVersion: v5.14 +Contact: Rajmohan Mani +Description: Writing 1 to this attribute puts the USB4 port into + offline mode. Only allowed when there is nothing + connected to the port (link attribute returns "none"). + Once the port is in offline mode it does not receive any + hotplug events. This is used to update NVM firmware of + on-board retimers. Writing 0 puts the port back to + online mode. + + This attribute is only visible if the platform supports + powering on retimers when there is no cable connected. + +What: /sys/bus/thunderbolt/devices/usb4_portX/rescan +Date: Sep 2021 +KernelVersion: v5.14 +Contact: Rajmohan Mani +Description: When the USB4 port is in offline mode writing 1 to this + attribute forces rescan of the sideband for on-board + retimers. Each retimer appear under the USB4 port as if + the USB4 link was up. These retimers act in the same way + as if the cable was connected so upgrading their NVM + firmware can be done the usual way. + What: /sys/bus/thunderbolt/devices/:./device Date: Oct 2020 KernelVersion: v5.9 diff --git a/Documentation/admin-guide/thunderbolt.rst b/Documentation/admin-guide/thunderbolt.rst index f18e881373c4..2ed79f41a411 100644 --- a/Documentation/admin-guide/thunderbolt.rst +++ b/Documentation/admin-guide/thunderbolt.rst @@ -256,6 +256,35 @@ Note names of the NVMem devices ``nvm_activeN`` and ``nvm_non_activeN`` depend on the order they are registered in the NVMem subsystem. N in the name is the identifier added by the NVMem subsystem. +Upgrading on-board retimer NVM when there is no cable connected +--------------------------------------------------------------- +If the platform supports, it may be possible to upgrade the retimer NVM +firmware even when there is nothing connected to the USB4 +ports. When this is the case the ``usb4_portX`` devices have two special +attributes: ``offline`` and ``rescan``. The way to upgrade the firmware +is to first put the USB4 port into offline mode:: + + # echo 1 > /sys/bus/thunderbolt/devices/0-0/usb4_port1/offline + +This step makes sure the port does not respond to any hotplug events, +and also ensures the retimers are powered on. The next step is to scan +for the retimers:: + + # echo 1 > /sys/bus/thunderbolt/devices/0-0/usb4_port1/rescan + +This enumerates and adds the on-board retimers. Now retimer NVM can be +upgraded in the same way than with cable connected (see previous +section). However, the retimer is not disconnected as we are offline +mode) so after writing ``1`` to ``nvm_authenticate`` one should wait for +5 or more seconds before running rescan again:: + + # echo 1 > /sys/bus/thunderbolt/devices/0-0/usb4_port1/rescan + +This point if everything went fine, the port can be put back to +functional state again:: + + # echo 0 > /sys/bus/thunderbolt/devices/0-0/usb4_port1/offline + Upgrading NVM when host controller is in safe mode -------------------------------------------------- If the existing NVM is not properly authenticated (or is missing) the -- cgit v1.2.3 From 1cbf680f7687f55ae5a1405556519bc70d66a616 Mon Sep 17 00:00:00 2001 From: Mika Westerberg Date: Mon, 12 Apr 2021 15:25:08 +0300 Subject: thunderbolt: Allow router NVM authenticate separately It may be useful if the actual NVM authentication can be delayed to be run later, for instance when the user logs out. For this reason add a new NVM operation (AUHENTICATE_ONLY) that just triggers the authentication procedure over whatever was written to the NVM storage. This is not supported with Thunderbolt 1-3 devices, though. Signed-off-by: Mika Westerberg Reviewed-by: Greg Kroah-Hartman --- Documentation/ABI/testing/sysfs-bus-thunderbolt | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-bus-thunderbolt b/Documentation/ABI/testing/sysfs-bus-thunderbolt index f6743dc33aac..da580b504c87 100644 --- a/Documentation/ABI/testing/sysfs-bus-thunderbolt +++ b/Documentation/ABI/testing/sysfs-bus-thunderbolt @@ -213,12 +213,15 @@ Description: When new NVM image is written to the non-active NVM restarted with the new NVM firmware. If the image verification fails an error code is returned instead. - This file will accept writing values "1" or "2" + This file will accept writing values "1", "2" or "3". - Writing "1" will flush the image to the storage area and authenticate the image in one action. - Writing "2" will run some basic validation on the image and flush it to the storage area. + - Writing "3" will authenticate the image that is + currently written in the storage area. This is only + supported with USB4 devices. When read holds status of the last authentication operation if an error occurred during the process. This -- cgit v1.2.3 From faa1c615f0bdd4f3ac5288bf2952f49dfeac916c Mon Sep 17 00:00:00 2001 From: Rajmohan Mani Date: Mon, 12 Apr 2021 15:29:16 +0300 Subject: thunderbolt: Add WRITE_ONLY and AUTHENTICATE_ONLY NVM operations for retimers The same way we support these two operations for USB4 routers we can extend the retimer NVM operations to support retimers also. Signed-off-by: Rajmohan Mani Co-developed-by: Mika Westerberg Signed-off-by: Mika Westerberg Reviewed-by: Greg Kroah-Hartman --- Documentation/ABI/testing/sysfs-bus-thunderbolt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-bus-thunderbolt b/Documentation/ABI/testing/sysfs-bus-thunderbolt index da580b504c87..95c21d6c9a84 100644 --- a/Documentation/ABI/testing/sysfs-bus-thunderbolt +++ b/Documentation/ABI/testing/sysfs-bus-thunderbolt @@ -221,7 +221,7 @@ Description: When new NVM image is written to the non-active NVM and flush it to the storage area. - Writing "3" will authenticate the image that is currently written in the storage area. This is only - supported with USB4 devices. + supported with USB4 devices and retimers. When read holds status of the last authentication operation if an error occurred during the process. This -- cgit v1.2.3 From 5f459cb0d67d6df6f74eac253ea10de9e9986812 Mon Sep 17 00:00:00 2001 From: Dmitry Osipenko Date: Tue, 1 Jun 2021 05:31:16 +0300 Subject: dt-bindings: soc: tegra-pmc: Document core power domain All NVIDIA Tegra SoCs have a core power domain where majority of hardware blocks reside. Document the new core power domain properties. Reviewed-by: Rob Herring Reviewed-by: Ulf Hansson Signed-off-by: Dmitry Osipenko Signed-off-by: Thierry Reding --- .../bindings/arm/tegra/nvidia,tegra20-pmc.yaml | 35 ++++++++++++++++++++++ 1 file changed, 35 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.yaml b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.yaml index 43fd2f8927d0..0afec83cc723 100644 --- a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.yaml +++ b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.yaml @@ -301,6 +301,33 @@ patternProperties: additionalProperties: false + core-domain: + type: object + description: | + The vast majority of hardware blocks of Tegra SoC belong to a + Core power domain, which has a dedicated voltage rail that powers + the blocks. + + properties: + operating-points-v2: + description: + Should contain level, voltages and opp-supported-hw property. + The supported-hw is a bitfield indicating SoC speedo or process + ID mask. + + "#power-domain-cells": + const: 0 + + required: + - operating-points-v2 + - "#power-domain-cells" + + additionalProperties: false + + core-supply: + description: + Phandle to voltage regulator connected to the SoC Core power rail. + required: - compatible - reg @@ -325,6 +352,7 @@ examples: tegra_pmc: pmc@7000e400 { compatible = "nvidia,tegra210-pmc"; reg = <0x7000e400 0x400>; + core-supply = <®ulator>; clocks = <&tegra_car TEGRA210_CLK_PCLK>, <&clk32k_in>; clock-names = "pclk", "clk32k_in"; #clock-cells = <1>; @@ -338,17 +366,24 @@ examples: nvidia,core-power-req-active-high; nvidia,sys-clock-req-active-high; + pd_core: core-domain { + operating-points-v2 = <&core_opp_table>; + #power-domain-cells = <0>; + }; + powergates { pd_audio: aud { clocks = <&tegra_car TEGRA210_CLK_APE>, <&tegra_car TEGRA210_CLK_APB2APE>; resets = <&tegra_car 198>; + power-domains = <&pd_core>; #power-domain-cells = <0>; }; pd_xusbss: xusba { clocks = <&tegra_car TEGRA210_CLK_XUSB_SS>; resets = <&tegra_car TEGRA210_CLK_XUSB_SS>; + power-domains = <&pd_core>; #power-domain-cells = <0>; }; }; -- cgit v1.2.3 From 437faaa6cebadf8ff4c2c28d7cb26ed4e34aeb14 Mon Sep 17 00:00:00 2001 From: Chris Morgan Date: Wed, 19 May 2021 15:37:53 -0500 Subject: dt-bindings: Add Rockchip rk817 audio CODEC support Create dt-binding documentation to document rk817 codec. New property name of rockchip,mic-in-differential added to control if the microphone is in differential mode or not. Signed-off-by: Chris Morgan Tested-by: Maciej Matuszczyk Acked-by: Rob Herring Signed-off-by: Lee Jones --- Documentation/devicetree/bindings/mfd/rk808.txt | 188 ++++++++++++++++++++++++ 1 file changed, 188 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mfd/rk808.txt b/Documentation/devicetree/bindings/mfd/rk808.txt index 04df07f6f793..23a17a6663ec 100644 --- a/Documentation/devicetree/bindings/mfd/rk808.txt +++ b/Documentation/devicetree/bindings/mfd/rk808.txt @@ -23,6 +23,7 @@ Optional properties: default output clock name - rockchip,system-power-controller: Telling whether or not this pmic is controlling the system power. +- wakeup-source: Device can be used as a wakeup source. Optional RK805 properties: - vcc1-supply: The input supply for DCDC_REG1 @@ -63,8 +64,18 @@ Optional RK809 properties: - vcc9-supply: The input supply for DCDC_REG5, SWITCH_REG2 Optional RK817 properties: +- clocks: The input clock for the audio codec +- clock-names: The clock name for the codec clock. Should be "mclk". +- #sound-dai-cells: Needed for the interpretation of sound dais. Should be 0. + - vcc8-supply: The input supply for BOOST - vcc9-supply: The input supply for OTG_SWITCH +- codec: The child node for the codec to hold additional properties. + If no additional properties are required for the codec, this + node can be omitted. + +- rockchip,mic-in-differential: Telling if the microphone uses differential + mode. Should be under the codec child node. Optional RK818 properties: - vcc1-supply: The input supply for DCDC_REG1 @@ -275,3 +286,180 @@ Example: }; }; }; + + rk817: pmic@20 { + compatible = "rockchip,rk817"; + reg = <0x20>; + interrupt-parent = <&gpio0>; + interrupts = ; + clock-output-names = "rk808-clkout1", "xin32k"; + clock-names = "mclk"; + clocks = <&cru SCLK_I2S1_OUT>; + pinctrl-names = "default"; + pinctrl-0 = <&pmic_int>, <&i2s1_2ch_mclk>; + wakeup-source; + #clock-cells = <1>; + #sound-dai-cells = <0>; + + vcc1-supply = <&vccsys>; + vcc2-supply = <&vccsys>; + vcc3-supply = <&vccsys>; + vcc4-supply = <&vccsys>; + vcc5-supply = <&vccsys>; + vcc6-supply = <&vccsys>; + vcc7-supply = <&vccsys>; + + regulators { + vdd_logic: DCDC_REG1 { + regulator-name = "vdd_logic"; + regulator-min-microvolt = <950000>; + regulator-max-microvolt = <1150000>; + regulator-ramp-delay = <6001>; + regulator-always-on; + regulator-boot-on; + + regulator-state-mem { + regulator-on-in-suspend; + regulator-suspend-microvolt = <950000>; + }; + }; + + vdd_arm: DCDC_REG2 { + regulator-name = "vdd_arm"; + regulator-min-microvolt = <950000>; + regulator-max-microvolt = <1350000>; + regulator-ramp-delay = <6001>; + regulator-always-on; + regulator-boot-on; + + regulator-state-mem { + regulator-off-in-suspend; + regulator-suspend-microvolt = <950000>; + }; + }; + + vcc_ddr: DCDC_REG3 { + regulator-name = "vcc_ddr"; + regulator-always-on; + regulator-boot-on; + + regulator-state-mem { + regulator-on-in-suspend; + }; + }; + + vcc_3v3: DCDC_REG4 { + regulator-name = "vcc_3v3"; + regulator-min-microvolt = <3300000>; + regulator-max-microvolt = <3300000>; + regulator-always-on; + regulator-boot-on; + + regulator-state-mem { + regulator-off-in-suspend; + regulator-suspend-microvolt = <3300000>; + }; + }; + + vcc_1v8: LDO_REG2 { + regulator-name = "vcc_1v8"; + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <1800000>; + regulator-always-on; + regulator-boot-on; + + regulator-state-mem { + regulator-on-in-suspend; + regulator-suspend-microvolt = <1800000>; + }; + }; + + vdd_1v0: LDO_REG3 { + regulator-name = "vdd_1v0"; + regulator-min-microvolt = <1000000>; + regulator-max-microvolt = <1000000>; + regulator-always-on; + regulator-boot-on; + + regulator-state-mem { + regulator-on-in-suspend; + regulator-suspend-microvolt = <1000000>; + }; + }; + + vcc3v3_pmu: LDO_REG4 { + regulator-name = "vcc3v3_pmu"; + regulator-min-microvolt = <3300000>; + regulator-max-microvolt = <3300000>; + regulator-always-on; + regulator-boot-on; + + regulator-state-mem { + regulator-on-in-suspend; + regulator-suspend-microvolt = <3300000>; + }; + }; + + vccio_sd: LDO_REG5 { + regulator-name = "vccio_sd"; + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <3300000>; + regulator-always-on; + regulator-boot-on; + + regulator-state-mem { + regulator-on-in-suspend; + regulator-suspend-microvolt = <3300000>; + }; + }; + + vcc_sd: LDO_REG6 { + regulator-name = "vcc_sd"; + regulator-min-microvolt = <3300000>; + regulator-max-microvolt = <3300000>; + regulator-boot-on; + + regulator-state-mem { + regulator-on-in-suspend; + regulator-suspend-microvolt = <3300000>; + }; + }; + + vcc_bl: LDO_REG7 { + regulator-name = "vcc_bl"; + regulator-min-microvolt = <3300000>; + regulator-max-microvolt = <3300000>; + + regulator-state-mem { + regulator-off-in-suspend; + regulator-suspend-microvolt = <3300000>; + }; + }; + + vcc_lcd: LDO_REG8 { + regulator-name = "vcc_lcd"; + regulator-min-microvolt = <2800000>; + regulator-max-microvolt = <2800000>; + + regulator-state-mem { + regulator-off-in-suspend; + regulator-suspend-microvolt = <2800000>; + }; + }; + + vcc_cam: LDO_REG9 { + regulator-name = "vcc_cam"; + regulator-min-microvolt = <3000000>; + regulator-max-microvolt = <3000000>; + + regulator-state-mem { + regulator-off-in-suspend; + regulator-suspend-microvolt = <3000000>; + }; + }; + }; + + rk817_codec: codec { + rockchip,mic-in-differential; + }; + }; -- cgit v1.2.3 From a8698707a1835be3abd12a3b28079a80999f8dee Mon Sep 17 00:00:00 2001 From: Christoph Hellwig Date: Tue, 25 May 2021 08:12:56 +0200 Subject: block: move bd_mutex to struct gendisk MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Replace the per-block device bd_mutex with a per-gendisk open_mutex, thus simplifying locking wherever we deal with partitions. Signed-off-by: Christoph Hellwig Reviewed-by: Ming Lei Acked-by: Roger Pau Monné Link: https://lore.kernel.org/r/20210525061301.2242282-4-hch@lst.de Signed-off-by: Jens Axboe --- Documentation/filesystems/locking.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/filesystems/locking.rst b/Documentation/filesystems/locking.rst index 1e894480115b..2183fd8cc350 100644 --- a/Documentation/filesystems/locking.rst +++ b/Documentation/filesystems/locking.rst @@ -480,7 +480,7 @@ prototypes:: locking rules: ======================= =================== -ops bd_mutex +ops open_mutex ======================= =================== open: yes release: yes -- cgit v1.2.3 From ec6aba3d2be1ed75b3f4c894bb64a36d40db1f55 Mon Sep 17 00:00:00 2001 From: Peter Zijlstra Date: Tue, 25 May 2021 09:25:19 +0200 Subject: kprobes: Remove kprobe::fault_handler The reason for kprobe::fault_handler(), as given by their comment: * We come here because instructions in the pre/post * handler caused the page_fault, this could happen * if handler tries to access user space by * copy_from_user(), get_user() etc. Let the * user-specified handler try to fix it first. Is just plain bad. Those other handlers are ran from non-preemptible context and had better use _nofault() functions. Also, there is no upstream usage of this. Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Christoph Hellwig Acked-by: Masami Hiramatsu Link: https://lore.kernel.org/r/20210525073213.561116662@infradead.org --- Documentation/trace/kprobes.rst | 24 +++++------------------- 1 file changed, 5 insertions(+), 19 deletions(-) (limited to 'Documentation') diff --git a/Documentation/trace/kprobes.rst b/Documentation/trace/kprobes.rst index b757b6dfd3d4..998149ce2fd9 100644 --- a/Documentation/trace/kprobes.rst +++ b/Documentation/trace/kprobes.rst @@ -362,14 +362,11 @@ register_kprobe #include int register_kprobe(struct kprobe *kp); -Sets a breakpoint at the address kp->addr. When the breakpoint is -hit, Kprobes calls kp->pre_handler. After the probed instruction -is single-stepped, Kprobe calls kp->post_handler. If a fault -occurs during execution of kp->pre_handler or kp->post_handler, -or during single-stepping of the probed instruction, Kprobes calls -kp->fault_handler. Any or all handlers can be NULL. If kp->flags -is set KPROBE_FLAG_DISABLED, that kp will be registered but disabled, -so, its handlers aren't hit until calling enable_kprobe(kp). +Sets a breakpoint at the address kp->addr. When the breakpoint is hit, Kprobes +calls kp->pre_handler. After the probed instruction is single-stepped, Kprobe +calls kp->post_handler. Any or all handlers can be NULL. If kp->flags is set +KPROBE_FLAG_DISABLED, that kp will be registered but disabled, so, its handlers +aren't hit until calling enable_kprobe(kp). .. note:: @@ -415,17 +412,6 @@ User's post-handler (kp->post_handler):: p and regs are as described for the pre_handler. flags always seems to be zero. -User's fault-handler (kp->fault_handler):: - - #include - #include - int fault_handler(struct kprobe *p, struct pt_regs *regs, int trapnr); - -p and regs are as described for the pre_handler. trapnr is the -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_kretprobe ------------------ -- cgit v1.2.3 From 65c1d05325b71b592688590d85c5ef6b360ca3fe Mon Sep 17 00:00:00 2001 From: Hsin-Hsiung Wang Date: Wed, 26 May 2021 14:52:02 +0800 Subject: dt-bindings: mfd: Add compatible for the MediaTek MT6359 PMIC This adds compatible for the MediaTek MT6359 PMIC. Signed-off-by: Hsin-Hsiung Wang Acked-by: Rob Herring Signed-off-by: Lee Jones --- Documentation/devicetree/bindings/mfd/mt6397.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mfd/mt6397.txt b/Documentation/devicetree/bindings/mfd/mt6397.txt index 2661775a3825..99a84b69a29f 100644 --- a/Documentation/devicetree/bindings/mfd/mt6397.txt +++ b/Documentation/devicetree/bindings/mfd/mt6397.txt @@ -21,6 +21,7 @@ Required properties: compatible: "mediatek,mt6323" for PMIC MT6323 "mediatek,mt6358" for PMIC MT6358 + "mediatek,mt6359" for PMIC MT6359 "mediatek,mt6397" for PMIC MT6397 Optional subnodes: -- cgit v1.2.3 From 8771456635d595707307210d5aa9f8ce41598f94 Mon Sep 17 00:00:00 2001 From: Hsin-Hsiung Wang Date: Wed, 26 May 2021 14:52:03 +0800 Subject: dt-bindings: regulator: Add document for MT6359 regulator add dt-binding document for MediaTek MT6359 PMIC Signed-off-by: Hsin-Hsiung Wang Reviewed-by: Rob Herring Signed-off-by: Lee Jones --- .../bindings/regulator/mt6359-regulator.yaml | 385 +++++++++++++++++++++ 1 file changed, 385 insertions(+) create mode 100644 Documentation/devicetree/bindings/regulator/mt6359-regulator.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/regulator/mt6359-regulator.yaml b/Documentation/devicetree/bindings/regulator/mt6359-regulator.yaml new file mode 100644 index 000000000000..8cc413eb482d --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/mt6359-regulator.yaml @@ -0,0 +1,385 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/regulator/mt6359-regulator.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: MT6359 Regulator from MediaTek Integrated + +maintainers: + - Hsin-Hsiung Wang + +description: | + List of regulators provided by this controller. It is named + according to its regulator type, buck_ and ldo_. + MT6359 regulators node should be sub node of the MT6397 MFD node. + +patternProperties: + "^buck_v(s1|gpu11|modem|pu|core|s2|pa|proc2|proc1|core_sshub)$": + type: object + $ref: "regulator.yaml#" + + properties: + regulator-name: + pattern: "^v(s1|gpu11|modem|pu|core|s2|pa|proc2|proc1|core_sshub)$" + + unevaluatedProperties: false + + "^ldo_v(ibr|rf12|usb|camio|efuse|xo22)$": + type: object + $ref: "regulator.yaml#" + + properties: + regulator-name: + pattern: "^v(ibr|rf12|usb|camio|efuse|xo22)$" + + unevaluatedProperties: false + + "^ldo_v(rfck|emc|a12|a09|ufs|bbck)$": + type: object + $ref: "regulator.yaml#" + + properties: + regulator-name: + pattern: "^v(rfck|emc|a12|a09|ufs|bbck)$" + + unevaluatedProperties: false + + "^ldo_vcn(18|13|33_1_bt|13_1_wifi|33_2_bt|33_2_wifi)$": + type: object + $ref: "regulator.yaml#" + + properties: + regulator-name: + pattern: "^vcn(18|13|33_1_bt|13_1_wifi|33_2_bt|33_2_wifi)$" + + unevaluatedProperties: false + + "^ldo_vsram_(proc2|others|md|proc1|others_sshub)$": + type: object + $ref: "regulator.yaml#" + + properties: + regulator-name: + pattern: "^vsram_(proc2|others|md|proc1|others_sshub)$" + + unevaluatedProperties: false + + "^ldo_v(fe|bif|io)28$": + type: object + $ref: "regulator.yaml#" + + properties: + regulator-name: + pattern: "^v(fe|bif|io)28$" + + unevaluatedProperties: false + + "^ldo_v(aud|io|aux|rf|m)18$": + type: object + $ref: "regulator.yaml#" + + properties: + regulator-name: + pattern: "^v(aud|io|aux|rf|m)18$" + + unevaluatedProperties: false + + "^ldo_vsim[12]$": + type: object + $ref: "regulator.yaml#" + + properties: + regulator-name: + pattern: "^vsim[12]$" + + required: + - regulator-name + + unevaluatedProperties: false + +additionalProperties: false + +examples: + - | + pmic { + regulators { + mt6359_vs1_buck_reg: buck_vs1 { + regulator-name = "vs1"; + regulator-min-microvolt = <800000>; + regulator-max-microvolt = <2200000>; + regulator-enable-ramp-delay = <0>; + regulator-always-on; + }; + mt6359_vgpu11_buck_reg: buck_vgpu11 { + regulator-name = "vgpu11"; + regulator-min-microvolt = <400000>; + regulator-max-microvolt = <1193750>; + regulator-ramp-delay = <5000>; + regulator-enable-ramp-delay = <200>; + regulator-allowed-modes = <0 1 2>; + }; + mt6359_vmodem_buck_reg: buck_vmodem { + regulator-name = "vmodem"; + regulator-min-microvolt = <400000>; + regulator-max-microvolt = <1100000>; + regulator-ramp-delay = <10760>; + regulator-enable-ramp-delay = <200>; + }; + mt6359_vpu_buck_reg: buck_vpu { + regulator-name = "vpu"; + regulator-min-microvolt = <400000>; + regulator-max-microvolt = <1193750>; + regulator-ramp-delay = <5000>; + regulator-enable-ramp-delay = <200>; + regulator-allowed-modes = <0 1 2>; + }; + mt6359_vcore_buck_reg: buck_vcore { + regulator-name = "vcore"; + regulator-min-microvolt = <400000>; + regulator-max-microvolt = <1300000>; + regulator-ramp-delay = <5000>; + regulator-enable-ramp-delay = <200>; + regulator-allowed-modes = <0 1 2>; + }; + mt6359_vs2_buck_reg: buck_vs2 { + regulator-name = "vs2"; + regulator-min-microvolt = <800000>; + regulator-max-microvolt = <1600000>; + regulator-enable-ramp-delay = <0>; + regulator-always-on; + }; + mt6359_vpa_buck_reg: buck_vpa { + regulator-name = "vpa"; + regulator-min-microvolt = <500000>; + regulator-max-microvolt = <3650000>; + regulator-enable-ramp-delay = <300>; + }; + mt6359_vproc2_buck_reg: buck_vproc2 { + regulator-name = "vproc2"; + regulator-min-microvolt = <400000>; + regulator-max-microvolt = <1193750>; + regulator-ramp-delay = <7500>; + regulator-enable-ramp-delay = <200>; + regulator-allowed-modes = <0 1 2>; + }; + mt6359_vproc1_buck_reg: buck_vproc1 { + regulator-name = "vproc1"; + regulator-min-microvolt = <400000>; + regulator-max-microvolt = <1193750>; + regulator-ramp-delay = <7500>; + regulator-enable-ramp-delay = <200>; + regulator-allowed-modes = <0 1 2>; + }; + mt6359_vcore_sshub_buck_reg: buck_vcore_sshub { + regulator-name = "vcore_sshub"; + regulator-min-microvolt = <400000>; + regulator-max-microvolt = <1193750>; + }; + mt6359_vgpu11_sshub_buck_reg: buck_vgpu11_sshub { + regulator-name = "vgpu11_sshub"; + regulator-min-microvolt = <400000>; + regulator-max-microvolt = <1193750>; + }; + mt6359_vaud18_ldo_reg: ldo_vaud18 { + regulator-name = "vaud18"; + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <1800000>; + regulator-enable-ramp-delay = <240>; + }; + mt6359_vsim1_ldo_reg: ldo_vsim1 { + regulator-name = "vsim1"; + regulator-min-microvolt = <1700000>; + regulator-max-microvolt = <3100000>; + }; + mt6359_vibr_ldo_reg: ldo_vibr { + regulator-name = "vibr"; + regulator-min-microvolt = <1200000>; + regulator-max-microvolt = <3300000>; + }; + mt6359_vrf12_ldo_reg: ldo_vrf12 { + regulator-name = "vrf12"; + regulator-min-microvolt = <1100000>; + regulator-max-microvolt = <1300000>; + }; + mt6359_vusb_ldo_reg: ldo_vusb { + regulator-name = "vusb"; + regulator-min-microvolt = <3000000>; + regulator-max-microvolt = <3000000>; + regulator-enable-ramp-delay = <960>; + regulator-always-on; + }; + mt6359_vsram_proc2_ldo_reg: ldo_vsram_proc2 { + regulator-name = "vsram_proc2"; + regulator-min-microvolt = <500000>; + regulator-max-microvolt = <1293750>; + regulator-ramp-delay = <7500>; + regulator-enable-ramp-delay = <240>; + regulator-always-on; + }; + mt6359_vio18_ldo_reg: ldo_vio18 { + regulator-name = "vio18"; + regulator-min-microvolt = <1700000>; + regulator-max-microvolt = <1900000>; + regulator-enable-ramp-delay = <960>; + regulator-always-on; + }; + mt6359_vcamio_ldo_reg: ldo_vcamio { + regulator-name = "vcamio"; + regulator-min-microvolt = <1700000>; + regulator-max-microvolt = <1900000>; + }; + mt6359_vcn18_ldo_reg: ldo_vcn18 { + regulator-name = "vcn18"; + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <1800000>; + regulator-enable-ramp-delay = <240>; + }; + mt6359_vfe28_ldo_reg: ldo_vfe28 { + regulator-name = "vfe28"; + regulator-min-microvolt = <2800000>; + regulator-max-microvolt = <2800000>; + regulator-enable-ramp-delay = <120>; + }; + mt6359_vcn13_ldo_reg: ldo_vcn13 { + regulator-name = "vcn13"; + regulator-min-microvolt = <900000>; + regulator-max-microvolt = <1300000>; + }; + mt6359_vcn33_1_bt_ldo_reg: ldo_vcn33_1_bt { + regulator-name = "vcn33_1_bt"; + regulator-min-microvolt = <2800000>; + regulator-max-microvolt = <3500000>; + }; + mt6359_vcn33_1_wifi_ldo_reg: ldo_vcn33_1_wifi { + regulator-name = "vcn33_1_wifi"; + regulator-min-microvolt = <2800000>; + regulator-max-microvolt = <3500000>; + }; + mt6359_vaux18_ldo_reg: ldo_vaux18 { + regulator-name = "vaux18"; + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <1800000>; + regulator-enable-ramp-delay = <240>; + regulator-always-on; + }; + mt6359_vsram_others_ldo_reg: ldo_vsram_others { + regulator-name = "vsram_others"; + regulator-min-microvolt = <500000>; + regulator-max-microvolt = <1293750>; + regulator-ramp-delay = <5000>; + regulator-enable-ramp-delay = <240>; + }; + mt6359_vefuse_ldo_reg: ldo_vefuse { + regulator-name = "vefuse"; + regulator-min-microvolt = <1700000>; + regulator-max-microvolt = <2000000>; + }; + mt6359_vxo22_ldo_reg: ldo_vxo22 { + regulator-name = "vxo22"; + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <2200000>; + regulator-always-on; + }; + mt6359_vrfck_ldo_reg: ldo_vrfck { + regulator-name = "vrfck"; + regulator-min-microvolt = <1500000>; + regulator-max-microvolt = <1700000>; + }; + mt6359_vrfck_1_ldo_reg: ldo_vrfck_1 { + regulator-name = "vrfck"; + regulator-min-microvolt = <1240000>; + regulator-max-microvolt = <1600000>; + }; + mt6359_vbif28_ldo_reg: ldo_vbif28 { + regulator-name = "vbif28"; + regulator-min-microvolt = <2800000>; + regulator-max-microvolt = <2800000>; + regulator-enable-ramp-delay = <240>; + }; + mt6359_vio28_ldo_reg: ldo_vio28 { + regulator-name = "vio28"; + regulator-min-microvolt = <2800000>; + regulator-max-microvolt = <3300000>; + regulator-always-on; + }; + mt6359_vemc_ldo_reg: ldo_vemc { + regulator-name = "vemc"; + regulator-min-microvolt = <2900000>; + regulator-max-microvolt = <3300000>; + }; + mt6359_vemc_1_ldo_reg: ldo_vemc_1 { + regulator-name = "vemc"; + regulator-min-microvolt = <2500000>; + regulator-max-microvolt = <3300000>; + }; + mt6359_vcn33_2_bt_ldo_reg: ldo_vcn33_2_bt { + regulator-name = "vcn33_2_bt"; + regulator-min-microvolt = <2800000>; + regulator-max-microvolt = <3500000>; + }; + mt6359_vcn33_2_wifi_ldo_reg: ldo_vcn33_2_wifi { + regulator-name = "vcn33_2_wifi"; + regulator-min-microvolt = <2800000>; + regulator-max-microvolt = <3500000>; + }; + mt6359_va12_ldo_reg: ldo_va12 { + regulator-name = "va12"; + regulator-min-microvolt = <1200000>; + regulator-max-microvolt = <1300000>; + regulator-always-on; + }; + mt6359_va09_ldo_reg: ldo_va09 { + regulator-name = "va09"; + regulator-min-microvolt = <800000>; + regulator-max-microvolt = <1200000>; + }; + mt6359_vrf18_ldo_reg: ldo_vrf18 { + regulator-name = "vrf18"; + regulator-min-microvolt = <1700000>; + regulator-max-microvolt = <1810000>; + }; + mt6359_vsram_md_ldo_reg: ldo_vsram_md { + regulator-name = "vsram_md"; + regulator-min-microvolt = <500000>; + regulator-max-microvolt = <1293750>; + regulator-ramp-delay = <10760>; + regulator-enable-ramp-delay = <240>; + }; + mt6359_vufs_ldo_reg: ldo_vufs { + regulator-name = "vufs"; + regulator-min-microvolt = <1700000>; + regulator-max-microvolt = <1900000>; + }; + mt6359_vm18_ldo_reg: ldo_vm18 { + regulator-name = "vm18"; + regulator-min-microvolt = <1700000>; + regulator-max-microvolt = <1900000>; + regulator-always-on; + }; + mt6359_vbbck_ldo_reg: ldo_vbbck { + regulator-name = "vbbck"; + regulator-min-microvolt = <1100000>; + regulator-max-microvolt = <1200000>; + }; + mt6359_vsram_proc1_ldo_reg: ldo_vsram_proc1 { + regulator-name = "vsram_proc1"; + regulator-min-microvolt = <500000>; + regulator-max-microvolt = <1293750>; + regulator-ramp-delay = <7500>; + regulator-enable-ramp-delay = <240>; + regulator-always-on; + }; + mt6359_vsim2_ldo_reg: ldo_vsim2 { + regulator-name = "vsim2"; + regulator-min-microvolt = <1700000>; + regulator-max-microvolt = <3100000>; + }; + mt6359_vsram_others_sshub_ldo: ldo_vsram_others_sshub { + regulator-name = "vsram_others_sshub"; + regulator-min-microvolt = <500000>; + regulator-max-microvolt = <1293750>; + }; + }; + }; +... -- cgit v1.2.3 From bad70abdfac1e27d9aa7cc07b02caad5c06667ba Mon Sep 17 00:00:00 2001 From: Peng Fan Date: Thu, 6 May 2021 12:08:36 +0800 Subject: dt-bindings: remoteproc: imx_rproc: add fsl,auto-boot property Add an optional property "fsl,auto-boot" to indicate remote processor auto boot. Signed-off-by: Peng Fan Acked-by: Rob Herring Link: https://lore.kernel.org/r/1620274123-1461-2-git-send-email-peng.fan@oss.nxp.com Signed-off-by: Bjorn Andersson --- Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml | 6 ++++++ 1 file changed, 6 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml b/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml index 208a628f8d6c..b13bf8d70488 100644 --- a/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml +++ b/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml @@ -49,6 +49,12 @@ properties: minItems: 1 maxItems: 32 + fsl,auto-boot: + $ref: /schemas/types.yaml#/definitions/flag + description: + Indicate whether need to load the default firmware and start the remote + processor automatically. + required: - compatible - clocks -- cgit v1.2.3 From 7a95b19a39c6bc4c107be9f0e8fa6fbee4db777d Mon Sep 17 00:00:00 2001 From: Peng Fan Date: Thu, 6 May 2021 12:08:37 +0800 Subject: dt-bindings: remoteproc: imx_rproc: add i.MX7ULP support Add i.MX7ULP compatible. We use i.MX7ULP dual mode and in which case i.MX7ULP A7 core runs under control of M4 core, M4 core starts by ROM and powers most services used by A7 core, so A7 core has no power to start and stop M4 core. So clocks and syscon are not required. Signed-off-by: Peng Fan Acked-by: Rob Herring Link: https://lore.kernel.org/r/1620274123-1461-3-git-send-email-peng.fan@oss.nxp.com Signed-off-by: Bjorn Andersson --- Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml b/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml index b13bf8d70488..58bc2a23f97b 100644 --- a/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml +++ b/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml @@ -18,6 +18,7 @@ properties: - fsl,imx8mq-cm4 - fsl,imx8mm-cm4 - fsl,imx7d-cm4 + - fsl,imx7ulp-cm4 - fsl,imx6sx-cm4 clocks: @@ -57,8 +58,6 @@ properties: required: - compatible - - clocks - - syscon additionalProperties: false -- cgit v1.2.3 From 5dc9e9d1b7582b0b7cba10f22763bcb7b1d33902 Mon Sep 17 00:00:00 2001 From: Peng Fan Date: Thu, 6 May 2021 12:08:38 +0800 Subject: dt-bindings: remoteproc: imx_rproc: support i.MX8MN/P Add i.MX8MN/P remote processor(Cortex-M7) compatible string Signed-off-by: Peng Fan Acked-by: Rob Herring Link: https://lore.kernel.org/r/1620274123-1461-4-git-send-email-peng.fan@oss.nxp.com Signed-off-by: Bjorn Andersson --- Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml b/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml index 58bc2a23f97b..1dc34cf5a4ea 100644 --- a/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml +++ b/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml @@ -17,6 +17,8 @@ properties: enum: - fsl,imx8mq-cm4 - fsl,imx8mm-cm4 + - fsl,imx8mn-cm7 + - fsl,imx8mp-cm7 - fsl,imx7d-cm4 - fsl,imx7ulp-cm4 - fsl,imx6sx-cm4 -- cgit v1.2.3 From 8e3237989b0d38176a3603422777ac7da6bfab2b Mon Sep 17 00:00:00 2001 From: Wesley Sheng Date: Mon, 31 May 2021 16:12:15 +0800 Subject: Documentation: PCI: Fix typo in pci-error-recovery.rst MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Replace "It" with "If", since it is a conditional statement. Link: https://lore.kernel.org/r/20210531081215.43507-1-wesley.sheng@amd.com Signed-off-by: Wesley Sheng Signed-off-by: Bjorn Helgaas Reviewed-by: Krzysztof Wilczyński --- Documentation/PCI/pci-error-recovery.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/PCI/pci-error-recovery.rst b/Documentation/PCI/pci-error-recovery.rst index 84ceebb08cac..187f43a03200 100644 --- a/Documentation/PCI/pci-error-recovery.rst +++ b/Documentation/PCI/pci-error-recovery.rst @@ -295,7 +295,7 @@ and let the driver restart normal I/O processing. A driver can still return a critical failure for this function if it can't get the device operational after reset. If the platform previously tried a soft reset, it might now try a hard reset (power -cycle) and then call slot_reset() again. It the device still can't +cycle) and then call slot_reset() again. If the device still can't be recovered, there is nothing more that can be done; the platform will typically report a "permanent failure" in such a case. The device will be considered "dead" in this case. -- cgit v1.2.3 From 1434c6a1d32a3a1a77f58a03197b802b1724c740 Mon Sep 17 00:00:00 2001 From: Roberto Sassu Date: Fri, 14 May 2021 17:27:50 +0200 Subject: evm: Deprecate EVM_ALLOW_METADATA_WRITES This patch deprecates the usage of EVM_ALLOW_METADATA_WRITES, as it is no longer necessary. All the issues that prevent the usage of EVM portable signatures just with a public key loaded have been solved. This flag will remain available for a short time to ensure that users are able to use EVM without it. Signed-off-by: Roberto Sassu Signed-off-by: Mimi Zohar --- Documentation/ABI/testing/evm | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/evm b/Documentation/ABI/testing/evm index 2243b72e4110..553fd8a33e56 100644 --- a/Documentation/ABI/testing/evm +++ b/Documentation/ABI/testing/evm @@ -24,7 +24,7 @@ Description: 1 Enable digital signature validation 2 Permit modification of EVM-protected metadata at runtime. Not supported if HMAC validation and - creation is enabled. + creation is enabled (deprecated). 31 Disable further runtime modification of EVM policy === ================================================== @@ -47,7 +47,13 @@ Description: will enable digital signature validation, permit modification of EVM-protected metadata and - disable all further modification of policy + disable all further modification of policy. This option is now + deprecated in favor of:: + + echo 0x80000002 >/evm + + as the outstanding issues that prevent the usage of EVM portable + signatures have been solved. Echoing a value is additive, the new value is added to the existing initialization flags. -- cgit v1.2.3 From 026d7fc92a9d629630779c999fe49ecae93f9d63 Mon Sep 17 00:00:00 2001 From: Roberto Sassu Date: Fri, 14 May 2021 17:27:52 +0200 Subject: ima: Introduce template field evmsig and write to field sig as fallback With the patch to accept EVM portable signatures when the appraise_type=imasig requirement is specified in the policy, appraisal can be successfully done even if the file does not have an IMA signature. However, remote attestation would not see that a different signature type was used, as only IMA signatures can be included in the measurement list. This patch solves the issue by introducing the new template field 'evmsig' to show EVM portable signatures and by including its value in the existing field 'sig' if the IMA signature is not found. Suggested-by: Mimi Zohar Signed-off-by: Roberto Sassu Signed-off-by: Mimi Zohar --- Documentation/security/IMA-templates.rst | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/security/IMA-templates.rst b/Documentation/security/IMA-templates.rst index c5a8432972ef..9f3e86ab028a 100644 --- a/Documentation/security/IMA-templates.rst +++ b/Documentation/security/IMA-templates.rst @@ -70,9 +70,11 @@ descriptors by adding their identifier to the format string prefix is shown only if the hash algorithm is not SHA1 or MD5); - 'd-modsig': the digest of the event without the appended modsig; - 'n-ng': the name of the event, without size limitations; - - 'sig': the file signature; + - 'sig': the file signature, or the EVM portable signature if the file + signature is not found; - 'modsig' the appended file signature; - 'buf': the buffer data that was used to generate the hash without size limitations; + - 'evmsig': the EVM portable signature; Below, there is the list of defined template descriptors: -- cgit v1.2.3 From 7dcfeacc5a9d0c130160b86de23279793a8732c8 Mon Sep 17 00:00:00 2001 From: Roberto Sassu Date: Fri, 28 May 2021 09:38:07 +0200 Subject: ima: Define new template fields iuid and igid This patch defines the new template fields iuid and igid, which include respectively the inode UID and GID. For idmapped mounts, still the original UID and GID are provided. These fields can be used to verify the EVM portable signature, if it was included with the template fields sig or evmsig. Signed-off-by: Roberto Sassu Acked-by: Christian Brauner Signed-off-by: Mimi Zohar --- Documentation/security/IMA-templates.rst | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/security/IMA-templates.rst b/Documentation/security/IMA-templates.rst index 9f3e86ab028a..bf8ce4cf5878 100644 --- a/Documentation/security/IMA-templates.rst +++ b/Documentation/security/IMA-templates.rst @@ -75,6 +75,8 @@ descriptors by adding their identifier to the format string - 'modsig' the appended file signature; - 'buf': the buffer data that was used to generate the hash without size limitations; - 'evmsig': the EVM portable signature; + - 'iuid': the inode UID; + - 'igid': the inode GID; Below, there is the list of defined template descriptors: -- cgit v1.2.3 From f8216f6b957f5657c5f4c97f4b037120c6f236bc Mon Sep 17 00:00:00 2001 From: Roberto Sassu Date: Fri, 28 May 2021 09:38:08 +0200 Subject: ima: Define new template field imode This patch defines the new template field imode, which includes the inode mode. It can be used by a remote verifier to verify the EVM portable signature, if it was included with the template fields sig or evmsig. Signed-off-by: Roberto Sassu Signed-off-by: Mimi Zohar --- Documentation/security/IMA-templates.rst | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/security/IMA-templates.rst b/Documentation/security/IMA-templates.rst index bf8ce4cf5878..65c1ce451d08 100644 --- a/Documentation/security/IMA-templates.rst +++ b/Documentation/security/IMA-templates.rst @@ -77,6 +77,7 @@ descriptors by adding their identifier to the format string - 'evmsig': the EVM portable signature; - 'iuid': the inode UID; - 'igid': the inode GID; + - 'imode': the inode mode; Below, there is the list of defined template descriptors: -- cgit v1.2.3 From 51568befea2aba3c75a5a929f41909c50176ca6e Mon Sep 17 00:00:00 2001 From: Yanteng Si Date: Thu, 27 May 2021 14:43:47 +0800 Subject: docs/zh_CN: add core-api symbol-namespaces.rst translation Translates Documentation/core-api/symbol-namespaces.rst into Chinese. Signed-off-by: Yanteng Si Reviewed-by: Wu XiangCheng Link: https://lore.kernel.org/r/20210527064347.3936694-1-siyanteng@loongson.cn Signed-off-by: Jonathan Corbet --- .../translations/zh_CN/core-api/index.rst | 2 - .../zh_CN/core-api/symbol-namespaces.rst | 142 +++++++++++++++++++++ 2 files changed, 142 insertions(+), 2 deletions(-) create mode 100644 Documentation/translations/zh_CN/core-api/symbol-namespaces.rst (limited to 'Documentation') diff --git a/Documentation/translations/zh_CN/core-api/index.rst b/Documentation/translations/zh_CN/core-api/index.rst index 4b7efb7edb18..93162b04624d 100644 --- a/Documentation/translations/zh_CN/core-api/index.rst +++ b/Documentation/translations/zh_CN/core-api/index.rst @@ -26,8 +26,6 @@ printk-basics printk-formats workqueue - -Todolist: symbol-namespaces 数据结构和低级实用程序 diff --git a/Documentation/translations/zh_CN/core-api/symbol-namespaces.rst b/Documentation/translations/zh_CN/core-api/symbol-namespaces.rst new file mode 100644 index 000000000000..ce05c29c7697 --- /dev/null +++ b/Documentation/translations/zh_CN/core-api/symbol-namespaces.rst @@ -0,0 +1,142 @@ +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/core-api/symbol-namespaces.rst +:Translator: Yanteng Si + +.. _cn_symbol-namespaces.rst: + + +================================= +符号命名空间（Symbol Namespaces） +================================= + +本文档描述了如何使用符号命名空间来构造通过EXPORT_SYMBOL()系列宏导出的内核内符号的导出面。 + +.. 目录 + + === 1 简介 + === 2 如何定义符号命名空间 + --- 2.1 使用EXPORT_SYMBOL宏 + --- 2.2 使用DEFAULT_SYMBOL_NAMESPACE定义 + === 3 如何使用命名空间中导出的符号 + === 4 加载使用命名空间符号的模块 + === 5 自动创建MODULE_IMPORT_NS声明 + +1. 简介 +======= + +符号命名空间已经被引入，作为构造内核内API的导出面的一种手段。它允许子系统维护者将 +他们导出的符号划分进独立的命名空间。这对于文档的编写非常有用（想想SUBSYSTEM_DEBUG +命名空间），也可以限制一组符号在内核其他部分的使用。今后，使用导出到命名空间的符号 +的模块必须导入命名空间。否则，内核将根据其配置，拒绝加载该模块或警告说缺少 +导入。 + +2. 如何定义符号命名空间 +======================= + +符号可以用不同的方法导出到命名空间。所有这些都在改变 EXPORT_SYMBOL 和与之类似的那些宏 +被检测到的方式，以创建 ksymtab 条目。 + +2.1 使用EXPORT_SYMBOL宏 +======================= + +除了允许将内核符号导出到内核符号表的宏EXPORT_SYMBOL()和EXPORT_SYMBOL_GPL()之外， +这些宏的变体还可以将符号导出到某个命名空间：EXPORT_SYMBOL_NS() 和 EXPORT_SYMBOL_NS_GPL()。 +它们需要一个额外的参数：命名空间（the namespace）。请注意，由于宏扩展，该参数需 +要是一个预处理器符号。例如，要把符号 ``usb_stor_suspend`` 导出到命名空间 ``USB_STORAGE``， +请使用:: + + EXPORT_SYMBOL_NS(usb_stor_suspend, USB_STORAGE); + +相应的 ksymtab 条目结构体 ``kernel_symbol`` 将有相应的成员 ``命名空间`` 集。 +导出时未指明命名空间的符号将指向 ``NULL`` 。如果没有定义命名空间，则默认没有。 +``modpost`` 和kernel/module.c分别在构建时或模块加载时使用名称空间。 + +2.2 使用DEFAULT_SYMBOL_NAMESPACE定义 +==================================== + +为一个子系统的所有符号定义命名空间可能会非常冗长，并可能变得难以维护。因此，我 +们提供了一个默认定义（DEFAULT_SYMBOL_NAMESPACE），如果设置了这个定义， 它将成 +为所有没有指定命名空间的 EXPORT_SYMBOL() 和 EXPORT_SYMBOL_GPL() 宏扩展的默认 +定义。 + +有多种方法来指定这个定义，使用哪种方法取决于子系统和维护者的喜好。第一种方法是在 +子系统的 ``Makefile`` 中定义默认命名空间。例如，如果要将usb-common中定义的所有符号导 +出到USB_COMMON命名空间，可以在drivers/usb/common/Makefile中添加这样一行:: + + ccflags-y += -DDEFAULT_SYMBOL_NAMESPACE=USB_COMMON + +这将影响所有 EXPORT_SYMBOL() 和 EXPORT_SYMBOL_GPL() 语句。当这个定义存在时， +用EXPORT_SYMBOL_NS()导出的符号仍然会被导出到作为命名空间参数传递的命名空间中， +因为这个参数优先于默认的符号命名空间。 + +定义默认命名空间的第二个选项是直接在编译单元中作为预处理声明。上面的例子就会变 +成:: + + #undef DEFAULT_SYMBOL_NAMESPACE + #define DEFAULT_SYMBOL_NAMESPACE USB_COMMON + +应置于相关编译单元中任何 EXPORT_SYMBOL 宏之前 + +3. 如何使用命名空间中导出的符号 +=============================== + +为了使用被导出到命名空间的符号，内核模块需要明确地导入这些命名空间。 +否则内核可能会拒绝加载该模块。模块代码需要使用宏MODULE_IMPORT_NS来 +表示它所使用的命名空间的符号。例如，一个使用usb_stor_suspend符号的 +模块，需要使用如下语句导入命名空间USB_STORAGE:: + + MODULE_IMPORT_NS(USB_STORAGE); + +这将在模块中为每个导入的命名空间创建一个 ``modinfo`` 标签。这也顺带 +使得可以用modinfo检查模块已导入的命名空间:: + + $ modinfo drivers/usb/storage/ums-karma.ko + [...] + import_ns: USB_STORAGE + [...] + + +建议将 MODULE_IMPORT_NS() 语句添加到靠近其他模块元数据定义的地方， +如 MODULE_AUTHOR() 或 MODULE_LICENSE() 。关于自动创建缺失的导入 +语句的方法，请参考第5节。 + +4. 加载使用命名空间符号的模块 +============================= + +在模块加载时（比如 ``insmod`` ），内核将检查每个从模块中引用的符号是否可 +用，以及它可能被导出到的名字空间是否被模块导入。内核的默认行为是拒绝 +加载那些没有指明足以导入的模块。此错误会被记录下来，并且加载将以 +EINVAL方式失败。要允许加载不满足这个前提条件的模块，可以使用此配置选项： +设置 MODULE_ALLOW_MISSING_NAMESPACE_IMPORTS=y 将使加载不受影响，但会 +发出警告。 + +5. 自动创建MODULE_IMPORT_NS声明 +=============================== + +缺少命名空间的导入可以在构建时很容易被检测到。事实上，如果一个模块 +使用了一个命名空间的符号而没有导入它，modpost会发出警告。 +MODULE_IMPORT_NS()语句通常会被添加到一个明确的位置（和其他模块元 +数据一起）。为了使模块作者（和子系统维护者）的生活更加轻松，我们提 +供了一个脚本和make目标来修复丢失的导入。修复丢失的导入可以用:: + + $ make nsdeps + +对模块作者来说，以下情况可能很典型:: + + - 编写依赖未导入命名空间的符号的代码 + - ``make`` + - 注意 ``modpost`` 的警告，提醒你有一个丢失的导入。 + - 运行 ``make nsdeps``将导入添加到正确的代码位置。 + +对于引入命名空间的子系统维护者来说，其步骤非常相似。同样，make nsdeps最终将 +为树内模块添加缺失的命名空间导入:: + + - 向命名空间转移或添加符号（例如，使用EXPORT_SYMBOL_NS()）。 + - `make e`（最好是用allmodconfig来覆盖所有的内核模块）。 + - 注意 ``modpost`` 的警告，提醒你有一个丢失的导入。 + - 运行 ``maknsdeps``将导入添加到正确的代码位置。 + +你也可以为外部模块的构建运行nsdeps。典型的用法是:: + + $ make -C M=$PWD nsdeps -- cgit v1.2.3 From cbae918b2c4b6d1c4577d35659196b4f75b5c376 Mon Sep 17 00:00:00 2001 From: Yanteng Si Date: Mon, 31 May 2021 20:41:05 +0800 Subject: docs/zh_CN:add core-api padata translation Translate Documentation/core-api/padata.rst into Chinese. Signed-off-by: Yanteng Si Reviewed-by: Wu XiangCheng Link: https://lore.kernel.org/r/20210531124105.946859-1-siyanteng@loongson.cn Signed-off-by: Jonathan Corbet --- .../translations/zh_CN/core-api/index.rst | 2 +- .../translations/zh_CN/core-api/padata.rst | 158 +++++++++++++++++++++ 2 files changed, 159 insertions(+), 1 deletion(-) create mode 100644 Documentation/translations/zh_CN/core-api/padata.rst (limited to 'Documentation') diff --git a/Documentation/translations/zh_CN/core-api/index.rst b/Documentation/translations/zh_CN/core-api/index.rst index 93162b04624d..a8b2afcbf5bc 100644 --- a/Documentation/translations/zh_CN/core-api/index.rst +++ b/Documentation/translations/zh_CN/core-api/index.rst @@ -65,10 +65,10 @@ Linux如何让一切同时发生。 详情请参阅 irq/index refcount-vs-atomic local_ops + padata Todolist: - padata ../RCU/index 低级硬件管理 diff --git a/Documentation/translations/zh_CN/core-api/padata.rst b/Documentation/translations/zh_CN/core-api/padata.rst new file mode 100644 index 000000000000..c627f8f131f9 --- /dev/null +++ b/Documentation/translations/zh_CN/core-api/padata.rst @@ -0,0 +1,158 @@ +.. SPDX-License-Identifier: GPL-2.0 + +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/core-api/padata.rst +:Translator: Yanteng Si + +.. _cn_core_api_padata.rst: + +================== +padata并行执行机制 +================== + +:日期: 2020年5月 + +Padata是一种机制，内核可以通过此机制将工作分散到多个CPU上并行完成，同时 +可以选择保持它们的顺序。 + +它最初是为IPsec开发的，它需要在不对这些数据包重新排序的其前提下，为大量的数 +据包进行加密和解密。这是目前padata的序列化作业支持的唯一用途。 + +Padata还支持多线程作业，将作业平均分割，同时在线程之间进行负载均衡和协调。 + +执行序列化作业 +============== + +初始化 +------ + +使用padata执行序列化作业的第一步是建立一个padata_instance结构体，以全面 +控制作业的运行方式:: + + #include + + struct padata_instance *padata_alloc(const char *name); + +'name'即标识了这个实例。 + +然后，通过分配一个padata_shell来完成padata的初始化:: + + struct padata_shell *padata_alloc_shell(struct padata_instance *pinst); + +一个padata_shell用于向padata提交一个作业，并允许一系列这样的作业被独立地 +序列化。一个padata_instance可以有一个或多个padata_shell与之相关联，每个 +都允许一系列独立的作业。 + +修改cpumasks +------------ + +用于运行作业的CPU可以通过两种方式改变，通过padata_set_cpumask()编程或通 +过sysfs。前者的定义是:: + + int padata_set_cpumask(struct padata_instance *pinst, int cpumask_type, + cpumask_var_t cpumask); + +这里cpumask_type是PADATA_CPU_PARALLEL（并行）或PADATA_CPU_SERIAL（串行）之一，其中并 +行cpumask描述了哪些处理器将被用来并行执行提交给这个实例的作业，串行cpumask +定义了哪些处理器被允许用作串行化回调处理器。 cpumask指定了要使用的新cpumask。 + +一个实例的cpumasks可能有sysfs文件。例如，pcrypt的文件在 +/sys/kernel/pcrypt/。在一个实例的目录中，有两个文件，parallel_cpumask +和serial_cpumask，任何一个cpumask都可以通过在文件中回显（echo）一个bitmask +来改变，比如说:: + + echo f > /sys/kernel/pcrypt/pencrypt/parallel_cpumask + +读取其中一个文件会显示用户提供的cpumask，它可能与“可用”的cpumask不同。 + +Padata内部维护着两对cpumask，用户提供的cpumask和“可用的”cpumask(每一对由一个 +并行和一个串行cpumask组成)。用户提供的cpumasks在实例分配时默认为所有可能的CPU， +并且可以如上所述进行更改。可用的cpumasks总是用户提供的cpumasks的一个子集，只包 +含用户提供的掩码中的在线CPU；这些是padata实际使用的cpumasks。因此，向padata提 +供一个包含离线CPU的cpumask是合法的。一旦用户提供的cpumask中的一个离线CPU上线， +padata就会使用它。 + +改变CPU掩码的操作代价很高，所以不应频繁更改。 + +运行一个作业 +------------- + +实际上向padata实例提交工作需要创建一个padata_priv结构体，它代表一个作业:: + + struct padata_priv { + /* Other stuff here... */ + void (*parallel)(struct padata_priv *padata); + void (*serial)(struct padata_priv *padata); + }; + +这个结构体几乎肯定会被嵌入到一些针对要做的工作的大结构体中。它的大部分字段对 +padata来说是私有的，但是这个结构在初始化时应该被清零，并且应该提供parallel()和 +serial()函数。在完成工作的过程中，这些函数将被调用，我们马上就会遇到。 + +工作的提交是通过:: + + int padata_do_parallel(struct padata_shell *ps, + struct padata_priv *padata, int *cb_cpu); + +ps和padata结构体必须如上所述进行设置；cb_cpu指向作业完成后用于最终回调的首选CPU； +它必须在当前实例的CPU掩码中（如果不是，cb_cpu指针将被更新为指向实际选择的CPU）。 +padata_do_parallel()的返回值在成功时为0，表示工作正在进行中。-EBUSY意味着有人 +在其他地方正在搞乱实例的CPU掩码，而当cb_cpu不在串行cpumask中、并行或串行cpumasks +中无在线CPU，或实例停止时，则会出现-EINVAL反馈。 + +每个提交给padata_do_parallel()的作业将依次传递给一个CPU上的上述parallel()函数 +的一个调用，所以真正的并行是通过提交多个作业来实现的。parallel()在运行时禁用软 +件中断，因此不能睡眠。parallel()函数把获得的padata_priv结构体指针作为其唯一的参 +数；关于实际要做的工作的信息可能是通过使用container_of()找到封装结构体来获得的。 + +请注意，parallel()没有返回值；padata子系统假定parallel()将从此时开始负责这项工 +作。作业不需要在这次调用中完成，但是，如果parallel()留下了未完成的工作，它应该准 +备在前一个作业完成之前，被以新的作业再次调用 + +序列化作业 +---------- + +当一个作业完成时，parallel()（或任何实际完成该工作的函数）应该通过调用通知padata此 +事:: + + void padata_do_serial(struct padata_priv *padata); + +在未来的某个时刻，padata_do_serial()将触发对padata_priv结构体中serial()函数的调 +用。这个调用将发生在最初要求调用padata_do_parallel()的CPU上；它也是在本地软件中断 +被禁用的情况下运行的。 +请注意，这个调用可能会被推迟一段时间，因为padata代码会努力确保作业按照提交的顺序完 +成。 + +销毁 +---- + +清理一个padata实例时，可以预见的是调用两个free函数，这两个函数对应于分配的逆过程:: + + void padata_free_shell(struct padata_shell *ps); + void padata_free(struct padata_instance *pinst); + +用户有责任确保在调用上述任何一项之前，所有未完成的工作都已完成。 + +运行多线程作业 +============== + +一个多线程作业有一个主线程和零个或多个辅助线程，主线程参与作业，然后等待所有辅助线 +程完成。padata将作业分割成称为chunk的单元，其中chunk是一个线程在一次调用线程函数 +中完成的作业片段。 + +用户必须做三件事来运行一个多线程作业。首先，通过定义一个padata_mt_job结构体来描述 +作业，这在接口部分有解释。这包括一个指向线程函数的指针，padata每次将作业块分配给线 +程时都会调用这个函数。然后，定义线程函数，它接受三个参数： ``start`` 、 ``end`` 和 ``arg`` ， +其中前两个参数限定了线程操作的范围，最后一个是指向作业共享状态的指针，如果有的话。 +准备好共享状态，它通常被分配在主线程的堆栈中。最后，调用padata_do_multithreaded()， +它将在作业完成后返回。 + +接口 +==== + +该API在以下内核代码中: + +include/linux/padata.h + +kernel/padata.c -- cgit v1.2.3 From 0afd4df0d16a5ae894b087562ffef4e5ec43fe24 Mon Sep 17 00:00:00 2001 From: Akira Yokosawa Date: Sun, 30 May 2021 00:19:14 +0900 Subject: docs: pdfdocs: Prevent column squeezing by tabulary Setting a reasonable width to \tymin prevents column squeezing by tabulary. Width of 20em works well in almost all the tables still in the ascii-art format. Excerpt from tabulary package documentation at [1]: To stop very narrow columns being too 'squeezed' by this process any columns that are narrower than \tymin are set to their natural width. [1]: https://mirrors.ctan.org/macros/latex/contrib/tabulary/tabulary.pdf Note: Sphinx has its own default value of \tymin set in sphinxlatextables.sty (Sphinx 4.0.2) and sphinxmulticell.sty (Sphinx 2.4.4) as follows: \setlength{\tymin}{3\fontcharwd\font`0 } , which is not sufficient for kernel-doc. Tested against Sphinx versions 2.4.4 and 4.0.2. Signed-off-by: Akira Yokosawa Link: https://lore.kernel.org/r/277d68fa-c96a-0ccb-6ce0-4d314851d9fe@gmail.com Signed-off-by: Jonathan Corbet --- Documentation/conf.py | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/conf.py b/Documentation/conf.py index 25aa00c707b0..a05225056e08 100644 --- a/Documentation/conf.py +++ b/Documentation/conf.py @@ -353,6 +353,8 @@ latex_elements = { # Additional stuff for the LaTeX preamble. 'preamble': ''' + % Prevent column squeezing of tabulary. + \\setlength{\\tymin}{20em} % Use some font with UTF-8 support with XeLaTeX \\usepackage{fontspec} \\setsansfont{DejaVu Sans} -- cgit v1.2.3 From 6ad1800071e80ade38b6287792a6ad678e6085ed Mon Sep 17 00:00:00 2001 From: Haocheng Xie Date: Mon, 31 May 2021 16:39:05 +0800 Subject: docs: Fix typos in Documentation/trace/ftrace.rst Fix the usage of "a/the" and improve the readability. Signed-off-by: Haocheng Xie Link: https://lore.kernel.org/r/20210531083905.25763-1-xiehaocheng.cn@gmail.com [jc: tweaked wording slightly] Signed-off-by: Jonathan Corbet --- Documentation/trace/ftrace.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/trace/ftrace.rst b/Documentation/trace/ftrace.rst index 62c98e9bbdd9..b88c6b79db3e 100644 --- a/Documentation/trace/ftrace.rst +++ b/Documentation/trace/ftrace.rst @@ -354,8 +354,8 @@ of ftrace. Here is a list of some of the key files: is being directly called by the function. If the count is greater than 1 it most likely will be ftrace_ops_list_func(). - If the callback of the function jumps to a trampoline that is - specific to a the callback and not the standard trampoline, + If the callback of a function jumps to a trampoline that is + specific to the callback and which is not the standard trampoline, its address will be printed as well as the function that the trampoline calls. -- cgit v1.2.3 From 9f3849be6f2f4ae368e61321f135c2734ab6dd8a Mon Sep 17 00:00:00 2001 From: Rob Herring Date: Wed, 26 May 2021 13:48:34 -0500 Subject: dt-bindings: mfd: ti,j721e-system-controller: Fix mux node errors The ti,j721e-system-controller binding does not follow the standard mux controller node name 'mux-controller' and the example is incomplete. Fix these to avoid schema errors before the mux controller binding is converted to schema. Cc: Lee Jones Cc: Kishon Vijay Abraham I Acked-by: Lee Jones Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20210526184839.2937899-2-robh@kernel.org --- .../bindings/mfd/ti,j721e-system-controller.yaml | 19 +++++++++++++------ 1 file changed, 13 insertions(+), 6 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mfd/ti,j721e-system-controller.yaml b/Documentation/devicetree/bindings/mfd/ti,j721e-system-controller.yaml index 19fcf59fd2fe..272832e9f8f2 100644 --- a/Documentation/devicetree/bindings/mfd/ti,j721e-system-controller.yaml +++ b/Documentation/devicetree/bindings/mfd/ti,j721e-system-controller.yaml @@ -43,12 +43,10 @@ properties: patternProperties: # Optional children - "^serdes-ln-ctrl@[0-9a-f]+$": + "^mux-controller@[0-9a-f]+$": type: object - description: | - This is the SERDES lane control mux. It should follow the bindings - specified in - Documentation/devicetree/bindings/mux/reg-mux.txt + description: + This is the SERDES lane control mux. required: - compatible @@ -68,9 +66,18 @@ examples: #size-cells = <1>; ranges; - serdes_ln_ctrl: serdes-ln-ctrl@4080 { + serdes_ln_ctrl: mux-controller@4080 { compatible = "mmio-mux"; reg = <0x00004080 0x50>; + + #mux-control-cells = <1>; + mux-reg-masks = + <0x4080 0x3>, <0x4084 0x3>, /* SERDES0 lane0/1 select */ + <0x4090 0x3>, <0x4094 0x3>, /* SERDES1 lane0/1 select */ + <0x40a0 0x3>, <0x40a4 0x3>, /* SERDES2 lane0/1 select */ + <0x40b0 0x3>, <0x40b4 0x3>, /* SERDES3 lane0/1 select */ + <0x40c0 0x3>, <0x40c4 0x3>, <0x40c8 0x3>, <0x40cc 0x3>; + /* SERDES4 lane0/1/2/3 select */ }; }; ... -- cgit v1.2.3 From f743c41d00bea01bf3e5c79b1ae5dcebca8f8daa Mon Sep 17 00:00:00 2001 From: Rob Herring Date: Wed, 26 May 2021 13:48:35 -0500 Subject: dt-bindings: rtc: nxp,pcf8563: Convert to DT schema Convert the Philips PCF8563/Epson RTC8564 binding to DT schema format. Add 'interrupts' and 'wakeup-source' as this device has an interrupt which was not documented, but in use. Add 'start-year' as well. Cc: Alexandre Belloni Reviewed-by: Laurent Pinchart Acked-by: Alexandre Belloni Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20210526184839.2937899-3-robh@kernel.org --- .../devicetree/bindings/rtc/nxp,pcf8563.yaml | 56 ++++++++++++++++++++++ Documentation/devicetree/bindings/rtc/pcf8563.txt | 29 ----------- 2 files changed, 56 insertions(+), 29 deletions(-) create mode 100644 Documentation/devicetree/bindings/rtc/nxp,pcf8563.yaml delete mode 100644 Documentation/devicetree/bindings/rtc/pcf8563.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/rtc/nxp,pcf8563.yaml b/Documentation/devicetree/bindings/rtc/nxp,pcf8563.yaml new file mode 100644 index 000000000000..a542b6c7ff44 --- /dev/null +++ b/Documentation/devicetree/bindings/rtc/nxp,pcf8563.yaml @@ -0,0 +1,56 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/rtc/nxp,pcf8563.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Philips PCF8563/Epson RTC8564 Real Time Clock + +maintainers: + - Alexandre Belloni + +allOf: + - $ref: rtc.yaml# + +properties: + compatible: + enum: + - epson,rtc8564 + - microcrystal,rv8564 + - nxp,pcf8563 + - nxp,pca8565 + + reg: + maxItems: 1 + + "#clock-cells": + const: 0 + + clock-output-names: + maxItems: 1 + + interrupts: + maxItems: 1 + + start-year: true + wakeup-source: true + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + rtc@51 { + compatible = "nxp,pcf8563"; + reg = <0x51>; + #clock-cells = <0>; + }; + }; +... diff --git a/Documentation/devicetree/bindings/rtc/pcf8563.txt b/Documentation/devicetree/bindings/rtc/pcf8563.txt deleted file mode 100644 index 0a900f7c8977..000000000000 --- a/Documentation/devicetree/bindings/rtc/pcf8563.txt +++ /dev/null @@ -1,29 +0,0 @@ -* Philips PCF8563/Epson RTC8564 Real Time Clock - -Philips PCF8563/Epson RTC8564 Real Time Clock - -Required properties: -- compatible: Should contain "nxp,pcf8563", - "epson,rtc8564" or - "microcrystal,rv8564" or - "nxp,pca8565" -- reg: I2C address for chip. - -Optional property: -- #clock-cells: Should be 0. -- clock-output-names: - overwrite the default clock name "pcf8563-clkout" - -Example: - -pcf8563: pcf8563@51 { - compatible = "nxp,pcf8563"; - reg = <0x51>; - #clock-cells = <0>; -}; - -device { -... - clocks = <&pcf8563>; -... -}; -- cgit v1.2.3 From 9b358af7c8186678677102e8c6cc472e7c00c0c0 Mon Sep 17 00:00:00 2001 From: Rob Herring Date: Wed, 26 May 2021 13:48:36 -0500 Subject: dt-bindings: mux: Convert mux controller bindings to schema Convert the mux controller bindings to DT schema. Cc: Peter Rosin Reviewed-by: Jonathan Cameron Acked-by: Wolfram Sang Acked-by: Peter Rosin Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20210526184839.2937899-4-robh@kernel.org --- .../devicetree/bindings/i2c/i2c-mux-gpmux.txt | 2 +- .../devicetree/bindings/i2c/i2c-mux-pca954x.txt | 2 +- .../bindings/iio/multiplexer/io-channel-mux.txt | 2 +- .../devicetree/bindings/mtd/ti,am654-hbmc.txt | 2 +- .../devicetree/bindings/mux/adi,adg792a.txt | 2 +- .../devicetree/bindings/mux/adi,adgs1408.txt | 2 +- Documentation/devicetree/bindings/mux/gpio-mux.txt | 69 -------- .../devicetree/bindings/mux/gpio-mux.yaml | 92 +++++++++++ .../devicetree/bindings/mux/mux-consumer.yaml | 46 ++++++ .../devicetree/bindings/mux/mux-controller.txt | 157 ------------------ .../devicetree/bindings/mux/mux-controller.yaml | 182 +++++++++++++++++++++ Documentation/devicetree/bindings/mux/reg-mux.txt | 129 --------------- Documentation/devicetree/bindings/mux/reg-mux.yaml | 143 ++++++++++++++++ .../bindings/net/mdio-mux-multiplexer.txt | 2 +- 14 files changed, 470 insertions(+), 362 deletions(-) delete mode 100644 Documentation/devicetree/bindings/mux/gpio-mux.txt create mode 100644 Documentation/devicetree/bindings/mux/gpio-mux.yaml create mode 100644 Documentation/devicetree/bindings/mux/mux-consumer.yaml delete mode 100644 Documentation/devicetree/bindings/mux/mux-controller.txt create mode 100644 Documentation/devicetree/bindings/mux/mux-controller.yaml delete mode 100644 Documentation/devicetree/bindings/mux/reg-mux.txt create mode 100644 Documentation/devicetree/bindings/mux/reg-mux.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/i2c/i2c-mux-gpmux.txt b/Documentation/devicetree/bindings/i2c/i2c-mux-gpmux.txt index 8b444b94e92f..057083a8ba17 100644 --- a/Documentation/devicetree/bindings/i2c/i2c-mux-gpmux.txt +++ b/Documentation/devicetree/bindings/i2c/i2c-mux-gpmux.txt @@ -25,7 +25,7 @@ Required properties: mux. * Standard I2C mux properties. See i2c-mux.txt in this directory. * I2C child bus nodes. See i2c-mux.txt in this directory. The sub-bus number - is also the mux-controller state described in ../mux/mux-controller.txt + is also the mux-controller state described in ../mux/mux-controller.yaml Optional properties: - mux-locked: If present, explicitly allow unrelated I2C transactions on the diff --git a/Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.txt b/Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.txt index 7abda506b828..9f3f3eb67e87 100644 --- a/Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.txt +++ b/Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.txt @@ -26,7 +26,7 @@ Optional Properties: - reset-gpios: Reference to the GPIO connected to the reset input. - idle-state: if present, overrides i2c-mux-idle-disconnect, - Please refer to Documentation/devicetree/bindings/mux/mux-controller.txt + Please refer to Documentation/devicetree/bindings/mux/mux-controller.yaml - i2c-mux-idle-disconnect: Boolean; if defined, forces mux to disconnect all children in idle state. This is necessary for example, if there are several multiplexers on the bus and the devices behind them use same I2C addresses. diff --git a/Documentation/devicetree/bindings/iio/multiplexer/io-channel-mux.txt b/Documentation/devicetree/bindings/iio/multiplexer/io-channel-mux.txt index 89647d714387..d2b3105dba67 100644 --- a/Documentation/devicetree/bindings/iio/multiplexer/io-channel-mux.txt +++ b/Documentation/devicetree/bindings/iio/multiplexer/io-channel-mux.txt @@ -17,7 +17,7 @@ For each non-empty string in the channels property, an io-channel will be created. The number of this io-channel is the same as the index into the list of strings in the channels property, and also matches the mux controller state. The mux controller state is described in -../mux/mux-controller.txt +../mux/mux-controller.yaml Example: mux: mux-controller { diff --git a/Documentation/devicetree/bindings/mtd/ti,am654-hbmc.txt b/Documentation/devicetree/bindings/mtd/ti,am654-hbmc.txt index faa81c2e5da6..ccfd37b8a0ad 100644 --- a/Documentation/devicetree/bindings/mtd/ti,am654-hbmc.txt +++ b/Documentation/devicetree/bindings/mtd/ti,am654-hbmc.txt @@ -13,7 +13,7 @@ Optional properties: - mux-controls : phandle to the multiplexer that controls selection of HBMC vs OSPI inside Flash SubSystem (FSS). Default is OSPI, if property is absent. - See Documentation/devicetree/bindings/mux/reg-mux.txt + See Documentation/devicetree/bindings/mux/reg-mux.yaml for mmio-mux binding details Example: diff --git a/Documentation/devicetree/bindings/mux/adi,adg792a.txt b/Documentation/devicetree/bindings/mux/adi,adg792a.txt index 96b787a69f50..b0e5bf6903d8 100644 --- a/Documentation/devicetree/bindings/mux/adi,adg792a.txt +++ b/Documentation/devicetree/bindings/mux/adi,adg792a.txt @@ -5,7 +5,7 @@ Required properties: - #mux-control-cells : <0> if parallel (the three muxes are bound together with a single mux controller controlling all three muxes), or <1> if not (one mux controller for each mux). -* Standard mux-controller bindings as described in mux-controller.txt +* Standard mux-controller bindings as described in mux-controller.yaml Optional properties for ADG792G: - gpio-controller : if present, #gpio-cells below is required. diff --git a/Documentation/devicetree/bindings/mux/adi,adgs1408.txt b/Documentation/devicetree/bindings/mux/adi,adgs1408.txt index be6947f4d86b..453a38961c13 100644 --- a/Documentation/devicetree/bindings/mux/adi,adgs1408.txt +++ b/Documentation/devicetree/bindings/mux/adi,adgs1408.txt @@ -4,7 +4,7 @@ Required properties: - compatible : Should be one of * "adi,adgs1408" * "adi,adgs1409" -* Standard mux-controller bindings as described in mux-controller.txt +* Standard mux-controller bindings as described in mux-controller.yaml Optional properties for ADGS1408/1409: - gpio-controller : if present, #gpio-cells is required. diff --git a/Documentation/devicetree/bindings/mux/gpio-mux.txt b/Documentation/devicetree/bindings/mux/gpio-mux.txt deleted file mode 100644 index b8f746344d80..000000000000 --- a/Documentation/devicetree/bindings/mux/gpio-mux.txt +++ /dev/null @@ -1,69 +0,0 @@ -GPIO-based multiplexer controller bindings - -Define what GPIO pins are used to control a multiplexer. Or several -multiplexers, if the same pins control more than one multiplexer. - -Required properties: -- compatible : "gpio-mux" -- mux-gpios : list of gpios used to control the multiplexer, least - significant bit first. -- #mux-control-cells : <0> -* Standard mux-controller bindings as decribed in mux-controller.txt - -Optional properties: -- idle-state : if present, the state the mux will have when idle. The - special state MUX_IDLE_AS_IS is the default. - -The multiplexer state is defined as the number represented by the -multiplexer GPIO pins, where the first pin is the least significant -bit. An active pin is a binary 1, an inactive pin is a binary 0. - -Example: - - mux: mux-controller { - compatible = "gpio-mux"; - #mux-control-cells = <0>; - - mux-gpios = <&pioA 0 GPIO_ACTIVE_HIGH>, - <&pioA 1 GPIO_ACTIVE_HIGH>; - }; - - adc-mux { - compatible = "io-channel-mux"; - io-channels = <&adc 0>; - io-channel-names = "parent"; - - mux-controls = <&mux>; - - channels = "sync-1", "in", "out", "sync-2"; - }; - - i2c-mux { - compatible = "i2c-mux"; - i2c-parent = <&i2c1>; - - mux-controls = <&mux>; - - #address-cells = <1>; - #size-cells = <0>; - - i2c@0 { - reg = <0>; - #address-cells = <1>; - #size-cells = <0>; - - ssd1307: oled@3c { - /* ... */ - }; - }; - - i2c@3 { - reg = <3>; - #address-cells = <1>; - #size-cells = <0>; - - pca9555: pca9555@20 { - /* ... */ - }; - }; - }; diff --git a/Documentation/devicetree/bindings/mux/gpio-mux.yaml b/Documentation/devicetree/bindings/mux/gpio-mux.yaml new file mode 100644 index 000000000000..0a7c8d64981a --- /dev/null +++ b/Documentation/devicetree/bindings/mux/gpio-mux.yaml @@ -0,0 +1,92 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mux/gpio-mux.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: GPIO-based multiplexer controller bindings + +maintainers: + - Peter Rosin + +description: |+ + Define what GPIO pins are used to control a multiplexer. Or several + multiplexers, if the same pins control more than one multiplexer. + + The multiplexer state is defined as the number represented by the + multiplexer GPIO pins, where the first pin is the least significant + bit. An active pin is a binary 1, an inactive pin is a binary 0. + +properties: + compatible: + const: gpio-mux + + mux-gpios: + description: + List of gpios used to control the multiplexer, least significant bit first. + + '#mux-control-cells': + const: 0 + + idle-state: + default: -1 + +required: + - compatible + - mux-gpios + - "#mux-control-cells" + +additionalProperties: false + +examples: + - | + #include + + mux: mux-controller { + compatible = "gpio-mux"; + #mux-control-cells = <0>; + + mux-gpios = <&pioA 0 GPIO_ACTIVE_HIGH>, + <&pioA 1 GPIO_ACTIVE_HIGH>; + }; + + adc-mux { + compatible = "io-channel-mux"; + io-channels = <&adc 0>; + io-channel-names = "parent"; + + mux-controls = <&mux>; + + channels = "sync-1", "in", "out", "sync-2"; + }; + + i2c-mux { + compatible = "i2c-mux"; + i2c-parent = <&i2c1>; + + mux-controls = <&mux>; + + #address-cells = <1>; + #size-cells = <0>; + + i2c@0 { + reg = <0>; + #address-cells = <1>; + #size-cells = <0>; + + ssd1307: oled@3c { + reg = <0x3c>; + }; + }; + + i2c@3 { + reg = <3>; + #address-cells = <1>; + #size-cells = <0>; + + pca9555: pca9555@20 { + reg = <0x20>; + }; + }; + }; +... diff --git a/Documentation/devicetree/bindings/mux/mux-consumer.yaml b/Documentation/devicetree/bindings/mux/mux-consumer.yaml new file mode 100644 index 000000000000..7af93298ab5c --- /dev/null +++ b/Documentation/devicetree/bindings/mux/mux-consumer.yaml @@ -0,0 +1,46 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mux/mux-consumer.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Common multiplexer controller consumer bindings + +maintainers: + - Peter Rosin + +description: | + Mux controller consumers should specify a list of mux controllers that they + want to use with a property containing a 'mux-ctrl-list': + + mux-ctrl-list ::= [mux-ctrl-list] + single-mux-ctrl ::= [mux-ctrl-specifier] + mux-ctrl-phandle : phandle to mux controller node + mux-ctrl-specifier : array of #mux-control-cells specifying the + given mux controller (controller specific) + + Mux controller properties should be named "mux-controls". The exact meaning of + each mux controller property must be documented in the device tree binding for + each consumer. An optional property "mux-control-names" may contain a list of + strings to label each of the mux controllers listed in the "mux-controls" + property. + + mux-ctrl-specifier typically encodes the chip-relative mux controller number. + If the mux controller chip only provides a single mux controller, the + mux-ctrl-specifier can typically be left out. + +select: true + +properties: + mux-controls: + $ref: /schemas/types.yaml#/definitions/phandle-array + + mux-control-names: + description: + Devices that use more than a single mux controller can use the + "mux-control-names" property to map the name of the requested mux + controller to an index into the list given by the "mux-controls" property. + +additionalProperties: true + +... diff --git a/Documentation/devicetree/bindings/mux/mux-controller.txt b/Documentation/devicetree/bindings/mux/mux-controller.txt deleted file mode 100644 index 4f47e4bd2fa0..000000000000 --- a/Documentation/devicetree/bindings/mux/mux-controller.txt +++ /dev/null @@ -1,157 +0,0 @@ -Common multiplexer controller bindings -====================================== - -A multiplexer (or mux) controller will have one, or several, consumer devices -that uses the mux controller. Thus, a mux controller can possibly control -several parallel multiplexers. Presumably there will be at least one -multiplexer needed by each consumer, but a single mux controller can of course -control several multiplexers for a single consumer. - -A mux controller provides a number of states to its consumers, and the state -space is a simple zero-based enumeration. I.e. 0-1 for a 2-way multiplexer, -0-7 for an 8-way multiplexer, etc. - - -Consumers ---------- - -Mux controller consumers should specify a list of mux controllers that they -want to use with a property containing a 'mux-ctrl-list': - - mux-ctrl-list ::= [mux-ctrl-list] - single-mux-ctrl ::= [mux-ctrl-specifier] - mux-ctrl-phandle : phandle to mux controller node - mux-ctrl-specifier : array of #mux-control-cells specifying the - given mux controller (controller specific) - -Mux controller properties should be named "mux-controls". The exact meaning of -each mux controller property must be documented in the device tree binding for -each consumer. An optional property "mux-control-names" may contain a list of -strings to label each of the mux controllers listed in the "mux-controls" -property. - -Drivers for devices that use more than a single mux controller can use the -"mux-control-names" property to map the name of the requested mux controller -to an index into the list given by the "mux-controls" property. - -mux-ctrl-specifier typically encodes the chip-relative mux controller number. -If the mux controller chip only provides a single mux controller, the -mux-ctrl-specifier can typically be left out. - -Example: - - /* One consumer of a 2-way mux controller (one GPIO-line) */ - mux: mux-controller { - compatible = "gpio-mux"; - #mux-control-cells = <0>; - - mux-gpios = <&pioA 0 GPIO_ACTIVE_HIGH>; - }; - - adc-mux { - compatible = "io-channel-mux"; - io-channels = <&adc 0>; - io-channel-names = "parent"; - - mux-controls = <&mux>; - mux-control-names = "adc"; - - channels = "sync", "in"; - }; - -Note that in the example above, specifying the "mux-control-names" is redundant -because there is only one mux controller in the list. However, if the driver -for the consumer node in fact asks for a named mux controller, that name is of -course still required. - - /* - * Two consumers (one for an ADC line and one for an i2c bus) of - * parallel 4-way multiplexers controlled by the same two GPIO-lines. - */ - mux: mux-controller { - compatible = "gpio-mux"; - #mux-control-cells = <0>; - - mux-gpios = <&pioA 0 GPIO_ACTIVE_HIGH>, - <&pioA 1 GPIO_ACTIVE_HIGH>; - }; - - adc-mux { - compatible = "io-channel-mux"; - io-channels = <&adc 0>; - io-channel-names = "parent"; - - mux-controls = <&mux>; - - channels = "sync-1", "in", "out", "sync-2"; - }; - - i2c-mux { - compatible = "i2c-mux"; - i2c-parent = <&i2c1>; - - mux-controls = <&mux>; - - #address-cells = <1>; - #size-cells = <0>; - - i2c@0 { - reg = <0>; - #address-cells = <1>; - #size-cells = <0>; - - ssd1307: oled@3c { - /* ... */ - }; - }; - - i2c@3 { - reg = <3>; - #address-cells = <1>; - #size-cells = <0>; - - pca9555: pca9555@20 { - /* ... */ - }; - }; - }; - - -Mux controller nodes --------------------- - -Mux controller nodes must specify the number of cells used for the -specifier using the '#mux-control-cells' property. - -Optionally, mux controller nodes can also specify the state the mux should -have when it is idle. The idle-state property is used for this. If the -idle-state is not present, the mux controller is typically left as is when -it is idle. For multiplexer chips that expose several mux controllers, the -idle-state property is an array with one idle state for each mux controller. - -The special value (-1) may be used to indicate that the mux should be left -as is when it is idle. This is the default, but can still be useful for -mux controller chips with more than one mux controller, particularly when -there is a need to "step past" a mux controller and set some other idle -state for a mux controller with a higher index. - -Some mux controllers have the ability to disconnect the input/output of the -multiplexer. Using this disconnected high-impedance state as the idle state -is indicated with idle state (-2). - -These constants are available in - - #include - -as MUX_IDLE_AS_IS (-1) and MUX_IDLE_DISCONNECT (-2). - -An example mux controller node look like this (the adg972a chip is a triple -4-way multiplexer): - - mux: mux-controller@50 { - compatible = "adi,adg792a"; - reg = <0x50>; - #mux-control-cells = <1>; - - idle-state = ; - }; diff --git a/Documentation/devicetree/bindings/mux/mux-controller.yaml b/Documentation/devicetree/bindings/mux/mux-controller.yaml new file mode 100644 index 000000000000..736a84c3b6a5 --- /dev/null +++ b/Documentation/devicetree/bindings/mux/mux-controller.yaml @@ -0,0 +1,182 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mux/mux-controller.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Common multiplexer controller provider bindings + +maintainers: + - Peter Rosin + +description: | + A multiplexer (or mux) controller will have one, or several, consumer devices + that uses the mux controller. Thus, a mux controller can possibly control + several parallel multiplexers. Presumably there will be at least one + multiplexer needed by each consumer, but a single mux controller can of course + control several multiplexers for a single consumer. + + A mux controller provides a number of states to its consumers, and the state + space is a simple zero-based enumeration. I.e. 0-1 for a 2-way multiplexer, + 0-7 for an 8-way multiplexer, etc. + + + Mux controller nodes + -------------------- + + Mux controller nodes must specify the number of cells used for the + specifier using the '#mux-control-cells' property. + + Optionally, mux controller nodes can also specify the state the mux should + have when it is idle. The idle-state property is used for this. If the + idle-state is not present, the mux controller is typically left as is when + it is idle. For multiplexer chips that expose several mux controllers, the + idle-state property is an array with one idle state for each mux controller. + + The special value (-1) may be used to indicate that the mux should be left + as is when it is idle. This is the default, but can still be useful for + mux controller chips with more than one mux controller, particularly when + there is a need to "step past" a mux controller and set some other idle + state for a mux controller with a higher index. + + Some mux controllers have the ability to disconnect the input/output of the + multiplexer. Using this disconnected high-impedance state as the idle state + is indicated with idle state (-2). + + These constants are available in + + #include + + as MUX_IDLE_AS_IS (-1) and MUX_IDLE_DISCONNECT (-2). + + An example mux controller node look like this (the adg972a chip is a triple + 4-way multiplexer): + + mux: mux-controller@50 { + compatible = "adi,adg792a"; + reg = <0x50>; + #mux-control-cells = <1>; + + idle-state = ; + }; + +select: + anyOf: + - properties: + $nodename: + pattern: '^mux-controller' + - required: + - '#mux-control-cells' + +properties: + $nodename: + pattern: '^mux-controller(@.*|-[0-9a-f]+)?$' + + '#mux-control-cells': + enum: [ 0, 1 ] + + idle-state: + $ref: /schemas/types.yaml#/definitions/int32 + minimum: -2 + + idle-states: + description: | + Mux controller nodes can specify the state the mux should have when it is + idle. If the idle-state is not present, the mux controller is typically + left as is when it is idle. For multiplexer chips that expose several mux + controllers, the idle-state property is an array with one idle state for + each mux controller. + + The special value (-1) may be used to indicate that the mux should be left + as is when it is idle. This is the default, but can still be useful for + mux controller chips with more than one mux controller, particularly when + there is a need to "step past" a mux controller and set some other idle + state for a mux controller with a higher index. + + Some mux controllers have the ability to disconnect the input/output of the + multiplexer. Using this disconnected high-impedance state as the idle state + is indicated with idle state (-2). + $ref: /schemas/types.yaml#/definitions/int32-array + items: + minimum: -2 + +additionalProperties: true + +examples: + - | + #include + + /* One consumer of a 2-way mux controller (one GPIO-line) */ + mux: mux-controller { + compatible = "gpio-mux"; + #mux-control-cells = <0>; + + mux-gpios = <&pioA 0 GPIO_ACTIVE_HIGH>; + }; + + adc-mux { + compatible = "io-channel-mux"; + io-channels = <&adc 0>; + io-channel-names = "parent"; + + mux-controls = <&mux>; + mux-control-names = "adc"; + + channels = "sync", "in"; + }; + + - | + #include + + /* + * Two consumers (one for an ADC line and one for an i2c bus) of + * parallel 4-way multiplexers controlled by the same two GPIO-lines. + */ + mux2: mux-controller { + compatible = "gpio-mux"; + #mux-control-cells = <0>; + + mux-gpios = <&pioA 0 GPIO_ACTIVE_HIGH>, + <&pioA 1 GPIO_ACTIVE_HIGH>; + }; + + adc-mux { + compatible = "io-channel-mux"; + io-channels = <&adc 0>; + io-channel-names = "parent"; + + mux-controls = <&mux2>; + + channels = "sync-1", "in", "out", "sync-2"; + }; + + i2c-mux { + compatible = "i2c-mux"; + i2c-parent = <&i2c1>; + + mux-controls = <&mux2>; + + #address-cells = <1>; + #size-cells = <0>; + + i2c@0 { + reg = <0>; + #address-cells = <1>; + #size-cells = <0>; + + ssd1307: oled@3c { + reg = <0x3c>; + }; + }; + + i2c@3 { + reg = <3>; + #address-cells = <1>; + #size-cells = <0>; + + pca9555: pca9555@20 { + reg = <0x20>; + }; + }; + }; +... diff --git a/Documentation/devicetree/bindings/mux/reg-mux.txt b/Documentation/devicetree/bindings/mux/reg-mux.txt deleted file mode 100644 index 4afd7ba73d60..000000000000 --- a/Documentation/devicetree/bindings/mux/reg-mux.txt +++ /dev/null @@ -1,129 +0,0 @@ -Generic register bitfield-based multiplexer controller bindings - -Define register bitfields to be used to control multiplexers. The parent -device tree node must be a device node to provide register r/w access. - -Required properties: -- compatible : should be one of - "reg-mux" : if parent device of mux controller is not syscon device - "mmio-mux" : if parent device of mux controller is syscon device -- #mux-control-cells : <1> -- mux-reg-masks : an array of register offset and pre-shifted bitfield mask - pairs, each describing a single mux control. -* Standard mux-controller bindings as decribed in mux-controller.txt - -Optional properties: -- idle-states : if present, the state the muxes will have when idle. The - special state MUX_IDLE_AS_IS is the default. - -The multiplexer state of each multiplexer is defined as the value of the -bitfield described by the corresponding register offset and bitfield mask -pair in the mux-reg-masks array. - -Example 1: -The parent device of mux controller is not a syscon device. - -&i2c0 { - fpga@66 { // fpga connected to i2c - compatible = "fsl,lx2160aqds-fpga", "fsl,fpga-qixis-i2c", - "simple-mfd"; - reg = <0x66>; - - mux: mux-controller { - compatible = "reg-mux"; - #mux-control-cells = <1>; - mux-reg-masks = <0x54 0xf8>, /* 0: reg 0x54, bits 7:3 */ - <0x54 0x07>; /* 1: reg 0x54, bits 2:0 */ - }; - }; -}; - -mdio-mux-1 { - compatible = "mdio-mux-multiplexer"; - mux-controls = <&mux 0>; - mdio-parent-bus = <&emdio1>; - #address-cells = <1>; - #size-cells = <0>; - - mdio@0 { - reg = <0x0>; - #address-cells = <1>; - #size-cells = <0>; - }; - - mdio@8 { - reg = <0x8>; - #address-cells = <1>; - #size-cells = <0>; - }; - - .. - .. -}; - -mdio-mux-2 { - compatible = "mdio-mux-multiplexer"; - mux-controls = <&mux 1>; - mdio-parent-bus = <&emdio2>; - #address-cells = <1>; - #size-cells = <0>; - - mdio@0 { - reg = <0x0>; - #address-cells = <1>; - #size-cells = <0>; - }; - - mdio@1 { - reg = <0x1>; - #address-cells = <1>; - #size-cells = <0>; - }; - - .. - .. -}; - -Example 2: -The parent device of mux controller is syscon device. - -syscon { - compatible = "syscon"; - - mux: mux-controller { - compatible = "mmio-mux"; - #mux-control-cells = <1>; - - mux-reg-masks = <0x3 0x30>, /* 0: reg 0x3, bits 5:4 */ - <0x3 0x40>, /* 1: reg 0x3, bit 6 */ - idle-states = , <0>; - }; -}; - -video-mux { - compatible = "video-mux"; - mux-controls = <&mux 0>; - #address-cells = <1>; - #size-cells = <0>; - - ports { - /* inputs 0..3 */ - port@0 { - reg = <0>; - }; - port@1 { - reg = <1>; - }; - port@2 { - reg = <2>; - }; - port@3 { - reg = <3>; - }; - - /* output */ - port@4 { - reg = <4>; - }; - }; -}; diff --git a/Documentation/devicetree/bindings/mux/reg-mux.yaml b/Documentation/devicetree/bindings/mux/reg-mux.yaml new file mode 100644 index 000000000000..60d5746eb39d --- /dev/null +++ b/Documentation/devicetree/bindings/mux/reg-mux.yaml @@ -0,0 +1,143 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mux/reg-mux.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Generic register bitfield-based multiplexer controller bindings + +maintainers: + - Peter Rosin + +description: |+ + Define register bitfields to be used to control multiplexers. The parent + device tree node must be a device node to provide register r/w access. + +properties: + compatible: + enum: + - reg-mux # parent device of mux controller is not syscon device + - mmio-mux # parent device of mux controller is syscon device + + reg: true + + '#mux-control-cells': + const: 1 + + mux-reg-masks: + description: an array of register offset and pre-shifted bitfield mask + pairs, each describing a single mux control. + + idle-states: true + +required: + - compatible + - mux-reg-masks + - '#mux-control-cells' + +additionalProperties: false + +examples: + - | + /* The parent device of mux controller is not a syscon device. */ + + #include + + mux-controller { + compatible = "reg-mux"; + #mux-control-cells = <1>; + mux-reg-masks = + <0x54 0xf8>, /* 0: reg 0x54, bits 7:3 */ + <0x54 0x07>; /* 1: reg 0x54, bits 2:0 */ + }; + + mdio-mux-1 { + compatible = "mdio-mux-multiplexer"; + mux-controls = <&mux1 0>; + mdio-parent-bus = <&emdio1>; + #address-cells = <1>; + #size-cells = <0>; + + mdio@0 { + reg = <0x0>; + #address-cells = <1>; + #size-cells = <0>; + }; + + mdio@8 { + reg = <0x8>; + #address-cells = <1>; + #size-cells = <0>; + }; + }; + + mdio-mux-2 { + compatible = "mdio-mux-multiplexer"; + mux-controls = <&mux1 1>; + mdio-parent-bus = <&emdio2>; + #address-cells = <1>; + #size-cells = <0>; + + mdio@0 { + reg = <0x0>; + #address-cells = <1>; + #size-cells = <0>; + }; + + mdio@1 { + reg = <0x1>; + #address-cells = <1>; + #size-cells = <0>; + }; + }; + + - | + /* The parent device of mux controller is syscon device. */ + + #include + syscon@1000 { + compatible = "fsl,imx7d-iomuxc-gpr", "fsl,imx6q-iomuxc-gpr", "syscon", "simple-mfd"; + reg = <0x1000 0x100>; + + mux2: mux-controller { + compatible = "mmio-mux"; + #mux-control-cells = <1>; + + mux-reg-masks = + <0x3 0x30>, /* 0: reg 0x3, bits 5:4 */ + <0x3 0x40>; /* 1: reg 0x3, bit 6 */ + idle-states = , <0>; + }; + }; + + video-mux { + compatible = "video-mux"; + mux-controls = <&mux2 0>; + #address-cells = <1>; + #size-cells = <0>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + /* inputs 0..3 */ + port@0 { + reg = <0>; + }; + port@1 { + reg = <1>; + }; + port@2 { + reg = <2>; + }; + port@3 { + reg = <3>; + }; + + /* output */ + port@4 { + reg = <4>; + }; + }; + }; +... diff --git a/Documentation/devicetree/bindings/net/mdio-mux-multiplexer.txt b/Documentation/devicetree/bindings/net/mdio-mux-multiplexer.txt index 534e38058fe0..87fd0b4f654f 100644 --- a/Documentation/devicetree/bindings/net/mdio-mux-multiplexer.txt +++ b/Documentation/devicetree/bindings/net/mdio-mux-multiplexer.txt @@ -14,7 +14,7 @@ each child node of mdio bus multiplexer consumer device represent a mdio bus. for more information please refer -Documentation/devicetree/bindings/mux/mux-controller.txt +Documentation/devicetree/bindings/mux/mux-controller.yaml and Documentation/devicetree/bindings/net/mdio-mux.txt Example: -- cgit v1.2.3 From a404a6367b0e74dee3125fa05811274565a34343 Mon Sep 17 00:00:00 2001 From: Rob Herring Date: Wed, 26 May 2021 13:48:37 -0500 Subject: dt-bindings: i2c: Convert i2c-mux bindings to DT schema As some of the example I2C devices don't have schemas yet, change them to ones that do. Cc: Peter Rosin Acked-by: Wolfram Sang Acked-by: Peter Rosin Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20210526184839.2937899-5-robh@kernel.org --- .../devicetree/bindings/i2c/i2c-demux-pinctrl.txt | 2 +- .../devicetree/bindings/i2c/i2c-mux-gpio.txt | 4 +- .../devicetree/bindings/i2c/i2c-mux-gpmux.txt | 99 ---------------- .../devicetree/bindings/i2c/i2c-mux-gpmux.yaml | 124 +++++++++++++++++++++ .../devicetree/bindings/i2c/i2c-mux-ltc4306.txt | 4 +- .../devicetree/bindings/i2c/i2c-mux-pinctrl.txt | 4 +- .../devicetree/bindings/i2c/i2c-mux-reg.txt | 4 +- Documentation/devicetree/bindings/i2c/i2c-mux.txt | 73 ------------ Documentation/devicetree/bindings/i2c/i2c-mux.yaml | 87 +++++++++++++++ 9 files changed, 220 insertions(+), 181 deletions(-) delete mode 100644 Documentation/devicetree/bindings/i2c/i2c-mux-gpmux.txt create mode 100644 Documentation/devicetree/bindings/i2c/i2c-mux-gpmux.yaml delete mode 100644 Documentation/devicetree/bindings/i2c/i2c-mux.txt create mode 100644 Documentation/devicetree/bindings/i2c/i2c-mux.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/i2c/i2c-demux-pinctrl.txt b/Documentation/devicetree/bindings/i2c/i2c-demux-pinctrl.txt index 81b5d55086fa..86b2e433a969 100644 --- a/Documentation/devicetree/bindings/i2c/i2c-demux-pinctrl.txt +++ b/Documentation/devicetree/bindings/i2c/i2c-demux-pinctrl.txt @@ -27,7 +27,7 @@ Required properties: - i2c-bus-name: The name of this bus. Also needed as pinctrl-name for the I2C parents. -Furthermore, I2C mux properties and child nodes. See i2c-mux.txt in this +Furthermore, I2C mux properties and child nodes. See i2c-mux.yaml in this directory. Example: diff --git a/Documentation/devicetree/bindings/i2c/i2c-mux-gpio.txt b/Documentation/devicetree/bindings/i2c/i2c-mux-gpio.txt index 21da3ecbb370..e00d2b9e957a 100644 --- a/Documentation/devicetree/bindings/i2c/i2c-mux-gpio.txt +++ b/Documentation/devicetree/bindings/i2c/i2c-mux-gpio.txt @@ -22,8 +22,8 @@ Required properties: - i2c-parent: The phandle of the I2C bus that this multiplexer's master-side port is connected to. - mux-gpios: list of gpios used to control the muxer -* Standard I2C mux properties. See i2c-mux.txt in this directory. -* I2C child bus nodes. See i2c-mux.txt in this directory. +* Standard I2C mux properties. See i2c-mux.yaml in this directory. +* I2C child bus nodes. See i2c-mux.yaml in this directory. Optional properties: - idle-state: value to set the muxer to when idle. When no value is diff --git a/Documentation/devicetree/bindings/i2c/i2c-mux-gpmux.txt b/Documentation/devicetree/bindings/i2c/i2c-mux-gpmux.txt deleted file mode 100644 index 057083a8ba17..000000000000 --- a/Documentation/devicetree/bindings/i2c/i2c-mux-gpmux.txt +++ /dev/null @@ -1,99 +0,0 @@ -General Purpose I2C Bus Mux - -This binding describes an I2C bus multiplexer that uses a mux controller -from the mux subsystem to route the I2C signals. - - .-----. .-----. - | dev | | dev | - .------------. '-----' '-----' - | SoC | | | - | | .--------+--------' - | .------. | .------+ child bus A, on MUX value set to 0 - | | I2C |-|--| Mux | - | '------' | '--+---+ child bus B, on MUX value set to 1 - | .------. | | '----------+--------+--------. - | | MUX- | | | | | | - | | Ctrl |-|-----+ .-----. .-----. .-----. - | '------' | | dev | | dev | | dev | - '------------' '-----' '-----' '-----' - -Required properties: -- compatible: i2c-mux -- i2c-parent: The phandle of the I2C bus that this multiplexer's master-side - port is connected to. -- mux-controls: The phandle of the mux controller to use for operating the - mux. -* Standard I2C mux properties. See i2c-mux.txt in this directory. -* I2C child bus nodes. See i2c-mux.txt in this directory. The sub-bus number - is also the mux-controller state described in ../mux/mux-controller.yaml - -Optional properties: -- mux-locked: If present, explicitly allow unrelated I2C transactions on the - parent I2C adapter at these times: - + during setup of the multiplexer - + between setup of the multiplexer and the child bus I2C transaction - + between the child bus I2C transaction and releasing of the multiplexer - + during releasing of the multiplexer - However, I2C transactions to devices behind all I2C multiplexers connected - to the same parent adapter that this multiplexer is connected to are blocked - for the full duration of the complete multiplexed I2C transaction (i.e. - including the times covered by the above list). - If mux-locked is not present, the multiplexer is assumed to be parent-locked. - This means that no unrelated I2C transactions are allowed on the parent I2C - adapter for the complete multiplexed I2C transaction. - The properties of mux-locked and parent-locked multiplexers are discussed - in more detail in Documentation/i2c/i2c-topology.rst. - -For each i2c child node, an I2C child bus will be created. They will -be numbered based on their order in the device tree. - -Whenever an access is made to a device on a child bus, the value set -in the relevant node's reg property will be set as the state in the -mux controller. - -Example: - mux: mux-controller { - compatible = "gpio-mux"; - #mux-control-cells = <0>; - - mux-gpios = <&pioA 0 GPIO_ACTIVE_HIGH>, - <&pioA 1 GPIO_ACTIVE_HIGH>; - }; - - i2c-mux { - compatible = "i2c-mux"; - mux-locked; - i2c-parent = <&i2c1>; - - mux-controls = <&mux>; - - #address-cells = <1>; - #size-cells = <0>; - - i2c@1 { - reg = <1>; - #address-cells = <1>; - #size-cells = <0>; - - ssd1307: oled@3c { - compatible = "solomon,ssd1307fb-i2c"; - reg = <0x3c>; - pwms = <&pwm 4 3000>; - reset-gpios = <&gpio2 7 1>; - reset-active-low; - }; - }; - - i2c@3 { - reg = <3>; - #address-cells = <1>; - #size-cells = <0>; - - pca9555: pca9555@20 { - compatible = "nxp,pca9555"; - gpio-controller; - #gpio-cells = <2>; - reg = <0x20>; - }; - }; - }; diff --git a/Documentation/devicetree/bindings/i2c/i2c-mux-gpmux.yaml b/Documentation/devicetree/bindings/i2c/i2c-mux-gpmux.yaml new file mode 100644 index 000000000000..9b0603a72f40 --- /dev/null +++ b/Documentation/devicetree/bindings/i2c/i2c-mux-gpmux.yaml @@ -0,0 +1,124 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/i2c/i2c-mux-gpmux.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: General Purpose I2C Bus Mux + +maintainers: + - Peter Rosin + +description: |+ + This binding describes an I2C bus multiplexer that uses a mux controller + from the mux subsystem to route the I2C signals. + + .-----. .-----. + | dev | | dev | + .------------. '-----' '-----' + | SoC | | | + | | .--------+--------' + | .------. | .------+ child bus A, on MUX value set to 0 + | | I2C |-|--| Mux | + | '------' | '--+---+ child bus B, on MUX value set to 1 + | .------. | | '----------+--------+--------. + | | MUX- | | | | | | + | | Ctrl |-|-----+ .-----. .-----. .-----. + | '------' | | dev | | dev | | dev | + '------------' '-----' '-----' '-----' + + + +allOf: + - $ref: /schemas/i2c/i2c-mux.yaml# + +properties: + compatible: + const: i2c-mux + + i2c-parent: + $ref: /schemas/types.yaml#/definitions/phandle + description: + The phandle of the I2C bus that this multiplexer's master-side port is + connected to. + + mux-controls: + maxItems: 1 + description: + The mux-controller states are the I2C sub-bus numbers. + + mux-locked: + type: boolean + description: | + Explicitly allow unrelated I2C transactions on the parent I2C adapter at + these times: + - during setup of the multiplexer + - between setup of the multiplexer and the child bus I2C transaction + - between the child bus I2C transaction and releasing of the multiplexer + - during releasing of the multiplexer + + However, I2C transactions to devices behind all I2C multiplexers connected + to the same parent adapter that this multiplexer is connected to are blocked + for the full duration of the complete multiplexed I2C transaction (i.e. + including the times covered by the above list). + If mux-locked is not present, the multiplexer is assumed to be parent-locked. + This means that no unrelated I2C transactions are allowed on the parent I2C + adapter for the complete multiplexed I2C transaction. + The properties of mux-locked and parent-locked multiplexers are discussed + in more detail in Documentation/i2c/i2c-topology.rst. + +required: + - compatible + - i2c-parent + - mux-controls + +unevaluatedProperties: false + +examples: + - | + #include + mux: mux-controller { + compatible = "gpio-mux"; + #mux-control-cells = <0>; + + mux-gpios = <&pioA 0 GPIO_ACTIVE_HIGH>, + <&pioA 1 GPIO_ACTIVE_HIGH>; + }; + + i2c-mux { + compatible = "i2c-mux"; + mux-locked; + i2c-parent = <&i2c1>; + + mux-controls = <&mux>; + + #address-cells = <1>; + #size-cells = <0>; + + i2c@1 { + reg = <1>; + #address-cells = <1>; + #size-cells = <0>; + + gpio@20 { + compatible = "nxp,pca9555"; + gpio-controller; + #gpio-cells = <2>; + reg = <0x20>; + }; + }; + + i2c@3 { + reg = <3>; + #address-cells = <1>; + #size-cells = <0>; + + gpio@20 { + compatible = "nxp,pca9555"; + gpio-controller; + #gpio-cells = <2>; + reg = <0x20>; + }; + }; + }; +... diff --git a/Documentation/devicetree/bindings/i2c/i2c-mux-ltc4306.txt b/Documentation/devicetree/bindings/i2c/i2c-mux-ltc4306.txt index 8b1e49cdce3f..29c4550c9782 100644 --- a/Documentation/devicetree/bindings/i2c/i2c-mux-ltc4306.txt +++ b/Documentation/devicetree/bindings/i2c/i2c-mux-ltc4306.txt @@ -8,8 +8,8 @@ Required Properties: The following required properties are defined externally: - - Standard I2C mux properties. See i2c-mux.txt in this directory. - - I2C child bus nodes. See i2c-mux.txt in this directory. + - Standard I2C mux properties. See i2c-mux.yaml in this directory. + - I2C child bus nodes. See i2c-mux.yaml in this directory. Optional Properties: diff --git a/Documentation/devicetree/bindings/i2c/i2c-mux-pinctrl.txt b/Documentation/devicetree/bindings/i2c/i2c-mux-pinctrl.txt index 33119a98e144..997a287ed3f6 100644 --- a/Documentation/devicetree/bindings/i2c/i2c-mux-pinctrl.txt +++ b/Documentation/devicetree/bindings/i2c/i2c-mux-pinctrl.txt @@ -28,9 +28,9 @@ Also required are: * Standard pinctrl properties that specify the pin mux state for each child bus. See ../pinctrl/pinctrl-bindings.txt. -* Standard I2C mux properties. See i2c-mux.txt in this directory. +* Standard I2C mux properties. See i2c-mux.yaml in this directory. -* I2C child bus nodes. See i2c-mux.txt in this directory. +* I2C child bus nodes. See i2c-mux.yaml in this directory. For each named state defined in the pinctrl-names property, an I2C child bus will be created. I2C child bus numbers are assigned based on the index into diff --git a/Documentation/devicetree/bindings/i2c/i2c-mux-reg.txt b/Documentation/devicetree/bindings/i2c/i2c-mux-reg.txt index de00d7fc450b..b9d9755e4172 100644 --- a/Documentation/devicetree/bindings/i2c/i2c-mux-reg.txt +++ b/Documentation/devicetree/bindings/i2c/i2c-mux-reg.txt @@ -7,8 +7,8 @@ Required properties: - compatible: i2c-mux-reg - i2c-parent: The phandle of the I2C bus that this multiplexer's master-side port is connected to. -* Standard I2C mux properties. See i2c-mux.txt in this directory. -* I2C child bus nodes. See i2c-mux.txt in this directory. +* Standard I2C mux properties. See i2c-mux.yaml in this directory. +* I2C child bus nodes. See i2c-mux.yaml in this directory. Optional properties: - reg: this pair of specifies the register to control the mux. diff --git a/Documentation/devicetree/bindings/i2c/i2c-mux.txt b/Documentation/devicetree/bindings/i2c/i2c-mux.txt deleted file mode 100644 index b38f58a1c878..000000000000 --- a/Documentation/devicetree/bindings/i2c/i2c-mux.txt +++ /dev/null @@ -1,73 +0,0 @@ -Common i2c bus multiplexer/switch properties. - -An i2c bus multiplexer/switch will have several child busses that are -numbered uniquely in a device dependent manner. The nodes for an i2c bus -multiplexer/switch will have one child node for each child bus. - -Optional properties: -- #address-cells = <1>; - This property is required if the i2c-mux child node does not exist. - -- #size-cells = <0>; - 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 - of both i2c child busses and other child nodes, the 'i2c-mux' subnode - can be used for populating the i2c child busses. If an 'i2c-mux' - subnode is present, only subnodes of this will be considered as i2c - child busses. - -Required properties for the i2c-mux child node: -- #address-cells = <1>; -- #size-cells = <0>; - -Required properties for i2c child bus nodes: -- #address-cells = <1>; -- #size-cells = <0>; -- reg : The sub-bus number. - -Optional properties for i2c child bus nodes: -- Other properties specific to the multiplexer/switch hardware. -- Child nodes conforming to i2c bus binding - - -Example : - - /* - An NXP pca9548 8 channel I2C multiplexer at address 0x70 - with two NXP pca8574 GPIO expanders attached, one each to - ports 3 and 4. - */ - - mux@70 { - compatible = "nxp,pca9548"; - reg = <0x70>; - #address-cells = <1>; - #size-cells = <0>; - - i2c@3 { - #address-cells = <1>; - #size-cells = <0>; - reg = <3>; - - gpio1: gpio@38 { - compatible = "nxp,pca8574"; - reg = <0x38>; - #gpio-cells = <2>; - gpio-controller; - }; - }; - i2c@4 { - #address-cells = <1>; - #size-cells = <0>; - reg = <4>; - - gpio2: gpio@38 { - compatible = "nxp,pca8574"; - reg = <0x38>; - #gpio-cells = <2>; - gpio-controller; - }; - }; - }; diff --git a/Documentation/devicetree/bindings/i2c/i2c-mux.yaml b/Documentation/devicetree/bindings/i2c/i2c-mux.yaml new file mode 100644 index 000000000000..24cac36037f5 --- /dev/null +++ b/Documentation/devicetree/bindings/i2c/i2c-mux.yaml @@ -0,0 +1,87 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/i2c/i2c-mux.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Common i2c bus multiplexer/switch properties. + +maintainers: + - Peter Rosin + +description: |+ + An i2c bus multiplexer/switch will have several child busses that are numbered + uniquely in a device dependent manner. The nodes for an i2c bus + multiplexer/switch will have one child node for each child bus. + + For i2c multiplexers/switches that have child nodes that are a mixture of both + i2c child busses and other child nodes, the 'i2c-mux' subnode can be used for + populating the i2c child busses. If an 'i2c-mux' subnode is present, only + subnodes of this will be considered as i2c child busses. + +properties: + $nodename: + pattern: '^(i2c-?)?mux' + + '#address-cells': + const: 1 + + '#size-cells': + const: 0 + +patternProperties: + '^i2c@[0-9a-f]+$': + $ref: /schemas/i2c/i2c-controller.yaml + unevaluatedProperties: false + + properties: + reg: + description: The mux selector sub-bus number for the child I2C bus. + maxItems: 1 + +additionalProperties: true + +examples: + - | + /* + * An NXP pca9548 8 channel I2C multiplexer at address 0x70 + * with two NXP pca8574 GPIO expanders attached, one each to + * ports 3 and 4. + */ + i2c { + #address-cells = <1>; + #size-cells = <0>; + + i2c-mux@70 { + compatible = "nxp,pca9548"; + reg = <0x70>; + #address-cells = <1>; + #size-cells = <0>; + + i2c@3 { + #address-cells = <1>; + #size-cells = <0>; + reg = <3>; + + gpio@20 { + compatible = "nxp,pca9555"; + gpio-controller; + #gpio-cells = <2>; + reg = <0x20>; + }; + }; + i2c@4 { + #address-cells = <1>; + #size-cells = <0>; + reg = <4>; + + gpio@20 { + compatible = "nxp,pca9555"; + gpio-controller; + #gpio-cells = <2>; + reg = <0x20>; + }; + }; + }; + }; +... -- cgit v1.2.3 From 86335b51e47d9b5065abf0e5fc438234e53ffe86 Mon Sep 17 00:00:00 2001 From: Rob Herring Date: Wed, 26 May 2021 13:48:38 -0500 Subject: dt-bindings: i2c: i2c-mux-pca954x: Convert to DT schema Convert the i2c-mux-pca954x binding to DT schema format. Add the missing compatible for 'nxp,pca9645' which is already in use. Reviewed-by: Laurent Pinchart Acked-by: Wolfram Sang Acked-by: Peter Rosin Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20210526184839.2937899-6-robh@kernel.org --- .../devicetree/bindings/i2c/i2c-mux-pca954x.txt | 74 -------------- .../devicetree/bindings/i2c/i2c-mux-pca954x.yaml | 110 +++++++++++++++++++++ 2 files changed, 110 insertions(+), 74 deletions(-) delete mode 100644 Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.txt create mode 100644 Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.txt b/Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.txt deleted file mode 100644 index 9f3f3eb67e87..000000000000 --- a/Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.txt +++ /dev/null @@ -1,74 +0,0 @@ -* NXP PCA954x I2C bus switch - -The driver supports NXP PCA954x and PCA984x I2C mux/switch devices. - -Required Properties: - - - compatible: Must contain one of the following. - "nxp,pca9540", - "nxp,pca9542", - "nxp,pca9543", - "nxp,pca9544", - "nxp,pca9545", - "nxp,pca9546", "nxp,pca9846", - "nxp,pca9547", "nxp,pca9847", - "nxp,pca9548", "nxp,pca9848", - "nxp,pca9849" - - - reg: The I2C address of the device. - - The following required properties are defined externally: - - - Standard I2C mux properties. See i2c-mux.txt in this directory. - - I2C child bus nodes. See i2c-mux.txt in this directory. - -Optional Properties: - - - reset-gpios: Reference to the GPIO connected to the reset input. - - idle-state: if present, overrides i2c-mux-idle-disconnect, - Please refer to Documentation/devicetree/bindings/mux/mux-controller.yaml - - i2c-mux-idle-disconnect: Boolean; if defined, forces mux to disconnect all - children in idle state. This is necessary for example, if there are several - multiplexers on the bus and the devices behind them use same I2C addresses. - - interrupts: Interrupt mapping for IRQ. - - interrupt-controller: Marks the device node as an interrupt controller. - - #interrupt-cells : Should be two. - - first cell is the pin number - - second cell is used to specify flags. - See also Documentation/devicetree/bindings/interrupt-controller/interrupts.txt - -Example: - - i2c-switch@74 { - compatible = "nxp,pca9548"; - #address-cells = <1>; - #size-cells = <0>; - reg = <0x74>; - - interrupt-parent = <&ipic>; - interrupts = <17 IRQ_TYPE_LEVEL_LOW>; - interrupt-controller; - #interrupt-cells = <2>; - - i2c@2 { - #address-cells = <1>; - #size-cells = <0>; - reg = <2>; - - eeprom@54 { - compatible = "atmel,24c08"; - reg = <0x54>; - }; - }; - - i2c@4 { - #address-cells = <1>; - #size-cells = <0>; - reg = <4>; - - rtc@51 { - compatible = "nxp,pcf8563"; - reg = <0x51>; - }; - }; - }; diff --git a/Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.yaml b/Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.yaml new file mode 100644 index 000000000000..9f1726d0356b --- /dev/null +++ b/Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.yaml @@ -0,0 +1,110 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/i2c/i2c-mux-pca954x.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NXP PCA954x I2C bus switch + +maintainers: + - Laurent Pinchart + +description: + The binding supports NXP PCA954x and PCA984x I2C mux/switch devices. + +allOf: + - $ref: /schemas/i2c/i2c-mux.yaml# + +properties: + compatible: + oneOf: + - enum: + - nxp,pca9540 + - nxp,pca9542 + - nxp,pca9543 + - nxp,pca9544 + - nxp,pca9545 + - nxp,pca9546 + - nxp,pca9547 + - nxp,pca9548 + - nxp,pca9846 + - nxp,pca9847 + - nxp,pca9848 + - nxp,pca9849 + - items: + - const: nxp,pca9646 + - const: nxp,pca9546 + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + "#interrupt-cells": + const: 2 + + interrupt-controller: true + + reset-gpios: + maxItems: 1 + + i2c-mux-idle-disconnect: + type: boolean + description: Forces mux to disconnect all children in idle state. This is + necessary for example, if there are several multiplexers on the bus and + the devices behind them use same I2C addresses. + + idle-state: + description: if present, overrides i2c-mux-idle-disconnect + $ref: /schemas/mux/mux-controller.yaml#/properties/idle-state + +required: + - compatible + - reg + +unevaluatedProperties: false + +examples: + - | + #include + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + i2c-mux@74 { + compatible = "nxp,pca9548"; + #address-cells = <1>; + #size-cells = <0>; + reg = <0x74>; + + interrupt-parent = <&ipic>; + interrupts = <17 IRQ_TYPE_LEVEL_LOW>; + interrupt-controller; + #interrupt-cells = <2>; + + i2c@2 { + #address-cells = <1>; + #size-cells = <0>; + reg = <2>; + + eeprom@54 { + compatible = "atmel,24c08"; + reg = <0x54>; + }; + }; + + i2c@4 { + #address-cells = <1>; + #size-cells = <0>; + reg = <4>; + + rtc@51 { + compatible = "nxp,pcf8563"; + reg = <0x51>; + }; + }; + }; + }; +... -- cgit v1.2.3 From f22107b91ae26f82ec27620ba37f2687ab3fe2b6 Mon Sep 17 00:00:00 2001 From: Rob Herring Date: Wed, 26 May 2021 13:48:39 -0500 Subject: dt-bindings: i2c: maxim,max9286: Use the i2c-mux.yaml schema MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Use the i2c-mux.yaml schema in the maxim,max9286 binding schema. With this, several properties can be dropped as they are defined in i2c-mux.yaml already. Cc: Jacopo Mondi Cc: Kieran Bingham Cc: Niklas Söderlund Reviewed-by: Laurent Pinchart Acked-by: Wolfram Sang Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20210526184839.2937899-7-robh@kernel.org --- .../bindings/media/i2c/maxim,max9286.yaml | 23 +++------------------- 1 file changed, 3 insertions(+), 20 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/media/i2c/maxim,max9286.yaml b/Documentation/devicetree/bindings/media/i2c/maxim,max9286.yaml index ee16102fdfe7..02f656e78700 100644 --- a/Documentation/devicetree/bindings/media/i2c/maxim,max9286.yaml +++ b/Documentation/devicetree/bindings/media/i2c/maxim,max9286.yaml @@ -111,17 +111,10 @@ properties: i2c-mux: type: object + $ref: /schemas/i2c/i2c-mux.yaml# + unevaluatedProperties: false description: | - Each GMSL link is modelled as a child bus of an i2c bus - multiplexer/switch, in accordance with bindings described in - Documentation/devicetree/bindings/i2c/i2c-mux.txt. - - properties: - '#address-cells': - const: 1 - - '#size-cells': - const: 0 + Each GMSL link is modelled as a child bus of an i2c bus multiplexer/switch. patternProperties: "^i2c@[0-3]$": @@ -133,12 +126,6 @@ properties: channels. properties: - '#address-cells': - const: 1 - - '#size-cells': - const: 0 - reg: description: The index of the GMSL channel. maxItems: 1 @@ -173,10 +160,6 @@ properties: additionalProperties: false - additionalProperties: false - - additionalProperties: false - required: - compatible - reg -- cgit v1.2.3 From 710b797cf61b318995db6d31767a532162db113d Mon Sep 17 00:00:00 2001 From: Sharath Chandra Vurukala Date: Wed, 2 Jun 2021 00:58:34 +0530 Subject: docs: networking: Add documentation for MAPv5 Adding documentation explaining the new MAPv4/v5 packet formats and the corresponding checksum offload headers. Signed-off-by: Sharath Chandra Vurukala Signed-off-by: David S. Miller --- .../device_drivers/cellular/qualcomm/rmnet.rst | 126 +++++++++++++++++++-- 1 file changed, 114 insertions(+), 12 deletions(-) (limited to 'Documentation') diff --git a/Documentation/networking/device_drivers/cellular/qualcomm/rmnet.rst b/Documentation/networking/device_drivers/cellular/qualcomm/rmnet.rst index 70643b58de05..4118384cf8eb 100644 --- a/Documentation/networking/device_drivers/cellular/qualcomm/rmnet.rst +++ b/Documentation/networking/device_drivers/cellular/qualcomm/rmnet.rst @@ -27,34 +27,136 @@ these MAP frames and send them to appropriate PDN's. 2. Packet format ================ -a. MAP packet (data / control) +a. MAP packet v1 (data / control) -MAP header has the same endianness of the IP packet. +MAP header fields are in big endian format. Packet format:: - Bit 0 1 2-7 8 - 15 16 - 31 + Bit 0 1 2-7 8-15 16-31 Function Command / Data Reserved Pad Multiplexer ID Payload length - Bit 32 - x - Function Raw Bytes + + Bit 32-x + Function Raw bytes Command (1)/ Data (0) bit value is to indicate if the packet is a MAP command -or data packet. Control packet is used for transport level flow control. Data +or data packet. Command packet is used for transport level flow control. Data packets are standard IP packets. -Reserved bits are usually zeroed out and to be ignored by receiver. +Reserved bits must be zero when sent and ignored when received. -Padding is number of bytes to be added for 4 byte alignment if required by -hardware. +Padding is the number of bytes to be appended to the payload to +ensure 4 byte alignment. Multiplexer ID is to indicate the PDN on which data has to be sent. Payload length includes the padding length but does not include MAP header length. -b. MAP packet (command specific):: +b. Map packet v4 (data / control) + +MAP header fields are in big endian format. + +Packet format:: + + Bit 0 1 2-7 8-15 16-31 + Function Command / Data Reserved Pad Multiplexer ID Payload length + + Bit 32-(x-33) (x-32)-x + Function Raw bytes Checksum offload header + +Command (1)/ Data (0) bit value is to indicate if the packet is a MAP command +or data packet. Command packet is used for transport level flow control. Data +packets are standard IP packets. + +Reserved bits must be zero when sent and ignored when received. + +Padding is the number of bytes to be appended to the payload to +ensure 4 byte alignment. + +Multiplexer ID is to indicate the PDN on which data has to be sent. + +Payload length includes the padding length but does not include MAP header +length. + +Checksum offload header, has the information about the checksum processing done +by the hardware.Checksum offload header fields are in big endian format. + +Packet format:: + + Bit 0-14 15 16-31 + Function Reserved Valid Checksum start offset + + Bit 31-47 48-64 + Function Checksum length Checksum value + +Reserved bits must be zero when sent and ignored when received. + +Valid bit indicates whether the partial checksum is calculated and is valid. +Set to 1, if its is valid. Set to 0 otherwise. + +Padding is the number of bytes to be appended to the payload to +ensure 4 byte alignment. + +Checksum start offset, Indicates the offset in bytes from the beginning of the +IP header, from which modem computed checksum. + +Checksum length is the Length in bytes starting from CKSUM_START_OFFSET, +over which checksum is computed. + +Checksum value, indicates the checksum computed. + +c. MAP packet v5 (data / control) + +MAP header fields are in big endian format. + +Packet format:: + + Bit 0 1 2-7 8-15 16-31 + Function Command / Data Next header Pad Multiplexer ID Payload length + + Bit 32-x + Function Raw bytes + +Command (1)/ Data (0) bit value is to indicate if the packet is a MAP command +or data packet. Command packet is used for transport level flow control. Data +packets are standard IP packets. + +Next header is used to indicate the presence of another header, currently is +limited to checksum header. + +Padding is the number of bytes to be appended to the payload to +ensure 4 byte alignment. + +Multiplexer ID is to indicate the PDN on which data has to be sent. + +Payload length includes the padding length but does not include MAP header +length. + +d. Checksum offload header v5 + +Checksum offload header fields are in big endian format. + + Bit 0 - 6 7 8-15 16-31 + Function Header Type Next Header Checksum Valid Reserved + +Header Type is to indicate the type of header, this usually is set to CHECKSUM + +Header types += ========================================== +0 Reserved +1 Reserved +2 checksum header + +Checksum Valid is to indicate whether the header checksum is valid. Value of 1 +implies that checksum is calculated on this packet and is valid, value of 0 +indicates that the calculated packet checksum is invalid. + +Reserved bits must be zero when sent and ignored when received. + +e. MAP packet v1/v5 (command specific):: - Bit 0 1 2-7 8 - 15 16 - 31 + Bit 0 1 2-7 8 - 15 16 - 31 Function Command Reserved Pad Multiplexer ID Payload length Bit 32 - 39 40 - 45 46 - 47 48 - 63 Function Command name Reserved Command Type Reserved @@ -74,7 +176,7 @@ Command types 3 is for error during processing of commands = ========================================== -c. Aggregation +f. Aggregation Aggregation is multiple MAP packets (can be data or command) delivered to rmnet in a single linear skb. rmnet will process the individual -- cgit v1.2.3 From 6faa7e4ddce6ddd5e93b0e521537e0360c7dac2b Mon Sep 17 00:00:00 2001 From: Konrad Dybcio Date: Sat, 13 Mar 2021 03:03:07 +0100 Subject: dt-bindings: clock: Add MDM9607 GCC clock bindings Add device tree bindings for global clock controller on MDM9607 SoC. Signed-off-by: Konrad Dybcio Link: https://lore.kernel.org/r/20210313020310.386152-1-konrad.dybcio@somainline.org Acked-by: Rob Herring Signed-off-by: Stephen Boyd --- Documentation/devicetree/bindings/clock/qcom,gcc.yaml | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc.yaml index 490edad25830..3599702cd428 100644 --- a/Documentation/devicetree/bindings/clock/qcom,gcc.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,gcc.yaml @@ -29,6 +29,7 @@ description: | - dt-bindings/clock/qcom,gcc-msm8974.h - dt-bindings/reset/qcom,gcc-msm8974.h - dt-bindings/clock/qcom,gcc-msm8994.h + - dt-bindings/clock/qcom,gcc-mdm9607.h - dt-bindings/clock/qcom,gcc-mdm9615.h - dt-bindings/reset/qcom,gcc-mdm9615.h - dt-bindings/clock/qcom,gcc-sdm660.h (qcom,gcc-sdm630 and qcom,gcc-sdm660) @@ -40,6 +41,7 @@ properties: - qcom,gcc-ipq4019 - qcom,gcc-ipq6018 - qcom,gcc-ipq8064 + - qcom,gcc-mdm9607 - qcom,gcc-msm8660 - qcom,gcc-msm8916 - qcom,gcc-msm8939 -- cgit v1.2.3 From 8ff48c82df66bf8864070922b9d7ddcfd8ab2918 Mon Sep 17 00:00:00 2001 From: Bjorn Andersson Date: Mon, 10 May 2021 23:17:18 -0500 Subject: clk: qcom: dispcc-sm8250: Add sc8180x support The display clock controller in SC8180x is reused from SM8150, so add the necessary compatible and wire up the driver to enable this. Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20210511041719.591969-1-bjorn.andersson@linaro.org Acked-by: Rob Herring Signed-off-by: Stephen Boyd --- Documentation/devicetree/bindings/clock/qcom,dispcc-sm8x50.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/qcom,dispcc-sm8x50.yaml b/Documentation/devicetree/bindings/clock/qcom,dispcc-sm8x50.yaml index 0cdf53f41f84..6667261dc665 100644 --- a/Documentation/devicetree/bindings/clock/qcom,dispcc-sm8x50.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,dispcc-sm8x50.yaml @@ -20,6 +20,7 @@ description: | properties: compatible: enum: + - qcom,sc8180x-dispcc - qcom,sm8150-dispcc - qcom,sm8250-dispcc -- cgit v1.2.3 From ec7e22abec97b6bd577027380077ec395864a3c5 Mon Sep 17 00:00:00 2001 From: Bartosz Dudziak Date: Sun, 2 May 2021 14:20:26 +0200 Subject: dt-bindings: clock: qcom: rpmcc: Document MSM8226 compatible Add the dt-binding for the RPM Clock Controller on the MSM8226 SoC. Signed-off-by: Bartosz Dudziak Link: https://lore.kernel.org/r/20210502122027.9351-4-bartosz.dudziak@snejp.pl Acked-by: Rob Herring 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 b44a0622fb3a..6cf5a7ec2b4c 100644 --- a/Documentation/devicetree/bindings/clock/qcom,rpmcc.txt +++ b/Documentation/devicetree/bindings/clock/qcom,rpmcc.txt @@ -12,6 +12,7 @@ Required properties : "qcom,rpmcc-msm8660", "qcom,rpmcc" "qcom,rpmcc-apq8060", "qcom,rpmcc" + "qcom,rpmcc-msm8226", "qcom,rpmcc" "qcom,rpmcc-msm8916", "qcom,rpmcc" "qcom,rpmcc-msm8936", "qcom,rpmcc" "qcom,rpmcc-msm8974", "qcom,rpmcc" -- cgit v1.2.3 From dc794d3d24246588d4db88c9d2c2ad67273027fd Mon Sep 17 00:00:00 2001 From: Sakari Ailus Date: Mon, 12 Apr 2021 13:04:33 +0200 Subject: media: staging: ipu3-imgu: Move the UAPI header from include under include/uapi The header defines the user space interface but may be mistaken as kernel-only header due to its location. Add "uapi" directory under driver's include directory and move the header there. Suggested-by: Greg KH Signed-off-by: Sakari Ailus Reviewed-by: Bingbu Cao Signed-off-by: Mauro Carvalho Chehab --- Documentation/admin-guide/media/ipu3.rst | 35 +++++++++++----------- .../media/v4l/pixfmt-meta-intel-ipu3.rst | 2 +- 2 files changed, 19 insertions(+), 18 deletions(-) (limited to 'Documentation') diff --git a/Documentation/admin-guide/media/ipu3.rst b/Documentation/admin-guide/media/ipu3.rst index f59697c7b374..d6454f637ff4 100644 --- a/Documentation/admin-guide/media/ipu3.rst +++ b/Documentation/admin-guide/media/ipu3.rst @@ -234,22 +234,23 @@ The IPU3 ImgU pipelines can be configured using the Media Controller, defined at Running mode and firmware binary selection ------------------------------------------ -ImgU works based on firmware, currently the ImgU firmware support run 2 pipes in -time-sharing with single input frame data. Each pipe can run at certain mode - -"VIDEO" or "STILL", "VIDEO" mode is commonly used for video frames capture, and -"STILL" is used for still frame capture. However, you can also select "VIDEO" to -capture still frames if you want to capture images with less system load and -power. For "STILL" mode, ImgU will try to use smaller BDS factor and output -larger bayer frame for further YUV processing than "VIDEO" mode to get high -quality images. Besides, "STILL" mode need XNR3 to do noise reduction, hence -"STILL" mode will need more power and memory bandwidth than "VIDEO" mode. TNR -will be enabled in "VIDEO" mode and bypassed by "STILL" mode. ImgU is running at -“VIDEO” mode by default, the user can use v4l2 control V4L2_CID_INTEL_IPU3_MODE -(currently defined in drivers/staging/media/ipu3/include/intel-ipu3.h) to query -and set the running mode. For user, there is no difference for buffer queueing -between the "VIDEO" and "STILL" mode, mandatory input and main output node -should be enabled and buffers need be queued, the statistics and the view-finder -queues are optional. +ImgU works based on firmware, currently the ImgU firmware support run 2 pipes +in time-sharing with single input frame data. Each pipe can run at certain mode +- "VIDEO" or "STILL", "VIDEO" mode is commonly used for video frames capture, +and "STILL" is used for still frame capture. However, you can also select +"VIDEO" to capture still frames if you want to capture images with less system +load and power. For "STILL" mode, ImgU will try to use smaller BDS factor and +output larger bayer frame for further YUV processing than "VIDEO" mode to get +high quality images. Besides, "STILL" mode need XNR3 to do noise reduction, +hence "STILL" mode will need more power and memory bandwidth than "VIDEO" mode. +TNR will be enabled in "VIDEO" mode and bypassed by "STILL" mode. ImgU is +running at “VIDEO” mode by default, the user can use v4l2 control +V4L2_CID_INTEL_IPU3_MODE (currently defined in +drivers/staging/media/ipu3/include/uapi/intel-ipu3.h) to query and set the +running mode. For user, there is no difference for buffer queueing between the +"VIDEO" and "STILL" mode, mandatory input and main output node should be +enabled and buffers need be queued, the statistics and the view-finder queues +are optional. The firmware binary will be selected according to current running mode, such log "using binary if_to_osys_striped " or "using binary if_to_osys_primary_striped" @@ -586,7 +587,7 @@ preserved. References ========== -.. [#f5] drivers/staging/media/ipu3/include/intel-ipu3.h +.. [#f5] drivers/staging/media/ipu3/include/uapi/intel-ipu3.h .. [#f1] https://github.com/intel/nvt diff --git a/Documentation/userspace-api/media/v4l/pixfmt-meta-intel-ipu3.rst b/Documentation/userspace-api/media/v4l/pixfmt-meta-intel-ipu3.rst index 5f33d35532ef..84d81dd7a7b5 100644 --- a/Documentation/userspace-api/media/v4l/pixfmt-meta-intel-ipu3.rst +++ b/Documentation/userspace-api/media/v4l/pixfmt-meta-intel-ipu3.rst @@ -78,4 +78,4 @@ hardware and algorithm details. Intel IPU3 ImgU uAPI data types =============================== -.. kernel-doc:: drivers/staging/media/ipu3/include/intel-ipu3.h +.. kernel-doc:: drivers/staging/media/ipu3/include/uapi/intel-ipu3.h -- cgit v1.2.3 From 80cf16de33a29b45a0bbfd74b0cf65fdb458f7bf Mon Sep 17 00:00:00 2001 From: Ikjoon Jang Date: Wed, 12 May 2021 18:08:31 +0800 Subject: mfd: google,cros-ec: add DT bindings for a baseboard's switch device This is for ChromeOS tablets which have a 'cros_cbas' switch device in the "Whiskers" base board. This device can be instantiated only by device tree on ARM platforms. ChromeOS EC doesn't provide a way to probe the device. Signed-off-by: Ikjoon Jang Reviewed-by: Rob Herring Acked-by: Enric Balletbo i Serra Signed-off-by: Lee Jones --- .../devicetree/bindings/mfd/google,cros-ec.yaml | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mfd/google,cros-ec.yaml b/Documentation/devicetree/bindings/mfd/google,cros-ec.yaml index 4dfa70a013ae..d793dd0316b7 100644 --- a/Documentation/devicetree/bindings/mfd/google,cros-ec.yaml +++ b/Documentation/devicetree/bindings/mfd/google,cros-ec.yaml @@ -117,6 +117,22 @@ properties: - "#address-cells" - "#size-cells" + cbas: + type: object + + description: + This device is used to signal when a detachable base is attached + to a Chrome OS tablet. This device cannot be detected at runtime. + + properties: + compatible: + const: google,cros-cbas + + required: + - compatible + + additionalProperties: false + patternProperties: "^i2c-tunnel[0-9]*$": type: object @@ -187,6 +203,10 @@ examples: proximity { compatible = "google,cros-ec-mkbp-proximity"; }; + + cbas { + compatible = "google,cros-cbas"; + }; }; }; -- cgit v1.2.3 From 4f10f31e72582bb68ebd39505e2f2f5ce906eb47 Mon Sep 17 00:00:00 2001 From: ChiYuan Huang Date: Mon, 17 May 2021 22:35:59 +0800 Subject: backlight: rt4831: Adds DT binding document for Richtek RT4831 backlight Adds DT binding document for Richtek RT4831 backlight. Signed-off-by: ChiYuan Huang Reviewed-by: Daniel Thompson Signed-off-by: Lee Jones --- .../leds/backlight/richtek,rt4831-backlight.yaml | 62 ++++++++++++++++++++++ 1 file changed, 62 insertions(+) create mode 100644 Documentation/devicetree/bindings/leds/backlight/richtek,rt4831-backlight.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/leds/backlight/richtek,rt4831-backlight.yaml b/Documentation/devicetree/bindings/leds/backlight/richtek,rt4831-backlight.yaml new file mode 100644 index 000000000000..e0ac68694b63 --- /dev/null +++ b/Documentation/devicetree/bindings/leds/backlight/richtek,rt4831-backlight.yaml @@ -0,0 +1,62 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/leds/backlight/richtek,rt4831-backlight.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Richtek RT4831 Backlight + +maintainers: + - ChiYuan Huang + +description: | + RT4831 is a mutifunctional device that can provide power to the LCD display + and LCD backlight. + + For the LCD backlight, it can provide four channel WLED driving capability. + Each channel driving current is up to 30mA + + Datasheet is available at + https://www.richtek.com/assets/product_file/RT4831A/DS4831A-05.pdf + +allOf: + - $ref: common.yaml# + +properties: + compatible: + const: richtek,rt4831-backlight + + default-brightness: + minimum: 0 + maximum: 2048 + + max-brightness: + minimum: 0 + maximum: 2048 + + richtek,pwm-enable: + description: | + Specify the backlight dimming following by PWM duty or by SW control. + type: boolean + + richtek,bled-ovp-sel: + description: | + Backlight OVP level selection, currently support 17V/21V/25V/29V. + $ref: /schemas/types.yaml#/definitions/uint8 + default: 1 + minimum: 0 + maximum: 3 + + richtek,channel-use: + description: | + Backlight LED channel to be used. + BIT 0/1/2/3 is used to indicate led channel 1/2/3/4 enable or disable. + $ref: /schemas/types.yaml#/definitions/uint8 + minimum: 1 + maximum: 15 + +required: + - compatible + - richtek,channel-use + +additionalProperties: false -- cgit v1.2.3 From 037dd2f023516be217199def5a3079c6b284d4de Mon Sep 17 00:00:00 2001 From: ChiYuan Huang Date: Mon, 17 May 2021 22:36:00 +0800 Subject: mfd: rt4831: Adds DT binding document for Richtek RT4831 Adds DT binding document for Richtek RT4831. Signed-off-by: ChiYuan Huang Reviewed-by: Rob Herring Signed-off-by: Lee Jones --- .../devicetree/bindings/mfd/richtek,rt4831.yaml | 90 ++++++++++++++++++++++ 1 file changed, 90 insertions(+) create mode 100644 Documentation/devicetree/bindings/mfd/richtek,rt4831.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mfd/richtek,rt4831.yaml b/Documentation/devicetree/bindings/mfd/richtek,rt4831.yaml new file mode 100644 index 000000000000..4762eb1439ce --- /dev/null +++ b/Documentation/devicetree/bindings/mfd/richtek,rt4831.yaml @@ -0,0 +1,90 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mfd/richtek,rt4831.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Richtek RT4831 DSV and Backlight Integrated IC + +maintainers: + - ChiYuan Huang + +description: | + RT4831 is a multifunctional device that can provide power to the LCD display + and LCD backlight. + + For Display Bias Voltage DSVP and DSVN, the output range is about 4V to 6.5V. + It's sufficient to meet the current LCD power requirement. + + For the LCD backlight, it can provide four channel WLED driving capability. + Each channel driving current is up to 30mA + + Datasheet is available at + https://www.richtek.com/assets/product_file/RT4831A/DS4831A-05.pdf + +properties: + compatible: + const: richtek,rt4831 + + reg: + description: I2C device address. + maxItems: 1 + + enable-gpios: + description: | + GPIO to enable/disable the chip. It is optional. + Some usage directly tied this pin to follow VIO 1.8V power on sequence. + maxItems: 1 + + regulators: + $ref: ../regulator/richtek,rt4831-regulator.yaml + + backlight: + $ref: ../leds/backlight/richtek,rt4831-backlight.yaml + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + #include + i2c { + #address-cells = <1>; + #size-cells = <0>; + + rt4831@11 { + compatible = "richtek,rt4831"; + reg = <0x11>; + + regulators { + DSVLCM { + regulator-min-microvolt = <4000000>; + regulator-max-microvolt = <7150000>; + regulator-allow-bypass; + }; + DSVP { + regulator-name = "rt4831-dsvp"; + regulator-min-microvolt = <4000000>; + regulator-max-microvolt = <6500000>; + regulator-boot-on; + }; + DSVN { + regulator-name = "rt4831-dsvn"; + regulator-min-microvolt = <4000000>; + regulator-max-microvolt = <6500000>; + regulator-boot-on; + }; + }; + + backlight { + compatible = "richtek,rt4831-backlight"; + default-brightness = <1024>; + max-brightness = <2048>; + richtek,bled-ovp-sel = /bits/ 8 ; + richtek,channel-use = /bits/ 8 ; + }; + }; + }; -- cgit v1.2.3 From f94c780172b397756da82c3de98f3965d34a2b94 Mon Sep 17 00:00:00 2001 From: Linus Walleij Date: Tue, 18 May 2021 16:51:32 +0200 Subject: mfd: db8500-prcmu: Add devicetree bindings This driver was merged in the early days of device tree on Arm in 2012 and somehow we failed to provide bindings for it. Fix it up with some YAML bindings. Signed-off-by: Linus Walleij Reviewed-by: Rob Herring Signed-off-by: Lee Jones --- .../bindings/mfd/stericsson,db8500-prcmu.yaml | 278 +++++++++++++++++++++ 1 file changed, 278 insertions(+) create mode 100644 Documentation/devicetree/bindings/mfd/stericsson,db8500-prcmu.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mfd/stericsson,db8500-prcmu.yaml b/Documentation/devicetree/bindings/mfd/stericsson,db8500-prcmu.yaml new file mode 100644 index 000000000000..a0d4bad5dc81 --- /dev/null +++ b/Documentation/devicetree/bindings/mfd/stericsson,db8500-prcmu.yaml @@ -0,0 +1,278 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mfd/stericsson,db8500-prcmu.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: ST-Ericsson DB8500 PRCMU - Power Reset and Control Management Unit + +maintainers: + - Linus Walleij + +description: + The DB8500 Power Reset and Control Management Unit is an XP70 8-bit + microprocessor that is embedded in the always-on power domain of the + DB8500 SoCs to manage the low power states, powering up and down parts + of the silicon, and controlling reset of different IP blocks. + +properties: + $nodename: + pattern: '^prcmu@[0-9a-f]+$' + + compatible: + description: The device is compatible both to the device-specific + compatible "stericsson,db8500-prcmu" and "syscon". The latter + compatible is needed for the device to be exposed as a system + controller so that arbitrary registers can be access by + different operating system components. + items: + - const: stericsson,db8500-prcmu + - const: syscon + + reg: + items: + - description: Main PRCMU register area + - description: PRCMU TCPM register area + - description: PRCMU TCDM register area + + reg-names: + items: + - const: prcmu + - const: prcmu-tcpm + - const: prcmu-tcdm + + interrupts: + maxItems: 1 + + '#address-cells': + const: 1 + + '#size-cells': + const: 1 + + ranges: true + + interrupt-controller: true + + '#interrupt-cells': + const: 2 + + db8500-prcmu-regulators: + description: Node describing the DB8500 regulators. These are mainly + power rails inside the silicon but some of those are also routed + out to external pins. + type: object + + properties: + compatible: + const: stericsson,db8500-prcmu-regulator + + db8500_vape: + description: The voltage for the application processor, the + main voltage domain for the chip. + type: object + $ref: ../regulator/regulator.yaml# + + db8500_varm: + description: The voltage for the ARM Cortex A-9 CPU. + type: object + $ref: ../regulator/regulator.yaml# + + db8500_vmodem: + description: The voltage for the modem subsystem. + type: object + $ref: ../regulator/regulator.yaml# + + db8500_vpll: + description: The voltage for the phase locked loop clocks. + type: object + $ref: ../regulator/regulator.yaml# + + db8500_vsmps1: + description: Also known as VIO12, is a step-down voltage regulator + for 1.2V I/O. SMPS means System Management Power Source. + type: object + $ref: ../regulator/regulator.yaml# + + db8500_vsmps2: + description: Also known as VIO18, is a step-down voltage regulator + for 1.8V I/O. SMPS means System Management Power Source. + type: object + $ref: ../regulator/regulator.yaml# + + db8500_vsmps3: + description: This is a step-down voltage regulator + for 0.87 thru 1.875V I/O. SMPS means System Management Power Source. + type: object + $ref: ../regulator/regulator.yaml# + + db8500_vrf1: + description: RF transciever voltage regulator. + type: object + $ref: ../regulator/regulator.yaml# + + db8500_sva_mmdsp: + description: Smart Video Accelerator (SVA) multimedia DSP (MMDSP) + voltage regulator. This is the voltage for the accelerator DSP + for video encoding and decoding. + type: object + $ref: ../regulator/regulator.yaml# + + db8500_sva_mmdsp_ret: + description: Smart Video Accelerator (SVA) multimedia DSP (MMDSP) + voltage regulator for retention mode. + type: object + $ref: ../regulator/regulator.yaml# + + db8500_sva_pipe: + description: Smart Video Accelerator (SVA) multimedia DSP (MMDSP) + voltage regulator for the data pipe. + type: object + $ref: ../regulator/regulator.yaml# + + db8500_sia_mmdsp: + description: Smart Image Accelerator (SIA) multimedia DSP (MMDSP) + voltage regulator. This is the voltage for the accelerator DSP + for image encoding and decoding. + type: object + $ref: ../regulator/regulator.yaml# + + db8500_sia_mmdsp_ret: + description: Smart Image Accelerator (SIA) multimedia DSP (MMDSP) + voltage regulator for retention mode. + type: object + $ref: ../regulator/regulator.yaml# + + db8500_sia_pipe: + description: Smart Image Accelerator (SIA) multimedia DSP (MMDSP) + voltage regulator for the data pipe. + type: object + $ref: ../regulator/regulator.yaml# + + db8500_sga: + description: Smart Graphics Accelerator (SGA) voltage regulator. + This is in effect controlling the power to the MALI400 3D + accelerator block. + type: object + $ref: ../regulator/regulator.yaml# + + db8500_b2r2_mcde: + description: Blit Blend Rotate and Rescale (B2R2), and Multi-Channel + Display Engine (MCDE) voltage regulator. These are two graphics + blocks. + type: object + $ref: ../regulator/regulator.yaml# + + db8500_esram12: + description: Embedded Static RAM (ESRAM) 1 and 2 voltage regulator. + type: object + $ref: ../regulator/regulator.yaml# + + db8500_esram12_ret: + description: Embedded Static RAM (ESRAM) 1 and 2 voltage regulator for + retention mode. + type: object + $ref: ../regulator/regulator.yaml# + + db8500_esram34: + description: Embedded Static RAM (ESRAM) 3 and 4 voltage regulator. + type: object + $ref: ../regulator/regulator.yaml# + + db8500_esram34_ret: + description: Embedded Static RAM (ESRAM) 3 and 4 voltage regulator for + retention mode. + type: object + $ref: ../regulator/regulator.yaml# + + required: + - compatible + - db8500_vape + - db8500_varm + - db8500_vmodem + - db8500_vpll + - db8500_vsmps1 + - db8500_vsmps2 + - db8500_vsmps3 + - db8500_vrf1 + - db8500_sva_mmdsp + - db8500_sva_mmdsp_ret + - db8500_sva_pipe + - db8500_sia_mmdsp + - db8500_sia_mmdsp_ret + - db8500_sia_pipe + - db8500_sga + - db8500_b2r2_mcde + - db8500_esram12 + - db8500_esram12_ret + - db8500_esram34 + - db8500_esram34_ret + + additionalProperties: false + +patternProperties: + "^thermal@[0-9a-f]+$": + description: Node describing the DB8500 thermal control functions. + This binds to an operating system driver that monitors the + temperature of the SoC. + type: object + + properties: + compatible: + const: stericsson,db8500-thermal + + reg: + maxItems: 1 + + interrupts: + items: + - description: Hotmon low interrupt (falling temperature) + - description: Hotmon high interrupt (rising temperature) + + interrupt-names: + items: + - const: IRQ_HOTMON_LOW + - const: IRQ_HOTMON_HIGH + + '#thermal-sensor-cells': + const: 0 + + additionalProperties: false + + "^prcmu-timer-4@[0-9a-f]+$": + description: Node describing the externally visible timer 4 in the + PRCMU block. This timer is interesting to the operating system + since even thought it has a very low resolution (32768 Hz) it is + always on, and thus provides a consistent monotonic timeline for + the system. + type: object + + properties: + compatible: + const: stericsson,db8500-prcmu-timer-4 + + reg: + maxItems: 1 + + additionalProperties: false + + "^ab850[05]$": + description: Node describing the Analog Baseband 8500 mixed-signals + ASIC AB8500 and subcomponents. The AB8500 is accessed through the + PRCMU and hence it appears here. This component has a separate + set of devicetree bindings. The AB8505 is a newer version of the + same ASIC. + type: object + +required: + - compatible + - reg + - '#address-cells' + - '#size-cells' + - ranges + - interrupts + - interrupt-controller + - '#interrupt-cells' + - db8500-prcmu-regulators + +additionalProperties: false -- cgit v1.2.3 From caad79405086151dec128f78274a999f15d947ed Mon Sep 17 00:00:00 2001 From: Bernhard Wimmer Date: Wed, 21 Apr 2021 23:33:19 +0200 Subject: media: Documentation: ccs: Fix the op_pll_multiplier address According to the CCS spec the op_pll_multiplier address is 0x030e, not 0x031e. Signed-off-by: Bernhard Wimmer Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab --- Documentation/driver-api/media/drivers/ccs/ccs-regs.asc | 2 +- Documentation/driver-api/media/drivers/ccs/mk-ccs-regs | 5 +++-- 2 files changed, 4 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/driver-api/media/drivers/ccs/ccs-regs.asc b/Documentation/driver-api/media/drivers/ccs/ccs-regs.asc index f2042acc8a45..bbf9213c3388 100644 --- a/Documentation/driver-api/media/drivers/ccs/ccs-regs.asc +++ b/Documentation/driver-api/media/drivers/ccs/ccs-regs.asc @@ -210,7 +210,7 @@ pll_multiplier 0x0306 16 op_pix_clk_div 0x0308 16 op_sys_clk_div 0x030a 16 op_pre_pll_clk_div 0x030c 16 -op_pll_multiplier 0x031e 16 +op_pll_multiplier 0x030e 16 pll_mode 0x0310 8 - f 0 0 - e single 0 diff --git a/Documentation/driver-api/media/drivers/ccs/mk-ccs-regs b/Documentation/driver-api/media/drivers/ccs/mk-ccs-regs index 6668deaf2f19..2a4edc7e051a 100755 --- a/Documentation/driver-api/media/drivers/ccs/mk-ccs-regs +++ b/Documentation/driver-api/media/drivers/ccs/mk-ccs-regs @@ -72,13 +72,14 @@ $uc_header =~ s/[^A-Z0-9]/_/g; my $copyright = "/* Copyright (C) 2019--2020 Intel Corporation */\n"; my $license = "SPDX-License-Identifier: GPL-2.0-only OR BSD-3-Clause"; +my $note = "/*\n * Generated by $0;\n * do not modify.\n */\n"; for my $fh ($A, $LC) { - print $fh "// $license\n$copyright\n" if defined $fh; + print $fh "// $license\n$copyright$note\n" if defined $fh; } for my $fh ($H, $LH) { - print $fh "/* $license */\n$copyright\n"; + print $fh "/* $license */\n$copyright$note\n"; } sub bit_def($) { -- cgit v1.2.3 From b0572a9b2397117db7d915a16928de35af08ceea Mon Sep 17 00:00:00 2001 From: Guru Das Srinagesh Date: Tue, 25 May 2021 11:02:39 -0700 Subject: dt-bindings: mfd: pm8008: Add bindings Add bindings for the Qualcomm Technologies, Inc. PM8008 MFD driver. Signed-off-by: Guru Das Srinagesh Reviewed-by: Rob Herring Signed-off-by: Lee Jones --- .../devicetree/bindings/mfd/qcom,pm8008.yaml | 121 +++++++++++++++++++++ 1 file changed, 121 insertions(+) create mode 100644 Documentation/devicetree/bindings/mfd/qcom,pm8008.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mfd/qcom,pm8008.yaml b/Documentation/devicetree/bindings/mfd/qcom,pm8008.yaml new file mode 100644 index 000000000000..779936850ee0 --- /dev/null +++ b/Documentation/devicetree/bindings/mfd/qcom,pm8008.yaml @@ -0,0 +1,121 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mfd/qcom,pm8008.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Technologies, Inc. PM8008 PMIC bindings + +maintainers: + - Guru Das Srinagesh + +description: | + Qualcomm Technologies, Inc. PM8008 is a dedicated camera PMIC that integrates + all the necessary power management, housekeeping, and interface support + functions into a single IC. + +properties: + compatible: + const: qcom,pm8008 + + reg: + description: + I2C slave address. + + maxItems: 1 + + interrupts: + maxItems: 1 + + description: Parent interrupt. + + "#interrupt-cells": + const: 2 + + description: | + The first cell is the IRQ number, the second cell is the IRQ trigger + flag. All interrupts are listed in include/dt-bindings/mfd/qcom-pm8008.h. + + interrupt-controller: true + + "#address-cells": + const: 1 + + "#size-cells": + const: 0 + +patternProperties: + "^gpio@[0-9a-f]+$": + type: object + + description: | + The GPIO peripheral. This node may be specified twice, one for each GPIO. + + properties: + compatible: + const: qcom,pm8008-gpio + + reg: + description: Peripheral address of one of the two GPIO peripherals. + maxItems: 1 + + gpio-controller: true + + interrupt-controller: true + + "#interrupt-cells": + const: 2 + + "#gpio-cells": + const: 2 + + required: + - compatible + - reg + - gpio-controller + - interrupt-controller + - "#gpio-cells" + - "#interrupt-cells" + + additionalProperties: false + +required: + - compatible + - reg + - interrupts + - "#address-cells" + - "#size-cells" + - "#interrupt-cells" + +additionalProperties: false + +examples: + - | + #include + #include + qupv3_se13_i2c { + #address-cells = <1>; + #size-cells = <0>; + pm8008i@8 { + compatible = "qcom,pm8008"; + reg = <0x8>; + #address-cells = <1>; + #size-cells = <0>; + interrupt-controller; + #interrupt-cells = <2>; + + interrupt-parent = <&tlmm>; + interrupts = <32 IRQ_TYPE_EDGE_RISING>; + + gpio@c000 { + compatible = "qcom,pm8008-gpio"; + reg = <0xc000>; + gpio-controller; + #gpio-cells = <2>; + interrupt-controller; + #interrupt-cells = <2>; + }; + }; + }; + +... -- cgit v1.2.3 From c32d7feba0b5c8a3e2867bb5def86fab986c51d7 Mon Sep 17 00:00:00 2001 From: satya priya Date: Tue, 25 May 2021 15:41:06 +0530 Subject: mfd: qcom-spmi-pmic: Add support for four variants Add support for pm8350c, pmk8350, pm7325 and pmr735a PMICS. Signed-off-by: satya priya Reviewed-by: Bjorn Andersson Signed-off-by: Lee Jones --- Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.txt | 4 ++++ 1 file changed, 4 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.txt b/Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.txt index 79367a43b27d..5ef79bf3d035 100644 --- a/Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.txt +++ b/Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.txt @@ -34,6 +34,10 @@ Required properties: "qcom,pm8998", "qcom,pmi8998", "qcom,pm8005", + "qcom,pm8350c", + "qcom,pmk8350", + "qcom,pm7325", + "qcom,pmr735a", or generalized "qcom,spmi-pmic". - reg: Specifies the SPMI USID slave address for this device. For more information see: -- cgit v1.2.3 From 00d5fa42210e23803d20e5e255f6ca80a3304875 Mon Sep 17 00:00:00 2001 From: Alexandre Torgue Date: Thu, 15 Apr 2021 12:10:28 +0200 Subject: dt-bindings: mfd: stm32-timers: Remove #address/size cells from required properties address-cells and size-cells can't be declared as "required" properties as they are not needed if subnodes don't have a "reg" entry. Signed-off-by: Alexandre Torgue Reviewed-by: Fabrice Gasnier Acked-by: Rob Herring Signed-off-by: Lee Jones --- Documentation/devicetree/bindings/mfd/st,stm32-timers.yaml | 2 -- 1 file changed, 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mfd/st,stm32-timers.yaml b/Documentation/devicetree/bindings/mfd/st,stm32-timers.yaml index 0f16c8864a87..dace35362a7a 100644 --- a/Documentation/devicetree/bindings/mfd/st,stm32-timers.yaml +++ b/Documentation/devicetree/bindings/mfd/st,stm32-timers.yaml @@ -119,8 +119,6 @@ patternProperties: - compatible required: - - "#address-cells" - - "#size-cells" - compatible - reg - clocks -- cgit v1.2.3 From d443d838f6d76c8e1acbd4e27583cb2948066f0e Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Niklas=20S=C3=B6derlund?= Date: Tue, 11 May 2021 16:23:20 +0200 Subject: media: dt-bindings: media: renesas,isp: Add bindings for ISP Channel Selector MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Add bindings for Renesas R-Car ISP Channel Selector IP. The ISP is responsible for filtering the MIPI CSI-2 bus and directing the different CSI-2 virtual channels to different R-Car VIN instances (DMA engines) for capture. Signed-off-by: Niklas Söderlund Reviewed-by: Rob Herring Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab --- .../devicetree/bindings/media/renesas,isp.yaml | 196 +++++++++++++++++++++ 1 file changed, 196 insertions(+) create mode 100644 Documentation/devicetree/bindings/media/renesas,isp.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/media/renesas,isp.yaml b/Documentation/devicetree/bindings/media/renesas,isp.yaml new file mode 100644 index 000000000000..514857d36f6b --- /dev/null +++ b/Documentation/devicetree/bindings/media/renesas,isp.yaml @@ -0,0 +1,196 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +# Copyright (C) 2021 Renesas Electronics Corp. +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/media/renesas,isp.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Renesas R-Car ISP Channel Selector + +maintainers: + - Niklas Söderlund + +description: + The R-Car ISP Channel Selector provides MIPI CSI-2 VC and DT filtering + capabilities for the Renesas R-Car family of devices. It is used in + conjunction with the R-Car VIN and CSI-2 modules, which provides the video + capture capabilities. + +properties: + compatible: + items: + - enum: + - renesas,r8a779a0-isp # V3U + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + + power-domains: + maxItems: 1 + + resets: + maxItems: 1 + + ports: + $ref: /schemas/graph.yaml#/properties/ports + + properties: + port@0: + $ref: /schemas/graph.yaml#/properties/port + description: + Input port node, multiple endpoints describing the connected R-Car + CSI-2 receivers. + + port@1: + $ref: /schemas/graph.yaml#/properties/port + description: + Single endpoint describing the R-Car VIN connected to output port 0. + + port@2: + $ref: /schemas/graph.yaml#/properties/port + description: + Single endpoint describing the R-Car VIN connected to output port 1. + + port@3: + $ref: /schemas/graph.yaml#/properties/port + description: + Single endpoint describing the R-Car VIN connected to output port 2. + + port@4: + $ref: /schemas/graph.yaml#/properties/port + description: + Single endpoint describing the R-Car VIN connected to output port 3. + + port@5: + $ref: /schemas/graph.yaml#/properties/port + description: + Single endpoint describing the R-Car VIN connected to output port 4. + + port@6: + $ref: /schemas/graph.yaml#/properties/port + description: + Single endpoint describing the R-Car VIN connected to output port 5. + + port@7: + $ref: /schemas/graph.yaml#/properties/port + description: + Single endpoint describing the R-Car VIN connected to output port 6. + + port@8: + $ref: /schemas/graph.yaml#/properties/port + description: + Single endpoint describing the R-Car VIN connected to output port 7. + + required: + - port@0 + - port@1 + - port@2 + - port@3 + - port@4 + - port@5 + - port@6 + - port@7 + - port@8 + +required: + - compatible + - reg + - interrupts + - clocks + - power-domains + - resets + - ports + +additionalProperties: false + +examples: + - | + #include + #include + #include + + isp1: isp@fed20000 { + compatible = "renesas,r8a779a0-isp"; + reg = <0xfed20000 0x10000>; + interrupts = ; + clocks = <&cpg CPG_MOD 613>; + power-domains = <&sysc R8A779A0_PD_A3ISP01>; + resets = <&cpg 613>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + #address-cells = <1>; + #size-cells = <0>; + + reg = <0>; + isp1csi41: endpoint@1 { + reg = <1>; + remote-endpoint = <&csi41isp1>; + }; + }; + + port@1 { + reg = <1>; + isp1vin08: endpoint { + remote-endpoint = <&vin08isp1>; + }; + }; + + port@2 { + reg = <2>; + isp1vin09: endpoint { + remote-endpoint = <&vin09isp1>; + }; + }; + + port@3 { + reg = <3>; + isp1vin10: endpoint { + remote-endpoint = <&vin10isp1>; + }; + }; + + port@4 { + reg = <4>; + isp1vin11: endpoint { + remote-endpoint = <&vin11isp1>; + }; + }; + + port@5 { + reg = <5>; + isp1vin12: endpoint { + remote-endpoint = <&vin12isp1>; + }; + }; + + port@6 { + reg = <6>; + isp1vin13: endpoint { + remote-endpoint = <&vin13isp1>; + }; + }; + + port@7 { + reg = <7>; + isp1vin14: endpoint { + remote-endpoint = <&vin14isp1>; + }; + }; + + port@8 { + reg = <8>; + isp1vin15: endpoint { + remote-endpoint = <&vin15isp1>; + }; + }; + }; + }; -- cgit v1.2.3 From 8f6a0eabb1f21a23a570b0986c8abe9fded3ad6f Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Niklas=20S=C3=B6derlund?= Date: Tue, 11 May 2021 16:33:32 +0200 Subject: media: dt-bindings: media: renesas,vin: Add r8a779a0 support MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Document support for the VIN module in the Renesas V3U (r8a779a0) SoC. The V3U is different from other SoCs as it have 32 instead of 8 (most of Gen3) or 16 (V3H) VIN instances. The VIN instances are also connected to a new IP the R-Car ISP Channel Selector. Signed-off-by: Niklas Söderlund Reviewed-by: Rob Herring Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab --- .../devicetree/bindings/media/renesas,vin.yaml | 26 +++++++++++++++++++++- 1 file changed, 25 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/media/renesas,vin.yaml b/Documentation/devicetree/bindings/media/renesas,vin.yaml index dd1a5ce5896c..5ba06b0f030b 100644 --- a/Documentation/devicetree/bindings/media/renesas,vin.yaml +++ b/Documentation/devicetree/bindings/media/renesas,vin.yaml @@ -51,6 +51,7 @@ properties: - renesas,vin-r8a77980 # R-Car V3H - renesas,vin-r8a77990 # R-Car E3 - renesas,vin-r8a77995 # R-Car D3 + - renesas,vin-r8a779a0 # R-Car V3U reg: maxItems: 1 @@ -111,7 +112,7 @@ properties: description: VIN channel number $ref: /schemas/types.yaml#/definitions/uint32 minimum: 0 - maximum: 15 + maximum: 31 ports: $ref: /schemas/graph.yaml#/properties/ports @@ -187,6 +188,29 @@ properties: - required: - endpoint@3 + port@2: + $ref: /schemas/graph.yaml#/properties/port + description: + Input port node, multiple endpoints describing all the R-Car ISP + modules connected the VIN. + + properties: + endpoint@0: + $ref: /schemas/graph.yaml#/properties/endpoint + description: Endpoint connected to ISP0. + + endpoint@1: + $ref: /schemas/graph.yaml#/properties/endpoint + description: Endpoint connected to ISP1. + + endpoint@2: + $ref: /schemas/graph.yaml#/properties/endpoint + description: Endpoint connected to ISP2. + + endpoint@3: + $ref: /schemas/graph.yaml#/properties/endpoint + description: Endpoint connected to ISP3. + required: - compatible - reg -- cgit v1.2.3 From 83df8dfd57be041669e6dc365caf1d5f1b2791b8 Mon Sep 17 00:00:00 2001 From: Paul Cercueil Date: Tue, 2 Mar 2021 15:42:35 +0100 Subject: media: dt-bindings: media: Document RDA5807 FM radio bindings Add documentation for the devicetree bindings of the RDA5807 FM radio I2C chip from Unisoc. Signed-off-by: Paul Cercueil Reviewed-by: Rob Herring Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab --- .../devicetree/bindings/media/i2c/rda,rda5807.yaml | 67 ++++++++++++++++++++++ 1 file changed, 67 insertions(+) create mode 100644 Documentation/devicetree/bindings/media/i2c/rda,rda5807.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/media/i2c/rda,rda5807.yaml b/Documentation/devicetree/bindings/media/i2c/rda,rda5807.yaml new file mode 100644 index 000000000000..f50e54a722eb --- /dev/null +++ b/Documentation/devicetree/bindings/media/i2c/rda,rda5807.yaml @@ -0,0 +1,67 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/media/i2c/rda,rda5807.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Unisoc Communications RDA5807 FM radio receiver + +maintainers: + - Paul Cercueil + +properties: + compatible: + enum: + - rda,rda5807 + + reg: + description: I2C address. + maxItems: 1 + + power-supply: true + + rda,lnan: + description: Use LNAN input port. + type: boolean + + rda,lnap: + description: Use LNAP input port. + type: boolean + + rda,analog-out: + description: Enable analog audio output. + type: boolean + + rda,i2s-out: + description: Enable I2S digital audio output. + type: boolean + + rda,lna-microamp: + description: LNA working current, in micro-amperes. + default: 2500 + enum: [1800, 2100, 2500, 3000] + +required: + - compatible + - reg + - power-supply + +additionalProperties: false + +examples: + - | + i2c0 { + #address-cells = <1>; + #size-cells = <0>; + + radio@11 { + compatible = "rda,rda5807"; + reg = <0x11>; + + power-supply = <&ldo6>; + + rda,lnan; + rda,lnap; + rda,analog-out; + }; + }; -- cgit v1.2.3 From 90c3493e4d9e2e1450b5d3ffd314ff350f5132a0 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Niklas=20S=C3=B6derlund?= Date: Fri, 12 Mar 2021 14:03:30 +0100 Subject: media: dt-bindings: media: renesas,vin: Add r8a77961 support MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Add the compatible string for M3-W+ (r8a77961) to the list of supported SoCs. Signed-off-by: Niklas Söderlund Acked-by: Rob Herring Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab --- Documentation/devicetree/bindings/media/renesas,vin.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/media/renesas,vin.yaml b/Documentation/devicetree/bindings/media/renesas,vin.yaml index 5ba06b0f030b..39bb6db2fb32 100644 --- a/Documentation/devicetree/bindings/media/renesas,vin.yaml +++ b/Documentation/devicetree/bindings/media/renesas,vin.yaml @@ -46,6 +46,7 @@ properties: - renesas,vin-r8a7779 # R-Car H1 - renesas,vin-r8a7795 # R-Car H3 - renesas,vin-r8a7796 # R-Car M3-W + - renesas,vin-r8a77961 # R-Car M3-W+ - renesas,vin-r8a77965 # R-Car M3-N - renesas,vin-r8a77970 # R-Car V3M - renesas,vin-r8a77980 # R-Car V3H -- cgit v1.2.3 From be6cdcf2c9c97c5a702adb95520d0268c8ecc1ae Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Niklas=20S=C3=B6derlund?= Date: Fri, 12 Mar 2021 14:04:21 +0100 Subject: media: dt-bindings: media: renesas,csi2: Add r8a77961 support MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Add the compatible string for M3-W+ (r8a77961) to the list of supported SoCs. Signed-off-by: Niklas Söderlund Acked-by: Rob Herring Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab --- Documentation/devicetree/bindings/media/renesas,csi2.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/media/renesas,csi2.yaml b/Documentation/devicetree/bindings/media/renesas,csi2.yaml index 20396f1be999..23703b767f5b 100644 --- a/Documentation/devicetree/bindings/media/renesas,csi2.yaml +++ b/Documentation/devicetree/bindings/media/renesas,csi2.yaml @@ -25,6 +25,7 @@ properties: - renesas,r8a774e1-csi2 # RZ/G2H - renesas,r8a7795-csi2 # R-Car H3 - renesas,r8a7796-csi2 # R-Car M3-W + - renesas,r8a77961-csi2 # R-Car M3-W+ - renesas,r8a77965-csi2 # R-Car M3-N - renesas,r8a77970-csi2 # R-Car V3M - renesas,r8a77980-csi2 # R-Car V3H -- cgit v1.2.3 From 513df99993857863e42bf3d7d65d87c191ce9493 Mon Sep 17 00:00:00 2001 From: Vincent Knecht Date: Fri, 28 May 2021 12:50:58 +0200 Subject: ASoC: dt-bindings: nxp,tfa989x: Add tfa9897 support Document TFA9897 bindings. Signed-off-by: Vincent Knecht Reviewed-by: Stephan Gerhold Link: https://lore.kernel.org/r/20210528105101.508254-1-vincent.knecht@mailoo.org Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/sound/nxp,tfa989x.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/nxp,tfa989x.yaml b/Documentation/devicetree/bindings/sound/nxp,tfa989x.yaml index 45db5776550c..46ddc1f3fc0c 100644 --- a/Documentation/devicetree/bindings/sound/nxp,tfa989x.yaml +++ b/Documentation/devicetree/bindings/sound/nxp,tfa989x.yaml @@ -13,6 +13,7 @@ properties: compatible: enum: - nxp,tfa9895 + - nxp,tfa9897 reg: maxItems: 1 -- cgit v1.2.3 From 9cf1a98e2b0171e2586a13197a9a1ad605336166 Mon Sep 17 00:00:00 2001 From: Vincent Knecht Date: Fri, 28 May 2021 12:51:00 +0200 Subject: ASoC: dt-bindings: nxp, tfa989x: Add vddd-supply property Add optional vddd-supply property to allow regulator control. Signed-off-by: Vincent Knecht Link: https://lore.kernel.org/r/20210528105101.508254-3-vincent.knecht@mailoo.org Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/sound/nxp,tfa989x.yaml | 3 +++ 1 file changed, 3 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/nxp,tfa989x.yaml b/Documentation/devicetree/bindings/sound/nxp,tfa989x.yaml index 46ddc1f3fc0c..ffb8fcfeb629 100644 --- a/Documentation/devicetree/bindings/sound/nxp,tfa989x.yaml +++ b/Documentation/devicetree/bindings/sound/nxp,tfa989x.yaml @@ -27,6 +27,9 @@ properties: Used as prefix for sink/source names of the component. Must be a unique string among multiple instances of the same component. + vddd-supply: + description: regulator phandle for the VDDD power supply. + required: - compatible - reg -- cgit v1.2.3 From bce18e52c866ff6ded13ac8ac37e9271f786c005 Mon Sep 17 00:00:00 2001 From: ChiYuan Huang Date: Wed, 2 Jun 2021 13:31:45 +0800 Subject: regulator: rt6160: Add DT binding document for Richtek RT6160 Add DT binding document for Richtek RT6160 voltage regulator. Signed-off-by: ChiYuan Huang Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/1622611906-2403-1-git-send-email-u0084500@gmail.com Signed-off-by: Mark Brown --- .../regulator/richtek,rt6160-regulator.yaml | 61 ++++++++++++++++++++++ 1 file changed, 61 insertions(+) create mode 100644 Documentation/devicetree/bindings/regulator/richtek,rt6160-regulator.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/regulator/richtek,rt6160-regulator.yaml b/Documentation/devicetree/bindings/regulator/richtek,rt6160-regulator.yaml new file mode 100644 index 000000000000..0534b0d68359 --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/richtek,rt6160-regulator.yaml @@ -0,0 +1,61 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/regulator/richtek,rt6160-regulator.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Richtek RT6160 BuckBoost converter + +maintainers: + - ChiYuan Huang + +description: | + The RT6160 is a high-efficiency buck-boost converter that can provide + up to 3A output current from 2025mV to 5200mV. And it support the wide + input voltage range from 2200mV to 5500mV. + + Datasheet is available at + https://www.richtek.com/assets/product_file/RT6160A/DS6160A-00.pdf + +allOf: + - $ref: regulator.yaml# + +properties: + compatible: + enum: + - richtek,rt6160 + + reg: + maxItems: 1 + + enable-gpios: + description: A connection of the 'enable' gpio line. + maxItems: 1 + + richtek,vsel-active-low: + description: | + Used to indicate the 'vsel' pin active level. if not specified, use + high active level as the default. + type: boolean + +required: + - compatible + - reg + +unevaluatedProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + rt6160@75 { + compatible = "richtek,rt6160"; + reg = <0x75>; + enable-gpios = <&gpio26 2 0>; + regulator-name = "rt6160-buckboost"; + regulator-min-microvolt = <2025000>; + regulator-max-microvolt = <5200000>; + }; + }; -- cgit v1.2.3 From 98b9c7890b2d74d2f5342ef23d12c4bcbbec54bf Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Wed, 2 Jun 2021 15:06:12 +0200 Subject: docs: admin-guide: media: ipu3.rst: replace some characters MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The conversion tools used during DocBook/LaTeX/html/Markdown->ReST conversion and some cut-and-pasted text contain some characters that aren't easily reachable on standard keyboards and/or could cause troubles when parsed by the documentation build system. Replace the occurences of the following characters: - U+201c ('“'): LEFT DOUBLE QUOTATION MARK - U+201d ('”'): RIGHT DOUBLE QUOTATION MARK Signed-off-by: Mauro Carvalho Chehab --- Documentation/admin-guide/media/ipu3.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/admin-guide/media/ipu3.rst b/Documentation/admin-guide/media/ipu3.rst index d6454f637ff4..52c1c04173da 100644 --- a/Documentation/admin-guide/media/ipu3.rst +++ b/Documentation/admin-guide/media/ipu3.rst @@ -244,7 +244,7 @@ output larger bayer frame for further YUV processing than "VIDEO" mode to get high quality images. Besides, "STILL" mode need XNR3 to do noise reduction, hence "STILL" mode will need more power and memory bandwidth than "VIDEO" mode. TNR will be enabled in "VIDEO" mode and bypassed by "STILL" mode. ImgU is -running at “VIDEO” mode by default, the user can use v4l2 control +running at "VIDEO" mode by default, the user can use v4l2 control V4L2_CID_INTEL_IPU3_MODE (currently defined in drivers/staging/media/ipu3/include/uapi/intel-ipu3.h) to query and set the running mode. For user, there is no difference for buffer queueing between the -- cgit v1.2.3 From 9df4827523bdc4032b1021395e8ee6f880d1e8b1 Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Wed, 2 Jun 2021 15:06:43 +0200 Subject: docs: driver-api: media: zoran: replace SOFT HYPHEN character MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Replace the occurences of the following character: - U+00ad ('­'): SOFT HYPHEN as ASCII HYPHEN is preferred over SOFT HYPHEN At least with some fonts, a SOFT HYPHEN is displayed as a blank space. Signed-off-by: Mauro Carvalho Chehab --- Documentation/driver-api/media/drivers/zoran.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/driver-api/media/drivers/zoran.rst b/Documentation/driver-api/media/drivers/zoran.rst index 83cbae9cedef..b205e10c3154 100644 --- a/Documentation/driver-api/media/drivers/zoran.rst +++ b/Documentation/driver-api/media/drivers/zoran.rst @@ -319,7 +319,7 @@ Conexant bt866 TV encoder ~~~~~~~~~~~~~~~~~~~~~~~~~ - is used in AVS6EYES, and -- can generate: NTSC/PAL, PAL­M, PAL­N +- can generate: NTSC/PAL, PAL-M, PAL-N The adv717x, should be able to produce PAL N. But you find nothing PAL N specific in the registers. Seem that you have to reuse a other standard -- cgit v1.2.3 From d4a84f86e9169e07595dd399c42bc7728d077531 Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Wed, 2 Jun 2021 15:12:17 +0200 Subject: docs: userspace-api: media: fdl-appendix.rst: replace some characters MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The conversion tools used during DocBook/LaTeX/html/Markdown->ReST conversion and some cut-and-pasted text contain some characters that aren't easily reachable on standard keyboards and/or could cause troubles when parsed by the documentation build system. Replace the occurences of the following characters: - U+201c ('“'): LEFT DOUBLE QUOTATION MARK - U+201d ('”'): RIGHT DOUBLE QUOTATION MARK Signed-off-by: Mauro Carvalho Chehab --- Documentation/userspace-api/media/fdl-appendix.rst | 64 +++++++++++----------- 1 file changed, 32 insertions(+), 32 deletions(-) (limited to 'Documentation') diff --git a/Documentation/userspace-api/media/fdl-appendix.rst b/Documentation/userspace-api/media/fdl-appendix.rst index 683ebed87017..b1bc725b4ec7 100644 --- a/Documentation/userspace-api/media/fdl-appendix.rst +++ b/Documentation/userspace-api/media/fdl-appendix.rst @@ -13,14 +13,14 @@ GNU Free Documentation License =========== The purpose of this License is to make a manual, textbook, or other -written document “free” in the sense of freedom: to assure everyone the +written document "free" in the sense of freedom: to assure everyone the effective freedom to copy and redistribute it, with or without modifying it, either commercially or noncommercially. Secondarily, this License preserves for the author and publisher a way to get credit for their work, while not being considered responsible for modifications made by others. -This License is a kind of “copyleft”, which means that derivative works +This License is a kind of "copyleft", which means that derivative works of the document must themselves be free in the same sense. It complements the GNU General Public License, which is a copyleft license designed for free software. @@ -44,21 +44,21 @@ works whose purpose is instruction or reference. This License applies to any manual or other work that contains a notice placed by the copyright holder saying it can be distributed under the -terms of this License. The “Document”, below, refers to any such manual +terms of this License. The "Document", below, refers to any such manual or work. Any member of the public is a licensee, and is addressed as -“you”. +"you". .. _fdl-modified: -A “Modified Version” of the Document means any work containing the +A "Modified Version" of the Document means any work containing the Document or a portion of it, either copied verbatim, or with modifications and/or translated into another language. .. _fdl-secondary: -A “Secondary Section” is a named appendix or a front-matter section of +A "Secondary Section" is a named appendix or a front-matter section of the :ref:`Document ` that deals exclusively with the relationship of the publishers or authors of the Document to the Document's overall subject (or to related matters) and contains nothing @@ -72,7 +72,7 @@ regarding them. .. _fdl-invariant: -The “Invariant Sections” are certain +The "Invariant Sections" are certain :ref:`Secondary Sections ` whose titles are designated, as being those of Invariant Sections, in the notice that says that the :ref:`Document ` is released under this License. @@ -80,14 +80,14 @@ as being those of Invariant Sections, in the notice that says that the .. _fdl-cover-texts: -The “Cover Texts” are certain short passages of text that are listed, as +The "Cover Texts" are certain short passages of text that are listed, as Front-Cover Texts or Back-Cover Texts, in the notice that says that the :ref:`Document ` is released under this License. .. _fdl-transparent: -A “Transparent” copy of the :ref:`Document ` means a +A "Transparent" copy of the :ref:`Document ` means a machine-readable copy, represented in a format whose specification is available to the general public, whose contents can be viewed and edited directly and straightforwardly with generic text editors or (for images @@ -97,7 +97,7 @@ formatters or for automatic translation to a variety of formats suitable for input to text formatters. A copy made in an otherwise Transparent file format whose markup has been designed to thwart or discourage subsequent modification by readers is not Transparent. A copy that is -not “Transparent” is called “Opaque”. +not "Transparent" is called "Opaque". Examples of suitable formats for Transparent copies include plain ASCII without markup, Texinfo input format, LaTeX input format, SGML or XML @@ -111,10 +111,10 @@ word processors for output purposes only. .. _fdl-title-page: -The “Title Page” means, for a printed book, the title page itself, plus +The "Title Page" means, for a printed book, the title page itself, plus such following pages as are needed to hold, legibly, the material this License requires to appear in the title page. For works in formats which -do not have any title page as such, “Title Page” means the text near the +do not have any title page as such, "Title Page" means the text near the most prominent appearance of the work's title, preceding the beginning of the body of the text. @@ -242,11 +242,11 @@ Modified Version: Include an unaltered copy of this License. - **I.** - Preserve the section entitled “History”, and its title, and add to it + Preserve the section entitled "History", and its title, and add to it an item stating at least the title, year, new authors, and publisher of the :ref:`Modified Version ` as given on the :ref:`Title Page `. If there is no section entitled - “History” in the :ref:`Document `, create one stating + "History" in the :ref:`Document `, create one stating the title, year, authors, and publisher of the Document as given on its Title Page, then add an item describing the Modified Version as stated in the previous sentence. @@ -256,13 +256,13 @@ Modified Version: :ref:`Document ` for public access to a :ref:`Transparent ` copy of the Document, and likewise the network locations given in the Document for previous - versions it was based on. These may be placed in the “History” + versions it was based on. These may be placed in the "History" section. You may omit a network location for a work that was published at least four years before the Document itself, or if the original publisher of the version it refers to gives permission. - **K.** - In any section entitled “Acknowledgements” or “Dedications”, preserve + In any section entitled "Acknowledgements" or "Dedications", preserve the section's title, and preserve in the section all the substance and tone of each of the contributor acknowledgements and/or dedications given therein. @@ -274,11 +274,11 @@ Modified Version: part of the section titles. - **M.** - Delete any section entitled “Endorsements”. Such a section may not be + Delete any section entitled "Endorsements". Such a section may not be included in the :ref:`Modified Version `. - **N.** - Do not retitle any existing section as “Endorsements” or to conflict + Do not retitle any existing section as "Endorsements" or to conflict in title with any :ref:`Invariant Section `. If the :ref:`Modified Version ` includes new @@ -290,7 +290,7 @@ of :ref:`Invariant Sections ` in the Modified Version's license notice. These titles must be distinct from any other section titles. -You may add a section entitled “Endorsements”, provided it contains +You may add a section entitled "Endorsements", provided it contains nothing but endorsements of your :ref:`Modified Version ` by various parties--for example, statements of peer review or that the text has been approved by @@ -337,11 +337,11 @@ the original author or publisher of that section if known, or else a unique number. Make the same adjustment to the section titles in the list of Invariant Sections in the license notice of the combined work. -In the combination, you must combine any sections entitled “History” in -the various original documents, forming one section entitled “History”; -likewise combine any sections entitled “Acknowledgements”, and any -sections entitled “Dedications”. You must delete all sections entitled -“Endorsements.” +In the combination, you must combine any sections entitled "History" in +the various original documents, forming one section entitled "History"; +likewise combine any sections entitled "Acknowledgements", and any +sections entitled "Dedications". You must delete all sections entitled +"Endorsements." .. _fdl-section6: @@ -372,7 +372,7 @@ with other separate and independent documents or works, in or on a volume of a storage or distribution medium, does not as a whole count as a :ref:`Modified Version ` of the Document, provided no compilation copyright is claimed for the compilation. Such a compilation -is called an “aggregate”, and this License does not apply to the other +is called an "aggregate", and this License does not apply to the other self-contained works thus compiled with the Document , on account of their being thus compiled, if they are not themselves derivative works of the Document. If the :ref:`Cover Text ` @@ -429,7 +429,7 @@ concerns. See Each version of the License is given a distinguishing version number. If the :ref:`Document ` specifies that a particular -numbered version of this License “or any later version” applies to it, +numbered version of this License "or any later version" applies to it, you have the option of following the terms and conditions either of that specified version or of any later version that has been published (not as a draft) by the Free Software Foundation. If the Document does not @@ -455,13 +455,13 @@ notices just after the title page: being LIST THEIR TITLES, with the :ref:`Front-Cover Texts ` being LIST, and with the :ref:`Back-Cover Texts ` being LIST. A copy - of the license is included in the section entitled “GNU Free - Documentation License”. + of the license is included in the section entitled "GNU Free + Documentation License". -If you have no :ref:`Invariant Sections `, write “with -no Invariant Sections” instead of saying which ones are invariant. If -you have no :ref:`Front-Cover Texts `, write “no -Front-Cover Texts” instead of “Front-Cover Texts being LIST”; likewise +If you have no :ref:`Invariant Sections `, write "with +no Invariant Sections" instead of saying which ones are invariant. If +you have no :ref:`Front-Cover Texts `, write "no +Front-Cover Texts" instead of "Front-Cover Texts being LIST"; likewise for :ref:`Back-Cover Texts `. If your document contains nontrivial examples of program code, we -- cgit v1.2.3 From eff7d26abc05821fd4ff32f2eef0a37cf977535b Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Wed, 2 Jun 2021 15:12:18 +0200 Subject: docs: userspace-api: media: v4l: replace some characters MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The conversion tools used during DocBook/LaTeX/html/Markdown->ReST conversion and some cut-and-pasted text contain some characters that aren't easily reachable on standard keyboards and/or could cause troubles when parsed by the documentation build system. Replace the occurences of the following characters: - U+00a0 (' '): NO-BREAK SPACE as it can cause lines being truncated on PDF output - U+2014 ('—'): EM DASH - U+2019 ('’'): RIGHT SINGLE QUOTATION MARK Note that Sphinx auto-translates '---' into EM DASH. Signed-off-by: Mauro Carvalho Chehab --- Documentation/userspace-api/media/v4l/biblio.rst | 8 ++++---- Documentation/userspace-api/media/v4l/dev-decoder.rst | 6 +++--- 2 files changed, 7 insertions(+), 7 deletions(-) (limited to 'Documentation') diff --git a/Documentation/userspace-api/media/v4l/biblio.rst b/Documentation/userspace-api/media/v4l/biblio.rst index 64d241daf63c..7b8e6738ff9e 100644 --- a/Documentation/userspace-api/media/v4l/biblio.rst +++ b/Documentation/userspace-api/media/v4l/biblio.rst @@ -51,7 +51,7 @@ ISO 13818-1 =========== -:title: ITU-T Rec. H.222.0 | ISO/IEC 13818-1 "Information technology — Generic coding of moving pictures and associated audio information: Systems" +:title: ITU-T Rec. H.222.0 | ISO/IEC 13818-1 "Information technology --- Generic coding of moving pictures and associated audio information: Systems" :author: International Telecommunication Union (http://www.itu.ch), International Organisation for Standardisation (http://www.iso.ch) @@ -61,7 +61,7 @@ ISO 13818-2 =========== -:title: ITU-T Rec. H.262 | ISO/IEC 13818-2 "Information technology — Generic coding of moving pictures and associated audio information: Video" +:title: ITU-T Rec. H.262 | ISO/IEC 13818-2 "Information technology --- Generic coding of moving pictures and associated audio information: Video" :author: International Telecommunication Union (http://www.itu.ch), International Organisation for Standardisation (http://www.iso.ch) @@ -150,7 +150,7 @@ ITU-T.81 ======== -:title: ITU-T Recommendation T.81 "Information Technology — Digital Compression and Coding of Continous-Tone Still Images — Requirements and Guidelines" +:title: ITU-T Recommendation T.81 "Information Technology --- Digital Compression and Coding of Continous-Tone Still Images --- Requirements and Guidelines" :author: International Telecommunication Union (http://www.itu.int) @@ -310,7 +310,7 @@ ISO 12232:2006 ============== -:title: Photography — Digital still cameras — Determination of exposure index, ISO speed ratings, standard output sensitivity, and recommended exposure index +:title: Photography --- Digital still cameras --- Determination of exposure index, ISO speed ratings, standard output sensitivity, and recommended exposure index :author: International Organization for Standardization (http://www.iso.org) diff --git a/Documentation/userspace-api/media/v4l/dev-decoder.rst b/Documentation/userspace-api/media/v4l/dev-decoder.rst index 3d4138a4ba69..5b9b83feeceb 100644 --- a/Documentation/userspace-api/media/v4l/dev-decoder.rst +++ b/Documentation/userspace-api/media/v4l/dev-decoder.rst @@ -38,7 +38,7 @@ Conventions and Notations Used in This Document 6. i = [a..b]: sequence of integers from a to b, inclusive, i.e. i = [0..2]: i = 0, 1, 2. -7. Given an ``OUTPUT`` buffer A, then A’ represents a buffer on the ``CAPTURE`` +7. Given an ``OUTPUT`` buffer A, then A' represents a buffer on the ``CAPTURE`` queue containing data that resulted from processing buffer A. .. _decoder-glossary: @@ -288,7 +288,7 @@ Initialization Changing the ``OUTPUT`` format may change the currently set ``CAPTURE`` format. How the new ``CAPTURE`` format is determined is up to the decoder - and the client must ensure it matches its needs afterwards. + and the client must ensure it matches its needs afterwards. 2. Allocate source (bytestream) buffers via :c:func:`VIDIOC_REQBUFS` on ``OUTPUT``. @@ -874,7 +874,7 @@ it may be affected as per normal decoder operation. any of the following results on the ``CAPTURE`` queue is allowed: - {A’, B’, G’, H’}, {A’, G’, H’}, {G’, H’}. + {A', B', G', H'}, {A', G', H'}, {G', H'}. To determine the CAPTURE buffer containing the first decoded frame after the seek, the client may observe the timestamps to match the CAPTURE and OUTPUT -- cgit v1.2.3 From c11669f738f48c7b3cf3b7ec700af33e1566d9c3 Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Wed, 2 Jun 2021 15:12:18 +0200 Subject: docs: userspace-api: media: dvb: replace some characters MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The conversion tools used during DocBook/LaTeX/html/Markdown->ReST conversion and some cut-and-pasted text contain some characters that aren't easily reachable on standard keyboards and/or could cause troubles when parsed by the documentation build system. Replace the occurences of the following characters: - U+00a0 (' '): NO-BREAK SPACE as it can cause lines being truncated on PDF output - U+2019 ('’'): RIGHT SINGLE QUOTATION MARK - U+201c ('“'): LEFT DOUBLE QUOTATION MARK - U+201d ('”'): RIGHT DOUBLE QUOTATION MARK Signed-off-by: Mauro Carvalho Chehab --- Documentation/userspace-api/media/dvb/audio-set-bypass-mode.rst | 2 +- Documentation/userspace-api/media/dvb/audio.rst | 2 +- Documentation/userspace-api/media/dvb/dmx-fopen.rst | 2 +- Documentation/userspace-api/media/dvb/dmx-fread.rst | 2 +- Documentation/userspace-api/media/dvb/dmx-set-filter.rst | 2 +- Documentation/userspace-api/media/dvb/intro.rst | 6 +++--- Documentation/userspace-api/media/dvb/video.rst | 2 +- 7 files changed, 9 insertions(+), 9 deletions(-) (limited to 'Documentation') diff --git a/Documentation/userspace-api/media/dvb/audio-set-bypass-mode.rst b/Documentation/userspace-api/media/dvb/audio-set-bypass-mode.rst index ecac02f1b2fc..80d551a2053a 100644 --- a/Documentation/userspace-api/media/dvb/audio-set-bypass-mode.rst +++ b/Documentation/userspace-api/media/dvb/audio-set-bypass-mode.rst @@ -50,7 +50,7 @@ Description This ioctl call asks the Audio Device to bypass the Audio decoder and forward the stream without decoding. This mode shall be used if streams -that can’t be handled by the Digital TV system shall be decoded. Dolby +that can't be handled by the Digital TV system shall be decoded. Dolby DigitalTM streams are automatically forwarded by the Digital TV subsystem if the hardware can handle it. diff --git a/Documentation/userspace-api/media/dvb/audio.rst b/Documentation/userspace-api/media/dvb/audio.rst index eaae5675a47d..aa753336b31f 100644 --- a/Documentation/userspace-api/media/dvb/audio.rst +++ b/Documentation/userspace-api/media/dvb/audio.rst @@ -11,7 +11,7 @@ TV hardware. It can be accessed through ``/dev/dvb/adapter?/audio?``. Data types and ioctl definitions can be accessed by including ``linux/dvb/audio.h`` in your application. -Please note that some Digital TV cards don’t have their own MPEG decoder, which +Please note that some Digital TV cards don't have their own MPEG decoder, which results in the omission of the audio and video device. These ioctls were also used by V4L2 to control MPEG decoders implemented diff --git a/Documentation/userspace-api/media/dvb/dmx-fopen.rst b/Documentation/userspace-api/media/dvb/dmx-fopen.rst index 8f0a2b831d4a..50b36eb4371e 100644 --- a/Documentation/userspace-api/media/dvb/dmx-fopen.rst +++ b/Documentation/userspace-api/media/dvb/dmx-fopen.rst @@ -82,7 +82,7 @@ appropriately. :widths: 1 16 - - ``EMFILE`` - - “Too many open files”, i.e. no more filters available. + - "Too many open files", i.e. no more filters available. The generic error codes are described at the :ref:`Generic Error Codes ` chapter. diff --git a/Documentation/userspace-api/media/dvb/dmx-fread.rst b/Documentation/userspace-api/media/dvb/dmx-fread.rst index 78e9daef595a..88c4cddf7c30 100644 --- a/Documentation/userspace-api/media/dvb/dmx-fread.rst +++ b/Documentation/userspace-api/media/dvb/dmx-fread.rst @@ -34,7 +34,7 @@ Description This system call returns filtered data, which might be section or Packetized Elementary Stream (PES) data. The filtered data is transferred from -the driver’s internal circular buffer to ``buf``. The maximum amount of data +the driver's internal circular buffer to ``buf``. The maximum amount of data to be transferred is implied by count. .. note:: diff --git a/Documentation/userspace-api/media/dvb/dmx-set-filter.rst b/Documentation/userspace-api/media/dvb/dmx-set-filter.rst index f43455b7adae..1b8c8071b14f 100644 --- a/Documentation/userspace-api/media/dvb/dmx-set-filter.rst +++ b/Documentation/userspace-api/media/dvb/dmx-set-filter.rst @@ -37,7 +37,7 @@ parameters provided. A timeout may be defined stating number of seconds to wait for a section to be loaded. A value of 0 means that no timeout should be applied. Finally there is a flag field where it is possible to state whether a section should be CRC-checked, whether the filter should -be a ”one-shot” filter, i.e. if the filtering operation should be +be a "one-shot" filter, i.e. if the filtering operation should be stopped after the first section is received, and whether the filtering operation should be started immediately (without waiting for a :ref:`DMX_START` ioctl call). If a filter was previously set-up, this diff --git a/Documentation/userspace-api/media/dvb/intro.rst b/Documentation/userspace-api/media/dvb/intro.rst index a935f3914e56..6784ae79657c 100644 --- a/Documentation/userspace-api/media/dvb/intro.rst +++ b/Documentation/userspace-api/media/dvb/intro.rst @@ -107,7 +107,7 @@ Audio and video decoder a Systems on a Chip (SoC) integrated circuit. It may also not be needed for certain usages (e.g. for data-only - uses like “internet over satellite”). + uses like "internet over satellite"). :ref:`stb_components` shows a crude schematic of the control and data flow between those components. @@ -148,9 +148,9 @@ individual devices are called: - ``/dev/dvb/adapterN/caM``, -where ``N`` enumerates the Digital TV cards in a system starting from 0, and +where ``N`` enumerates the Digital TV cards in a system starting from 0, and ``M`` enumerates the devices of each type within each adapter, starting -from 0, too. We will omit the “``/dev/dvb/adapterN/``\ ” in the further +from 0, too. We will omit the "``/dev/dvb/adapterN/``\ " in the further discussion of these devices. More details about the data structures and function calls of all the diff --git a/Documentation/userspace-api/media/dvb/video.rst b/Documentation/userspace-api/media/dvb/video.rst index 38a8d39a1d25..808705b769a1 100644 --- a/Documentation/userspace-api/media/dvb/video.rst +++ b/Documentation/userspace-api/media/dvb/video.rst @@ -16,7 +16,7 @@ stream, not its presentation on the TV or computer screen. On PCs this is typically handled by an associated video4linux device, e.g. **/dev/video**, which allows scaling and defining output windows. -Some Digital TV cards don’t have their own MPEG decoder, which results in the +Some Digital TV cards don't have their own MPEG decoder, which results in the omission of the audio and video device as well as the video4linux device. -- cgit v1.2.3 From 011ab4dffe965c16c2ba27c0b97d42d41a97b4da Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Rafa=C5=82=20Mi=C5=82ecki?= Date: Thu, 27 May 2021 22:28:15 +0200 Subject: dt-bindings: net: brcm,iproc-mdio: convert to the json-schema MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit This helps validating DTS files. Introduced changes: 1. Swapped #address-cells and #size-cells values 2. Renamed node: s/enet-gphy/ethernet-phy@/ Signed-off-by: Rafał Miłecki Signed-off-by: David S. Miller --- .../devicetree/bindings/net/brcm,iproc-mdio.txt | 23 ------------- .../devicetree/bindings/net/brcm,iproc-mdio.yaml | 38 ++++++++++++++++++++++ 2 files changed, 38 insertions(+), 23 deletions(-) delete mode 100644 Documentation/devicetree/bindings/net/brcm,iproc-mdio.txt create mode 100644 Documentation/devicetree/bindings/net/brcm,iproc-mdio.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/brcm,iproc-mdio.txt b/Documentation/devicetree/bindings/net/brcm,iproc-mdio.txt deleted file mode 100644 index 8ba9ed11d716..000000000000 --- a/Documentation/devicetree/bindings/net/brcm,iproc-mdio.txt +++ /dev/null @@ -1,23 +0,0 @@ -* Broadcom iProc MDIO bus controller - -Required properties: -- compatible: should be "brcm,iproc-mdio" -- reg: address and length of the register set for the MDIO interface -- #size-cells: must be 1 -- #address-cells: must be 0 - -Child nodes of this MDIO bus controller node are standard Ethernet PHY device -nodes as described in Documentation/devicetree/bindings/net/phy.txt - -Example: - -mdio@18002000 { - compatible = "brcm,iproc-mdio"; - reg = <0x18002000 0x8>; - #size-cells = <1>; - #address-cells = <0>; - - enet-gphy@0 { - reg = <0>; - }; -}; diff --git a/Documentation/devicetree/bindings/net/brcm,iproc-mdio.yaml b/Documentation/devicetree/bindings/net/brcm,iproc-mdio.yaml new file mode 100644 index 000000000000..3031395f7e6e --- /dev/null +++ b/Documentation/devicetree/bindings/net/brcm,iproc-mdio.yaml @@ -0,0 +1,38 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/brcm,iproc-mdio.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Broadcom iProc MDIO bus controller + +maintainers: + - Rafał Miłecki + +allOf: + - $ref: mdio.yaml# + +properties: + compatible: + const: brcm,iproc-mdio + + reg: + maxItems: 1 + +unevaluatedProperties: false + +required: + - reg + +examples: + - | + mdio@18002000 { + compatible = "brcm,iproc-mdio"; + reg = <0x18002000 0x8>; + #address-cells = <1>; + #size-cells = <0>; + + ethernet-phy@0 { + reg = <0>; + }; + }; -- cgit v1.2.3 From e9ab77a4f2aa1de5982a041ffbc1facc96ef0d40 Mon Sep 17 00:00:00 2001 From: Jonathan Cameron Date: Sat, 22 May 2021 12:29:08 +0100 Subject: dt-bindings: iio: multiplexer: Convert io-channel-mux bindings to DT schema Straight conversion of the txt file using the mux-consumer.yaml binding now that is available. Signed-off-by: Jonathan Cameron Cc: Peter Rosin [robh: Drop quotes and $ref for mux-controls] Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20210522112908.1611389-3-jic23@kernel.org --- .../bindings/iio/multiplexer/io-channel-mux.txt | 39 ------------ .../bindings/iio/multiplexer/io-channel-mux.yaml | 70 ++++++++++++++++++++++ 2 files changed, 70 insertions(+), 39 deletions(-) delete mode 100644 Documentation/devicetree/bindings/iio/multiplexer/io-channel-mux.txt create mode 100644 Documentation/devicetree/bindings/iio/multiplexer/io-channel-mux.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/iio/multiplexer/io-channel-mux.txt b/Documentation/devicetree/bindings/iio/multiplexer/io-channel-mux.txt deleted file mode 100644 index d2b3105dba67..000000000000 --- a/Documentation/devicetree/bindings/iio/multiplexer/io-channel-mux.txt +++ /dev/null @@ -1,39 +0,0 @@ -I/O channel multiplexer bindings - -If a multiplexer is used to select which hardware signal is fed to -e.g. an ADC channel, these bindings describe that situation. - -Required properties: -- compatible : "io-channel-mux" -- io-channels : Channel node of the parent channel that has multiplexed - input. -- io-channel-names : Should be "parent". -- #address-cells = <1>; -- #size-cells = <0>; -- mux-controls : Mux controller node to use for operating the mux -- channels : List of strings, labeling the mux controller states. - -For each non-empty string in the channels property, an io-channel will -be created. The number of this io-channel is the same as the index into -the list of strings in the channels property, and also matches the mux -controller state. The mux controller state is described in -../mux/mux-controller.yaml - -Example: - mux: mux-controller { - compatible = "gpio-mux"; - #mux-control-cells = <0>; - - mux-gpios = <&pioA 0 GPIO_ACTIVE_HIGH>, - <&pioA 1 GPIO_ACTIVE_HIGH>; - }; - - adc-mux { - compatible = "io-channel-mux"; - io-channels = <&adc 0>; - io-channel-names = "parent"; - - mux-controls = <&mux>; - - channels = "sync", "in", "system-regulator"; - }; diff --git a/Documentation/devicetree/bindings/iio/multiplexer/io-channel-mux.yaml b/Documentation/devicetree/bindings/iio/multiplexer/io-channel-mux.yaml new file mode 100644 index 000000000000..870b043406d8 --- /dev/null +++ b/Documentation/devicetree/bindings/iio/multiplexer/io-channel-mux.yaml @@ -0,0 +1,70 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iio/multiplexer/io-channel-mux.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: I/O channel multiplexer bindings + +maintainers: + - Peter Rosin + +description: | + If a multiplexer is used to select which hardware signal is fed to + e.g. an ADC channel, these bindings describe that situation. + + For each non-empty string in the channels property, an io-channel will be + created. The number of this io-channel is the same as the index into the list + of strings in the channels property, and also matches the mux controller + state. The mux controller state is described in + Documentation/devicetree/bindings/mux/mux-controller.yaml + +properties: + + compatible: + const: io-channel-mux + + io-channels: + maxItems: 1 + description: Channel node of the parent channel that has multiplexed input. + + io-channel-names: + const: parent + + mux-controls: true + mux-control-names: true + + channels: + $ref: /schemas/types.yaml#/definitions/string-array + description: + List of strings, labeling the mux controller states. + +required: + - compatible + - io-channels + - io-channel-names + - mux-controls + - channels + +additionalProperties: false + +examples: + - | + #include + mux: mux-controller { + compatible = "gpio-mux"; + #mux-control-cells = <0>; + + mux-gpios = <&pioA 0 GPIO_ACTIVE_HIGH>, + <&pioA 1 GPIO_ACTIVE_HIGH>; + }; + + adc-mux { + compatible = "io-channel-mux"; + io-channels = <&adc 0>; + io-channel-names = "parent"; + + mux-controls = <&mux>; + channels = "sync", "in", "system-regulator"; + }; +... -- cgit v1.2.3 From 652f2efa93c446cbf439988e77a5c788c0fb5ff4 Mon Sep 17 00:00:00 2001 From: Rob Herring Date: Wed, 26 May 2021 13:14:11 -0500 Subject: dt-bindings: net: Convert MDIO mux bindings to DT schema Convert the common MDIO mux bindings to DT schema. Drop the example from mdio-mux.yaml as mdio-mux-gpio.yaml has the same one. Cc: "David S. Miller" Cc: Jakub Kicinski Cc: Ray Jui Cc: Scott Branden Cc: bcm-kernel-feedback-list@broadcom.com Cc: Andrew Lunn Cc: Heiner Kallweit Cc: Russell King Cc: netdev@vger.kernel.org Cc: linux-arm-kernel@lists.infradead.org Reviewed-by: Andrew Lunn Link: https://lore.kernel.org/r/20210526181411.2888516-1-robh@kernel.org Signed-off-by: Rob Herring --- .../bindings/net/brcm,mdio-mux-iproc.txt | 2 +- .../devicetree/bindings/net/mdio-mux-gpio.txt | 119 ------------------ .../devicetree/bindings/net/mdio-mux-gpio.yaml | 135 +++++++++++++++++++++ .../devicetree/bindings/net/mdio-mux-mmioreg.txt | 75 ------------ .../devicetree/bindings/net/mdio-mux-mmioreg.yaml | 78 ++++++++++++ .../bindings/net/mdio-mux-multiplexer.txt | 82 ------------- .../bindings/net/mdio-mux-multiplexer.yaml | 82 +++++++++++++ Documentation/devicetree/bindings/net/mdio-mux.txt | 129 -------------------- .../devicetree/bindings/net/mdio-mux.yaml | 44 +++++++ 9 files changed, 340 insertions(+), 406 deletions(-) delete mode 100644 Documentation/devicetree/bindings/net/mdio-mux-gpio.txt create mode 100644 Documentation/devicetree/bindings/net/mdio-mux-gpio.yaml delete mode 100644 Documentation/devicetree/bindings/net/mdio-mux-mmioreg.txt create mode 100644 Documentation/devicetree/bindings/net/mdio-mux-mmioreg.yaml delete mode 100644 Documentation/devicetree/bindings/net/mdio-mux-multiplexer.txt create mode 100644 Documentation/devicetree/bindings/net/mdio-mux-multiplexer.yaml delete mode 100644 Documentation/devicetree/bindings/net/mdio-mux.txt create mode 100644 Documentation/devicetree/bindings/net/mdio-mux.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/brcm,mdio-mux-iproc.txt b/Documentation/devicetree/bindings/net/brcm,mdio-mux-iproc.txt index b58843f29591..deb9e852ea27 100644 --- a/Documentation/devicetree/bindings/net/brcm,mdio-mux-iproc.txt +++ b/Documentation/devicetree/bindings/net/brcm,mdio-mux-iproc.txt @@ -17,7 +17,7 @@ Optional properties: - clocks: phandle of the core clock which drives the mdio block. Additional information regarding generic multiplexer properties can be found -at- Documentation/devicetree/bindings/net/mdio-mux.txt +at- Documentation/devicetree/bindings/net/mdio-mux.yaml for example: diff --git a/Documentation/devicetree/bindings/net/mdio-mux-gpio.txt b/Documentation/devicetree/bindings/net/mdio-mux-gpio.txt deleted file mode 100644 index 694987d3c17a..000000000000 --- a/Documentation/devicetree/bindings/net/mdio-mux-gpio.txt +++ /dev/null @@ -1,119 +0,0 @@ -Properties for an MDIO bus multiplexer/switch controlled by GPIO pins. - -This is a special case of a MDIO bus multiplexer. One or more GPIO -lines are used to control which child bus is connected. - -Required properties in addition to the generic multiplexer properties: - -- compatible : mdio-mux-gpio. -- gpios : GPIO specifiers for each GPIO line. One or more must be specified. - - -Example : - - /* The parent MDIO bus. */ - smi1: mdio@1180000001900 { - compatible = "cavium,octeon-3860-mdio"; - #address-cells = <1>; - #size-cells = <0>; - reg = <0x11800 0x00001900 0x0 0x40>; - }; - - /* - An NXP sn74cbtlv3253 dual 1-of-4 switch controlled by a - pair of GPIO lines. Child busses 2 and 3 populated with 4 - PHYs each. - */ - mdio-mux { - compatible = "mdio-mux-gpio"; - gpios = <&gpio1 3 0>, <&gpio1 4 0>; - mdio-parent-bus = <&smi1>; - #address-cells = <1>; - #size-cells = <0>; - - mdio@2 { - reg = <2>; - #address-cells = <1>; - #size-cells = <0>; - - phy11: ethernet-phy@1 { - reg = <1>; - marvell,reg-init = <3 0x10 0 0x5777>, - <3 0x11 0 0x00aa>, - <3 0x12 0 0x4105>, - <3 0x13 0 0x0a60>; - interrupt-parent = <&gpio>; - interrupts = <10 8>; /* Pin 10, active low */ - }; - phy12: ethernet-phy@2 { - reg = <2>; - marvell,reg-init = <3 0x10 0 0x5777>, - <3 0x11 0 0x00aa>, - <3 0x12 0 0x4105>, - <3 0x13 0 0x0a60>; - interrupt-parent = <&gpio>; - interrupts = <10 8>; /* Pin 10, active low */ - }; - phy13: ethernet-phy@3 { - reg = <3>; - marvell,reg-init = <3 0x10 0 0x5777>, - <3 0x11 0 0x00aa>, - <3 0x12 0 0x4105>, - <3 0x13 0 0x0a60>; - interrupt-parent = <&gpio>; - interrupts = <10 8>; /* Pin 10, active low */ - }; - phy14: ethernet-phy@4 { - reg = <4>; - marvell,reg-init = <3 0x10 0 0x5777>, - <3 0x11 0 0x00aa>, - <3 0x12 0 0x4105>, - <3 0x13 0 0x0a60>; - interrupt-parent = <&gpio>; - interrupts = <10 8>; /* Pin 10, active low */ - }; - }; - - mdio@3 { - reg = <3>; - #address-cells = <1>; - #size-cells = <0>; - - phy21: ethernet-phy@1 { - reg = <1>; - marvell,reg-init = <3 0x10 0 0x5777>, - <3 0x11 0 0x00aa>, - <3 0x12 0 0x4105>, - <3 0x13 0 0x0a60>; - interrupt-parent = <&gpio>; - interrupts = <12 8>; /* Pin 12, active low */ - }; - phy22: ethernet-phy@2 { - reg = <2>; - marvell,reg-init = <3 0x10 0 0x5777>, - <3 0x11 0 0x00aa>, - <3 0x12 0 0x4105>, - <3 0x13 0 0x0a60>; - interrupt-parent = <&gpio>; - interrupts = <12 8>; /* Pin 12, active low */ - }; - phy23: ethernet-phy@3 { - reg = <3>; - marvell,reg-init = <3 0x10 0 0x5777>, - <3 0x11 0 0x00aa>, - <3 0x12 0 0x4105>, - <3 0x13 0 0x0a60>; - interrupt-parent = <&gpio>; - interrupts = <12 8>; /* Pin 12, active low */ - }; - phy24: ethernet-phy@4 { - reg = <4>; - marvell,reg-init = <3 0x10 0 0x5777>, - <3 0x11 0 0x00aa>, - <3 0x12 0 0x4105>, - <3 0x13 0 0x0a60>; - interrupt-parent = <&gpio>; - interrupts = <12 8>; /* Pin 12, active low */ - }; - }; - }; diff --git a/Documentation/devicetree/bindings/net/mdio-mux-gpio.yaml b/Documentation/devicetree/bindings/net/mdio-mux-gpio.yaml new file mode 100644 index 000000000000..71c25c4580ea --- /dev/null +++ b/Documentation/devicetree/bindings/net/mdio-mux-gpio.yaml @@ -0,0 +1,135 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/mdio-mux-gpio.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Properties for an MDIO bus multiplexer/switch controlled by GPIO pins. + +maintainers: + - Andrew Lunn + +description: + This is a special case of a MDIO bus multiplexer. One or more GPIO + lines are used to control which child bus is connected. + +allOf: + - $ref: /schemas/net/mdio-mux.yaml# + +properties: + compatible: + const: mdio-mux-gpio + + gpios: + description: + List of GPIOs used to control the multiplexer, least significant bit first. + minItems: 1 + maxItems: 32 + +required: + - compatible + - gpios + +unevaluatedProperties: false + +examples: + - | + /* + An NXP sn74cbtlv3253 dual 1-of-4 switch controlled by a + pair of GPIO lines. Child busses 2 and 3 populated with 4 + PHYs each. + */ + mdio-mux { + compatible = "mdio-mux-gpio"; + gpios = <&gpio1 3 0>, <&gpio1 4 0>; + mdio-parent-bus = <&smi1>; + #address-cells = <1>; + #size-cells = <0>; + + mdio@2 { + reg = <2>; + #address-cells = <1>; + #size-cells = <0>; + + ethernet-phy@1 { + reg = <1>; + marvell,reg-init = <3 0x10 0 0x5777>, + <3 0x11 0 0x00aa>, + <3 0x12 0 0x4105>, + <3 0x13 0 0x0a60>; + interrupt-parent = <&gpio>; + interrupts = <10 8>; /* Pin 10, active low */ + }; + ethernet-phy@2 { + reg = <2>; + marvell,reg-init = <3 0x10 0 0x5777>, + <3 0x11 0 0x00aa>, + <3 0x12 0 0x4105>, + <3 0x13 0 0x0a60>; + interrupt-parent = <&gpio>; + interrupts = <10 8>; /* Pin 10, active low */ + }; + ethernet-phy@3 { + reg = <3>; + marvell,reg-init = <3 0x10 0 0x5777>, + <3 0x11 0 0x00aa>, + <3 0x12 0 0x4105>, + <3 0x13 0 0x0a60>; + interrupt-parent = <&gpio>; + interrupts = <10 8>; /* Pin 10, active low */ + }; + ethernet-phy@4 { + reg = <4>; + marvell,reg-init = <3 0x10 0 0x5777>, + <3 0x11 0 0x00aa>, + <3 0x12 0 0x4105>, + <3 0x13 0 0x0a60>; + interrupt-parent = <&gpio>; + interrupts = <10 8>; /* Pin 10, active low */ + }; + }; + + mdio@3 { + reg = <3>; + #address-cells = <1>; + #size-cells = <0>; + + ethernet-phy@1 { + reg = <1>; + marvell,reg-init = <3 0x10 0 0x5777>, + <3 0x11 0 0x00aa>, + <3 0x12 0 0x4105>, + <3 0x13 0 0x0a60>; + interrupt-parent = <&gpio>; + interrupts = <12 8>; /* Pin 12, active low */ + }; + ethernet-phy@2 { + reg = <2>; + marvell,reg-init = <3 0x10 0 0x5777>, + <3 0x11 0 0x00aa>, + <3 0x12 0 0x4105>, + <3 0x13 0 0x0a60>; + interrupt-parent = <&gpio>; + interrupts = <12 8>; /* Pin 12, active low */ + }; + ethernet-phy@3 { + reg = <3>; + marvell,reg-init = <3 0x10 0 0x5777>, + <3 0x11 0 0x00aa>, + <3 0x12 0 0x4105>, + <3 0x13 0 0x0a60>; + interrupt-parent = <&gpio>; + interrupts = <12 8>; /* Pin 12, active low */ + }; + ethernet-phy@4 { + reg = <4>; + marvell,reg-init = <3 0x10 0 0x5777>, + <3 0x11 0 0x00aa>, + <3 0x12 0 0x4105>, + <3 0x13 0 0x0a60>; + interrupt-parent = <&gpio>; + interrupts = <12 8>; /* Pin 12, active low */ + }; + }; + }; +... diff --git a/Documentation/devicetree/bindings/net/mdio-mux-mmioreg.txt b/Documentation/devicetree/bindings/net/mdio-mux-mmioreg.txt deleted file mode 100644 index 065e8bdb957d..000000000000 --- a/Documentation/devicetree/bindings/net/mdio-mux-mmioreg.txt +++ /dev/null @@ -1,75 +0,0 @@ -Properties for an MDIO bus multiplexer controlled by a memory-mapped device - -This is a special case of a MDIO bus multiplexer. A memory-mapped device, -like an FPGA, is used to control which child bus is connected. The mdio-mux -node must be a child of the memory-mapped device. The driver currently only -supports devices with 8, 16 or 32-bit registers. - -Required properties in addition to the generic multiplexer properties: - -- compatible : string, must contain "mdio-mux-mmioreg" - -- reg : integer, contains the offset of the register that controls the bus - multiplexer. The size field in the 'reg' property is the size of - register, and must therefore be 1, 2, or 4. - -- mux-mask : integer, contains an eight-bit mask that specifies which - bits in the register control the actual bus multiplexer. The - 'reg' property of each child mdio-mux node must be constrained by - this mask. - -Example: - -The FPGA node defines a memory-mapped FPGA with a register space of 0x30 bytes. -For the "EMI2" MDIO bus, register 9 (BRDCFG1) controls the mux on that bus. -A bitmask of 0x6 means that bits 1 and 2 (bit 0 is lsb) are the bits on -BRDCFG1 that control the actual mux. - - /* The FPGA node */ - fpga: board-control@3,0 { - #address-cells = <1>; - #size-cells = <1>; - compatible = "fsl,p5020ds-fpga", "fsl,fpga-ngpixis"; - reg = <3 0 0x30>; - ranges = <0 3 0 0x30>; - - mdio-mux-emi2 { - compatible = "mdio-mux-mmioreg", "mdio-mux"; - mdio-parent-bus = <&xmdio0>; - #address-cells = <1>; - #size-cells = <0>; - reg = <9 1>; // BRDCFG1 - mux-mask = <0x6>; // EMI2 - - emi2_slot1: mdio@0 { // Slot 1 XAUI (FM2) - reg = <0>; - #address-cells = <1>; - #size-cells = <0>; - - phy_xgmii_slot1: ethernet-phy@0 { - compatible = "ethernet-phy-ieee802.3-c45"; - reg = <4>; - }; - }; - - emi2_slot2: mdio@2 { // Slot 2 XAUI (FM1) - reg = <2>; - #address-cells = <1>; - #size-cells = <0>; - - phy_xgmii_slot2: ethernet-phy@4 { - compatible = "ethernet-phy-ieee802.3-c45"; - reg = <0>; - }; - }; - }; - }; - - /* The parent MDIO bus. */ - xmdio0: mdio@f1000 { - #address-cells = <1>; - #size-cells = <0>; - compatible = "fsl,fman-xmdio"; - reg = <0xf1000 0x1000>; - interrupts = <100 1 0 0>; - }; diff --git a/Documentation/devicetree/bindings/net/mdio-mux-mmioreg.yaml b/Documentation/devicetree/bindings/net/mdio-mux-mmioreg.yaml new file mode 100644 index 000000000000..cf86bb0b0b62 --- /dev/null +++ b/Documentation/devicetree/bindings/net/mdio-mux-mmioreg.yaml @@ -0,0 +1,78 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/mdio-mux-mmioreg.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Properties for an MDIO bus multiplexer controlled by a memory-mapped device + +maintainers: + - Andrew Lunn + +description: |+ + This is a special case of a MDIO bus multiplexer. A memory-mapped device, + like an FPGA, is used to control which child bus is connected. The mdio-mux + node must be a child of the memory-mapped device. The driver currently only + supports devices with 8, 16 or 32-bit registers. + +allOf: + - $ref: /schemas/net/mdio-mux.yaml# + +properties: + compatible: + items: + - const: mdio-mux-mmioreg + - const: mdio-mux + + reg: + description: Contains the offset of the register that controls the bus + multiplexer. The size field in the 'reg' property is the size of register, + and must therefore be 1, 2, or 4. + maxItems: 1 + + mux-mask: + $ref: /schemas/types.yaml#/definitions/uint32 + description: Contains an eight-bit mask that specifies which bits in the + register control the actual bus multiplexer. The 'reg' property of each + child mdio-mux node must be constrained by this mask. + +required: + - compatible + - reg + - mux-mask + +unevaluatedProperties: false + +examples: + - | + mdio-mux@9 { + compatible = "mdio-mux-mmioreg", "mdio-mux"; + mdio-parent-bus = <&xmdio0>; + #address-cells = <1>; + #size-cells = <0>; + reg = <9 1>; // BRDCFG1 + mux-mask = <0x6>; // EMI2 + + mdio@0 { // Slot 1 XAUI (FM2) + reg = <0>; + #address-cells = <1>; + #size-cells = <0>; + + phy_xgmii_slot1: ethernet-phy@4 { + compatible = "ethernet-phy-ieee802.3-c45"; + reg = <4>; + }; + }; + + mdio@2 { // Slot 2 XAUI (FM1) + reg = <2>; + #address-cells = <1>; + #size-cells = <0>; + + ethernet-phy@4 { + compatible = "ethernet-phy-ieee802.3-c45"; + reg = <4>; + }; + }; + }; +... diff --git a/Documentation/devicetree/bindings/net/mdio-mux-multiplexer.txt b/Documentation/devicetree/bindings/net/mdio-mux-multiplexer.txt deleted file mode 100644 index 87fd0b4f654f..000000000000 --- a/Documentation/devicetree/bindings/net/mdio-mux-multiplexer.txt +++ /dev/null @@ -1,82 +0,0 @@ -Properties for an MDIO bus multiplexer consumer device - -This is a special case of MDIO mux when MDIO mux is defined as a consumer -of a mux producer device. The mux producer can be of any type like mmio mux -producer, gpio mux producer or generic register based mux producer. - -Required properties in addition to the MDIO Bus multiplexer properties: - -- compatible : should be "mmio-mux-multiplexer" -- mux-controls : mux controller node to use for operating the mux -- mdio-parent-bus : phandle to the parent MDIO bus. - -each child node of mdio bus multiplexer consumer device represent a mdio -bus. - -for more information please refer -Documentation/devicetree/bindings/mux/mux-controller.yaml -and Documentation/devicetree/bindings/net/mdio-mux.txt - -Example: -In below example the Mux producer and consumer are separate nodes. - -&i2c0 { - fpga@66 { // fpga connected to i2c - compatible = "fsl,lx2160aqds-fpga", "fsl,fpga-qixis-i2c", - "simple-mfd"; - reg = <0x66>; - - mux: mux-controller { // Mux Producer - compatible = "reg-mux"; - #mux-control-cells = <1>; - mux-reg-masks = <0x54 0xf8>, /* 0: reg 0x54, bits 7:3 */ - <0x54 0x07>; /* 1: reg 0x54, bits 2:0 */ - }; - }; -}; - -mdio-mux-1 { // Mux consumer - compatible = "mdio-mux-multiplexer"; - mux-controls = <&mux 0>; - mdio-parent-bus = <&emdio1>; - #address-cells = <1>; - #size-cells = <0>; - - mdio@0 { - reg = <0x0>; - #address-cells = <1>; - #size-cells = <0>; - }; - - mdio@8 { - reg = <0x8>; - #address-cells = <1>; - #size-cells = <0>; - }; - - .. - .. -}; - -mdio-mux-2 { // Mux consumer - compatible = "mdio-mux-multiplexer"; - mux-controls = <&mux 1>; - mdio-parent-bus = <&emdio2>; - #address-cells = <1>; - #size-cells = <0>; - - mdio@0 { - reg = <0x0>; - #address-cells = <1>; - #size-cells = <0>; - }; - - mdio@1 { - reg = <0x1>; - #address-cells = <1>; - #size-cells = <0>; - }; - - .. - .. -}; diff --git a/Documentation/devicetree/bindings/net/mdio-mux-multiplexer.yaml b/Documentation/devicetree/bindings/net/mdio-mux-multiplexer.yaml new file mode 100644 index 000000000000..282987074ee4 --- /dev/null +++ b/Documentation/devicetree/bindings/net/mdio-mux-multiplexer.yaml @@ -0,0 +1,82 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/mdio-mux-multiplexer.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Properties for an MDIO bus multiplexer consumer device + +maintainers: + - Andrew Lunn + +description: |+ + This is a special case of MDIO mux when MDIO mux is defined as a consumer + of a mux producer device. The mux producer can be of any type like mmio mux + producer, gpio mux producer or generic register based mux producer. + + +allOf: + - $ref: /schemas/net/mdio-mux.yaml# + +properties: + compatible: + const: mdio-mux-multiplexer + + mux-controls: + maxItems: 1 + +required: + - compatible + - mux-controls + +unevaluatedProperties: false + +examples: + - | + mux: mux-controller { // Mux Producer + compatible = "reg-mux"; + #mux-control-cells = <1>; + mux-reg-masks = <0x54 0xf8>, /* 0: reg 0x54, bits 7:3 */ + <0x54 0x07>; /* 1: reg 0x54, bits 2:0 */ + }; + + mdio-mux-1 { // Mux consumer + compatible = "mdio-mux-multiplexer"; + mux-controls = <&mux 0>; + mdio-parent-bus = <&emdio1>; + #address-cells = <1>; + #size-cells = <0>; + + mdio@0 { + reg = <0x0>; + #address-cells = <1>; + #size-cells = <0>; + }; + + mdio@8 { + reg = <0x8>; + #address-cells = <1>; + #size-cells = <0>; + }; + }; + + mdio-mux-2 { // Mux consumer + compatible = "mdio-mux-multiplexer"; + mux-controls = <&mux 1>; + mdio-parent-bus = <&emdio2>; + #address-cells = <1>; + #size-cells = <0>; + + mdio@0 { + reg = <0x0>; + #address-cells = <1>; + #size-cells = <0>; + }; + + mdio@1 { + reg = <0x1>; + #address-cells = <1>; + #size-cells = <0>; + }; + }; +... diff --git a/Documentation/devicetree/bindings/net/mdio-mux.txt b/Documentation/devicetree/bindings/net/mdio-mux.txt deleted file mode 100644 index f58571f36570..000000000000 --- a/Documentation/devicetree/bindings/net/mdio-mux.txt +++ /dev/null @@ -1,129 +0,0 @@ -Common MDIO bus multiplexer/switch properties. - -An MDIO bus multiplexer/switch will have several child busses that are -numbered uniquely in a device dependent manner. The nodes for an MDIO -bus multiplexer/switch will have one child node for each child bus. - -Required properties: -- #address-cells = <1>; -- #size-cells = <0>; - -Optional properties: -- mdio-parent-bus : phandle to the parent MDIO bus. - -- Other properties specific to the multiplexer/switch hardware. - -Required properties for child nodes: -- #address-cells = <1>; -- #size-cells = <0>; -- reg : The sub-bus number. - - -Example : - - /* The parent MDIO bus. */ - smi1: mdio@1180000001900 { - compatible = "cavium,octeon-3860-mdio"; - #address-cells = <1>; - #size-cells = <0>; - reg = <0x11800 0x00001900 0x0 0x40>; - }; - - /* - An NXP sn74cbtlv3253 dual 1-of-4 switch controlled by a - pair of GPIO lines. Child busses 2 and 3 populated with 4 - PHYs each. - */ - mdio-mux { - compatible = "mdio-mux-gpio"; - gpios = <&gpio1 3 0>, <&gpio1 4 0>; - mdio-parent-bus = <&smi1>; - #address-cells = <1>; - #size-cells = <0>; - - mdio@2 { - reg = <2>; - #address-cells = <1>; - #size-cells = <0>; - - phy11: ethernet-phy@1 { - reg = <1>; - marvell,reg-init = <3 0x10 0 0x5777>, - <3 0x11 0 0x00aa>, - <3 0x12 0 0x4105>, - <3 0x13 0 0x0a60>; - interrupt-parent = <&gpio>; - interrupts = <10 8>; /* Pin 10, active low */ - }; - phy12: ethernet-phy@2 { - reg = <2>; - marvell,reg-init = <3 0x10 0 0x5777>, - <3 0x11 0 0x00aa>, - <3 0x12 0 0x4105>, - <3 0x13 0 0x0a60>; - interrupt-parent = <&gpio>; - interrupts = <10 8>; /* Pin 10, active low */ - }; - phy13: ethernet-phy@3 { - reg = <3>; - marvell,reg-init = <3 0x10 0 0x5777>, - <3 0x11 0 0x00aa>, - <3 0x12 0 0x4105>, - <3 0x13 0 0x0a60>; - interrupt-parent = <&gpio>; - interrupts = <10 8>; /* Pin 10, active low */ - }; - phy14: ethernet-phy@4 { - reg = <4>; - marvell,reg-init = <3 0x10 0 0x5777>, - <3 0x11 0 0x00aa>, - <3 0x12 0 0x4105>, - <3 0x13 0 0x0a60>; - interrupt-parent = <&gpio>; - interrupts = <10 8>; /* Pin 10, active low */ - }; - }; - - mdio@3 { - reg = <3>; - #address-cells = <1>; - #size-cells = <0>; - - phy21: ethernet-phy@1 { - reg = <1>; - marvell,reg-init = <3 0x10 0 0x5777>, - <3 0x11 0 0x00aa>, - <3 0x12 0 0x4105>, - <3 0x13 0 0x0a60>; - interrupt-parent = <&gpio>; - interrupts = <12 8>; /* Pin 12, active low */ - }; - phy22: ethernet-phy@2 { - reg = <2>; - marvell,reg-init = <3 0x10 0 0x5777>, - <3 0x11 0 0x00aa>, - <3 0x12 0 0x4105>, - <3 0x13 0 0x0a60>; - interrupt-parent = <&gpio>; - interrupts = <12 8>; /* Pin 12, active low */ - }; - phy23: ethernet-phy@3 { - reg = <3>; - marvell,reg-init = <3 0x10 0 0x5777>, - <3 0x11 0 0x00aa>, - <3 0x12 0 0x4105>, - <3 0x13 0 0x0a60>; - interrupt-parent = <&gpio>; - interrupts = <12 8>; /* Pin 12, active low */ - }; - phy24: ethernet-phy@4 { - reg = <4>; - marvell,reg-init = <3 0x10 0 0x5777>, - <3 0x11 0 0x00aa>, - <3 0x12 0 0x4105>, - <3 0x13 0 0x0a60>; - interrupt-parent = <&gpio>; - interrupts = <12 8>; /* Pin 12, active low */ - }; - }; - }; diff --git a/Documentation/devicetree/bindings/net/mdio-mux.yaml b/Documentation/devicetree/bindings/net/mdio-mux.yaml new file mode 100644 index 000000000000..d169adf5d9f4 --- /dev/null +++ b/Documentation/devicetree/bindings/net/mdio-mux.yaml @@ -0,0 +1,44 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/mdio-mux.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Common MDIO bus multiplexer/switch properties. + +maintainers: + - Andrew Lunn + +description: |+ + An MDIO bus multiplexer/switch will have several child busses that are + numbered uniquely in a device dependent manner. The nodes for an MDIO + bus multiplexer/switch will have one child node for each child bus. + +properties: + $nodename: + pattern: '^mdio-mux[\-@]?' + + mdio-parent-bus: + $ref: /schemas/types.yaml#/definitions/phandle + description: + The phandle of the MDIO bus that this multiplexer's master-side port is + connected to. + + '#address-cells': + const: 1 + + '#size-cells': + const: 0 + +patternProperties: + '^mdio@[0-9a-f]+$': + type: object + + properties: + reg: + maxItems: 1 + description: The sub-bus number. + +additionalProperties: true + +... -- cgit v1.2.3 From 1ae5a3d52f95247b5233e0e3c01a198883f7ab3e Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Wed, 26 May 2021 12:27:50 -0400 Subject: dt-bindings: arm: intel,keembay: limit the dtschema to root node The check for the board compatible should be limited only to the root node. Any other nodes with such compatible are not part of this schema and should not match. Signed-off-by: Krzysztof Kozlowski Acked-by: Daniele Alessandrelli Link: https://lore.kernel.org/r/20210526162750.135139-1-krzysztof.kozlowski@canonical.com Signed-off-by: Rob Herring --- Documentation/devicetree/bindings/arm/intel,keembay.yaml | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/intel,keembay.yaml b/Documentation/devicetree/bindings/arm/intel,keembay.yaml index 69cd30872928..107e686ab207 100644 --- a/Documentation/devicetree/bindings/arm/intel,keembay.yaml +++ b/Documentation/devicetree/bindings/arm/intel,keembay.yaml @@ -11,6 +11,8 @@ maintainers: - Daniele Alessandrelli properties: + $nodename: + const: '/' compatible: items: - enum: -- cgit v1.2.3 From 4071883fd8f386fa070cf82b30909ea5ddd7dcf9 Mon Sep 17 00:00:00 2001 From: Drew Fustini Date: Mon, 31 May 2021 00:04:18 -0700 Subject: dt-bindings: add StarFive Technology Co. Ltd. Add vendor prefix for StarFive Technology Co. Ltd [1]. StarFive was formed in 2018 and has now produced their first SoC, the JH7100, which contains 64-bit RISC-V cores [2]. It used in the BeagleV Starlight [3]. [1] https://starfivetech.com/site/company [2] https://github.com/starfive-tech/beaglev_doc [3] https://github.com/beagleboard/beaglev-starlight Signed-off-by: Drew Fustini Link: https://lore.kernel.org/r/20210531070415.269667-1-drew@beagleboard.org Signed-off-by: Rob Herring --- Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index 92fa427d2a80..b547d4ddf09c 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -1087,6 +1087,8 @@ patternProperties: (formerly part of MStar Semiconductor, Inc.) "^st,.*": description: STMicroelectronics + "^starfive,.*": + description: StarFive Technology Co. Ltd. "^starry,.*": description: Starry Electronic Technology (ShenZhen) Co., LTD "^startek,.*": -- cgit v1.2.3 From b62767e7bab3a397166a2fa36b409e5e2859f100 Mon Sep 17 00:00:00 2001 From: Dmytro Linkin Date: Wed, 2 Jun 2021 15:17:31 +0300 Subject: Documentation: devlink rate objects Add devlink rate objects section at devlink port documentation. Add devlink rate support info at netdevsim devlink documentation. Signed-off-by: Dmytro Linkin Reviewed-by: Jiri Pirko Signed-off-by: David S. Miller --- Documentation/networking/devlink/devlink-port.rst | 35 +++++++++++++++++++++++ Documentation/networking/devlink/netdevsim.rst | 26 +++++++++++++++++ 2 files changed, 61 insertions(+) (limited to 'Documentation') diff --git a/Documentation/networking/devlink/devlink-port.rst b/Documentation/networking/devlink/devlink-port.rst index ab790e7980b8..7627b1da01f2 100644 --- a/Documentation/networking/devlink/devlink-port.rst +++ b/Documentation/networking/devlink/devlink-port.rst @@ -164,6 +164,41 @@ device to instantiate the subfunction device on particular PCI function. A subfunction device is created on the :ref:`Documentation/driver-api/auxiliary_bus.rst `. At this point a matching subfunction driver binds to the subfunction's auxiliary device. +Rate object management +====================== + +Devlink provides API to manage tx rates of single devlink port or a group. +This is done through rate objects, which can be one of the two types: + +``leaf`` + Represents a single devlink port; created/destroyed by the driver. Since leaf + have 1to1 mapping to its devlink port, in user space it is referred as + ``pci//``; + +``node`` + Represents a group of rate objects (leafs and/or nodes); created/deleted by + request from the userspace; initially empty (no rate objects added). In + userspace it is referred as ``pci//``, where + ``node_name`` can be any identifier, except decimal number, to avoid + collisions with leafs. + +API allows to configure following rate object's parameters: + +``tx_share`` + Minimum TX rate value shared among all other rate objects, or rate objects + that parts of the parent group, if it is a part of the same group. + +``tx_max`` + Maximum TX rate value. + +``parent`` + Parent node name. Parent node rate limits are considered as additional limits + to all node children limits. ``tx_max`` is an upper limit for children. + ``tx_share`` is a total bandwidth distributed among children. + +Driver implementations are allowed to support both or either rate object types +and setting methods of their parameters. + Terms and Definitions ===================== diff --git a/Documentation/networking/devlink/netdevsim.rst b/Documentation/networking/devlink/netdevsim.rst index 02c2d20dc673..8a292fb5aaea 100644 --- a/Documentation/networking/devlink/netdevsim.rst +++ b/Documentation/networking/devlink/netdevsim.rst @@ -57,6 +57,32 @@ entries, FIB rule entries and nexthops that the driver will allow. $ devlink resource set netdevsim/netdevsim0 path /nexthops size 16 $ devlink dev reload netdevsim/netdevsim0 +Rate objects +============ + +The ``netdevsim`` driver supports rate objects management, which includes: + +- registerging/unregistering leaf rate objects per VF devlink port; +- creation/deletion node rate objects; +- setting tx_share and tx_max rate values for any rate object type; +- setting parent node for any rate object type. + +Rate nodes and it's parameters are exposed in ``netdevsim`` debugfs in RO mode. +For example created rate node with name ``some_group``: + +.. code:: shell + + $ ls /sys/kernel/debug/netdevsim/netdevsim0/rate_groups/some_group + rate_parent tx_max tx_share + +Same parameters are exposed for leaf objects in corresponding ports directories. +For ex.: + +.. code:: shell + + $ ls /sys/kernel/debug/netdevsim/netdevsim0/ports/1 + dev ethtool rate_parent tx_max tx_share + Driver-specific Traps ===================== -- cgit v1.2.3 From 8314b6732ae4e600bb933e108f96ce0176acb09c Mon Sep 17 00:00:00 2001 From: Roberto Sassu Date: Tue, 1 Jun 2021 10:23:38 +0200 Subject: ima: Define new template fields xattrnames, xattrlengths and xattrvalues This patch defines the new template fields xattrnames, xattrlengths and xattrvalues, which contain respectively a list of xattr names (strings, separated by |), lengths (u32, hex) and values (hex). If an xattr is not present, the name and length are not displayed in the measurement list. Reported-by: kernel test robot (Missing prototype def) Signed-off-by: Roberto Sassu Signed-off-by: Mimi Zohar --- Documentation/security/IMA-templates.rst | 4 ++++ 1 file changed, 4 insertions(+) (limited to 'Documentation') diff --git a/Documentation/security/IMA-templates.rst b/Documentation/security/IMA-templates.rst index 65c1ce451d08..6a58760a0a35 100644 --- a/Documentation/security/IMA-templates.rst +++ b/Documentation/security/IMA-templates.rst @@ -78,6 +78,10 @@ descriptors by adding their identifier to the format string - 'iuid': the inode UID; - 'igid': the inode GID; - 'imode': the inode mode; + - 'xattrnames': a list of xattr names (separated by |), only if the xattr is + present; + - 'xattrlengths': a list of xattr lengths (u32), only if the xattr is present; + - 'xattrvalues': a list of xattr values; Below, there is the list of defined template descriptors: -- cgit v1.2.3 From fa0cf568fd76550c1ddb806c03a65a1a4a1ea909 Mon Sep 17 00:00:00 2001 From: Shiraz Saleem Date: Wed, 2 Jun 2021 15:51:37 -0500 Subject: RDMA/irdma: Add irdma Kconfig/Makefile and remove i40iw Add Kconfig and Makefile to build irdma driver. Remove i40iw driver and add an alias in irdma. Remove legacy exported symbols i40e_register_client and i40e_unregister_client from i40e as they are no longer used. irdma is the replacement driver that supports X722. Link: https://lore.kernel.org/r/20210602205138.889-16-shiraz.saleem@intel.com Signed-off-by: Shiraz Saleem Signed-off-by: Jason Gunthorpe --- Documentation/ABI/stable/sysfs-class-infiniband | 20 -------------------- 1 file changed, 20 deletions(-) (limited to 'Documentation') diff --git a/Documentation/ABI/stable/sysfs-class-infiniband b/Documentation/ABI/stable/sysfs-class-infiniband index 348c4ac803ad..9b1bdfa43354 100644 --- a/Documentation/ABI/stable/sysfs-class-infiniband +++ b/Documentation/ABI/stable/sysfs-class-infiniband @@ -731,26 +731,6 @@ Description: is the irq number of "sdma3", and M is irq number of "sdma4" in the /proc/interrupts file. - -sysfs interface for Intel(R) X722 iWARP i40iw driver ----------------------------------------------------- - -What: /sys/class/infiniband/i40iwX/hw_rev -What: /sys/class/infiniband/i40iwX/hca_type -What: /sys/class/infiniband/i40iwX/board_id -Date: Jan, 2016 -KernelVersion: v4.10 -Contact: linux-rdma@vger.kernel.org -Description: - =============== ==== ======================== - hw_rev: (RO) Hardware revision number - - hca_type: (RO) Show HCA type (I40IW) - - board_id: (RO) I40IW board ID - =============== ==== ======================== - - sysfs interface for QLogic qedr NIC Driver ------------------------------------------ -- cgit v1.2.3 From ed21e4cd291a6dd2fe62978b55b65a7e5d54f3a6 Mon Sep 17 00:00:00 2001 From: Suman Anna Date: Thu, 20 May 2021 18:43:48 -0500 Subject: dt-bindings: mailbox: Convert omap-mailbox.txt binding to YAML Convert the current OMAP Mailbox binding from text format to YAML format/DT schema, and delete the legacy text binding file. The new YAML binding conversion is an updated version compared to the original. The descriptions for certain properties have been improved to provide more clarity. Constraints are added to the properties 'ti,mbox-num-users', 'ti,mbox-num-fifos' and 'interrupts'. The 'ti,hwmods' is a legacy property and is retained only to reflect the existing usage on some older OMAP2 and OMAP3 platforms. All the existing examples have also been updated to reflect the latest dts nodes (ti,hwmods removed from OMAP4 and AM33xx examples, and interrupts value updated for AM65x SoCs). Signed-off-by: Suman Anna [robh: Update ref in ti,omap-remoteproc.yaml] Link: https://lore.kernel.org/r/20210520234348.4479-1-s-anna@ti.com Signed-off-by: Rob Herring --- .../devicetree/bindings/mailbox/omap-mailbox.txt | 184 ------------ .../bindings/mailbox/ti,omap-mailbox.yaml | 308 +++++++++++++++++++++ .../bindings/remoteproc/ti,omap-remoteproc.yaml | 2 +- 3 files changed, 309 insertions(+), 185 deletions(-) delete mode 100644 Documentation/devicetree/bindings/mailbox/omap-mailbox.txt create mode 100644 Documentation/devicetree/bindings/mailbox/ti,omap-mailbox.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mailbox/omap-mailbox.txt b/Documentation/devicetree/bindings/mailbox/omap-mailbox.txt deleted file mode 100644 index 12371f5c6cd9..000000000000 --- a/Documentation/devicetree/bindings/mailbox/omap-mailbox.txt +++ /dev/null @@ -1,184 +0,0 @@ -OMAP2+ and K3 Mailbox -===================== - -The OMAP mailbox hardware facilitates communication between different processors -using a queued mailbox interrupt mechanism. The IP block is external to the -various processor subsystems and is connected on an interconnect bus. The -communication is achieved through a set of registers for message storage and -interrupt configuration registers. - -Each mailbox IP block/cluster has a certain number of h/w fifo queues and output -interrupt lines. An output interrupt line is routed to an interrupt controller -within a processor subsystem, and there can be more than one line going to a -specific processor's interrupt controller. The interrupt line connections are -fixed for an instance and are dictated by the IP integration into the SoC -(excluding the SoCs that have a Interrupt Crossbar IP). Each interrupt line is -programmable through a set of interrupt configuration registers, and have a rx -and tx interrupt source per h/w fifo. Communication between different processors -is achieved through the appropriate programming of the rx and tx interrupt -sources on the appropriate interrupt lines. - -The number of h/w fifo queues and interrupt lines dictate the usable registers. -All the current OMAP SoCs except for the newest DRA7xx SoC has a single IP -instance. DRA7xx has multiple instances with different number of h/w fifo queues -and interrupt lines between different instances. The interrupt lines can also be -routed to different processor sub-systems on DRA7xx as they are routed through -the Crossbar, a kind of interrupt router/multiplexer. The K3 AM65x and J721E -SoCs has each of these instances form a cluster and combine multiple clusters -into a single IP block present within the Main NavSS. The interrupt lines from -all these clusters are multiplexed and routed to different processor subsystems -over a limited number of common interrupt output lines of an Interrupt Router. -The AM64x SoCS also uses a single IP block comprising of multiple clusters, -but the number of clusters are smaller, and the interrupt output lines are -connected directly to various processors. - -Mailbox Device Node: -==================== -A Mailbox device node is used to represent a Mailbox IP instance/cluster within -a SoC. The sub-mailboxes are represented as child nodes of this parent node. - -Required properties: --------------------- -- compatible: Should be one of the following, - "ti,omap2-mailbox" for OMAP2420, OMAP2430 SoCs - "ti,omap3-mailbox" for OMAP3430, OMAP3630 SoCs - "ti,omap4-mailbox" for OMAP44xx, OMAP54xx, AM33xx, - AM43xx and DRA7xx SoCs - "ti,am654-mailbox" for K3 AM65x and J721E SoCs - "ti,am64-mailbox" for K3 AM64x SoCs -- reg: Contains the mailbox register address range (base - address and length) -- interrupts: Contains the interrupt information for the mailbox - device. The format is dependent on which interrupt - controller the Mailbox device uses -- #mbox-cells: Common mailbox binding property to identify the number - of cells required for the mailbox specifier. Should be - 1 -- ti,mbox-num-users: Number of targets (processor devices) that the mailbox - device can interrupt -- ti,mbox-num-fifos: Number of h/w fifo queues within the mailbox IP block - -SoC-specific Required properties: ---------------------------------- -The following are mandatory properties for the OMAP architecture based SoCs -only: -- ti,hwmods: Name of the hwmod associated with the mailbox. This - should be defined in the mailbox node only if the node - is not defined as a child node of a corresponding sysc - interconnect node. - -The following are mandatory properties for the K3 AM65x and J721E SoCs only: -- interrupt-parent: Should contain a phandle to the TI-SCI interrupt - controller node that is used to dynamically program - the interrupt routes between the IP and the main GIC - controllers. See the following binding for additional - details, - Documentation/devicetree/bindings/interrupt-controller/ti,sci-intr.yaml - -Child Nodes: -============ -A child node is used for representing the actual sub-mailbox device that is -used for the communication between the host processor and a remote processor. -Each child node should have a unique node name across all the different -mailbox device nodes. - -Required properties: --------------------- -- ti,mbox-tx: sub-mailbox descriptor property defining a Tx fifo -- ti,mbox-rx: sub-mailbox descriptor property defining a Rx fifo - -Sub-mailbox Descriptor Data ---------------------------- -Each of the above ti,mbox-tx and ti,mbox-rx properties should have 3 cells of -data that represent the following: - Cell #1 (fifo_id) - mailbox fifo id used either for transmitting - (ti,mbox-tx) or for receiving (ti,mbox-rx) - Cell #2 (irq_id) - irq identifier index number to use from the parent's - interrupts data. Should be 0 for most of the cases, a - positive index value is seen only on mailboxes that have - multiple interrupt lines connected to the MPU processor. - Cell #3 (usr_id) - mailbox user id for identifying the interrupt line - associated with generating a tx/rx fifo interrupt. - -Optional Properties: --------------------- -- ti,mbox-send-noirq: Quirk flag to allow the client user of this sub-mailbox - to send messages without triggering a Tx ready interrupt, - and to control the Tx ticker. Should be used only on - sub-mailboxes used to communicate with WkupM3 remote - processor on AM33xx/AM43xx SoCs. - -Mailbox Users: -============== -A device needing to communicate with a target processor device should specify -them using the common mailbox binding properties, "mboxes" and the optional -"mbox-names" (please see Documentation/devicetree/bindings/mailbox/mailbox.txt -for details). Each value of the mboxes property should contain a phandle to the -mailbox controller device node and an args specifier that will be the phandle to -the intended sub-mailbox child node to be used for communication. The equivalent -"mbox-names" property value can be used to give a name to the communication channel -to be used by the client user. - - -Example: --------- - -1. /* OMAP4 */ -mailbox: mailbox@4a0f4000 { - compatible = "ti,omap4-mailbox"; - reg = <0x4a0f4000 0x200>; - interrupts = ; - ti,hwmods = "mailbox"; - #mbox-cells = <1>; - ti,mbox-num-users = <3>; - ti,mbox-num-fifos = <8>; - mbox_ipu: mbox_ipu { - ti,mbox-tx = <0 0 0>; - ti,mbox-rx = <1 0 0>; - }; - mbox_dsp: mbox_dsp { - ti,mbox-tx = <3 0 0>; - ti,mbox-rx = <2 0 0>; - }; -}; - -dsp { - ... - mboxes = <&mailbox &mbox_dsp>; - ... -}; - -2. /* AM33xx */ -mailbox: mailbox@480c8000 { - compatible = "ti,omap4-mailbox"; - reg = <0x480C8000 0x200>; - interrupts = <77>; - ti,hwmods = "mailbox"; - #mbox-cells = <1>; - ti,mbox-num-users = <4>; - ti,mbox-num-fifos = <8>; - mbox_wkupm3: wkup_m3 { - ti,mbox-tx = <0 0 0>; - ti,mbox-rx = <0 0 3>; - }; -}; - -3. /* AM65x */ -&cbass_main { - cbass_main_navss: interconnect0 { - mailbox0_cluster0: mailbox@31f80000 { - compatible = "ti,am654-mailbox"; - reg = <0x00 0x31f80000 0x00 0x200>; - #mbox-cells = <1>; - ti,mbox-num-users = <4>; - ti,mbox-num-fifos = <16>; - interrupt-parent = <&intr_main_navss>; - interrupts = <164 0>; - - mbox_mcu_r5fss0_core0: mbox-mcu-r5fss0-core0 { - ti,mbox-tx = <1 0 0>; - ti,mbox-rx = <0 0 0>; - }; - }; - }; -}; diff --git a/Documentation/devicetree/bindings/mailbox/ti,omap-mailbox.yaml b/Documentation/devicetree/bindings/mailbox/ti,omap-mailbox.yaml new file mode 100644 index 000000000000..e864d798168d --- /dev/null +++ b/Documentation/devicetree/bindings/mailbox/ti,omap-mailbox.yaml @@ -0,0 +1,308 @@ +# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mailbox/ti,omap-mailbox.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: TI OMAP2+ and K3 Mailbox devices + +maintainers: + - Suman Anna + +description: | + The OMAP Mailbox hardware facilitates communication between different + processors using a queued mailbox interrupt mechanism. The IP block is + external to the various processor subsystems and is connected on an + interconnect bus. The communication is achieved through a set of registers + for message storage and interrupt configuration registers. + + Each mailbox IP block/cluster has a certain number of h/w fifo queues and + output interrupt lines. An output interrupt line is routed to an interrupt + controller within a processor subsystem, and there can be more than one line + going to a specific processor's interrupt controller. The interrupt line + connections are fixed for an instance and are dictated by the IP integration + into the SoC (excluding the SoCs that have an Interrupt Crossbar or an + Interrupt Router IP). Each interrupt line is programmable through a set of + interrupt configuration registers, and have a rx and tx interrupt source per + h/w fifo. Communication between different processors is achieved through the + appropriate programming of the rx and tx interrupt sources on the appropriate + interrupt lines. + + The number of h/w fifo queues and interrupt lines dictate the usable + registers. All the current OMAP SoCs except for the newest DRA7xx SoC has a + single IP instance. DRA7xx has multiple instances with different number of + h/w fifo queues and interrupt lines between different instances. The interrupt + lines can also be routed to different processor sub-systems on DRA7xx as they + are routed through the Crossbar, a kind of interrupt router/multiplexer. The + K3 AM65x, J721E and J7200 SoCs has each of these instances form a cluster and + combine multiple clusters into a single IP block present within the Main + NavSS. The interrupt lines from all these clusters are multiplexed and routed + to different processor subsystems over a limited number of common interrupt + output lines of an Interrupt Router. The AM64x SoCS also uses a single IP + block comprising of multiple clusters, but the number of clusters are + smaller, and the interrupt output lines are connected directly to various + processors. + + Mailbox Controller Nodes + ========================= + A Mailbox device node is used to represent a Mailbox IP instance/cluster + within a SoC. The sub-mailboxes (actual communication channels) are + represented as child nodes of this parent node. + + Mailbox Users + ============== + A device needing to communicate with a target processor device should specify + them using the common mailbox binding properties, "mboxes" and the optional + "mbox-names" (please see Documentation/devicetree/bindings/mailbox/mailbox.txt + for details). Each value of the mboxes property should contain a phandle to + the mailbox controller device node and an args specifier that will be the + phandle to the intended sub-mailbox child node to be used for communication. + The equivalent "mbox-names" property value can be used to give a name to the + communication channel to be used by the client user. + +$defs: + omap-mbox-descriptor: + $ref: /schemas/types.yaml#/definitions/uint32-array + description: + The omap-mbox-descriptor is made of up of 3 cells and represents a single + uni-directional communication channel. A typical sub-mailbox device uses + two such channels - one for transmitting (Tx) and one for receiving (Rx). + items: + - description: + mailbox fifo id used either for transmitting on ti,mbox-tx channel or + for receiving on ti,mbox-rx channel (fifo_id). This is the hardware + fifo number within a mailbox cluster. + - description: + irq identifier index number to use from the parent's interrupts data. + Should be 0 for most of the cases, a positive index value is seen only + on mailboxes that have multiple interrupt lines connected to the MPU + processor (irq_id). This is an index number in the listed interrupts + property in the DT nodes. + - description: + mailbox user id for identifying the interrupt line associated with + generating a tx/rx fifo interrupt (usr_id). This is the hardware + user id number within a mailbox cluster. + + omap-sub-mailbox: + type: object + description: + The omap-sub-mailbox is a child node within a Mailbox controller device + node and represents the actual communication channel used to send and + receive messages between the host processor and a remote processor. Each + child node should have a unique node name across all the different mailbox + device nodes. + + properties: + ti,mbox-tx: + $ref: "#/$defs/omap-mbox-descriptor" + description: sub-mailbox descriptor property defining a Tx fifo. + + ti,mbox-rx: + $ref: "#/$defs/omap-mbox-descriptor" + description: sub-mailbox descriptor property defining a Rx fifo. + + ti,mbox-send-noirq: + type: boolean + description: + Quirk flag to allow the client user of this sub-mailbox to send + messages without triggering a Tx ready interrupt, and to control + the Tx ticker. Should be used only on sub-mailboxes used to + communicate with WkupM3 remote processor on AM33xx/AM43xx SoCs. + + required: + - ti,mbox-tx + - ti,mbox-rx + +properties: + compatible: + enum: + - ti,omap2-mailbox # for OMAP2420, OMAP2430 SoCs + - ti,omap3-mailbox # for OMAP3430, OMAP3630 SoCs + - ti,omap4-mailbox # for OMAP44xx, OMAP54xx, AM33xx, AM43xx and DRA7xx SoCs + - ti,am654-mailbox # for K3 AM65x, J721E and J7200 SoCs + - ti,am64-mailbox # for K3 AM64x SoCs + + reg: + maxItems: 1 + + interrupts: + description: + Contains the interrupt information for the mailbox device. The format is + dependent on which interrupt controller the Mailbox device uses. The + number of interrupts listed will at most be the value specified in + ti,mbox-num-users property, but is usually limited by the number of + interrupts reaching the main processor. An interrupt-parent property + is required on SoCs where the interrupt lines are connected through a + Interrupt Router before reaching the main processor's GIC. + + "#mbox-cells": + const: 1 + description: + The specifier is a phandle to an omap-sub-mailbox device. + + ti,mbox-num-users: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + Number of targets (processor devices) that the mailbox device can + interrupt. + + ti,mbox-num-fifos: + $ref: /schemas/types.yaml#/definitions/uint32 + description: Number of h/w fifo queues within the mailbox IP block. + + ti,hwmods: + $ref: /schemas/types.yaml#/definitions/string + deprecated: true + description: + Name of the hwmod associated with the mailbox. This should be defined + in the mailbox node only if the node is not defined as a child node of + a corresponding sysc interconnect node. + + This property is only needed on some legacy OMAP SoCs which have not + yet been converted to the ti,sysc interconnect hierarachy, but is + otherwise considered obsolete. + +patternProperties: + "^mbox-[a-z0-9-]+$": + $ref: "#/$defs/omap-sub-mailbox" + +required: + - compatible + - reg + - interrupts + - "#mbox-cells" + - ti,mbox-num-users + - ti,mbox-num-fifos + +allOf: + - if: + properties: + compatible: + enum: + - ti,am654-mailbox + then: + required: + - interrupt-parent + + - if: + properties: + compatible: + enum: + - ti,am654-mailbox + - ti,am64-mailbox + then: + properties: + ti,mbox-num-users: + const: 4 + ti,mbox-num-fifos: + const: 16 + interrupts: + minItems: 1 + maxItems: 4 + + - if: + properties: + compatible: + enum: + - ti,omap4-mailbox + then: + properties: + ti,mbox-num-users: + enum: [3, 4] + ti,mbox-num-fifos: + enum: [8, 12] + interrupts: + minItems: 1 + maxItems: 4 + + - if: + properties: + compatible: + enum: + - ti,omap3-mailbox + then: + properties: + ti,mbox-num-users: + const: 2 + ti,mbox-num-fifos: + const: 2 + interrupts: + minItems: 1 + maxItems: 1 + + - if: + properties: + compatible: + enum: + - ti,omap2-mailbox + then: + properties: + ti,mbox-num-users: + const: 4 + ti,mbox-num-fifos: + const: 6 + interrupts: + minItems: 1 + maxItems: 2 + +additionalProperties: false + +examples: + - | + /* OMAP4 */ + #include + mailbox: mailbox@4a0f4000 { + compatible = "ti,omap4-mailbox"; + reg = <0x4a0f4000 0x200>; + interrupts = ; + #mbox-cells = <1>; + ti,mbox-num-users = <3>; + ti,mbox-num-fifos = <8>; + + mbox_ipu: mbox-ipu { + ti,mbox-tx = <0 0 0>; + ti,mbox-rx = <1 0 0>; + }; + mbox_dsp: mbox-dsp { + ti,mbox-tx = <3 0 0>; + ti,mbox-rx = <2 0 0>; + }; + }; + + dsp { + mboxes = <&mailbox &mbox_dsp>; + }; + + - | + /* AM33xx */ + mailbox1: mailbox@480c8000 { + compatible = "ti,omap4-mailbox"; + reg = <0x480c8000 0x200>; + interrupts = <77>; + #mbox-cells = <1>; + ti,mbox-num-users = <4>; + ti,mbox-num-fifos = <8>; + + mbox_wkupm3: mbox-wkup-m3 { + ti,mbox-tx = <0 0 0>; + ti,mbox-rx = <0 0 3>; + ti,mbox-send-noirq; + }; + }; + + - | + /* AM65x */ + mailbox0_cluster0: mailbox@31f80000 { + compatible = "ti,am654-mailbox"; + reg = <0x31f80000 0x200>; + #mbox-cells = <1>; + ti,mbox-num-users = <4>; + ti,mbox-num-fifos = <16>; + interrupt-parent = <&intr_main_navss>; + interrupts = <436>; + + mbox_mcu_r5fss0_core0: mbox-mcu-r5fss0-core0 { + ti,mbox-tx = <1 0 0>; + ti,mbox-rx = <0 0 0>; + }; + }; diff --git a/Documentation/devicetree/bindings/remoteproc/ti,omap-remoteproc.yaml b/Documentation/devicetree/bindings/remoteproc/ti,omap-remoteproc.yaml index 73400bc6e91d..0ef0bc498357 100644 --- a/Documentation/devicetree/bindings/remoteproc/ti,omap-remoteproc.yaml +++ b/Documentation/devicetree/bindings/remoteproc/ti,omap-remoteproc.yaml @@ -65,7 +65,7 @@ properties: OMAP Mailbox specifier denoting the sub-mailbox, to be used for communication with the remote processor. The specifier format is as per the bindings, - Documentation/devicetree/bindings/mailbox/omap-mailbox.txt + Documentation/devicetree/bindings/mailbox/ti,omap-mailbox.yaml This property should match with the sub-mailbox node used in the firmware image. -- cgit v1.2.3 From 7bf063a1cea9841a32507bb291b4539c5247ab45 Mon Sep 17 00:00:00 2001 From: Sudeep Holla Date: Tue, 1 Jun 2021 23:48:57 +0100 Subject: dt-bindings: firmware: arm,scpi: Move arm,scp-shmem to json schema Move the SRAM and shared memory binding for SCPI into the existing Generic on-chip SRAM. We just need to update the compatible list and there-by remove the whole old text format binding for the same. Cc: Rob Herring Cc: Kevin Hilman Cc: Neil Armstrong Cc: Jerome Brunet Signed-off-by: Sudeep Holla Link: https://lore.kernel.org/r/20210601224904.917990-2-sudeep.holla@arm.com Signed-off-by: Rob Herring --- Documentation/devicetree/bindings/arm/arm,scpi.txt | 15 --------------- Documentation/devicetree/bindings/sram/sram.yaml | 1 + 2 files changed, 1 insertion(+), 15 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/arm,scpi.txt b/Documentation/devicetree/bindings/arm/arm,scpi.txt index bcd6c3ec471e..bcb8b3d61e68 100644 --- a/Documentation/devicetree/bindings/arm/arm,scpi.txt +++ b/Documentation/devicetree/bindings/arm/arm,scpi.txt @@ -56,21 +56,6 @@ Other required properties for all clocks(all from common clock binding): node. It can be non linear and hence provide the mapping of identifiers into the clock-output-names array. -SRAM and Shared Memory for SCPI -------------------------------- - -A small area of SRAM is reserved for SCPI communication between application -processors and SCP. - -The properties should follow the generic mmio-sram description found in [3] - -Each sub-node represents the reserved area for SCPI. - -Required sub-node properties: -- reg : The base offset and size of the reserved area with the SRAM -- compatible : should be "arm,scp-shmem" for Non-secure SRAM based - shared memory - Sensor bindings for the sensors based on SCPI Message Protocol -------------------------------------------------------------- SCPI provides an API to access the various sensors on the SoC. diff --git a/Documentation/devicetree/bindings/sram/sram.yaml b/Documentation/devicetree/bindings/sram/sram.yaml index c1a5afa73cfe..7fc208692a7a 100644 --- a/Documentation/devicetree/bindings/sram/sram.yaml +++ b/Documentation/devicetree/bindings/sram/sram.yaml @@ -80,6 +80,7 @@ patternProperties: - amlogic,meson8b-smp-sram - amlogic,meson-gxbb-scp-shmem - amlogic,meson-axg-scp-shmem + - arm,scp-shmem - renesas,smp-sram - rockchip,rk3066-smp-sram - samsung,exynos4210-sysram -- cgit v1.2.3 From 4041e842e2a96d12e311f27c6a7f0f446e45f0b5 Mon Sep 17 00:00:00 2001 From: Sudeep Holla Date: Tue, 1 Jun 2021 23:48:58 +0100 Subject: dt-bindings: firmware: arm,scmi: Move arm,scmi-shmem to json schema Move the SRAM and shared memory binding for SCMI into the existing Generic on-chip SRAM. We just need to update the compatible list and there-by remove the whole old text format binding for the same. Cc: Rob Herring Cc: Cristian Marussi Cc: Florian Fainelli Signed-off-by: Sudeep Holla Link: https://lore.kernel.org/r/20210601224904.917990-3-sudeep.holla@arm.com Signed-off-by: Rob Herring --- Documentation/devicetree/bindings/arm/arm,scmi.txt | 15 --------------- Documentation/devicetree/bindings/sram/sram.yaml | 1 + 2 files changed, 1 insertion(+), 15 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/arm,scmi.txt b/Documentation/devicetree/bindings/arm/arm,scmi.txt index 667d58e0a659..b7be2000afcb 100644 --- a/Documentation/devicetree/bindings/arm/arm,scmi.txt +++ b/Documentation/devicetree/bindings/arm/arm,scmi.txt @@ -106,21 +106,6 @@ Required properties: - #reset-cells : Should be 1. Contains the reset domain ID value used by SCMI commands. -SRAM and Shared Memory for SCMI -------------------------------- - -A small area of SRAM is reserved for SCMI communication between application -processors and SCP. - -The properties should follow the generic mmio-sram description found in [4] - -Each sub-node represents the reserved area for SCMI. - -Required sub-node properties: -- reg : The base offset and size of the reserved area with the SRAM -- compatible : should be "arm,scmi-shmem" for Non-secure SRAM based - shared memory - [0] http://infocenter.arm.com/help/topic/com.arm.doc.den0056a/index.html [1] Documentation/devicetree/bindings/clock/clock-bindings.txt [2] Documentation/devicetree/bindings/power/power-domain.yaml diff --git a/Documentation/devicetree/bindings/sram/sram.yaml b/Documentation/devicetree/bindings/sram/sram.yaml index 7fc208692a7a..543aa400fbdf 100644 --- a/Documentation/devicetree/bindings/sram/sram.yaml +++ b/Documentation/devicetree/bindings/sram/sram.yaml @@ -80,6 +80,7 @@ patternProperties: - amlogic,meson8b-smp-sram - amlogic,meson-gxbb-scp-shmem - amlogic,meson-axg-scp-shmem + - arm,scmi-shmem - arm,scp-shmem - renesas,smp-sram - rockchip,rk3066-smp-sram -- cgit v1.2.3 From cba0c95b3b35737ac614c6de232261224c5088aa Mon Sep 17 00:00:00 2001 From: Sudeep Holla Date: Tue, 1 Jun 2021 23:48:59 +0100 Subject: dt-bindings: firmware: juno,scpi: Move to sram.yaml json schema Commit a90b15e0ad72 ("Documentation: bindings: decouple juno specific details from generic binding") moved the juno specific bindings into separate file. Though there was no need for juno specific binding, it has been used unfortunately for whatever stupid reason I added it for. Let us move the same to the generic sram.yaml schema and remove the old text format binding. Cc: Rob Herring Signed-off-by: Sudeep Holla Link: https://lore.kernel.org/r/20210601224904.917990-4-sudeep.holla@arm.com Signed-off-by: Rob Herring --- .../devicetree/bindings/arm/juno,scpi.txt | 26 ---------------------- Documentation/devicetree/bindings/sram/sram.yaml | 2 ++ 2 files changed, 2 insertions(+), 26 deletions(-) delete mode 100644 Documentation/devicetree/bindings/arm/juno,scpi.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/juno,scpi.txt b/Documentation/devicetree/bindings/arm/juno,scpi.txt deleted file mode 100644 index 2ace8696bbee..000000000000 --- a/Documentation/devicetree/bindings/arm/juno,scpi.txt +++ /dev/null @@ -1,26 +0,0 @@ -System Control and Power Interface (SCPI) Message Protocol -(in addition to the standard binding in [0]) - -Juno SRAM and Shared Memory for SCPI ------------------------------------- - -Required properties: -- compatible : should be "arm,juno-sram-ns" for Non-secure SRAM - -Each sub-node represents the reserved area for SCPI. - -Required sub-node properties: -- reg : The base offset and size of the reserved area with the SRAM -- compatible : should be "arm,juno-scp-shmem" for Non-secure SRAM based - shared memory on Juno platforms - -Sensor bindings for the sensors based on SCPI Message Protocol --------------------------------------------------------------- -Required properties: -- compatible : should be "arm,scpi-sensors". -- #thermal-sensor-cells: should be set to 1. - For Juno R0 and Juno R1 refer to [1] for the - sensor identifiers - -[0] Documentation/devicetree/bindings/arm/arm,scpi.txt -[1] http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0922b/apas03s22.html diff --git a/Documentation/devicetree/bindings/sram/sram.yaml b/Documentation/devicetree/bindings/sram/sram.yaml index 543aa400fbdf..799ed9a0e4b2 100644 --- a/Documentation/devicetree/bindings/sram/sram.yaml +++ b/Documentation/devicetree/bindings/sram/sram.yaml @@ -28,6 +28,7 @@ properties: contains: enum: - mmio-sram + - arm,juno-sram-ns - atmel,sama5d2-securam - rockchip,rk3288-pmu-sram @@ -80,6 +81,7 @@ patternProperties: - amlogic,meson8b-smp-sram - amlogic,meson-gxbb-scp-shmem - amlogic,meson-axg-scp-shmem + - arm,juno-scp-shmem - arm,scmi-shmem - arm,scp-shmem - renesas,smp-sram -- cgit v1.2.3 From d6178370995fb4bac531e2e5c18163ce1731a97c Mon Sep 17 00:00:00 2001 From: Sudeep Holla Date: Tue, 1 Jun 2021 23:49:00 +0100 Subject: dt-bindings: firmware: amlogic,scpi: Move arm,scpi-shmem to json schema "amlogic,meson-gxbb-scp-shmem" is already in the Generic on-chip SRAM binding though "amlogic,meson-gxbb-scpi" is missing which is now added. Also remove the whole old text format binding for the same. Cc: Rob Herring Cc: Kevin Hilman Cc: Neil Armstrong Cc: Jerome Brunet Signed-off-by: Sudeep Holla Link: https://lore.kernel.org/r/20210601224904.917990-5-sudeep.holla@arm.com Signed-off-by: Rob Herring --- Documentation/devicetree/bindings/arm/amlogic,scpi.txt | 12 ------------ Documentation/devicetree/bindings/sram/sram.yaml | 1 + 2 files changed, 1 insertion(+), 12 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/amlogic,scpi.txt b/Documentation/devicetree/bindings/arm/amlogic,scpi.txt index 5ab59da052df..ebfe302fb747 100644 --- a/Documentation/devicetree/bindings/arm/amlogic,scpi.txt +++ b/Documentation/devicetree/bindings/arm/amlogic,scpi.txt @@ -5,18 +5,6 @@ Required properties - compatible : should be "amlogic,meson-gxbb-scpi" -AMLOGIC SRAM and Shared Memory for SCPI ------------------------------------- - -Required properties: -- compatible : should be "amlogic,meson-gxbb-sram" - -Each sub-node represents the reserved area for SCPI. - -Required sub-node properties: -- compatible : should be "amlogic,meson-gxbb-scp-shmem" for SRAM based shared - memory on Amlogic GXBB SoC. - Sensor bindings for the sensors based on SCPI Message Protocol -------------------------------------------------------------- SCPI provides an API to access the various sensors on the SoC. diff --git a/Documentation/devicetree/bindings/sram/sram.yaml b/Documentation/devicetree/bindings/sram/sram.yaml index 799ed9a0e4b2..3eda5049d183 100644 --- a/Documentation/devicetree/bindings/sram/sram.yaml +++ b/Documentation/devicetree/bindings/sram/sram.yaml @@ -28,6 +28,7 @@ properties: contains: enum: - mmio-sram + - amlogic,meson-gxbb-sram - arm,juno-sram-ns - atmel,sama5d2-securam - rockchip,rk3288-pmu-sram -- cgit v1.2.3 From 94dac76d4317ec652aa052cbe81db9f7a719da1d Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Wed, 2 Jun 2021 17:43:07 +0200 Subject: dt-bindings: power: supply: cpcap-battery: update cpcap-battery.yaml reference Changeset 3c5be0454972 ("dt-bindings: power: supply: cpcap-battery: Convert to DT schema format") renamed: Documentation/devicetree/bindings/power/supply/cpcap-battery.txt to: Documentation/devicetree/bindings/power/supply/cpcap-battery.yaml. Update its cross-reference accordingly. Fixes: 3c5be0454972 ("dt-bindings: power: supply: cpcap-battery: Convert to DT schema format") Signed-off-by: Mauro Carvalho Chehab Link: https://lore.kernel.org/r/1d0c8d50db22d9e5540a42be874fcd39fb7fc2a7.1622648507.git.mchehab+huawei@kernel.org Signed-off-by: Rob Herring --- Documentation/devicetree/bindings/mfd/motorola-cpcap.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mfd/motorola-cpcap.txt b/Documentation/devicetree/bindings/mfd/motorola-cpcap.txt index b52e7a33f0f9..e656e6f08fed 100644 --- a/Documentation/devicetree/bindings/mfd/motorola-cpcap.txt +++ b/Documentation/devicetree/bindings/mfd/motorola-cpcap.txt @@ -16,7 +16,7 @@ Optional subnodes: The sub-functions of CPCAP get their own node with their own compatible values, which are described in the following files: -- Documentation/devicetree/bindings/power/supply/cpcap-battery.txt +- Documentation/devicetree/bindings/power/supply/cpcap-battery.yaml - Documentation/devicetree/bindings/power/supply/cpcap-charger.txt - Documentation/devicetree/bindings/regulator/cpcap-regulator.txt - Documentation/devicetree/bindings/phy/phy-cpcap-usb.txt -- cgit v1.2.3 From b5205bb4de9e5ebaaaf20a7d0cf3bd1e98b42652 Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Wed, 2 Jun 2021 17:43:08 +0200 Subject: dt-bindings: power: supply: cpcap-charger: update cpcap-charger.yaml reference Changeset ce49e4282200 ("dt-bindings: power: supply: cpcap-charger: Convert to DT schema format") renamed: Documentation/devicetree/bindings/power/supply/cpcap-charger.txt to: Documentation/devicetree/bindings/power/supply/cpcap-charger.yaml. Update its cross-reference accordingly. Fixes: ce49e4282200 ("dt-bindings: power: supply: cpcap-charger: Convert to DT schema format") Signed-off-by: Mauro Carvalho Chehab Link: https://lore.kernel.org/r/e9ce216362b7b9dcf84d707a3854247123440bf7.1622648507.git.mchehab+huawei@kernel.org Signed-off-by: Rob Herring --- Documentation/devicetree/bindings/mfd/motorola-cpcap.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mfd/motorola-cpcap.txt b/Documentation/devicetree/bindings/mfd/motorola-cpcap.txt index e656e6f08fed..190230216de8 100644 --- a/Documentation/devicetree/bindings/mfd/motorola-cpcap.txt +++ b/Documentation/devicetree/bindings/mfd/motorola-cpcap.txt @@ -17,7 +17,7 @@ The sub-functions of CPCAP get their own node with their own compatible values, which are described in the following files: - Documentation/devicetree/bindings/power/supply/cpcap-battery.yaml -- Documentation/devicetree/bindings/power/supply/cpcap-charger.txt +- Documentation/devicetree/bindings/power/supply/cpcap-charger.yaml - Documentation/devicetree/bindings/regulator/cpcap-regulator.txt - Documentation/devicetree/bindings/phy/phy-cpcap-usb.txt - Documentation/devicetree/bindings/input/cpcap-pwrbutton.txt -- cgit v1.2.3 From f22145f1532b00f0132ed0fd5db3900c7f6b7944 Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Wed, 2 Jun 2021 17:43:09 +0200 Subject: dt-bindings: soc: ti: update sci-pm-domain.yaml references Changeset fda55c7256fe ("dt-bindings: soc: ti: Convert ti,sci-pm-domain to json schema") renamed: Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt to: Documentation/devicetree/bindings/soc/ti/sci-pm-domain.yaml. Update the cross-references accordingly. Fixes: fda55c7256fe ("dt-bindings: soc: ti: Convert ti,sci-pm-domain to json schema") Signed-off-by: Mauro Carvalho Chehab Link: https://lore.kernel.org/r/c03020ff281054c3bd2527c510659e05fec6f181.1622648507.git.mchehab+huawei@kernel.org Signed-off-by: Rob Herring --- Documentation/devicetree/bindings/dma/ti-edma.txt | 4 ++-- Documentation/devicetree/bindings/i2c/i2c-davinci.txt | 2 +- Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt | 2 +- Documentation/devicetree/bindings/net/can/c_can.txt | 2 +- Documentation/devicetree/bindings/remoteproc/ti,keystone-rproc.txt | 2 +- Documentation/devicetree/bindings/usb/ti,j721e-usb.yaml | 2 +- Documentation/devicetree/bindings/usb/ti,keystone-dwc3.yaml | 2 +- 7 files changed, 8 insertions(+), 8 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/dma/ti-edma.txt b/Documentation/devicetree/bindings/dma/ti-edma.txt index 29fcd37082e8..f719e1612b0a 100644 --- a/Documentation/devicetree/bindings/dma/ti-edma.txt +++ b/Documentation/devicetree/bindings/dma/ti-edma.txt @@ -33,7 +33,7 @@ The following are mandatory properties for 66AK2G SoCs only: - power-domains:Should contain a phandle to a PM domain provider node and an args specifier containing the device id value. This property is as per the binding, - Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt + Documentation/devicetree/bindings/soc/ti/sci-pm-domain.yaml Optional properties: ------------------- @@ -70,7 +70,7 @@ The following are mandatory properties for 66AK2G SoCs only: - power-domains:Should contain a phandle to a PM domain provider node and an args specifier containing the device id value. This property is as per the binding, - Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt + Documentation/devicetree/bindings/soc/ti/sci-pm-domain.yaml Optional properties: ------------------- diff --git a/Documentation/devicetree/bindings/i2c/i2c-davinci.txt b/Documentation/devicetree/bindings/i2c/i2c-davinci.txt index b745f3706120..b35ad748ed68 100644 --- a/Documentation/devicetree/bindings/i2c/i2c-davinci.txt +++ b/Documentation/devicetree/bindings/i2c/i2c-davinci.txt @@ -17,7 +17,7 @@ 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 + Documentation/devicetree/bindings/soc/ti/sci-pm-domain.yaml Recommended properties : - interrupts : standard interrupt property. diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt index 4a9145ef15d6..0663e7648ef9 100644 --- a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt +++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt @@ -25,7 +25,7 @@ The following are mandatory properties for 66AK2G SoCs only: - power-domains:Should contain a phandle to a PM domain provider node and an args specifier containing the MMC device id value. This property is as per the binding, - Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt + Documentation/devicetree/bindings/soc/ti/sci-pm-domain.yaml - clocks: Must contain an entry for each entry in clock-names. Should be defined as per the he appropriate clock bindings consumer usage in Documentation/devicetree/bindings/clock/ti,sci-clk.txt diff --git a/Documentation/devicetree/bindings/net/can/c_can.txt b/Documentation/devicetree/bindings/net/can/c_can.txt index 2d504256b0d8..febd2cc1ca14 100644 --- a/Documentation/devicetree/bindings/net/can/c_can.txt +++ b/Documentation/devicetree/bindings/net/can/c_can.txt @@ -19,7 +19,7 @@ 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 DCAN device id value. This property is as per the binding, - Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt + Documentation/devicetree/bindings/soc/ti/sci-pm-domain.yaml - clocks : CAN functional clock phandle. This property is as per the binding, Documentation/devicetree/bindings/clock/ti,sci-clk.txt diff --git a/Documentation/devicetree/bindings/remoteproc/ti,keystone-rproc.txt b/Documentation/devicetree/bindings/remoteproc/ti,keystone-rproc.txt index 461dc1d8d570..e99123c1445e 100644 --- a/Documentation/devicetree/bindings/remoteproc/ti,keystone-rproc.txt +++ b/Documentation/devicetree/bindings/remoteproc/ti,keystone-rproc.txt @@ -82,7 +82,7 @@ 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 DSP device id value. This property is as per the binding, - Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt + Documentation/devicetree/bindings/soc/ti/sci-pm-domain.yaml Optional properties: -------------------- diff --git a/Documentation/devicetree/bindings/usb/ti,j721e-usb.yaml b/Documentation/devicetree/bindings/usb/ti,j721e-usb.yaml index 7ec87a783c5c..a634774c537c 100644 --- a/Documentation/devicetree/bindings/usb/ti,j721e-usb.yaml +++ b/Documentation/devicetree/bindings/usb/ti,j721e-usb.yaml @@ -27,7 +27,7 @@ properties: description: PM domain provider node and an args specifier containing the USB device id value. See, - Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt + Documentation/devicetree/bindings/soc/ti/sci-pm-domain.yaml maxItems: 1 clocks: diff --git a/Documentation/devicetree/bindings/usb/ti,keystone-dwc3.yaml b/Documentation/devicetree/bindings/usb/ti,keystone-dwc3.yaml index 9a068d3bc73b..f6e91a5fd8fe 100644 --- a/Documentation/devicetree/bindings/usb/ti,keystone-dwc3.yaml +++ b/Documentation/devicetree/bindings/usb/ti,keystone-dwc3.yaml @@ -47,7 +47,7 @@ properties: description: Should contain a phandle to a PM domain provider node and an args specifier containing the USB device id value. This property is as per the binding, - Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt + Documentation/devicetree/bindings/soc/ti/sci-pm-domain.yaml phys: maxItems: 1 -- cgit v1.2.3 From c601eef1e2588df9b8bfe00f6743df4f5f59ca46 Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Wed, 2 Jun 2021 17:43:10 +0200 Subject: dt-bindings: clock: update ti,sci-clk.yaml references Changeset a7dbfa6f3877 ("dt-bindings: clock: Convert ti,sci-clk to json schema") renamed: Documentation/devicetree/bindings/clock/ti,sci-clk.txt to: Documentation/devicetree/bindings/clock/ti,sci-clk.yaml. Update the cross-references accordingly. Fixes: a7dbfa6f3877 ("dt-bindings: clock: Convert ti,sci-clk to json schema") Signed-off-by: Mauro Carvalho Chehab Link: https://lore.kernel.org/r/0fae687366c09dfb510425b3c88316a727b27d6d.1622648507.git.mchehab+huawei@kernel.org Signed-off-by: Rob Herring --- Documentation/devicetree/bindings/gpio/gpio-davinci.txt | 2 +- Documentation/devicetree/bindings/i2c/i2c-davinci.txt | 2 +- Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt | 2 +- Documentation/devicetree/bindings/net/can/c_can.txt | 2 +- Documentation/devicetree/bindings/spi/spi-davinci.txt | 2 +- 5 files changed, 5 insertions(+), 5 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/gpio/gpio-davinci.txt b/Documentation/devicetree/bindings/gpio/gpio-davinci.txt index 696ea46227d1..8ad4fd9aaffd 100644 --- a/Documentation/devicetree/bindings/gpio/gpio-davinci.txt +++ b/Documentation/devicetree/bindings/gpio/gpio-davinci.txt @@ -32,7 +32,7 @@ Required Properties: Documentation/devicetree/bindings/clock/keystone-gate.txt for 66AK2HK/66AK2L/66AK2E SoCs or, - Documentation/devicetree/bindings/clock/ti,sci-clk.txt + Documentation/devicetree/bindings/clock/ti,sci-clk.yaml for 66AK2G SoCs - clock-names: Name should be "gpio"; diff --git a/Documentation/devicetree/bindings/i2c/i2c-davinci.txt b/Documentation/devicetree/bindings/i2c/i2c-davinci.txt index b35ad748ed68..6590501c53d4 100644 --- a/Documentation/devicetree/bindings/i2c/i2c-davinci.txt +++ b/Documentation/devicetree/bindings/i2c/i2c-davinci.txt @@ -8,7 +8,7 @@ Required properties: - 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 + Documentation/devicetree/bindings/clock/ti,sci-clk.yaml SoC-specific Required Properties: diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt index 0663e7648ef9..57d077c0b7c1 100644 --- a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt +++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt @@ -28,7 +28,7 @@ The following are mandatory properties for 66AK2G SoCs only: Documentation/devicetree/bindings/soc/ti/sci-pm-domain.yaml - clocks: Must contain an entry for each entry in clock-names. Should be defined as per the he appropriate clock bindings consumer - usage in Documentation/devicetree/bindings/clock/ti,sci-clk.txt + usage in Documentation/devicetree/bindings/clock/ti,sci-clk.yaml - clock-names: Shall be "fck" for the functional clock, and "mmchsdb_fck" for the debounce clock. diff --git a/Documentation/devicetree/bindings/net/can/c_can.txt b/Documentation/devicetree/bindings/net/can/c_can.txt index febd2cc1ca14..366479806acb 100644 --- a/Documentation/devicetree/bindings/net/can/c_can.txt +++ b/Documentation/devicetree/bindings/net/can/c_can.txt @@ -22,7 +22,7 @@ The following are mandatory properties for Keystone 2 66AK2G SoCs only: Documentation/devicetree/bindings/soc/ti/sci-pm-domain.yaml - clocks : CAN functional clock phandle. This property is as per the binding, - Documentation/devicetree/bindings/clock/ti,sci-clk.txt + Documentation/devicetree/bindings/clock/ti,sci-clk.yaml Optional properties: - syscon-raminit : Handle to system control region that contains the diff --git a/Documentation/devicetree/bindings/spi/spi-davinci.txt b/Documentation/devicetree/bindings/spi/spi-davinci.txt index e2198a389484..200c7fc7b089 100644 --- a/Documentation/devicetree/bindings/spi/spi-davinci.txt +++ b/Documentation/devicetree/bindings/spi/spi-davinci.txt @@ -25,7 +25,7 @@ Required properties: - 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 + Documentation/devicetree/bindings/clock/ti,sci-clk.yaml SoC-specific Required Properties: -- cgit v1.2.3 From e84881785ea915e9bcff5bf4ed07f6749084ab66 Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Wed, 2 Jun 2021 17:43:11 +0200 Subject: dt-bindings: reset: update ti,sci-reset.yaml references Changeset 9a81b8cbc245 ("dt-bindings: reset: Convert ti,sci-reset to json schema") renamed: Documentation/devicetree/bindings/reset/ti,sci-reset.txt to: Documentation/devicetree/bindings/reset/ti,sci-reset.yaml. Update the cross-references accordingly. Fixes: 9a81b8cbc245 ("dt-bindings: reset: Convert ti,sci-reset to json schema") Signed-off-by: Mauro Carvalho Chehab Link: https://lore.kernel.org/r/e9b505d900d898c0d030deb168ab291206c203ee.1622648507.git.mchehab+huawei@kernel.org Signed-off-by: Rob Herring --- Documentation/devicetree/bindings/remoteproc/ti,keystone-rproc.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/remoteproc/ti,keystone-rproc.txt b/Documentation/devicetree/bindings/remoteproc/ti,keystone-rproc.txt index e99123c1445e..463a97c11eff 100644 --- a/Documentation/devicetree/bindings/remoteproc/ti,keystone-rproc.txt +++ b/Documentation/devicetree/bindings/remoteproc/ti,keystone-rproc.txt @@ -48,7 +48,7 @@ The following are the mandatory properties: bindings for the reset argument specifier as per SoC, Documentation/devicetree/bindings/reset/ti-syscon-reset.txt for 66AK2HK/66AK2L/66AK2E SoCs or, - Documentation/devicetree/bindings/reset/ti,sci-reset.txt + Documentation/devicetree/bindings/reset/ti,sci-reset.yaml for 66AK2G SoCs - interrupts: Should contain an entry for each value in 'interrupt-names'. -- cgit v1.2.3 From b970b8e9fbb4ab8eb0753ae5d73813e68213a2a6 Mon Sep 17 00:00:00 2001 From: Daniel Vetter Date: Fri, 21 May 2021 10:24:57 +0200 Subject: drm/doc: Include fence chain api MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit We have this nice kerneldoc, but forgot to include it. Reviewed-by: Christian König Signed-off-by: Daniel Vetter Cc: Sumit Semwal Cc: "Christian König" Cc: linux-media@vger.kernel.org Cc: linaro-mm-sig@lists.linaro.org Link: https://patchwork.freedesktop.org/patch/msgid/20210521082457.1656333-1-daniel.vetter@ffwll.ch --- Documentation/driver-api/dma-buf.rst | 9 +++++++++ 1 file changed, 9 insertions(+) (limited to 'Documentation') diff --git a/Documentation/driver-api/dma-buf.rst b/Documentation/driver-api/dma-buf.rst index 7f37ec30d9fd..7f21425d9435 100644 --- a/Documentation/driver-api/dma-buf.rst +++ b/Documentation/driver-api/dma-buf.rst @@ -178,6 +178,15 @@ DMA Fence Array .. kernel-doc:: include/linux/dma-fence-array.h :internal: +DMA Fence Chain +~~~~~~~~~~~~~~~ + +.. kernel-doc:: drivers/dma-buf/dma-fence-chain.c + :export: + +.. kernel-doc:: include/linux/dma-fence-chain.h + :internal: + DMA Fence uABI/Sync File ~~~~~~~~~~~~~~~~~~~~~~~~ -- cgit v1.2.3 From e71ccdff376b0bd1bf4d47642b7ec4d791293b96 Mon Sep 17 00:00:00 2001 From: Johan Jonker Date: Tue, 1 Jun 2021 18:47:56 +0200 Subject: dt-bindings: phy: rename phy nodename in phy-rockchip-inno-usb2.yaml The pattern: "^(|usb-|usb2-|usb3-|pci-|pcie-|sata-)phy(@[0-9a-f,]+)*$" in phy-provider.yaml has required "#phy-cells" for phy nodes. The "phy-cells" in rockchip-inno-usb2 nodes are located in subnodes. Rename the nodename to pattern "usb2phy@[0-9a-f]+$" to prevent notifications. Remove unneeded "#phy-cells" from parent node. Also sort example. make ARCH=arm dtbs_check DT_SCHEMA_FILES=~/.local/lib/python3.5/site-packages/dtschema/schemas/ phy/phy-provider.yaml Signed-off-by: Johan Jonker Acked-by: Rob Herring Acked-By: Vinod Koul Link: https://lore.kernel.org/r/20210601164800.7670-2-jbx6244@gmail.com Signed-off-by: Heiko Stuebner --- .../devicetree/bindings/phy/phy-rockchip-inno-usb2.yaml | 11 +++-------- Documentation/devicetree/bindings/soc/rockchip/grf.yaml | 4 ++-- 2 files changed, 5 insertions(+), 10 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/phy/phy-rockchip-inno-usb2.yaml b/Documentation/devicetree/bindings/phy/phy-rockchip-inno-usb2.yaml index fb29ad807b68..fbe860fff063 100644 --- a/Documentation/devicetree/bindings/phy/phy-rockchip-inno-usb2.yaml +++ b/Documentation/devicetree/bindings/phy/phy-rockchip-inno-usb2.yaml @@ -29,9 +29,6 @@ properties: "#clock-cells": const: 0 - "#phy-cells": - const: 0 - clocks: maxItems: 1 @@ -119,7 +116,6 @@ required: - reg - clock-output-names - "#clock-cells" - - "#phy-cells" - host-port - otg-port @@ -130,26 +126,25 @@ examples: #include #include #include - u2phy0: usb2-phy@e450 { + u2phy0: usb2phy@e450 { compatible = "rockchip,rk3399-usb2phy"; reg = <0xe450 0x10>; clocks = <&cru SCLK_USB2PHY0_REF>; clock-names = "phyclk"; clock-output-names = "clk_usbphy0_480m"; #clock-cells = <0>; - #phy-cells = <0>; u2phy0_host: host-port { - #phy-cells = <0>; interrupts = ; interrupt-names = "linestate"; + #phy-cells = <0>; }; u2phy0_otg: otg-port { - #phy-cells = <0>; interrupts = , , ; interrupt-names = "otg-bvalid", "otg-id", "linestate"; + #phy-cells = <0>; }; }; diff --git a/Documentation/devicetree/bindings/soc/rockchip/grf.yaml b/Documentation/devicetree/bindings/soc/rockchip/grf.yaml index 84bdaf88d5a6..43c288708f67 100644 --- a/Documentation/devicetree/bindings/soc/rockchip/grf.yaml +++ b/Documentation/devicetree/bindings/soc/rockchip/grf.yaml @@ -184,7 +184,7 @@ allOf: - "#size-cells" patternProperties: - "usb2-phy@[0-9a-f]+$": + "usb2phy@[0-9a-f]+$": type: object $ref: "/schemas/phy/phy-rockchip-inno-usb2.yaml#" @@ -233,7 +233,7 @@ examples: #phy-cells = <0>; }; - u2phy0: usb2-phy@e450 { + u2phy0: usb2phy@e450 { compatible = "rockchip,rk3399-usb2phy"; reg = <0xe450 0x10>; clocks = <&cru SCLK_USB2PHY0_REF>; -- cgit v1.2.3 From da76290fa39dc647bf7a1bac6467e66c8e465e54 Mon Sep 17 00:00:00 2001 From: Tobias Schramm Date: Tue, 1 Jun 2021 18:47:57 +0200 Subject: dt-bindings: soc: rockchip: grf: add compatible for RK3308 USB grf The RK3308 has a USB GRF. This patch adds a compatible string for it. Signed-off-by: Tobias Schramm Signed-off-by: Johan Jonker Acked-by: Rob Herring Link: https://lore.kernel.org/r/20210601164800.7670-3-jbx6244@gmail.com Signed-off-by: Heiko Stuebner --- Documentation/devicetree/bindings/soc/rockchip/grf.yaml | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/soc/rockchip/grf.yaml b/Documentation/devicetree/bindings/soc/rockchip/grf.yaml index 43c288708f67..8c1c46fef157 100644 --- a/Documentation/devicetree/bindings/soc/rockchip/grf.yaml +++ b/Documentation/devicetree/bindings/soc/rockchip/grf.yaml @@ -31,6 +31,7 @@ properties: - rockchip,rk3308-core-grf - rockchip,rk3308-detect-grf - rockchip,rk3308-grf + - rockchip,rk3308-usb2phy-grf - rockchip,rk3328-grf - rockchip,rk3328-usb2phy-grf - rockchip,rk3368-grf @@ -174,6 +175,7 @@ allOf: enum: - rockchip,px30-usb2phy-grf - rockchip,rk3228-grf + - rockchip,rk3308-usb2phy-grf - rockchip,rk3328-usb2phy-grf - rockchip,rk3399-grf - rockchip,rv1108-grf -- cgit v1.2.3 From 309f5d7944627bd61550c880833a3e9c543018bb Mon Sep 17 00:00:00 2001 From: Geert Uytterhoeven Date: Thu, 27 May 2021 21:39:52 +0200 Subject: dt-bindings: usb: cdns,usb3: Fix interrupts order Correct the order of the descriptions for the "interrupts" property to match the order of the "interrupt-names" property. Fixes: 68989fe1c39d9b32 ("dt-bindings: usb: Convert cdns-usb3.txt to YAML schema") Acked-by: Peter Chen Acked-by: Peter Chen Signed-off-by: Geert Uytterhoeven Link: https://lore.kernel.org/r/20210527193952.1705127-1-geert@linux-m68k.org Signed-off-by: Greg Kroah-Hartman --- Documentation/devicetree/bindings/usb/cdns,usb3.yaml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/usb/cdns,usb3.yaml b/Documentation/devicetree/bindings/usb/cdns,usb3.yaml index a407e1143cf4..8dedfa16c992 100644 --- a/Documentation/devicetree/bindings/usb/cdns,usb3.yaml +++ b/Documentation/devicetree/bindings/usb/cdns,usb3.yaml @@ -28,9 +28,9 @@ properties: interrupts: minItems: 3 items: - - description: OTG/DRD controller interrupt - description: XHCI host controller interrupt - description: Device controller interrupt + - description: OTG/DRD controller interrupt - description: interrupt used to wake up core, e.g when usbcmd.rs is cleared by xhci core, this interrupt is optional -- cgit v1.2.3 From 937264905aa21655cb1142146997f211153e6e27 Mon Sep 17 00:00:00 2001 From: Linus Walleij Date: Tue, 25 May 2021 10:48:46 +0200 Subject: crypto: ixp4xx - Add DT bindings This adds device tree bindings for the ixp4xx crypto engine. Cc: Corentin Labbe Cc: devicetree@vger.kernel.org Signed-off-by: Linus Walleij Reviewed-by: Rob Herring Signed-off-by: Herbert Xu --- .../bindings/crypto/intel,ixp4xx-crypto.yaml | 47 ++++++++++++++++++++++ .../intel,ixp4xx-network-processing-engine.yaml | 22 ++++++++-- 2 files changed, 65 insertions(+), 4 deletions(-) create mode 100644 Documentation/devicetree/bindings/crypto/intel,ixp4xx-crypto.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/crypto/intel,ixp4xx-crypto.yaml b/Documentation/devicetree/bindings/crypto/intel,ixp4xx-crypto.yaml new file mode 100644 index 000000000000..9c53c27bd20a --- /dev/null +++ b/Documentation/devicetree/bindings/crypto/intel,ixp4xx-crypto.yaml @@ -0,0 +1,47 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +# Copyright 2018 Linaro Ltd. +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/crypto/intel,ixp4xx-crypto.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: Intel IXP4xx cryptographic engine + +maintainers: + - Linus Walleij + +description: | + The Intel IXP4xx cryptographic engine makes use of the IXP4xx NPE + (Network Processing Engine). Since it is not a device on its own + it is defined as a subnode of the NPE, if crypto support is + available on the platform. + +properties: + compatible: + const: intel,ixp4xx-crypto + + intel,npe-handle: + $ref: '/schemas/types.yaml#/definitions/phandle-array' + maxItems: 1 + description: phandle to the NPE this crypto engine is using, the cell + describing the NPE instance to be used. + + queue-rx: + $ref: /schemas/types.yaml#/definitions/phandle-array + maxItems: 1 + description: phandle to the RX queue on the NPE, the cell describing + the queue instance to be used. + + queue-txready: + $ref: /schemas/types.yaml#/definitions/phandle-array + maxItems: 1 + description: phandle to the TX READY queue on the NPE, the cell describing + the queue instance to be used. + +required: + - compatible + - intel,npe-handle + - queue-rx + - queue-txready + +additionalProperties: false diff --git a/Documentation/devicetree/bindings/firmware/intel,ixp4xx-network-processing-engine.yaml b/Documentation/devicetree/bindings/firmware/intel,ixp4xx-network-processing-engine.yaml index 1bd2870c3a9c..c435c9f369a4 100644 --- a/Documentation/devicetree/bindings/firmware/intel,ixp4xx-network-processing-engine.yaml +++ b/Documentation/devicetree/bindings/firmware/intel,ixp4xx-network-processing-engine.yaml @@ -26,9 +26,16 @@ properties: reg: items: - - description: NPE0 register range - - description: NPE1 register range - - description: NPE2 register range + - description: NPE0 (NPE-A) register range + - description: NPE1 (NPE-B) register range + - description: NPE2 (NPE-C) register range + + crypto: + $ref: /schemas/crypto/intel,ixp4xx-crypto.yaml# + type: object + description: Optional node for the embedded crypto engine, the node + should be named with the instance number of the NPE engine used for + the crypto engine. required: - compatible @@ -38,8 +45,15 @@ additionalProperties: false examples: - | - npe@c8006000 { + npe: npe@c8006000 { compatible = "intel,ixp4xx-network-processing-engine"; reg = <0xc8006000 0x1000>, <0xc8007000 0x1000>, <0xc8008000 0x1000>; + + crypto { + compatible = "intel,ixp4xx-crypto"; + intel,npe-handle = <&npe 2>; + queue-rx = <&qmgr 30>; + queue-txready = <&qmgr 29>; + }; }; ... -- cgit v1.2.3 From 14aa731dbf464f7272bcc2f0c4f32f6de28cbe8c Mon Sep 17 00:00:00 2001 From: Oleksij Rempel Date: Mon, 31 May 2021 08:47:52 +0200 Subject: ASoC: dt-bindings: Convert imx-audmux binding to json schema Convert the imx-audmux binding to DT schema format using json-schema Signed-off-by: Oleksij Rempel Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20210531064752.8809-1-o.rempel@pengutronix.de Signed-off-by: Mark Brown --- .../devicetree/bindings/sound/imx-audmux.txt | 28 ----- .../devicetree/bindings/sound/imx-audmux.yaml | 119 +++++++++++++++++++++ 2 files changed, 119 insertions(+), 28 deletions(-) delete mode 100644 Documentation/devicetree/bindings/sound/imx-audmux.txt create mode 100644 Documentation/devicetree/bindings/sound/imx-audmux.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/imx-audmux.txt b/Documentation/devicetree/bindings/sound/imx-audmux.txt deleted file mode 100644 index 2db4dcbee1b9..000000000000 --- a/Documentation/devicetree/bindings/sound/imx-audmux.txt +++ /dev/null @@ -1,28 +0,0 @@ -Freescale Digital Audio Mux (AUDMUX) device - -Required properties: - - - compatible : "fsl,imx21-audmux" for AUDMUX version firstly used - on i.MX21, or "fsl,imx31-audmux" for the version - firstly used on i.MX31. - - - reg : Should contain AUDMUX registers location and length. - -An initial configuration can be setup using child nodes. - -Required properties of optional child nodes: - - - fsl,audmux-port : Integer of the audmux port that is configured by this - child node. - - - fsl,port-config : List of configuration options for the specific port. - For imx31-audmux and above, it is a list of tuples - . For imx21-audmux it is a list of pcr - values. - -Example: - -audmux@21d8000 { - compatible = "fsl,imx6q-audmux", "fsl,imx31-audmux"; - reg = <0x021d8000 0x4000>; -}; diff --git a/Documentation/devicetree/bindings/sound/imx-audmux.yaml b/Documentation/devicetree/bindings/sound/imx-audmux.yaml new file mode 100644 index 000000000000..dab45c310670 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/imx-audmux.yaml @@ -0,0 +1,119 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/imx-audmux.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Freescale Digital Audio Mux device + +maintainers: + - Oleksij Rempel + +properties: + compatible: + oneOf: + - items: + - enum: + - fsl,imx27-audmux + - const: fsl,imx21-audmux + - items: + - enum: + - fsl,imx25-audmux + - fsl,imx35-audmux + - fsl,imx50-audmux + - fsl,imx51-audmux + - fsl,imx53-audmux + - fsl,imx6q-audmux + - fsl,imx6sl-audmux + - fsl,imx6sll-audmux + - fsl,imx6sx-audmux + - const: fsl,imx31-audmux + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + + clock-names: + items: + - const: audmux + +patternProperties: + "^mux-[0-9a-z]*$": + type: object + properties: + fsl,audmux-port: + $ref: /schemas/types.yaml#/definitions/uint32 + description: | + Integer of the audmux port that is configured by this child node + + fsl,port-config: + $ref: /schemas/types.yaml#/definitions/uint32-array + description: | + List of configuration options for the specific port. + For imx31-audmux and above, it is a list of tuples ptcr pdcr. + For imx21-audmux it is a list of pcr values. + + required: + - fsl,audmux-port + - fsl,port-config + + additionalProperties: false + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + audmux@21d8000 { + compatible = "fsl,imx6q-audmux", "fsl,imx31-audmux"; + reg = <0x021d8000 0x4000>; + }; + - | + audmux@10016000 { + compatible = "fsl,imx27-audmux", "fsl,imx21-audmux"; + reg = <0x10016000 0x1000>; + clocks = <&clks 1>; + clock-names = "audmux"; + + mux-ssi0 { + fsl,audmux-port = <0>; + fsl,port-config = <0xcb205000>; + }; + + mux-pins4 { + fsl,audmux-port = <2>; + fsl,port-config = <0x00001000>; + }; + }; + - | + #include + audmux@21d8000 { + compatible = "fsl,imx6q-audmux", "fsl,imx31-audmux"; + reg = <0x021d8000 0x4000>; + pinctrl-names = "default"; + pinctrl-0 = <&pinctrl_audmux>; + + mux-ssi1 { + fsl,audmux-port = <0>; + fsl,port-config = < + IMX_AUDMUX_V2_PTCR_SYN 0 + IMX_AUDMUX_V2_PTCR_TFSEL(2) 0 + IMX_AUDMUX_V2_PTCR_TCSEL(2) 0 + IMX_AUDMUX_V2_PTCR_TFSDIR 0 + IMX_AUDMUX_V2_PTCR_TCLKDIR IMX_AUDMUX_V2_PDCR_RXDSEL(2) + >; + }; + + mux-pins3 { + fsl,audmux-port = <2>; + fsl,port-config = < + IMX_AUDMUX_V2_PTCR_SYN IMX_AUDMUX_V2_PDCR_RXDSEL(0) + 0 IMX_AUDMUX_V2_PDCR_TXRXEN + >; + }; + }; -- cgit v1.2.3 From 1623d767c7ec563d6e52ab76426377bfdde68f97 Mon Sep 17 00:00:00 2001 From: ChiYuan Huang Date: Thu, 3 Jun 2021 13:57:23 +0800 Subject: regulator: rt6245: Add the binding document for Richtek RT6245 Add the binding document for Richtek RT6245. Signed-off-by: ChiYuan Huang Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/1622699844-19203-1-git-send-email-u0084500@gmail.com Signed-off-by: Mark Brown --- .../regulator/richtek,rt6245-regulator.yaml | 89 ++++++++++++++++++++++ 1 file changed, 89 insertions(+) create mode 100644 Documentation/devicetree/bindings/regulator/richtek,rt6245-regulator.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/regulator/richtek,rt6245-regulator.yaml b/Documentation/devicetree/bindings/regulator/richtek,rt6245-regulator.yaml new file mode 100644 index 000000000000..796ceac87445 --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/richtek,rt6245-regulator.yaml @@ -0,0 +1,89 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/regulator/richtek,rt6245-regulator.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Richtek RT6245 High Current Voltage Regulator + +maintainers: + - ChiYuan Huang + +description: | + The RT6245 is a high-performance, synchronous step-down converter + that can deliver up to 14A output current with an input supply + voltage range of 4.5V to 17V. + +allOf: + - $ref: regulator.yaml# + +properties: + compatible: + enum: + - richtek,rt6245 + + reg: + maxItems: 1 + + enable-gpios: + description: | + A connection of the chip 'enable' gpio line. If not provided, + it will be treat as a default-on power. + maxItems: 1 + + richtek,oc-level-select: + $ref: "/schemas/types.yaml#/definitions/uint8" + enum: [0, 1, 2, 3] + description: | + Over current level selection. Each respective value means the current + limit 8A, 14A, 12A, 10A. If this property is missing then keep in + in chip default. + + richtek,ot-level-select: + $ref: "/schemas/types.yaml#/definitions/uint8" + enum: [0, 1, 2] + description: | + Over temperature level selection. Each respective value means the degree + 150'c, 130'c, 170'c. If this property is missing then keep in chip + default. + + richtek,pgdly-time-select: + $ref: "/schemas/types.yaml#/definitions/uint8" + enum: [0, 1, 2, 3] + description: | + Power good signal delay time selection. Each respective value means the + delay time 0us, 10us, 20us, 40us. If this property is missing then keep + in chip default. + + + richtek,switch-freq-select: + $ref: "/schemas/types.yaml#/definitions/uint8" + enum: [0, 1, 2] + description: | + Buck switch frequency selection. Each respective value means 400KHz, + 800KHz, 1200KHz. If this property is missing then keep in chip default. + +required: + - compatible + - reg + +unevaluatedProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + rt6245@34 { + compatible = "richtek,rt6245"; + status = "okay"; + reg = <0x34>; + enable-gpios = <&gpio26 2 0>; + + regulator-name = "rt6245-regulator"; + regulator-min-microvolt = <437500>; + regulator-max-microvolt = <1387500>; + regulator-boot-on; + }; + }; -- cgit v1.2.3 From 88016de3ab075790e1f1bf047576e9b557c22d19 Mon Sep 17 00:00:00 2001 From: Roberto Sassu Date: Thu, 3 Jun 2021 15:17:05 +0200 Subject: ima: Define new template evm-sig With the recent introduction of the evmsig template field, remote verifiers can obtain the EVM portable signature instead of the IMA signature, to verify file metadata. After introducing the new fields to include file metadata in the measurement list, this patch finally defines the evm-sig template, whose format is: d-ng|n-ng|evmsig|xattrnames|xattrlengths|xattrvalues|iuid|igid|imode xattrnames, xattrlengths and xattrvalues are populated only from defined EVM protected xattrs, i.e. the ones that EVM considers to verify the portable signature. xattrnames and xattrlengths are populated only if the xattr is present. xattrnames and xattrlengths are not necessary for verifying the EVM portable signature, but they are included for completeness of information, if a remote verifier wants to infer more from file metadata. Signed-off-by: Roberto Sassu Signed-off-by: Mimi Zohar --- Documentation/security/IMA-templates.rst | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/security/IMA-templates.rst b/Documentation/security/IMA-templates.rst index 6a58760a0a35..5adc22f99496 100644 --- a/Documentation/security/IMA-templates.rst +++ b/Documentation/security/IMA-templates.rst @@ -91,6 +91,7 @@ Below, there is the list of defined template descriptors: - "ima-sig": its format is ``d-ng|n-ng|sig``; - "ima-buf": its format is ``d-ng|n-ng|buf``; - "ima-modsig": its format is ``d-ng|n-ng|sig|d-modsig|modsig``; + - "evm-sig": its format is ``d-ng|n-ng|evmsig|xattrnames|xattrlengths|xattrvalues|iuid|igid|imode``; Use -- cgit v1.2.3 From 13f212e15b843684d4922278b97fcd0e3627e0e0 Mon Sep 17 00:00:00 2001 From: Lucas Stankus Date: Sat, 1 May 2021 09:32:31 -0300 Subject: dt-bindings: staging: iio: cdc: ad7746: add binding documentation for AD7746 Add device tree binding documentation for AD7746 cdc in YAML format. Signed-off-by: Lucas Stankus Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/2c2f4d486a94e0740e112bfac0d9306bdb7ea69c.1619841953.git.lucas.p.stankus@gmail.com Signed-off-by: Jonathan Cameron --- .../devicetree/bindings/iio/cdc/adi,ad7746.yaml | 77 ++++++++++++++++++++++ 1 file changed, 77 insertions(+) create mode 100644 Documentation/devicetree/bindings/iio/cdc/adi,ad7746.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/iio/cdc/adi,ad7746.yaml b/Documentation/devicetree/bindings/iio/cdc/adi,ad7746.yaml new file mode 100644 index 000000000000..a02036ef9e8d --- /dev/null +++ b/Documentation/devicetree/bindings/iio/cdc/adi,ad7746.yaml @@ -0,0 +1,77 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iio/cdc/adi,ad7746.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: AD7746 24-Bit Capacitance-to-Digital Converter with Temperature Sensor + +maintainers: + - Michael Hennerich + +description: | + AD7746 24-Bit Capacitance-to-Digital Converter with Temperature Sensor + + Specifications about the part can be found at: + https://www.analog.com/media/en/technical-documentation/data-sheets/ad7291.pdf + +properties: + compatible: + enum: + - adi,ad7745 + - adi,ad7746 + - adi,ad7747 + + reg: + maxItems: 1 + + adi,excitation-vdd-permille: + description: | + Set VDD per mille to be used as the excitation voltage. + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [125, 250, 375, 500] + + adi,exca-output-en: + description: Enables the EXCA pin as the excitation output. + type: boolean + + adi,exca-output-invert: + description: | + Inverts the excitation output in the EXCA pin. + Normally only one of the EXCX pins would be inverted, check the following + application notes for more details + https://www.analog.com/media/en/technical-documentation/application-notes/AN-1585.pdf + type: boolean + + adi,excb-output-en: + description: Enables the EXCB pin as the excitation output. + type: boolean + + adi,excb-output-invert: + description: Inverts the excitation output in the EXCB pin. + type: boolean + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + ad7746: cdc@48 { + compatible = "adi,ad7746"; + reg = <0x48>; + adi,excitation-vdd-permille = <125>; + + adi,exca-output-en; + adi,exca-output-invert; + adi,excb-output-en; + adi,excb-output-invert; + }; + }; +... -- cgit v1.2.3 From b711f687a1c1c14c2da589e84e4f61b975196951 Mon Sep 17 00:00:00 2001 From: Jarkko Nikula Date: Wed, 2 Jun 2021 14:32:59 +0300 Subject: counter: Add support for Intel Quadrature Encoder Peripheral Add support for Intel Quadrature Encoder Peripheral found on Intel Elkhart Lake platform. Initial implementation was done by Felipe Balbi while he was working at Intel with later changes from Raymond Tan and me. Co-developed-by: Felipe Balbi (Intel) Signed-off-by: Felipe Balbi (Intel) Co-developed-by: Raymond Tan Signed-off-by: Raymond Tan Signed-off-by: Jarkko Nikula Acked-by: William Breathitt Gray Link: https://lore.kernel.org/r/20210602113259.158674-1-jarkko.nikula@linux.intel.com Signed-off-by: Jonathan Cameron --- Documentation/ABI/testing/sysfs-bus-counter | 9 +++++++++ 1 file changed, 9 insertions(+) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-bus-counter b/Documentation/ABI/testing/sysfs-bus-counter index 566bd99fe0a5..e9d9e50f03be 100644 --- a/Documentation/ABI/testing/sysfs-bus-counter +++ b/Documentation/ABI/testing/sysfs-bus-counter @@ -193,6 +193,15 @@ Description: both edges: Any state transition. +What: /sys/bus/counter/devices/counterX/countY/spike_filter_ns +KernelVersion: 5.14 +Contact: linux-iio@vger.kernel.org +Description: + If the counter device supports programmable spike filter this + attribute indicates the value in nanoseconds where noise pulses + shorter or equal to configured value are ignored. Value 0 means + filter is disabled. + What: /sys/bus/counter/devices/counterX/name KernelVersion: 5.2 Contact: linux-iio@vger.kernel.org -- cgit v1.2.3 From ea8806344743816717280fdc8587d55d1c099040 Mon Sep 17 00:00:00 2001 From: Henry Chen Date: Wed, 2 Jun 2021 19:20:49 +0800 Subject: dt-bindings: mediatek: add compatible for MT8195 pwrap This adds dt-binding documentation of pwrap for Mediatek MT8195 SoCs Platform. Signed-off-by: Henry Chen Link: https://lore.kernel.org/r/20210602112050.12338-2-james.lo@mediatek.com Signed-off-by: Matthias Brugger --- Documentation/devicetree/bindings/soc/mediatek/pwrap.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/soc/mediatek/pwrap.txt b/Documentation/devicetree/bindings/soc/mediatek/pwrap.txt index 8051c17e640e..d74a7a5ae9f2 100644 --- a/Documentation/devicetree/bindings/soc/mediatek/pwrap.txt +++ b/Documentation/devicetree/bindings/soc/mediatek/pwrap.txt @@ -27,6 +27,7 @@ Required properties in pwrap device node. "mediatek,mt8135-pwrap" for MT8135 SoCs "mediatek,mt8173-pwrap" for MT8173 SoCs "mediatek,mt8183-pwrap" for MT8183 SoCs + "mediatek,mt8195-pwrap" for MT8195 SoCs "mediatek,mt8516-pwrap" for MT8516 SoCs - interrupts: IRQ for pwrap in SOC - reg-names: Must include the following entries: -- cgit v1.2.3 From 9821a195d4e263801884b105554e801642c59f2a Mon Sep 17 00:00:00 2001 From: Seiya Wang Date: Tue, 1 Jun 2021 15:10:42 +0800 Subject: dt-bindings: cpufreq: update cpu type and clock name for MT8173 SoC Update the cpu type of cpu2 and cpu3 since MT8173 used Cortex-a72. Acked-by: Viresh Kumar Acked-by: Rob Herring Reviewed-by: Matthias Brugger Signed-off-by: Seiya Wang Signed-off-by: Viresh Kumar --- Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek.txt | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek.txt b/Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek.txt index ea4994b35207..ef68711716fb 100644 --- a/Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek.txt +++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek.txt @@ -202,11 +202,11 @@ Example 2 (MT8173 SoC): cpu2: cpu@100 { device_type = "cpu"; - compatible = "arm,cortex-a57"; + compatible = "arm,cortex-a72"; reg = <0x100>; enable-method = "psci"; cpu-idle-states = <&CPU_SLEEP_0>; - clocks = <&infracfg CLK_INFRA_CA57SEL>, + clocks = <&infracfg CLK_INFRA_CA72SEL>, <&apmixedsys CLK_APMIXED_MAINPLL>; clock-names = "cpu", "intermediate"; operating-points-v2 = <&cpu_opp_table_b>; @@ -214,11 +214,11 @@ Example 2 (MT8173 SoC): cpu3: cpu@101 { device_type = "cpu"; - compatible = "arm,cortex-a57"; + compatible = "arm,cortex-a72"; reg = <0x101>; enable-method = "psci"; cpu-idle-states = <&CPU_SLEEP_0>; - clocks = <&infracfg CLK_INFRA_CA57SEL>, + clocks = <&infracfg CLK_INFRA_CA72SEL>, <&apmixedsys CLK_APMIXED_MAINPLL>; clock-names = "cpu", "intermediate"; operating-points-v2 = <&cpu_opp_table_b>; -- cgit v1.2.3 From 793e52d4e77d49737ad83cb11925c98f4907fcb1 Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Tue, 1 Jun 2021 11:41:39 +0200 Subject: media: docs: move DVB audio/video docs to staging The only upstream driver using the API described there is the av7110 driver. As the driver was moved to staging, move the API bits to staging as well. Signed-off-by: Mauro Carvalho Chehab --- Documentation/userspace-api/media/Makefile | 10 +- .../userspace-api/media/audio.h.rst.exceptions | 19 -- .../media/dvb/audio-bilingual-channel-select.rst | 58 ----- .../media/dvb/audio-channel-select.rst | 57 ----- .../userspace-api/media/dvb/audio-clear-buffer.rst | 48 ---- .../userspace-api/media/dvb/audio-continue.rst | 48 ---- .../userspace-api/media/dvb/audio-fclose.rst | 51 ----- .../userspace-api/media/dvb/audio-fopen.rst | 103 --------- .../userspace-api/media/dvb/audio-fwrite.rst | 79 ------- .../media/dvb/audio-get-capabilities.rst | 54 ----- .../userspace-api/media/dvb/audio-get-status.rst | 54 ----- .../userspace-api/media/dvb/audio-pause.rst | 49 ---- .../userspace-api/media/dvb/audio-play.rst | 48 ---- .../media/dvb/audio-select-source.rst | 56 ----- .../userspace-api/media/dvb/audio-set-av-sync.rst | 58 ----- .../media/dvb/audio-set-bypass-mode.rst | 62 ------ .../userspace-api/media/dvb/audio-set-id.rst | 59 ----- .../userspace-api/media/dvb/audio-set-mixer.rst | 53 ----- .../userspace-api/media/dvb/audio-set-mute.rst | 62 ------ .../media/dvb/audio-set-streamtype.rst | 66 ------ .../userspace-api/media/dvb/audio-stop.rst | 48 ---- Documentation/userspace-api/media/dvb/audio.rst | 27 --- .../userspace-api/media/dvb/audio_data_types.rst | 116 ---------- .../media/dvb/audio_function_calls.rst | 30 --- Documentation/userspace-api/media/dvb/headers.rst | 7 - .../userspace-api/media/dvb/legacy_dvb_apis.rst | 7 - .../userspace-api/media/dvb/video-clear-buffer.rst | 54 ----- .../userspace-api/media/dvb/video-command.rst | 96 -------- .../userspace-api/media/dvb/video-continue.rst | 57 ----- .../userspace-api/media/dvb/video-fast-forward.rst | 72 ------ .../userspace-api/media/dvb/video-fclose.rst | 51 ----- .../userspace-api/media/dvb/video-fopen.rst | 111 --------- .../userspace-api/media/dvb/video-freeze.rst | 61 ----- .../userspace-api/media/dvb/video-fwrite.rst | 79 ------- .../media/dvb/video-get-capabilities.rst | 61 ----- .../userspace-api/media/dvb/video-get-event.rst | 105 --------- .../media/dvb/video-get-frame-count.rst | 65 ------ .../userspace-api/media/dvb/video-get-pts.rst | 69 ------ .../userspace-api/media/dvb/video-get-size.rst | 69 ------ .../userspace-api/media/dvb/video-get-status.rst | 72 ------ .../userspace-api/media/dvb/video-play.rst | 57 ----- .../media/dvb/video-select-source.rst | 76 ------- .../userspace-api/media/dvb/video-set-blank.rst | 64 ------ .../media/dvb/video-set-display-format.rst | 60 ----- .../userspace-api/media/dvb/video-set-format.rst | 82 ------- .../media/dvb/video-set-streamtype.rst | 61 ----- .../userspace-api/media/dvb/video-slowmotion.rst | 72 ------ .../userspace-api/media/dvb/video-stillpicture.rst | 61 ----- .../userspace-api/media/dvb/video-stop.rst | 74 ------ .../userspace-api/media/dvb/video-try-command.rst | 66 ------ Documentation/userspace-api/media/dvb/video.rst | 36 --- .../media/dvb/video_function_calls.rst | 35 --- .../userspace-api/media/dvb/video_types.rst | 248 --------------------- .../userspace-api/media/video.h.rst.exceptions | 39 ---- 54 files changed, 2 insertions(+), 3380 deletions(-) delete mode 100644 Documentation/userspace-api/media/audio.h.rst.exceptions delete mode 100644 Documentation/userspace-api/media/dvb/audio-bilingual-channel-select.rst delete mode 100644 Documentation/userspace-api/media/dvb/audio-channel-select.rst delete mode 100644 Documentation/userspace-api/media/dvb/audio-clear-buffer.rst delete mode 100644 Documentation/userspace-api/media/dvb/audio-continue.rst delete mode 100644 Documentation/userspace-api/media/dvb/audio-fclose.rst delete mode 100644 Documentation/userspace-api/media/dvb/audio-fopen.rst delete mode 100644 Documentation/userspace-api/media/dvb/audio-fwrite.rst delete mode 100644 Documentation/userspace-api/media/dvb/audio-get-capabilities.rst delete mode 100644 Documentation/userspace-api/media/dvb/audio-get-status.rst delete mode 100644 Documentation/userspace-api/media/dvb/audio-pause.rst delete mode 100644 Documentation/userspace-api/media/dvb/audio-play.rst delete mode 100644 Documentation/userspace-api/media/dvb/audio-select-source.rst delete mode 100644 Documentation/userspace-api/media/dvb/audio-set-av-sync.rst delete mode 100644 Documentation/userspace-api/media/dvb/audio-set-bypass-mode.rst delete mode 100644 Documentation/userspace-api/media/dvb/audio-set-id.rst delete mode 100644 Documentation/userspace-api/media/dvb/audio-set-mixer.rst delete mode 100644 Documentation/userspace-api/media/dvb/audio-set-mute.rst delete mode 100644 Documentation/userspace-api/media/dvb/audio-set-streamtype.rst delete mode 100644 Documentation/userspace-api/media/dvb/audio-stop.rst delete mode 100644 Documentation/userspace-api/media/dvb/audio.rst delete mode 100644 Documentation/userspace-api/media/dvb/audio_data_types.rst delete mode 100644 Documentation/userspace-api/media/dvb/audio_function_calls.rst delete mode 100644 Documentation/userspace-api/media/dvb/video-clear-buffer.rst delete mode 100644 Documentation/userspace-api/media/dvb/video-command.rst delete mode 100644 Documentation/userspace-api/media/dvb/video-continue.rst delete mode 100644 Documentation/userspace-api/media/dvb/video-fast-forward.rst delete mode 100644 Documentation/userspace-api/media/dvb/video-fclose.rst delete mode 100644 Documentation/userspace-api/media/dvb/video-fopen.rst delete mode 100644 Documentation/userspace-api/media/dvb/video-freeze.rst delete mode 100644 Documentation/userspace-api/media/dvb/video-fwrite.rst delete mode 100644 Documentation/userspace-api/media/dvb/video-get-capabilities.rst delete mode 100644 Documentation/userspace-api/media/dvb/video-get-event.rst delete mode 100644 Documentation/userspace-api/media/dvb/video-get-frame-count.rst delete mode 100644 Documentation/userspace-api/media/dvb/video-get-pts.rst delete mode 100644 Documentation/userspace-api/media/dvb/video-get-size.rst delete mode 100644 Documentation/userspace-api/media/dvb/video-get-status.rst delete mode 100644 Documentation/userspace-api/media/dvb/video-play.rst delete mode 100644 Documentation/userspace-api/media/dvb/video-select-source.rst delete mode 100644 Documentation/userspace-api/media/dvb/video-set-blank.rst delete mode 100644 Documentation/userspace-api/media/dvb/video-set-display-format.rst delete mode 100644 Documentation/userspace-api/media/dvb/video-set-format.rst delete mode 100644 Documentation/userspace-api/media/dvb/video-set-streamtype.rst delete mode 100644 Documentation/userspace-api/media/dvb/video-slowmotion.rst delete mode 100644 Documentation/userspace-api/media/dvb/video-stillpicture.rst delete mode 100644 Documentation/userspace-api/media/dvb/video-stop.rst delete mode 100644 Documentation/userspace-api/media/dvb/video-try-command.rst delete mode 100644 Documentation/userspace-api/media/dvb/video.rst delete mode 100644 Documentation/userspace-api/media/dvb/video_function_calls.rst delete mode 100644 Documentation/userspace-api/media/dvb/video_types.rst delete mode 100644 Documentation/userspace-api/media/video.h.rst.exceptions (limited to 'Documentation') diff --git a/Documentation/userspace-api/media/Makefile b/Documentation/userspace-api/media/Makefile index 81a4a1a53bce..00922aa7efde 100644 --- a/Documentation/userspace-api/media/Makefile +++ b/Documentation/userspace-api/media/Makefile @@ -7,8 +7,8 @@ PARSER = $(srctree)/Documentation/sphinx/parse-headers.pl UAPI = $(srctree)/include/uapi/linux KAPI = $(srctree)/include/linux -FILES = audio.h.rst ca.h.rst dmx.h.rst frontend.h.rst net.h.rst video.h.rst \ - videodev2.h.rst media.h.rst cec.h.rst lirc.h.rst +FILES = ca.h.rst dmx.h.rst frontend.h.rst net.h.rst \ + videodev2.h.rst media.h.rst cec.h.rst lirc.h.rst TARGETS := $(addprefix $(BUILDDIR)/, $(FILES)) @@ -21,9 +21,6 @@ quiet_gen_rst = echo ' PARSE $(patsubst $(srctree)/%,%,$<)'; \ silent_gen_rst = ${gen_rst} -$(BUILDDIR)/audio.h.rst: ${UAPI}/dvb/audio.h ${PARSER} $(SRC_DIR)/audio.h.rst.exceptions - @$($(quiet)gen_rst) - $(BUILDDIR)/ca.h.rst: ${UAPI}/dvb/ca.h ${PARSER} $(SRC_DIR)/ca.h.rst.exceptions @$($(quiet)gen_rst) @@ -36,9 +33,6 @@ $(BUILDDIR)/frontend.h.rst: ${UAPI}/dvb/frontend.h ${PARSER} $(SRC_DIR)/frontend $(BUILDDIR)/net.h.rst: ${UAPI}/dvb/net.h ${PARSER} $(SRC_DIR)/net.h.rst.exceptions @$($(quiet)gen_rst) -$(BUILDDIR)/video.h.rst: ${UAPI}/dvb/video.h ${PARSER} $(SRC_DIR)/video.h.rst.exceptions - @$($(quiet)gen_rst) - $(BUILDDIR)/videodev2.h.rst: ${UAPI}/videodev2.h ${PARSER} $(SRC_DIR)/videodev2.h.rst.exceptions @$($(quiet)gen_rst) diff --git a/Documentation/userspace-api/media/audio.h.rst.exceptions b/Documentation/userspace-api/media/audio.h.rst.exceptions deleted file mode 100644 index cf6620477f73..000000000000 --- a/Documentation/userspace-api/media/audio.h.rst.exceptions +++ /dev/null @@ -1,19 +0,0 @@ -# SPDX-License-Identifier: GPL-2.0 - -# Ignore header name -ignore define _DVBAUDIO_H_ - -# Undocumented audio caps, as this is a deprecated API anyway -ignore define AUDIO_CAP_DTS -ignore define AUDIO_CAP_LPCM -ignore define AUDIO_CAP_MP1 -ignore define AUDIO_CAP_MP2 -ignore define AUDIO_CAP_MP3 -ignore define AUDIO_CAP_AAC -ignore define AUDIO_CAP_OGG -ignore define AUDIO_CAP_SDDS -ignore define AUDIO_CAP_AC3 - -# some typedefs should point to struct/enums -replace typedef audio_mixer_t :c:type:`audio_mixer` -replace typedef audio_status_t :c:type:`audio_status` diff --git a/Documentation/userspace-api/media/dvb/audio-bilingual-channel-select.rst b/Documentation/userspace-api/media/dvb/audio-bilingual-channel-select.rst deleted file mode 100644 index 33b5363317f1..000000000000 --- a/Documentation/userspace-api/media/dvb/audio-bilingual-channel-select.rst +++ /dev/null @@ -1,58 +0,0 @@ -.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later -.. c:namespace:: DTV.audio - -.. _AUDIO_BILINGUAL_CHANNEL_SELECT: - -============================== -AUDIO_BILINGUAL_CHANNEL_SELECT -============================== - -Name ----- - -AUDIO_BILINGUAL_CHANNEL_SELECT - -.. attention:: This ioctl is deprecated - -Synopsis --------- - -.. c:macro:: AUDIO_BILINGUAL_CHANNEL_SELECT - -``int ioctl(int fd, AUDIO_BILINGUAL_CHANNEL_SELECT, struct audio_channel_select *select)`` - -Arguments ---------- - -.. flat-table:: - :header-rows: 0 - :stub-columns: 0 - - - - - - int fd - - - File descriptor returned by a previous call to open(). - - - - - - audio_channel_select_t ch - - - Select the output format of the audio (mono left/right, stereo). - -Description ------------ - -This ioctl is obsolete. Do not use in new drivers. It has been replaced -by the V4L2 ``V4L2_CID_MPEG_AUDIO_DEC_MULTILINGUAL_PLAYBACK`` control -for MPEG decoders controlled through V4L2. - -This ioctl call asks the Audio Device to select the requested channel -for bilingual streams if possible. - -Return Value ------------- - -On success 0 is returned, on error -1 and the ``errno`` variable is set -appropriately. The generic error codes are described at the -:ref:`Generic Error Codes ` chapter. diff --git a/Documentation/userspace-api/media/dvb/audio-channel-select.rst b/Documentation/userspace-api/media/dvb/audio-channel-select.rst deleted file mode 100644 index 74093df92a68..000000000000 --- a/Documentation/userspace-api/media/dvb/audio-channel-select.rst +++ /dev/null @@ -1,57 +0,0 @@ -.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later -.. c:namespace:: DTV.audio - -.. _AUDIO_CHANNEL_SELECT: - -==================== -AUDIO_CHANNEL_SELECT -==================== - -Name ----- - -AUDIO_CHANNEL_SELECT - -.. attention:: This ioctl is deprecated - -Synopsis --------- - -.. c:macro:: AUDIO_CHANNEL_SELECT - -``int ioctl(int fd, AUDIO_CHANNEL_SELECT, struct audio_channel_select *select)`` - -Arguments ---------- - -.. flat-table:: - :header-rows: 0 - :stub-columns: 0 - - - - - - int fd - - - File descriptor returned by a previous call to open(). - - - - - - audio_channel_select_t ch - - - Select the output format of the audio (mono left/right, stereo). - -Description ------------ - -This ioctl is for Digital TV devices only. To control a V4L2 decoder use the -V4L2 ``V4L2_CID_MPEG_AUDIO_DEC_PLAYBACK`` control instead. - -This ioctl call asks the Audio Device to select the requested channel if -possible. - -Return Value ------------- - -On success 0 is returned, on error -1 and the ``errno`` variable is set -appropriately. The generic error codes are described at the -:ref:`Generic Error Codes ` chapter. diff --git a/Documentation/userspace-api/media/dvb/audio-clear-buffer.rst b/Documentation/userspace-api/media/dvb/audio-clear-buffer.rst deleted file mode 100644 index a0ebb0278260..000000000000 --- a/Documentation/userspace-api/media/dvb/audio-clear-buffer.rst +++ /dev/null @@ -1,48 +0,0 @@ -.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later -.. c:namespace:: DTV.audio - -.. _AUDIO_CLEAR_BUFFER: - -================== -AUDIO_CLEAR_BUFFER -================== - -Name ----- - -AUDIO_CLEAR_BUFFER - -.. attention:: This ioctl is deprecated - -Synopsis --------- - -.. c:macro:: AUDIO_CLEAR_BUFFER - -``int ioctl(int fd, AUDIO_CLEAR_BUFFER)`` - -Arguments ---------- - -.. flat-table:: - :header-rows: 0 - :stub-columns: 0 - - - .. row 1 - - - int fd - - - File descriptor returned by a previous call to open(). - -Description ------------ - -This ioctl call asks the Audio Device to clear all software and hardware -buffers of the audio decoder device. - -Return Value ------------- - -On success 0 is returned, on error -1 and the ``errno`` variable is set -appropriately. The generic error codes are described at the -:ref:`Generic Error Codes ` chapter. diff --git a/Documentation/userspace-api/media/dvb/audio-continue.rst b/Documentation/userspace-api/media/dvb/audio-continue.rst deleted file mode 100644 index a2e9850f37f2..000000000000 --- a/Documentation/userspace-api/media/dvb/audio-continue.rst +++ /dev/null @@ -1,48 +0,0 @@ -.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later -.. c:namespace:: DTV.audio - -.. _AUDIO_CONTINUE: - -============== -AUDIO_CONTINUE -============== - -Name ----- - -AUDIO_CONTINUE - -.. attention:: This ioctl is deprecated - -Synopsis --------- - -.. c:macro:: AUDIO_CONTINUE - -``int ioctl(int fd, AUDIO_CONTINUE)`` - -Arguments ---------- - -.. flat-table:: - :header-rows: 0 - :stub-columns: 0 - - - .. row 1 - - - int fd - - - File descriptor returned by a previous call to open(). - -Description ------------ - -This ioctl restarts the decoding and playing process previously paused -with AUDIO_PAUSE command. - -Return Value ------------- - -On success 0 is returned, on error -1 and the ``errno`` variable is set -appropriately. The generic error codes are described at the -:ref:`Generic Error Codes ` chapter. diff --git a/Documentation/userspace-api/media/dvb/audio-fclose.rst b/Documentation/userspace-api/media/dvb/audio-fclose.rst deleted file mode 100644 index 77857d578e83..000000000000 --- a/Documentation/userspace-api/media/dvb/audio-fclose.rst +++ /dev/null @@ -1,51 +0,0 @@ -.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later -.. c:namespace:: DTV.audio - -.. _audio_fclose: - -======================== -Digital TV audio close() -======================== - -Name ----- - -Digital TV audio close() - -.. attention:: This ioctl is deprecated - -Synopsis --------- - -.. c:function:: int close(int fd) - -Arguments ---------- - -.. flat-table:: - :header-rows: 0 - :stub-columns: 0 - - - .. row 1 - - - int fd - - - File descriptor returned by a previous call to open(). - -Description ------------ - -This system call closes a previously opened audio device. - -Return Value ------------- - -.. flat-table:: - :header-rows: 0 - :stub-columns: 0 - - - .. row 1 - - - ``EBADF`` - - - fd is not a valid open file descriptor. diff --git a/Documentation/userspace-api/media/dvb/audio-fopen.rst b/Documentation/userspace-api/media/dvb/audio-fopen.rst deleted file mode 100644 index 774daaab3bad..000000000000 --- a/Documentation/userspace-api/media/dvb/audio-fopen.rst +++ /dev/null @@ -1,103 +0,0 @@ -.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later -.. c:namespace:: DTV.audio - -.. _audio_fopen: - -======================= -Digital TV audio open() -======================= - -Name ----- - -Digital TV audio open() - -.. attention:: This ioctl is deprecated - -Synopsis --------- - -.. c:function:: int open(const char *deviceName, int flags) - -Arguments ---------- - -.. flat-table:: - :header-rows: 0 - :stub-columns: 0 - - - .. row 1 - - - const char \*deviceName - - - Name of specific audio device. - - - .. row 2 - - - int flags - - - A bit-wise OR of the following flags: - - - .. row 3 - - - - - O_RDONLY read-only access - - - .. row 4 - - - - - O_RDWR read/write access - - - .. row 5 - - - - - O_NONBLOCK open in non-blocking mode - - - .. row 6 - - - - - (blocking mode is the default) - -Description ------------ - -This system call opens a named audio device (e.g. -/dev/dvb/adapter0/audio0) for subsequent use. When an open() call has -succeeded, the device will be ready for use. The significance of -blocking or non-blocking mode is described in the documentation for -functions where there is a difference. It does not affect the semantics -of the open() call itself. A device opened in blocking mode can later be -put into non-blocking mode (and vice versa) using the F_SETFL command -of the fcntl system call. This is a standard system call, documented in -the Linux manual page for fcntl. Only one user can open the Audio Device -in O_RDWR mode. All other attempts to open the device in this mode will -fail, and an error code will be returned. If the Audio Device is opened -in O_RDONLY mode, the only ioctl call that can be used is -AUDIO_GET_STATUS. All other call will return with an error code. - -Return Value ------------- - -.. tabularcolumns:: |p{2.5cm}|p{15.0cm}| - -.. flat-table:: - :header-rows: 0 - :stub-columns: 0 - - - .. row 1 - - - ``ENODEV`` - - - Device driver not loaded/available. - - - .. row 2 - - - ``EBUSY`` - - - Device or resource busy. - - - .. row 3 - - - ``EINVAL`` - - - Invalid argument. diff --git a/Documentation/userspace-api/media/dvb/audio-fwrite.rst b/Documentation/userspace-api/media/dvb/audio-fwrite.rst deleted file mode 100644 index 7b096ac2b6c4..000000000000 --- a/Documentation/userspace-api/media/dvb/audio-fwrite.rst +++ /dev/null @@ -1,79 +0,0 @@ -.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later -.. c:namespace:: DTV.audio - -.. _audio_fwrite: - -========================= -Digital TV audio write() -========================= - -Name ----- - -Digital TV audio write() - -.. attention:: This ioctl is deprecated - -Synopsis --------- - -.. c:function:: size_t write(int fd, const void *buf, size_t count) - -Arguments ---------- - -.. flat-table:: - :header-rows: 0 - :stub-columns: 0 - - - .. row 1 - - - int fd - - - File descriptor returned by a previous call to open(). - - - .. row 2 - - - void \*buf - - - Pointer to the buffer containing the PES data. - - - .. row 3 - - - size_t count - - - Size of buf. - -Description ------------ - -This system call can only be used if AUDIO_SOURCE_MEMORY is selected -in the ioctl call AUDIO_SELECT_SOURCE. The data provided shall be in -PES format. If O_NONBLOCK is not specified the function will block -until buffer space is available. The amount of data to be transferred is -implied by count. - -Return Value ------------- - -.. flat-table:: - :header-rows: 0 - :stub-columns: 0 - - - .. row 1 - - - ``EPERM`` - - - Mode AUDIO_SOURCE_MEMORY not selected. - - - .. row 2 - - - ``ENOMEM`` - - - Attempted to write more data than the internal buffer can hold. - - - .. row 3 - - - ``EBADF`` - - - fd is not a valid open file descriptor. diff --git a/Documentation/userspace-api/media/dvb/audio-get-capabilities.rst b/Documentation/userspace-api/media/dvb/audio-get-capabilities.rst deleted file mode 100644 index 6d9eb71dad17..000000000000 --- a/Documentation/userspace-api/media/dvb/audio-get-capabilities.rst +++ /dev/null @@ -1,54 +0,0 @@ -.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later -.. c:namespace:: DTV.audio - -.. _AUDIO_GET_CAPABILITIES: - -====================== -AUDIO_GET_CAPABILITIES -====================== - -Name ----- - -AUDIO_GET_CAPABILITIES - -.. attention:: This ioctl is deprecated - -Synopsis --------- - -.. c:macro:: AUDIO_GET_CAPABILITIES - -``int ioctl(int fd, AUDIO_GET_CAPABILITIES, unsigned int *cap)`` - -Arguments ---------- - -.. flat-table:: - :header-rows: 0 - :stub-columns: 0 - - - - - - int fd - - - File descriptor returned by a previous call to open(). - - - - - - unsigned int \*cap - - - Returns a bit array of supported sound formats. - -Description ------------ - -This ioctl call asks the Audio Device to tell us about the decoding -capabilities of the audio hardware. - -Return Value ------------- - -On success 0 is returned, on error -1 and the ``errno`` variable is set -appropriately. The generic error codes are described at the -:ref:`Generic Error Codes ` chapter. diff --git a/Documentation/userspace-api/media/dvb/audio-get-status.rst b/Documentation/userspace-api/media/dvb/audio-get-status.rst deleted file mode 100644 index 7ae8db2e65e9..000000000000 --- a/Documentation/userspace-api/media/dvb/audio-get-status.rst +++ /dev/null @@ -1,54 +0,0 @@ -.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later -.. c:namespace:: DTV.audio - -.. _AUDIO_GET_STATUS: - -================ -AUDIO_GET_STATUS -================ - -Name ----- - -AUDIO_GET_STATUS - -.. attention:: This ioctl is deprecated - -Synopsis --------- - -.. c:macro:: AUDIO_GET_STATUS - -``int ioctl(int fd, AUDIO_GET_STATUS, struct audio_status *status)`` - -Arguments ---------- - -.. flat-table:: - :header-rows: 0 - :stub-columns: 0 - - - - - - int fd - - - File descriptor returned by a previous call to open(). - - - - - - struct audio_status \*status - - - Returns the current state of Audio Device. - -Description ------------ - -This ioctl call asks the Audio Device to return the current state of the -Audio Device. - -Return Value ------------- - -On success 0 is returned, on error -1 and the ``errno`` variable is set -appropriately. The generic error codes are described at the -:ref:`Generic Error Codes ` chapter. diff --git a/Documentation/userspace-api/media/dvb/audio-pause.rst b/Documentation/userspace-api/media/dvb/audio-pause.rst deleted file mode 100644 index d37d1ddce4df..000000000000 --- a/Documentation/userspace-api/media/dvb/audio-pause.rst +++ /dev/null @@ -1,49 +0,0 @@ -.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later -.. c:namespace:: DTV.audio - -.. _AUDIO_PAUSE: - -=========== -AUDIO_PAUSE -=========== - -Name ----- - -AUDIO_PAUSE - -.. attention:: This ioctl is deprecated - -Synopsis --------- - -.. c:macro:: AUDIO_PAUSE - -``int ioctl(int fd, AUDIO_PAUSE)`` - -Arguments ---------- - -.. flat-table:: - :header-rows: 0 - :stub-columns: 0 - - - .. row 1 - - - int fd - - - File descriptor returned by a previous call to open(). - -Description ------------ - -This ioctl call suspends the audio stream being played. Decoding and -playing are paused. It is then possible to restart again decoding and -playing process of the audio stream using AUDIO_CONTINUE command. - -Return Value ------------- - -On success 0 is returned, on error -1 and the ``errno`` variable is set -appropriately. The generic error codes are described at the -:ref:`Generic Error Codes ` chapter. diff --git a/Documentation/userspace-api/media/dvb/audio-play.rst b/Documentation/userspace-api/media/dvb/audio-play.rst deleted file mode 100644 index e591930b6ca7..000000000000 --- a/Documentation/userspace-api/media/dvb/audio-play.rst +++ /dev/null @@ -1,48 +0,0 @@ -.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later -.. c:namespace:: DTV.audio - -.. _AUDIO_PLAY: - -========== -AUDIO_PLAY -========== - -Name ----- - -AUDIO_PLAY - -.. attention:: This ioctl is deprecated - -Synopsis --------- - -.. c:macro:: AUDIO_PLAY - -``int ioctl(int fd, AUDIO_PLAY)`` - -Arguments ---------- - -.. flat-table:: - :header-rows: 0 - :stub-columns: 0 - - - .. row 1 - - - int fd - - - File descriptor returned by a previous call to open(). - -Description ------------ - -This ioctl call asks the Audio Device to start playing an audio stream -from the selected source. - -Return Value ------------- - -On success 0 is returned, on error -1 and the ``errno`` variable is set -appropriately. The generic error codes are described at the -:ref:`Generic Error Codes ` chapter. diff --git a/Documentation/userspace-api/media/dvb/audio-select-source.rst b/Documentation/userspace-api/media/dvb/audio-select-source.rst deleted file mode 100644 index 6a0c0f365eb1..000000000000 --- a/Documentation/userspace-api/media/dvb/audio-select-source.rst +++ /dev/null @@ -1,56 +0,0 @@ -.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later -.. c:namespace:: DTV.audio - -.. _AUDIO_SELECT_SOURCE: - -=================== -AUDIO_SELECT_SOURCE -=================== - -Name ----- - -AUDIO_SELECT_SOURCE - -.. attention:: This ioctl is deprecated - -Synopsis --------- - -.. c:macro:: AUDIO_SELECT_SOURCE - -``int ioctl(int fd, AUDIO_SELECT_SOURCE, struct audio_stream_source *source)`` - -Arguments ---------- - -.. flat-table:: - :header-rows: 0 - :stub-columns: 0 - - - - - - int fd - - - File descriptor returned by a previous call to open(). - - - - - - audio_stream_source_t source - - - Indicates the source that shall be used for the Audio stream. - -Description ------------ - -This ioctl call informs the audio device which source shall be used for -the input data. The possible sources are demux or memory. If -AUDIO_SOURCE_MEMORY is selected, the data is fed to the Audio Device -through the write command. - -Return Value ------------- - -On success 0 is returned, on error -1 and the ``errno`` variable is set -appropriately. The generic error codes are described at the -:ref:`Generic Error Codes ` chapter. diff --git a/Documentation/userspace-api/media/dvb/audio-set-av-sync.rst b/Documentation/userspace-api/media/dvb/audio-set-av-sync.rst deleted file mode 100644 index 85a8016bf025..000000000000 --- a/Documentation/userspace-api/media/dvb/audio-set-av-sync.rst +++ /dev/null @@ -1,58 +0,0 @@ -.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later -.. c:namespace:: DTV.audio - -.. _AUDIO_SET_AV_SYNC: - -================= -AUDIO_SET_AV_SYNC -================= - -Name ----- - -AUDIO_SET_AV_SYNC - -.. attention:: This ioctl is deprecated - -Synopsis --------- - -.. c:macro:: AUDIO_SET_AV_SYNC - -``int ioctl(int fd, AUDIO_SET_AV_SYNC, boolean state)`` - -Arguments ---------- - -.. flat-table:: - :header-rows: 0 - :stub-columns: 0 - - - - - - int fd - - - File descriptor returned by a previous call to open(). - - - - - - boolean state - - - Tells the Digital TV subsystem if A/V synchronization shall be ON or OFF. - - TRUE: AV-sync ON - - FALSE: AV-sync OFF - -Description ------------ - -This ioctl call asks the Audio Device to turn ON or OFF A/V -synchronization. - -Return Value ------------- - -On success 0 is returned, on error -1 and the ``errno`` variable is set -appropriately. The generic error codes are described at the -:ref:`Generic Error Codes ` chapter. diff --git a/Documentation/userspace-api/media/dvb/audio-set-bypass-mode.rst b/Documentation/userspace-api/media/dvb/audio-set-bypass-mode.rst deleted file mode 100644 index 80d551a2053a..000000000000 --- a/Documentation/userspace-api/media/dvb/audio-set-bypass-mode.rst +++ /dev/null @@ -1,62 +0,0 @@ -.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later -.. c:namespace:: DTV.audio - -.. _AUDIO_SET_BYPASS_MODE: - -===================== -AUDIO_SET_BYPASS_MODE -===================== - -Name ----- - -AUDIO_SET_BYPASS_MODE - -.. attention:: This ioctl is deprecated - -Synopsis --------- - -.. c:macro:: AUDIO_SET_BYPASS_MODE - -``int ioctl(int fd, AUDIO_SET_BYPASS_MODE, boolean mode)`` - -Arguments ---------- - -.. flat-table:: - :header-rows: 0 - :stub-columns: 0 - - - - - - int fd - - - File descriptor returned by a previous call to open(). - - - - - - boolean mode - - - Enables or disables the decoding of the current Audio stream in - the Digital TV subsystem. - - TRUE: Bypass is disabled - - FALSE: Bypass is enabled - -Description ------------ - -This ioctl call asks the Audio Device to bypass the Audio decoder and -forward the stream without decoding. This mode shall be used if streams -that can't be handled by the Digital TV system shall be decoded. Dolby -DigitalTM streams are automatically forwarded by the Digital TV subsystem if -the hardware can handle it. - -Return Value ------------- - -On success 0 is returned, on error -1 and the ``errno`` variable is set -appropriately. The generic error codes are described at the -:ref:`Generic Error Codes ` chapter. diff --git a/Documentation/userspace-api/media/dvb/audio-set-id.rst b/Documentation/userspace-api/media/dvb/audio-set-id.rst deleted file mode 100644 index 39ad846d412d..000000000000 --- a/Documentation/userspace-api/media/dvb/audio-set-id.rst +++ /dev/null @@ -1,59 +0,0 @@ -.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later -.. c:namespace:: DTV.audio - -.. _AUDIO_SET_ID: - -============ -AUDIO_SET_ID -============ - -Name ----- - -AUDIO_SET_ID - -.. attention:: This ioctl is deprecated - -Synopsis --------- - -.. c:macro:: AUDIO_SET_ID - -``int ioctl(int fd, AUDIO_SET_ID, int id)`` - -Arguments ---------- - -.. flat-table:: - :header-rows: 0 - :stub-columns: 0 - - - - - - int fd - - - File descriptor returned by a previous call to open(). - - - - - - int id - - - audio sub-stream id - -Description ------------ - -This ioctl selects which sub-stream is to be decoded if a program or -system stream is sent to the video device. If no audio stream type is -set the id has to be in [0xC0,0xDF] for MPEG sound, in [0x80,0x87] for -AC3 and in [0xA0,0xA7] for LPCM. More specifications may follow for -other stream types. If the stream type is set the id just specifies the -substream id of the audio stream and only the first 5 bits are -recognized. - -Return Value ------------- - -On success 0 is returned, on error -1 and the ``errno`` variable is set -appropriately. The generic error codes are described at the -:ref:`Generic Error Codes ` chapter. diff --git a/Documentation/userspace-api/media/dvb/audio-set-mixer.rst b/Documentation/userspace-api/media/dvb/audio-set-mixer.rst deleted file mode 100644 index 45dbdf4801e0..000000000000 --- a/Documentation/userspace-api/media/dvb/audio-set-mixer.rst +++ /dev/null @@ -1,53 +0,0 @@ -.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later -.. c:namespace:: DTV.audio - -.. _AUDIO_SET_MIXER: - -=============== -AUDIO_SET_MIXER -=============== - -Name ----- - -AUDIO_SET_MIXER - -.. attention:: This ioctl is deprecated - -Synopsis --------- - -.. c:macro:: AUDIO_SET_MIXER - -``int ioctl(int fd, AUDIO_SET_MIXER, struct audio_mixer *mix)`` - -Arguments ---------- - -.. flat-table:: - :header-rows: 0 - :stub-columns: 0 - - - - - - int fd - - - File descriptor returned by a previous call to open(). - - - - - - audio_mixer_t \*mix - - - mixer settings. - -Description ------------ - -This ioctl lets you adjust the mixer settings of the audio decoder. - -Return Value ------------- - -On success 0 is returned, on error -1 and the ``errno`` variable is set -appropriately. The generic error codes are described at the -:ref:`Generic Error Codes ` chapter. diff --git a/Documentation/userspace-api/media/dvb/audio-set-mute.rst b/Documentation/userspace-api/media/dvb/audio-set-mute.rst deleted file mode 100644 index 987751f92967..000000000000 --- a/Documentation/userspace-api/media/dvb/audio-set-mute.rst +++ /dev/null @@ -1,62 +0,0 @@ -.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later -.. c:namespace:: DTV.audio - -.. _AUDIO_SET_MUTE: - -============== -AUDIO_SET_MUTE -============== - -Name ----- - -AUDIO_SET_MUTE - -.. attention:: This ioctl is deprecated - -Synopsis --------- - -.. c:macro:: AUDIO_SET_MUTE - -``int ioctl(int fd, AUDIO_SET_MUTE, boolean state)`` - -Arguments ---------- - -.. flat-table:: - :header-rows: 0 - :stub-columns: 0 - - - - - - int fd - - - File descriptor returned by a previous call to open(). - - - - - - boolean state - - - Indicates if audio device shall mute or not. - - TRUE: Audio Mute - - FALSE: Audio Un-mute - -Description ------------ - -This ioctl is for Digital TV devices only. To control a V4L2 decoder use the -V4L2 :ref:`VIDIOC_DECODER_CMD` with the -``V4L2_DEC_CMD_START_MUTE_AUDIO`` flag instead. - -This ioctl call asks the audio device to mute the stream that is -currently being played. - -Return Value ------------- - -On success 0 is returned, on error -1 and the ``errno`` variable is set -appropriately. The generic error codes are described at the -:ref:`Generic Error Codes ` chapter. diff --git a/Documentation/userspace-api/media/dvb/audio-set-streamtype.rst b/Documentation/userspace-api/media/dvb/audio-set-streamtype.rst deleted file mode 100644 index 77d73c74882f..000000000000 --- a/Documentation/userspace-api/media/dvb/audio-set-streamtype.rst +++ /dev/null @@ -1,66 +0,0 @@ -.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later -.. c:namespace:: DTV.audio - -.. _AUDIO_SET_STREAMTYPE: - -==================== -AUDIO_SET_STREAMTYPE -==================== - -Name ----- - -AUDIO_SET_STREAMTYPE - -.. attention:: This ioctl is deprecated - -Synopsis --------- - -.. c:macro:: AUDIO_SET_STREAMTYPE - -``int ioctl(fd, AUDIO_SET_STREAMTYPE, int type)`` - -Arguments ---------- - -.. flat-table:: - :header-rows: 0 - :stub-columns: 0 - - - - - - int fd - - - File descriptor returned by a previous call to open(). - - - - - - int type - - - stream type - -Description ------------ - -This ioctl tells the driver which kind of audio stream to expect. This -is useful if the stream offers several audio sub-streams like LPCM and -AC3. - -Return Value ------------- - -On success 0 is returned, on error -1 and the ``errno`` variable is set -appropriately. The generic error codes are described at the -:ref:`Generic Error Codes ` chapter. - - -.. flat-table:: - :header-rows: 0 - :stub-columns: 0 - - - .. row 1 - - - ``EINVAL`` - - - type is not a valid or supported stream type. diff --git a/Documentation/userspace-api/media/dvb/audio-stop.rst b/Documentation/userspace-api/media/dvb/audio-stop.rst deleted file mode 100644 index d77f786fd797..000000000000 --- a/Documentation/userspace-api/media/dvb/audio-stop.rst +++ /dev/null @@ -1,48 +0,0 @@ -.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later -.. c:namespace:: DTV.audio - -.. _AUDIO_STOP: - -========== -AUDIO_STOP -========== - -Name ----- - -AUDIO_STOP - -.. attention:: This ioctl is deprecated - -Synopsis --------- - -.. c:macro:: AUDIO_STOP - -``int ioctl(int fd, AUDIO_STOP)`` - -Arguments ---------- - -.. flat-table:: - :header-rows: 0 - :stub-columns: 0 - - - .. row 1 - - - int fd - - - File descriptor returned by a previous call to open(). - -Description ------------ - -This ioctl call asks the Audio Device to stop playing the current -stream. - -Return Value ------------- - -On success 0 is returned, on error -1 and the ``errno`` variable is set -appropriately. The generic error codes are described at the -:ref:`Generic Error Codes ` chapter. diff --git a/Documentation/userspace-api/media/dvb/audio.rst b/Documentation/userspace-api/media/dvb/audio.rst deleted file mode 100644 index aa753336b31f..000000000000 --- a/Documentation/userspace-api/media/dvb/audio.rst +++ /dev/null @@ -1,27 +0,0 @@ -.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later - -.. _dvb_audio: - -####################### -Digital TV Audio Device -####################### - -The Digital TV audio device controls the MPEG2 audio decoder of the Digital -TV hardware. It can be accessed through ``/dev/dvb/adapter?/audio?``. Data -types and ioctl definitions can be accessed by including -``linux/dvb/audio.h`` in your application. - -Please note that some Digital TV cards don't have their own MPEG decoder, which -results in the omission of the audio and video device. - -These ioctls were also used by V4L2 to control MPEG decoders implemented -in V4L2. The use of these ioctls for that purpose has been made obsolete -and proper V4L2 ioctls or controls have been created to replace that -functionality. - - -.. toctree:: - :maxdepth: 1 - - audio_data_types - audio_function_calls diff --git a/Documentation/userspace-api/media/dvb/audio_data_types.rst b/Documentation/userspace-api/media/dvb/audio_data_types.rst deleted file mode 100644 index 4744529136a8..000000000000 --- a/Documentation/userspace-api/media/dvb/audio_data_types.rst +++ /dev/null @@ -1,116 +0,0 @@ -.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later - -.. _audio_data_types: - -**************** -Audio Data Types -**************** - -This section describes the structures, data types and defines used when -talking to the audio device. - -.. c:type:: audio_stream_source - -The audio stream source is set through the AUDIO_SELECT_SOURCE call -and can take the following values, depending on whether we are replaying -from an internal (demux) or external (user write) source. - - -.. code-block:: c - - typedef enum { - AUDIO_SOURCE_DEMUX, - AUDIO_SOURCE_MEMORY - } audio_stream_source_t; - -AUDIO_SOURCE_DEMUX selects the demultiplexer (fed either by the -frontend or the DVR device) as the source of the video stream. If -AUDIO_SOURCE_MEMORY is selected the stream comes from the application -through the ``write()`` system call. - - -.. c:type:: audio_play_state - -The following values can be returned by the AUDIO_GET_STATUS call -representing the state of audio playback. - - -.. code-block:: c - - typedef enum { - AUDIO_STOPPED, - AUDIO_PLAYING, - AUDIO_PAUSED - } audio_play_state_t; - - -.. c:type:: audio_channel_select - -The audio channel selected via AUDIO_CHANNEL_SELECT is determined by -the following values. - - -.. code-block:: c - - typedef enum { - AUDIO_STEREO, - AUDIO_MONO_LEFT, - AUDIO_MONO_RIGHT, - AUDIO_MONO, - AUDIO_STEREO_SWAPPED - } audio_channel_select_t; - - -.. c:type:: audio_status - -The AUDIO_GET_STATUS call returns the following structure informing -about various states of the playback operation. - - -.. code-block:: c - - typedef struct audio_status { - boolean AV_sync_state; - boolean mute_state; - audio_play_state_t play_state; - audio_stream_source_t stream_source; - audio_channel_select_t channel_select; - boolean bypass_mode; - audio_mixer_t mixer_state; - } audio_status_t; - - -.. c:type:: audio_mixer - -The following structure is used by the AUDIO_SET_MIXER call to set the -audio volume. - - -.. code-block:: c - - typedef struct audio_mixer { - unsigned int volume_left; - unsigned int volume_right; - } audio_mixer_t; - - -.. _audio_encodings: - -audio encodings -=============== - -A call to AUDIO_GET_CAPABILITIES returns an unsigned integer with the -following bits set according to the hardwares capabilities. - - -.. code-block:: c - - #define AUDIO_CAP_DTS 1 - #define AUDIO_CAP_LPCM 2 - #define AUDIO_CAP_MP1 4 - #define AUDIO_CAP_MP2 8 - #define AUDIO_CAP_MP3 16 - #define AUDIO_CAP_AAC 32 - #define AUDIO_CAP_OGG 64 - #define AUDIO_CAP_SDDS 128 - #define AUDIO_CAP_AC3 256 diff --git a/Documentation/userspace-api/media/dvb/audio_function_calls.rst b/Documentation/userspace-api/media/dvb/audio_function_calls.rst deleted file mode 100644 index fa5ba9539caf..000000000000 --- a/Documentation/userspace-api/media/dvb/audio_function_calls.rst +++ /dev/null @@ -1,30 +0,0 @@ -.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later - -.. _audio_function_calls: - -******************** -Audio Function Calls -******************** - -.. toctree:: - :maxdepth: 1 - - audio-fopen - audio-fclose - audio-fwrite - audio-stop - audio-play - audio-pause - audio-continue - audio-select-source - audio-set-mute - audio-set-av-sync - audio-set-bypass-mode - audio-channel-select - audio-bilingual-channel-select - audio-get-status - audio-get-capabilities - audio-clear-buffer - audio-set-id - audio-set-mixer - audio-set-streamtype diff --git a/Documentation/userspace-api/media/dvb/headers.rst b/Documentation/userspace-api/media/dvb/headers.rst index 9743ffc35096..88c3eb33a89e 100644 --- a/Documentation/userspace-api/media/dvb/headers.rst +++ b/Documentation/userspace-api/media/dvb/headers.rst @@ -14,10 +14,3 @@ Digital TV uAPI headers .. kernel-include:: $BUILDDIR/ca.h.rst .. kernel-include:: $BUILDDIR/net.h.rst - -Legacy uAPI -*********** - -.. kernel-include:: $BUILDDIR/audio.h.rst - -.. kernel-include:: $BUILDDIR/video.h.rst diff --git a/Documentation/userspace-api/media/dvb/legacy_dvb_apis.rst b/Documentation/userspace-api/media/dvb/legacy_dvb_apis.rst index 6104879d728a..b97d56ee543c 100644 --- a/Documentation/userspace-api/media/dvb/legacy_dvb_apis.rst +++ b/Documentation/userspace-api/media/dvb/legacy_dvb_apis.rst @@ -11,11 +11,6 @@ The APIs described here **should not** be used on new drivers or applications. The DVBv3 frontend API has issues with new delivery systems, including DVB-S2, DVB-T2, ISDB, etc. -There's just one driver for a very legacy hardware using the Digital TV -audio and video APIs. No modern drivers should use it. Instead, audio and -video should be using the V4L2 and ALSA APIs, and the pipelines should -be set via the Media Controller API. - .. attention:: The APIs described here doesn't necessarily reflect the current @@ -28,5 +23,3 @@ be set via the Media Controller API. :maxdepth: 1 frontend_legacy_dvbv3_api - video - audio diff --git a/Documentation/userspace-api/media/dvb/video-clear-buffer.rst b/Documentation/userspace-api/media/dvb/video-clear-buffer.rst deleted file mode 100644 index a7730559bbb2..000000000000 --- a/Documentation/userspace-api/media/dvb/video-clear-buffer.rst +++ /dev/null @@ -1,54 +0,0 @@ -.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later -.. c:namespace:: DTV.video - -.. _VIDEO_CLEAR_BUFFER: - -================== -VIDEO_CLEAR_BUFFER -================== - -Name ----- - -VIDEO_CLEAR_BUFFER - -.. attention:: This ioctl is deprecated. - -Synopsis --------- - -.. c:macro:: VIDEO_CLEAR_BUFFER - -``int ioctl(fd, VIDEO_CLEAR_BUFFER)`` - -Arguments ---------- - -.. flat-table:: - :header-rows: 0 - :stub-columns: 0 - - - .. row 1 - - - int fd - - - File descriptor returned by a previous call to open(). - - - .. row 2 - - - int request - - - Equals VIDEO_CLEAR_BUFFER for this command. - -Description ------------ - -This ioctl call clears all video buffers in the driver and in the -decoder hardware. - -Return Value ------------- - -On success 0 is returned, on error -1 and the ``errno`` variable is set -appropriately. The generic error codes are described at the -:ref:`Generic Error Codes ` chapter. diff --git a/Documentation/userspace-api/media/dvb/video-command.rst b/Documentation/userspace-api/media/dvb/video-command.rst deleted file mode 100644 index cae9445eb3af..000000000000 --- a/Documentation/userspace-api/media/dvb/video-command.rst +++ /dev/null @@ -1,96 +0,0 @@ -.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later -.. c:namespace:: DTV.video - -.. _VIDEO_COMMAND: - -============= -VIDEO_COMMAND -============= - -Name ----- - -VIDEO_COMMAND - -.. attention:: This ioctl is deprecated. - -Synopsis --------- - -.. c:macro:: VIDEO_COMMAND - -``int ioctl(int fd, VIDEO_COMMAND, struct video_command *cmd)`` - -Arguments ---------- - -.. flat-table:: - :header-rows: 0 - :stub-columns: 0 - - - .. row 1 - - - int fd - - - File descriptor returned by a previous call to open(). - - - .. row 2 - - - int request - - - Equals VIDEO_COMMAND for this command. - - - .. row 3 - - - struct video_command \*cmd - - - Commands the decoder. - -Description ------------ - -This ioctl is obsolete. Do not use in new drivers. For V4L2 decoders -this ioctl has been replaced by the -:ref:`VIDIOC_DECODER_CMD` ioctl. - -This ioctl commands the decoder. The ``video_command`` struct is a -subset of the ``v4l2_decoder_cmd`` struct, so refer to the -:ref:`VIDIOC_DECODER_CMD` documentation for -more information. - -.. c:type:: video_command - -.. code-block:: c - - /* The structure must be zeroed before use by the application - This ensures it can be extended safely in the future. */ - struct video_command { - __u32 cmd; - __u32 flags; - union { - struct { - __u64 pts; - } stop; - - struct { - /* 0 or 1000 specifies normal speed, - 1 specifies forward single stepping, - -1 specifies backward single stepping, - >1: playback at speed/1000 of the normal speed, - <-1: reverse playback at (-speed/1000) of the normal speed. */ - __s32 speed; - __u32 format; - } play; - - struct { - __u32 data[16]; - } raw; - }; - }; - -Return Value ------------- - -On success 0 is returned, on error -1 and the ``errno`` variable is set -appropriately. The generic error codes are described at the -:ref:`Generic Error Codes ` chapter. diff --git a/Documentation/userspace-api/media/dvb/video-continue.rst b/Documentation/userspace-api/media/dvb/video-continue.rst deleted file mode 100644 index bc34bf3989e4..000000000000 --- a/Documentation/userspace-api/media/dvb/video-continue.rst +++ /dev/null @@ -1,57 +0,0 @@ -.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later -.. c:namespace:: DTV.video - -.. _VIDEO_CONTINUE: - -============== -VIDEO_CONTINUE -============== - -Name ----- - -VIDEO_CONTINUE - -.. attention:: This ioctl is deprecated. - -Synopsis --------- - -.. c:macro:: VIDEO_CONTINUE - -``int ioctl(fd, VIDEO_CONTINUE)`` - -Arguments ---------- - -.. flat-table:: - :header-rows: 0 - :stub-columns: 0 - - - .. row 1 - - - int fd - - - File descriptor returned by a previous call to open(). - - - .. row 2 - - - int request - - - Equals VIDEO_CONTINUE for this command. - -Description ------------ - -This ioctl is for Digital TV devices only. To control a V4L2 decoder use the -V4L2 :ref:`VIDIOC_DECODER_CMD` instead. - -This ioctl call restarts decoding and playing processes of the video -stream which was played before a call to VIDEO_FREEZE was made. - -Return Value ------------- - -On success 0 is returned, on error -1 and the ``errno`` variable is set -appropriately. The generic error codes are described at the -:ref:`Generic Error Codes ` chapter. diff --git a/Documentation/userspace-api/media/dvb/video-fast-forward.rst b/Documentation/userspace-api/media/dvb/video-fast-forward.rst deleted file mode 100644 index e71fa8d6965b..000000000000 --- a/Documentation/userspace-api/media/dvb/video-fast-forward.rst +++ /dev/null @@ -1,72 +0,0 @@ -.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later -.. c:namespace:: DTV.video - -.. _VIDEO_FAST_FORWARD: - -================== -VIDEO_FAST_FORWARD -================== - -Name ----- - -VIDEO_FAST_FORWARD - -.. attention:: This ioctl is deprecated. - -Synopsis --------- - -.. c:macro:: VIDEO_FAST_FORWARD - -``int ioctl(fd, VIDEO_FAST_FORWARD, int nFrames)`` - -Arguments ---------- - -.. flat-table:: - :header-rows: 0 - :stub-columns: 0 - - - .. row 1 - - - int fd - - - File descriptor returned by a previous call to open(). - - - .. row 2 - - - int request - - - Equals VIDEO_FAST_FORWARD for this command. - - - .. row 3 - - - int nFrames - - - The number of frames to skip. - -Description ------------ - -This ioctl call asks the Video Device to skip decoding of N number of -I-frames. This call can only be used if VIDEO_SOURCE_MEMORY is -selected. - -Return Value ------------- - -On success 0 is returned, on error -1 and the ``errno`` variable is set -appropriately. The generic error codes are described at the -:ref:`Generic Error Codes ` chapter. - - -.. flat-table:: - :header-rows: 0 - :stub-columns: 0 - - - .. row 1 - - - ``EPERM`` - - - Mode VIDEO_SOURCE_MEMORY not selected. diff --git a/Documentation/userspace-api/media/dvb/video-fclose.rst b/Documentation/userspace-api/media/dvb/video-fclose.rst deleted file mode 100644 index 01d24d548439..000000000000 --- a/Documentation/userspace-api/media/dvb/video-fclose.rst +++ /dev/null @@ -1,51 +0,0 @@ -.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later -.. c:namespace:: DTV.video - -.. _video_fclose: - -================= -dvb video close() -================= - -Name ----- - -dvb video close() - -.. attention:: This ioctl is deprecated. - -Synopsis --------- - -.. c:function:: int close(int fd) - -Arguments ---------- - -.. flat-table:: - :header-rows: 0 - :stub-columns: 0 - - - .. row 1 - - - int fd - - - File descriptor returned by a previous call to open(). - -Description ------------ - -This system call closes a previously opened video device. - -Return Value ------------- - -.. flat-table:: - :header-rows: 0 - :stub-columns: 0 - - - .. row 1 - - - ``EBADF`` - - - fd is not a valid open file descriptor. diff --git a/Documentation/userspace-api/media/dvb/video-fopen.rst b/Documentation/userspace-api/media/dvb/video-fopen.rst deleted file mode 100644 index 1371b083e4e8..000000000000 --- a/Documentation/userspace-api/media/dvb/video-fopen.rst +++ /dev/null @@ -1,111 +0,0 @@ -.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later -.. c:namespace:: DTV.video - -.. _video_fopen: - -================ -dvb video open() -================ - -Name ----- - -dvb video open() - -.. attention:: This ioctl is deprecated. - -Synopsis --------- - -.. c:function:: int open(const char *deviceName, int flags) - -Arguments ---------- - -.. flat-table:: - :header-rows: 0 - :stub-columns: 0 - - - .. row 1 - - - const char \*deviceName - - - Name of specific video device. - - - .. row 2 - - - int flags - - - A bit-wise OR of the following flags: - - - .. row 3 - - - - - O_RDONLY read-only access - - - .. row 4 - - - - - O_RDWR read/write access - - - .. row 5 - - - - - O_NONBLOCK open in non-blocking mode - - - .. row 6 - - - - - (blocking mode is the default) - -Description ------------ - -This system call opens a named video device (e.g. -/dev/dvb/adapter0/video0) for subsequent use. - -When an open() call has succeeded, the device will be ready for use. The -significance of blocking or non-blocking mode is described in the -documentation for functions where there is a difference. It does not -affect the semantics of the open() call itself. A device opened in -blocking mode can later be put into non-blocking mode (and vice versa) -using the F_SETFL command of the fcntl system call. This is a standard -system call, documented in the Linux manual page for fcntl. Only one -user can open the Video Device in O_RDWR mode. All other attempts to -open the device in this mode will fail, and an error-code will be -returned. If the Video Device is opened in O_RDONLY mode, the only -ioctl call that can be used is VIDEO_GET_STATUS. All other call will -return an error code. - -Return Value ------------- - -.. tabularcolumns:: |p{2.5cm}|p{15.0cm}| - -.. flat-table:: - :header-rows: 0 - :stub-columns: 0 - - - .. row 1 - - - ``ENODEV`` - - - Device driver not loaded/available. - - - .. row 2 - - - ``EINTERNAL`` - - - Internal error. - - - .. row 3 - - - ``EBUSY`` - - - Device or resource busy. - - - .. row 4 - - - ``EINVAL`` - - - Invalid argument. diff --git a/Documentation/userspace-api/media/dvb/video-freeze.rst b/Documentation/userspace-api/media/dvb/video-freeze.rst deleted file mode 100644 index 4321f257cb70..000000000000 --- a/Documentation/userspace-api/media/dvb/video-freeze.rst +++ /dev/null @@ -1,61 +0,0 @@ -.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later -.. c:namespace:: DTV.video - -.. _VIDEO_FREEZE: - -============ -VIDEO_FREEZE -============ - -Name ----- - -VIDEO_FREEZE - -.. attention:: This ioctl is deprecated. - -Synopsis --------- - -.. c:macro:: VIDEO_FREEZE - -``int ioctl(fd, VIDEO_FREEZE)`` - -Arguments ---------- - -.. flat-table:: - :header-rows: 0 - :stub-columns: 0 - - - .. row 1 - - - int fd - - - File descriptor returned by a previous call to open(). - - - .. row 2 - - - int request - - - Equals VIDEO_FREEZE for this command. - -Description ------------ - -This ioctl is for Digital TV devices only. To control a V4L2 decoder use the -V4L2 :ref:`VIDIOC_DECODER_CMD` instead. - -This ioctl call suspends the live video stream being played. Decoding -and playing are frozen. It is then possible to restart the decoding and -playing process of the video stream using the VIDEO_CONTINUE command. -If VIDEO_SOURCE_MEMORY is selected in the ioctl call -VIDEO_SELECT_SOURCE, the Digital TV subsystem will not decode any more data -until the ioctl call VIDEO_CONTINUE or VIDEO_PLAY is performed. - -Return Value ------------- - -On success 0 is returned, on error -1 and the ``errno`` variable is set -appropriately. The generic error codes are described at the -:ref:`Generic Error Codes ` chapter. diff --git a/Documentation/userspace-api/media/dvb/video-fwrite.rst b/Documentation/userspace-api/media/dvb/video-fwrite.rst deleted file mode 100644 index a07fd7d7a40e..000000000000 --- a/Documentation/userspace-api/media/dvb/video-fwrite.rst +++ /dev/null @@ -1,79 +0,0 @@ -.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later -.. c:namespace:: DTV.video - -.. _video_fwrite: - -================= -dvb video write() -================= - -Name ----- - -dvb video write() - -.. attention:: This ioctl is deprecated. - -Synopsis --------- - -.. c:function:: size_t write(int fd, const void *buf, size_t count) - -Arguments ---------- - -.. flat-table:: - :header-rows: 0 - :stub-columns: 0 - - - .. row 1 - - - int fd - - - File descriptor returned by a previous call to open(). - - - .. row 2 - - - void \*buf - - - Pointer to the buffer containing the PES data. - - - .. row 3 - - - size_t count - - - Size of buf. - -Description ------------ - -This system call can only be used if VIDEO_SOURCE_MEMORY is selected -in the ioctl call VIDEO_SELECT_SOURCE. The data provided shall be in -PES format, unless the capability allows other formats. If O_NONBLOCK -is not specified the function will block until buffer space is -available. The amount of data to be transferred is implied by count. - -Return Value ------------- - -.. flat-table:: - :header-rows: 0 - :stub-columns: 0 - - - .. row 1 - - - ``EPERM`` - - - Mode VIDEO_SOURCE_MEMORY not selected. - - - .. row 2 - - - ``ENOMEM`` - - - Attempted to write more data than the internal buffer can hold. - - - .. row 3 - - - ``EBADF`` - - - fd is not a valid open file descriptor. diff --git a/Documentation/userspace-api/media/dvb/video-get-capabilities.rst b/Documentation/userspace-api/media/dvb/video-get-capabilities.rst deleted file mode 100644 index 01e09f56656c..000000000000 --- a/Documentation/userspace-api/media/dvb/video-get-capabilities.rst +++ /dev/null @@ -1,61 +0,0 @@ -.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later -.. c:namespace:: DTV.video - -.. _VIDEO_GET_CAPABILITIES: - -====================== -VIDEO_GET_CAPABILITIES -====================== - -Name ----- - -VIDEO_GET_CAPABILITIES - -.. attention:: This ioctl is deprecated. - -Synopsis --------- - -.. c:macro:: VIDEO_GET_CAPABILITIES - -``int ioctl(fd, VIDEO_GET_CAPABILITIES, unsigned int *cap)`` - -Arguments ---------- - -.. flat-table:: - :header-rows: 0 - :stub-columns: 0 - - - .. row 1 - - - int fd - - - File descriptor returned by a previous call to open(). - - - .. row 2 - - - int request - - - Equals VIDEO_GET_CAPABILITIES for this command. - - - .. row 3 - - - unsigned int \*cap - - - Pointer to a location where to store the capability information. - -Description ------------ - -This ioctl call asks the video device about its decoding capabilities. -On success it returns and integer which has bits set according to the -defines in section ??. - -Return Value ------------- - -On success 0 is returned, on error -1 and the ``errno`` variable is set -appropriately. The generic error codes are described at the -:ref:`Generic Error Codes ` chapter. diff --git a/Documentation/userspace-api/media/dvb/video-get-event.rst b/Documentation/userspace-api/media/dvb/video-get-event.rst deleted file mode 100644 index 90382bc36cfe..000000000000 --- a/Documentation/userspace-api/media/dvb/video-get-event.rst +++ /dev/null @@ -1,105 +0,0 @@ -.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later -.. c:namespace:: DTV.video - -.. _VIDEO_GET_EVENT: - -=============== -VIDEO_GET_EVENT -=============== - -Name ----- - -VIDEO_GET_EVENT - -.. attention:: This ioctl is deprecated. - -Synopsis --------- - -.. c:macro:: VIDEO_GET_EVENT - -``int ioctl(fd, VIDEO_GET_EVENT, struct video_event *ev)`` - -Arguments ---------- - -.. flat-table:: - :header-rows: 0 - :stub-columns: 0 - - - .. row 1 - - - int fd - - - File descriptor returned by a previous call to open(). - - - .. row 2 - - - int request - - - Equals VIDEO_GET_EVENT for this command. - - - .. row 3 - - - struct video_event \*ev - - - Points to the location where the event, if any, is to be stored. - -Description ------------ - -This ioctl is for Digital TV devices only. To get events from a V4L2 decoder -use the V4L2 :ref:`VIDIOC_DQEVENT` ioctl instead. - -This ioctl call returns an event of type video_event if available. If -an event is not available, the behavior depends on whether the device is -in blocking or non-blocking mode. In the latter case, the call fails -immediately with errno set to ``EWOULDBLOCK``. In the former case, the call -blocks until an event becomes available. The standard Linux poll() -and/or select() system calls can be used with the device file descriptor -to watch for new events. For select(), the file descriptor should be -included in the exceptfds argument, and for poll(), POLLPRI should be -specified as the wake-up condition. Read-only permissions are sufficient -for this ioctl call. - -.. c:type:: video_event - -.. code-block:: c - - struct video_event { - __s32 type; - #define VIDEO_EVENT_SIZE_CHANGED 1 - #define VIDEO_EVENT_FRAME_RATE_CHANGED 2 - #define VIDEO_EVENT_DECODER_STOPPED 3 - #define VIDEO_EVENT_VSYNC 4 - long timestamp; - union { - video_size_t size; - unsigned int frame_rate; /* in frames per 1000sec */ - unsigned char vsync_field; /* unknown/odd/even/progressive */ - } u; - }; - -Return Value ------------- - -On success 0 is returned, on error -1 and the ``errno`` variable is set -appropriately. The generic error codes are described at the -:ref:`Generic Error Codes ` chapter. - -.. flat-table:: - :header-rows: 0 - :stub-columns: 0 - - - .. row 1 - - - ``EWOULDBLOCK`` - - - There is no event pending, and the device is in non-blocking mode. - - - .. row 2 - - - ``EOVERFLOW`` - - - Overflow in event queue - one or more events were lost. diff --git a/Documentation/userspace-api/media/dvb/video-get-frame-count.rst b/Documentation/userspace-api/media/dvb/video-get-frame-count.rst deleted file mode 100644 index b48ac8c58a41..000000000000 --- a/Documentation/userspace-api/media/dvb/video-get-frame-count.rst +++ /dev/null @@ -1,65 +0,0 @@ -.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later -.. c:namespace:: DTV.video - -.. _VIDEO_GET_FRAME_COUNT: - -===================== -VIDEO_GET_FRAME_COUNT -===================== - -Name ----- - -VIDEO_GET_FRAME_COUNT - -.. attention:: This ioctl is deprecated. - -Synopsis --------- - -.. c:macro:: VIDEO_GET_FRAME_COUNT - -``int ioctl(int fd, VIDEO_GET_FRAME_COUNT, __u64 *pts)`` - -Arguments ---------- - -.. flat-table:: - :header-rows: 0 - :stub-columns: 0 - - - .. row 1 - - - int fd - - - File descriptor returned by a previous call to open(). - - - .. row 2 - - - int request - - - Equals VIDEO_GET_FRAME_COUNT for this command. - - - .. row 3 - - - __u64 \*pts - - - Returns the number of frames displayed since the decoder was - started. - -Description ------------ - -This ioctl is obsolete. Do not use in new drivers. For V4L2 decoders -this ioctl has been replaced by the ``V4L2_CID_MPEG_VIDEO_DEC_FRAME`` -control. - -This ioctl call asks the Video Device to return the number of displayed -frames since the decoder was started. - -Return Value ------------- - -On success 0 is returned, on error -1 and the ``errno`` variable is set -appropriately. The generic error codes are described at the -:ref:`Generic Error Codes ` chapter. diff --git a/Documentation/userspace-api/media/dvb/video-get-pts.rst b/Documentation/userspace-api/media/dvb/video-get-pts.rst deleted file mode 100644 index fedaff41be0b..000000000000 --- a/Documentation/userspace-api/media/dvb/video-get-pts.rst +++ /dev/null @@ -1,69 +0,0 @@ -.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later -.. c:namespace:: DTV.video - -.. _VIDEO_GET_PTS: - -============= -VIDEO_GET_PTS -============= - -Name ----- - -VIDEO_GET_PTS - -.. attention:: This ioctl is deprecated. - -Synopsis --------- - -.. c:macro:: VIDEO_GET_PTS - -``int ioctl(int fd, VIDEO_GET_PTS, __u64 *pts)`` - -Arguments ---------- - -.. flat-table:: - :header-rows: 0 - :stub-columns: 0 - - - .. row 1 - - - int fd - - - File descriptor returned by a previous call to open(). - - - .. row 2 - - - int request - - - Equals VIDEO_GET_PTS for this command. - - - .. row 3 - - - __u64 \*pts - - - Returns the 33-bit timestamp as defined in ITU T-REC-H.222.0 / - ISO/IEC 13818-1. - - The PTS should belong to the currently played frame if possible, - but may also be a value close to it like the PTS of the last - decoded frame or the last PTS extracted by the PES parser. - -Description ------------ - -This ioctl is obsolete. Do not use in new drivers. For V4L2 decoders -this ioctl has been replaced by the ``V4L2_CID_MPEG_VIDEO_DEC_PTS`` -control. - -This ioctl call asks the Video Device to return the current PTS -timestamp. - -Return Value ------------- - -On success 0 is returned, on error -1 and the ``errno`` variable is set -appropriately. The generic error codes are described at the -:ref:`Generic Error Codes ` chapter. diff --git a/Documentation/userspace-api/media/dvb/video-get-size.rst b/Documentation/userspace-api/media/dvb/video-get-size.rst deleted file mode 100644 index de34331c5bd1..000000000000 --- a/Documentation/userspace-api/media/dvb/video-get-size.rst +++ /dev/null @@ -1,69 +0,0 @@ -.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later -.. c:namespace:: DTV.video - -.. _VIDEO_GET_SIZE: - -============== -VIDEO_GET_SIZE -============== - -Name ----- - -VIDEO_GET_SIZE - -.. attention:: This ioctl is deprecated. - -Synopsis --------- - -.. c:macro:: VIDEO_GET_SIZE - -``int ioctl(int fd, VIDEO_GET_SIZE, video_size_t *size)`` - -Arguments ---------- - -.. flat-table:: - :header-rows: 0 - :stub-columns: 0 - - - .. row 1 - - - int fd - - - File descriptor returned by a previous call to open(). - - - .. row 2 - - - int request - - - Equals VIDEO_GET_SIZE for this command. - - - .. row 3 - - - video_size_t \*size - - - Returns the size and aspect ratio. - -Description ------------ - -This ioctl returns the size and aspect ratio. - -.. c:type:: video_size_t - -.. code-block::c - - typedef struct { - int w; - int h; - video_format_t aspect_ratio; - } video_size_t; - -Return Value ------------- - -On success 0 is returned, on error -1 and the ``errno`` variable is set -appropriately. The generic error codes are described at the -:ref:`Generic Error Codes ` chapter. diff --git a/Documentation/userspace-api/media/dvb/video-get-status.rst b/Documentation/userspace-api/media/dvb/video-get-status.rst deleted file mode 100644 index 9b86fbf411d4..000000000000 --- a/Documentation/userspace-api/media/dvb/video-get-status.rst +++ /dev/null @@ -1,72 +0,0 @@ -.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later -.. c:namespace:: DTV.video - -.. _VIDEO_GET_STATUS: - -================ -VIDEO_GET_STATUS -================ - -Name ----- - -VIDEO_GET_STATUS - -.. attention:: This ioctl is deprecated. - -Synopsis --------- - -.. c:macro:: VIDEO_GET_STATUS - -``int ioctl(fd, VIDEO_GET_STATUS, struct video_status *status)`` - -Arguments ---------- - -.. flat-table:: - :header-rows: 0 - :stub-columns: 0 - - - .. row 1 - - - int fd - - - File descriptor returned by a previous call to open(). - - - .. row 2 - - - int request - - - Equals VIDEO_GET_STATUS for this command. - - - .. row 3 - - - struct video_status \*status - - - Returns the current status of the Video Device. - -Description ------------ - -This ioctl call asks the Video Device to return the current status of -the device. - -.. c:type:: video_status - -.. code-block:: c - - struct video_status { - int video_blank; /* blank video on freeze? */ - video_play_state_t play_state; /* current state of playback */ - video_stream_source_t stream_source; /* current source (demux/memory) */ - video_format_t video_format; /* current aspect ratio of stream*/ - video_displayformat_t display_format;/* selected cropping mode */ - }; - -Return Value ------------- - -On success 0 is returned, on error -1 and the ``errno`` variable is set -appropriately. The generic error codes are described at the -:ref:`Generic Error Codes ` chapter. diff --git a/Documentation/userspace-api/media/dvb/video-play.rst b/Documentation/userspace-api/media/dvb/video-play.rst deleted file mode 100644 index 35ac8b98fdbf..000000000000 --- a/Documentation/userspace-api/media/dvb/video-play.rst +++ /dev/null @@ -1,57 +0,0 @@ -.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later -.. c:namespace:: DTV.video - -.. _VIDEO_PLAY: - -========== -VIDEO_PLAY -========== - -Name ----- - -VIDEO_PLAY - -.. attention:: This ioctl is deprecated. - -Synopsis --------- - -.. c:macro:: VIDEO_PLAY - -``int ioctl(fd, VIDEO_PLAY)`` - -Arguments ---------- - -.. flat-table:: - :header-rows: 0 - :stub-columns: 0 - - - .. row 1 - - - int fd - - - File descriptor returned by a previous call to open(). - - - .. row 2 - - - int request - - - Equals VIDEO_PLAY for this command. - -Description ------------ - -This ioctl is for Digital TV devices only. To control a V4L2 decoder use the -V4L2 :ref:`VIDIOC_DECODER_CMD` instead. - -This ioctl call asks the Video Device to start playing a video stream -from the selected source. - -Return Value ------------- - -On success 0 is returned, on error -1 and the ``errno`` variable is set -appropriately. The generic error codes are described at the -:ref:`Generic Error Codes ` chapter. diff --git a/Documentation/userspace-api/media/dvb/video-select-source.rst b/Documentation/userspace-api/media/dvb/video-select-source.rst deleted file mode 100644 index 929a20985d53..000000000000 --- a/Documentation/userspace-api/media/dvb/video-select-source.rst +++ /dev/null @@ -1,76 +0,0 @@ -.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later -.. c:namespace:: DTV.video - -.. _VIDEO_SELECT_SOURCE: - -=================== -VIDEO_SELECT_SOURCE -=================== - -Name ----- - -VIDEO_SELECT_SOURCE - -.. attention:: This ioctl is deprecated. - -Synopsis --------- - -.. c:macro:: VIDEO_SELECT_SOURCE - -``int ioctl(fd, VIDEO_SELECT_SOURCE, video_stream_source_t source)`` - -Arguments ---------- - -.. flat-table:: - :header-rows: 0 - :stub-columns: 0 - - - .. row 1 - - - int fd - - - File descriptor returned by a previous call to open(). - - - .. row 2 - - - int request - - - Equals VIDEO_SELECT_SOURCE for this command. - - - .. row 3 - - - video_stream_source_t source - - - Indicates which source shall be used for the Video stream. - -Description ------------ - -This ioctl is for Digital TV devices only. This ioctl was also supported by the -V4L2 ivtv driver, but that has been replaced by the ivtv-specific -``IVTV_IOC_PASSTHROUGH_MODE`` ioctl. - -This ioctl call informs the video device which source shall be used for -the input data. The possible sources are demux or memory. If memory is -selected, the data is fed to the video device through the write command. - -.. c:type:: video_stream_source_t - -.. code-block:: c - - typedef enum { - VIDEO_SOURCE_DEMUX, /* Select the demux as the main source */ - VIDEO_SOURCE_MEMORY /* If this source is selected, the stream - comes from the user through the write - system call */ - } video_stream_source_t; - -Return Value ------------- - -On success 0 is returned, on error -1 and the ``errno`` variable is set -appropriately. The generic error codes are described at the -:ref:`Generic Error Codes ` chapter. diff --git a/Documentation/userspace-api/media/dvb/video-set-blank.rst b/Documentation/userspace-api/media/dvb/video-set-blank.rst deleted file mode 100644 index 70249a6ba125..000000000000 --- a/Documentation/userspace-api/media/dvb/video-set-blank.rst +++ /dev/null @@ -1,64 +0,0 @@ -.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later -.. c:namespace:: DTV.video - -.. _VIDEO_SET_BLANK: - -=============== -VIDEO_SET_BLANK -=============== - -Name ----- - -VIDEO_SET_BLANK - -.. attention:: This ioctl is deprecated. - -Synopsis --------- - -.. c:macro:: VIDEO_SET_BLANK - -``int ioctl(fd, VIDEO_SET_BLANK, boolean mode)`` - -Arguments ---------- - -.. flat-table:: - :header-rows: 0 - :stub-columns: 0 - - - .. row 1 - - - int fd - - - File descriptor returned by a previous call to open(). - - - .. row 2 - - - int request - - - Equals VIDEO_SET_BLANK for this command. - - - .. row 3 - - - boolean mode - - - TRUE: Blank screen when stop. - - - .. row 4 - - - - - FALSE: Show last decoded frame. - -Description ------------ - -This ioctl call asks the Video Device to blank out the picture. - -Return Value ------------- - -On success 0 is returned, on error -1 and the ``errno`` variable is set -appropriately. The generic error codes are described at the -:ref:`Generic Error Codes ` chapter. diff --git a/Documentation/userspace-api/media/dvb/video-set-display-format.rst b/Documentation/userspace-api/media/dvb/video-set-display-format.rst deleted file mode 100644 index 1de4f40ae732..000000000000 --- a/Documentation/userspace-api/media/dvb/video-set-display-format.rst +++ /dev/null @@ -1,60 +0,0 @@ -.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later -.. c:namespace:: DTV.video - -.. _VIDEO_SET_DISPLAY_FORMAT: - -======================== -VIDEO_SET_DISPLAY_FORMAT -======================== - -Name ----- - -VIDEO_SET_DISPLAY_FORMAT - -.. attention:: This ioctl is deprecated. - -Synopsis --------- - -.. c:macro:: VIDEO_SET_DISPLAY_FORMAT - -``int ioctl(fd, VIDEO_SET_DISPLAY_FORMAT)`` - -Arguments ---------- - -.. flat-table:: - :header-rows: 0 - :stub-columns: 0 - - - .. row 1 - - - int fd - - - File descriptor returned by a previous call to open(). - - - .. row 2 - - - int request - - - Equals VIDEO_SET_DISPLAY_FORMAT for this command. - - - .. row 3 - - - video_display_format_t format - - - Selects the video format to be used. - -Description ------------ - -This ioctl call asks the Video Device to select the video format to be -applied by the MPEG chip on the video. - -Return Value ------------- - -On success 0 is returned, on error -1 and the ``errno`` variable is set -appropriately. The generic error codes are described at the -:ref:`Generic Error Codes ` chapter. diff --git a/Documentation/userspace-api/media/dvb/video-set-format.rst b/Documentation/userspace-api/media/dvb/video-set-format.rst deleted file mode 100644 index bb64e37ae081..000000000000 --- a/Documentation/userspace-api/media/dvb/video-set-format.rst +++ /dev/null @@ -1,82 +0,0 @@ -.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later -.. c:namespace:: DTV.video - -.. _VIDEO_SET_FORMAT: - -================ -VIDEO_SET_FORMAT -================ - -Name ----- - -VIDEO_SET_FORMAT - -.. attention:: This ioctl is deprecated. - -Synopsis --------- - -.. c:macro:: VIDEO_SET_FORMAT - -``int ioctl(fd, VIDEO_SET_FORMAT, video_format_t format)`` - -Arguments ---------- - -.. flat-table:: - :header-rows: 0 - :stub-columns: 0 - - - .. row 1 - - - int fd - - - File descriptor returned by a previous call to open(). - - - .. row 2 - - - int request - - - Equals VIDEO_SET_FORMAT for this command. - - - .. row 3 - - - video_format_t format - - - video format of TV as defined in section ??. - -Description ------------ - -This ioctl sets the screen format (aspect ratio) of the connected output -device (TV) so that the output of the decoder can be adjusted -accordingly. - -.. c:type:: video_format_t - -.. code-block:: c - - typedef enum { - VIDEO_FORMAT_4_3, /* Select 4:3 format */ - VIDEO_FORMAT_16_9, /* Select 16:9 format. */ - VIDEO_FORMAT_221_1 /* 2.21:1 */ - } video_format_t; - -Return Value ------------- - -On success 0 is returned, on error -1 and the ``errno`` variable is set -appropriately. The generic error codes are described at the -:ref:`Generic Error Codes ` chapter. - - -.. flat-table:: - :header-rows: 0 - :stub-columns: 0 - - - .. row 1 - - - ``EINVAL`` - - - format is not a valid video format. diff --git a/Documentation/userspace-api/media/dvb/video-set-streamtype.rst b/Documentation/userspace-api/media/dvb/video-set-streamtype.rst deleted file mode 100644 index 1f31c048bdbc..000000000000 --- a/Documentation/userspace-api/media/dvb/video-set-streamtype.rst +++ /dev/null @@ -1,61 +0,0 @@ -.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later -.. c:namespace:: DTV.video - -.. _VIDEO_SET_STREAMTYPE: - -==================== -VIDEO_SET_STREAMTYPE -==================== - -Name ----- - -VIDEO_SET_STREAMTYPE - -.. attention:: This ioctl is deprecated. - -Synopsis --------- - -.. c:macro:: VIDEO_SET_STREAMTYPE - -``int ioctl(fd, VIDEO_SET_STREAMTYPE, int type)`` - -Arguments ---------- - -.. flat-table:: - :header-rows: 0 - :stub-columns: 0 - - - .. row 1 - - - int fd - - - File descriptor returned by a previous call to open(). - - - .. row 2 - - - int request - - - Equals VIDEO_SET_STREAMTYPE for this command. - - - .. row 3 - - - int type - - - stream type - -Description ------------ - -This ioctl tells the driver which kind of stream to expect being written -to it. If this call is not used the default of video PES is used. Some -drivers might not support this call and always expect PES. - -Return Value ------------- - -On success 0 is returned, on error -1 and the ``errno`` variable is set -appropriately. The generic error codes are described at the -:ref:`Generic Error Codes ` chapter. diff --git a/Documentation/userspace-api/media/dvb/video-slowmotion.rst b/Documentation/userspace-api/media/dvb/video-slowmotion.rst deleted file mode 100644 index 1478fcc30cb8..000000000000 --- a/Documentation/userspace-api/media/dvb/video-slowmotion.rst +++ /dev/null @@ -1,72 +0,0 @@ -.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later -.. c:namespace:: DTV.video - -.. _VIDEO_SLOWMOTION: - -================ -VIDEO_SLOWMOTION -================ - -Name ----- - -VIDEO_SLOWMOTION - -.. attention:: This ioctl is deprecated. - -Synopsis --------- - -.. c:macro:: VIDEO_SLOWMOTION - -``int ioctl(fd, VIDEO_SLOWMOTION, int nFrames)`` - -Arguments ---------- - -.. flat-table:: - :header-rows: 0 - :stub-columns: 0 - - - .. row 1 - - - int fd - - - File descriptor returned by a previous call to open(). - - - .. row 2 - - - int request - - - Equals VIDEO_SLOWMOTION for this command. - - - .. row 3 - - - int nFrames - - - The number of times to repeat each frame. - -Description ------------ - -This ioctl call asks the video device to repeat decoding frames N number -of times. This call can only be used if VIDEO_SOURCE_MEMORY is -selected. - -Return Value ------------- - -On success 0 is returned, on error -1 and the ``errno`` variable is set -appropriately. The generic error codes are described at the -:ref:`Generic Error Codes ` chapter. - - -.. flat-table:: - :header-rows: 0 - :stub-columns: 0 - - - .. row 1 - - - ``EPERM`` - - - Mode VIDEO_SOURCE_MEMORY not selected. diff --git a/Documentation/userspace-api/media/dvb/video-stillpicture.rst b/Documentation/userspace-api/media/dvb/video-stillpicture.rst deleted file mode 100644 index d25384222a20..000000000000 --- a/Documentation/userspace-api/media/dvb/video-stillpicture.rst +++ /dev/null @@ -1,61 +0,0 @@ -.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later -.. c:namespace:: DTV.video - -.. _VIDEO_STILLPICTURE: - -================== -VIDEO_STILLPICTURE -================== - -Name ----- - -VIDEO_STILLPICTURE - -.. attention:: This ioctl is deprecated. - -Synopsis --------- - -.. c:macro:: VIDEO_STILLPICTURE - -``int ioctl(fd, VIDEO_STILLPICTURE, struct video_still_picture *sp)`` - -Arguments ---------- - -.. flat-table:: - :header-rows: 0 - :stub-columns: 0 - - - .. row 1 - - - int fd - - - File descriptor returned by a previous call to open(). - - - .. row 2 - - - int request - - - Equals VIDEO_STILLPICTURE for this command. - - - .. row 3 - - - struct video_still_picture \*sp - - - Pointer to a location where an I-frame and size is stored. - -Description ------------ - -This ioctl call asks the Video Device to display a still picture -(I-frame). The input data shall contain an I-frame. If the pointer is -NULL, then the current displayed still picture is blanked. - -Return Value ------------- - -On success 0 is returned, on error -1 and the ``errno`` variable is set -appropriately. The generic error codes are described at the -:ref:`Generic Error Codes ` chapter. diff --git a/Documentation/userspace-api/media/dvb/video-stop.rst b/Documentation/userspace-api/media/dvb/video-stop.rst deleted file mode 100644 index 96f61c5b48a2..000000000000 --- a/Documentation/userspace-api/media/dvb/video-stop.rst +++ /dev/null @@ -1,74 +0,0 @@ -.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later -.. c:namespace:: DTV.video - -.. _VIDEO_STOP: - -========== -VIDEO_STOP -========== - -Name ----- - -VIDEO_STOP - -.. attention:: This ioctl is deprecated. - -Synopsis --------- - -.. c:macro:: VIDEO_STOP - -``int ioctl(fd, VIDEO_STOP, boolean mode)`` - -Arguments ---------- - -.. flat-table:: - :header-rows: 0 - :stub-columns: 0 - - - .. row 1 - - - int fd - - - File descriptor returned by a previous call to open(). - - - .. row 2 - - - int request - - - Equals VIDEO_STOP for this command. - - - .. row 3 - - - Boolean mode - - - Indicates how the screen shall be handled. - - - .. row 4 - - - - - TRUE: Blank screen when stop. - - - .. row 5 - - - - - FALSE: Show last decoded frame. - -Description ------------ - -This ioctl is for Digital TV devices only. To control a V4L2 decoder use the -V4L2 :ref:`VIDIOC_DECODER_CMD` instead. - -This ioctl call asks the Video Device to stop playing the current -stream. Depending on the input parameter, the screen can be blanked out -or displaying the last decoded frame. - -Return Value ------------- - -On success 0 is returned, on error -1 and the ``errno`` variable is set -appropriately. The generic error codes are described at the -:ref:`Generic Error Codes ` chapter. diff --git a/Documentation/userspace-api/media/dvb/video-try-command.rst b/Documentation/userspace-api/media/dvb/video-try-command.rst deleted file mode 100644 index 79bf3dfb8a32..000000000000 --- a/Documentation/userspace-api/media/dvb/video-try-command.rst +++ /dev/null @@ -1,66 +0,0 @@ -.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later -.. c:namespace:: DTV.video - -.. _VIDEO_TRY_COMMAND: - -================= -VIDEO_TRY_COMMAND -================= - -Name ----- - -VIDEO_TRY_COMMAND - -.. attention:: This ioctl is deprecated. - -Synopsis --------- - -.. c:macro:: VIDEO_TRY_COMMAND - -``int ioctl(int fd, VIDEO_TRY_COMMAND, struct video_command *cmd)`` - -Arguments ---------- - -.. flat-table:: - :header-rows: 0 - :stub-columns: 0 - - - .. row 1 - - - int fd - - - File descriptor returned by a previous call to open(). - - - .. row 2 - - - int request - - - Equals VIDEO_TRY_COMMAND for this command. - - - .. row 3 - - - struct video_command \*cmd - - - Try a decoder command. - -Description ------------ - -This ioctl is obsolete. Do not use in new drivers. For V4L2 decoders -this ioctl has been replaced by the -:ref:`VIDIOC_TRY_DECODER_CMD ` ioctl. - -This ioctl tries a decoder command. The ``video_command`` struct is a -subset of the ``v4l2_decoder_cmd`` struct, so refer to the -:ref:`VIDIOC_TRY_DECODER_CMD ` documentation -for more information. - -Return Value ------------- - -On success 0 is returned, on error -1 and the ``errno`` variable is set -appropriately. The generic error codes are described at the -:ref:`Generic Error Codes ` chapter. diff --git a/Documentation/userspace-api/media/dvb/video.rst b/Documentation/userspace-api/media/dvb/video.rst deleted file mode 100644 index 808705b769a1..000000000000 --- a/Documentation/userspace-api/media/dvb/video.rst +++ /dev/null @@ -1,36 +0,0 @@ -.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later - -.. _dvb_video: - -####################### -Digital TV Video Device -####################### - -The Digital TV video device controls the MPEG2 video decoder of the Digital -TV hardware. It can be accessed through **/dev/dvb/adapter0/video0**. Data -types and ioctl definitions can be accessed by including -**linux/dvb/video.h** in your application. - -Note that the Digital TV video device only controls decoding of the MPEG video -stream, not its presentation on the TV or computer screen. On PCs this -is typically handled by an associated video4linux device, e.g. -**/dev/video**, which allows scaling and defining output windows. - -Some Digital TV cards don't have their own MPEG decoder, which results in the -omission of the audio and video device as well as the video4linux -device. - -The ioctls that deal with SPUs (sub picture units) and navigation -packets are only supported on some MPEG decoders made for DVD playback. - -These ioctls were also used by V4L2 to control MPEG decoders implemented -in V4L2. The use of these ioctls for that purpose has been made obsolete -and proper V4L2 ioctls or controls have been created to replace that -functionality. - - -.. toctree:: - :maxdepth: 1 - - video_types - video_function_calls diff --git a/Documentation/userspace-api/media/dvb/video_function_calls.rst b/Documentation/userspace-api/media/dvb/video_function_calls.rst deleted file mode 100644 index 20a897be5dca..000000000000 --- a/Documentation/userspace-api/media/dvb/video_function_calls.rst +++ /dev/null @@ -1,35 +0,0 @@ -.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later - -.. _video_function_calls: - -******************** -Video Function Calls -******************** - -.. toctree:: - :maxdepth: 1 - - video-fopen - video-fclose - video-fwrite - video-stop - video-play - video-freeze - video-continue - video-select-source - video-set-blank - video-get-status - video-get-frame-count - video-get-pts - video-get-event - video-command - video-try-command - video-get-size - video-set-display-format - video-stillpicture - video-fast-forward - video-slowmotion - video-get-capabilities - video-clear-buffer - video-set-streamtype - video-set-format diff --git a/Documentation/userspace-api/media/dvb/video_types.rst b/Documentation/userspace-api/media/dvb/video_types.rst deleted file mode 100644 index c4557d328b7a..000000000000 --- a/Documentation/userspace-api/media/dvb/video_types.rst +++ /dev/null @@ -1,248 +0,0 @@ -.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later - -.. _video_types: - -**************** -Video Data Types -**************** - - -.. _video-format-t: - -video_format_t -============== - -The ``video_format_t`` data type defined by - - -.. code-block:: c - - typedef enum { - VIDEO_FORMAT_4_3, /* Select 4:3 format */ - VIDEO_FORMAT_16_9, /* Select 16:9 format. */ - VIDEO_FORMAT_221_1 /* 2.21:1 */ - } video_format_t; - -is used in the VIDEO_SET_FORMAT function (??) to tell the driver which -aspect ratio the output hardware (e.g. TV) has. It is also used in the -data structures video_status (??) returned by VIDEO_GET_STATUS (??) -and video_event (??) returned by VIDEO_GET_EVENT (??) which report -about the display format of the current video stream. - - -.. _video-displayformat-t: - -video_displayformat_t -===================== - -In case the display format of the video stream and of the display -hardware differ the application has to specify how to handle the -cropping of the picture. This can be done using the -VIDEO_SET_DISPLAY_FORMAT call (??) which accepts - - -.. code-block:: c - - typedef enum { - VIDEO_PAN_SCAN, /* use pan and scan format */ - VIDEO_LETTER_BOX, /* use letterbox format */ - VIDEO_CENTER_CUT_OUT /* use center cut out format */ - } video_displayformat_t; - -as argument. - - -.. _video-stream-source-t: - -video_stream_source_t -===================== - -The video stream source is set through the VIDEO_SELECT_SOURCE call -and can take the following values, depending on whether we are replaying -from an internal (demuxer) or external (user write) source. - - -.. code-block:: c - - typedef enum { - VIDEO_SOURCE_DEMUX, /* Select the demux as the main source */ - VIDEO_SOURCE_MEMORY /* If this source is selected, the stream - comes from the user through the write - system call */ - } video_stream_source_t; - -VIDEO_SOURCE_DEMUX selects the demultiplexer (fed either by the -frontend or the DVR device) as the source of the video stream. If -VIDEO_SOURCE_MEMORY is selected the stream comes from the application -through the **write()** system call. - - -.. _video-play-state-t: - -video_play_state_t -================== - -The following values can be returned by the VIDEO_GET_STATUS call -representing the state of video playback. - - -.. code-block:: c - - typedef enum { - VIDEO_STOPPED, /* Video is stopped */ - VIDEO_PLAYING, /* Video is currently playing */ - VIDEO_FREEZED /* Video is freezed */ - } video_play_state_t; - - -.. c:type:: video_command - -struct video_command -==================== - -The structure must be zeroed before use by the application This ensures -it can be extended safely in the future. - - -.. code-block:: c - - struct video_command { - __u32 cmd; - __u32 flags; - union { - struct { - __u64 pts; - } stop; - - struct { - /* 0 or 1000 specifies normal speed, - 1 specifies forward single stepping, - -1 specifies backward single stepping, - >>1: playback at speed/1000 of the normal speed, - <-1: reverse playback at (-speed/1000) of the normal speed. */ - __s32 speed; - __u32 format; - } play; - - struct { - __u32 data[16]; - } raw; - }; - }; - - -.. _video-size-t: - -video_size_t -============ - - -.. code-block:: c - - typedef struct { - int w; - int h; - video_format_t aspect_ratio; - } video_size_t; - - -.. c:type:: video_event - -struct video_event -================== - -The following is the structure of a video event as it is returned by the -VIDEO_GET_EVENT call. - - -.. code-block:: c - - struct video_event { - __s32 type; - #define VIDEO_EVENT_SIZE_CHANGED 1 - #define VIDEO_EVENT_FRAME_RATE_CHANGED 2 - #define VIDEO_EVENT_DECODER_STOPPED 3 - #define VIDEO_EVENT_VSYNC 4 - long timestamp; - union { - video_size_t size; - unsigned int frame_rate; /* in frames per 1000sec */ - unsigned char vsync_field; /* unknown/odd/even/progressive */ - } u; - }; - - -.. c:type:: video_status - -struct video_status -=================== - -The VIDEO_GET_STATUS call returns the following structure informing -about various states of the playback operation. - - -.. code-block:: c - - struct video_status { - int video_blank; /* blank video on freeze? */ - video_play_state_t play_state; /* current state of playback */ - video_stream_source_t stream_source; /* current source (demux/memory) */ - video_format_t video_format; /* current aspect ratio of stream */ - video_displayformat_t display_format;/* selected cropping mode */ - }; - -If video_blank is set video will be blanked out if the channel is -changed or if playback is stopped. Otherwise, the last picture will be -displayed. play_state indicates if the video is currently frozen, -stopped, or being played back. The stream_source corresponds to the -selected source for the video stream. It can come either from the -demultiplexer or from memory. The video_format indicates the aspect -ratio (one of 4:3 or 16:9) of the currently played video stream. -Finally, display_format corresponds to the selected cropping mode in -case the source video format is not the same as the format of the output -device. - - -.. c:type:: video_still_picture - -struct video_still_picture -========================== - -An I-frame displayed via the VIDEO_STILLPICTURE call is passed on -within the following structure. - - -.. code-block:: c - - /* pointer to and size of a single iframe in memory */ - struct video_still_picture { - char *iFrame; /* pointer to a single iframe in memory */ - int32_t size; - }; - - -.. _video_caps: - -video capabilities -================== - -A call to VIDEO_GET_CAPABILITIES returns an unsigned integer with the -following bits set according to the hardwares capabilities. - - -.. code-block:: c - - /* bit definitions for capabilities: */ - /* can the hardware decode MPEG1 and/or MPEG2? */ - #define VIDEO_CAP_MPEG1 1 - #define VIDEO_CAP_MPEG2 2 - /* can you send a system and/or program stream to video device? - (you still have to open the video and the audio device but only - send the stream to the video device) */ - #define VIDEO_CAP_SYS 4 - #define VIDEO_CAP_PROG 8 - /* can the driver also handle SPU, NAVI and CSS encoded data? - (CSS API is not present yet) */ - #define VIDEO_CAP_SPU 16 - #define VIDEO_CAP_NAVI 32 - #define VIDEO_CAP_CSS 64 diff --git a/Documentation/userspace-api/media/video.h.rst.exceptions b/Documentation/userspace-api/media/video.h.rst.exceptions deleted file mode 100644 index ea9de59ad8b7..000000000000 --- a/Documentation/userspace-api/media/video.h.rst.exceptions +++ /dev/null @@ -1,39 +0,0 @@ -# SPDX-License-Identifier: GPL-2.0 - -# Ignore header name -ignore define _UAPI_DVBVIDEO_H_ - -# This is a deprecated obscure API. Just ignore things we don't know -ignore define VIDEO_CMD_PLAY -ignore define VIDEO_CMD_STOP -ignore define VIDEO_CMD_FREEZE -ignore define VIDEO_CMD_CONTINUE -ignore define VIDEO_CMD_FREEZE_TO_BLACK -ignore define VIDEO_CMD_STOP_TO_BLACK -ignore define VIDEO_CMD_STOP_IMMEDIATELY -ignore define VIDEO_PLAY_FMT_NONE -ignore define VIDEO_PLAY_FMT_GOP -ignore define VIDEO_VSYNC_FIELD_UNKNOWN -ignore define VIDEO_VSYNC_FIELD_ODD -ignore define VIDEO_VSYNC_FIELD_EVEN -ignore define VIDEO_VSYNC_FIELD_PROGRESSIVE -ignore define VIDEO_EVENT_SIZE_CHANGED -ignore define VIDEO_EVENT_FRAME_RATE_CHANGED -ignore define VIDEO_EVENT_DECODER_STOPPED -ignore define VIDEO_EVENT_VSYNC -ignore define VIDEO_CAP_MPEG1 -ignore define VIDEO_CAP_MPEG2 -ignore define VIDEO_CAP_SYS -ignore define VIDEO_CAP_PROG -ignore define VIDEO_CAP_SPU -ignore define VIDEO_CAP_NAVI -ignore define VIDEO_CAP_CSS - -# some typedefs should point to struct/enums -replace typedef video_format_t :c:type:`video_format` -replace typedef video_system_t :c:type:`video_system` -replace typedef video_displayformat_t :c:type:`video_displayformat` -replace typedef video_size_t :c:type:`video_size` -replace typedef video_stream_source_t :c:type:`video_stream_source` -replace typedef video_play_state_t :c:type:`video_play_state` -replace typedef video_navi_pack_t :c:type:`video_navi_pack` -- cgit v1.2.3 From 9e40ee18a1dc1623a5368d6232aaed52fd29dada Mon Sep 17 00:00:00 2001 From: Clemens Gruber Date: Fri, 7 May 2021 15:18:42 +0200 Subject: pwm: core: Support new usage_power setting in PWM state If usage_power is set, the PWM driver is only required to maintain the power output but has more freedom regarding signal form. If supported, the signal can be optimized, for example to improve EMI by phase shifting individual channels. Signed-off-by: Clemens Gruber Signed-off-by: Thierry Reding --- Documentation/driver-api/pwm.rst | 4 ++++ 1 file changed, 4 insertions(+) (limited to 'Documentation') diff --git a/Documentation/driver-api/pwm.rst b/Documentation/driver-api/pwm.rst index a7ca4f58305a..750734a7f874 100644 --- a/Documentation/driver-api/pwm.rst +++ b/Documentation/driver-api/pwm.rst @@ -48,6 +48,10 @@ After being requested, a PWM has to be configured using:: This API controls both the PWM period/duty_cycle config and the enable/disable state. +There is also a usage_power setting: If set, the PWM driver is only required to +maintain the power output but has more freedom regarding signal form. +If supported by the driver, the signal can be optimized, for example to improve +EMI by phase shifting the individual channels of a chip. The pwm_config(), pwm_enable() and pwm_disable() functions are just wrappers around pwm_apply_state() and should not be used if the user wants to change -- cgit v1.2.3 From 2ba4597d932b45b25bc2e6604c1dbbb08e444cb7 Mon Sep 17 00:00:00 2001 From: Lokesh Vutla Date: Tue, 1 Jun 2021 11:14:01 +0530 Subject: dt-bindings: pwm: pwm-tiehrpwm: Convert to json schema Convert the tiehrpwm binding to DT schema format using json-schema. Along with this conversion the following changes are included: - 'clock' and 'clock-names' properties are marked as required as driver fails to probe without these properties - Dropped ti,am33xx-ehrpwm as it is no longer applicable. - 'power-domains' property is introduced and marked as optional. Signed-off-by: Lokesh Vutla Reviewed-by: Rob Herring Signed-off-by: Thierry Reding --- .../devicetree/bindings/pwm/pwm-tiehrpwm.txt | 50 ----------------- .../devicetree/bindings/pwm/pwm-tiehrpwm.yaml | 64 ++++++++++++++++++++++ 2 files changed, 64 insertions(+), 50 deletions(-) delete mode 100644 Documentation/devicetree/bindings/pwm/pwm-tiehrpwm.txt create mode 100644 Documentation/devicetree/bindings/pwm/pwm-tiehrpwm.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pwm/pwm-tiehrpwm.txt b/Documentation/devicetree/bindings/pwm/pwm-tiehrpwm.txt deleted file mode 100644 index c7e28f6d28be..000000000000 --- a/Documentation/devicetree/bindings/pwm/pwm-tiehrpwm.txt +++ /dev/null @@ -1,50 +0,0 @@ -TI SOC EHRPWM based PWM controller - -Required properties: -- compatible: Must be "ti,-ehrpwm". - for am33xx - compatible = "ti,am3352-ehrpwm", "ti,am33xx-ehrpwm"; - for am4372 - compatible = "ti,am4372-ehrpwm", "ti-am3352-ehrpwm", "ti,am33xx-ehrpwm"; - for am654 - compatible = "ti,am654-ehrpwm", "ti-am3352-ehrpwm"; - for da850 - compatible = "ti,da850-ehrpwm", "ti-am3352-ehrpwm", "ti,am33xx-ehrpwm"; - for dra746 - compatible = "ti,dra746-ehrpwm", "ti-am3352-ehrpwm"; -- #pwm-cells: should be 3. See pwm.yaml in this directory for a description of - the cells format. The only third cell flag supported by this binding is - PWM_POLARITY_INVERTED. -- reg: physical base address and size of the registers map. - -Optional properties: -- clocks: Handle to the PWM's time-base and functional clock. -- clock-names: Must be set to "tbclk" and "fck". - -Example: - -ehrpwm0: pwm@48300200 { /* EHRPWM on am33xx */ - compatible = "ti,am3352-ehrpwm", "ti,am33xx-ehrpwm"; - #pwm-cells = <3>; - reg = <0x48300200 0x100>; - clocks = <&ehrpwm0_tbclk>, <&l4ls_gclk>; - clock-names = "tbclk", "fck"; -}; - -ehrpwm0: pwm@48300200 { /* EHRPWM on am4372 */ - compatible = "ti,am4372-ehrpwm", "ti,am3352-ehrpwm", "ti,am33xx-ehrpwm"; - #pwm-cells = <3>; - reg = <0x48300200 0x80>; - clocks = <&ehrpwm0_tbclk>, <&l4ls_gclk>; - clock-names = "tbclk", "fck"; - ti,hwmods = "ehrpwm0"; -}; - -ehrpwm0: pwm@1f00000 { /* EHRPWM on da850 */ - compatible = "ti,da850-ehrpwm", "ti,am3352-ehrpwm", "ti,am33xx-ehrpwm"; - #pwm-cells = <3>; - reg = <0x1f00000 0x2000>; -}; - -ehrpwm0: pwm@4843e200 { /* EHRPWM on dra746 */ - compatible = "ti,dra746-ehrpwm", "ti,am3352-ehrpwm"; - #pwm-cells = <3>; - reg = <0x4843e200 0x80>; - clocks = <&ehrpwm0_tbclk>, <&l4_root_clk_div>; - clock-names = "tbclk", "fck"; -}; diff --git a/Documentation/devicetree/bindings/pwm/pwm-tiehrpwm.yaml b/Documentation/devicetree/bindings/pwm/pwm-tiehrpwm.yaml new file mode 100644 index 000000000000..84a8d6d38cee --- /dev/null +++ b/Documentation/devicetree/bindings/pwm/pwm-tiehrpwm.yaml @@ -0,0 +1,64 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pwm/pwm-tiehrpwm.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: TI SOC EHRPWM based PWM controller + +maintainers: + - Vignesh R + +allOf: + - $ref: pwm.yaml# + +properties: + compatible: + oneOf: + - const: ti,am3352-ehrpwm + - items: + - enum: + - ti,da850-ehrpwm + - ti,am4372-ehrpwm + - ti,dra746-ehrpwm + - ti,am654-ehrpwm + - const: ti,am3352-ehrpwm + + reg: + maxItems: 1 + + "#pwm-cells": + const: 3 + description: | + See pwm.yaml in this directory for a description of the cells format. + The only third cell flag supported by this binding is PWM_POLARITY_INVERTED. + + clock-names: + items: + - const: tbclk + - const: fck + + clocks: + maxItems: 2 + + power-domains: + maxItems: 1 + +required: + - compatible + - reg + - "#pwm-cells" + - clocks + - clock-names + +additionalProperties: false + +examples: + - | + ehrpwm0: pwm@48300200 { /* EHRPWM on am33xx */ + compatible = "ti,am3352-ehrpwm"; + #pwm-cells = <3>; + reg = <0x48300200 0x100>; + clocks = <&ehrpwm0_tbclk>, <&l4ls_gclk>; + clock-names = "tbclk", "fck"; + }; -- cgit v1.2.3 From d233504af7db9f4ddbbc4b04513d5ca657e7ae1f Mon Sep 17 00:00:00 2001 From: Lokesh Vutla Date: Tue, 1 Jun 2021 11:14:02 +0530 Subject: dt-bindings: pwm: pwm-tiehrpwm: Add compatible string for AM64 SoC Add compatible string for AM64 SoC in device tree binding. EPWM IP in AM64 does not support High resolution, so named epwm instead of ehrpwm in compatible. However IP is till compatible with features supported by driver with ti,am3352-ehrpwm compatible. Signed-off-by: Lokesh Vutla Reviewed-by: Rob Herring Signed-off-by: Thierry Reding --- Documentation/devicetree/bindings/pwm/pwm-tiehrpwm.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pwm/pwm-tiehrpwm.yaml b/Documentation/devicetree/bindings/pwm/pwm-tiehrpwm.yaml index 84a8d6d38cee..ee312cb210e6 100644 --- a/Documentation/devicetree/bindings/pwm/pwm-tiehrpwm.yaml +++ b/Documentation/devicetree/bindings/pwm/pwm-tiehrpwm.yaml @@ -22,6 +22,7 @@ properties: - ti,am4372-ehrpwm - ti,dra746-ehrpwm - ti,am654-ehrpwm + - ti,am64-epwm - const: ti,am3352-ehrpwm reg: -- cgit v1.2.3 From 8bb2314fc22628333d89df83d695ff9a8d2a6eac Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Wed, 26 May 2021 13:20:36 -0400 Subject: power: supply: max17040: Do not enforce (incorrect) interrupt trigger type Interrupt line can be configured on different hardware in different way, even inverted. Therefore driver should not enforce specific trigger type - edge falling - but instead rely on Devicetree to configure it. The Maxim 14577/77836 datasheets describe the interrupt line as active low with a requirement of acknowledge from the CPU therefore the edge falling is not correct. Signed-off-by: Krzysztof Kozlowski Acked-by: Iskren Chernev Acked-by: Rob Herring Signed-off-by: Sebastian Reichel --- Documentation/devicetree/bindings/power/supply/maxim,max17040.yaml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/power/supply/maxim,max17040.yaml b/Documentation/devicetree/bindings/power/supply/maxim,max17040.yaml index de91cf3f058c..f792d06db413 100644 --- a/Documentation/devicetree/bindings/power/supply/maxim,max17040.yaml +++ b/Documentation/devicetree/bindings/power/supply/maxim,max17040.yaml @@ -89,7 +89,7 @@ examples: reg = <0x36>; maxim,alert-low-soc-level = <10>; interrupt-parent = <&gpio7>; - interrupts = <2 IRQ_TYPE_EDGE_FALLING>; + interrupts = <2 IRQ_TYPE_LEVEL_LOW>; wakeup-source; }; }; -- cgit v1.2.3 From 4a8fd33517daa6020f10c31f609f9ec8a07775f8 Mon Sep 17 00:00:00 2001 From: Stephan Gerhold Date: Mon, 17 May 2021 12:51:11 +0200 Subject: dt-bindings: power: supply: Add DT schema for richtek,rt5033-battery The RT5033 PMIC provides a simple fuel gauge via I2C. Add a DT schema to describe how to set it up in the device tree. Note that although RT5033 is a MFD with lots of functionality (also charger, regulator, LEDs, ...) the fuel gauge has a separate I2C bus and is not part of the MFD. Cc: Beomho Seo Signed-off-by: Stephan Gerhold Reviewed-by: Rob Herring Signed-off-by: Sebastian Reichel --- .../power/supply/richtek,rt5033-battery.yaml | 54 ++++++++++++++++++++++ 1 file changed, 54 insertions(+) create mode 100644 Documentation/devicetree/bindings/power/supply/richtek,rt5033-battery.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/power/supply/richtek,rt5033-battery.yaml b/Documentation/devicetree/bindings/power/supply/richtek,rt5033-battery.yaml new file mode 100644 index 000000000000..ae647d3355a2 --- /dev/null +++ b/Documentation/devicetree/bindings/power/supply/richtek,rt5033-battery.yaml @@ -0,0 +1,54 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/power/supply/richtek,rt5033-battery.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: Richtek RT5033 PMIC Fuel Gauge + +maintainers: + - Stephan Gerhold + +allOf: + - $ref: power-supply.yaml# + +properties: + compatible: + const: richtek,rt5033-battery + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + battery@35 { + compatible = "richtek,rt5033-battery"; + reg = <0x35>; + }; + }; + - | + #include + i2c { + #address-cells = <1>; + #size-cells = <0>; + + battery@35 { + compatible = "richtek,rt5033-battery"; + reg = <0x35>; + interrupt-parent = <&msmgpio>; + interrupts = <121 IRQ_TYPE_EDGE_FALLING>; + }; + }; -- cgit v1.2.3 From ab1150e9576f5889107568329ebc62902ed83682 Mon Sep 17 00:00:00 2001 From: Aswath Govindraju Date: Fri, 28 May 2021 11:36:57 +0530 Subject: doc: dt-binding: cdns,usb3: Add interrupt-names property under required In the driver the interrupts are fetched by name. Therefore, add interrupt names in the list of required properties Fixes: 68989fe1c39d ("dt-bindings: usb: Convert cdns-usb3.txt to YAML schema") Signed-off-by: Aswath Govindraju Link: https://lore.kernel.org/r/20210528060657.29100-1-a-govindraju@ti.com Signed-off-by: Greg Kroah-Hartman --- Documentation/devicetree/bindings/usb/cdns,usb3.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/usb/cdns,usb3.yaml b/Documentation/devicetree/bindings/usb/cdns,usb3.yaml index 8dedfa16c992..dc9d6ed0781d 100644 --- a/Documentation/devicetree/bindings/usb/cdns,usb3.yaml +++ b/Documentation/devicetree/bindings/usb/cdns,usb3.yaml @@ -75,6 +75,7 @@ required: - reg - reg-names - interrupts + - interrupt-names additionalProperties: false -- cgit v1.2.3 From db0a196bd8ad1d6bb4b1a9e54f54c09f8dc2cc25 Mon Sep 17 00:00:00 2001 From: Fabien Lahoudere Date: Fri, 30 Apr 2021 19:50:37 +0200 Subject: serial: imx: Add DMA buffer configuration via DT In order to optimize serial communication (performance/throughput VS latency), we may need to tweak DMA period number and size. This adds DT properties to configure those values before initialising DMA. The defaults will stay the same as before. [update documentation and commit message, rebase to current master, switch back to DT instead of sysfs] Signed-off-by: Fabien Lahoudere Signed-off-by: Sebastian Reichel Link: https://lore.kernel.org/r/20210430175038.103226-2-sebastian.reichel@collabora.com Signed-off-by: Greg Kroah-Hartman --- Documentation/devicetree/bindings/serial/fsl-imx-uart.yaml | 12 ++++++++++++ 1 file changed, 12 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/serial/fsl-imx-uart.yaml b/Documentation/devicetree/bindings/serial/fsl-imx-uart.yaml index 2b06c6ce4a75..9d949296a142 100644 --- a/Documentation/devicetree/bindings/serial/fsl-imx-uart.yaml +++ b/Documentation/devicetree/bindings/serial/fsl-imx-uart.yaml @@ -71,6 +71,18 @@ properties: received, and that the peripheral should invert its input using the INVR registers. + fsl,dma-info: + $ref: /schemas/types.yaml#/definitions/uint32-array + minItems: 2 + maxItems: 2 + description: | + First cell contains the size of DMA buffer chunks, second cell contains + the amount of chunks used for the device. Multiplying both numbers is + the total size of memory used for receiving data. + When not being configured the system will use default settings, which + are sensible for most use cases. If you need low latency processing on + slow connections this needs to be configured appropriately. + uart-has-rtscts: true rs485-rts-delay: true -- cgit v1.2.3 From 92e669017ff1616ba7d8ba3c65f5193bc2a7acbe Mon Sep 17 00:00:00 2001 From: Nicolas Ferre Date: Fri, 4 Jun 2021 15:19:25 +0200 Subject: dt-bindings: i2c: at91: fix example for scl-gpios The SCL gpio pin used by I2C bus for recovery needs to be configured as open drain, so fix the binding example accordingly. In relation with fix c5a283802573 ("ARM: dts: at91: Configure I2C SCL gpio as open drain"). Signed-off-by: Nicolas Ferre Fixes: 19e5cef058a0 ("dt-bindings: i2c: at91: document optional bus recovery properties") --- Documentation/devicetree/bindings/i2c/i2c-at91.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/i2c/i2c-at91.txt b/Documentation/devicetree/bindings/i2c/i2c-at91.txt index 96c914e048f5..2015f50aed0f 100644 --- a/Documentation/devicetree/bindings/i2c/i2c-at91.txt +++ b/Documentation/devicetree/bindings/i2c/i2c-at91.txt @@ -73,7 +73,7 @@ i2c0: i2c@f8034600 { pinctrl-0 = <&pinctrl_i2c0>; pinctrl-1 = <&pinctrl_i2c0_gpio>; sda-gpios = <&pioA 30 GPIO_ACTIVE_HIGH>; - scl-gpios = <&pioA 31 GPIO_ACTIVE_HIGH>; + scl-gpios = <&pioA 31 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>; wm8731: wm8731@1a { compatible = "wm8731"; -- cgit v1.2.3 From c6d25d5786090edc7299b32160644bb2e468c25d Mon Sep 17 00:00:00 2001 From: Srinivas Kandagatla Date: Fri, 4 Jun 2021 12:52:27 +0100 Subject: ASoC: dt-bindings: wcd934x: add bindings for Headset Button detection Add bindings required for Multi Button Headset detection. WCD934x support Headsets with upto 8 buttons including, impedance measurement on both L/R Headset speakers and cross connection detection. Signed-off-by: Srinivas Kandagatla Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20210604115230.23259-2-srinivas.kandagatla@linaro.org Signed-off-by: Mark Brown --- .../devicetree/bindings/sound/qcom,wcd934x.yaml | 30 ++++++++++++++++++++++ 1 file changed, 30 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/qcom,wcd934x.yaml b/Documentation/devicetree/bindings/sound/qcom,wcd934x.yaml index e8f716b5f875..9b225dbf8b79 100644 --- a/Documentation/devicetree/bindings/sound/qcom,wcd934x.yaml +++ b/Documentation/devicetree/bindings/sound/qcom,wcd934x.yaml @@ -77,6 +77,31 @@ properties: minimum: 1800000 maximum: 2850000 + qcom,hphl-jack-type-normally-closed: + description: Indicates that HPHL jack switch type is normally closed + type: boolean + + qcom,ground-jack-type-normally-closed: + description: Indicates that Headset Ground switch type is normally closed + type: boolean + + qcom,mbhc-headset-vthreshold-microvolt: + description: Voltage threshold value for headset detection + minimum: 0 + maximum: 2850000 + + qcom,mbhc-headphone-vthreshold-microvolt: + description: Voltage threshold value for headphone detection + minimum: 0 + maximum: 2850000 + + qcom,mbhc-buttons-vthreshold-microvolt: + description: + Array of 8 Voltage threshold values corresponding to headset + button0 - button7 + minItems: 8 + maxItems: 8 + clock-output-names: const: mclk @@ -159,6 +184,11 @@ examples: qcom,micbias2-microvolt = <1800000>; qcom,micbias3-microvolt = <1800000>; qcom,micbias4-microvolt = <1800000>; + qcom,hphl-jack-type-normally-closed; + qcom,ground-jack-type-normally-closed; + qcom,mbhc-buttons-vthreshold-microvolt = <75000 150000 237000 500000 500000 500000 500000 500000>; + qcom,mbhc-headset-vthreshold-microvolt = <1700000>; + qcom,mbhc-headphone-vthreshold-microvolt = <50000>; clock-names = "extclk"; clocks = <&rpmhcc 2>; -- cgit v1.2.3 From b1e650db2cc4acca6e7c9974f6a2ca232261173a Mon Sep 17 00:00:00 2001 From: Joerg Roedel Date: Thu, 3 Jun 2021 15:02:03 +0200 Subject: iommu/amd: Add amd_iommu=force_enable option Add this option to enable the IOMMU on platforms like AMD Stoney, where the kernel usually disables it because it may cause problems in some scenarios. Signed-off-by: Joerg Roedel Acked-by: Alex Deucher Link: https://lore.kernel.org/r/20210603130203.29016-1-joro@8bytes.org --- 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 cb89dbdedc46..f6bf4e87df80 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -301,6 +301,9 @@ allowed anymore to lift isolation requirements as needed. This option does not override iommu=pt + force_enable - Force enable the IOMMU on platforms known + to be buggy with IOMMU enabled. Use this + option with care. amd_iommu_dump= [HW,X86-64] Enable AMD IOMMU driver option to dump the ACPI table -- cgit v1.2.3 From a7673a1c1acdd81aa462997a4c3b8f24464a8eeb Mon Sep 17 00:00:00 2001 From: Sathishkumar S Date: Sun, 30 May 2021 09:45:26 +0530 Subject: drm/amd/pm: sysfs attrs to read ss powershare (v6) add sysfs attrs to read smartshift APU and DGPU power share. document the sysfs device attributes. V2: change variable/macro name for stapm power limit (Lijo) V3: files to be exposed as sysfs device attributes (Alex) V4: check ret value of sysfs create and remove only if created. V5: add ss attrs in amdgpu_device_attrs and use attr_update (Lijo) V6: all checks for ss support to be in if else if statements. (Lijo) Signed-off-by: Sathishkumar S Reviewed-by: Lijo Lazar Signed-off-by: Alex Deucher --- Documentation/gpu/amdgpu.rst | 15 +++++++++++++++ 1 file changed, 15 insertions(+) (limited to 'Documentation') diff --git a/Documentation/gpu/amdgpu.rst b/Documentation/gpu/amdgpu.rst index 2062a6023678..6cce26b5621e 100644 --- a/Documentation/gpu/amdgpu.rst +++ b/Documentation/gpu/amdgpu.rst @@ -300,4 +300,19 @@ pcie_replay_count .. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_device.c :doc: pcie_replay_count ++GPU SmartShift Information +============================ + +GPU SmartShift information via sysfs +smartshift_apu_power +-------------------- + +.. kernel-doc:: drivers/gpu/drm/amd/pm/amdgpu_pm.c + :doc: smartshift_apu_power + +smartshift_dgpu_power +--------------------- + +.. kernel-doc:: drivers/gpu/drm/amd/pm/amdgpu_pm.c + :doc: smartshift_dgpu_power -- cgit v1.2.3 From 30d95a37f46d1be90048c565d3ec380ddecb0541 Mon Sep 17 00:00:00 2001 From: Sathishkumar S Date: Sun, 30 May 2021 10:47:16 +0530 Subject: drm/amdgpu: attr to control SS2.0 bias level (v2) add sysfs attr to read/write smartshift bias level. document smartshift_bias sysfs attr. V2: add attr to amdgpu_device_attrs and use attr_update (Lijo) Signed-off-by: Sathishkumar S Reviewed-by: Lijo Lazar Signed-off-by: Alex Deucher --- Documentation/gpu/amdgpu.rst | 6 ++++++ 1 file changed, 6 insertions(+) (limited to 'Documentation') diff --git a/Documentation/gpu/amdgpu.rst b/Documentation/gpu/amdgpu.rst index 6cce26b5621e..364680cdad2e 100644 --- a/Documentation/gpu/amdgpu.rst +++ b/Documentation/gpu/amdgpu.rst @@ -316,3 +316,9 @@ smartshift_dgpu_power .. kernel-doc:: drivers/gpu/drm/amd/pm/amdgpu_pm.c :doc: smartshift_dgpu_power + +smartshift_bias +--------------- + +.. kernel-doc:: drivers/gpu/drm/amd/pm/amdgpu_pm.c + :doc: smartshift_bias -- cgit v1.2.3 From 52ea62e74ecf3dd60e6df0479320213470e2ae7f Mon Sep 17 00:00:00 2001 From: Yanteng Si Date: Fri, 4 Jun 2021 17:06:55 +0800 Subject: docs/zh_CN: add core api cachetlb translation Translate Documentation/core-api/cachetlb.rst into Chinese. Reviewed-by: Wu XiangCheng Signed-off-by: Yanteng Si Reviewed-by: Alex Shi Link: https://lore.kernel.org/r/20210604090655.1971227-1-siyanteng@loongson.cn Signed-off-by: Jonathan Corbet --- .../translations/zh_CN/core-api/cachetlb.rst | 336 +++++++++++++++++++++ .../translations/zh_CN/core-api/index.rst | 7 +- 2 files changed, 342 insertions(+), 1 deletion(-) create mode 100644 Documentation/translations/zh_CN/core-api/cachetlb.rst (limited to 'Documentation') diff --git a/Documentation/translations/zh_CN/core-api/cachetlb.rst b/Documentation/translations/zh_CN/core-api/cachetlb.rst new file mode 100644 index 000000000000..8376485a534d --- /dev/null +++ b/Documentation/translations/zh_CN/core-api/cachetlb.rst @@ -0,0 +1,336 @@ +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/core-api/cachetlb.rst + +:翻译: + + 司延腾 Yanteng Si + +:校译: + + 吴想成 Wu XiangCheng + +.. _cn_core-api_cachetlb: + +====================== +Linux下的缓存和TLB刷新 +====================== + +:作者: David S. Miller + +*译注：TLB，Translation Lookaside Buffer，页表缓存/变换旁查缓冲器* + +本文描述了由Linux虚拟内存子系统调用的缓存/TLB刷新接口。它列举了每个接 +口，描述了它的预期目的，以及接口被调用后的预期副作用。 + +下面描述的副作用是针对单处理器的实现，以及在单个处理器上发生的情况。若 +为SMP，则只需将定义简单地扩展一下，使发生在某个特定接口的副作用扩展到系 +统的所有处理器上。不要被这句话吓到，以为SMP的缓存/tlb刷新一定是很低 +效的，事实上，这是一个可以进行很多优化的领域。例如，如果可以证明一个用 +户地址空间从未在某个cpu上执行过（见mm_cpumask()），那么就不需要在该 +cpu上对这个地址空间进行刷新。 + +首先是TLB刷新接口，因为它们是最简单的。在Linux下，TLB被抽象为cpu +用来缓存从软件页表获得的虚拟->物理地址转换的东西。这意味着，如果软件页 +表发生变化，这个“TLB”缓存中就有可能出现过时（脏）的翻译。因此，当软件页表 +发生变化时，内核会在页表发生 *变化后* 调用以下一种刷新方法： + +1) ``void flush_tlb_all(void)`` + + 最严格的刷新。在这个接口运行后，任何以前的页表修改都会对cpu可见。 + + 这通常是在内核页表被改变时调用的，因为这种转换在本质上是“全局”的。 + +2) ``void flush_tlb_mm(struct mm_struct *mm)`` + + 这个接口从TLB中刷新整个用户地址空间。在运行后，这个接口必须确保 + 以前对地址空间‘mm’的任何页表修改对cpu来说是可见的。也就是说，在 + 运行后，TLB中不会有‘mm’的页表项。 + + 这个接口被用来处理整个地址空间的页表操作，比如在fork和exec过程 + 中发生的事情。 + +3) ``void flush_tlb_range(struct vm_area_struct *vma, + unsigned long start, unsigned long end)`` + + 这里我们要从TLB中刷新一个特定范围的（用户）虚拟地址转换。在运行后， + 这个接口必须确保以前对‘start’到‘end-1’范围内的地址空间‘vma->vm_mm’ + 的任何页表修改对cpu来说是可见的。也就是说，在运行后，TLB中不会有 + ‘mm’的页表项用于‘start’到‘end-1’范围内的虚拟地址。 + + “vma”是用于该区域的备份存储。主要是用于munmap()类型的操作。 + + 提供这个接口是希望端口能够找到一个合适的有效方法来从TLB中删除多 + 个页面大小的转换，而不是让内核为每个可能被修改的页表项调用 + flush_tlb_page(见下文)。 + +4) ``void flush_tlb_page(struct vm_area_struct *vma, unsigned long addr)`` + + 这一次我们需要从TLB中删除PAGE_SIZE大小的转换。‘vma’是Linux用来跟 + 踪进程的mmap区域的支持结构体，地址空间可以通过vma->vm_mm获得。另 + 外，可以通过测试（vma->vm_flags & VM_EXEC）来查看这个区域是否是 + 可执行的（因此在split-tlb类型的设置中可能在“指令TLB”中）。 + + 在运行后，这个接口必须确保之前对用户虚拟地址“addr”的地址空间 + “vma->vm_mm”的页表修改对cpu来说是可见的。也就是说，在运行后，TLB + 中不会有虚拟地址‘addr’的‘vma->vm_mm’的页表项。 + + 这主要是在故障处理时使用。 + +5) ``void update_mmu_cache(struct vm_area_struct *vma, + unsigned long address, pte_t *ptep)`` + + 在每个页面故障结束时，这个程序被调用，以告诉体系结构特定的代码，在 + 软件页表中，在地址空间“vma->vm_mm”的虚拟地址“地址”处，现在存在 + 一个翻译。 + + 可以用它所选择的任何方式使用这个信息来进行移植。例如，它可以使用这 + 个事件来为软件管理的TLB配置预装TLB转换。目前sparc64移植就是这么干 + 的。 + +接下来，我们有缓存刷新接口。一般来说，当Linux将现有的虚拟->物理映射 +改变为新的值时，其顺序将是以下形式之一:: + + 1) flush_cache_mm(mm); + change_all_page_tables_of(mm); + flush_tlb_mm(mm); + + 2) flush_cache_range(vma, start, end); + change_range_of_page_tables(mm, start, end); + flush_tlb_range(vma, start, end); + + 3) flush_cache_page(vma, addr, pfn); + set_pte(pte_pointer, new_pte_val); + flush_tlb_page(vma, addr); + +缓存级别的刷新将永远是第一位的，因为这允许我们正确处理那些缓存严格， +且在虚拟地址被从缓存中刷新时要求一个虚拟地址的虚拟->物理转换存在的系统。 +HyperSparc cpu就是这样一个具有这种属性的cpu。 + +下面的缓存刷新程序只需要在特定的cpu需要的范围内处理缓存刷新。大多数 +情况下，这些程序必须为cpu实现，这些cpu有虚拟索引的缓存，当虚拟->物 +理转换被改变或移除时，必须被刷新。因此，例如，IA32处理器的物理索引 +的物理标记的缓存没有必要实现这些接口，因为这些缓存是完全同步的，并 +且不依赖于翻译信息。 + +下面逐个列出这些程序: + +1) ``void flush_cache_mm(struct mm_struct *mm)`` + + 这个接口将整个用户地址空间从高速缓存中刷掉。也就是说，在运行后， + 将没有与‘mm’相关的缓存行。 + + 这个接口被用来处理整个地址空间的页表操作，比如在退出和执行过程 + 中发生的事情。 + +2) ``void flush_cache_dup_mm(struct mm_struct *mm)`` + + 这个接口将整个用户地址空间从高速缓存中刷新掉。也就是说，在运行 + 后，将没有与‘mm’相关的缓存行。 + + 这个接口被用来处理整个地址空间的页表操作，比如在fork过程中发生 + 的事情。 + + 这个选项与flush_cache_mm分开，以允许对VIPT缓存进行一些优化。 + +3) ``void flush_cache_range(struct vm_area_struct *vma, + unsigned long start, unsigned long end)`` + + 在这里，我们要从缓存中刷新一个特定范围的（用户）虚拟地址。运行 + 后，在“start”到“end-1”范围内的虚拟地址的“vma->vm_mm”的缓存中 + 将没有页表项。 + + “vma”是被用于该区域的备份存储。主要是用于munmap()类型的操作。 + + 提供这个接口是希望端口能够找到一个合适的有效方法来从缓存中删 + 除多个页面大小的区域， 而不是让内核为每个可能被修改的页表项调 + 用 flush_cache_page (见下文)。 + +4) ``void flush_cache_page(struct vm_area_struct *vma, unsigned long addr, unsigned long pfn)`` + + 这一次我们需要从缓存中删除一个PAGE_SIZE大小的区域。“vma”是 + Linux用来跟踪进程的mmap区域的支持结构体，地址空间可以通过 + vma->vm_mm获得。另外，我们可以通过测试（vma->vm_flags & + VM_EXEC）来查看这个区域是否是可执行的（因此在“Harvard”类 + 型的缓存布局中可能是在“指令缓存”中）。 + + “pfn”表示“addr”所对应的物理页框（通过PAGE_SHIFT左移这个 + 值来获得物理地址）。正是这个映射应该从缓存中删除。 + + 在运行之后，对于虚拟地址‘addr’的‘vma->vm_mm’，在缓存中不会 + 有任何页表项，它被翻译成‘pfn’。 + + 这主要是在故障处理过程中使用。 + +5) ``void flush_cache_kmaps(void)`` + + 只有在平台使用高位内存的情况下才需要实现这个程序。它将在所有的 + kmaps失效之前被调用。 + + 运行后，内核虚拟地址范围PKMAP_ADDR(0)到PKMAP_ADDR(LAST_PKMAP) + 的缓存中将没有页表项。 + + 这个程序应该在asm/highmem.h中实现。 + +6) ``void flush_cache_vmap(unsigned long start, unsigned long end)`` + ``void flush_cache_vunmap(unsigned long start, unsigned long end)`` + + 在这里，在这两个接口中，我们从缓存中刷新一个特定范围的（内核） + 虚拟地址。运行后，在“start”到“end-1”范围内的虚拟地址的内核地 + 址空间的缓存中不会有页表项。 + + 这两个程序中的第一个是在vmap_range()安装了页表项之后调用的。 + 第二个是在vunmap_range()删除页表项之前调用的。 + +还有一类cpu缓存问题，目前需要一套完全不同的接口来正确处理。最大 +的问题是处理器的数据缓存中的虚拟别名。 + +.. note:: + + 这段内容有些晦涩，为了减轻中文阅读压力，特作此译注。 + + 别名（alias）属于缓存一致性问题，当不同的虚拟地址映射相同的 + 物理地址，而这些虚拟地址的index不同，此时就发生了别名现象(多 + 个虚拟地址被称为别名)。通俗点来说就是指同一个物理地址的数据被 + 加载到不同的cacheline中就会出现别名现象。 + + 常见的解决方法有两种：第一种是硬件维护一致性，设计特定的cpu电 + 路来解决问题（例如设计为PIPT的cache）；第二种是软件维护一致性， + 就是下面介绍的sparc的解决方案——页面染色，涉及的技术细节太多， + 译者不便展开，请读者自行查阅相关资料。 + +您的移植是否容易在其D-cache中出现虚拟别名？嗯，如果您的D-cache +是虚拟索引的，且cache大于PAGE_SIZE（页大小），并且不能防止同一 +物理地址的多个cache行同时存在，您就会遇到这个问题。 + +如果你的D-cache有这个问题，首先正确定义asm/shmparam.h SHMLBA， +它基本上应该是你的虚拟寻址D-cache的大小（或者如果大小是可变的， +则是最大的可能大小）。这个设置将迫使SYSv IPC层只允许用户进程在 +这个值的倍数的地址上对共享内存进行映射。 + +.. note:: + + 这并不能解决共享mmaps的问题，请查看sparc64移植解决 + 这个问题的一个方法（特别是 SPARC_FLAG_MMAPSHARED）。 + +接下来，你必须解决所有其他情况下的D-cache别名问题。请记住这个事 +实，对于一个给定的页面映射到某个用户地址空间，总是至少还有一个映 +射，那就是内核在其线性映射中从PAGE_OFFSET开始。因此，一旦第一个 +用户将一个给定的物理页映射到它的地址空间，就意味着D-cache的别名 +问题有可能存在，因为内核已经将这个页映射到它的虚拟地址。 + + ``void copy_user_page(void *to, void *from, unsigned long addr, struct page *page)`` + ``void clear_user_page(void *to, unsigned long addr, struct page *page)`` + + 这两个程序在用户匿名或COW页中存储数据。它允许一个端口有效地 + 避免用户空间和内核之间的D-cache别名问题。 + + 例如，一个端口可以在复制过程中把“from”和“to”暂时映射到内核 + 的虚拟地址上。这两个页面的虚拟地址的选择方式是，内核的加载/存 + 储指令发生在虚拟地址上，而这些虚拟地址与用户的页面映射是相同 + 的“颜色”。例如，Sparc64就使用这种技术。 + + “addr”参数告诉了用户最终要映射这个页面的虚拟地址，“page”参 + 数给出了一个指向目标页结构体的指针。 + + 如果D-cache别名不是问题，这两个程序可以简单地直接调用 + memcpy/memset而不做其他事情。 + + ``void flush_dcache_page(struct page *page)`` + + 任何时候，当内核写到一个页面缓存页，或者内核要从一个页面缓存 + 页中读出，并且这个页面的用户空间共享/可写映射可能存在时， + 这个程序就会被调用。 + + .. note:: + + 这个程序只需要为有可能被映射到用户进程的地址空间的 + 页面缓存调用。因此，例如，处理页面缓存中vfs符号链 + 接的VFS层代码根本不需要调用这个接口。 + + “内核写入页面缓存的页面”这句话的意思是，具体来说，内核执行存 + 储指令，在该页面的页面->虚拟映射处弄脏该页面的数据。在这里，通 + 过刷新的手段处理D-cache的别名是很重要的，以确保这些内核存储对 + 该页的用户空间映射是可见的。 + + 推论的情况也同样重要，如果有用户对这个文件有共享+可写的映射， + 我们必须确保内核对这些页面的读取会看到用户所做的最新的存储。 + + 如果D-cache别名不是一个问题，这个程序可以简单地定义为该架构上 + 的nop。 + + 在page->flags (PG_arch_1)中有一个位是“架构私有”。内核保证， + 对于分页缓存的页面，当这样的页面第一次进入分页缓存时，它将清除 + 这个位。 + + 这使得这些接口可以更有效地被实现。如果目前没有用户进程映射这个 + 页面，它允许我们“推迟”（也许是无限期）实际的刷新过程。请看 + sparc64的flush_dcache_page和update_mmu_cache实现，以了解如 + 何做到这一点。 + + 这个想法是，首先在flush_dcache_page()时，如果page->mapping->i_mmap + 是一个空树，只需标记架构私有页标志位。之后，在update_mmu_cache() + 中，会对这个标志位进行检查，如果设置了，就进行刷新，并清除标志位。 + + .. important:: + + 通常很重要的是，如果你推迟刷新，实际的刷新发生在同一个 + CPU上，因为它将cpu存储到页面上，使其变脏。同样，请看 + sparc64关于如何处理这个问题的例子。 + + ``void copy_to_user_page(struct vm_area_struct *vma, struct page *page, + unsigned long user_vaddr, void *dst, void *src, int len)`` + ``void copy_from_user_page(struct vm_area_struct *vma, struct page *page, + unsigned long user_vaddr, void *dst, void *src, int len)`` + + 当内核需要复制任意的数据进出任意的用户页时（比如ptrace()），它将使 + 用这两个程序。 + + 任何必要的缓存刷新或其他需要发生的一致性操作都应该在这里发生。如果 + 处理器的指令缓存没有对cpu存储进行窥探，那么你很可能需要为 + copy_to_user_page()刷新指令缓存。 + + ``void flush_anon_page(struct vm_area_struct *vma, struct page *page, + unsigned long vmaddr)`` + + 当内核需要访问一个匿名页的内容时，它会调用这个函数（目前只有 + get_user_pages()）。注意：flush_dcache_page()故意对匿名页不起作 + 用。默认的实现是nop（对于所有相干的架构应该保持这样）。对于不一致性 + 的架构，它应该刷新vmaddr处的页面缓存。 + + ``void flush_kernel_dcache_page(struct page *page)`` + + 当内核需要修改一个用kmap获得的用户页时，它会在所有修改完成后（但在 + kunmapping之前）调用这个函数，以使底层页面达到最新状态。这里假定用 + 户没有不一致性的缓存副本（即原始页面是从类似get_user_pages()的机制 + 中获得的）。默认的实现是一个nop，在所有相干的架构上都应该如此。在不 + 一致性的架构上，这应该刷新内核缓存中的页面（使用page_address(page)）。 + + + ``void flush_icache_range(unsigned long start, unsigned long end)`` + + 当内核存储到它将执行的地址中时（例如在加载模块时），这个函数被调用。 + + 如果icache不对存储进行窥探，那么这个程序将需要对其进行刷新。 + + ``void flush_icache_page(struct vm_area_struct *vma, struct page *page)`` + + flush_icache_page的所有功能都可以在flush_dcache_page和update_mmu_cache + 中实现。在未来，我们希望能够完全删除这个接口。 + +最后一类API是用于I/O到内核内特意设置的别名地址范围。这种别名是通过使用 +vmap/vmalloc API设置的。由于内核I/O是通过物理页进行的，I/O子系统假定用户 +映射和内核偏移映射是唯一的别名。这对vmap别名来说是不正确的，所以内核中任何 +试图对vmap区域进行I/O的东西都必须手动管理一致性。它必须在做I/O之前刷新vmap +范围，并在I/O返回后使其失效。 + + ``void flush_kernel_vmap_range(void *vaddr, int size)`` + + 刷新vmap区域中指定的虚拟地址范围的内核缓存。这是为了确保内核在vmap范围 + 内修改的任何数据对物理页是可见的。这个设计是为了使这个区域可以安全地执 + 行I/O。注意，这个API并 *没有* 刷新该区域的偏移映射别名。 + + ``void invalidate_kernel_vmap_range(void *vaddr, int size) invalidates`` + + 在vmap区域的一个给定的虚拟地址范围的缓存，这可以防止处理器在物理页的I/O + 发生时通过投机性地读取数据而使缓存变脏。这只对读入vmap区域的数据是必要的。 diff --git a/Documentation/translations/zh_CN/core-api/index.rst b/Documentation/translations/zh_CN/core-api/index.rst index a8b2afcbf5bc..b4bde9396339 100644 --- a/Documentation/translations/zh_CN/core-api/index.rst +++ b/Documentation/translations/zh_CN/core-api/index.rst @@ -76,9 +76,14 @@ Todolist: 缓存管理，CPU热插拔管理等。 -Todolist: +.. toctree:: + :maxdepth: 1 cachetlb + +Todolist: + + cpu_hotplug memory-hotplug genericirq -- cgit v1.2.3 From b0cbba2e44c629f1b4efb31701b1d3f3ade6926e Mon Sep 17 00:00:00 2001 From: Hailong Liu Date: Thu, 3 Jun 2021 22:52:27 +0800 Subject: docs/zh_CN: Add zh_CN/admin-guide/lockup-watchdogs.rst Add translation zh_CN/admin-guide/lockup-watchdogs.rst and link it to zh_CN/admin-guide/index.rst while clean its todo entry. Reviewed-by: Yanteng Si Signed-off-by: Hailong Liu Link: https://lore.kernel.org/r/20210603145227.30956-1-liuhailongg6@163.com Signed-off-by: Jonathan Corbet --- .../translations/zh_CN/admin-guide/index.rst | 2 +- .../zh_CN/admin-guide/lockup-watchdogs.rst | 66 ++++++++++++++++++++++ 2 files changed, 67 insertions(+), 1 deletion(-) create mode 100644 Documentation/translations/zh_CN/admin-guide/lockup-watchdogs.rst (limited to 'Documentation') diff --git a/Documentation/translations/zh_CN/admin-guide/index.rst b/Documentation/translations/zh_CN/admin-guide/index.rst index be835ec8e632..460034cbc2ab 100644 --- a/Documentation/translations/zh_CN/admin-guide/index.rst +++ b/Documentation/translations/zh_CN/admin-guide/index.rst @@ -65,6 +65,7 @@ Todolist: clearing-warn-once cpu-load + lockup-watchdogs unicode Todolist: @@ -100,7 +101,6 @@ Todolist: laptops/index lcd-panel-cgram ldm - lockup-watchdogs LSM/index md media/index diff --git a/Documentation/translations/zh_CN/admin-guide/lockup-watchdogs.rst b/Documentation/translations/zh_CN/admin-guide/lockup-watchdogs.rst new file mode 100644 index 000000000000..55ed3f4af442 --- /dev/null +++ b/Documentation/translations/zh_CN/admin-guide/lockup-watchdogs.rst @@ -0,0 +1,66 @@ +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/admin-guide/lockup-watchdogs.rst +:Translator: Hailong Liu + +.. _cn_lockup-watchdogs: + + +================================================= +Softlockup与hardlockup检测机制(又名:nmi_watchdog) +================================================= + +Linux中内核实现了一种用以检测系统发生softlockup和hardlockup的看门狗机制。 + +Softlockup是一种会引发系统在内核态中一直循环超过20秒（详见下面“实现”小节）导致 +其他任务没有机会得到运行的BUG。一旦检测到'softlockup'发生，默认情况下系统会打 +印当前堆栈跟踪信息并进入锁定状态。也可配置使其在检测到'softlockup'后进入panic +状态；通过sysctl命令设置“kernel.softlockup_panic”、使用内核启动参数 +“softlockup_panic”（详见Documentation/admin-guide/kernel-parameters.rst）以及使 +能内核编译选项“BOOTPARAM_SOFTLOCKUP_PANIC”都可实现这种配置。 + +而'hardlockup'是一种会引发系统在内核态一直循环超过10秒钟（详见"实现"小节）导致其 +他中断没有机会运行的缺陷。与'softlockup'情况类似，除了使用sysctl命令设置 +'hardlockup_panic'、使能内核选项“BOOTPARAM_HARDLOCKUP_PANIC”以及使用内核参数 +"nmi_watchdog"(详见:”Documentation/admin-guide/kernel-parameters.rst“)外，一旦检 +测到'hardlockup'默认情况下系统打印当前堆栈跟踪信息，然后进入锁定状态。 + +这个panic选项也可以与panic_timeout结合使用（这个panic_timeout是通过稍具迷惑性的 +sysctl命令"kernel.panic"来设置），使系统在panic指定时间后自动重启。 + +实现 +==== + +Softlockup和hardlockup分别建立在hrtimer(高精度定时器)和perf两个子系统上而实现。 +这也就意味着理论上任何架构只要实现了这两个子系统就支持这两种检测机制。 + +Hrtimer用于周期性产生中断并唤醒watchdog线程；NMI perf事件则以”watchdog_thresh“ +(编译时默认初始化为10秒，也可通过”watchdog_thresh“这个sysctl接口来进行配置修改) +为间隔周期产生以检测 hardlockups。如果一个CPU在这个时间段内没有检测到hrtimer中 +断发生，'hardlockup 检测器'(即NMI perf事件处理函数)将会视系统配置而选择产生内核 +警告或者直接panic。 + +而watchdog线程本质上是一个高优先级内核线程，每调度一次就对时间戳进行一次更新。 +如果时间戳在2*watchdog_thresh(这个是softlockup的触发门限)这段时间都未更新,那么 +"softlocup 检测器"(内部hrtimer定时器回调函数)会将相关的调试信息打印到系统日志中， +然后如果系统配置了进入panic流程则进入panic，否则内核继续执行。 + +Hrtimer定时器的周期是2*watchdog_thresh/5，也就是说在hardlockup被触发前hrtimer有 +2~3次机会产生时钟中断。 + +如上所述,内核相当于为系统管理员提供了一个可调节hrtimer定时器和perf事件周期长度 +的调节旋钮。如何通过这个旋钮为特定使用场景配置一个合理的周期值要对lockups检测的 +响应速度和lockups检测开销这二者之间进行权衡。 + +默认情况下所有在线cpu上都会运行一个watchdog线程。不过在内核配置了”NO_HZ_FULL“的 +情况下watchdog线程默认只会运行在管家(housekeeping)cpu上，而”nohz_full“启动参数指 +定的cpu上则不会有watchdog线程运行。试想，如果我们允许watchdog线程在”nohz_full“指 +定的cpu上运行，这些cpu上必须得运行时钟定时器来激发watchdog线程调度；这样一来就会 +使”nohz_full“保护用户程序免受内核干扰的功能失效。当然，副作用就是”nohz_full“指定 +的cpu即使在内核产生了lockup问题我们也无法检测到。不过，至少我们可以允许watchdog +线程在管家(non-tickless)核上继续运行以便我们能继续正常的监测这些cpus上的lockups +事件。 + +不论哪种情况都可以通过sysctl命令kernel.watchdog_cpumask来对没有运行watchdog线程 +的cpu集合进行调节。对于nohz_full而言,如果nohz_full cpu上有异常挂住的情况，通过 +这种方式打开这些cpu上的watchdog进行调试可能会有所作用。 -- cgit v1.2.3 From c003555a026f56dae1d6b522045a7917150ceabb Mon Sep 17 00:00:00 2001 From: Wan Jiabing Date: Thu, 3 Jun 2021 22:11:17 +0800 Subject: docs/zh_CN: add translations in zh_CN/dev-tools/kasan Add new zh translations * zh_CN/dev-tools/kasan.rst and link it to zh_CN/dev-tools/index.rst Reviewed-by: Fangrui Song Signed-off-by: Wan Jiabing Reviewed-by: Alex Shi Link: https://lore.kernel.org/r/20210603141127.101689-1-wanjiabing@vivo.com Signed-off-by: Jonathan Corbet --- .../translations/zh_CN/dev-tools/index.rst | 2 +- .../translations/zh_CN/dev-tools/kasan.rst | 417 +++++++++++++++++++++ 2 files changed, 418 insertions(+), 1 deletion(-) create mode 100644 Documentation/translations/zh_CN/dev-tools/kasan.rst (limited to 'Documentation') diff --git a/Documentation/translations/zh_CN/dev-tools/index.rst b/Documentation/translations/zh_CN/dev-tools/index.rst index fd73c479917b..e6c99f2f543f 100644 --- a/Documentation/translations/zh_CN/dev-tools/index.rst +++ b/Documentation/translations/zh_CN/dev-tools/index.rst @@ -19,13 +19,13 @@ :maxdepth: 2 gcov + kasan Todolist: - coccinelle - sparse - kcov - - kasan - ubsan - kmemleak - kcsan diff --git a/Documentation/translations/zh_CN/dev-tools/kasan.rst b/Documentation/translations/zh_CN/dev-tools/kasan.rst new file mode 100644 index 000000000000..23db9d419047 --- /dev/null +++ b/Documentation/translations/zh_CN/dev-tools/kasan.rst @@ -0,0 +1,417 @@ +.. SPDX-License-Identifier: GPL-2.0 + +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/dev-tools/kasan.rst +:Translator: 万家兵 Wan Jiabing + +内核地址消毒剂(KASAN) +===================== + +概述 +---- + +KernelAddressSANitizer(KASAN)是一种动态内存安全错误检测工具，主要功能是 +检查内存越界访问和使用已释放内存的问题。KASAN有三种模式: + +1. 通用KASAN（与用户空间的ASan类似） +2. 基于软件标签的KASAN（与用户空间的HWASan类似） +3. 基于硬件标签的KASAN（基于硬件内存标签） + +由于通用KASAN的内存开销较大，通用KASAN主要用于调试。基于软件标签的KASAN +可用于dogfood测试，因为它具有较低的内存开销，并允许将其用于实际工作量。 +基于硬件标签的KASAN具有较低的内存和性能开销，因此可用于生产。同时可用于 +检测现场内存问题或作为安全缓解措施。 + +软件KASAN模式（#1和#2）使用编译时工具在每次内存访问之前插入有效性检查， +因此需要一个支持它的编译器版本。 + +通用KASAN在GCC和Clang受支持。GCC需要8.3.0或更高版本。任何受支持的Clang +版本都是兼容的，但从Clang 11才开始支持检测全局变量的越界访问。 + +基于软件标签的KASAN模式仅在Clang中受支持。 + +硬件KASAN模式（#3）依赖硬件来执行检查，但仍需要支持内存标签指令的编译器 +版本。GCC 10+和Clang 11+支持此模式。 + +两种软件KASAN模式都适用于SLUB和SLAB内存分配器，而基于硬件标签的KASAN目前 +仅支持SLUB。 + +目前x86_64、arm、arm64、xtensa、s390、riscv架构支持通用KASAN模式，仅 +arm64架构支持基于标签的KASAN模式。 + +用法 +---- + +要启用KASAN，请使用以下命令配置内核:: + + CONFIG_KASAN=y + +同时在 ``CONFIG_KASAN_GENERIC`` (启用通用KASAN模式)， ``CONFIG_KASAN_SW_TAGS`` +(启用基于硬件标签的KASAN模式)，和 ``CONFIG_KASAN_HW_TAGS`` (启用基于硬件标签 +的KASAN模式)之间进行选择。 + +对于软件模式，还可以在 ``CONFIG_KASAN_OUTLINE`` 和 ``CONFIG_KASAN_INLINE`` +之间进行选择。outline和inline是编译器插桩类型。前者产生较小的二进制文件， +而后者快1.1-2倍。 + +要将受影响的slab对象的alloc和free堆栈跟踪包含到报告中，请启用 +``CONFIG_STACKTRACE`` 。要包括受影响物理页面的分配和释放堆栈跟踪的话， +请启用 ``CONFIG_PAGE_OWNER`` 并使用 ``page_owner=on`` 进行引导。 + +错误报告 +~~~~~~~~ + +典型的KASAN报告如下所示:: + + ================================================================== + BUG: KASAN: slab-out-of-bounds in kmalloc_oob_right+0xa8/0xbc [test_kasan] + Write of size 1 at addr ffff8801f44ec37b by task insmod/2760 + + CPU: 1 PID: 2760 Comm: insmod Not tainted 4.19.0-rc3+ #698 + Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1 04/01/2014 + Call Trace: + dump_stack+0x94/0xd8 + print_address_description+0x73/0x280 + kasan_report+0x144/0x187 + __asan_report_store1_noabort+0x17/0x20 + kmalloc_oob_right+0xa8/0xbc [test_kasan] + kmalloc_tests_init+0x16/0x700 [test_kasan] + do_one_initcall+0xa5/0x3ae + do_init_module+0x1b6/0x547 + load_module+0x75df/0x8070 + __do_sys_init_module+0x1c6/0x200 + __x64_sys_init_module+0x6e/0xb0 + do_syscall_64+0x9f/0x2c0 + entry_SYSCALL_64_after_hwframe+0x44/0xa9 + RIP: 0033:0x7f96443109da + RSP: 002b:00007ffcf0b51b08 EFLAGS: 00000202 ORIG_RAX: 00000000000000af + RAX: ffffffffffffffda RBX: 000055dc3ee521a0 RCX: 00007f96443109da + RDX: 00007f96445cff88 RSI: 0000000000057a50 RDI: 00007f9644992000 + RBP: 000055dc3ee510b0 R08: 0000000000000003 R09: 0000000000000000 + R10: 00007f964430cd0a R11: 0000000000000202 R12: 00007f96445cff88 + R13: 000055dc3ee51090 R14: 0000000000000000 R15: 0000000000000000 + + Allocated by task 2760: + save_stack+0x43/0xd0 + kasan_kmalloc+0xa7/0xd0 + kmem_cache_alloc_trace+0xe1/0x1b0 + kmalloc_oob_right+0x56/0xbc [test_kasan] + kmalloc_tests_init+0x16/0x700 [test_kasan] + do_one_initcall+0xa5/0x3ae + do_init_module+0x1b6/0x547 + load_module+0x75df/0x8070 + __do_sys_init_module+0x1c6/0x200 + __x64_sys_init_module+0x6e/0xb0 + do_syscall_64+0x9f/0x2c0 + entry_SYSCALL_64_after_hwframe+0x44/0xa9 + + Freed by task 815: + save_stack+0x43/0xd0 + __kasan_slab_free+0x135/0x190 + kasan_slab_free+0xe/0x10 + kfree+0x93/0x1a0 + umh_complete+0x6a/0xa0 + call_usermodehelper_exec_async+0x4c3/0x640 + ret_from_fork+0x35/0x40 + + The buggy address belongs to the object at ffff8801f44ec300 + which belongs to the cache kmalloc-128 of size 128 + The buggy address is located 123 bytes inside of + 128-byte region [ffff8801f44ec300, ffff8801f44ec380) + The buggy address belongs to the page: + page:ffffea0007d13b00 count:1 mapcount:0 mapping:ffff8801f7001640 index:0x0 + flags: 0x200000000000100(slab) + raw: 0200000000000100 ffffea0007d11dc0 0000001a0000001a ffff8801f7001640 + raw: 0000000000000000 0000000080150015 00000001ffffffff 0000000000000000 + page dumped because: kasan: bad access detected + + Memory state around the buggy address: + ffff8801f44ec200: fc fc fc fc fc fc fc fc fb fb fb fb fb fb fb fb + ffff8801f44ec280: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc + >ffff8801f44ec300: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 03 + ^ + ffff8801f44ec380: fc fc fc fc fc fc fc fc fb fb fb fb fb fb fb fb + ffff8801f44ec400: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc + ================================================================== + +报告标题总结了发生的错误类型以及导致该错误的访问类型。紧随其后的是错误访问的 +堆栈跟踪、所访问内存分配位置的堆栈跟踪（对于访问了slab对象的情况）以及对象 +被释放的位置的堆栈跟踪（对于访问已释放内存的问题报告）。接下来是对访问的 +slab对象的描述以及关于访问的内存页的信息。 + +最后，报告展示了访问地址周围的内存状态。在内部，KASAN单独跟踪每个内存颗粒的 +内存状态，根据KASAN模式分为8或16个对齐字节。报告的内存状态部分中的每个数字 +都显示了围绕访问地址的其中一个内存颗粒的状态。 + +对于通用KASAN，每个内存颗粒的大小为8个字节。每个颗粒的状态被编码在一个影子字节 +中。这8个字节可以是可访问的，部分访问的，已释放的或成为Redzone的一部分。KASAN +对每个影子字节使用以下编码:00表示对应内存区域的所有8个字节都可以访问；数字N +(1 <= N <= 7)表示前N个字节可访问，其他(8 - N)个字节不可访问；任何负值都表示 +无法访问整个8字节。KASAN使用不同的负值来区分不同类型的不可访问内存，如redzones +或已释放的内存（参见 mm/kasan/kasan.h）。 + +在上面的报告中，箭头指向影子字节 ``03`` ，表示访问的地址是部分可访问的。 + +对于基于标签的KASAN模式，报告最后的部分显示了访问地址周围的内存标签 +(参考 `实施细则`_ 章节)。 + +请注意，KASAN错误标题（如 ``slab-out-of-bounds`` 或 ``use-after-free`` ） +是尽量接近的:KASAN根据其拥有的有限信息打印出最可能的错误类型。错误的实际类型 +可能会有所不同。 + +通用KASAN还报告两个辅助调用堆栈跟踪。这些堆栈跟踪指向代码中与对象交互但不直接 +出现在错误访问堆栈跟踪中的位置。目前，这包括 call_rcu() 和排队的工作队列。 + +启动参数 +~~~~~~~~ + +KASAN受通用 ``panic_on_warn`` 命令行参数的影响。启用该功能后，KASAN在打印错误 +报告后会引起内核恐慌。 + +默认情况下，KASAN只为第一次无效内存访问打印错误报告。使用 ``kasan_multi_shot`` ， +KASAN会针对每个无效访问打印报告。这有效地禁用了KASAN报告的 ``panic_on_warn`` 。 + +基于硬件标签的KASAN模式（请参阅下面有关各种模式的部分）旨在在生产中用作安全缓解 +措施。因此，它支持允许禁用KASAN或控制其功能的引导参数。 + +- ``kasan=off`` 或 ``=on`` 控制KASAN是否启用 (默认: ``on`` )。 + +- ``kasan.mode=sync`` 或 ``=async`` 控制KASAN是否配置为同步或异步执行模式(默认: + ``sync`` )。同步模式：当标签检查错误发生时，立即检测到错误访问。异步模式： + 延迟错误访问检测。当标签检查错误发生时，信息存储在硬件中（在arm64的 + TFSR_EL1寄存器中）。内核会定期检查硬件，并且仅在这些检查期间报告标签错误。 + +- ``kasan.stacktrace=off`` 或 ``=on`` 禁用或启用alloc和free堆栈跟踪收集 + (默认: ``on`` )。 + +- ``kasan.fault=report`` 或 ``=panic`` 控制是只打印KASAN报告还是同时使内核恐慌 + (默认: ``report`` )。即使启用了 ``kasan_multi_shot`` ，也会发生内核恐慌。 + +实施细则 +-------- + +通用KASAN +~~~~~~~~~ + +软件KASAN模式使用影子内存来记录每个内存字节是否可以安全访问，并使用编译时工具 +在每次内存访问之前插入影子内存检查。 + +通用KASAN将1/8的内核内存专用于其影子内存（16TB以覆盖x86_64上的128TB），并使用 +具有比例和偏移量的直接映射将内存地址转换为其相应的影子地址。 + +这是将地址转换为其相应影子地址的函数:: + + static inline void *kasan_mem_to_shadow(const void *addr) + { + return (void *)((unsigned long)addr >> KASAN_SHADOW_SCALE_SHIFT) + + KASAN_SHADOW_OFFSET; + } + +在这里 ``KASAN_SHADOW_SCALE_SHIFT = 3`` 。 + +编译时工具用于插入内存访问检查。编译器在每次访问大小为1、2、4、8或16的内存之前 +插入函数调用( ``__asan_load*(addr)`` , ``__asan_store*(addr)``)。这些函数通过 +检查相应的影子内存来检查内存访问是否有效。 + +使用inline插桩，编译器不进行函数调用，而是直接插入代码来检查影子内存。此选项 +显著地增大了内核体积，但与outline插桩内核相比，它提供了x1.1-x2的性能提升。 + +通用KASAN是唯一一种通过隔离延迟重新使用已释放对象的模式 +（参见 mm/kasan/quarantine.c 以了解实现）。 + +基于软件标签的KASAN模式 +~~~~~~~~~~~~~~~~~~~~~~~ + +基于软件标签的KASAN使用软件内存标签方法来检查访问有效性。目前仅针对arm64架构实现。 + +基于软件标签的KASAN使用arm64 CPU的顶部字节忽略(TBI)特性在内核指针的顶部字节中 +存储一个指针标签。它使用影子内存来存储与每个16字节内存单元相关的内存标签(因此， +它将内核内存的1/16专用于影子内存)。 + +在每次内存分配时，基于软件标签的KASAN都会生成一个随机标签，用这个标签标记分配 +的内存，并将相同的标签嵌入到返回的指针中。 + +基于软件标签的KASAN使用编译时工具在每次内存访问之前插入检查。这些检查确保正在 +访问的内存的标签等于用于访问该内存的指针的标签。如果标签不匹配，基于软件标签 +的KASAN会打印错误报告。 + +基于软件标签的KASAN也有两种插桩模式（outline，发出回调来检查内存访问；inline， +执行内联的影子内存检查）。使用outline插桩模式，会从执行访问检查的函数打印错误 +报告。使用inline插桩，编译器会发出 ``brk`` 指令，并使用专用的 ``brk`` 处理程序 +来打印错误报告。 + +基于软件标签的KASAN使用0xFF作为匹配所有指针标签（不检查通过带有0xFF指针标签 +的指针进行的访问）。值0xFE当前保留用于标记已释放的内存区域。 + +基于软件标签的KASAN目前仅支持对Slab和page_alloc内存进行标记。 + +基于硬件标签的KASAN模式 +~~~~~~~~~~~~~~~~~~~~~~~ + +基于硬件标签的KASAN在概念上类似于软件模式，但它是使用硬件内存标签作为支持而 +不是编译器插桩和影子内存。 + +基于硬件标签的KASAN目前仅针对arm64架构实现，并且基于ARMv8.5指令集架构中引入 +的arm64内存标记扩展(MTE)和最高字节忽略(TBI)。 + +特殊的arm64指令用于为每次内存分配指定内存标签。相同的标签被指定给指向这些分配 +的指针。在每次内存访问时，硬件确保正在访问的内存的标签等于用于访问该内存的指针 +的标签。如果标签不匹配，则会生成故障并打印报告。 + +基于硬件标签的KASAN使用0xFF作为匹配所有指针标签（不检查通过带有0xFF指针标签的 +指针进行的访问）。值0xFE当前保留用于标记已释放的内存区域。 + +基于硬件标签的KASAN目前仅支持对Slab和page_alloc内存进行标记。 + +如果硬件不支持MTE（ARMv8.5之前），则不会启用基于硬件标签的KASAN。在这种情况下， +所有KASAN引导参数都将被忽略。 + +请注意，启用CONFIG_KASAN_HW_TAGS始终会导致启用内核中的TBI。即使提供了 +``kasan.mode=off`` 或硬件不支持MTE（但支持TBI）。 + +基于硬件标签的KASAN只报告第一个发现的错误。之后，MTE标签检查将被禁用。 + +影子内存 +-------- + +内核将内存映射到地址空间的几个不同部分。内核虚拟地址的范围很大：没有足够的真实 +内存来支持内核可以访问的每个地址的真实影子区域。因此，KASAN只为地址空间的某些 +部分映射真实的影子。 + +默认行为 +~~~~~~~~ + +默认情况下，体系结构仅将实际内存映射到用于线性映射的阴影区域（以及可能的其他 +小区域）。对于所有其他区域 —— 例如vmalloc和vmemmap空间 —— 一个只读页面被映射 +到阴影区域上。这个只读的影子页面声明所有内存访问都是允许的。 + +这给模块带来了一个问题：它们不存在于线性映射中，而是存在于专用的模块空间中。 +通过连接模块分配器，KASAN临时映射真实的影子内存以覆盖它们。例如，这允许检测 +对模块全局变量的无效访问。 + +这也造成了与 ``VMAP_STACK`` 的不兼容：如果堆栈位于vmalloc空间中，它将被分配 +只读页面的影子内存，并且内核在尝试为堆栈变量设置影子数据时会出错。 + +CONFIG_KASAN_VMALLOC +~~~~~~~~~~~~~~~~~~~~ + +使用 ``CONFIG_KASAN_VMALLOC`` ，KASAN可以以更大的内存使用为代价覆盖vmalloc +空间。目前，这在x86、riscv、s390和powerpc上受支持。 + +这通过连接到vmalloc和vmap并动态分配真实的影子内存来支持映射。 + +vmalloc空间中的大多数映射都很小，需要不到一整页的阴影空间。因此，为每个映射 +分配一个完整的影子页面将是一种浪费。此外，为了确保不同的映射使用不同的影子 +页面，映射必须与 ``KASAN_GRANULE_SIZE * PAGE_SIZE`` 对齐。 + +相反，KASAN跨多个映射共享后备空间。当vmalloc空间中的映射使用影子区域的特定 +页面时，它会分配一个后备页面。此页面稍后可以由其他vmalloc映射共享。 + +KASAN连接到vmap基础架构以懒清理未使用的影子内存。 + +为了避免交换映射的困难，KASAN预测覆盖vmalloc空间的阴影区域部分将不会被早期 +的阴影页面覆盖，但是将不会被映射。这将需要更改特定于arch的代码。 + +这允许在x86上支持 ``VMAP_STACK`` ，并且可以简化对没有固定模块区域的架构的支持。 + +对于开发者 +---------- + +忽略访问 +~~~~~~~~ + +软件KASAN模式使用编译器插桩来插入有效性检查。此类检测可能与内核的某些部分 +不兼容，因此需要禁用。 + +内核的其他部分可能会访问已分配对象的元数据。通常，KASAN会检测并报告此类访问， +但在某些情况下（例如，在内存分配器中），这些访问是有效的。 + +对于软件KASAN模式，要禁用特定文件或目录的检测，请将 ``KASAN_SANITIZE`` 添加 +到相应的内核Makefile中: + +- 对于单个文件(例如，main.o):: + + KASAN_SANITIZE_main.o := n + +- 对于一个目录下的所有文件:: + + KASAN_SANITIZE := n + +对于软件KASAN模式，要在每个函数的基础上禁用检测，请使用KASAN特定的 +``__no_sanitize_address`` 函数属性或通用的 ``noinstr`` 。 + +请注意，禁用编译器插桩（基于每个文件或每个函数）会使KASAN忽略在软件KASAN模式 +的代码中直接发生的访问。当访问是间接发生的（通过调用检测函数）或使用没有编译器 +插桩的基于硬件标签的模式时，它没有帮助。 + +对于软件KASAN模式，要在当前任务的一部分内核代码中禁用KASAN报告，请使用 +``kasan_disable_current()``/``kasan_enable_current()`` 部分注释这部分代码。 +这也会禁用通过函数调用发生的间接访问的报告。 + +对于基于标签的KASAN模式（包括硬件模式），要禁用访问检查，请使用 +``kasan_reset_tag()`` 或 ``page_kasan_tag_reset()`` 。请注意，通过 +``page_kasan_tag_reset()`` 临时禁用访问检查需要通过 ``page_kasan_tag`` +/ ``page_kasan_tag_set`` 保存和恢复每页KASAN标签。 + +测试 +~~~~ + +有一些KASAN测试可以验证KASAN是否正常工作并可以检测某些类型的内存损坏。 +测试由两部分组成: + +1. 与KUnit测试框架集成的测试。使用 ``CONFIG_KASAN_KUNIT_TEST`` 启用。 +这些测试可以通过几种不同的方式自动运行和部分验证；请参阅下面的说明。 + +2. 与KUnit不兼容的测试。使用 ``CONFIG_KASAN_MODULE_TEST`` 启用并且只能作为模块 +运行。这些测试只能通过加载内核模块并检查内核日志以获取KASAN报告来手动验证。 + +如果检测到错误，每个KUnit兼容的KASAN测试都会打印多个KASAN报告之一，然后测试打印 +其编号和状态。 + +当测试通过:: + + ok 28 - kmalloc_double_kzfree + +当由于 ``kmalloc`` 失败而导致测试失败时:: + + # kmalloc_large_oob_right: ASSERTION FAILED at lib/test_kasan.c:163 + Expected ptr is not null, but is + not ok 4 - kmalloc_large_oob_right + +当由于缺少KASAN报告而导致测试失败时:: + + # kmalloc_double_kzfree: EXPECTATION FAILED at lib/test_kasan.c:629 + Expected kasan_data->report_expected == kasan_data->report_found, but + kasan_data->report_expected == 1 + kasan_data->report_found == 0 + not ok 28 - kmalloc_double_kzfree + +最后打印所有KASAN测试的累积状态。成功:: + + ok 1 - kasan + +或者，如果其中一项测试失败:: + + not ok 1 - kasan + +有几种方法可以运行与KUnit兼容的KASAN测试。 + +1. 可加载模块 + + 启用 ``CONFIG_KUNIT`` 后，KASAN-KUnit测试可以构建为可加载模块，并通过使用 + ``insmod`` 或 ``modprobe`` 加载 ``test_kasan.ko`` 来运行。 + +2. 内置 + + 通过内置 ``CONFIG_KUNIT`` ，也可以内置KASAN-KUnit测试。在这种情况下， + 测试将在启动时作为后期初始化调用运行。 + +3. 使用kunit_tool + + 通过内置 ``CONFIG_KUNIT`` 和 ``CONFIG_KASAN_KUNIT_TEST`` ，还可以使用 + ``kunit_tool`` 以更易读的方式查看KUnit测试结果。这不会打印通过测试 + 的KASAN报告。有关 ``kunit_tool`` 更多最新信息，请参阅 + `KUnit文档 `_ 。 + +.. _KUnit: https://www.kernel.org/doc/html/latest/dev-tools/kunit/index.html -- cgit v1.2.3 From f9ce26c56d37fa6d32f700dfc77f4ceb445ce215 Mon Sep 17 00:00:00 2001 From: Kees Cook Date: Wed, 2 Jun 2021 13:29:14 -0700 Subject: docs: networking: Replace strncpy() with strscpy() Replace example code's use of strncpy() with strscpy() functions. Using strncpy() is considered deprecated: https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings Signed-off-by: Kees Cook Acked-by: Dmitry Torokhov Link: https://lore.kernel.org/r/20210602202914.4079123-1-keescook@chromium.org Signed-off-by: Jonathan Corbet --- Documentation/input/joydev/joystick-api.rst | 2 +- Documentation/networking/packet_mmap.rst | 2 +- Documentation/networking/tuntap.rst | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/input/joydev/joystick-api.rst b/Documentation/input/joydev/joystick-api.rst index af5934c10c1c..5db6dc6fe1c5 100644 --- a/Documentation/input/joydev/joystick-api.rst +++ b/Documentation/input/joydev/joystick-api.rst @@ -263,7 +263,7 @@ possible overrun should the name be too long:: char name[128]; if (ioctl(fd, JSIOCGNAME(sizeof(name)), name) < 0) - strncpy(name, "Unknown", sizeof(name)); + strscpy(name, "Unknown", sizeof(name)); printf("Name: %s\n", name); diff --git a/Documentation/networking/packet_mmap.rst b/Documentation/networking/packet_mmap.rst index 500ef60b1b82..c5da1a5d93de 100644 --- a/Documentation/networking/packet_mmap.rst +++ b/Documentation/networking/packet_mmap.rst @@ -153,7 +153,7 @@ As capture, each frame contains two parts:: struct ifreq s_ifr; ... - strncpy (s_ifr.ifr_name, "eth0", sizeof(s_ifr.ifr_name)); + strscpy_pad (s_ifr.ifr_name, "eth0", sizeof(s_ifr.ifr_name)); /* get interface index of eth0 */ ioctl(this->socket, SIOCGIFINDEX, &s_ifr); diff --git a/Documentation/networking/tuntap.rst b/Documentation/networking/tuntap.rst index a59d1dd6fdcc..4d7087f727be 100644 --- a/Documentation/networking/tuntap.rst +++ b/Documentation/networking/tuntap.rst @@ -107,7 +107,7 @@ Note that the character pointer becomes overwritten with the real device name */ ifr.ifr_flags = IFF_TUN; if( *dev ) - strncpy(ifr.ifr_name, dev, IFNAMSIZ); + strscpy_pad(ifr.ifr_name, dev, IFNAMSIZ); if( (err = ioctl(fd, TUNSETIFF, (void *) &ifr)) < 0 ){ close(fd); -- cgit v1.2.3 From e53eeac9a9d78dc550b889897f5315424bb63e10 Mon Sep 17 00:00:00 2001 From: Gao Mingfei Date: Tue, 1 Jun 2021 08:51:45 +0000 Subject: docs: block: fix stat.rst document error Update the description of the device stat files to include the proper number of fields. Signed-off-by: Gao Mingfei Link: https://lore.kernel.org/r/20210601085145.3273-1-g199209@gmail.com Signed-off-by: Jonathan Corbet --- Documentation/block/stat.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/block/stat.rst b/Documentation/block/stat.rst index 77311335c08b..a1cd9db2058f 100644 --- a/Documentation/block/stat.rst +++ b/Documentation/block/stat.rst @@ -18,7 +18,7 @@ A. each, it would be impossible to guarantee that a set of readings represent a single point in time. -The stat file consists of a single line of text containing 11 decimal +The stat file consists of a single line of text containing 17 decimal values separated by whitespace. The fields are summarized in the following table, and described in more detail below. -- cgit v1.2.3 From fb7b26a8b1d0b82c79e93deb12d624011c7a4e0e Mon Sep 17 00:00:00 2001 From: Nobuhiro Iwamatsu Date: Mon, 31 May 2021 22:42:35 +0900 Subject: docs: Fix typo in Documentation/arm/marvell.rst Fix typo in the documentation, changed from 'comatible' to 'compatible. Signed-off-by: Nobuhiro Iwamatsu Link: https://lore.kernel.org/r/20210531134235.720351-1-iwamatsu@nigauri.org Signed-off-by: Jonathan Corbet --- Documentation/arm/marvell.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/arm/marvell.rst b/Documentation/arm/marvell.rst index c50be711ec72..db2246493d18 100644 --- a/Documentation/arm/marvell.rst +++ b/Documentation/arm/marvell.rst @@ -259,7 +259,7 @@ Storage family https://web.archive.org/web/20191129073953/http://www.marvell.com/storage/armada-sp/ Core: - Sheeva ARMv7 comatible Quad-core PJ4C + Sheeva ARMv7 compatible Quad-core PJ4C (not supported in upstream Linux kernel) -- cgit v1.2.3 From acda97acb2e98c97895d81d20494bf6a4bc67c6c Mon Sep 17 00:00:00 2001 From: Igor Matheus Andrade Torrente Date: Mon, 31 May 2021 10:05:15 -0300 Subject: docs: convert dax.txt to rst Change the file extension and add the rst constructs to integrate this doc to the documentation infrastructure and take advantage of rst features. Signed-off-by: Igor Matheus Andrade Torrente Link: https://lore.kernel.org/r/20210531130515.10309-1-igormtorrente@gmail.com Signed-off-by: Jonathan Corbet --- Documentation/filesystems/dax.rst | 291 ++++++++++++++++++++++++++++++++++++ Documentation/filesystems/dax.txt | 257 ------------------------------- Documentation/filesystems/index.rst | 1 + 3 files changed, 292 insertions(+), 257 deletions(-) create mode 100644 Documentation/filesystems/dax.rst delete mode 100644 Documentation/filesystems/dax.txt (limited to 'Documentation') diff --git a/Documentation/filesystems/dax.rst b/Documentation/filesystems/dax.rst new file mode 100644 index 000000000000..9a1b8fd9e82b --- /dev/null +++ b/Documentation/filesystems/dax.rst @@ -0,0 +1,291 @@ +======================= +Direct Access for files +======================= + +Motivation +---------- + +The page cache is usually used to buffer reads and writes to files. +It is also used to provide the pages which are mapped into userspace +by a call to mmap. + +For block devices that are memory-like, the page cache pages would be +unnecessary copies of the original storage. The `DAX` code removes the +extra copy by performing reads and writes directly to the storage device. +For file mappings, the storage device is mapped directly into userspace. + + +Usage +----- + +If you have a block device which supports `DAX`, you can make a filesystem +on it as usual. The `DAX` code currently only supports files with a block +size equal to your kernel's `PAGE_SIZE`, so you may need to specify a block +size when creating the filesystem. + +Currently 3 filesystems support `DAX`: ext2, ext4 and xfs. Enabling `DAX` on them +is different. + +Enabling DAX on ext2 +-------------------- + +When mounting the filesystem, use the ``-o dax`` option on the command line or +add 'dax' to the options in ``/etc/fstab``. This works to enable `DAX` on all files +within the filesystem. It is equivalent to the ``-o dax=always`` behavior below. + + +Enabling DAX on xfs and ext4 +---------------------------- + +Summary +------- + + 1. There exists an in-kernel file access mode flag `S_DAX` that corresponds to + the statx flag `STATX_ATTR_DAX`. See the manpage for statx(2) for details + about this access mode. + + 2. There exists a persistent flag `FS_XFLAG_DAX` that can be applied to regular + files and directories. This advisory flag can be set or cleared at any + time, but doing so does not immediately affect the `S_DAX` state. + + 3. If the persistent `FS_XFLAG_DAX` flag is set on a directory, this flag will + be inherited by all regular files and subdirectories that are subsequently + created in this directory. Files and subdirectories that exist at the time + this flag is set or cleared on the parent directory are not modified by + this modification of the parent directory. + + 4. There exist dax mount options which can override `FS_XFLAG_DAX` in the + setting of the `S_DAX` flag. Given underlying storage which supports `DAX` the + following hold: + + ``-o dax=inode`` means "follow `FS_XFLAG_DAX`" and is the default. + + ``-o dax=never`` means "never set `S_DAX`, ignore `FS_XFLAG_DAX`." + + ``-o dax=always`` means "always set `S_DAX` ignore `FS_XFLAG_DAX`." + + ``-o dax`` is a legacy option which is an alias for ``dax=always``. + + .. warning:: + + The option ``-o dax`` may be removed in the future so ``-o dax=always`` is + the preferred method for specifying this behavior. + + .. note:: + + Modifications to and the inheritance behavior of `FS_XFLAG_DAX` remain + the same even when the filesystem is mounted with a dax option. However, + in-core inode state (`S_DAX`) will be overridden until the filesystem is + remounted with dax=inode and the inode is evicted from kernel memory. + + 5. The `S_DAX` policy can be changed via: + + a) Setting the parent directory `FS_XFLAG_DAX` as needed before files are + created + + b) Setting the appropriate dax="foo" mount option + + c) Changing the `FS_XFLAG_DAX` flag on existing regular files and + directories. This has runtime constraints and limitations that are + described in 6) below. + + 6. When changing the `S_DAX` policy via toggling the persistent `FS_XFLAG_DAX` + flag, the change to existing regular files won't take effect until the + files are closed by all processes. + + +Details +------- + +There are 2 per-file dax flags. One is a persistent inode setting (`FS_XFLAG_DAX`) +and the other is a volatile flag indicating the active state of the feature +(`S_DAX`). + +`FS_XFLAG_DAX` is preserved within the filesystem. This persistent config +setting can be set, cleared and/or queried using the `FS_IOC_FS`[`GS`]`ETXATTR` ioctl +(see ioctl_xfs_fsgetxattr(2)) or an utility such as 'xfs_io'. + +New files and directories automatically inherit `FS_XFLAG_DAX` from +their parent directory **when created**. Therefore, setting `FS_XFLAG_DAX` at +directory creation time can be used to set a default behavior for an entire +sub-tree. + +To clarify inheritance, here are 3 examples: + +Example A: + +.. code-block:: shell + + mkdir -p a/b/c + xfs_io -c 'chattr +x' a + mkdir a/b/c/d + mkdir a/e + + ------[outcome]------ + + dax: a,e + no dax: b,c,d + +Example B: + +.. code-block:: shell + + mkdir a + xfs_io -c 'chattr +x' a + mkdir -p a/b/c/d + + ------[outcome]------ + + dax: a,b,c,d + no dax: + +Example C: + +.. code-block:: shell + + mkdir -p a/b/c + xfs_io -c 'chattr +x' c + mkdir a/b/c/d + + ------[outcome]------ + + dax: c,d + no dax: a,b + +The current enabled state (`S_DAX`) is set when a file inode is instantiated in +memory by the kernel. It is set based on the underlying media support, the +value of `FS_XFLAG_DAX` and the filesystem's dax mount option. + +statx can be used to query `S_DAX`. + +.. note:: + + That only regular files will ever have `S_DAX` set and therefore statx + will never indicate that `S_DAX` is set on directories. + +Setting the `FS_XFLAG_DAX` flag (specifically or through inheritance) occurs even +if the underlying media does not support dax and/or the filesystem is +overridden with a mount option. + + +Implementation Tips for Block Driver Writers +-------------------------------------------- + +To support `DAX` in your block driver, implement the 'direct_access' +block device operation. It is used to translate the sector number +(expressed in units of 512-byte sectors) to a page frame number (pfn) +that identifies the physical page for the memory. It also returns a +kernel virtual address that can be used to access the memory. + +The direct_access method takes a 'size' parameter that indicates the +number of bytes being requested. The function should return the number +of bytes that can be contiguously accessed at that offset. It may also +return a negative errno if an error occurs. + +In order to support this method, the storage must be byte-accessible by +the CPU at all times. If your device uses paging techniques to expose +a large amount of memory through a smaller window, then you cannot +implement direct_access. Equally, if your device can occasionally +stall the CPU for an extended period, you should also not attempt to +implement direct_access. + +These block devices may be used for inspiration: +- brd: RAM backed block device driver +- dcssblk: s390 dcss block device driver +- pmem: NVDIMM persistent memory driver + + +Implementation Tips for Filesystem Writers +------------------------------------------ + +Filesystem support consists of: + +* Adding support to mark inodes as being `DAX` by setting the `S_DAX` flag in + i_flags +* Implementing ->read_iter and ->write_iter operations which use + :c:func:`dax_iomap_rw()` when inode has `S_DAX` flag set +* Implementing an mmap file operation for `DAX` files which sets the + `VM_MIXEDMAP` and `VM_HUGEPAGE` flags on the `VMA`, and setting the vm_ops to + include handlers for fault, pmd_fault, page_mkwrite, pfn_mkwrite. These + handlers should probably call :c:func:`dax_iomap_fault()` passing the + appropriate fault size and iomap operations. +* Calling :c:func:`iomap_zero_range()` passing appropriate iomap operations + instead of :c:func:`block_truncate_page()` for `DAX` files +* Ensuring that there is sufficient locking between reads, writes, + truncates and page faults + +The iomap handlers for allocating blocks must make sure that allocated blocks +are zeroed out and converted to written extents before being returned to avoid +exposure of uninitialized data through mmap. + +These filesystems may be used for inspiration: + +.. seealso:: + + ext2: see Documentation/filesystems/ext2.rst + +.. seealso:: + + xfs: see Documentation/admin-guide/xfs.rst + +.. seealso:: + + ext4: see Documentation/filesystems/ext4/ + + +Handling Media Errors +--------------------- + +The libnvdimm subsystem stores a record of known media error locations for +each pmem block device (in gendisk->badblocks). If we fault at such location, +or one with a latent error not yet discovered, the application can expect +to receive a `SIGBUS`. Libnvdimm also allows clearing of these errors by simply +writing the affected sectors (through the pmem driver, and if the underlying +NVDIMM supports the clear_poison DSM defined by ACPI). + +Since `DAX` IO normally doesn't go through the ``driver/bio`` path, applications or +sysadmins have an option to restore the lost data from a prior ``backup/inbuilt`` +redundancy in the following ways: + +1. Delete the affected file, and restore from a backup (sysadmin route): + This will free the filesystem blocks that were being used by the file, + and the next time they're allocated, they will be zeroed first, which + happens through the driver, and will clear bad sectors. + +2. Truncate or hole-punch the part of the file that has a bad-block (at least + an entire aligned sector has to be hole-punched, but not necessarily an + entire filesystem block). + +These are the two basic paths that allow `DAX` filesystems to continue operating +in the presence of media errors. More robust error recovery mechanisms can be +built on top of this in the future, for example, involving redundancy/mirroring +provided at the block layer through DM, or additionally, at the filesystem +level. These would have to rely on the above two tenets, that error clearing +can happen either by sending an IO through the driver, or zeroing (also through +the driver). + + +Shortcomings +------------ + +Even if the kernel or its modules are stored on a filesystem that supports +`DAX` on a block device that supports `DAX`, they will still be copied into RAM. + +The DAX code does not work correctly on architectures which have virtually +mapped caches such as ARM, MIPS and SPARC. + +Calling :c:func:`get_user_pages()` on a range of user memory that has been +mmaped from a `DAX` file will fail when there are no 'struct page' to describe +those pages. This problem has been addressed in some device drivers +by adding optional struct page support for pages under the control of +the driver (see `CONFIG_NVDIMM_PFN` in ``drivers/nvdimm`` for an example of +how to do this). In the non struct page cases `O_DIRECT` reads/writes to +those memory ranges from a non-`DAX` file will fail + + +.. note:: + + `O_DIRECT` reads/writes _of a `DAX` file do work, it is the memory that + is being accessed that is key here). Other things that will not work in + the non struct page case include RDMA, :c:func:`sendfile()` and + :c:func:`splice()`. diff --git a/Documentation/filesystems/dax.txt b/Documentation/filesystems/dax.txt deleted file mode 100644 index e03c20564f3a..000000000000 --- a/Documentation/filesystems/dax.txt +++ /dev/null @@ -1,257 +0,0 @@ -Direct Access for files ------------------------ - -Motivation ----------- - -The page cache is usually used to buffer reads and writes to files. -It is also used to provide the pages which are mapped into userspace -by a call to mmap. - -For block devices that are memory-like, the page cache pages would be -unnecessary copies of the original storage. The DAX code removes the -extra copy by performing reads and writes directly to the storage device. -For file mappings, the storage device is mapped directly into userspace. - - -Usage ------ - -If you have a block device which supports DAX, you can make a filesystem -on it as usual. The DAX code currently only supports files with a block -size equal to your kernel's PAGE_SIZE, so you may need to specify a block -size when creating the filesystem. - -Currently 3 filesystems support DAX: ext2, ext4 and xfs. Enabling DAX on them -is different. - -Enabling DAX on ext2 ------------------------------ - -When mounting the filesystem, use the "-o dax" option on the command line or -add 'dax' to the options in /etc/fstab. This works to enable DAX on all files -within the filesystem. It is equivalent to the '-o dax=always' behavior below. - - -Enabling DAX on xfs and ext4 ----------------------------- - -Summary -------- - - 1. There exists an in-kernel file access mode flag S_DAX that corresponds to - the statx flag STATX_ATTR_DAX. See the manpage for statx(2) for details - about this access mode. - - 2. There exists a persistent flag FS_XFLAG_DAX that can be applied to regular - files and directories. This advisory flag can be set or cleared at any - time, but doing so does not immediately affect the S_DAX state. - - 3. If the persistent FS_XFLAG_DAX flag is set on a directory, this flag will - be inherited by all regular files and subdirectories that are subsequently - created in this directory. Files and subdirectories that exist at the time - this flag is set or cleared on the parent directory are not modified by - this modification of the parent directory. - - 4. There exist dax mount options which can override FS_XFLAG_DAX in the - setting of the S_DAX flag. Given underlying storage which supports DAX the - following hold: - - "-o dax=inode" means "follow FS_XFLAG_DAX" and is the default. - - "-o dax=never" means "never set S_DAX, ignore FS_XFLAG_DAX." - - "-o dax=always" means "always set S_DAX ignore FS_XFLAG_DAX." - - "-o dax" is a legacy option which is an alias for "dax=always". - This may be removed in the future so "-o dax=always" is - the preferred method for specifying this behavior. - - NOTE: Modifications to and the inheritance behavior of FS_XFLAG_DAX remain - the same even when the filesystem is mounted with a dax option. However, - in-core inode state (S_DAX) will be overridden until the filesystem is - remounted with dax=inode and the inode is evicted from kernel memory. - - 5. The S_DAX policy can be changed via: - - a) Setting the parent directory FS_XFLAG_DAX as needed before files are - created - - b) Setting the appropriate dax="foo" mount option - - c) Changing the FS_XFLAG_DAX flag on existing regular files and - directories. This has runtime constraints and limitations that are - described in 6) below. - - 6. When changing the S_DAX policy via toggling the persistent FS_XFLAG_DAX - flag, the change to existing regular files won't take effect until the - files are closed by all processes. - - -Details -------- - -There are 2 per-file dax flags. One is a persistent inode setting (FS_XFLAG_DAX) -and the other is a volatile flag indicating the active state of the feature -(S_DAX). - -FS_XFLAG_DAX is preserved within the filesystem. This persistent config -setting can be set, cleared and/or queried using the FS_IOC_FS[GS]ETXATTR ioctl -(see ioctl_xfs_fsgetxattr(2)) or an utility such as 'xfs_io'. - -New files and directories automatically inherit FS_XFLAG_DAX from -their parent directory _when_ _created_. Therefore, setting FS_XFLAG_DAX at -directory creation time can be used to set a default behavior for an entire -sub-tree. - -To clarify inheritance, here are 3 examples: - -Example A: - -mkdir -p a/b/c -xfs_io -c 'chattr +x' a -mkdir a/b/c/d -mkdir a/e - - dax: a,e - no dax: b,c,d - -Example B: - -mkdir a -xfs_io -c 'chattr +x' a -mkdir -p a/b/c/d - - dax: a,b,c,d - no dax: - -Example C: - -mkdir -p a/b/c -xfs_io -c 'chattr +x' c -mkdir a/b/c/d - - dax: c,d - no dax: a,b - - -The current enabled state (S_DAX) is set when a file inode is instantiated in -memory by the kernel. It is set based on the underlying media support, the -value of FS_XFLAG_DAX and the filesystem's dax mount option. - -statx can be used to query S_DAX. NOTE that only regular files will ever have -S_DAX set and therefore statx will never indicate that S_DAX is set on -directories. - -Setting the FS_XFLAG_DAX flag (specifically or through inheritance) occurs even -if the underlying media does not support dax and/or the filesystem is -overridden with a mount option. - - - -Implementation Tips for Block Driver Writers --------------------------------------------- - -To support DAX in your block driver, implement the 'direct_access' -block device operation. It is used to translate the sector number -(expressed in units of 512-byte sectors) to a page frame number (pfn) -that identifies the physical page for the memory. It also returns a -kernel virtual address that can be used to access the memory. - -The direct_access method takes a 'size' parameter that indicates the -number of bytes being requested. The function should return the number -of bytes that can be contiguously accessed at that offset. It may also -return a negative errno if an error occurs. - -In order to support this method, the storage must be byte-accessible by -the CPU at all times. If your device uses paging techniques to expose -a large amount of memory through a smaller window, then you cannot -implement direct_access. Equally, if your device can occasionally -stall the CPU for an extended period, you should also not attempt to -implement direct_access. - -These block devices may be used for inspiration: -- brd: RAM backed block device driver -- dcssblk: s390 dcss block device driver -- pmem: NVDIMM persistent memory driver - - -Implementation Tips for Filesystem Writers ------------------------------------------- - -Filesystem support consists of -- adding support to mark inodes as being DAX by setting the S_DAX flag in - i_flags -- implementing ->read_iter and ->write_iter operations which use dax_iomap_rw() - when inode has S_DAX flag set -- implementing an mmap file operation for DAX files which sets the - VM_MIXEDMAP and VM_HUGEPAGE flags on the VMA, and setting the vm_ops to - include handlers for fault, pmd_fault, page_mkwrite, pfn_mkwrite. These - handlers should probably call dax_iomap_fault() passing the appropriate - fault size and iomap operations. -- calling iomap_zero_range() passing appropriate iomap operations instead of - block_truncate_page() for DAX files -- ensuring that there is sufficient locking between reads, writes, - truncates and page faults - -The iomap handlers for allocating blocks must make sure that allocated blocks -are zeroed out and converted to written extents before being returned to avoid -exposure of uninitialized data through mmap. - -These filesystems may be used for inspiration: -- ext2: see Documentation/filesystems/ext2.rst -- ext4: see Documentation/filesystems/ext4/ -- xfs: see Documentation/admin-guide/xfs.rst - - -Handling Media Errors ---------------------- - -The libnvdimm subsystem stores a record of known media error locations for -each pmem block device (in gendisk->badblocks). If we fault at such location, -or one with a latent error not yet discovered, the application can expect -to receive a SIGBUS. Libnvdimm also allows clearing of these errors by simply -writing the affected sectors (through the pmem driver, and if the underlying -NVDIMM supports the clear_poison DSM defined by ACPI). - -Since DAX IO normally doesn't go through the driver/bio path, applications or -sysadmins have an option to restore the lost data from a prior backup/inbuilt -redundancy in the following ways: - -1. Delete the affected file, and restore from a backup (sysadmin route): - This will free the filesystem blocks that were being used by the file, - and the next time they're allocated, they will be zeroed first, which - happens through the driver, and will clear bad sectors. - -2. Truncate or hole-punch the part of the file that has a bad-block (at least - an entire aligned sector has to be hole-punched, but not necessarily an - entire filesystem block). - -These are the two basic paths that allow DAX filesystems to continue operating -in the presence of media errors. More robust error recovery mechanisms can be -built on top of this in the future, for example, involving redundancy/mirroring -provided at the block layer through DM, or additionally, at the filesystem -level. These would have to rely on the above two tenets, that error clearing -can happen either by sending an IO through the driver, or zeroing (also through -the driver). - - -Shortcomings ------------- - -Even if the kernel or its modules are stored on a filesystem that supports -DAX on a block device that supports DAX, they will still be copied into RAM. - -The DAX code does not work correctly on architectures which have virtually -mapped caches such as ARM, MIPS and SPARC. - -Calling get_user_pages() on a range of user memory that has been mmaped -from a DAX file will fail when there are no 'struct page' to describe -those pages. This problem has been addressed in some device drivers -by adding optional struct page support for pages under the control of -the driver (see CONFIG_NVDIMM_PFN in drivers/nvdimm for an example of -how to do this). In the non struct page cases O_DIRECT reads/writes to -those memory ranges from a non-DAX file will fail (note that O_DIRECT -reads/writes _of a DAX file_ do work, it is the memory that is being -accessed that is key here). Other things that will not work in the -non struct page case include RDMA, sendfile() and splice(). diff --git a/Documentation/filesystems/index.rst b/Documentation/filesystems/index.rst index d4853cb919d2..246af51b277a 100644 --- a/Documentation/filesystems/index.rst +++ b/Documentation/filesystems/index.rst @@ -77,6 +77,7 @@ Documentation for filesystem implementations. coda configfs cramfs + dax debugfs dlmfs ecryptfs -- cgit v1.2.3 From 02fa1189927f69f0f9d617789943fb4ae748012b Mon Sep 17 00:00:00 2001 From: Vignesh Raghavendra Date: Wed, 26 May 2021 15:34:12 +0530 Subject: dt-bindings: i2c: Move i2c-omap.txt to YAML format Convert i2c-omap.txt to YAML schema for better checks and documentation. Following properties were used in DT but were not documented in txt bindings and has been included in YAML schema: 1. Include ti,am4372-i2c compatible 2. Document clocks property Signed-off-by: Vignesh Raghavendra Reviewed-by: Rob Herring Signed-off-by: Wolfram Sang --- Documentation/devicetree/bindings/i2c/i2c-omap.txt | 37 -------- .../devicetree/bindings/i2c/ti,omap4-i2c.yaml | 102 +++++++++++++++++++++ 2 files changed, 102 insertions(+), 37 deletions(-) delete mode 100644 Documentation/devicetree/bindings/i2c/i2c-omap.txt create mode 100644 Documentation/devicetree/bindings/i2c/ti,omap4-i2c.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/i2c/i2c-omap.txt b/Documentation/devicetree/bindings/i2c/i2c-omap.txt deleted file mode 100644 index a425b91af48f..000000000000 --- a/Documentation/devicetree/bindings/i2c/i2c-omap.txt +++ /dev/null @@ -1,37 +0,0 @@ -I2C for OMAP platforms - -Required properties : -- compatible : Must be - "ti,omap2420-i2c" for OMAP2420 SoCs - "ti,omap2430-i2c" for OMAP2430 SoCs - "ti,omap3-i2c" for OMAP3 SoCs - "ti,omap4-i2c" for OMAP4+ SoCs - "ti,am654-i2c", "ti,omap4-i2c" for AM654 SoCs - "ti,j721e-i2c", "ti,omap4-i2c" for J721E SoCs - "ti,am64-i2c", "ti,omap4-i2c" for AM64 SoCs -- ti,hwmods : Must be "i2c", n being the instance number (1-based) -- #address-cells = <1>; -- #size-cells = <0>; - -Recommended properties : -- clock-frequency : Desired I2C bus clock frequency in Hz. Otherwise - the default 100 kHz frequency will be used. - -Optional properties: -- Child nodes conforming to i2c bus binding - -Note: Current implementation will fetch base address, irq and dma -from omap hwmod data base during device registration. -Future plan is to migrate hwmod data base contents into device tree -blob so that, all the required data will be used from device tree dts -file. - -Examples : - -i2c1: i2c@0 { - compatible = "ti,omap3-i2c"; - #address-cells = <1>; - #size-cells = <0>; - ti,hwmods = "i2c1"; - clock-frequency = <400000>; -}; diff --git a/Documentation/devicetree/bindings/i2c/ti,omap4-i2c.yaml b/Documentation/devicetree/bindings/i2c/ti,omap4-i2c.yaml new file mode 100644 index 000000000000..ff165ad1bee8 --- /dev/null +++ b/Documentation/devicetree/bindings/i2c/ti,omap4-i2c.yaml @@ -0,0 +1,102 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/i2c/ti,omap4-i2c.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Bindings for I2C controllers on TI's OMAP and K3 SoCs + +maintainers: + - Vignesh Raghavendra + +properties: + compatible: + oneOf: + - enum: + - ti,omap2420-i2c + - ti,omap2430-i2c + - ti,omap3-i2c + - ti,omap4-i2c + - items: + - enum: + - ti,am4372-i2c + - ti,am64-i2c + - ti,am654-i2c + - ti,j721e-i2c + - const: ti,omap4-i2c + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + + clock-names: + const: fck + + clock-frequency: true + + power-domains: true + + "#address-cells": + const: 1 + + "#size-cells": + const: 0 + + ti,hwmods: + description: + Must be "i2c", n being the instance number (1-based). + This property is applicable only on legacy platforms mainly omap2/3 + and ti81xx and should not be used on other platforms. + $ref: /schemas/types.yaml#/definitions/string + deprecated: true + +# subnode's properties +patternProperties: + "@[0-9a-f]+$": + type: object + description: + Flash device uses the below defined properties in the subnode. + +required: + - compatible + - reg + - interrupts + +additionalProperties: false + +if: + properties: + compatible: + oneOf: + - const: ti,omap2420-i2c + - const: ti,omap2430-i2c + - const: ti,omap3-i2c + - const: ti,omap4-i2c + +then: + properties: + ti,hwmods: + items: + - pattern: "^i2c([1-9])$" + +else: + properties: + ti,hwmods: false + +examples: + - | + #include + #include + + main_i2c0: i2c@2000000 { + compatible = "ti,j721e-i2c", "ti,omap4-i2c"; + reg = <0x2000000 0x100>; + interrupts = ; + #address-cells = <1>; + #size-cells = <0>; + }; -- cgit v1.2.3 From 93b2e8711fe2ad6d25829574906b09a2339d2c80 Mon Sep 17 00:00:00 2001 From: Geert Uytterhoeven Date: Fri, 28 May 2021 13:10:49 +0200 Subject: dt-bindings: i2c: i2c-mux: Remove reset-active-low from ssd1307fb examples The "reset-active-low" property was removed from the ssd1307fb bindings in commit 519b4dba586198ee ("fbdev: ssd1307fb: Remove reset-active-low from the DT binding document") and from the ssd1307fb binding examples in commit 7d7e58d30e046d34 ("dt-bindings: display: ssd1307fb: Remove reset-active-low from examples"). Signed-off-by: Geert Uytterhoeven Signed-off-by: Wolfram Sang --- Documentation/devicetree/bindings/i2c/i2c-mux-gpio.txt | 1 - 1 file changed, 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/i2c/i2c-mux-gpio.txt b/Documentation/devicetree/bindings/i2c/i2c-mux-gpio.txt index 21da3ecbb370..1bf267302251 100644 --- a/Documentation/devicetree/bindings/i2c/i2c-mux-gpio.txt +++ b/Documentation/devicetree/bindings/i2c/i2c-mux-gpio.txt @@ -62,7 +62,6 @@ Example: reg = <0x3c>; pwms = <&pwm 4 3000>; reset-gpios = <&gpio2 7 1>; - reset-active-low; }; }; -- cgit v1.2.3 From e837220a27befd9c215dee9de1f64696bdc41f74 Mon Sep 17 00:00:00 2001 From: Sudeep Holla Date: Fri, 4 Jun 2021 21:57:05 +0100 Subject: dt-bindings: mailbox : arm,mhu: Fix arm,scpi example used here Once the arm,scpi binding is converted to YAML format, the following errors will be seen when doing `make DT_CHECKER_FLAGS=-m dt_binding_check` From schema: Documentation/devicetree/bindings/firmware/arm,scpi.yaml Documentation/devicetree/bindings/mailbox/arm,mhu.example.dt.yaml: scpi@2f000000: $nodename:0: 'scpi' was expected Documentation/devicetree/bindings/mailbox/arm,mhu.example.dt.yaml: scpi@2f000000: reg: [[0, 788529152, 0, 512]] is not of type 'object' Documentation/devicetree/bindings/mailbox/arm,mhu.example.dt.yaml: scpi@2f000000: 'shmem' is a required property Fix those error following the SCPI bindings. Cc: Rob Herring Cc: Viresh Kumar Signed-off-by: Sudeep Holla Link: https://lore.kernel.org/r/20210604205710.1944363-2-sudeep.holla@arm.com Signed-off-by: Rob Herring --- Documentation/devicetree/bindings/mailbox/arm,mhu.yaml | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mailbox/arm,mhu.yaml b/Documentation/devicetree/bindings/mailbox/arm,mhu.yaml index d07eb00b97c8..496308d91a86 100644 --- a/Documentation/devicetree/bindings/mailbox/arm,mhu.yaml +++ b/Documentation/devicetree/bindings/mailbox/arm,mhu.yaml @@ -126,9 +126,15 @@ examples: clock-names = "apb_pclk"; }; - mhu_client_scpi: scpi@2f000000 { + scpi { compatible = "arm,scpi"; - reg = <0 0x2f000000 0 0x200>; mboxes = <&mhuB 1 4>; /* HP-NonSecure, 5th doorbell */ + shmem = <&cpu_scp_hpri>; /* HP-NonSecure */ + + scpi_devpd: power-controller { + compatible = "arm,scpi-power-domains"; + num-domains = <2>; + #power-domain-cells = <1>; + }; }; }; -- cgit v1.2.3 From 1496be7194687a2e1027f6d04fde7b8a1c82137a Mon Sep 17 00:00:00 2001 From: Sudeep Holla Date: Fri, 4 Jun 2021 21:57:06 +0100 Subject: dt-bindings: firmware: arm,scpi: Convert to json schema Convert the old text format binding for System Control and Power Interface (SCPI) Message Protocol into the new and shiny YAML format. Cc: Rob Herring Cc: Kevin Hilman Cc: Neil Armstrong Cc: Jerome Brunet Cc: Viresh Kumar Signed-off-by: Sudeep Holla Link: https://lore.kernel.org/r/20210604205710.1944363-3-sudeep.holla@arm.com [robh: Move fixed strings to 'properties', drop some literal block notations] Signed-off-by: Rob Herring --- Documentation/devicetree/bindings/arm/arm,scpi.txt | 204 ------------------- .../devicetree/bindings/firmware/arm,scpi.yaml | 225 +++++++++++++++++++++ 2 files changed, 225 insertions(+), 204 deletions(-) delete mode 100644 Documentation/devicetree/bindings/arm/arm,scpi.txt create mode 100644 Documentation/devicetree/bindings/firmware/arm,scpi.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/arm,scpi.txt b/Documentation/devicetree/bindings/arm/arm,scpi.txt deleted file mode 100644 index bcb8b3d61e68..000000000000 --- a/Documentation/devicetree/bindings/arm/arm,scpi.txt +++ /dev/null @@ -1,204 +0,0 @@ -System Control and Power Interface (SCPI) Message Protocol ----------------------------------------------------------- - -Firmware implementing the SCPI described in ARM document number ARM DUI 0922B -("ARM Compute Subsystem SCP: Message Interface Protocols")[0] can be used -by Linux to initiate various system control and power operations. - -Required properties: - -- compatible : should be - * "arm,scpi" : For implementations complying to SCPI v1.0 or above - * "arm,scpi-pre-1.0" : For implementations complying to all - unversioned releases prior to SCPI v1.0 -- mboxes: List of phandle and mailbox channel specifiers - All the channels reserved by remote SCP firmware for use by - SCPI message protocol should be specified in any order -- shmem : List of phandle pointing to the shared memory(SHM) area between the - processors using these mailboxes for IPC, one for each mailbox - SHM can be any memory reserved for the purpose of this communication - between the processors. - -See Documentation/devicetree/bindings/mailbox/mailbox.txt -for more details about the generic mailbox controller and -client driver bindings. - -Clock bindings for the clocks based on SCPI Message Protocol ------------------------------------------------------------- - -This binding uses the common clock binding[1]. - -Container Node -============== -Required properties: -- compatible : should be "arm,scpi-clocks" - All the clocks provided by SCP firmware via SCPI message - protocol much be listed as sub-nodes under this node. - -Sub-nodes -========= -Required properties: -- compatible : shall include one of the following - "arm,scpi-dvfs-clocks" - all the clocks that are variable and index based. - These clocks don't provide an entire range of values between the - limits but only discrete points within the range. The firmware - provides the mapping for each such operating frequency and the - index associated with it. The firmware also manages the - voltage scaling appropriately with the clock scaling. - "arm,scpi-variable-clocks" - all the clocks that are variable and provide full - range within the specified range. The firmware provides the - range of values within a specified range. - -Other required properties for all clocks(all from common clock binding): -- #clock-cells : Should be 1. Contains the Clock ID value used by SCPI commands. -- clock-output-names : shall be the corresponding names of the outputs. -- clock-indices: The identifying number for the clocks(i.e.clock_id) in the - node. It can be non linear and hence provide the mapping of identifiers - into the clock-output-names array. - -Sensor bindings for the sensors based on SCPI Message Protocol --------------------------------------------------------------- -SCPI provides an API to access the various sensors on the SoC. - -Required properties: -- compatible : should be "arm,scpi-sensors". -- #thermal-sensor-cells: should be set to 1. This property follows the - thermal device tree bindings[2]. - - Valid cell values are raw identifiers (Sensor ID) - as used by the firmware. Refer to platform details - for your implementation for the IDs to use. - -Power domain bindings for the power domains based on SCPI Message Protocol ------------------------------------------------------------- - -This binding uses the generic power domain binding[4]. - -PM domain providers -=================== - -Required properties: - - #power-domain-cells : Should be 1. Contains the device or the power - domain ID value used by SCPI commands. - - num-domains: Total number of power domains provided by SCPI. This is - needed as the SCPI message protocol lacks a mechanism to - query this information at runtime. - -PM domain consumers -=================== - -Required properties: - - power-domains : A phandle and PM domain specifier as defined by bindings of - the power controller specified by phandle. - -[0] http://infocenter.arm.com/help/topic/com.arm.doc.dui0922b/index.html -[1] Documentation/devicetree/bindings/clock/clock-bindings.txt -[2] Documentation/devicetree/bindings/thermal/thermal*.yaml -[3] Documentation/devicetree/bindings/sram/sram.yaml -[4] Documentation/devicetree/bindings/power/power-domain.yaml - -Example: - -sram: sram@50000000 { - compatible = "arm,juno-sram-ns", "mmio-sram"; - reg = <0x0 0x50000000 0x0 0x10000>; - - #address-cells = <1>; - #size-cells = <1>; - ranges = <0 0x0 0x50000000 0x10000>; - - cpu_scp_lpri: scp-shmem@0 { - compatible = "arm,juno-scp-shmem"; - reg = <0x0 0x200>; - }; - - cpu_scp_hpri: scp-shmem@200 { - compatible = "arm,juno-scp-shmem"; - reg = <0x200 0x200>; - }; -}; - -mailbox: mailbox0@40000000 { - .... - #mbox-cells = <1>; -}; - -scpi_protocol: scpi@2e000000 { - compatible = "arm,scpi"; - mboxes = <&mailbox 0 &mailbox 1>; - shmem = <&cpu_scp_lpri &cpu_scp_hpri>; - - clocks { - compatible = "arm,scpi-clocks"; - - scpi_dvfs: scpi_clocks@0 { - compatible = "arm,scpi-dvfs-clocks"; - #clock-cells = <1>; - clock-indices = <0>, <1>, <2>; - clock-output-names = "atlclk", "aplclk","gpuclk"; - }; - scpi_clk: scpi_clocks@3 { - compatible = "arm,scpi-variable-clocks"; - #clock-cells = <1>; - clock-indices = <3>, <4>; - clock-output-names = "pxlclk0", "pxlclk1"; - }; - }; - - scpi_sensors0: sensors { - compatible = "arm,scpi-sensors"; - #thermal-sensor-cells = <1>; - }; - - scpi_devpd: scpi-power-domains { - compatible = "arm,scpi-power-domains"; - num-domains = <2>; - #power-domain-cells = <1>; - }; -}; - -cpu@0 { - ... - reg = <0 0>; - clocks = <&scpi_dvfs 0>; -}; - -hdlcd@7ff60000 { - ... - reg = <0 0x7ff60000 0 0x1000>; - clocks = <&scpi_clk 4>; - power-domains = <&scpi_devpd 1>; -}; - -thermal-zones { - soc_thermal { - polling-delay-passive = <100>; - polling-delay = <1000>; - - /* sensor ID */ - thermal-sensors = <&scpi_sensors0 3>; - ... - }; -}; - -In the above example, the #clock-cells is set to 1 as required. -scpi_dvfs has 3 output clocks namely: atlclk, aplclk, and gpuclk with 0, -1 and 2 as clock-indices. scpi_clk has 2 output clocks namely: pxlclk0 -and pxlclk1 with 3 and 4 as clock-indices. - -The first consumer in the example is cpu@0 and it has '0' as the clock -specifier which points to the first entry in the output clocks of -scpi_dvfs i.e. "atlclk". - -Similarly the second example is hdlcd@7ff60000 and it has pxlclk1 as input -clock. '4' in the clock specifier here points to the second entry -in the output clocks of scpi_clocks i.e. "pxlclk1" - -The thermal-sensors property in the soc_thermal node uses the -temperature sensor provided by SCP firmware to setup a thermal -zone. The ID "3" is the sensor identifier for the temperature sensor -as used by the firmware. - -The num-domains property in scpi-power-domains domain specifies that -SCPI provides 2 power domains. The hdlcd node uses the power domain with -domain ID 1. diff --git a/Documentation/devicetree/bindings/firmware/arm,scpi.yaml b/Documentation/devicetree/bindings/firmware/arm,scpi.yaml new file mode 100644 index 000000000000..e3ea23ae3336 --- /dev/null +++ b/Documentation/devicetree/bindings/firmware/arm,scpi.yaml @@ -0,0 +1,225 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +# Copyright 2021 ARM Ltd. +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/firmware/arm,scpi.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: System Control and Power Interface (SCPI) Message Protocol bindings + +maintainers: + - Sudeep Holla + +description: | + Firmware implementing the SCPI described in ARM document number ARM DUI + 0922B ("ARM Compute Subsystem SCP: Message Interface Protocols")[0] can be + used by Linux to initiate various system control and power operations. + + This binding is intended to define the interface the firmware implementing + the SCPI provide for OSPM in the device tree. + + [0] http://infocenter.arm.com/help/topic/com.arm.doc.dui0922b/index.html + +properties: + $nodename: + const: scpi + + compatible: + description: + SCPI compliant firmware complying to SCPI v1.0 and above OR + SCPI compliant firmware complying to all unversioned releases + prior to SCPI v1.0 + oneOf: + - const: arm,scpi # SCPI v1.0 and above + - const: arm,scpi-pre-1.0 # Unversioned SCPI before v1.0 + + mboxes: + description: + List of phandle and mailbox channel specifiers. All the channels reserved + by remote SCP firmware for use by SCPI message protocol should be + specified in any order. + minItems: 1 + + shmem: + description: + List of phandle pointing to the shared memory(SHM) area between the + processors using these mailboxes for IPC, one for each mailbox SHM can + be any memory reserved for the purpose of this communication between the + processors. + minItems: 1 + + power-controller: + type: object + description: + This sub-node represents SCPI power domain controller. + + properties: + compatible: + const: arm,scpi-power-domains + + '#power-domain-cells': + const: 1 + + num-domains: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + Total number of power domains provided by SCPI. This is needed as + the SCPI message protocol lacks a mechanism to query this + information at runtime. + + required: + - compatible + - '#power-domain-cells' + - num-domains + + additionalProperties: false + + sensors: + type: object + description: | + This sub-node represents SCPI sensors controller. + + properties: + compatible: + const: arm,scpi-sensors + + '#thermal-sensor-cells': + const: 1 + + required: + - compatible + - '#thermal-sensor-cells' + + additionalProperties: false + + clocks: + type: object + description: + This is the container node. Each sub-node represents one of the types + of clock controller - indexed or full range. + + properties: + compatible: + const: arm,scpi-clocks + + patternProperties: + "^clocks-[0-9a-f]+$": + type: object + description: | + This sub-node represents one of the types of clock controller + - indexed or full range. + + "arm,scpi-dvfs-clocks" - all the clocks that are variable and index + based. These clocks don't provide an entire range of values between + the limits but only discrete points within the range. The firmware + provides the mapping for each such operating frequency and the index + associated with it. The firmware also manages the voltage scaling + appropriately with the clock scaling. + + "arm,scpi-variable-clocks" - all the clocks that are variable and + provide full range within the specified range. The firmware provides + the range of values within a specified range. + + properties: + compatible: + oneOf: + - const: arm,scpi-dvfs-clocks + - const: arm,scpi-variable-clocks + + '#clock-cells': + const: 1 + + clock-output-names: true + + clock-indices: + $ref: /schemas/types.yaml#/definitions/uint32-array + description: + The identifying number for the clocks(i.e.clock_id) in the node. + It can be non linear and hence provide the mapping of identifiers + into the clock-output-names array. + + required: + - compatible + - '#clock-cells' + - clock-output-names + - clock-indices + + additionalProperties: false + + required: + - compatible + + additionalProperties: false + +additionalProperties: false + +required: + - compatible + - mboxes + - shmem + +examples: + - | + firmware { + scpi { + compatible = "arm,scpi"; + mboxes = <&mhuA 1>; + shmem = <&cpu_scp_hpri>; /* HP-NonSecure */ + + scpi_devpd: power-controller { + compatible = "arm,scpi-power-domains"; + num-domains = <2>; + #power-domain-cells = <1>; + }; + + clocks { + compatible = "arm,scpi-clocks"; + + scpi_dvfs: clocks-0 { + compatible = "arm,scpi-dvfs-clocks"; + #clock-cells = <1>; + clock-indices = <0>, <1>, <2>; + clock-output-names = "atlclk", "aplclk","gpuclk"; + }; + + scpi_clk: clocks-1 { + compatible = "arm,scpi-variable-clocks"; + #clock-cells = <1>; + clock-indices = <3>, <4>; + clock-output-names = "pxlclk0", "pxlclk1"; + }; + }; + + scpi_sensors: sensors { + compatible = "arm,scpi-sensors"; + #thermal-sensor-cells = <1>; + }; + + }; + }; + + soc { + #address-cells = <2>; + #size-cells = <2>; + + sram@50000000 { + compatible = "mmio-sram"; + reg = <0x0 0x50000000 0x0 0x10000>; + + #address-cells = <1>; + #size-cells = <1>; + ranges = <0 0x0 0x50000000 0x10000>; + + cpu_scp_lpri: scp-sram-section@0 { + compatible = "arm,scp-shmem"; + reg = <0x0 0x200>; + }; + + cpu_scp_hpri: scp-sram-section@200 { + compatible = "arm,scp-shmem"; + reg = <0x200 0x200>; + }; + }; + }; + +... -- cgit v1.2.3 From 01c70dfaa509b085fe7c94f08d24a26297f59281 Mon Sep 17 00:00:00 2001 From: Sudeep Holla Date: Fri, 4 Jun 2021 21:57:07 +0100 Subject: dt-bindings: firmware: amlogic,scpi: Convert to json schema Convert/merge the existing text format SCPI binding additions for amlogic,scpi into the common arm,scpi json scheme. Couple of things to note: "amlogic,meson-gxbb-scpi" is always used with "arm,scpi-pre-1.0" and "amlogic,meson-gxbb-scpi-sensors" is used always with "arm,scpi-sensors" Cc: Rob Herring Cc: Kevin Hilman Cc: Neil Armstrong Cc: Jerome Brunet Signed-off-by: Sudeep Holla Link: https://lore.kernel.org/r/20210604205710.1944363-4-sudeep.holla@arm.com Signed-off-by: Rob Herring --- .../devicetree/bindings/arm/amlogic,scpi.txt | 15 -------------- .../devicetree/bindings/firmware/arm,scpi.yaml | 24 +++++++++++++++++++++- 2 files changed, 23 insertions(+), 16 deletions(-) delete mode 100644 Documentation/devicetree/bindings/arm/amlogic,scpi.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/amlogic,scpi.txt b/Documentation/devicetree/bindings/arm/amlogic,scpi.txt deleted file mode 100644 index ebfe302fb747..000000000000 --- a/Documentation/devicetree/bindings/arm/amlogic,scpi.txt +++ /dev/null @@ -1,15 +0,0 @@ -System Control and Power Interface (SCPI) Message Protocol -(in addition to the standard binding in [0]) ----------------------------------------------------------- -Required properties - -- compatible : should be "amlogic,meson-gxbb-scpi" - -Sensor bindings for the sensors based on SCPI Message Protocol --------------------------------------------------------------- -SCPI provides an API to access the various sensors on the SoC. - -Required properties: -- compatible : should be "amlogic,meson-gxbb-scpi-sensors". - -[0] Documentation/devicetree/bindings/arm/arm,scpi.txt diff --git a/Documentation/devicetree/bindings/firmware/arm,scpi.yaml b/Documentation/devicetree/bindings/firmware/arm,scpi.yaml index e3ea23ae3336..d7113b06454b 100644 --- a/Documentation/devicetree/bindings/firmware/arm,scpi.yaml +++ b/Documentation/devicetree/bindings/firmware/arm,scpi.yaml @@ -32,6 +32,10 @@ properties: oneOf: - const: arm,scpi # SCPI v1.0 and above - const: arm,scpi-pre-1.0 # Unversioned SCPI before v1.0 + - items: + - enum: + - amlogic,meson-gxbb-scpi + - const: arm,scpi-pre-1.0 mboxes: description: @@ -81,7 +85,12 @@ properties: properties: compatible: - const: arm,scpi-sensors + oneOf: + - const: arm,scpi-sensors + - items: + - enum: + - amlogic,meson-gxbb-scpi-sensors + - const: arm,scpi-sensors '#thermal-sensor-cells': const: 1 @@ -222,4 +231,17 @@ examples: }; }; + - | + firmware { + scpi { + compatible = "amlogic,meson-gxbb-scpi", "arm,scpi-pre-1.0"; + mboxes = <&mailbox 1 &mailbox 2>; + shmem = <&cpu_scp_lpri &cpu_scp_hpri>; + + scpi_sensors1: sensors { + compatible = "amlogic,meson-gxbb-scpi-sensors", "arm,scpi-sensors"; + #thermal-sensor-cells = <1>; + }; + }; + }; ... -- cgit v1.2.3 From 61b8ac9bf89da2bf730d4b1410592b5b46243034 Mon Sep 17 00:00:00 2001 From: Sudeep Holla Date: Fri, 4 Jun 2021 21:57:08 +0100 Subject: dt-bindings: firmware: arm,scmi: Convert to json schema Convert the old text format binding for System Control and Management Interface (SCMI) Message Protocol into the new and shiny YAML format. Cc: Cristian Marussi Cc: Florian Fainelli Cc: Jim Quinlan Cc: Etienne Carriere Cc: Peter Hilber Signed-off-by: Sudeep Holla Link: https://lore.kernel.org/r/20210604205710.1944363-5-sudeep.holla@arm.com [robh: Rework interrupts schema and if/then] Signed-off-by: Rob Herring --- Documentation/devicetree/bindings/arm/arm,scmi.txt | 224 -------------- .../devicetree/bindings/firmware/arm,scmi.yaml | 341 +++++++++++++++++++++ 2 files changed, 341 insertions(+), 224 deletions(-) delete mode 100644 Documentation/devicetree/bindings/arm/arm,scmi.txt create mode 100644 Documentation/devicetree/bindings/firmware/arm,scmi.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/arm,scmi.txt b/Documentation/devicetree/bindings/arm/arm,scmi.txt deleted file mode 100644 index b7be2000afcb..000000000000 --- a/Documentation/devicetree/bindings/arm/arm,scmi.txt +++ /dev/null @@ -1,224 +0,0 @@ -System Control and Management Interface (SCMI) Message Protocol ----------------------------------------------------------- - -The SCMI is intended to allow agents such as OSPM to manage various functions -that are provided by the hardware platform it is running on, including power -and performance functions. - -This binding is intended to define the interface the firmware implementing -the SCMI as described in ARM document number ARM DEN 0056A ("ARM System Control -and Management Interface Platform Design Document")[0] provide for OSPM in -the device tree. - -Required properties: - -The scmi node with the following properties shall be under the /firmware/ node. - -- compatible : shall be "arm,scmi" or "arm,scmi-smc" for smc/hvc transports -- mboxes: List of phandle and mailbox channel specifiers. It should contain - exactly one or two mailboxes, one for transmitting messages("tx") - and another optional for receiving the notifications("rx") if - supported. -- shmem : List of phandle pointing to the shared memory(SHM) area as per - generic mailbox client binding. -- #address-cells : should be '1' if the device has sub-nodes, maps to - protocol identifier for a given sub-node. -- #size-cells : should be '0' as 'reg' property doesn't have any size - associated with it. -- arm,smc-id : SMC id required when using smc or hvc transports - -Optional properties: - -- mbox-names: shall be "tx" or "rx" depending on mboxes entries. - -- interrupts : when using smc or hvc transports, this optional - property indicates that msg completion by the platform is indicated - by an interrupt rather than by the return of the smc call. This - should not be used except when the platform requires such behavior. - -- interrupt-names : if "interrupts" is present, interrupt-names must also - be present and have the value "a2p". - -See Documentation/devicetree/bindings/mailbox/mailbox.txt for more details -about the generic mailbox controller and client driver bindings. - -The mailbox is the only permitted method of calling the SCMI firmware. -Mailbox doorbell is used as a mechanism to alert the presence of a -messages and/or notification. - -Each protocol supported shall have a sub-node with corresponding compatible -as described in the following sections. If the platform supports dedicated -communication channel for a particular protocol, the 3 properties namely: -mboxes, mbox-names and shmem shall be present in the sub-node corresponding -to that protocol. - -Clock/Performance bindings for the clocks/OPPs based on SCMI Message Protocol ------------------------------------------------------------- - -This binding uses the common clock binding[1]. - -Required properties: -- #clock-cells : Should be 1. Contains the Clock ID value used by SCMI commands. - -Power domain bindings for the power domains based on SCMI Message Protocol ------------------------------------------------------------- - -This binding for the SCMI power domain providers uses the generic power -domain binding[2]. - -Required properties: - - #power-domain-cells : Should be 1. Contains the device or the power - domain ID value used by SCMI commands. - -Regulator bindings for the SCMI Regulator based on SCMI Message Protocol ------------------------------------------------------------- -An SCMI Regulator is permanently bound to a well defined SCMI Voltage Domain, -and should be always positioned as a root regulator. -It does not support any current operation. - -SCMI Regulators are grouped under a 'regulators' node which in turn is a child -of the SCMI Voltage protocol node inside the desired SCMI instance node. - -This binding uses the common regulator binding[6]. - -Required properties: - - reg : shall identify an existent SCMI Voltage Domain. - -Sensor bindings for the sensors based on SCMI Message Protocol --------------------------------------------------------------- -SCMI provides an API to access the various sensors on the SoC. - -Required properties: -- #thermal-sensor-cells: should be set to 1. This property follows the - thermal device tree bindings[3]. - - Valid cell values are raw identifiers (Sensor ID) - as used by the firmware. Refer to platform details - for your implementation for the IDs to use. - -Reset signal bindings for the reset domains based on SCMI Message Protocol ------------------------------------------------------------- - -This binding for the SCMI reset domain providers uses the generic reset -signal binding[5]. - -Required properties: - - #reset-cells : Should be 1. Contains the reset domain ID value used - by SCMI commands. - -[0] http://infocenter.arm.com/help/topic/com.arm.doc.den0056a/index.html -[1] Documentation/devicetree/bindings/clock/clock-bindings.txt -[2] Documentation/devicetree/bindings/power/power-domain.yaml -[3] Documentation/devicetree/bindings/thermal/thermal*.yaml -[4] Documentation/devicetree/bindings/sram/sram.yaml -[5] Documentation/devicetree/bindings/reset/reset.txt -[6] Documentation/devicetree/bindings/regulator/regulator.yaml - -Example: - -sram@50000000 { - compatible = "mmio-sram"; - reg = <0x0 0x50000000 0x0 0x10000>; - - #address-cells = <1>; - #size-cells = <1>; - ranges = <0 0x0 0x50000000 0x10000>; - - cpu_scp_lpri: scp-shmem@0 { - compatible = "arm,scmi-shmem"; - reg = <0x0 0x200>; - }; - - cpu_scp_hpri: scp-shmem@200 { - compatible = "arm,scmi-shmem"; - reg = <0x200 0x200>; - }; -}; - -mailbox@40000000 { - .... - #mbox-cells = <1>; - reg = <0x0 0x40000000 0x0 0x10000>; -}; - -firmware { - - ... - - scmi { - compatible = "arm,scmi"; - mboxes = <&mailbox 0 &mailbox 1>; - mbox-names = "tx", "rx"; - shmem = <&cpu_scp_lpri &cpu_scp_hpri>; - #address-cells = <1>; - #size-cells = <0>; - - scmi_devpd: protocol@11 { - reg = <0x11>; - #power-domain-cells = <1>; - }; - - scmi_dvfs: protocol@13 { - reg = <0x13>; - #clock-cells = <1>; - }; - - scmi_clk: protocol@14 { - reg = <0x14>; - #clock-cells = <1>; - }; - - scmi_sensors0: protocol@15 { - reg = <0x15>; - #thermal-sensor-cells = <1>; - }; - - scmi_reset: protocol@16 { - reg = <0x16>; - #reset-cells = <1>; - }; - - scmi_voltage: protocol@17 { - reg = <0x17>; - - regulators { - regulator_devX: regulator@0 { - reg = <0x0>; - regulator-max-microvolt = <3300000>; - }; - - regulator_devY: regulator@9 { - reg = <0x9>; - regulator-min-microvolt = <500000>; - regulator-max-microvolt = <4200000>; - }; - - ... - }; - }; - }; -}; - -cpu@0 { - ... - reg = <0 0>; - clocks = <&scmi_dvfs 0>; -}; - -hdlcd@7ff60000 { - ... - reg = <0 0x7ff60000 0 0x1000>; - clocks = <&scmi_clk 4>; - power-domains = <&scmi_devpd 1>; - resets = <&scmi_reset 10>; -}; - -thermal-zones { - soc_thermal { - polling-delay-passive = <100>; - polling-delay = <1000>; - /* sensor ID */ - thermal-sensors = <&scmi_sensors0 3>; - ... - }; -}; diff --git a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml new file mode 100644 index 000000000000..cebf6ffe70d5 --- /dev/null +++ b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml @@ -0,0 +1,341 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +# Copyright 2021 ARM Ltd. +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/firmware/arm,scmi.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: System Control and Management Interface (SCMI) Message Protocol bindings + +maintainers: + - Sudeep Holla + +description: | + The SCMI is intended to allow agents such as OSPM to manage various functions + that are provided by the hardware platform it is running on, including power + and performance functions. + + This binding is intended to define the interface the firmware implementing + the SCMI as described in ARM document number ARM DEN 0056 ("ARM System Control + and Management Interface Platform Design Document")[0] provide for OSPM in + the device tree. + + [0] https://developer.arm.com/documentation/den0056/latest + +properties: + $nodename: + const: scmi + + compatible: + oneOf: + - description: SCMI compliant firmware with mailbox transport + items: + - const: arm,scmi + - description: SCMI compliant firmware with ARM SMC/HVC transport + items: + - const: arm,scmi-smc + + interrupts: + description: + The interrupt that indicates message completion by the platform + rather than by the return of the smc call. This should not be used + except when the platform requires such behavior. + maxItems: 1 + + interrupt-names: + const: a2p + + mbox-names: + description: + Specifies the mailboxes used to communicate with SCMI compliant + firmware. + items: + - const: tx + - const: rx + + mboxes: + description: + List of phandle and mailbox channel specifiers. It should contain + exactly one or two mailboxes, one for transmitting messages("tx") + and another optional for receiving the notifications("rx") if supported. + minItems: 1 + maxItems: 2 + + shmem: + description: + List of phandle pointing to the shared memory(SHM) area, for each + transport channel specified. + minItems: 1 + maxItems: 2 + + '#address-cells': + const: 1 + + '#size-cells': + const: 0 + + arm,smc-id: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + SMC id required when using smc or hvc transports + + protocol@11: + type: object + properties: + reg: + const: 0x11 + + '#power-domain-cells': + const: 1 + + required: + - '#power-domain-cells' + + protocol@13: + type: object + properties: + reg: + const: 0x13 + + '#clock-cells': + const: 1 + + required: + - '#clock-cells' + + protocol@14: + type: object + properties: + reg: + const: 0x14 + + '#clock-cells': + const: 1 + + required: + - '#clock-cells' + + protocol@15: + type: object + properties: + reg: + const: 0x15 + + '#thermal-sensor-cells': + const: 1 + + required: + - '#thermal-sensor-cells' + + protocol@16: + type: object + properties: + reg: + const: 0x16 + + '#reset-cells': + const: 1 + + required: + - '#reset-cells' + + protocol@17: + type: object + properties: + reg: + const: 0x17 + + regulators: + type: object + description: + The list of all regulators provided by this SCMI controller. + + patternProperties: + '^regulators@[0-9a-f]+$': + type: object + $ref: "../regulator/regulator.yaml#" + + properties: + reg: + maxItems: 1 + description: Identifier for the voltage regulator. + + required: + - reg + +additionalProperties: false + +patternProperties: + '^protocol@[0-9a-f]+$': + type: object + description: + Each sub-node represents a protocol supported. If the platform + supports a dedicated communication channel for a particular protocol, + then the corresponding transport properties must be present. + + properties: + reg: + maxItems: 1 + + mbox-names: + items: + - const: tx + - const: rx + + mboxes: + minItems: 1 + maxItems: 2 + + shmem: + minItems: 1 + maxItems: 2 + + required: + - reg + +required: + - compatible + - shmem + +if: + properties: + compatible: + contains: + const: arm,scmi +then: + properties: + interrupts: false + interrupt-names: false + + required: + - mboxes + +else: + if: + properties: + compatible: + contains: + const: arm,scmi-smc + then: + required: + - arm,smc-id + +examples: + - | + firmware { + scmi { + compatible = "arm,scmi"; + mboxes = <&mhuB 0 0>, + <&mhuB 0 1>; + mbox-names = "tx", "rx"; + shmem = <&cpu_scp_lpri0>, + <&cpu_scp_lpri1>; + + #address-cells = <1>; + #size-cells = <0>; + + scmi_devpd: protocol@11 { + reg = <0x11>; + #power-domain-cells = <1>; + }; + + scmi_dvfs: protocol@13 { + reg = <0x13>; + #clock-cells = <1>; + + mboxes = <&mhuB 1 0>, + <&mhuB 1 1>; + mbox-names = "tx", "rx"; + shmem = <&cpu_scp_hpri0>, + <&cpu_scp_hpri1>; + }; + + scmi_clk: protocol@14 { + reg = <0x14>; + #clock-cells = <1>; + }; + + scmi_sensors: protocol@15 { + reg = <0x15>; + #thermal-sensor-cells = <1>; + }; + + scmi_reset: protocol@16 { + reg = <0x16>; + #reset-cells = <1>; + }; + + scmi_voltage: protocol@17 { + reg = <0x17>; + regulators { + #address-cells = <1>; + #size-cells = <0>; + + regulator_devX: regulator@0 { + reg = <0x0>; + regulator-max-microvolt = <3300000>; + }; + + regulator_devY: regulator@9 { + reg = <0x9>; + regulator-min-microvolt = <500000>; + regulator-max-microvolt = <4200000>; + }; + }; + }; + }; + }; + + soc { + #address-cells = <2>; + #size-cells = <2>; + + sram@50000000 { + compatible = "mmio-sram"; + reg = <0x0 0x50000000 0x0 0x10000>; + + #address-cells = <1>; + #size-cells = <1>; + ranges = <0 0x0 0x50000000 0x10000>; + + cpu_scp_lpri0: scp-sram-section@0 { + compatible = "arm,scmi-shmem"; + reg = <0x0 0x80>; + }; + + cpu_scp_lpri1: scp-sram-section@80 { + compatible = "arm,scmi-shmem"; + reg = <0x80 0x80>; + }; + + cpu_scp_hpri0: scp-sram-section@100 { + compatible = "arm,scmi-shmem"; + reg = <0x100 0x80>; + }; + + cpu_scp_hpri2: scp-sram-section@180 { + compatible = "arm,scmi-shmem"; + reg = <0x180 0x80>; + }; + }; + }; + + - | + firmware { + scmi { + compatible = "arm,scmi-smc"; + shmem = <&cpu_scp_lpri0 &cpu_scp_lpri1>; + arm,smc-id = <0xc3000001>; + + #address-cells = <1>; + #size-cells = <0>; + + scmi_devpd1: protocol@11 { + reg = <0x11>; + #power-domain-cells = <1>; + }; + + }; + }; + +... -- cgit v1.2.3 From 3a32f22cc21fd525c786a7f3d78497cd7a703b34 Mon Sep 17 00:00:00 2001 From: Sudeep Holla Date: Fri, 4 Jun 2021 21:57:09 +0100 Subject: dt-bindings: mailbox : arm,mhu: Use examples with matching schema Currently the example provided in arm,mhu schema complains as below: Documentation/devicetree/bindings/mailbox/arm,mhu.example.dt.yaml :0:0: /example-0/soc/scb@2e000000: failed to match any schema with compatible: ['fujitsu,mb86s70-scb-1.0'] Fix the same using examples based on Juno platform. The old SCPI firmware used MHU with standard 32-bit data transfer protocol while the new SCMI firmware uses MHU and expects to be used in doorbell mode. Update example with SCPI and SCMI firmware nodes to demonstrate both 32-bit data transfer and doorbell mode of MHU operations Cc: Rob Herring Cc: Viresh Kumar Signed-off-by: Sudeep Holla Link: https://lore.kernel.org/r/20210604205710.1944363-6-sudeep.holla@arm.com Signed-off-by: Rob Herring --- .../devicetree/bindings/mailbox/arm,mhu.yaml | 48 +++++++++++++++++----- 1 file changed, 38 insertions(+), 10 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mailbox/arm,mhu.yaml b/Documentation/devicetree/bindings/mailbox/arm,mhu.yaml index 496308d91a86..bd49c201477d 100644 --- a/Documentation/devicetree/bindings/mailbox/arm,mhu.yaml +++ b/Documentation/devicetree/bindings/mailbox/arm,mhu.yaml @@ -101,11 +101,19 @@ examples: clocks = <&clock 0 2 1>; clock-names = "apb_pclk"; }; + }; - mhu_client_scb: scb@2e000000 { - compatible = "fujitsu,mb86s70-scb-1.0"; - reg = <0 0x2e000000 0 0x4000>; + firmware { + scpi { + compatible = "arm,scpi"; mboxes = <&mhuA 1>; /* HP-NonSecure */ + shmem = <&cpu_scp_hpri>; /* HP-NonSecure */ + + scpi_devpd: power-controller { + compatible = "arm,scpi-power-domains"; + num-domains = <2>; + #power-domain-cells = <1>; + }; }; }; @@ -125,16 +133,36 @@ examples: clocks = <&clock 0 2 1>; clock-names = "apb_pclk"; }; + }; - scpi { - compatible = "arm,scpi"; - mboxes = <&mhuB 1 4>; /* HP-NonSecure, 5th doorbell */ - shmem = <&cpu_scp_hpri>; /* HP-NonSecure */ + firmware { + scmi { + compatible = "arm,scmi"; + mboxes = <&mhuB 0 0>, /* LP-NonSecure, 1st doorbell */ + <&mhuB 0 1>; /* LP-NonSecure, 2nd doorbell */ + mbox-names = "tx", "rx"; + shmem = <&cpu_scp_lpri0>, + <&cpu_scp_lpri1>; - scpi_devpd: power-controller { - compatible = "arm,scpi-power-domains"; - num-domains = <2>; + #address-cells = <1>; + #size-cells = <0>; + + scmi_devpd: protocol@11 { + reg = <0x11>; #power-domain-cells = <1>; }; + + scmi_dvfs: protocol@13 { + reg = <0x13>; + #clock-cells = <1>; + + mboxes = <&mhuB 1 2>, /* HP-NonSecure, 3rd doorbell */ + <&mhuB 1 3>; /* HP-NonSecure, 4th doorbell */ + mbox-names = "tx", "rx"; + shmem = <&cpu_scp_hpri0>, + <&cpu_scp_hpri1>; + }; }; }; + +... -- cgit v1.2.3 From 0daa6056476ebe4ede2f4cce906508937193077d Mon Sep 17 00:00:00 2001 From: Sudeep Holla Date: Fri, 4 Jun 2021 21:57:10 +0100 Subject: dt-bindings: mailbox : arm,mhuv2: Use example with matching schema Currently the example provided in arm,mhuv2 schema complains as below: Documentation/devicetree/bindings/mailbox/arm,mhuv2.example.dt.yaml :0:0: /example-0/soc/scb@2e000000: failed to match any schema with compatible: ['fujitsu,mb86s70-scb-1.0'] Fix it by using an example with a matching schema that makes use of 4 mailboxes that is well suited to demonstrate Rx and Tx channels with both doorbell and data transfer protocols. Cc: Rob Herring Cc: Viresh Kumar Signed-off-by: Sudeep Holla Link: https://lore.kernel.org/r/20210604205710.1944363-7-sudeep.holla@arm.com Signed-off-by: Rob Herring --- .../devicetree/bindings/mailbox/arm,mhuv2.yaml | 25 +++++++++++----------- 1 file changed, 12 insertions(+), 13 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mailbox/arm,mhuv2.yaml b/Documentation/devicetree/bindings/mailbox/arm,mhuv2.yaml index 6608545ea66f..a4f1fe63659a 100644 --- a/Documentation/devicetree/bindings/mailbox/arm,mhuv2.yaml +++ b/Documentation/devicetree/bindings/mailbox/arm,mhuv2.yaml @@ -192,18 +192,17 @@ examples: arm,mhuv2-protocols = <1 1>, <1 7>, <0 2>; }; - mhu_client: scb@2e000000 { - compatible = "fujitsu,mb86s70-scb-1.0"; - reg = <0 0x2e000000 0 0x4000>; - - mboxes = - //data-transfer protocol with 5 windows, mhu-tx - <&mhu_tx 2 0>, - //data-transfer protocol with 7 windows, mhu-tx - <&mhu_tx 3 0>, - //doorbell protocol channel 4, doorbell 27, mhu-tx - <&mhu_tx 4 27>, - //data-transfer protocol with 1 window, mhu-rx - <&mhu_rx 0 0>; + mhu_client: dsp@596e8000 { + compatible = "fsl,imx8qxp-dsp"; + reg = <0 0x596e8000 0 0x88000>; + clocks = <&adma_lpcg 0>, <&adma_lpcg 1>, <&adma_lpcg 2>; + clock-names = "ipg", "ocram", "core"; + power-domains = <&pd 0>, <&pd 1>, <&pd 2>, <&pd 3>; + mbox-names = "txdb0", "txdb1", "rxdb0", "rxdb1"; + mboxes = <&mhu_tx 2 0>, //data-transfer protocol with 5 windows, mhu-tx + <&mhu_tx 3 0>, //data-transfer protocol with 7 windows, mhu-tx + <&mhu_rx 2 27>, //doorbell protocol channel 2, doorbell 27, mhu-rx + <&mhu_rx 0 0>; //data-transfer protocol with 1 window, mhu-rx + memory-region = <&dsp_reserved>; }; }; -- cgit v1.2.3 From 8acd12dadc20ec7bffc138c510d9e816143d6755 Mon Sep 17 00:00:00 2001 From: Hao Fang Date: Sat, 22 May 2021 18:23:17 +0800 Subject: dt-bindings: hisilicon: use the correct HiSilicon copyright s/Hisilicon/HiSilicon/. It should use capital S, according to the official website https://www.hisilicon.com/en. Signed-off-by: Hao Fang Link: https://lore.kernel.org/r/1621678997-15240-1-git-send-email-fanghao11@huawei.com Signed-off-by: Rob Herring --- Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index b547d4ddf09c..944a14926e02 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -472,7 +472,7 @@ patternProperties: "^hirschmann,.*": description: Hirschmann Automation and Control GmbH "^hisilicon,.*": - description: Hisilicon Limited. + description: HiSilicon Limited. "^hit,.*": description: Hitachi Ltd. "^hitex,.*": -- cgit v1.2.3 From 7cb32edb05d5ffa31cbe8f01e11e7b6aaea7ec3c Mon Sep 17 00:00:00 2001 From: Geert Uytterhoeven Date: Thu, 27 May 2021 21:39:52 +0200 Subject: dt-bindings: usb: cdns,usb3: Fix interrupts order Correct the order of the descriptions for the "interrupts" property to match the order of the "interrupt-names" property. Fixes: 68989fe1c39d9b32 ("dt-bindings: usb: Convert cdns-usb3.txt to YAML schema") Signed-off-by: Geert Uytterhoeven Acked-by: Peter Chen Acked-by: Peter Chen Link: https://lore.kernel.org/r/20210527193952.1705127-1-geert@linux-m68k.org Signed-off-by: Rob Herring --- Documentation/devicetree/bindings/usb/cdns,usb3.yaml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/usb/cdns,usb3.yaml b/Documentation/devicetree/bindings/usb/cdns,usb3.yaml index a407e1143cf4..8dedfa16c992 100644 --- a/Documentation/devicetree/bindings/usb/cdns,usb3.yaml +++ b/Documentation/devicetree/bindings/usb/cdns,usb3.yaml @@ -28,9 +28,9 @@ properties: interrupts: minItems: 3 items: - - description: OTG/DRD controller interrupt - description: XHCI host controller interrupt - description: Device controller interrupt + - description: OTG/DRD controller interrupt - description: interrupt used to wake up core, e.g when usbcmd.rs is cleared by xhci core, this interrupt is optional -- cgit v1.2.3 From e22808071d4d23596e6cc8f62588225515789031 Mon Sep 17 00:00:00 2001 From: Geert Uytterhoeven Date: Tue, 1 Jun 2021 13:31:55 +0200 Subject: dt-bindings: irqchip: renesas-irqc: Add R-Car M3-W+ support MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Document support for the Interrupt Controller for External Devices (INT-EC) in the Renesas R-Car M3-W+ (r8a77961) SoC. Signed-off-by: Geert Uytterhoeven Reviewed-by: Niklas Söderlund Reviewed-by: Yoshihiro Shimoda Acked-by: Rob Herring Signed-off-by: Marc Zyngier Link: https://lore.kernel.org/r/55d2c30cb14b2e10193a7fd4aa7670c70f360037.1622546880.git.geert+renesas@glider.be --- Documentation/devicetree/bindings/interrupt-controller/renesas,irqc.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/interrupt-controller/renesas,irqc.yaml b/Documentation/devicetree/bindings/interrupt-controller/renesas,irqc.yaml index b67b8cbd33fc..abb22db3bb28 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/renesas,irqc.yaml +++ b/Documentation/devicetree/bindings/interrupt-controller/renesas,irqc.yaml @@ -29,6 +29,7 @@ properties: - renesas,intc-ex-r8a774c0 # RZ/G2E - renesas,intc-ex-r8a7795 # R-Car H3 - renesas,intc-ex-r8a7796 # R-Car M3-W + - renesas,intc-ex-r8a77961 # R-Car M3-W+ - renesas,intc-ex-r8a77965 # R-Car M3-N - renesas,intc-ex-r8a77970 # R-Car V3M - renesas,intc-ex-r8a77980 # R-Car V3H -- cgit v1.2.3 From 1a6a9044b96729abacede172d7591c714a5b81d1 Mon Sep 17 00:00:00 2001 From: Mike Rapoport Date: Tue, 1 Jun 2021 10:53:53 +0300 Subject: x86/setup: Remove CONFIG_X86_RESERVE_LOW and reservelow= options The CONFIG_X86_RESERVE_LOW build time and reservelow= command line option allowed to control the amount of memory under 1M that would be reserved at boot to avoid using memory that can be potentially clobbered by BIOS. Since the entire range under 1M is always reserved there is no need for these options anymore and they can be removed. Signed-off-by: Mike Rapoport Signed-off-by: Borislav Petkov Link: https://lkml.kernel.org/r/20210601075354.5149-3-rppt@kernel.org --- Documentation/admin-guide/kernel-parameters.txt | 5 ----- 1 file changed, 5 deletions(-) (limited to 'Documentation') diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index cb89dbdedc46..d7d813032c51 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -4775,11 +4775,6 @@ Reserves a hole at the top of the kernel virtual address space. - reservelow= [X86] - Format: nn[K] - Set the amount of memory to reserve for BIOS at - the bottom of the address space. - reset_devices [KNL] Force drivers to reset the underlying device during initialization. -- cgit v1.2.3 From 03c36034ce19e5ad855bd6b72a3d6fb194ac4df4 Mon Sep 17 00:00:00 2001 From: Thomas Bogendoerfer Date: Fri, 14 May 2021 14:33:08 +0200 Subject: dt-bindings: gpio: Add devicetree binding for IDT 79RC32434 GPIO controller Add YAML devicetree binding for IDT 79RC32434 GPIO controller Signed-off-by: Thomas Bogendoerfer Reviewed-by: Rob Herring Reviewed-by: Linus Walleij Signed-off-by: Bartosz Golaszewski --- .../devicetree/bindings/gpio/idt,32434-gpio.yaml | 67 ++++++++++++++++++++++ 1 file changed, 67 insertions(+) create mode 100644 Documentation/devicetree/bindings/gpio/idt,32434-gpio.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/gpio/idt,32434-gpio.yaml b/Documentation/devicetree/bindings/gpio/idt,32434-gpio.yaml new file mode 100644 index 000000000000..d38de8144656 --- /dev/null +++ b/Documentation/devicetree/bindings/gpio/idt,32434-gpio.yaml @@ -0,0 +1,67 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/gpio/idt,32434-gpio.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: IDT 79RC32434 GPIO controller + +maintainers: + - Thomas Bogendoerfer + +properties: + compatible: + const: idt,32434-gpio + + reg: + maxItems: 2 + + reg-names: + items: + - const: gpio + - const: pic + + gpio-controller: true + + "#gpio-cells": + const: 2 + + ngpios: + minimum: 1 + maximum: 32 + + interrupt-controller: true + + "#interrupt-cells": + const: 2 + + interrupts: + maxItems: 1 + +required: + - compatible + - reg + - reg-names + - gpio-controller + - "#gpio-cells" + +additionalProperties: false + +examples: + - | + gpio0: gpio@50004 { + compatible = "idt,32434-gpio"; + reg = <0x50004 0x10>, <0x38030 0x0c>; + reg-names = "gpio", "pic"; + + interrupt-controller; + #interrupt-cells = <2>; + + interrupt-parent = <&cpuintc>; + interrupts = <6>; + + gpio-controller; + #gpio-cells = <2>; + + ngpios = <14>; + }; -- cgit v1.2.3 From b7e32bef4ae5f9149276203564b7911fac466588 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Thomas=20Hellstr=C3=B6m?= Date: Wed, 2 Jun 2021 10:38:11 +0200 Subject: drm: Add a prefetching memcpy_from_wc MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Reading out of write-combining mapped memory is typically very slow since the CPU doesn't prefetch. However some archs have special instructions to do this. So add a best-effort memcpy_from_wc taking dma-buf-map pointer arguments that attempts to use a fast prefetching memcpy and otherwise falls back to ordinary memcopies, taking the iomem tagging into account. The code is largely copied from i915_memcpy_from_wc. Cc: Daniel Vetter Cc: Christian König Suggested-by: Daniel Vetter Signed-off-by: Thomas Hellström Acked-by: Christian König Acked-by: Daniel Vetter Link: https://lore.kernel.org/r/20210602083818.241793-5-thomas.hellstrom@linux.intel.com Link: https://patchwork.freedesktop.org/patch/msgid/20210602083818.241793-5-thomas.hellstrom@linux.intel.com --- Documentation/gpu/drm-mm.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/gpu/drm-mm.rst b/Documentation/gpu/drm-mm.rst index 21be6deadc12..d5a73fa2c9ef 100644 --- a/Documentation/gpu/drm-mm.rst +++ b/Documentation/gpu/drm-mm.rst @@ -469,8 +469,8 @@ DRM MM Range Allocator Function References .. kernel-doc:: drivers/gpu/drm/drm_mm.c :export: -DRM Cache Handling -================== +DRM Cache Handling and Fast WC memcpy() +======================================= .. kernel-doc:: drivers/gpu/drm/drm_cache.c :export: -- cgit v1.2.3 From c858d436be8b949c368de0e079084acaff3d4aaf Mon Sep 17 00:00:00 2001 From: Vladimir Oltean Date: Fri, 4 Jun 2021 17:01:48 +0300 Subject: net: phy: introduce PHY_INTERFACE_MODE_REVRMII The "reverse RMII" protocol name is a personal invention, derived from "reverse MII". Just like MII, RMII is an asymmetric protocol in that a PHY behaves differently than a MAC. In the case of RMII, for example: - the 50 MHz clock signals are either driven by the MAC or by an external oscillator (but never by the PHY). - the PHY can transmit extra in-band control symbols via RXD[1:0] which the MAC is supposed to understand, but a PHY isn't. The "reverse MII" protocol is not standardized either, except for this web document: https://www.eetimes.com/reverse-media-independent-interface-revmii-block-architecture/# In short, it means that the Ethernet controller speaks the 4-bit data parallel protocol from the perspective of a PHY (it acts like a PHY). This might mean that it implements clause 22 compatible registers, although that is optional - the important bit is that its pins can be connected to an MII MAC and it will 'just work'. In this discussion thread: https://lore.kernel.org/netdev/20210201214515.cx6ivvme2tlquge2@skbuf/ we agreed that it would be an abuse of terms to use the "RevMII" name for anything than the 4-bit parallel MII protocol. But since all the same concepts can be applied to the 2-bit Reduced MII protocol as well, here we are introducing a "Reverse RMII" protocol. This means: "behave like an RMII PHY". Signed-off-by: Vladimir Oltean Acked-by: Florian Fainelli Signed-off-by: David S. Miller --- Documentation/devicetree/bindings/net/ethernet-controller.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/ethernet-controller.yaml b/Documentation/devicetree/bindings/net/ethernet-controller.yaml index e8f04687a3e0..d97b561003ed 100644 --- a/Documentation/devicetree/bindings/net/ethernet-controller.yaml +++ b/Documentation/devicetree/bindings/net/ethernet-controller.yaml @@ -68,6 +68,7 @@ properties: - tbi - rev-mii - rmii + - rev-rmii # RX and TX delays are added by the MAC when required - rgmii -- cgit v1.2.3 From 5d645df99ac60fab5368e01f1ddf4a57fa4f719f Mon Sep 17 00:00:00 2001 From: Vladimir Oltean Date: Fri, 4 Jun 2021 17:01:50 +0300 Subject: net: dsa: sja1105: determine PHY/MAC role from PHY interface type Now that both RevMII as well as RevRMII exist, we can deprecate the sja1105,role-mac and sja1105,role-phy properties and simply let the user select that a port operates in MII PHY role by using phy-mode = "rev-mii"; or in RMII PHY role by using phy-mode = "rev-rmii"; There are no fixed-link MII or RMII properties in mainline device trees, and the setup itself is fairly uncommon, so there shouldn't be risks of breaking compatibility. Signed-off-by: Vladimir Oltean Reviewed-by: Florian Fainelli Signed-off-by: David S. Miller --- .../devicetree/bindings/net/dsa/sja1105.txt | 37 +--------------------- 1 file changed, 1 insertion(+), 36 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/dsa/sja1105.txt b/Documentation/devicetree/bindings/net/dsa/sja1105.txt index 13fd21074d48..dcf3b2c1d26b 100644 --- a/Documentation/devicetree/bindings/net/dsa/sja1105.txt +++ b/Documentation/devicetree/bindings/net/dsa/sja1105.txt @@ -19,37 +19,6 @@ Required properties: of support for RGMII internal delays (supported on P/Q/R/S, but not on E/T). -Optional properties: - -- sja1105,role-mac: -- sja1105,role-phy: - Boolean properties that can be assigned under each port node. By - default (unless otherwise specified) a port is configured as MAC if it - is driving a PHY (phy-handle is present) or as PHY if it is PHY-less - (fixed-link specified, presumably because it is connected to a MAC). - The effect of this property (in either its implicit or explicit form) - is: - - In the case of MII or RMII it specifies whether the SJA1105 port is a - clock source or sink for this interface (not applicable for RGMII - where there is a Tx and an Rx clock). - - In the case of RGMII it affects the behavior regarding internal - delays: - 1. If sja1105,role-mac is specified, and the phy-mode property is one - of "rgmii-id", "rgmii-txid" or "rgmii-rxid", then the entity - designated to apply the delay/clock skew necessary for RGMII - is the PHY. The SJA1105 MAC does not apply any internal delays. - 2. If sja1105,role-phy is specified, and the phy-mode property is one - of the above, the designated entity to apply the internal delays - is the SJA1105 MAC (if hardware-supported). This is only supported - by the second-generation (P/Q/R/S) hardware. On a first-generation - E or T device, it is an error to specify an RGMII phy-mode other - than "rgmii" for a port that is in fixed-link mode. In that case, - the clock skew must either be added by the MAC at the other end of - the fixed-link, or by PCB serpentine traces on the board. - These properties are required, for example, in the case where SJA1105 - ports are at both ends of a MII/RMII PHY-less setup. One end would need - to have sja1105,role-mac, while the other sja1105,role-phy. - See Documentation/devicetree/bindings/net/dsa/dsa.txt for the list of standard DSA required and optional properties. @@ -87,7 +56,6 @@ arch/arm/boot/dts/ls1021a-tsn.dts: phy-handle = <&rgmii_phy6>; phy-mode = "rgmii-id"; reg = <0>; - /* Implicit "sja1105,role-mac;" */ }; port@1 { /* ETH2 written on chassis */ @@ -95,7 +63,6 @@ arch/arm/boot/dts/ls1021a-tsn.dts: phy-handle = <&rgmii_phy3>; phy-mode = "rgmii-id"; reg = <1>; - /* Implicit "sja1105,role-mac;" */ }; port@2 { /* ETH3 written on chassis */ @@ -103,7 +70,6 @@ arch/arm/boot/dts/ls1021a-tsn.dts: phy-handle = <&rgmii_phy4>; phy-mode = "rgmii-id"; reg = <2>; - /* Implicit "sja1105,role-mac;" */ }; port@3 { /* ETH4 written on chassis */ @@ -111,14 +77,13 @@ arch/arm/boot/dts/ls1021a-tsn.dts: label = "swp4"; phy-mode = "rgmii-id"; reg = <3>; - /* Implicit "sja1105,role-mac;" */ }; port@4 { /* Internal port connected to eth2 */ ethernet = <&enet2>; phy-mode = "rgmii"; reg = <4>; - /* Implicit "sja1105,role-phy;" */ + fixed-link { speed = <1000>; full-duplex; -- cgit v1.2.3 From 62568bdbe6f6293c955fbd98db15adf7ee6aca1c Mon Sep 17 00:00:00 2001 From: Vladimir Oltean Date: Fri, 4 Jun 2021 17:01:51 +0300 Subject: dt-bindings: net: dsa: sja1105: convert to YAML schema Since the sja1105 driver no longer has any custom device tree properties, the conversion is trivial. Signed-off-by: Vladimir Oltean Signed-off-by: David S. Miller --- .../devicetree/bindings/net/dsa/nxp,sja1105.yaml | 89 +++++++++++++++ .../devicetree/bindings/net/dsa/sja1105.txt | 121 --------------------- 2 files changed, 89 insertions(+), 121 deletions(-) create mode 100644 Documentation/devicetree/bindings/net/dsa/nxp,sja1105.yaml delete mode 100644 Documentation/devicetree/bindings/net/dsa/sja1105.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/dsa/nxp,sja1105.yaml b/Documentation/devicetree/bindings/net/dsa/nxp,sja1105.yaml new file mode 100644 index 000000000000..d6ac9a0c1b04 --- /dev/null +++ b/Documentation/devicetree/bindings/net/dsa/nxp,sja1105.yaml @@ -0,0 +1,89 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/dsa/nxp,sja1105.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NXP SJA1105 Automotive Ethernet Switch Family Device Tree Bindings + +description: + The SJA1105 SPI interface requires a CS-to-CLK time (t2 in UM10944.pdf) of at + least one half of t_CLK. At an SPI frequency of 1MHz, this means a minimum + cs_sck_delay of 500ns. Ensuring that this SPI timing requirement is observed + depends on the SPI bus master driver. + +allOf: + - $ref: "dsa.yaml#" + +maintainers: + - Vladimir Oltean + +properties: + compatible: + enum: + - nxp,sja1105e + - nxp,sja1105t + - nxp,sja1105p + - nxp,sja1105q + - nxp,sja1105r + - nxp,sja1105s + + reg: + maxItems: 1 + +required: + - compatible + - reg + +unevaluatedProperties: false + +examples: + - | + spi { + #address-cells = <1>; + #size-cells = <0>; + + ethernet-switch@1 { + reg = <0x1>; + compatible = "nxp,sja1105t"; + + ethernet-ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + phy-handle = <&rgmii_phy6>; + phy-mode = "rgmii-id"; + reg = <0>; + }; + + port@1 { + phy-handle = <&rgmii_phy3>; + phy-mode = "rgmii-id"; + reg = <1>; + }; + + port@2 { + phy-handle = <&rgmii_phy4>; + phy-mode = "rgmii-id"; + reg = <2>; + }; + + port@3 { + phy-mode = "rgmii-id"; + reg = <3>; + }; + + port@4 { + ethernet = <&enet2>; + phy-mode = "rgmii"; + reg = <4>; + + fixed-link { + speed = <1000>; + full-duplex; + }; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/net/dsa/sja1105.txt b/Documentation/devicetree/bindings/net/dsa/sja1105.txt deleted file mode 100644 index dcf3b2c1d26b..000000000000 --- a/Documentation/devicetree/bindings/net/dsa/sja1105.txt +++ /dev/null @@ -1,121 +0,0 @@ -NXP SJA1105 switch driver -========================= - -Required properties: - -- compatible: - Must be one of: - - "nxp,sja1105e" - - "nxp,sja1105t" - - "nxp,sja1105p" - - "nxp,sja1105q" - - "nxp,sja1105r" - - "nxp,sja1105s" - - Although the device ID could be detected at runtime, explicit bindings - are required in order to be able to statically check their validity. - For example, SGMII can only be specified on port 4 of R and S devices, - and the non-SGMII devices, while pin-compatible, are not equal in terms - of support for RGMII internal delays (supported on P/Q/R/S, but not on - E/T). - -See Documentation/devicetree/bindings/net/dsa/dsa.txt for the list of standard -DSA required and optional properties. - -Other observations ------------------- - -The SJA1105 SPI interface requires a CS-to-CLK time (t2 in UM10944) of at least -one half of t_CLK. At an SPI frequency of 1MHz, this means a minimum -cs_sck_delay of 500ns. Ensuring that this SPI timing requirement is observed -depends on the SPI bus master driver. - -Example -------- - -Ethernet switch connected via SPI to the host, CPU port wired to enet2: - -arch/arm/boot/dts/ls1021a-tsn.dts: - -/* SPI controller of the LS1021 */ -&dspi0 { - sja1105@1 { - reg = <0x1>; - #address-cells = <1>; - #size-cells = <0>; - compatible = "nxp,sja1105t"; - spi-max-frequency = <4000000>; - fsl,spi-cs-sck-delay = <1000>; - fsl,spi-sck-cs-delay = <1000>; - ports { - #address-cells = <1>; - #size-cells = <0>; - port@0 { - /* ETH5 written on chassis */ - label = "swp5"; - phy-handle = <&rgmii_phy6>; - phy-mode = "rgmii-id"; - reg = <0>; - }; - port@1 { - /* ETH2 written on chassis */ - label = "swp2"; - phy-handle = <&rgmii_phy3>; - phy-mode = "rgmii-id"; - reg = <1>; - }; - port@2 { - /* ETH3 written on chassis */ - label = "swp3"; - phy-handle = <&rgmii_phy4>; - phy-mode = "rgmii-id"; - reg = <2>; - }; - port@3 { - /* ETH4 written on chassis */ - phy-handle = <&rgmii_phy5>; - label = "swp4"; - phy-mode = "rgmii-id"; - reg = <3>; - }; - port@4 { - /* Internal port connected to eth2 */ - ethernet = <&enet2>; - phy-mode = "rgmii"; - reg = <4>; - - fixed-link { - speed = <1000>; - full-duplex; - }; - }; - }; - }; -}; - -/* MDIO controller of the LS1021 */ -&mdio0 { - /* BCM5464 */ - rgmii_phy3: ethernet-phy@3 { - reg = <0x3>; - }; - rgmii_phy4: ethernet-phy@4 { - reg = <0x4>; - }; - rgmii_phy5: ethernet-phy@5 { - reg = <0x5>; - }; - rgmii_phy6: ethernet-phy@6 { - reg = <0x6>; - }; -}; - -/* Ethernet master port of the LS1021 */ -&enet2 { - phy-connection-type = "rgmii"; - status = "ok"; - fixed-link { - speed = <1000>; - full-duplex; - }; -}; -- cgit v1.2.3 From db2aad0ffa7dfec31ddf715017a6ae57aa162045 Mon Sep 17 00:00:00 2001 From: Marek Vasut Date: Mon, 7 Jun 2021 19:42:57 +0200 Subject: dt-bindings: drm/bridge: ti-sn65dsi83: Add TI SN65DSI83 and SN65DSI84 bindings Add DT binding document for TI SN65DSI83 and SN65DSI84 DSI to LVDS bridge. Reviewed-by: Linus Walleij Reviewed-by: Rob Herring Signed-off-by: Marek Vasut Cc: Douglas Anderson Cc: Jagan Teki Cc: Laurent Pinchart Cc: Linus Walleij Cc: Rob Herring Cc: Sam Ravnborg Cc: Stephen Boyd Cc: devicetree@vger.kernel.org To: dri-devel@lists.freedesktop.org Signed-off-by: Robert Foss Link: https://patchwork.freedesktop.org/patch/msgid/20210607174258.16300-1-marex@denx.de --- .../bindings/display/bridge/ti,sn65dsi83.yaml | 159 +++++++++++++++++++++ 1 file changed, 159 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml new file mode 100644 index 000000000000..d101233ae17f --- /dev/null +++ b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml @@ -0,0 +1,159 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/bridge/ti,sn65dsi83.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: SN65DSI83 and SN65DSI84 DSI to LVDS bridge chip + +maintainers: + - Marek Vasut + +description: | + Texas Instruments SN65DSI83 1x Single-link MIPI DSI + to 1x Single-link LVDS + https://www.ti.com/lit/gpn/sn65dsi83 + Texas Instruments SN65DSI84 1x Single-link MIPI DSI + to 1x Dual-link or 2x Single-link LVDS + https://www.ti.com/lit/gpn/sn65dsi84 + +properties: + compatible: + enum: + - ti,sn65dsi83 + - ti,sn65dsi84 + + reg: + enum: + - 0x2c + - 0x2d + + enable-gpios: + maxItems: 1 + description: GPIO specifier for bridge_en pin (active high). + + ports: + $ref: /schemas/graph.yaml#/properties/ports + + properties: + port@0: + $ref: /schemas/graph.yaml#/properties/port + description: Video port for MIPI DSI Channel-A input + + properties: + endpoint: + $ref: /schemas/media/video-interfaces.yaml# + unevaluatedProperties: false + + properties: + data-lanes: + description: array of physical DSI data lane indexes. + minItems: 1 + maxItems: 4 + items: + - const: 1 + - const: 2 + - const: 3 + - const: 4 + + port@1: + $ref: /schemas/graph.yaml#/properties/port + description: Video port for MIPI DSI Channel-B input + + properties: + endpoint: + $ref: /schemas/media/video-interfaces.yaml# + unevaluatedProperties: false + + properties: + data-lanes: + description: array of physical DSI data lane indexes. + minItems: 1 + maxItems: 4 + items: + - const: 1 + - const: 2 + - const: 3 + - const: 4 + + port@2: + $ref: /schemas/graph.yaml#/properties/port + description: Video port for LVDS Channel-A output (panel or bridge). + + port@3: + $ref: /schemas/graph.yaml#/properties/port + description: Video port for LVDS Channel-B output (panel or bridge). + + required: + - port@0 + - port@2 + +required: + - compatible + - reg + - enable-gpios + - ports + +allOf: + - if: + properties: + compatible: + contains: + const: ti,sn65dsi83 + then: + properties: + ports: + properties: + port@1: false + port@3: false + + - if: + properties: + compatible: + contains: + const: ti,sn65dsi84 + then: + properties: + ports: + properties: + port@1: false + +additionalProperties: false + +examples: + - | + #include + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + bridge@2d { + compatible = "ti,sn65dsi83"; + reg = <0x2d>; + + enable-gpios = <&gpio2 1 GPIO_ACTIVE_HIGH>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + + endpoint { + remote-endpoint = <&dsi0_out>; + data-lanes = <1 2 3 4>; + }; + }; + + port@2 { + reg = <2>; + + endpoint { + remote-endpoint = <&panel_in_lvds>; + }; + }; + }; + }; + }; -- cgit v1.2.3 From 269b4dd3e8b34edec44c5bb0016ee96353638618 Mon Sep 17 00:00:00 2001 From: John Cox Date: Fri, 30 Apr 2021 18:48:13 +0200 Subject: media: hevc: Add sps_max_sub_layers_minus1 to v4l2_ctrl_hevc_sps sps_max_sub_layers_minus1 is needed if the driver wishes to determine whether or not a frame might be used for reference. Signed-off-by: John Cox Reviewed-by: Benjamin Gaignard Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab --- Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst | 3 +++ 1 file changed, 3 insertions(+) (limited to 'Documentation') diff --git a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst index 0b8061666c57..2b5edab55bb4 100644 --- a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst +++ b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst @@ -2707,6 +2707,9 @@ enum v4l2_mpeg_video_hevc_size_of_length_field - * - __u8 - ``chroma_format_idc`` - + * - __u8 + - ``sps_max_sub_layers_minus1`` + - * - __u64 - ``flags`` - See :ref:`Sequence Parameter Set Flags ` -- cgit v1.2.3 From ed1d08b9d0c9baed54a74073eae6c28d1e5422e8 Mon Sep 17 00:00:00 2001 From: Jean-Philippe Brucker Date: Wed, 26 May 2021 18:19:26 +0200 Subject: dt-bindings: Document stall property for IOMMU masters On ARM systems, some platform devices behind an IOMMU may support stall, which is the ability to recover from page faults. Let the firmware tell us when a device supports stall. Reviewed-by: Eric Auger Reviewed-by: Rob Herring Signed-off-by: Jean-Philippe Brucker Link: https://lore.kernel.org/r/20210526161927.24268-2-jean-philippe@linaro.org Signed-off-by: Will Deacon --- Documentation/devicetree/bindings/iommu/iommu.txt | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/iommu/iommu.txt b/Documentation/devicetree/bindings/iommu/iommu.txt index 3c36334e4f94..26ba9e530f13 100644 --- a/Documentation/devicetree/bindings/iommu/iommu.txt +++ b/Documentation/devicetree/bindings/iommu/iommu.txt @@ -92,6 +92,24 @@ Optional properties: tagging DMA transactions with an address space identifier. By default, this is 0, which means that the device only has one address space. +- dma-can-stall: When present, the master can wait for a transaction to + complete for an indefinite amount of time. Upon translation fault some + IOMMUs, instead of aborting the translation immediately, may first + notify the driver and keep the transaction in flight. This allows the OS + to inspect the fault and, for example, make physical pages resident + before updating the mappings and completing the transaction. Such IOMMU + accepts a limited number of simultaneous stalled transactions before + having to either put back-pressure on the master, or abort new faulting + transactions. + + Firmware has to opt-in stalling, because most buses and masters don't + support it. In particular it isn't compatible with PCI, where + transactions have to complete before a time limit. More generally it + won't work in systems and masters that haven't been designed for + stalling. For example the OS, in order to handle a stalled transaction, + may attempt to retrieve pages from secondary storage in a stalled + domain, leading to a deadlock. + Notes: ====== -- cgit v1.2.3 From 54203301d02a3afff13a002f3c2cffb30f59a2fb Mon Sep 17 00:00:00 2001 From: Eugen Hristev Date: Thu, 15 Apr 2021 10:55:30 +0200 Subject: media: dt-bindings: media: atmel-isc: convert to yaml Convert the Atmel ISC to yaml binding format. Signed-off-by: Eugen Hristev Reviewed-by: Rob Herring Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab --- .../devicetree/bindings/media/atmel,isc.yaml | 114 +++++++++++++++++++++ .../devicetree/bindings/media/atmel-isc.txt | 65 ------------ 2 files changed, 114 insertions(+), 65 deletions(-) create mode 100644 Documentation/devicetree/bindings/media/atmel,isc.yaml delete mode 100644 Documentation/devicetree/bindings/media/atmel-isc.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/media/atmel,isc.yaml b/Documentation/devicetree/bindings/media/atmel,isc.yaml new file mode 100644 index 000000000000..3e4bb8892d94 --- /dev/null +++ b/Documentation/devicetree/bindings/media/atmel,isc.yaml @@ -0,0 +1,114 @@ +# SPDX-License-Identifier: GPL-2.0-only +# Copyright (C) 2016-2021 Microchip Technology, Inc. +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/media/atmel,isc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Atmel Image Sensor Controller (ISC) + +maintainers: + - Eugen Hristev + +description: | + The Image Sensor Controller (ISC) device provides the video input capabilities for the + Atmel/Microchip AT91 SAMA family of devices. + + The ISC has a single parallel input that supports RAW Bayer, RGB or YUV video, + with both external synchronization and BT.656 synchronization for the latter. + +properties: + compatible: + const: atmel,sama5d2-isc + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + minItems: 3 + maxItems: 3 + + clock-names: + items: + - const: hclock + - const: iscck + - const: gck + + '#clock-cells': + const: 0 + + clock-output-names: + const: isc-mck + + port: + $ref: /schemas/graph.yaml#/properties/port + description: + Input port node, single endpoint describing the input pad. + + properties: + endpoint: + $ref: video-interfaces.yaml# + + properties: + remote-endpoint: true + + bus-width: + enum: [8, 9, 10, 11, 12] + default: 12 + + hsync-active: + enum: [0, 1] + default: 1 + + vsync-active: + enum: [0, 1] + default: 1 + + pclk-sample: + enum: [0, 1] + default: 1 + + required: + - remote-endpoint + + additionalProperties: false + + additionalProperties: false + +required: + - compatible + - reg + - clocks + - clock-names + - '#clock-cells' + - clock-output-names + - port + +additionalProperties: false + +examples: + - | + #include + + isc: isc@f0008000 { + compatible = "atmel,sama5d2-isc"; + reg = <0xf0008000 0x4000>; + interrupts = <46 IRQ_TYPE_LEVEL_HIGH 5>; + clocks = <&isc_clk>, <&iscck>, <&isc_gclk>; + clock-names = "hclock", "iscck", "gck"; + #clock-cells = <0>; + clock-output-names = "isc-mck"; + + port { + isc_0: endpoint { + remote-endpoint = <&ov7740_0>; + hsync-active = <1>; + vsync-active = <0>; + pclk-sample = <1>; + bus-width = <8>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/media/atmel-isc.txt b/Documentation/devicetree/bindings/media/atmel-isc.txt deleted file mode 100644 index bbe0e87c6188..000000000000 --- a/Documentation/devicetree/bindings/media/atmel-isc.txt +++ /dev/null @@ -1,65 +0,0 @@ -Atmel Image Sensor Controller (ISC) ----------------------------------------------- - -Required properties for ISC: -- compatible - Must be "atmel,sama5d2-isc". -- reg - Physical base address and length of the registers set for the device. -- interrupts - Should contain IRQ line for the ISC. -- clocks - List of clock specifiers, corresponding to entries in - the clock-names property; - Please refer to clock-bindings.txt. -- clock-names - Required elements: "hclock", "iscck", "gck". -- #clock-cells - Should be 0. -- clock-output-names - Should be "isc-mck". -- pinctrl-names, pinctrl-0 - Please refer to pinctrl-bindings.txt. - -ISC supports a single port node with parallel bus. It should contain one -'port' child node with child 'endpoint' node. Please refer to the bindings -defined in Documentation/devicetree/bindings/media/video-interfaces.txt. - -Example: -isc: isc@f0008000 { - compatible = "atmel,sama5d2-isc"; - reg = <0xf0008000 0x4000>; - interrupts = <46 IRQ_TYPE_LEVEL_HIGH 5>; - clocks = <&isc_clk>, <&iscck>, <&isc_gclk>; - clock-names = "hclock", "iscck", "gck"; - #clock-cells = <0>; - clock-output-names = "isc-mck"; - pinctrl-names = "default"; - pinctrl-0 = <&pinctrl_isc_base &pinctrl_isc_data_8bit &pinctrl_isc_data_9_10 &pinctrl_isc_data_11_12>; - - port { - isc_0: endpoint { - remote-endpoint = <&ov7740_0>; - hsync-active = <1>; - vsync-active = <0>; - pclk-sample = <1>; - }; - }; -}; - -i2c1: i2c@fc028000 { - ov7740: camera@21 { - compatible = "ovti,ov7740"; - reg = <0x21>; - clocks = <&isc>; - clock-names = "xvclk"; - assigned-clocks = <&isc>; - assigned-clock-rates = <24000000>; - - port { - ov7740_0: endpoint { - remote-endpoint = <&isc_0>; - }; - }; - }; -}; -- cgit v1.2.3 From 7b8d3d03df83aae74519b34022e95dec577af1df Mon Sep 17 00:00:00 2001 From: Eugen Hristev Date: Thu, 15 Apr 2021 20:45:00 +0200 Subject: media: dt-bindings: media: add microchip,xisc device bindings Add bindings for the Microchip eXtended Image Sensor Controller. Based on the atmel,isc.yaml binding. Signed-off-by: Eugen Hristev Reviewed-by: Rob Herring Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab --- .../devicetree/bindings/media/microchip,xisc.yaml | 129 +++++++++++++++++++++ 1 file changed, 129 insertions(+) create mode 100644 Documentation/devicetree/bindings/media/microchip,xisc.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/media/microchip,xisc.yaml b/Documentation/devicetree/bindings/media/microchip,xisc.yaml new file mode 100644 index 000000000000..41afe2e5f133 --- /dev/null +++ b/Documentation/devicetree/bindings/media/microchip,xisc.yaml @@ -0,0 +1,129 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +# Copyright (C) 2021 Microchip Technology, Inc. +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/media/microchip,xisc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Microchip eXtended Image Sensor Controller (XISC) + +maintainers: + - Eugen Hristev + +description: | + The eXtended Image Sensor Controller (XISC) device provides the video input capabilities for the + Microchip AT91 SAM family of devices. + + The XISC has a single internal parallel input that supports RAW Bayer, RGB or YUV video. + The source can be either a demuxer from a CSI2 type of bus, or a simple direct bridge to a + parallel sensor. + + The XISC provides one clock output that is used to clock the demuxer/bridge. + +properties: + compatible: + const: microchip,sama7g5-isc + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + + clock-names: + items: + - const: hclock + + '#clock-cells': + const: 0 + + clock-output-names: + const: isc-mck + + microchip,mipi-mode: + type: boolean + description: + As the XISC is usually connected to a demux/bridge, the XISC receives + the same type of input, however, it should be aware of the type of + signals received. The mipi-mode enables different internal handling + of the data and clock lines. + + port: + $ref: /schemas/graph.yaml#/properties/port + description: + Input port node, single endpoint describing the input pad. + + properties: + endpoint: + $ref: video-interfaces.yaml# + + properties: + bus-type: + enum: [5, 6] + + remote-endpoint: true + + bus-width: + enum: [8, 9, 10, 11, 12] + default: 12 + + hsync-active: + enum: [0, 1] + default: 1 + + vsync-active: + enum: [0, 1] + default: 1 + + pclk-sample: + enum: [0, 1] + default: 1 + + required: + - remote-endpoint + - bus-type + + additionalProperties: false + + additionalProperties: false + +required: + - compatible + - reg + - clocks + - clock-names + - '#clock-cells' + - clock-output-names + - port + +additionalProperties: false + +examples: + - | + #include + #include + #include + + xisc: xisc@e1408000 { + compatible = "microchip,sama7g5-isc"; + reg = <0xe1408000 0x2000>; + interrupts = ; + clocks = <&pmc PMC_TYPE_PERIPHERAL 56>; + clock-names = "hclock"; + #clock-cells = <0>; + clock-output-names = "isc-mck"; + + port { + xisc_in: endpoint { + bus-type = <5>; /* Parallel */ + remote-endpoint = <&csi2dc_out>; + hsync-active = <1>; + vsync-active = <1>; + bus-width = <12>; + }; + }; + }; + -- cgit v1.2.3 From 53a370f621a04a06bd2402c13580d7e4eb172c98 Mon Sep 17 00:00:00 2001 From: Alexander Voronov Date: Tue, 1 Jun 2021 22:28:12 +0200 Subject: media: rc: add keymap for Toshiba CT-90405 remote This is an NEC remote control device shipped with some Toshiba TVs. Signed-off-by: Alexander Voronov Signed-off-by: Sean Young Signed-off-by: Mauro Carvalho Chehab --- Documentation/devicetree/bindings/media/rc.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/media/rc.yaml b/Documentation/devicetree/bindings/media/rc.yaml index 12d838b05632..d4c541c4b164 100644 --- a/Documentation/devicetree/bindings/media/rc.yaml +++ b/Documentation/devicetree/bindings/media/rc.yaml @@ -45,6 +45,7 @@ properties: - rc-cec - rc-cinergy - rc-cinergy-1400 + - rc-ct-90405 - rc-d680-dmb - rc-delock-61959 - rc-dib0700-nec -- cgit v1.2.3 From 4dd0f63b51c24afd2f34afbae2e728cf00c390e6 Mon Sep 17 00:00:00 2001 From: Benjamin Gaignard Date: Thu, 3 Jun 2021 13:49:56 +0200 Subject: media: hevc: Add fields and flags for hevc PPS Add fields and flags as they are defined in 7.4.3.3.1 "General picture parameter set RBSP semantics of the H.265 ITU specification. Signed-off-by: Benjamin Gaignard Reviewed-by: Ezequiel Garcia Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab --- Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst | 14 ++++++++++++++ 1 file changed, 14 insertions(+) (limited to 'Documentation') diff --git a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst index 2b5edab55bb4..15468dcfaf08 100644 --- a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst +++ b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst @@ -2786,6 +2786,12 @@ enum v4l2_mpeg_video_hevc_size_of_length_field - * - __u8 - ``num_extra_slice_header_bits`` - + * - __u8 + - ``num_ref_idx_l0_default_active_minus1`` + - Specifies the inferred value of num_ref_idx_l0_active_minus1 + * - __u8 + - ``num_ref_idx_l1_default_active_minus1`` + - Specifies the inferred value of num_ref_idx_l1_active_minus1 * - __s8 - ``init_qp_minus26`` - @@ -2896,6 +2902,14 @@ enum v4l2_mpeg_video_hevc_size_of_length_field - * - ``V4L2_HEVC_PPS_FLAG_SLICE_SEGMENT_HEADER_EXTENSION_PRESENT`` - 0x00040000 - + * - ``V4L2_HEVC_PPS_FLAG_DEBLOCKING_FILTER_CONTROL_PRESENT`` + - 0x00080000 + - Specifies the presence of deblocking filter control syntax elements in + the PPS + * - ``V4L2_HEVC_PPS_FLAG_UNIFORM_SPACING`` + - 0x00100000 + - Specifies that tile column boundaries and likewise tile row boundaries + are distributed uniformly across the picture .. raw:: latex -- cgit v1.2.3 From d395a78db9eabd12633b39e05c80e803543b6590 Mon Sep 17 00:00:00 2001 From: Benjamin Gaignard Date: Thu, 3 Jun 2021 13:49:57 +0200 Subject: media: hevc: Add decode params control Add decode params control and the associated structure to group all the information that are needed to decode a reference frame as is described in ITU-T Rec. H.265 section "8.3.2 Decoding process for reference picture set". Adapt Cedrus driver to these changes. Signed-off-by: Benjamin Gaignard Reviewed-by: Ezequiel Garcia Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab --- .../userspace-api/media/v4l/ext-ctrls-codec.rst | 94 +++++++++++++++++----- .../userspace-api/media/v4l/vidioc-queryctrl.rst | 6 ++ 2 files changed, 82 insertions(+), 18 deletions(-) (limited to 'Documentation') diff --git a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst index 15468dcfaf08..8c6e2a11ed95 100644 --- a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst +++ b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst @@ -3000,9 +3000,6 @@ enum v4l2_mpeg_video_hevc_size_of_length_field - * - __u8 - ``pic_struct`` - - * - __u8 - - ``num_active_dpb_entries`` - - The number of entries in ``dpb``. * - __u8 - ``ref_idx_l0[V4L2_HEVC_DPB_ENTRIES_NUM_MAX]`` - The list of L0 reference elements as indices in the DPB. @@ -3010,22 +3007,8 @@ enum v4l2_mpeg_video_hevc_size_of_length_field - - ``ref_idx_l1[V4L2_HEVC_DPB_ENTRIES_NUM_MAX]`` - The list of L1 reference elements as indices in the DPB. * - __u8 - - ``num_rps_poc_st_curr_before`` - - The number of reference pictures in the short-term set that come before - the current frame. - * - __u8 - - ``num_rps_poc_st_curr_after`` - - The number of reference pictures in the short-term set that come after - the current frame. - * - __u8 - - ``num_rps_poc_lt_curr`` - - The number of reference pictures in the long-term set. - * - __u8 - - ``padding[7]`` + - ``padding`` - Applications and drivers must set this to zero. - * - struct :c:type:`v4l2_hevc_dpb_entry` - - ``dpb[V4L2_HEVC_DPB_ENTRIES_NUM_MAX]`` - - The decoded picture buffer, for meta-data about reference frames. * - struct :c:type:`v4l2_hevc_pred_weight_table` - ``pred_weight_table`` - The prediction weight coefficients for inter-picture prediction. @@ -3281,3 +3264,78 @@ enum v4l2_mpeg_video_hevc_size_of_length_field - encoding the next frame queued after setting this control. This provides a bitmask which consists of bits [0, LTR_COUNT-1]. This is applicable to the H264 and HEVC encoders. + +``V4L2_CID_MPEG_VIDEO_HEVC_DECODE_PARAMS (struct)`` + Specifies various decode parameters, especially the references picture order + count (POC) for all the lists (short, long, before, current, after) and the + number of entries for each of them. + These parameters are defined according to :ref:`hevc`. + They are described in section 8.3 "Slice decoding process" of the + specification. + +.. c:type:: v4l2_ctrl_hevc_decode_params + +.. cssclass:: longtable + +.. flat-table:: struct v4l2_ctrl_hevc_decode_params + :header-rows: 0 + :stub-columns: 0 + :widths: 1 1 2 + + * - __s32 + - ``pic_order_cnt_val`` + - PicOrderCntVal as described in section 8.3.1 "Decoding process + for picture order count" of the specification. + * - __u8 + - ``num_active_dpb_entries`` + - The number of entries in ``dpb``. + * - struct :c:type:`v4l2_hevc_dpb_entry` + - ``dpb[V4L2_HEVC_DPB_ENTRIES_NUM_MAX]`` + - The decoded picture buffer, for meta-data about reference frames. + * - __u8 + - ``num_poc_st_curr_before`` + - The number of reference pictures in the short-term set that come before + the current frame. + * - __u8 + - ``num_poc_st_curr_after`` + - The number of reference pictures in the short-term set that come after + the current frame. + * - __u8 + - ``num_poc_lt_curr`` + - The number of reference pictures in the long-term set. + * - __u8 + - ``poc_st_curr_before[V4L2_HEVC_DPB_ENTRIES_NUM_MAX]`` + - PocStCurrBefore as described in section 8.3.2 "Decoding process for reference + picture set. + * - __u8 + - ``poc_st_curr_after[V4L2_HEVC_DPB_ENTRIES_NUM_MAX]`` + - PocStCurrAfter as described in section 8.3.2 "Decoding process for reference + picture set. + * - __u8 + - ``poc_lt_curr[V4L2_HEVC_DPB_ENTRIES_NUM_MAX]`` + - PocLtCurr as described in section 8.3.2 "Decoding process for reference + picture set. + * - __u64 + - ``flags`` + - See :ref:`Decode Parameters Flags ` + +.. _hevc_decode_params_flags: + +``Decode Parameters Flags`` + +.. cssclass:: longtable + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + :widths: 1 1 2 + + * - ``V4L2_HEVC_DECODE_PARAM_FLAG_IRAP_PIC`` + - 0x00000001 + - + * - ``V4L2_HEVC_DECODE_PARAM_FLAG_IDR_PIC`` + - 0x00000002 + - + * - ``V4L2_HEVC_DECODE_PARAM_FLAG_NO_OUTPUT_OF_PRIOR`` + - 0x00000004 + - diff --git a/Documentation/userspace-api/media/v4l/vidioc-queryctrl.rst b/Documentation/userspace-api/media/v4l/vidioc-queryctrl.rst index 07e54029e1e9..f9ecf6276129 100644 --- a/Documentation/userspace-api/media/v4l/vidioc-queryctrl.rst +++ b/Documentation/userspace-api/media/v4l/vidioc-queryctrl.rst @@ -501,6 +501,12 @@ See also the examples in :ref:`control`. - n/a - A struct :c:type:`v4l2_ctrl_vp8_frame`, containing VP8 frame parameters for stateless video decoders. + * - ``V4L2_CTRL_TYPE_HEVC_DECODE_PARAMS`` + - n/a + - n/a + - n/a + - A struct :c:type:`v4l2_ctrl_hevc_decode_params`, containing HEVC + decoding parameters for stateless video decoders. .. raw:: latex -- cgit v1.2.3 From 35f51f6091bcf2cb90d9ac2f41465c415a34632e Mon Sep 17 00:00:00 2001 From: Benjamin Gaignard Date: Thu, 3 Jun 2021 13:50:01 +0200 Subject: media: uapi: Add a control for HANTRO driver The HEVC HANTRO driver needs to know the number of bits to skip at the beginning of the slice header. That is a hardware specific requirement so create a dedicated control for this purpose. Signed-off-by: Benjamin Gaignard Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab --- Documentation/userspace-api/media/drivers/hantro.rst | 19 +++++++++++++++++++ Documentation/userspace-api/media/drivers/index.rst | 1 + 2 files changed, 20 insertions(+) create mode 100644 Documentation/userspace-api/media/drivers/hantro.rst (limited to 'Documentation') diff --git a/Documentation/userspace-api/media/drivers/hantro.rst b/Documentation/userspace-api/media/drivers/hantro.rst new file mode 100644 index 000000000000..cd9754b4e005 --- /dev/null +++ b/Documentation/userspace-api/media/drivers/hantro.rst @@ -0,0 +1,19 @@ +.. SPDX-License-Identifier: GPL-2.0 + +Hantro video decoder driver +=========================== + +The Hantro video decoder driver implements the following driver-specific controls: + +``V4L2_CID_HANTRO_HEVC_SLICE_HEADER_SKIP (integer)`` + Specifies to Hantro HEVC video decoder driver the number of data (in bits) to + skip in the slice segment header. + If non-IDR, the bits to be skipped go from syntax element "pic_output_flag" + to before syntax element "slice_temporal_mvp_enabled_flag". + If IDR, the skipped bits are just "pic_output_flag" + (separate_colour_plane_flag is not supported). + +.. note:: + + This control is not yet part of the public kernel API and + it is expected to change. diff --git a/Documentation/userspace-api/media/drivers/index.rst b/Documentation/userspace-api/media/drivers/index.rst index 1a9038f5f9fa..12e3c512d718 100644 --- a/Documentation/userspace-api/media/drivers/index.rst +++ b/Documentation/userspace-api/media/drivers/index.rst @@ -33,6 +33,7 @@ For more details see the file COPYING in the source distribution of Linux. ccs cx2341x-uapi + hantro imx-uapi max2175 meye-uapi -- cgit v1.2.3 From aa7899537a4ec63ac3d58c9ece945c2750d22168 Mon Sep 17 00:00:00 2001 From: Maxime Ripard Date: Tue, 25 May 2021 15:23:43 +0200 Subject: ALSA: doc: Clarify IEC958 controls iface The doc currently mentions that the IEC958 Playback Default should be exposed on the PCM iface, and the Playback Mask on the mixer iface. It's a bit confusing to advise to have two related controls on two separate ifaces, and it looks like the drivers that currently expose those controls use any combination of the mixer and PCM ifaces. Let's try to clarify the situation a bit, and encourage to at least have the controls on the same iface. Signed-off-by: Maxime Ripard Reviewed-by: Takashi Iwai Link: https://lore.kernel.org/r/20210525132354.297468-2-maxime@cerno.tech --- Documentation/sound/kernel-api/writing-an-alsa-driver.rst | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) (limited to 'Documentation') diff --git a/Documentation/sound/kernel-api/writing-an-alsa-driver.rst b/Documentation/sound/kernel-api/writing-an-alsa-driver.rst index e6365836fa8b..01d59b8aea92 100644 --- a/Documentation/sound/kernel-api/writing-an-alsa-driver.rst +++ b/Documentation/sound/kernel-api/writing-an-alsa-driver.rst @@ -3508,14 +3508,15 @@ field must be set, though). “IEC958 Playback Con Mask” is used to return the bit-mask for the IEC958 status bits of consumer mode. Similarly, “IEC958 Playback Pro Mask” -returns the bitmask for professional mode. They are read-only controls, -and are defined as MIXER controls (iface = -``SNDRV_CTL_ELEM_IFACE_MIXER``). +returns the bitmask for professional mode. They are read-only controls. Meanwhile, “IEC958 Playback Default” control is defined for getting and -setting the current default IEC958 bits. Note that this one is usually -defined as a PCM control (iface = ``SNDRV_CTL_ELEM_IFACE_PCM``), -although in some places it's defined as a MIXER control. +setting the current default IEC958 bits. + +Due to historical reasons, both variants of the Playback Mask and the +Playback Default controls can be implemented on either a +``SNDRV_CTL_ELEM_IFACE_PCM`` or a ``SNDRV_CTL_ELEM_IFACE_MIXER`` iface. +Drivers should expose the mask and default on the same iface though. In addition, you can define the control switches to enable/disable or to set the raw bit mode. The implementation will depend on the chip, but -- cgit v1.2.3 From a9f15dc2b9733cb5870e655e6b77a4ec2cc51b8b Mon Sep 17 00:00:00 2001 From: Joakim Zhang Date: Tue, 8 Jun 2021 11:15:32 +0800 Subject: dt-bindings: net: add dt binding for realtek rtl82xx phy Add binding for realtek rtl82xx phy. Signed-off-by: Joakim Zhang Signed-off-by: David S. Miller --- .../devicetree/bindings/net/realtek,rtl82xx.yaml | 45 ++++++++++++++++++++++ 1 file changed, 45 insertions(+) create mode 100644 Documentation/devicetree/bindings/net/realtek,rtl82xx.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/realtek,rtl82xx.yaml b/Documentation/devicetree/bindings/net/realtek,rtl82xx.yaml new file mode 100644 index 000000000000..bb94a2388520 --- /dev/null +++ b/Documentation/devicetree/bindings/net/realtek,rtl82xx.yaml @@ -0,0 +1,45 @@ +# SPDX-License-Identifier: GPL-2.0+ +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/realtek,rtl82xx.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Realtek RTL82xx PHY + +maintainers: + - Andrew Lunn + - Florian Fainelli + - Heiner Kallweit + +description: + Bindings for Realtek RTL82xx PHYs + +allOf: + - $ref: ethernet-phy.yaml# + +properties: + realtek,clkout-disable: + type: boolean + description: + Disable CLKOUT clock, CLKOUT clock default is enabled after hardware reset. + + + realtek,aldps-enable: + type: boolean + description: + Enable ALDPS mode, ALDPS mode default is disabled after hardware reset. + +unevaluatedProperties: false + +examples: + - | + mdio { + #address-cells = <1>; + #size-cells = <0>; + + ethphy1: ethernet-phy@1 { + reg = <1>; + realtek,clkout-disable; + realtek,aldps-enable; + }; + }; -- cgit v1.2.3 From 3958e2d0c34e18c41b60dc01832bd670a59ef70f Mon Sep 17 00:00:00 2001 From: Suren Baghdasaryan Date: Mon, 24 May 2021 12:53:39 -0700 Subject: cgroup: make per-cgroup pressure stall tracking configurable PSI accounts stalls for each cgroup separately and aggregates it at each level of the hierarchy. This causes additional overhead with psi_avgs_work being called for each cgroup in the hierarchy. psi_avgs_work has been highly optimized, however on systems with large number of cgroups the overhead becomes noticeable. Systems which use PSI only at the system level could avoid this overhead if PSI can be configured to skip per-cgroup stall accounting. Add "cgroup_disable=pressure" kernel command-line option to allow requesting system-wide only pressure stall accounting. When set, it keeps system-wide accounting under /proc/pressure/ but skips accounting for individual cgroups and does not expose PSI nodes in cgroup hierarchy. Signed-off-by: Suren Baghdasaryan Acked-by: Peter Zijlstra (Intel) Acked-by: Johannes Weiner Signed-off-by: Tejun Heo --- Documentation/admin-guide/kernel-parameters.txt | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index cb89dbdedc46..653c62142f07 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -497,16 +497,21 @@ ccw_timeout_log [S390] See Documentation/s390/common_io.rst for details. - cgroup_disable= [KNL] Disable a particular controller - Format: {name of the controller(s) to disable} + cgroup_disable= [KNL] Disable a particular controller or optional feature + Format: {name of the controller(s) or feature(s) to disable} The effects of cgroup_disable=foo are: - foo isn't auto-mounted if you mount all cgroups in a single hierarchy - foo isn't visible as an individually mountable subsystem + - if foo is an optional feature then the feature is + disabled and corresponding cgroup files are not + created {Currently only "memory" controller deal with this and cut the overhead, others just disable the usage. So only cgroup_disable=memory is actually worthy} + Specifying "pressure" disables per-cgroup pressure + stall information accounting feature cgroup_no_v1= [KNL] Disable cgroup controllers and named hierarchies in v1 Format: { { controller | "all" | "named" } -- cgit v1.2.3 From 22a558f567ab40b6ea779d0f535d3e32c35c099a Mon Sep 17 00:00:00 2001 From: Roberto Sassu Date: Tue, 8 Jun 2021 14:31:20 +0200 Subject: doc: Fix warning in Documentation/security/IMA-templates.rst This patch fixes the warning: Documentation/security/IMA-templates.rst:81: WARNING: Inline substitution_reference start-string without end-string. Reported-by: Stephen Rothwell Signed-off-by: Roberto Sassu Signed-off-by: Mimi Zohar --- Documentation/security/IMA-templates.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/security/IMA-templates.rst b/Documentation/security/IMA-templates.rst index 5adc22f99496..1a91d92950a7 100644 --- a/Documentation/security/IMA-templates.rst +++ b/Documentation/security/IMA-templates.rst @@ -78,7 +78,7 @@ descriptors by adding their identifier to the format string - 'iuid': the inode UID; - 'igid': the inode GID; - 'imode': the inode mode; - - 'xattrnames': a list of xattr names (separated by |), only if the xattr is + - 'xattrnames': a list of xattr names (separated by ``|``), only if the xattr is present; - 'xattrlengths': a list of xattr lengths (u32), only if the xattr is present; - 'xattrvalues': a list of xattr values; -- cgit v1.2.3 From 224bd597a4f37a918c492be35aac1ccf4b8507f4 Mon Sep 17 00:00:00 2001 From: Stefan Wahren Date: Sun, 6 Jun 2021 14:16:14 +0200 Subject: dt-bindings: arm: bcm2835: Add Raspberry Pi 400 to DT schema Add new Raspberry Pi 400 to DT schema. Signed-off-by: Stefan Wahren Acked-by: Rob Herring Link: https://lore.kernel.org/r/1622981777-5023-5-git-send-email-stefan.wahren@i2se.com Signed-off-by: Nicolas Saenz Julienne --- Documentation/devicetree/bindings/arm/bcm/bcm2835.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/bcm/bcm2835.yaml b/Documentation/devicetree/bindings/arm/bcm/bcm2835.yaml index 812ae8cc5959..230b80d9d6cf 100644 --- a/Documentation/devicetree/bindings/arm/bcm/bcm2835.yaml +++ b/Documentation/devicetree/bindings/arm/bcm/bcm2835.yaml @@ -18,6 +18,7 @@ properties: - description: BCM2711 based Boards items: - enum: + - raspberrypi,400 - raspberrypi,4-model-b - const: brcm,bcm2711 -- cgit v1.2.3 From 070f5b701d559ae139b348fb19145269b58b68c3 Mon Sep 17 00:00:00 2001 From: Vladimir Oltean Date: Tue, 8 Jun 2021 12:25:35 +0300 Subject: dt-bindings: net: dsa: sja1105: add SJA1110 bindings There are 4 variations of the SJA1110 switch which have a different set of MII protocols supported per port. Document the compatible strings. Also, the SJA1110 optionally supports 2 internal MDIO buses for 2 different types of Ethernet PHYs. Document a container node called "mdios" which has 2 subnodes "mdio@0" and "mdio@1", identifiable via compatible string, under which the driver finds the internal PHYs. Cc: Rob Herring Cc: devicetree@vger.kernel.org Signed-off-by: Vladimir Oltean Signed-off-by: David S. Miller --- .../devicetree/bindings/net/dsa/nxp,sja1105.yaml | 43 ++++++++++++++++++++++ 1 file changed, 43 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/dsa/nxp,sja1105.yaml b/Documentation/devicetree/bindings/net/dsa/nxp,sja1105.yaml index d6ac9a0c1b04..0b8a05dd52e6 100644 --- a/Documentation/devicetree/bindings/net/dsa/nxp,sja1105.yaml +++ b/Documentation/devicetree/bindings/net/dsa/nxp,sja1105.yaml @@ -27,10 +27,53 @@ properties: - nxp,sja1105q - nxp,sja1105r - nxp,sja1105s + - nxp,sja1110a + - nxp,sja1110b + - nxp,sja1110c + - nxp,sja1110d reg: maxItems: 1 + # Optional container node for the 2 internal MDIO buses of the SJA1110 + # (one for the internal 100base-T1 PHYs and the other for the single + # 100base-TX PHY). The "reg" property does not have physical significance. + # The PHY addresses to port correspondence is as follows: for 100base-T1, + # port 5 has PHY 1, port 6 has PHY 2 etc, while for 100base-TX, port 1 has + # PHY 1. + mdios: + type: object + + properties: + '#address-cells': + const: 1 + '#size-cells': + const: 0 + + patternProperties: + "^mdio@[0-1]$": + type: object + + allOf: + - $ref: "http://devicetree.org/schemas/net/mdio.yaml#" + + properties: + compatible: + oneOf: + - enum: + - nxp,sja1110-base-t1-mdio + - nxp,sja1110-base-tx-mdio + + reg: + oneOf: + - enum: + - 0 + - 1 + + required: + - compatible + - reg + required: - compatible - reg -- cgit v1.2.3 From 511c537bb5647662ff7df7a41180a1721c078720 Mon Sep 17 00:00:00 2001 From: Shay Agroskin Date: Tue, 8 Jun 2021 19:01:15 +0300 Subject: net: ena: fix RST format in ENA documentation file The documentation file used to be written in markdown format but was converted to reStructuredText (rst). The converted file doesn't keep up with rst format requirements which results in hard-to-read text. This patch fixes the formatting of the file. The patch also * Highlights and emphasizes some lines to improve readability * Rephrases some hard-to-understand text * Updates outdated function descriptions. * Removes TSO description which falsely claims the driver supports it Signed-off-by: Shay Agroskin Signed-off-by: David S. Miller --- .../device_drivers/ethernet/amazon/ena.rst | 164 ++++++++++----------- 1 file changed, 78 insertions(+), 86 deletions(-) (limited to 'Documentation') diff --git a/Documentation/networking/device_drivers/ethernet/amazon/ena.rst b/Documentation/networking/device_drivers/ethernet/amazon/ena.rst index f8c6469f2bd2..01b2a69b0cb0 100644 --- a/Documentation/networking/device_drivers/ethernet/amazon/ena.rst +++ b/Documentation/networking/device_drivers/ethernet/amazon/ena.rst @@ -11,12 +11,12 @@ ENA is a networking interface designed to make good use of modern CPU features and system architectures. The ENA device exposes a lightweight management interface with a -minimal set of memory mapped registers and extendable command set +minimal set of memory mapped registers and extendible command set through an Admin Queue. The driver supports a range of ENA devices, is link-speed independent -(i.e., the same driver is used for 10GbE, 25GbE, 40GbE, etc.), and has -a negotiated and extendable feature set. +(i.e., the same driver is used for 10GbE, 25GbE, 40GbE, etc), and has +a negotiated and extendible feature set. Some ENA devices support SR-IOV. This driver is used for both the SR-IOV Physical Function (PF) and Virtual Function (VF) devices. @@ -27,9 +27,9 @@ is advertised by the device via the Admin Queue), a dedicated MSI-X interrupt vector per Tx/Rx queue pair, adaptive interrupt moderation, and CPU cacheline optimized data placement. -The ENA driver supports industry standard TCP/IP offload features such -as checksum offload and TCP transmit segmentation offload (TSO). -Receive-side scaling (RSS) is supported for multi-core scaling. +The ENA driver supports industry standard TCP/IP offload features such as +checksum offload. Receive-side scaling (RSS) is supported for multi-core +scaling. The ENA driver and its corresponding devices implement health monitoring mechanisms such as watchdog, enabling the device and driver @@ -38,22 +38,20 @@ debug logs. Some of the ENA devices support a working mode called Low-latency Queue (LLQ), which saves several more microseconds. - ENA Source Code Directory Structure =================================== ================= ====================================================== ena_com.[ch] Management communication layer. This layer is - responsible for the handling all the management - (admin) communication between the device and the - driver. + responsible for the handling all the management + (admin) communication between the device and the + driver. ena_eth_com.[ch] Tx/Rx data path. ena_admin_defs.h Definition of ENA management interface. ena_eth_io_defs.h Definition of ENA data path interface. ena_common_defs.h Common definitions for ena_com layer. ena_regs_defs.h Definition of ENA PCI memory-mapped (MMIO) registers. ena_netdev.[ch] Main Linux kernel driver. -ena_syfsfs.[ch] Sysfs files. ena_ethtool.c ethtool callbacks. ena_pci_id_tbl.h Supported device IDs. ================= ====================================================== @@ -69,7 +67,7 @@ ENA management interface is exposed by means of: - Asynchronous Event Notification Queue (AENQ) ENA device MMIO Registers are accessed only during driver -initialization and are not involved in further normal device +initialization and are not used during further normal device operation. AQ is used for submitting management commands, and the @@ -100,28 +98,27 @@ group may have multiple syndromes, as shown below The events are: - ==================== =============== - Group Syndrome - ==================== =============== - Link state change **X** - Fatal error **X** - Notification Suspend traffic - Notification Resume traffic - Keep-Alive **X** - ==================== =============== +==================== =============== +Group Syndrome +==================== =============== +Link state change **X** +Fatal error **X** +Notification Suspend traffic +Notification Resume traffic +Keep-Alive **X** +==================== =============== ACQ and AENQ share the same MSI-X vector. -Keep-Alive is a special mechanism that allows monitoring of the -device's health. The driver maintains a watchdog (WD) handler which, -if fired, logs the current state and statistics then resets and -restarts the ENA device and driver. A Keep-Alive event is delivered by -the device every second. The driver re-arms the WD upon reception of a -Keep-Alive event. A missed Keep-Alive event causes the WD handler to -fire. +Keep-Alive is a special mechanism that allows monitoring the device's health. +A Keep-Alive event is delivered by the device every second. +The driver maintains a watchdog (WD) handler which logs the current state and +statistics. If the keep-alive events aren't delivered as expected the WD resets +the device and the driver. Data Path Interface =================== + I/O operations are based on Tx and Rx Submission Queues (Tx SQ and Rx SQ correspondingly). Each SQ has a completion queue (CQ) associated with it. @@ -131,26 +128,24 @@ physical memory. The ENA driver supports two Queue Operation modes for Tx SQs: -- Regular mode +- **Regular mode:** + In this mode the Tx SQs reside in the host's memory. The ENA + device fetches the ENA Tx descriptors and packet data from host + memory. - * In this mode the Tx SQs reside in the host's memory. The ENA - device fetches the ENA Tx descriptors and packet data from host - memory. +- **Low Latency Queue (LLQ) mode or "push-mode":** + In this mode the driver pushes the transmit descriptors and the + first 128 bytes of the packet directly to the ENA device memory + space. The rest of the packet payload is fetched by the + device. For this operation mode, the driver uses a dedicated PCI + device memory BAR, which is mapped with write-combine capability. -- Low Latency Queue (LLQ) mode or "push-mode". - - * In this mode the driver pushes the transmit descriptors and the - first 128 bytes of the packet directly to the ENA device memory - space. The rest of the packet payload is fetched by the - device. For this operation mode, the driver uses a dedicated PCI - device memory BAR, which is mapped with write-combine capability. + **Note that** not all ENA devices support LLQ, and this feature is negotiated + with the device upon initialization. If the ENA device does not + support LLQ mode, the driver falls back to the regular mode. The Rx SQs support only the regular mode. -Note: Not all ENA devices support LLQ, and this feature is negotiated - with the device upon initialization. If the ENA device does not - support LLQ mode, the driver falls back to the regular mode. - The driver supports multi-queue for both Tx and Rx. This has various benefits: @@ -165,6 +160,7 @@ benefits: Interrupt Modes =============== + The driver assigns a single MSI-X vector per queue pair (for both Tx and Rx directions). The driver assigns an additional dedicated MSI-X vector for management (for ACQ and AENQ). @@ -190,20 +186,21 @@ unmasked by the driver after NAPI processing is complete. Interrupt Moderation ==================== + ENA driver and device can operate in conventional or adaptive interrupt moderation mode. -In conventional mode the driver instructs device to postpone interrupt +**In conventional mode** the driver instructs device to postpone interrupt posting according to static interrupt delay value. The interrupt delay -value can be configured through ethtool(8). The following ethtool -parameters are supported by the driver: tx-usecs, rx-usecs +value can be configured through `ethtool(8)`. The following `ethtool` +parameters are supported by the driver: ``tx-usecs``, ``rx-usecs`` -In adaptive interrupt moderation mode the interrupt delay value is +**In adaptive interrupt** moderation mode the interrupt delay value is updated by the driver dynamically and adjusted every NAPI cycle according to the traffic nature. -Adaptive coalescing can be switched on/off through ethtool(8) -adaptive_rx on|off parameter. +Adaptive coalescing can be switched on/off through `ethtool(8)`'s +:code:`adaptive_rx on|off` parameter. More information about Adaptive Interrupt Moderation (DIM) can be found in Documentation/networking/net_dim.rst @@ -214,17 +211,10 @@ The rx_copybreak is initialized by default to ENA_DEFAULT_RX_COPYBREAK and can be configured by the ETHTOOL_STUNABLE command of the SIOCETHTOOL ioctl. -SKB -=== -The driver-allocated SKB for frames received from Rx handling using -NAPI context. The allocation method depends on the size of the packet. -If the frame length is larger than rx_copybreak, napi_get_frags() -is used, otherwise netdev_alloc_skb_ip_align() is used, the buffer -content is copied (by CPU) to the SKB, and the buffer is recycled. - Statistics ========== -The user can obtain ENA device and driver statistics using ethtool. + +The user can obtain ENA device and driver statistics using `ethtool`. The driver can collect regular or extended statistics (including per-queue stats) from the device. @@ -232,22 +222,23 @@ In addition the driver logs the stats to syslog upon device reset. MTU === + The driver supports an arbitrarily large MTU with a maximum that is negotiated with the device. The driver configures MTU using the SetFeature command (ENA_ADMIN_MTU property). The user can change MTU -via ip(8) and similar legacy tools. +via `ip(8)` and similar legacy tools. Stateless Offloads ================== + The ENA driver supports: -- TSO over IPv4/IPv6 -- TSO with ECN - IPv4 header checksum offload - TCP/UDP over IPv4/IPv6 checksum offloads RSS === + - The ENA device supports RSS that allows flexible Rx traffic steering. - Toeplitz and CRC32 hash functions are supported. @@ -260,41 +251,42 @@ RSS function delivered in the Rx CQ descriptor is set in the received SKB. - The user can provide a hash key, hash function, and configure the - indirection table through ethtool(8). + indirection table through `ethtool(8)`. DATA PATH ========= + Tx -- -ena_start_xmit() is called by the stack. This function does the following: +:code:`ena_start_xmit()` is called by the stack. This function does the following: -- Maps data buffers (skb->data and frags). -- Populates ena_buf for the push buffer (if the driver and device are - in push mode.) +- Maps data buffers (``skb->data`` and frags). +- Populates ``ena_buf`` for the push buffer (if the driver and device are + in push mode). - Prepares ENA bufs for the remaining frags. -- Allocates a new request ID from the empty req_id ring. The request +- Allocates a new request ID from the empty ``req_id`` ring. The request ID is the index of the packet in the Tx info. This is used for - out-of-order TX completions. + out-of-order Tx completions. - Adds the packet to the proper place in the Tx ring. -- Calls ena_com_prepare_tx(), an ENA communication layer that converts - the ena_bufs to ENA descriptors (and adds meta ENA descriptors as - needed.) +- Calls :code:`ena_com_prepare_tx()`, an ENA communication layer that converts + the ``ena_bufs`` to ENA descriptors (and adds meta ENA descriptors as + needed). * This function also copies the ENA descriptors and the push buffer - to the Device memory space (if in push mode.) + to the Device memory space (if in push mode). -- Writes doorbell to the ENA device. +- Writes a doorbell to the ENA device. - When the ENA device finishes sending the packet, a completion interrupt is raised. - The interrupt handler schedules NAPI. -- The ena_clean_tx_irq() function is called. This function handles the +- The :code:`ena_clean_tx_irq()` function is called. This function handles the completion descriptors generated by the ENA, with a single completion descriptor per completed packet. - * req_id is retrieved from the completion descriptor. The tx_info of - the packet is retrieved via the req_id. The data buffers are - unmapped and req_id is returned to the empty req_id ring. + * ``req_id`` is retrieved from the completion descriptor. The ``tx_info`` of + the packet is retrieved via the ``req_id``. The data buffers are + unmapped and ``req_id`` is returned to the empty ``req_id`` ring. * The function stops when the completion descriptors are completed or the budget is reached. @@ -303,12 +295,11 @@ Rx - When a packet is received from the ENA device. - The interrupt handler schedules NAPI. -- The ena_clean_rx_irq() function is called. This function calls - ena_rx_pkt(), an ENA communication layer function, which returns the - number of descriptors used for a new unhandled packet, and zero if +- The :code:`ena_clean_rx_irq()` function is called. This function calls + :code:`ena_com_rx_pkt()`, an ENA communication layer function, which returns the + number of descriptors used for a new packet, and zero if no new packet is found. -- Then it calls the ena_clean_rx_irq() function. -- ena_eth_rx_skb() checks packet length: +- :code:`ena_rx_skb()` checks packet length: * If the packet is small (len < rx_copybreak), the driver allocates a SKB for the new packet, and copies the packet payload into the @@ -317,9 +308,10 @@ Rx - In this way the original data buffer is not passed to the stack and is reused for future Rx packets. - * Otherwise the function unmaps the Rx buffer, then allocates the - new SKB structure and hooks the Rx buffer to the SKB frags. + * Otherwise the function unmaps the Rx buffer, sets the first + descriptor as `skb`'s linear part and the other descriptors as the + `skb`'s frags. - The new SKB is updated with the necessary information (protocol, - checksum hw verify result, etc.), and then passed to the network - stack, using the NAPI interface function napi_gro_receive(). + checksum hw verify result, etc), and then passed to the network + stack, using the NAPI interface function :code:`napi_gro_receive()`. -- cgit v1.2.3 From 4a8bc2644ef0cbf8ebe46da3887eafd309b0f187 Mon Sep 17 00:00:00 2001 From: Dario Binacchi Date: Sun, 6 Jun 2021 22:22:50 +0200 Subject: dt-bindings: ti: dpll: add spread spectrum support DT bindings for enabling and adjusting spread spectrum clocking have been added. Signed-off-by: Dario Binacchi Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20210606202253.31649-3-dariobin@libero.it Signed-off-by: Stephen Boyd --- Documentation/devicetree/bindings/clock/ti/dpll.txt | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/ti/dpll.txt b/Documentation/devicetree/bindings/clock/ti/dpll.txt index df57009ff8e7..37a7cb6ad07d 100644 --- a/Documentation/devicetree/bindings/clock/ti/dpll.txt +++ b/Documentation/devicetree/bindings/clock/ti/dpll.txt @@ -42,6 +42,11 @@ Required properties: "idlest" - contains the idle status register base address "mult-div1" - contains the multiplier / divider register base address "autoidle" - contains the autoidle register base address (optional) + "ssc-deltam" - DPLL supports spread spectrum clocking (SSC), contains + the frequency spreading register base address (optional) + "ssc-modfreq" - DPLL supports spread spectrum clocking (SSC), contains + the modulation frequency register base address + (optional) ti,am3-* dpll types do not have autoidle register ti,omap2-* dpll type does not support idlest / autoidle registers @@ -51,6 +56,14 @@ Optional properties: - ti,low-power-stop : DPLL supports low power stop mode, gating output - ti,low-power-bypass : DPLL output matches rate of parent bypass clock - ti,lock : DPLL locks in programmed rate + - ti,min-div : the minimum divisor to start from to round the DPLL + target rate + - ti,ssc-deltam : DPLL supports spread spectrum clocking, frequency + spreading in permille (10th of a percent) + - ti,ssc-modfreq-hz : DPLL supports spread spectrum clocking, spread + spectrum modulation frequency + - ti,ssc-downspread : DPLL supports spread spectrum clocking, boolean + to enable the downspread feature Examples: dpll_core_ck: dpll_core_ck@44e00490 { @@ -83,3 +96,10 @@ Examples: clocks = <&sys_ck>, <&sys_ck>; reg = <0x0500>, <0x0540>; }; + + dpll_disp_ck: dpll_disp_ck { + #clock-cells = <0>; + compatible = "ti,am3-dpll-no-gate-clock"; + clocks = <&sys_clkin_ck>, <&sys_clkin_ck>; + reg = <0x0498>, <0x0448>, <0x0454>, <0x044c>, <0x0450>; + }; -- cgit v1.2.3 From bb718cad0a62717cab1fd847c94623d599e05c86 Mon Sep 17 00:00:00 2001 From: Rob Herring Date: Mon, 7 Jun 2021 08:49:17 -0500 Subject: dt-bindings: rtc: Add Arm PL031 schema The PL031 RTC binding has been in use for a long time, but never got documented. Fortunately, it's simple and existing users are consistent. Cc: Alessandro Zummo Cc: linux-rtc@vger.kernel.org Acked-by: Alexandre Belloni Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20210607193718.3090202-1-robh@kernel.org/ --- .../devicetree/bindings/rtc/arm,pl031.yaml | 58 ++++++++++++++++++++++ 1 file changed, 58 insertions(+) create mode 100644 Documentation/devicetree/bindings/rtc/arm,pl031.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/rtc/arm,pl031.yaml b/Documentation/devicetree/bindings/rtc/arm,pl031.yaml new file mode 100644 index 000000000000..fa5f2eda372e --- /dev/null +++ b/Documentation/devicetree/bindings/rtc/arm,pl031.yaml @@ -0,0 +1,58 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/rtc/arm,pl031.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Arm Primecell PL031 Real Time Clock + +select: + properties: + compatible: + contains: + const: arm,pl031 + required: + - compatible + +allOf: + - $ref: rtc.yaml# + +maintainers: + - Rob Herring + +properties: + compatible: + items: + - const: arm,pl031 + - const: arm,primecell + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + + clock-names: + maxItems: 1 + + start-year: true + +required: + - compatible + - reg + - clocks + - clock-names + +additionalProperties: false + +examples: + - | + rtc@10017000 { + compatible = "arm,pl031", "arm,primecell"; + reg = <0x10017000 0x1000>; + clocks = <&pclk>; + clock-names = "apb_pclk"; + }; -- cgit v1.2.3 From 13542a69b918db0118b75d9825bcc775c9c36ed3 Mon Sep 17 00:00:00 2001 From: Rob Herring Date: Mon, 7 Jun 2021 09:48:11 -0500 Subject: dt-bindings: virtio: Convert virtio-mmio to DT schema Convert the virtio-mmio binding to DT schema format. Cc: "Michael S. Tsirkin" Cc: Jason Wang Cc: Jean-Philippe Brucker Cc: virtualization@lists.linux-foundation.org Acked-by: Jean-Philippe Brucker Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20210607193928.3092186-1-robh@kernel.org/ --- Documentation/devicetree/bindings/virtio/mmio.txt | 47 ----------------- Documentation/devicetree/bindings/virtio/mmio.yaml | 60 ++++++++++++++++++++++ 2 files changed, 60 insertions(+), 47 deletions(-) delete mode 100644 Documentation/devicetree/bindings/virtio/mmio.txt create mode 100644 Documentation/devicetree/bindings/virtio/mmio.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/virtio/mmio.txt b/Documentation/devicetree/bindings/virtio/mmio.txt deleted file mode 100644 index 0a575f329f6e..000000000000 --- a/Documentation/devicetree/bindings/virtio/mmio.txt +++ /dev/null @@ -1,47 +0,0 @@ -* virtio memory mapped device - -See https://ozlabs.org/~rusty/virtio-spec/ for more details. - -Required properties: - -- compatible: "virtio,mmio" compatibility string -- reg: control registers base address and size including configuration space -- interrupts: interrupt generated by the device - -Required properties for virtio-iommu: - -- #iommu-cells: When the node corresponds to a virtio-iommu device, it is - linked to DMA masters using the "iommus" or "iommu-map" - properties [1][2]. #iommu-cells specifies the size of the - "iommus" property. For virtio-iommu #iommu-cells must be - 1, each cell describing a single endpoint ID. - -Optional properties: - -- iommus: If the device accesses memory through an IOMMU, it should - have an "iommus" property [1]. Since virtio-iommu itself - does not access memory through an IOMMU, the "virtio,mmio" - node cannot have both an "#iommu-cells" and an "iommus" - property. - -Example: - - virtio_block@3000 { - compatible = "virtio,mmio"; - reg = <0x3000 0x100>; - interrupts = <41>; - - /* Device has endpoint ID 23 */ - iommus = <&viommu 23> - } - - viommu: iommu@3100 { - compatible = "virtio,mmio"; - reg = <0x3100 0x100>; - interrupts = <42>; - - #iommu-cells = <1> - } - -[1] Documentation/devicetree/bindings/iommu/iommu.txt -[2] Documentation/devicetree/bindings/pci/pci-iommu.txt diff --git a/Documentation/devicetree/bindings/virtio/mmio.yaml b/Documentation/devicetree/bindings/virtio/mmio.yaml new file mode 100644 index 000000000000..d46597028cf1 --- /dev/null +++ b/Documentation/devicetree/bindings/virtio/mmio.yaml @@ -0,0 +1,60 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/virtio/mmio.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: virtio memory mapped devices + +maintainers: + - Jean-Philippe Brucker + +description: + See https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=virtio for + more details. + +properties: + compatible: + const: virtio,mmio + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + '#iommu-cells': + description: Required when the node corresponds to a virtio-iommu device. + const: 1 + + iommus: + description: Required for devices making accesses thru an IOMMU. + maxItems: 1 + +required: + - compatible + - reg + - interrupts + +additionalProperties: false + +examples: + - | + virtio@3000 { + compatible = "virtio,mmio"; + reg = <0x3000 0x100>; + interrupts = <41>; + + /* Device has endpoint ID 23 */ + iommus = <&viommu 23>; + }; + + viommu: iommu@3100 { + compatible = "virtio,mmio"; + reg = <0x3100 0x100>; + interrupts = <42>; + + #iommu-cells = <1>; + }; + +... -- cgit v1.2.3 From 7e0fc5072e0b7a3e4dfbc39ad54aefa494bdf3da Mon Sep 17 00:00:00 2001 From: Benjamin Gaignard Date: Fri, 4 Jun 2021 18:44:38 +0200 Subject: dt-bindings: iommu: rockchip: Convert IOMMU to DT schema Convert Rockchip IOMMU to DT schema Signed-off-by: Benjamin Gaignard Reviewed-by: Rob Herring Reviewed-by: Heiko Stuebner Link: https://lore.kernel.org/r/20210604164441.798362-2-benjamin.gaignard@collabora.com Signed-off-by: Joerg Roedel --- .../devicetree/bindings/iommu/rockchip,iommu.txt | 38 ---------- .../devicetree/bindings/iommu/rockchip,iommu.yaml | 80 ++++++++++++++++++++++ 2 files changed, 80 insertions(+), 38 deletions(-) delete mode 100644 Documentation/devicetree/bindings/iommu/rockchip,iommu.txt create mode 100644 Documentation/devicetree/bindings/iommu/rockchip,iommu.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/iommu/rockchip,iommu.txt b/Documentation/devicetree/bindings/iommu/rockchip,iommu.txt deleted file mode 100644 index 6ecefea1c6f9..000000000000 --- a/Documentation/devicetree/bindings/iommu/rockchip,iommu.txt +++ /dev/null @@ -1,38 +0,0 @@ -Rockchip IOMMU -============== - -A Rockchip DRM iommu translates io virtual addresses to physical addresses for -its master device. Each slave device is bound to a single master device, and -shares its clocks, power domain and irq. - -Required properties: -- compatible : Should be "rockchip,iommu" -- reg : Address space for the configuration registers -- interrupts : Interrupt specifier for the IOMMU instance -- interrupt-names : Interrupt name for the IOMMU instance -- #iommu-cells : Should be <0>. This indicates the iommu is a - "single-master" device, and needs no additional information - to associate with its master device. See: - Documentation/devicetree/bindings/iommu/iommu.txt -- clocks : A list of clocks required for the IOMMU to be accessible by - the host CPU. -- clock-names : Should contain the following: - "iface" - Main peripheral bus clock (PCLK/HCL) (required) - "aclk" - AXI bus clock (required) - -Optional properties: -- rockchip,disable-mmu-reset : Don't use the mmu reset operation. - Some mmu instances may produce unexpected results - when the reset operation is used. - -Example: - - vopl_mmu: iommu@ff940300 { - compatible = "rockchip,iommu"; - reg = <0xff940300 0x100>; - interrupts = ; - interrupt-names = "vopl_mmu"; - clocks = <&cru ACLK_VOP1>, <&cru HCLK_VOP1>; - clock-names = "aclk", "iface"; - #iommu-cells = <0>; - }; diff --git a/Documentation/devicetree/bindings/iommu/rockchip,iommu.yaml b/Documentation/devicetree/bindings/iommu/rockchip,iommu.yaml new file mode 100644 index 000000000000..099fc2578b54 --- /dev/null +++ b/Documentation/devicetree/bindings/iommu/rockchip,iommu.yaml @@ -0,0 +1,80 @@ +# SPDX-License-Identifier: GPL-2.0-only +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iommu/rockchip,iommu.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Rockchip IOMMU + +maintainers: + - Heiko Stuebner + +description: |+ + A Rockchip DRM iommu translates io virtual addresses to physical addresses for + its master device. Each slave device is bound to a single master device and + shares its clocks, power domain and irq. + + For information on assigning IOMMU controller to its peripheral devices, + see generic IOMMU bindings. + +properties: + compatible: + const: rockchip,iommu + + reg: + items: + - description: configuration registers for MMU instance 0 + - description: configuration registers for MMU instance 1 + minItems: 1 + maxItems: 2 + + interrupts: + items: + - description: interruption for MMU instance 0 + - description: interruption for MMU instance 1 + minItems: 1 + maxItems: 2 + + clocks: + items: + - description: Core clock + - description: Interface clock + + clock-names: + items: + - const: aclk + - const: iface + + "#iommu-cells": + const: 0 + + rockchip,disable-mmu-reset: + $ref: /schemas/types.yaml#/definitions/flag + description: | + Do not use the mmu reset operation. + Some mmu instances may produce unexpected results + when the reset operation is used. + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + - "#iommu-cells" + +additionalProperties: false + +examples: + - | + #include + #include + + vopl_mmu: iommu@ff940300 { + compatible = "rockchip,iommu"; + reg = <0xff940300 0x100>; + interrupts = ; + clocks = <&cru ACLK_VOP1>, <&cru HCLK_VOP1>; + clock-names = "aclk", "iface"; + #iommu-cells = <0>; + }; -- cgit v1.2.3 From 9e6f3cd589cb711b5949cfbeb84e5440906195bd Mon Sep 17 00:00:00 2001 From: Benjamin Gaignard Date: Fri, 4 Jun 2021 18:44:39 +0200 Subject: dt-bindings: iommu: rockchip: Add compatible for v2 Add compatible for the second version of IOMMU hardware block. RK356x IOMMU can also be link to a power domain. Signed-off-by: Benjamin Gaignard Reviewed-by: Rob Herring Reviewed-by: Heiko Stuebner Link: https://lore.kernel.org/r/20210604164441.798362-3-benjamin.gaignard@collabora.com Signed-off-by: Joerg Roedel --- Documentation/devicetree/bindings/iommu/rockchip,iommu.yaml | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/iommu/rockchip,iommu.yaml b/Documentation/devicetree/bindings/iommu/rockchip,iommu.yaml index 099fc2578b54..d2e28a9e3545 100644 --- a/Documentation/devicetree/bindings/iommu/rockchip,iommu.yaml +++ b/Documentation/devicetree/bindings/iommu/rockchip,iommu.yaml @@ -19,7 +19,9 @@ description: |+ properties: compatible: - const: rockchip,iommu + enum: + - rockchip,iommu + - rockchip,rk3568-iommu reg: items: @@ -48,6 +50,9 @@ properties: "#iommu-cells": const: 0 + power-domains: + maxItems: 1 + rockchip,disable-mmu-reset: $ref: /schemas/types.yaml#/definitions/flag description: | -- cgit v1.2.3 From 40c73b30546e759bedcec607fedc2d4be954508f Mon Sep 17 00:00:00 2001 From: Ruslan Bilovol Date: Fri, 4 Jun 2021 00:01:03 +0200 Subject: usb: gadget: f_uac2: add adaptive sync support for capture Current f_uac2 USB OUT (aka 'capture') synchronization implements 'ASYNC' scenario which means USB Gadget has it's own freerunning clock and can update Host about real clock frequency through feedback endpoint so Host can align number of samples sent to the USB gadget to prevent overruns/underruns In case if Gadget can has no it's internal clock and can consume audio samples at any rate (for example, on the Gadget side someone records audio directly to a file, or audio samples are played through an external DAC as soon as they arrive), UAC2 spec suggests 'ADAPTIVE' synchronization type. Change UAC2 driver to make it configurable through additional 'c_sync' configfs file. Default remains 'asynchronous' with possibility to switch it to 'adaptive' Signed-off-by: Ruslan Bilovol Signed-off-by: Jerome Brunet Link: https://lore.kernel.org/r/20210603220104.1216001-3-jbrunet@baylibre.com Signed-off-by: Greg Kroah-Hartman --- Documentation/ABI/testing/configfs-usb-gadget-uac2 | 1 + Documentation/usb/gadget-testing.rst | 1 + 2 files changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/configfs-usb-gadget-uac2 b/Documentation/ABI/testing/configfs-usb-gadget-uac2 index d4356c8b8cd6..e7e59d7fb12f 100644 --- a/Documentation/ABI/testing/configfs-usb-gadget-uac2 +++ b/Documentation/ABI/testing/configfs-usb-gadget-uac2 @@ -8,6 +8,7 @@ Description: c_chmask capture channel mask c_srate capture sampling rate c_ssize capture sample size (bytes) + c_sync capture synchronization type (async/adaptive) p_chmask playback channel mask p_srate playback sampling rate p_ssize playback sample size (bytes) diff --git a/Documentation/usb/gadget-testing.rst b/Documentation/usb/gadget-testing.rst index 2085e7b24eeb..f5a12667bd41 100644 --- a/Documentation/usb/gadget-testing.rst +++ b/Documentation/usb/gadget-testing.rst @@ -728,6 +728,7 @@ The uac2 function provides these attributes in its function directory: c_chmask capture channel mask c_srate capture sampling rate c_ssize capture sample size (bytes) + c_sync capture synchronization type (async/adaptive) p_chmask playback channel mask p_srate playback sampling rate p_ssize playback sample size (bytes) -- cgit v1.2.3 From e89bb4288378b85c82212b60dc98ecda6b3d3a70 Mon Sep 17 00:00:00 2001 From: Ruslan Bilovol Date: Fri, 4 Jun 2021 00:01:04 +0200 Subject: usb: gadget: u_audio: add real feedback implementation This adds interface between userspace and feedback endpoint to report real feedback frequency to the Host. Current implementation adds new userspace interface ALSA mixer control "Capture Pitch 1000000" (similar to aloop driver's "PCM Rate Shift 100000" mixer control) Value in PPM is chosen to have correction value agnostic of the actual HW rate, which the application is not necessarily dealing with, while still retaining a good enough precision to allow smooth clock correction on the playback side, if necessary. Similar to sound/usb/endpoint.c, a slow down is allowed up to 25%. This has no impact on the required bandwidth. Speedup correction has an impact on the bandwidth reserved for the isochronous endpoint. The default allowed speedup is 500ppm. This seems to be more than enough but, if necessary, this is configurable through a module parameter. The reserved bandwidth is rounded up to the next packet size. Usage of this new control is easy to implement in existing userspace tools like alsaloop from alsa-utils. Signed-off-by: Ruslan Bilovol Signed-off-by: Jerome Brunet Link: https://lore.kernel.org/r/20210603220104.1216001-4-jbrunet@baylibre.com Signed-off-by: Greg Kroah-Hartman --- Documentation/ABI/testing/configfs-usb-gadget-uac2 | 1 + Documentation/usb/gadget-testing.rst | 1 + 2 files changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/configfs-usb-gadget-uac2 b/Documentation/ABI/testing/configfs-usb-gadget-uac2 index e7e59d7fb12f..26fb8e9b4e61 100644 --- a/Documentation/ABI/testing/configfs-usb-gadget-uac2 +++ b/Documentation/ABI/testing/configfs-usb-gadget-uac2 @@ -9,6 +9,7 @@ Description: c_srate capture sampling rate c_ssize capture sample size (bytes) c_sync capture synchronization type (async/adaptive) + fb_max maximum extra bandwidth in async mode p_chmask playback channel mask p_srate playback sampling rate p_ssize playback sample size (bytes) diff --git a/Documentation/usb/gadget-testing.rst b/Documentation/usb/gadget-testing.rst index f5a12667bd41..9d6276f82774 100644 --- a/Documentation/usb/gadget-testing.rst +++ b/Documentation/usb/gadget-testing.rst @@ -729,6 +729,7 @@ The uac2 function provides these attributes in its function directory: c_srate capture sampling rate c_ssize capture sample size (bytes) c_sync capture synchronization type (async/adaptive) + fb_max maximum extra bandwidth in async mode p_chmask playback channel mask p_srate playback sampling rate p_ssize playback sample size (bytes) -- cgit v1.2.3 From 0508c477907b970a53153365e01463805238a052 Mon Sep 17 00:00:00 2001 From: Tom Rix Date: Tue, 8 Jun 2021 14:23:40 -0700 Subject: dt-bindings: fpga: fpga-region: change FPGA indirect article to an Change use of 'a fpga' to 'an fpga' Signed-off-by: Tom Rix Link: https://lore.kernel.org/r/20210608212350.3029742-3-trix@redhat.com Signed-off-by: Greg Kroah-Hartman --- .../devicetree/bindings/fpga/fpga-region.txt | 22 +++++++++++----------- 1 file changed, 11 insertions(+), 11 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/fpga/fpga-region.txt b/Documentation/devicetree/bindings/fpga/fpga-region.txt index d787d57491a1..7d3515264838 100644 --- a/Documentation/devicetree/bindings/fpga/fpga-region.txt +++ b/Documentation/devicetree/bindings/fpga/fpga-region.txt @@ -38,7 +38,7 @@ Partial Reconfiguration (PR) Partial Reconfiguration Region (PRR) * Also called a "reconfigurable partition" - * A PRR is a specific section of a FPGA reserved for reconfiguration. + * A PRR is a specific section of an FPGA reserved for reconfiguration. * A base (or static) FPGA image may create a set of PRR's that later may be independently reprogrammed many times. * The size and specific location of each PRR is fixed. @@ -105,7 +105,7 @@ reprogrammed independently while the rest of the system continues to function. Sequence ======== -When a DT overlay that targets a FPGA Region is applied, the FPGA Region will +When a DT overlay that targets an FPGA Region is applied, the FPGA Region will do the following: 1. Disable appropriate FPGA bridges. @@ -134,8 +134,8 @@ The intended use is that a Device Tree overlay (DTO) can be used to reprogram an FPGA while an operating system is running. An FPGA Region that exists in the live Device Tree reflects the current state. -If the live tree shows a "firmware-name" property or child nodes under a FPGA -Region, the FPGA already has been programmed. A DTO that targets a FPGA Region +If the live tree shows a "firmware-name" property or child nodes under an FPGA +Region, the FPGA already has been programmed. A DTO that targets an FPGA Region and adds the "firmware-name" property is taken as a request to reprogram the FPGA. After reprogramming is successful, the overlay is accepted into the live tree. @@ -152,9 +152,9 @@ These FPGA regions are children of FPGA bridges which are then children of the base FPGA region. The "Full Reconfiguration to add PRR's" example below shows this. -If an FPGA Region does not specify a FPGA Manager, it will inherit the FPGA +If an FPGA Region does not specify an FPGA Manager, it will inherit the FPGA Manager specified by its ancestor FPGA Region. This supports both the case -where the same FPGA Manager is used for all of a FPGA as well the case where +where the same FPGA Manager is used for all of an FPGA as well the case where a different FPGA Manager is used for each region. FPGA Regions do not inherit their ancestor FPGA regions' bridges. This prevents @@ -166,7 +166,7 @@ within the static image of the FPGA. Required properties: - compatible : should contain "fpga-region" - fpga-mgr : should contain a phandle to an FPGA Manager. Child FPGA Regions - inherit this property from their ancestor regions. A fpga-mgr property + inherit this property from their ancestor regions. An fpga-mgr property in a region will override any inherited FPGA manager. - #address-cells, #size-cells, ranges : must be present to handle address space mapping for child nodes. @@ -175,12 +175,12 @@ Optional properties: - firmware-name : should contain the name of an FPGA image file located on the firmware search path. If this property shows up in a live device tree it indicates that the FPGA has already been programmed with this image. - If this property is in an overlay targeting a FPGA region, it is a + If this property is in an overlay targeting an FPGA region, it is a request to program the FPGA with that image. - fpga-bridges : should contain a list of phandles to FPGA Bridges that must be controlled during FPGA programming along with the parent FPGA bridge. This property is optional if the FPGA Manager handles the bridges. - If the fpga-region is the child of a fpga-bridge, the list should not + If the fpga-region is the child of an fpga-bridge, the list should not contain the parent bridge. - partial-fpga-config : boolean, set if partial reconfiguration is to be done, otherwise full reconfiguration is done. @@ -279,7 +279,7 @@ Supported Use Models In all cases the live DT must have the FPGA Manager, FPGA Bridges (if any), and a FPGA Region. The target of the Device Tree Overlay is the FPGA Region. Some -uses are specific to a FPGA device. +uses are specific to an FPGA device. * No FPGA Bridges In this case, the FPGA Manager which programs the FPGA also handles the @@ -300,7 +300,7 @@ uses are specific to a FPGA device. bridges need to exist in the FPGA that can gate the buses going to each FPGA region while the buses are enabled for other sections. Before any partial reconfiguration can be done, a base FPGA image must be loaded which includes - PRR's with FPGA bridges. The device tree should have a FPGA region for each + PRR's with FPGA bridges. The device tree should have an FPGA region for each PRR. Device Tree Examples -- cgit v1.2.3 From f7c2e792c6fe556c68b7771f1596cab978a43f26 Mon Sep 17 00:00:00 2001 From: Tom Rix Date: Tue, 8 Jun 2021 14:23:41 -0700 Subject: Documentation: fpga: dfl: change FPGA indirect article to an Change use of 'a fpga' to 'an fpga' Signed-off-by: Tom Rix Link: https://lore.kernel.org/r/20210608212350.3029742-4-trix@redhat.com Signed-off-by: Greg Kroah-Hartman --- Documentation/fpga/dfl.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/fpga/dfl.rst b/Documentation/fpga/dfl.rst index f3a1223f2517..75df90d1e54c 100644 --- a/Documentation/fpga/dfl.rst +++ b/Documentation/fpga/dfl.rst @@ -57,7 +57,7 @@ FPGA Interface Unit (FIU) represents a standalone functional unit for the interface to FPGA, e.g. the FPGA Management Engine (FME) and Port (more descriptions on FME and Port in later sections). -Accelerated Function Unit (AFU) represents a FPGA programmable region and +Accelerated Function Unit (AFU) represents an FPGA programmable region and always connects to a FIU (e.g. a Port) as its child as illustrated above. Private Features represent sub features of the FIU and AFU. They could be @@ -311,7 +311,7 @@ The driver organization in virtualization case is illustrated below: | PCI PF Device | | | PCI VF Device | +---------------+ | +---------------+ -FPGA PCIe device driver is always loaded first once a FPGA PCIe PF or VF device +FPGA PCIe device driver is always loaded first once an FPGA PCIe PF or VF device is detected. It: * Finishes enumeration on both FPGA PCIe PF and VF device using common -- cgit v1.2.3 From 987b741c52c7c6c68d46fbaeb95b8d1087f10b7f Mon Sep 17 00:00:00 2001 From: Tom Rix Date: Tue, 8 Jun 2021 14:23:42 -0700 Subject: Documentation: ocxl.rst: change FPGA indirect article to an Change use of 'a fpga' to 'an fpga' Signed-off-by: Tom Rix Acked-by: Andrew Donnellan Link: https://lore.kernel.org/r/20210608212350.3029742-5-trix@redhat.com Signed-off-by: Greg Kroah-Hartman --- Documentation/userspace-api/accelerators/ocxl.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/userspace-api/accelerators/ocxl.rst b/Documentation/userspace-api/accelerators/ocxl.rst index 14cefc020e2d..db7570d5e50d 100644 --- a/Documentation/userspace-api/accelerators/ocxl.rst +++ b/Documentation/userspace-api/accelerators/ocxl.rst @@ -6,7 +6,7 @@ OpenCAPI is an interface between processors and accelerators. It aims at being low-latency and high-bandwidth. The specification is developed by the `OpenCAPI Consortium `_. -It allows an accelerator (which could be a FPGA, ASICs, ...) to access +It allows an accelerator (which could be an FPGA, ASICs, ...) to access the host memory coherently, using virtual addresses. An OpenCAPI device can also host its own memory, that can be accessed from the host. -- cgit v1.2.3 From c784e46c8445635afd81bd4089fc5e87271a8f3b Mon Sep 17 00:00:00 2001 From: Ralf Schlatterbeck Date: Wed, 19 May 2021 13:54:51 +0200 Subject: auxdisplay: Add I2C gpio expander example The hd44780 displays are often used with pcf8574 based I/O expanders. Add example to documentation. Suggested-by: Geert Uytterhoeven Signed-off-by: Ralf Schlatterbeck [Added Suggested-by tag] Signed-off-by: Miguel Ojeda --- .../bindings/auxdisplay/hit,hd44780.yaml | 31 +++++++++++++++++++++- 1 file changed, 30 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/auxdisplay/hit,hd44780.yaml b/Documentation/devicetree/bindings/auxdisplay/hit,hd44780.yaml index 9222b06e93a0..fde07e4b119d 100644 --- a/Documentation/devicetree/bindings/auxdisplay/hit,hd44780.yaml +++ b/Documentation/devicetree/bindings/auxdisplay/hit,hd44780.yaml @@ -12,7 +12,10 @@ maintainers: description: The Hitachi HD44780 Character LCD Controller is commonly used on character LCDs that can display one or more lines of text. It exposes an M6800 bus - interface, which can be used in either 4-bit or 8-bit mode. + interface, which can be used in either 4-bit or 8-bit mode. By using a + GPIO expander it is possible to use the driver with one of the popular I2C + expander boards based on the PCF8574 available for these displays. For + an example see below. properties: compatible: @@ -94,3 +97,29 @@ examples: display-height-chars = <2>; display-width-chars = <16>; }; + - | + #include + i2c { + #address-cells = <1>; + #size-cells = <0>; + + pcf8574: pcf8574@27 { + compatible = "nxp,pcf8574"; + reg = <0x27>; + gpio-controller; + #gpio-cells = <2>; + }; + }; + hd44780 { + compatible = "hit,hd44780"; + display-height-chars = <2>; + display-width-chars = <16>; + data-gpios = <&pcf8574 4 0>, + <&pcf8574 5 0>, + <&pcf8574 6 0>, + <&pcf8574 7 0>; + enable-gpios = <&pcf8574 2 0>; + rs-gpios = <&pcf8574 0 0>; + rw-gpios = <&pcf8574 1 0>; + backlight-gpios = <&pcf8574 3 0>; + }; -- cgit v1.2.3 From 769841c966fdb36b41d968d96d3e6fb7f7abd63c Mon Sep 17 00:00:00 2001 From: William Breathitt Gray Date: Wed, 9 Jun 2021 10:31:04 +0900 Subject: docs: counter: Consolidate Counter sysfs attributes documentation Duplicate ABIs are not valid, so let's consolidate these sysfs attributes into the main sysfs-bus-counter documentation file. Cc: Patrick Havelange Reviewed-by: David Lechner Signed-off-by: William Breathitt Gray Link: https://lore.kernel.org/r/c651ec1c541754ad108160839e2b8425ad089819.1623201081.git.vilhelm.gray@gmail.com Signed-off-by: Jonathan Cameron --- Documentation/ABI/testing/sysfs-bus-counter | 76 +++++++++++++++++++++- .../ABI/testing/sysfs-bus-counter-104-quad-8 | 61 ----------------- .../ABI/testing/sysfs-bus-counter-ftm-quaddec | 16 ----- 3 files changed, 74 insertions(+), 79 deletions(-) delete mode 100644 Documentation/ABI/testing/sysfs-bus-counter-104-quad-8 delete mode 100644 Documentation/ABI/testing/sysfs-bus-counter-ftm-quaddec (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-bus-counter b/Documentation/ABI/testing/sysfs-bus-counter index e9d9e50f03be..20fe5afd4f9e 100644 --- a/Documentation/ABI/testing/sysfs-bus-counter +++ b/Documentation/ABI/testing/sysfs-bus-counter @@ -57,6 +57,7 @@ Description: What: /sys/bus/counter/devices/counterX/countY/count_mode_available What: /sys/bus/counter/devices/counterX/countY/error_noise_available What: /sys/bus/counter/devices/counterX/countY/function_available +What: /sys/bus/counter/devices/counterX/countY/prescaler_available What: /sys/bus/counter/devices/counterX/countY/signalZ_action_available KernelVersion: 5.2 Contact: linux-iio@vger.kernel.org @@ -154,6 +155,15 @@ Description: Count Y. If possible, this should match the name of the respective channel as it appears in the device datasheet. +What: /sys/bus/counter/devices/counterX/countY/prescaler +KernelVersion: 5.2 +Contact: linux-iio@vger.kernel.org +Description: + Configure the prescaler value associated with Count Y. + On the FlexTimer, the counter clock source passes through a + prescaler (i.e. a counter). This acts like a clock + divider. + What: /sys/bus/counter/devices/counterX/countY/preset KernelVersion: 5.2 Contact: linux-iio@vger.kernel.org @@ -224,11 +234,45 @@ Description: Read-only attribute that indicates the total number of Signals belonging to the Counter. -What: /sys/bus/counter/devices/counterX/signalY/signal +What: /sys/bus/counter/devices/counterX/signalY/cable_fault +KernelVersion: 5.7 +Contact: linux-iio@vger.kernel.org +Description: + Read-only attribute that indicates whether a differential + encoder cable fault (not connected or loose wires) is detected + for the respective channel of Signal Y. Valid attribute values + are boolean. Detection must first be enabled via the + corresponding cable_fault_enable attribute. + +What: /sys/bus/counter/devices/counterX/signalY/cable_fault_enable +KernelVersion: 5.7 +Contact: linux-iio@vger.kernel.org +Description: + Whether detection of differential encoder cable faults for the + respective channel of Signal Y is enabled. Valid attribute + values are boolean. + +What: /sys/bus/counter/devices/counterX/signalY/filter_clock_prescaler +KernelVersion: 5.7 +Contact: linux-iio@vger.kernel.org +Description: + Filter clock factor for input Signal Y. This prescaler value + affects the inputs of both quadrature pair signals. + +What: /sys/bus/counter/devices/counterX/signalY/index_polarity KernelVersion: 5.2 Contact: linux-iio@vger.kernel.org Description: - Signal data of Signal Y represented as a string. + Active level of index input Signal Y; irrelevant in + non-synchronous load mode. + +What: /sys/bus/counter/devices/counterX/signalY/index_polarity_available +What: /sys/bus/counter/devices/counterX/signalY/synchronous_mode_available +KernelVersion: 5.2 +Contact: linux-iio@vger.kernel.org +Description: + Discrete set of available values for the respective Signal Y + configuration are listed in this file. What: /sys/bus/counter/devices/counterX/signalY/name KernelVersion: 5.2 @@ -237,3 +281,31 @@ Description: Read-only attribute that indicates the device-specific name of Signal Y. If possible, this should match the name of the respective signal as it appears in the device datasheet. + +What: /sys/bus/counter/devices/counterX/signalY/signal +KernelVersion: 5.2 +Contact: linux-iio@vger.kernel.org +Description: + Signal data of Signal Y represented as a string. + +What: /sys/bus/counter/devices/counterX/signalY/synchronous_mode +KernelVersion: 5.2 +Contact: linux-iio@vger.kernel.org +Description: + Configure the counter associated with Signal Y for + non-synchronous or synchronous load mode. Synchronous load mode + cannot be selected in non-quadrature (Pulse-Direction) clock + mode. + + non-synchronous: + A logic low level is the active level at this index + input. The index function (as enabled via preset_enable) + is performed directly on the active level of the index + input. + + synchronous: + Intended for interfacing with encoder Index output in + quadrature clock mode. The active level is configured + via index_polarity. The index function (as enabled via + preset_enable) is performed synchronously with the + quadrature clock on the active level of the index input. diff --git a/Documentation/ABI/testing/sysfs-bus-counter-104-quad-8 b/Documentation/ABI/testing/sysfs-bus-counter-104-quad-8 deleted file mode 100644 index eac32180c40d..000000000000 --- a/Documentation/ABI/testing/sysfs-bus-counter-104-quad-8 +++ /dev/null @@ -1,61 +0,0 @@ -What: /sys/bus/counter/devices/counterX/signalY/cable_fault -KernelVersion: 5.7 -Contact: linux-iio@vger.kernel.org -Description: - Read-only attribute that indicates whether a differential - encoder cable fault (not connected or loose wires) is detected - for the respective channel of Signal Y. Valid attribute values - are boolean. Detection must first be enabled via the - corresponding cable_fault_enable attribute. - -What: /sys/bus/counter/devices/counterX/signalY/cable_fault_enable -KernelVersion: 5.7 -Contact: linux-iio@vger.kernel.org -Description: - Whether detection of differential encoder cable faults for the - respective channel of Signal Y is enabled. Valid attribute - values are boolean. - -What: /sys/bus/counter/devices/counterX/signalY/filter_clock_prescaler -KernelVersion: 5.7 -Contact: linux-iio@vger.kernel.org -Description: - Filter clock factor for input Signal Y. This prescaler value - affects the inputs of both quadrature pair signals. - -What: /sys/bus/counter/devices/counterX/signalY/index_polarity -KernelVersion: 5.2 -Contact: linux-iio@vger.kernel.org -Description: - Active level of index input Signal Y; irrelevant in - non-synchronous load mode. - -What: /sys/bus/counter/devices/counterX/signalY/index_polarity_available -What: /sys/bus/counter/devices/counterX/signalY/synchronous_mode_available -KernelVersion: 5.2 -Contact: linux-iio@vger.kernel.org -Description: - Discrete set of available values for the respective Signal Y - configuration are listed in this file. - -What: /sys/bus/counter/devices/counterX/signalY/synchronous_mode -KernelVersion: 5.2 -Contact: linux-iio@vger.kernel.org -Description: - Configure the counter associated with Signal Y for - non-synchronous or synchronous load mode. Synchronous load mode - cannot be selected in non-quadrature (Pulse-Direction) clock - mode. - - non-synchronous: - A logic low level is the active level at this index - input. The index function (as enabled via preset_enable) - is performed directly on the active level of the index - input. - - synchronous: - Intended for interfacing with encoder Index output in - quadrature clock mode. The active level is configured - via index_polarity. The index function (as enabled via - preset_enable) is performed synchronously with the - quadrature clock on the active level of the index input. diff --git a/Documentation/ABI/testing/sysfs-bus-counter-ftm-quaddec b/Documentation/ABI/testing/sysfs-bus-counter-ftm-quaddec deleted file mode 100644 index 7d2e7b363467..000000000000 --- a/Documentation/ABI/testing/sysfs-bus-counter-ftm-quaddec +++ /dev/null @@ -1,16 +0,0 @@ -What: /sys/bus/counter/devices/counterX/countY/prescaler_available -KernelVersion: 5.2 -Contact: linux-iio@vger.kernel.org -Description: - Discrete set of available values for the respective Count Y - configuration are listed in this file. Values are delimited by - newline characters. - -What: /sys/bus/counter/devices/counterX/countY/prescaler -KernelVersion: 5.2 -Contact: linux-iio@vger.kernel.org -Description: - Configure the prescaler value associated with Count Y. - On the FlexTimer, the counter clock source passes through a - prescaler (i.e. a counter). This acts like a clock - divider. -- cgit v1.2.3 From c316424d9921b36b671a1bcc160e24a1fe9978c0 Mon Sep 17 00:00:00 2001 From: William Breathitt Gray Date: Wed, 9 Jun 2021 10:31:05 +0900 Subject: docs: counter: Fix spelling "Miscellaneous" is the correct spelling. Reviewed-by: David Lechner Signed-off-by: William Breathitt Gray Link: https://lore.kernel.org/r/880c2fd0e2e91b8962c9d388b37ba582d548db8e.1623201081.git.vilhelm.gray@gmail.com Signed-off-by: Jonathan Cameron --- Documentation/driver-api/generic-counter.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/driver-api/generic-counter.rst b/Documentation/driver-api/generic-counter.rst index b02c52cd69d6..64fe7db080e5 100644 --- a/Documentation/driver-api/generic-counter.rst +++ b/Documentation/driver-api/generic-counter.rst @@ -307,7 +307,7 @@ Determining the type of extension to create is a matter of scope. * Device extensions are attributes that expose information/control non-specific to a particular Count or Signal. This is where you would - put your global features or other miscellanous functionality. + put your global features or other miscellaneous functionality. For example, if your device has an overtemp sensor, you can report the chip overheated via a device extension called "error_overtemp": -- cgit v1.2.3 From 63f8e9e0ac655fb31f4e69aebd80acbafa2056ab Mon Sep 17 00:00:00 2001 From: Rob Herring Date: Mon, 7 Jun 2021 14:35:00 -0500 Subject: dt-bindings: mtd: Convert mtd-physmap to DT schema Convert the mtd-physmap binding to DT schema format. The arm-versatile, cypress,hyperflash and intel,ixp4xx-flash are all just an additional compatible string, so they are all merged into the main schema. There doesn't appear to be any users nor support for 'vendor-id' and 'device-id', so these have been dropped. Cc: Linus Walleij Cc: Miquel Raynal Cc: Richard Weinberger Cc: Vignesh Raghavendra Cc: linux-mtd@lists.infradead.org Signed-off-by: Rob Herring Reviewed-by: Linus Walleij Reviewed-by: Miquel Raynal Link: https://lore.kernel.org/r/20210607193500.3085920-1-robh@kernel.org --- .../devicetree/bindings/mtd/arm-versatile.txt | 26 --- .../bindings/mtd/cortina,gemini-flash.txt | 2 +- .../devicetree/bindings/mtd/cypress,hyperflash.txt | 13 -- .../devicetree/bindings/mtd/intel,ixp4xx-flash.txt | 22 --- .../devicetree/bindings/mtd/mtd-physmap.txt | 114 ----------- .../devicetree/bindings/mtd/mtd-physmap.yaml | 208 +++++++++++++++++++++ 6 files changed, 209 insertions(+), 176 deletions(-) delete mode 100644 Documentation/devicetree/bindings/mtd/arm-versatile.txt delete mode 100644 Documentation/devicetree/bindings/mtd/cypress,hyperflash.txt delete mode 100644 Documentation/devicetree/bindings/mtd/intel,ixp4xx-flash.txt delete mode 100644 Documentation/devicetree/bindings/mtd/mtd-physmap.txt create mode 100644 Documentation/devicetree/bindings/mtd/mtd-physmap.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mtd/arm-versatile.txt b/Documentation/devicetree/bindings/mtd/arm-versatile.txt deleted file mode 100644 index 4ec28796a3c0..000000000000 --- a/Documentation/devicetree/bindings/mtd/arm-versatile.txt +++ /dev/null @@ -1,26 +0,0 @@ -Flash device on ARM Versatile board - -These flash chips are found in the ARM reference designs like Integrator, -Versatile, RealView, Versatile Express etc. - -They are regular CFI compatible (Intel or AMD extended) flash chips with -some special write protect/VPP bits that can be controlled by the machine's -system controller. - -Required properties: -- compatible : must be "arm,versatile-flash", "cfi-flash"; -- reg : memory address for the flash chip -- bank-width : width in bytes of flash interface. - -For the rest of the properties, see mtd-physmap.txt. - -The device tree may optionally contain sub-nodes describing partitions of the -address space. See partition.txt for more detail. - -Example: - -flash@34000000 { - compatible = "arm,versatile-flash", "cfi-flash"; - reg = <0x34000000 0x4000000>; - bank-width = <4>; -}; diff --git a/Documentation/devicetree/bindings/mtd/cortina,gemini-flash.txt b/Documentation/devicetree/bindings/mtd/cortina,gemini-flash.txt index 3fa1b34d69ad..efa5b2aba829 100644 --- a/Documentation/devicetree/bindings/mtd/cortina,gemini-flash.txt +++ b/Documentation/devicetree/bindings/mtd/cortina,gemini-flash.txt @@ -9,7 +9,7 @@ Required properties: - syscon : must be a phandle to the system controller - bank-width : width in bytes of flash interface, should be <2> -For the rest of the properties, see mtd-physmap.txt. +For the rest of the properties, see mtd-physmap.yaml. The device tree may optionally contain sub-nodes describing partitions of the address space. See partition.txt for more detail. diff --git a/Documentation/devicetree/bindings/mtd/cypress,hyperflash.txt b/Documentation/devicetree/bindings/mtd/cypress,hyperflash.txt deleted file mode 100644 index ad42f4db32f1..000000000000 --- a/Documentation/devicetree/bindings/mtd/cypress,hyperflash.txt +++ /dev/null @@ -1,13 +0,0 @@ -Bindings for HyperFlash NOR flash chips compliant with Cypress HyperBus -specification and supports Cypress CFI specification 1.5 command set. - -Required properties: -- compatible : "cypress,hyperflash", "cfi-flash" for HyperFlash NOR chips -- reg : Address of flash's memory map - -Example: - - flash@0 { - compatible = "cypress,hyperflash", "cfi-flash"; - reg = <0x0 0x4000000>; - }; diff --git a/Documentation/devicetree/bindings/mtd/intel,ixp4xx-flash.txt b/Documentation/devicetree/bindings/mtd/intel,ixp4xx-flash.txt deleted file mode 100644 index 4bdcb92ae381..000000000000 --- a/Documentation/devicetree/bindings/mtd/intel,ixp4xx-flash.txt +++ /dev/null @@ -1,22 +0,0 @@ -Flash device on Intel IXP4xx SoC - -This flash is regular CFI compatible (Intel or AMD extended) flash chips with -specific big-endian or mixed-endian memory access pattern. - -Required properties: -- compatible : must be "intel,ixp4xx-flash", "cfi-flash"; -- reg : memory address for the flash chip -- bank-width : width in bytes of flash interface, should be <2> - -For the rest of the properties, see mtd-physmap.txt. - -The device tree may optionally contain sub-nodes describing partitions of the -address space. See partition.txt for more detail. - -Example: - -flash@50000000 { - compatible = "intel,ixp4xx-flash", "cfi-flash"; - reg = <0x50000000 0x01000000>; - bank-width = <2>; -}; diff --git a/Documentation/devicetree/bindings/mtd/mtd-physmap.txt b/Documentation/devicetree/bindings/mtd/mtd-physmap.txt deleted file mode 100644 index c69f4f065d23..000000000000 --- a/Documentation/devicetree/bindings/mtd/mtd-physmap.txt +++ /dev/null @@ -1,114 +0,0 @@ -CFI or JEDEC memory-mapped NOR flash, MTD-RAM (NVRAM...) - -Flash chips (Memory Technology Devices) are often used for solid state -file systems on embedded devices. - - - compatible : should contain the specific model of mtd chip(s) - used, if known, followed by either "cfi-flash", "jedec-flash", - "mtd-ram" or "mtd-rom". - - reg : Address range(s) of the mtd chip(s) - It's possible to (optionally) define multiple "reg" tuples so that - non-identical chips can be described in one node. - - bank-width : Width (in bytes) of the bank. Equal to the - device width times the number of interleaved chips. - - device-width : (optional) Width of a single mtd chip. If - omitted, assumed to be equal to 'bank-width'. - - #address-cells, #size-cells : Must be present if the device has - sub-nodes representing partitions (see below). In this case - both #address-cells and #size-cells must be equal to 1. - - no-unaligned-direct-access: boolean to disable the default direct - mapping of the flash. - On some platforms (e.g. MPC5200) a direct 1:1 mapping may cause - problems with JFFS2 usage, as the local bus (LPB) doesn't support - unaligned accesses as implemented in the JFFS2 code via memcpy(). - By defining "no-unaligned-direct-access", the flash will not be - exposed directly to the MTD users (e.g. JFFS2) any more. - - linux,mtd-name: allow to specify the mtd name for retro capability with - physmap-flash drivers as boot loader pass the mtd partition via the old - device name physmap-flash. - - use-advanced-sector-protection: boolean to enable support for the - advanced sector protection (Spansion: PPB - Persistent Protection - Bits) locking. - - addr-gpios : (optional) List of GPIO descriptors that will be used to - address the MSBs address lines. The order goes from LSB to MSB. - -For JEDEC compatible devices, the following additional properties -are defined: - - - vendor-id : Contains the flash chip's vendor id (1 byte). - - device-id : Contains the flash chip's device id (1 byte). - -For ROM compatible devices (and ROM fallback from cfi-flash), the following -additional (optional) property is defined: - - - erase-size : The chip's physical erase block size in bytes. - - The device tree may optionally contain endianness property. - little-endian or big-endian : It Represents the endianness that should be used - by the controller to properly read/write data - from/to the flash. If this property is missing, - the endianness is chosen by the system - (potentially based on extra configuration options). - -The device tree may optionally contain sub-nodes describing partitions of the -address space. See partition.txt for more detail. - -Example: - - flash@ff000000 { - compatible = "amd,am29lv128ml", "cfi-flash"; - reg = ; - bank-width = <4>; - device-width = <1>; - #address-cells = <1>; - #size-cells = <1>; - fs@0 { - label = "fs"; - reg = <0 f80000>; - }; - firmware@f80000 { - label ="firmware"; - reg = ; - read-only; - }; - }; - -Here an example with multiple "reg" tuples: - - flash@f0000000,0 { - #address-cells = <1>; - #size-cells = <1>; - compatible = "intel,PC48F4400P0VB", "cfi-flash"; - reg = <0 0x00000000 0x02000000 - 0 0x02000000 0x02000000>; - bank-width = <2>; - partition@0 { - label = "test-part1"; - reg = <0 0x04000000>; - }; - }; - -An example using SRAM: - - sram@2,0 { - compatible = "samsung,k6f1616u6a", "mtd-ram"; - reg = <2 0 0x00200000>; - bank-width = <2>; - }; - -An example using gpio-addrs - - flash@20000000 { - #address-cells = <1>; - #size-cells = <1>; - compatible = "cfi-flash", "jedec-flash"; - reg = <0x20000000 0x02000000>; - ranges = <0 0x00000000 0x02000000 - 1 0x02000000 0x02000000>; - bank-width = <2>; - addr-gpios = <&gpio1 2 GPIO_ACTIVE_HIGH>; - partition@0 { - label = "test-part1"; - reg = <0 0x04000000>; - }; - }; diff --git a/Documentation/devicetree/bindings/mtd/mtd-physmap.yaml b/Documentation/devicetree/bindings/mtd/mtd-physmap.yaml new file mode 100644 index 000000000000..13c29cc91b59 --- /dev/null +++ b/Documentation/devicetree/bindings/mtd/mtd-physmap.yaml @@ -0,0 +1,208 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mtd/mtd-physmap.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: CFI or JEDEC memory-mapped NOR flash, MTD-RAM (NVRAM...) + +maintainers: + - Rob Herring + +description: | + Flash chips (Memory Technology Devices) are often used for solid state + file systems on embedded devices. + +properties: + compatible: + oneOf: + - items: + - enum: + - amd,s29gl01gp + - amd,s29gl032a + - amd,s29gl256n + - amd,s29gl512n + - arm,versatile-flash + - cortina,gemini-flash + - cypress,hyperflash + - ge,imp3a-firmware-mirror + - ge,imp3a-paged-flash + - gef,ppc9a-firmware-mirror + - gef,ppc9a-paged-flash + - gef,sbc310-firmware-mirror + - gef,sbc310-paged-flash + - gef,sbc610-firmware-mirror + - gef,sbc610-paged-flash + - intel,28f128j3 + - intel,dt28f160 + - intel,ixp4xx-flash + - intel,JS28F128 + - intel,JS28F640 + - intel,PC28F640P30T85 + - numonyx,js28f00a + - numonyx,js28f128 + - sst,sst39vf320 + - xlnx,xps-mch-emc-2.00.a + - const: cfi-flash + - items: + - enum: + - cypress,cy7c1019dv33-10zsxi + - arm,vexpress-psram + - const: mtd-ram + - enum: + - cfi-flash + - jedec-flash + - mtd-ram + - mtd-rom + + reg: + description: | + It's possible to (optionally) define multiple "reg" tuples so that + non-identical chips can be described in one node. + minItems: 1 + maxItems: 8 + + bank-width: + description: Width (in bytes) of the bank. Equal to the device width times + the number of interleaved chips. + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [ 1, 2, 4 ] + + device-width: + description: + Width of a single mtd chip. If omitted, assumed to be equal to 'bank-width'. + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [ 1, 2 ] + + no-unaligned-direct-access: + type: boolean + description: | + Disables the default direct mapping of the flash. + + On some platforms (e.g. MPC5200) a direct 1:1 mapping may cause problems + with JFFS2 usage, as the local bus (LPB) doesn't support unaligned + accesses as implemented in the JFFS2 code via memcpy(). By defining + "no-unaligned-direct-access", the flash will not be exposed directly to + the MTD users (e.g. JFFS2) any more. + + linux,mtd-name: + description: + Allows specifying the mtd name for retro capability with physmap-flash + drivers as boot loader pass the mtd partition via the old device name + physmap-flash. + $ref: /schemas/types.yaml#/definitions/string + + use-advanced-sector-protection: + type: boolean + description: | + Enables support for the advanced sector protection (Spansion: PPB - + Persistent Protection Bits) locking. + + erase-size: + description: The chip's physical erase block size in bytes. + $ref: /schemas/types.yaml#/definitions/uint32 + + addr-gpios: + description: + List of GPIO descriptors that will be used to address the MSBs address + lines. The order goes from LSB to MSB. + minItems: 1 + maxItems: 8 + + '#address-cells': + const: 1 + + '#size-cells': + const: 1 + + big-endian: true + little-endian: true + +patternProperties: + '@[0-9a-f]+$': + $ref: partitions/partition.yaml + +required: + - compatible + - reg + +# FIXME: A parent bus may define timing properties +additionalProperties: true + +examples: + - | + + flash@ff000000 { + compatible = "cfi-flash"; + reg = <0xff000000 0x01000000>; + bank-width = <4>; + device-width = <1>; + + #address-cells = <1>; + #size-cells = <1>; + ranges = <0 0xff000000 0x01000000>; + + fs@0 { + label = "fs"; + reg = <0 0xf80000>; + }; + firmware@f80000 { + label ="firmware"; + reg = <0xf80000 0x80000>; + read-only; + }; + }; + + - | + /* An example with multiple "reg" tuples */ + + flash@0 { + compatible = "intel,PC28F640P30T85", "cfi-flash"; + reg = <0x00000000 0x02000000>, + <0x02000000 0x02000000>; + bank-width = <2>; + + #address-cells = <1>; + #size-cells = <1>; + ranges = <0 0 0x04000000>; + + partition@0 { + label = "test-part1"; + reg = <0 0x04000000>; + }; + }; + + - | + /* An example using SRAM */ + bus { + #address-cells = <2>; + #size-cells = <1>; + + sram@2,0 { + compatible = "mtd-ram"; + reg = <2 0 0x00200000>; + bank-width = <2>; + }; + }; + + - | + /* An example using addr-gpios */ + #include + + flash@20000000 { + compatible = "cfi-flash"; + reg = <0x20000000 0x02000000>; + bank-width = <2>; + addr-gpios = <&gpio1 2 GPIO_ACTIVE_HIGH>; + + #address-cells = <1>; + #size-cells = <1>; + ranges = <0 0x00000000 0x02000000>, + <1 0x02000000 0x02000000>; + + partition@0 { + label = "test-part1"; + reg = <0 0x04000000>; + }; + }; +... -- cgit v1.2.3 From 000fe96707b4cbffadc884ca750c525f0839695e Mon Sep 17 00:00:00 2001 From: Rob Herring Date: Mon, 7 Jun 2021 14:40:22 -0500 Subject: dt-bindings: watchdog: Convert arm,sbsa-gwdt to DT schema Convert the arm,sbsa-gwdt binding to DT schema format. Cc: Wim Van Sebroeck Cc: Guenter Roeck Cc: Fu Wei Cc: linux-watchdog@vger.kernel.org Signed-off-by: Rob Herring Acked-by: Guenter Roeck Link: https://lore.kernel.org/r/20210607194022.3095736-1-robh@kernel.org --- .../bindings/watchdog/arm,sbsa-gwdt.yaml | 51 ++++++++++++++++++++++ .../devicetree/bindings/watchdog/sbsa-gwdt.txt | 31 ------------- 2 files changed, 51 insertions(+), 31 deletions(-) create mode 100644 Documentation/devicetree/bindings/watchdog/arm,sbsa-gwdt.yaml delete mode 100644 Documentation/devicetree/bindings/watchdog/sbsa-gwdt.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/watchdog/arm,sbsa-gwdt.yaml b/Documentation/devicetree/bindings/watchdog/arm,sbsa-gwdt.yaml new file mode 100644 index 000000000000..6bfa46353c4e --- /dev/null +++ b/Documentation/devicetree/bindings/watchdog/arm,sbsa-gwdt.yaml @@ -0,0 +1,51 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/watchdog/arm,sbsa-gwdt.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: SBSA (Server Base System Architecture) Generic Watchdog + +maintainers: + - Fu Wei + +description: | + The SBSA Generic Watchdog Timer is used to force a reset of the system after + two stages of timeout have elapsed. A detailed definition of the watchdog + timer can be found in the ARM document: ARM-DEN-0029 - Server Base System + Architecture (SBSA) + +allOf: + - $ref: watchdog.yaml# + +properties: + compatible: + const: arm,sbsa-gwdt + + reg: + items: + - description: Watchdog control frame + - description: Refresh frame + + interrupts: + description: The Watchdog Signal 0 (WS0) SPI (Shared Peripheral Interrupt) + maxItems: 1 + +required: + - compatible + - reg + - interrupts + +unevaluatedProperties: false + +examples: + - | + + watchdog@2a440000 { + compatible = "arm,sbsa-gwdt"; + reg = <0x2a440000 0x1000>, + <0x2a450000 0x1000>; + interrupts = <0 27 4>; + timeout-sec = <30>; + }; +... diff --git a/Documentation/devicetree/bindings/watchdog/sbsa-gwdt.txt b/Documentation/devicetree/bindings/watchdog/sbsa-gwdt.txt deleted file mode 100644 index 6f2d5f91964d..000000000000 --- a/Documentation/devicetree/bindings/watchdog/sbsa-gwdt.txt +++ /dev/null @@ -1,31 +0,0 @@ -* SBSA (Server Base System Architecture) Generic Watchdog - -The SBSA Generic Watchdog Timer is used to force a reset of the system -after two stages of timeout have elapsed. A detailed definition of the -watchdog timer can be found in the ARM document: ARM-DEN-0029 - Server -Base System Architecture (SBSA) - -Required properties: -- compatible: Should at least contain "arm,sbsa-gwdt". - -- reg: Each entry specifies the base physical address of a register frame - and the length of that frame; currently, two frames must be defined, - in this order: - 1: Watchdog control frame; - 2: Refresh frame. - -- interrupts: Should contain the Watchdog Signal 0 (WS0) SPI (Shared - Peripheral Interrupt) number of SBSA Generic Watchdog. - -Optional properties -- timeout-sec: Watchdog timeout values (in seconds). - -Example for FVP Foundation Model v8: - -watchdog@2a440000 { - compatible = "arm,sbsa-gwdt"; - reg = <0x0 0x2a440000 0 0x1000>, - <0x0 0x2a450000 0 0x1000>; - interrupts = <0 27 4>; - timeout-sec = <30>; -}; -- cgit v1.2.3 From 4812be97c015bddf12c70155858df43acc35a4eb Mon Sep 17 00:00:00 2001 From: Dan Williams Date: Wed, 9 Jun 2021 09:01:35 -0700 Subject: cxl/acpi: Introduce the root of a cxl_port topology While CXL builds upon the PCI software model for enumeration and endpoint control, a static platform component is required to bootstrap the CXL memory layout. Similar to how ACPI identifies root-level PCI memory resources, ACPI data enumerates the address space and interleave configuration for CXL Memory. In addition to identifying host bridges, ACPI is responsible for enumerating the CXL memory space that can be addressed by downstream decoders. This is similar to the requirement for ACPI to publish resources via the _CRS method for PCI host bridges. Specifically, ACPI publishes a table, CXL Early Discovery Table (CEDT), which includes a list of CXL Memory resources, CXL Fixed Memory Window Structures (CFMWS). For now, introduce the core infrastructure for a cxl_port hierarchy starting with a root level anchor represented by the ACPI0017 device. Follow on changes model support for the configurable decode capabilities of cxl_port instances, i.e. CXL switch support. Co-developed-by: Alison Schofield Signed-off-by: Alison Schofield Acked-by: Rafael J. Wysocki Reviewed-by: Jonathan Cameron Link: https://lore.kernel.org/r/162325449515.2293126.15303270193010154608.stgit@dwillia2-desk3.amr.corp.intel.com Signed-off-by: Dan Williams --- Documentation/ABI/testing/sysfs-bus-cxl | 20 ++++++++++++++++++++ Documentation/driver-api/cxl/memory-devices.rst | 6 ++++++ 2 files changed, 26 insertions(+) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-bus-cxl b/Documentation/ABI/testing/sysfs-bus-cxl index 2fe7490ad6a8..bda2cc55cc38 100644 --- a/Documentation/ABI/testing/sysfs-bus-cxl +++ b/Documentation/ABI/testing/sysfs-bus-cxl @@ -24,3 +24,23 @@ Description: (RO) "Persistent Only Capacity" as bytes. Represents the identically named field in the Identify Memory Device Output Payload in the CXL-2.0 specification. + +What: /sys/bus/cxl/devices/*/devtype +Date: June, 2021 +KernelVersion: v5.14 +Contact: linux-cxl@vger.kernel.org +Description: + CXL device objects export the devtype attribute which mirrors + the same value communicated in the DEVTYPE environment variable + for uevents for devices on the "cxl" bus. + +What: /sys/bus/cxl/devices/portX/uport +Date: June, 2021 +KernelVersion: v5.14 +Contact: linux-cxl@vger.kernel.org +Description: + CXL port objects are enumerated from either a platform firmware + device (ACPI0017 and ACPI0016) or PCIe switch upstream port with + CXL component registers. The 'uport' symlink connects the CXL + portX object to the device that published the CXL port + capability. diff --git a/Documentation/driver-api/cxl/memory-devices.rst b/Documentation/driver-api/cxl/memory-devices.rst index 44c8ddbc8415..487ce4f41d77 100644 --- a/Documentation/driver-api/cxl/memory-devices.rst +++ b/Documentation/driver-api/cxl/memory-devices.rst @@ -30,6 +30,12 @@ CXL Memory Device CXL Core -------- +.. kernel-doc:: drivers/cxl/cxl.h + :doc: cxl objects + +.. kernel-doc:: drivers/cxl/cxl.h + :internal: + .. kernel-doc:: drivers/cxl/core.c :doc: cxl core -- cgit v1.2.3 From 7d4b5ca2e2cb5d28db628ec79c706bcfa832feea Mon Sep 17 00:00:00 2001 From: Dan Williams Date: Wed, 9 Jun 2021 09:01:46 -0700 Subject: cxl/acpi: Add downstream port data to cxl_port instances In preparation for infrastructure that enumerates and configures the CXL decode mechanism of an upstream port to its downstream ports, add a representation of a CXL downstream port. On ACPI systems the top-most logical downstream ports in the hierarchy are the host bridges (ACPI0016 devices) that decode the memory windows described by the CXL Early Discovery Table Fixed Memory Window Structures (CEDT.CFMWS). Reviewed-by: Alison Schofield Link: https://lore.kernel.org/r/162325450624.2293126.3533006409920271718.stgit@dwillia2-desk3.amr.corp.intel.com Signed-off-by: Dan Williams --- Documentation/ABI/testing/sysfs-bus-cxl | 13 +++++++++++++ 1 file changed, 13 insertions(+) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-bus-cxl b/Documentation/ABI/testing/sysfs-bus-cxl index bda2cc55cc38..f680da85fd44 100644 --- a/Documentation/ABI/testing/sysfs-bus-cxl +++ b/Documentation/ABI/testing/sysfs-bus-cxl @@ -44,3 +44,16 @@ Description: CXL component registers. The 'uport' symlink connects the CXL portX object to the device that published the CXL port capability. + +What: /sys/bus/cxl/devices/portX/dportY +Date: June, 2021 +KernelVersion: v5.14 +Contact: linux-cxl@vger.kernel.org +Description: + CXL port objects are enumerated from either a platform firmware + device (ACPI0017 and ACPI0016) or PCIe switch upstream port with + CXL component registers. The 'dportY' symlink identifies one or + more downstream ports that the upstream port may target in its + decode of CXL memory resources. The 'Y' integer reflects the + hardware port unique-id used in the hardware decoder target + list. -- cgit v1.2.3 From 40ba17afdfabb01688c61565dbe02a916241bc05 Mon Sep 17 00:00:00 2001 From: Dan Williams Date: Wed, 9 Jun 2021 09:43:29 -0700 Subject: cxl/acpi: Introduce cxl_decoder objects MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit A cxl_decoder is a child of a cxl_port. It represents a hardware decoder configuration of an upstream port to one or more of its downstream ports. The decoder is either represented in CXL standard HDM decoder registers (see CXL 2.0 section 8.2.5.12 CXL HDM Decoder Capability Structure), or it is a static decode configuration communicated by platform firmware (see the CXL Early Discovery Table: Fixed Memory Window Structure). The firmware described and hardware described decoders differ slightly leading to 2 different sub-types of decoders, cxl_decoder_root and cxl_decoder_switch. At the root level the decode capabilities restrict what can be mapped beneath them. Mid-level switch decoders are configured for either acclerator (type-2) or memory-expander (type-3) operation, but they are otherwise agnostic to the type of memory (volatile vs persistent) being mapped. Here is an example topology from a single-ported host-bridge environment without CFMWS decodes enumerated. /sys/bus/cxl/devices/root0 ├── devtype ├── dport0 -> ../../../LNXSYSTM:00/LNXSYBUS:00/ACPI0016:00 ├── port1 │   ├── decoder1.0 │   │   ├── devtype │   │   ├── locked │   │   ├── size │   │   ├── start │   │   ├── subsystem -> ../../../../../../bus/cxl │   │   ├── target_list │   │   ├── target_type │   │   └── uevent │   ├── devtype │   ├── dport0 -> ../../../../pci0000:34/0000:34:00.0 │   ├── subsystem -> ../../../../../bus/cxl │   ├── uevent │   └── uport -> ../../../../LNXSYSTM:00/LNXSYBUS:00/ACPI0016:00 ├── subsystem -> ../../../../bus/cxl ├── uevent └── uport -> ../../ACPI0017:00 Reviewed-by: Jonathan Cameron Link: https://lore.kernel.org/r/162325695128.2293823.17519927266014762694.stgit@dwillia2-desk3.amr.corp.intel.com Signed-off-by: Dan Williams --- Documentation/ABI/testing/sysfs-bus-cxl | 70 +++++++++++++++++++++++++++++++++ 1 file changed, 70 insertions(+) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-bus-cxl b/Documentation/ABI/testing/sysfs-bus-cxl index f680da85fd44..0b6a2e6e8fbb 100644 --- a/Documentation/ABI/testing/sysfs-bus-cxl +++ b/Documentation/ABI/testing/sysfs-bus-cxl @@ -57,3 +57,73 @@ Description: decode of CXL memory resources. The 'Y' integer reflects the hardware port unique-id used in the hardware decoder target list. + +What: /sys/bus/cxl/devices/decoderX.Y +Date: June, 2021 +KernelVersion: v5.14 +Contact: linux-cxl@vger.kernel.org +Description: + CXL decoder objects are enumerated from either a platform + firmware description, or a CXL HDM decoder register set in a + PCIe device (see CXL 2.0 section 8.2.5.12 CXL HDM Decoder + Capability Structure). The 'X' in decoderX.Y represents the + cxl_port container of this decoder, and 'Y' represents the + instance id of a given decoder resource. + +What: /sys/bus/cxl/devices/decoderX.Y/{start,size} +Date: June, 2021 +KernelVersion: v5.14 +Contact: linux-cxl@vger.kernel.org +Description: + The 'start' and 'size' attributes together convey the physical + address base and number of bytes mapped in the decoder's decode + window. For decoders of devtype "cxl_decoder_root" the address + range is fixed. For decoders of devtype "cxl_decoder_switch" the + address is bounded by the decode range of the cxl_port ancestor + of the decoder's cxl_port, and dynamically updates based on the + active memory regions in that address space. + +What: /sys/bus/cxl/devices/decoderX.Y/locked +Date: June, 2021 +KernelVersion: v5.14 +Contact: linux-cxl@vger.kernel.org +Description: + CXL HDM decoders have the capability to lock the configuration + until the next device reset. For decoders of devtype + "cxl_decoder_root" there is no standard facility to unlock them. + For decoders of devtype "cxl_decoder_switch" a secondary bus + reset, of the PCIe bridge that provides the bus for this + decoders uport, unlocks / resets the decoder. + +What: /sys/bus/cxl/devices/decoderX.Y/target_list +Date: June, 2021 +KernelVersion: v5.14 +Contact: linux-cxl@vger.kernel.org +Description: + Display a comma separated list of the current decoder target + configuration. The list is ordered by the current configured + interleave order of the decoder's dport instances. Each entry in + the list is a dport id. + +What: /sys/bus/cxl/devices/decoderX.Y/cap_{pmem,ram,type2,type3} +Date: June, 2021 +KernelVersion: v5.14 +Contact: linux-cxl@vger.kernel.org +Description: + When a CXL decoder is of devtype "cxl_decoder_root", it + represents a fixed memory window identified by platform + firmware. A fixed window may only support a subset of memory + types. The 'cap_*' attributes indicate whether persistent + memory, volatile memory, accelerator memory, and / or expander + memory may be mapped behind this decoder's memory window. + +What: /sys/bus/cxl/devices/decoderX.Y/target_type +Date: June, 2021 +KernelVersion: v5.14 +Contact: linux-cxl@vger.kernel.org +Description: + When a CXL decoder is of devtype "cxl_decoder_switch", it can + optionally decode either accelerator memory (type-2) or expander + memory (type-3). The 'target_type' attribute indicates the + current setting which may dynamically change based on what + memory regions are activated in this decode hierarchy. -- cgit v1.2.3 From 7cd6a54a828558c02ee2117eeba43593de54c448 Mon Sep 17 00:00:00 2001 From: Vlad Buslov Date: Mon, 7 Jun 2021 17:42:49 +0300 Subject: net/mlx5: Bridge, handle FDB events Hardware supported by mlx5 driver doesn't provide learning and requires the driver to emulate all switch-like behavior in software. As such, all packets by default go through miss path, appear on representor and get to software bridge, if it is the upper device of the representor. This causes bridge to process packet in software, learn the MAC address to FDB and send SWITCHDEV_FDB_ADD_TO_DEVICE event to all subscribers. In order to offload FDB entries in mlx5, register switchdev notifier callback and implement support for both 'added_by_user' and dynamic FDB entry SWITCHDEV_FDB_ADD_TO_DEVICE events asynchronously using new mlx5_esw_bridge_offloads->wq ordered workqueue. In workqueue callback offload the ingress rule (matching FDB entry MAC as packet source MAC) and egress table rule (matching FDB entry MAC as destination MAC). For ingress table rule also match source vport to ensure that only traffic coming from expected bridge port is matched by offloaded rule. Save all the relevant FDB entry data in struct mlx5_esw_bridge_fdb_entry instance and insert the instance in new mlx5_esw_bridge->fdb_list list (for traversing all entries by software ageing implementation in following patch) and in new mlx5_esw_bridge->fdb_ht hash table for fast retrieval. Notify the bridge that FDB entry has been offloaded by sending SWITCHDEV_FDB_OFFLOADED notification. Delete FDB entry on reception of SWITCHDEV_FDB_DEL_TO_DEVICE event. Signed-off-by: Vlad Buslov Reviewed-by: Jianbo Liu Signed-off-by: Saeed Mahameed --- .../networking/device_drivers/ethernet/mellanox/mlx5.rst | 15 +++++++++++++++ 1 file changed, 15 insertions(+) (limited to 'Documentation') diff --git a/Documentation/networking/device_drivers/ethernet/mellanox/mlx5.rst b/Documentation/networking/device_drivers/ethernet/mellanox/mlx5.rst index 936a10f1942c..ea32136b30e7 100644 --- a/Documentation/networking/device_drivers/ethernet/mellanox/mlx5.rst +++ b/Documentation/networking/device_drivers/ethernet/mellanox/mlx5.rst @@ -12,6 +12,7 @@ Contents - `Enabling the driver and kconfig options`_ - `Devlink info`_ - `Devlink parameters`_ +- `Bridge offload`_ - `mlx5 subfunction`_ - `mlx5 function attributes`_ - `Devlink health reporters`_ @@ -217,6 +218,20 @@ users try to enable them. $ devlink dev eswitch set pci/0000:06:00.0 mode switchdev +Bridge offload +============== +The mlx5 driver implements support for offloading bridge rules when in switchdev +mode. Linux bridge FDBs are automatically offloaded when mlx5 switchdev +representor is attached to bridge. + +- Change device to switchdev mode:: + + $ devlink dev eswitch set pci/0000:06:00.0 mode switchdev + +- Attach mlx5 switchdev representor 'enp8s0f0' to bridge netdev 'bridge1':: + + $ ip link set enp8s0f0 master bridge1 + mlx5 subfunction ================ mlx5 supports subfunction management using devlink port (see :ref:`Documentation/networking/devlink/devlink-port.rst `) interface. -- cgit v1.2.3 From ffc89ee5e5e88aa5924034c28d5e5aae75229e0f Mon Sep 17 00:00:00 2001 From: Vlad Buslov Date: Fri, 12 Mar 2021 13:37:46 +0200 Subject: net/mlx5: Bridge, match FDB entry vlan tag Add support for FDB vlan-tagged entries. Extend ingress and egress flow tables with flow groups to match packet vlan tag. Modify the flow creation code to include vlan tag, if vlan is configured on port and vlan configuration is supported for offload. Signed-off-by: Vlad Buslov Reviewed-by: Jianbo Liu Signed-off-by: Saeed Mahameed --- .../networking/device_drivers/ethernet/mellanox/mlx5.rst | 9 +++++++++ 1 file changed, 9 insertions(+) (limited to 'Documentation') diff --git a/Documentation/networking/device_drivers/ethernet/mellanox/mlx5.rst b/Documentation/networking/device_drivers/ethernet/mellanox/mlx5.rst index ea32136b30e7..a0c91fe5574d 100644 --- a/Documentation/networking/device_drivers/ethernet/mellanox/mlx5.rst +++ b/Documentation/networking/device_drivers/ethernet/mellanox/mlx5.rst @@ -232,6 +232,15 @@ representor is attached to bridge. $ ip link set enp8s0f0 master bridge1 +VLANs +----- +Following bridge VLAN functions are supported by mlx5: + +- VLAN filtering (including multiple VLANs per port):: + + $ ip link set bridge1 type bridge vlan_filtering 1 + $ bridge vlan add dev enp8s0f0 vid 2-3 + mlx5 subfunction ================ mlx5 supports subfunction management using devlink port (see :ref:`Documentation/networking/devlink/devlink-port.rst `) interface. -- cgit v1.2.3 From 36e55079e54955a70b2c340eedd6125f794a911d Mon Sep 17 00:00:00 2001 From: Vlad Buslov Date: Fri, 2 Apr 2021 15:09:06 +0300 Subject: net/mlx5: Bridge, support pvid and untagged vlan configurations Implement support for pushing vlan header into untagged packet on ingress of port that has pvid configured and support for popping vlan on egress of port that has the matching vlan configured as untagged. To support such configurations packet reformat contexts of {INSERT|REMOVE}_HEADER types are created per such vlan and saved to struct mlx5_esw_bridge_vlan which allows all FDB entries on particular vlan to share single packet reformat instance. When initializing FDB entries with pvid or untagged vlan type set its mlx5_flow_act->pkt_reformat action accordingly. Flush all flows when removing vlan from port. This is necessary because even though software bridge removes all FDB entries before removing their vlan, mlx5 bridge implementation deletes their corresponding flow entries from hardware in asynchronous workqueue task, which will cause firmware error if vlan packet reformat context is deleted before all flows that point to it. Signed-off-by: Vlad Buslov Reviewed-by: Jianbo Liu Signed-off-by: Saeed Mahameed --- .../networking/device_drivers/ethernet/mellanox/mlx5.rst | 8 ++++++++ 1 file changed, 8 insertions(+) (limited to 'Documentation') diff --git a/Documentation/networking/device_drivers/ethernet/mellanox/mlx5.rst b/Documentation/networking/device_drivers/ethernet/mellanox/mlx5.rst index a0c91fe5574d..058882dca17b 100644 --- a/Documentation/networking/device_drivers/ethernet/mellanox/mlx5.rst +++ b/Documentation/networking/device_drivers/ethernet/mellanox/mlx5.rst @@ -241,6 +241,14 @@ Following bridge VLAN functions are supported by mlx5: $ ip link set bridge1 type bridge vlan_filtering 1 $ bridge vlan add dev enp8s0f0 vid 2-3 +- VLAN push on bridge ingress:: + + $ bridge vlan add dev enp8s0f0 vid 3 pvid + +- VLAN pop on bridge egress:: + + $ bridge vlan add dev enp8s0f0 vid 3 untagged + mlx5 subfunction ================ mlx5 supports subfunction management using devlink port (see :ref:`Documentation/networking/devlink/devlink-port.rst `) interface. -- cgit v1.2.3 From 9724fd5d9c2a0d3686b799ed5ca90cb9378ca4f2 Mon Sep 17 00:00:00 2001 From: Vlad Buslov Date: Fri, 2 Apr 2021 21:16:13 +0300 Subject: net/mlx5: Bridge, add tracepoints Move private bridge structures to dedicated headers that is accessible to bridge tracepoint header. Implemented following tracepoints: - Initialize FDB entry. - Refresh FDB entry. - Cleanup FDB entry. - Create VLAN. - Cleanup VLAN. - Attach port to bridge. - Detach port from bridge. Usage example: ># cd /sys/kernel/debug/tracing ># echo mlx5:mlx5_esw_bridge_fdb_entry_init >> set_event ># cat trace ... kworker/u20:1-96 [001] .... 231.892503: mlx5_esw_bridge_fdb_entry_init: net_device=enp8s0f0_0 addr=e4:fd:05:08:00:02 vid=3 flags=0 lastuse=4294895695 Signed-off-by: Vlad Buslov Reviewed-by: Jianbo Liu Signed-off-by: Saeed Mahameed --- .../device_drivers/ethernet/mellanox/mlx5.rst | 56 ++++++++++++++++++++++ 1 file changed, 56 insertions(+) (limited to 'Documentation') diff --git a/Documentation/networking/device_drivers/ethernet/mellanox/mlx5.rst b/Documentation/networking/device_drivers/ethernet/mellanox/mlx5.rst index 058882dca17b..ef8cb62e82a1 100644 --- a/Documentation/networking/device_drivers/ethernet/mellanox/mlx5.rst +++ b/Documentation/networking/device_drivers/ethernet/mellanox/mlx5.rst @@ -600,3 +600,59 @@ tc and eswitch offloads tracepoints: $ cat /sys/kernel/debug/tracing/trace ... kworker/u48:7-2221 [009] ...1 1475.387435: mlx5e_rep_neigh_update: netdev: ens1f0 MAC: 24:8a:07:9a:17:9a IPv4: 1.1.1.10 IPv6: ::ffff:1.1.1.10 neigh_connected=1 + +Bridge offloads tracepoints: + +- mlx5_esw_bridge_fdb_entry_init: trace bridge FDB entry offloaded to mlx5:: + + $ echo mlx5:mlx5_esw_bridge_fdb_entry_init >> set_event + $ cat /sys/kernel/debug/tracing/trace + ... + kworker/u20:9-2217 [003] ...1 318.582243: mlx5_esw_bridge_fdb_entry_init: net_device=enp8s0f0_0 addr=e4:fd:05:08:00:02 vid=0 flags=0 used=0 + +- mlx5_esw_bridge_fdb_entry_cleanup: trace bridge FDB entry deleted from mlx5:: + + $ echo mlx5:mlx5_esw_bridge_fdb_entry_cleanup >> set_event + $ cat /sys/kernel/debug/tracing/trace + ... + ip-2581 [005] ...1 318.629871: mlx5_esw_bridge_fdb_entry_cleanup: net_device=enp8s0f0_1 addr=e4:fd:05:08:00:03 vid=0 flags=0 used=16 + +- mlx5_esw_bridge_fdb_entry_refresh: trace bridge FDB entry offload refreshed in + mlx5:: + + $ echo mlx5:mlx5_esw_bridge_fdb_entry_refresh >> set_event + $ cat /sys/kernel/debug/tracing/trace + ... + kworker/u20:8-3849 [003] ...1 466716: mlx5_esw_bridge_fdb_entry_refresh: net_device=enp8s0f0_0 addr=e4:fd:05:08:00:02 vid=3 flags=0 used=0 + +- mlx5_esw_bridge_vlan_create: trace bridge VLAN object add on mlx5 + representor:: + + $ echo mlx5:mlx5_esw_bridge_vlan_create >> set_event + $ cat /sys/kernel/debug/tracing/trace + ... + ip-2560 [007] ...1 318.460258: mlx5_esw_bridge_vlan_create: vid=1 flags=6 + +- mlx5_esw_bridge_vlan_cleanup: trace bridge VLAN object delete from mlx5 + representor:: + + $ echo mlx5:mlx5_esw_bridge_vlan_cleanup >> set_event + $ cat /sys/kernel/debug/tracing/trace + ... + bridge-2582 [007] ...1 318.653496: mlx5_esw_bridge_vlan_cleanup: vid=2 flags=8 + +- mlx5_esw_bridge_vport_init: trace mlx5 vport assigned with bridge upper + device:: + + $ echo mlx5:mlx5_esw_bridge_vport_init >> set_event + $ cat /sys/kernel/debug/tracing/trace + ... + ip-2560 [007] ...1 318.458915: mlx5_esw_bridge_vport_init: vport_num=1 + +- mlx5_esw_bridge_vport_cleanup: trace mlx5 vport removed from bridge upper + device:: + + $ echo mlx5:mlx5_esw_bridge_vport_cleanup >> set_event + $ cat /sys/kernel/debug/tracing/trace + ... + ip-5387 [000] ...1 573713: mlx5_esw_bridge_vport_cleanup: vport_num=1 -- cgit v1.2.3 From fcafd31b5f535573dd045f6151ab93a806e2b05b Mon Sep 17 00:00:00 2001 From: Heiko Stuebner Date: Mon, 7 Jun 2021 16:13:34 +0200 Subject: dt-bindings: soc: rockchip: drop unnecessary #phy-cells from grf.yaml The recent yaml conversion of the grf and inno-usb2-phy bindings left the #phy-cells in place in the main usb2phy node inside the example in grf.yaml, causing new warnings. Drop it to make the bindingcheck happy. Fixes: e71ccdff376b ("dt-bindings: phy: rename phy nodename in phy-rockchip-inno-usb2.yaml") Signed-off-by: Heiko Stuebner Link: https://lore.kernel.org/r/20210607141845.3331910-1-heiko@sntech.de --- Documentation/devicetree/bindings/soc/rockchip/grf.yaml | 1 - 1 file changed, 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/soc/rockchip/grf.yaml b/Documentation/devicetree/bindings/soc/rockchip/grf.yaml index 8c1c46fef157..62fa72cfea34 100644 --- a/Documentation/devicetree/bindings/soc/rockchip/grf.yaml +++ b/Documentation/devicetree/bindings/soc/rockchip/grf.yaml @@ -242,7 +242,6 @@ examples: clock-names = "phyclk"; #clock-cells = <0>; clock-output-names = "clk_usbphy0_480m"; - #phy-cells = <0>; u2phy0_host: host-port { #phy-cells = <0>; -- cgit v1.2.3 From 0159bb020ca9a43b17aa9149f1199643c1d49426 Mon Sep 17 00:00:00 2001 From: "Joel Fernandes (Google)" Date: Wed, 2 Jun 2021 21:31:36 -0400 Subject: Documentation: Add usecases, design and interface for core scheduling Now that core scheduling is merged, update the documentation. Co-developed-by: Chris Hyser Signed-off-by: Chris Hyser Co-developed-by: Josh Don Signed-off-by: Josh Don Signed-off-by: Joel Fernandes (Google) Signed-off-by: Peter Zijlstra (Intel) Link: https://lkml.kernel.org/r/20210603013136.370918-1-joel@joelfernandes.org --- .../admin-guide/hw-vuln/core-scheduling.rst | 223 +++++++++++++++++++++ Documentation/admin-guide/hw-vuln/index.rst | 1 + 2 files changed, 224 insertions(+) create mode 100644 Documentation/admin-guide/hw-vuln/core-scheduling.rst (limited to 'Documentation') diff --git a/Documentation/admin-guide/hw-vuln/core-scheduling.rst b/Documentation/admin-guide/hw-vuln/core-scheduling.rst new file mode 100644 index 000000000000..7b410aef9c5c --- /dev/null +++ b/Documentation/admin-guide/hw-vuln/core-scheduling.rst @@ -0,0 +1,223 @@ +.. SPDX-License-Identifier: GPL-2.0 + +=============== +Core Scheduling +=============== +Core scheduling support allows userspace to define groups of tasks that can +share a core. These groups can be specified either for security usecases (one +group of tasks don't trust another), or for performance usecases (some +workloads may benefit from running on the same core as they don't need the same +hardware resources of the shared core, or may prefer different cores if they +do share hardware resource needs). This document only describes the security +usecase. + +Security usecase +---------------- +A cross-HT attack involves the attacker and victim running on different Hyper +Threads of the same core. MDS and L1TF are examples of such attacks. The only +full mitigation of cross-HT attacks is to disable Hyper Threading (HT). Core +scheduling is a scheduler feature that can mitigate some (not all) cross-HT +attacks. It allows HT to be turned on safely by ensuring that only tasks in a +user-designated trusted group can share a core. This increase in core sharing +can also improve performance, however it is not guaranteed that performance +will always improve, though that is seen to be the case with a number of real +world workloads. In theory, core scheduling aims to perform at least as good as +when Hyper Threading is disabled. In practice, this is mostly the case though +not always: as synchronizing scheduling decisions across 2 or more CPUs in a +core involves additional overhead - especially when the system is lightly +loaded. When ``total_threads <= N_CPUS/2``, the extra overhead may cause core +scheduling to perform more poorly compared to SMT-disabled, where N_CPUS is the +total number of CPUs. Please measure the performance of your workloads always. + +Usage +----- +Core scheduling support is enabled via the ``CONFIG_SCHED_CORE`` config option. +Using this feature, userspace defines groups of tasks that can be co-scheduled +on the same core. The core scheduler uses this information to make sure that +tasks that are not in the same group never run simultaneously on a core, while +doing its best to satisfy the system's scheduling requirements. + +Core scheduling can be enabled via the ``PR_SCHED_CORE`` prctl interface. +This interface provides support for the creation of core scheduling groups, as +well as admission and removal of tasks from created groups:: + + #include + + int prctl(int option, unsigned long arg2, unsigned long arg3, + unsigned long arg4, unsigned long arg5); + +option: + ``PR_SCHED_CORE`` + +arg2: + Command for operation, must be one off: + + - ``PR_SCHED_CORE_GET`` -- get core_sched cookie of ``pid``. + - ``PR_SCHED_CORE_CREATE`` -- create a new unique cookie for ``pid``. + - ``PR_SCHED_CORE_SHARE_TO`` -- push core_sched cookie to ``pid``. + - ``PR_SCHED_CORE_SHARE_FROM`` -- pull core_sched cookie from ``pid``. + +arg3: + ``pid`` of the task for which the operation applies. + +arg4: + ``pid_type`` for which the operation applies. It is of type ``enum pid_type``. + For example, if arg4 is ``PIDTYPE_TGID``, then the operation of this command + will be performed for all tasks in the task group of ``pid``. + +arg5: + userspace pointer to an unsigned long for storing the cookie returned by + ``PR_SCHED_CORE_GET`` command. Should be 0 for all other commands. + +In order for a process to push a cookie to, or pull a cookie from a process, it +is required to have the ptrace access mode: `PTRACE_MODE_READ_REALCREDS` to the +process. + +Building hierarchies of tasks +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +The simplest way to build hierarchies of threads/processes which share a +cookie and thus a core is to rely on the fact that the core-sched cookie is +inherited across forks/clones and execs, thus setting a cookie for the +'initial' script/executable/daemon will place every spawned child in the +same core-sched group. + +Cookie Transferral +~~~~~~~~~~~~~~~~~~ +Transferring a cookie between the current and other tasks is possible using +PR_SCHED_CORE_SHARE_FROM and PR_SCHED_CORE_SHARE_TO to inherit a cookie from a +specified task or a share a cookie with a task. In combination this allows a +simple helper program to pull a cookie from a task in an existing core +scheduling group and share it with already running tasks. + +Design/Implementation +--------------------- +Each task that is tagged is assigned a cookie internally in the kernel. As +mentioned in `Usage`_, tasks with the same cookie value are assumed to trust +each other and share a core. + +The basic idea is that, every schedule event tries to select tasks for all the +siblings of a core such that all the selected tasks running on a core are +trusted (same cookie) at any point in time. Kernel threads are assumed trusted. +The idle task is considered special, as it trusts everything and everything +trusts it. + +During a schedule() event on any sibling of a core, the highest priority task on +the sibling's core is picked and assigned to the sibling calling schedule(), if +the sibling has the task enqueued. For rest of the siblings in the core, +highest priority task with the same cookie is selected if there is one runnable +in their individual run queues. If a task with same cookie is not available, +the idle task is selected. Idle task is globally trusted. + +Once a task has been selected for all the siblings in the core, an IPI is sent to +siblings for whom a new task was selected. Siblings on receiving the IPI will +switch to the new task immediately. If an idle task is selected for a sibling, +then the sibling is considered to be in a `forced idle` state. I.e., it may +have tasks on its on runqueue to run, however it will still have to run idle. +More on this in the next section. + +Forced-idling of hyperthreads +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +The scheduler tries its best to find tasks that trust each other such that all +tasks selected to be scheduled are of the highest priority in a core. However, +it is possible that some runqueues had tasks that were incompatible with the +highest priority ones in the core. Favoring security over fairness, one or more +siblings could be forced to select a lower priority task if the highest +priority task is not trusted with respect to the core wide highest priority +task. If a sibling does not have a trusted task to run, it will be forced idle +by the scheduler (idle thread is scheduled to run). + +When the highest priority task is selected to run, a reschedule-IPI is sent to +the sibling to force it into idle. This results in 4 cases which need to be +considered depending on whether a VM or a regular usermode process was running +on either HT:: + + HT1 (attack) HT2 (victim) + A idle -> user space user space -> idle + B idle -> user space guest -> idle + C idle -> guest user space -> idle + D idle -> guest guest -> idle + +Note that for better performance, we do not wait for the destination CPU +(victim) to enter idle mode. This is because the sending of the IPI would bring +the destination CPU immediately into kernel mode from user space, or VMEXIT +in the case of guests. At best, this would only leak some scheduler metadata +which may not be worth protecting. It is also possible that the IPI is received +too late on some architectures, but this has not been observed in the case of +x86. + +Trust model +~~~~~~~~~~~ +Core scheduling maintains trust relationships amongst groups of tasks by +assigning them a tag that is the same cookie value. +When a system with core scheduling boots, all tasks are considered to trust +each other. This is because the core scheduler does not have information about +trust relationships until userspace uses the above mentioned interfaces, to +communicate them. In other words, all tasks have a default cookie value of 0. +and are considered system-wide trusted. The forced-idling of siblings running +cookie-0 tasks is also avoided. + +Once userspace uses the above mentioned interfaces to group sets of tasks, tasks +within such groups are considered to trust each other, but do not trust those +outside. Tasks outside the group also don't trust tasks within. + +Limitations of core-scheduling +------------------------------ +Core scheduling tries to guarantee that only trusted tasks run concurrently on a +core. But there could be small window of time during which untrusted tasks run +concurrently or kernel could be running concurrently with a task not trusted by +kernel. + +IPI processing delays +~~~~~~~~~~~~~~~~~~~~~ +Core scheduling selects only trusted tasks to run together. IPI is used to notify +the siblings to switch to the new task. But there could be hardware delays in +receiving of the IPI on some arch (on x86, this has not been observed). This may +cause an attacker task to start running on a CPU before its siblings receive the +IPI. Even though cache is flushed on entry to user mode, victim tasks on siblings +may populate data in the cache and micro architectural buffers after the attacker +starts to run and this is a possibility for data leak. + +Open cross-HT issues that core scheduling does not solve +-------------------------------------------------------- +1. For MDS +~~~~~~~~~~ +Core scheduling cannot protect against MDS attacks between an HT running in +user mode and another running in kernel mode. Even though both HTs run tasks +which trust each other, kernel memory is still considered untrusted. Such +attacks are possible for any combination of sibling CPU modes (host or guest mode). + +2. For L1TF +~~~~~~~~~~~ +Core scheduling cannot protect against an L1TF guest attacker exploiting a +guest or host victim. This is because the guest attacker can craft invalid +PTEs which are not inverted due to a vulnerable guest kernel. The only +solution is to disable EPT (Extended Page Tables). + +For both MDS and L1TF, if the guest vCPU is configured to not trust each +other (by tagging separately), then the guest to guest attacks would go away. +Or it could be a system admin policy which considers guest to guest attacks as +a guest problem. + +Another approach to resolve these would be to make every untrusted task on the +system to not trust every other untrusted task. While this could reduce +parallelism of the untrusted tasks, it would still solve the above issues while +allowing system processes (trusted tasks) to share a core. + +3. Protecting the kernel (IRQ, syscall, VMEXIT) +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +Unfortunately, core scheduling does not protect kernel contexts running on +sibling hyperthreads from one another. Prototypes of mitigations have been posted +to LKML to solve this, but it is debatable whether such windows are practically +exploitable, and whether the performance overhead of the prototypes are worth +it (not to mention, the added code complexity). + +Other Use cases +--------------- +The main use case for Core scheduling is mitigating the cross-HT vulnerabilities +with SMT enabled. There are other use cases where this feature could be used: + +- Isolating tasks that needs a whole core: Examples include realtime tasks, tasks + that uses SIMD instructions etc. +- Gang scheduling: Requirements for a group of tasks that needs to be scheduled + together could also be realized using core scheduling. One example is vCPUs of + a VM. diff --git a/Documentation/admin-guide/hw-vuln/index.rst b/Documentation/admin-guide/hw-vuln/index.rst index ca4dbdd9016d..f12cda55538b 100644 --- a/Documentation/admin-guide/hw-vuln/index.rst +++ b/Documentation/admin-guide/hw-vuln/index.rst @@ -15,3 +15,4 @@ are configurable at compile, boot or run time. tsx_async_abort multihit.rst special-register-buffer-data-sampling.rst + core-scheduling.rst -- cgit v1.2.3 From 25c794cd440737c5e6d96c78ff9a7660a36e909f Mon Sep 17 00:00:00 2001 From: huangjianghui Date: Thu, 10 Jun 2021 14:20:36 +0800 Subject: ALSA: doc: Fix spelling mistakes correct Reatek to Realtek Signed-off-by: huangjianghui Link: https://lore.kernel.org/r/20210610062036.30300-1-huangjianghui@uniontech.com Signed-off-by: Takashi Iwai --- Documentation/sound/hd-audio/controls.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/sound/hd-audio/controls.rst b/Documentation/sound/hd-audio/controls.rst index f2ebc4f79b44..dbe6483f4ff4 100644 --- a/Documentation/sound/hd-audio/controls.rst +++ b/Documentation/sound/hd-audio/controls.rst @@ -102,7 +102,7 @@ Conexant codecs --------------- Auto-Mute Mode - See Reatek codecs. + See Realtek codecs. Analog codecs -- cgit v1.2.3 From 405e94e9aed2a38bdcd22efe53c36c6cd53185a6 Mon Sep 17 00:00:00 2001 From: Marc Zyngier Date: Thu, 13 Sep 2018 10:42:25 +0100 Subject: irqdomain: Kill irq_domain_add_legacy_isa This helper doesn't have a user anymore, let's remove it. Signed-off-by: Marc Zyngier --- Documentation/core-api/irq/irq-domain.rst | 1 - 1 file changed, 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/core-api/irq/irq-domain.rst b/Documentation/core-api/irq/irq-domain.rst index 8214e215a8bf..53283b3729a1 100644 --- a/Documentation/core-api/irq/irq-domain.rst +++ b/Documentation/core-api/irq/irq-domain.rst @@ -146,7 +146,6 @@ Legacy irq_domain_add_simple() irq_domain_add_legacy() - irq_domain_add_legacy_isa() irq_domain_create_simple() irq_domain_create_legacy() -- cgit v1.2.3 From fea99822914039c690a5322dd33d5abdc7c27ea3 Mon Sep 17 00:00:00 2001 From: Alexandre Torgue Date: Thu, 15 Apr 2021 12:10:32 +0200 Subject: dt-bindings: net: document ptp_ref clk in dwmac ptp_ref clk has been added in DT but not documented which makes yaml validation failed: ethernet@5800a000: clocks: [[6, 105], [6, 103], [6, 104], [6, 123], [6, 169], [6, 112]] is too long ethernet@5800a000: clock-names: ['stmmaceth', 'mac-clk-tx', 'mac-clk-rx', 'eth-ck', 'ptp_ref', 'ethstp'] is too long Reviewed-by: Rob Herring Signed-off-by: Alexandre Torgue --- Documentation/devicetree/bindings/net/stm32-dwmac.yaml | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/stm32-dwmac.yaml b/Documentation/devicetree/bindings/net/stm32-dwmac.yaml index 27eb6066793f..a1c490f3af02 100644 --- a/Documentation/devicetree/bindings/net/stm32-dwmac.yaml +++ b/Documentation/devicetree/bindings/net/stm32-dwmac.yaml @@ -46,17 +46,18 @@ properties: clocks: minItems: 3 - maxItems: 5 + maxItems: 6 items: - description: GMAC main clock - description: MAC TX clock - description: MAC RX clock - description: For MPU family, used for power mode - description: For MPU family, used for PHY without quartz + - description: PTP clock clock-names: minItems: 3 - maxItems: 5 + maxItems: 6 contains: enum: - stmmaceth @@ -64,6 +65,7 @@ properties: - mac-clk-rx - ethstp - eth-ck + - ptp_ref st,syscon: $ref: "/schemas/types.yaml#/definitions/phandle-array" -- cgit v1.2.3 From 305b80780879117b3448da42afe95af312393fbd Mon Sep 17 00:00:00 2001 From: Lad Prabhakar Date: Wed, 9 Jun 2021 16:32:20 +0100 Subject: dt-bindings: arm: renesas: Document Renesas RZ/G2UL SoC Add device tree bindings documentation for Renesas RZ/G2UL SoC. Signed-off-by: Lad Prabhakar Reviewed-by: Biju Das Reviewed-by: Chris Paterson Acked-by: Rob Herring Link: https://lore.kernel.org/r/20210609153230.6967-2-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Geert Uytterhoeven --- Documentation/devicetree/bindings/arm/renesas.yaml | 7 +++++++ 1 file changed, 7 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/renesas.yaml b/Documentation/devicetree/bindings/arm/renesas.yaml index 5fd0696a9f91..3b79108b49a0 100644 --- a/Documentation/devicetree/bindings/arm/renesas.yaml +++ b/Documentation/devicetree/bindings/arm/renesas.yaml @@ -302,6 +302,13 @@ properties: - renesas,rzn1d400-db # RZN1D-DB (RZ/N1D Demo Board for the RZ/N1D 400 pins package) - const: renesas,r9a06g032 + - description: RZ/G2UL (R9A07G043) + items: + - enum: + - renesas,r9a07g043u11 # RZ/G2UL Type-1 + - renesas,r9a07g043u12 # RZ/G2UL Type-2 + - const: renesas,r9a07g043 + additionalProperties: true ... -- cgit v1.2.3 From 2cd22416745fe1f0f6b6fa70c09438f85e20c693 Mon Sep 17 00:00:00 2001 From: Lad Prabhakar Date: Wed, 9 Jun 2021 16:32:21 +0100 Subject: dt-bindings: arm: renesas: Document Renesas RZ/G2{L,LC} SoC variants Add device tree bindings documentation for Renesas RZ/G2{L,LC} SoC variants. Signed-off-by: Lad Prabhakar Reviewed-by: Biju Das Reviewed-by: Chris Paterson Acked-by: Rob Herring Link: https://lore.kernel.org/r/20210609153230.6967-3-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Geert Uytterhoeven --- Documentation/devicetree/bindings/arm/renesas.yaml | 9 +++++++++ 1 file changed, 9 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/renesas.yaml b/Documentation/devicetree/bindings/arm/renesas.yaml index 3b79108b49a0..0f99408960d7 100644 --- a/Documentation/devicetree/bindings/arm/renesas.yaml +++ b/Documentation/devicetree/bindings/arm/renesas.yaml @@ -309,6 +309,15 @@ properties: - renesas,r9a07g043u12 # RZ/G2UL Type-2 - const: renesas,r9a07g043 + - description: RZ/G2{L,LC} (R9A07G044) + items: + - enum: + - renesas,r9a07g044c1 # Single Cortex-A55 RZ/G2LC + - renesas,r9a07g044c2 # Dual Cortex-A55 RZ/G2LC + - renesas,r9a07g044l1 # Single Cortex-A55 RZ/G2L + - renesas,r9a07g044l2 # Dual Cortex-A55 RZ/G2L + - const: renesas,r9a07g044 + additionalProperties: true ... -- cgit v1.2.3 From 4affc072e4fef6d1778f957037f255a6acdd44e2 Mon Sep 17 00:00:00 2001 From: Lad Prabhakar Date: Wed, 9 Jun 2021 16:32:22 +0100 Subject: dt-bindings: arm: renesas: Document SMARC EVK Document Renesas SMARC EVK board which are based on RZ/G2L (R9A07G044) SoC. The SMARC EVK consists of RZ/G2L SoM module and SMARC carrier board, the SoM module sits on top of carrier board. Signed-off-by: Lad Prabhakar Reviewed-by: Biju Das Reviewed-by: Chris Paterson Acked-by: Rob Herring Link: https://lore.kernel.org/r/20210609153230.6967-4-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Geert Uytterhoeven --- Documentation/devicetree/bindings/arm/renesas.yaml | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/renesas.yaml b/Documentation/devicetree/bindings/arm/renesas.yaml index 0f99408960d7..a0cce4e25039 100644 --- a/Documentation/devicetree/bindings/arm/renesas.yaml +++ b/Documentation/devicetree/bindings/arm/renesas.yaml @@ -311,6 +311,8 @@ properties: - description: RZ/G2{L,LC} (R9A07G044) items: + - enum: + - renesas,smarc-evk # SMARC EVK - enum: - renesas,r9a07g044c1 # Single Cortex-A55 RZ/G2LC - renesas,r9a07g044c2 # Dual Cortex-A55 RZ/G2LC -- cgit v1.2.3 From 972f67be8929ac095df6a8bbce738b4f39e984cb Mon Sep 17 00:00:00 2001 From: Lad Prabhakar Date: Wed, 9 Jun 2021 17:37:15 +0100 Subject: dt-bindings: power: renesas,rzg2l-sysc: Add DT binding documentation for SYSC controller Add DT binding documentation for SYSC controller found on RZ/G2{L,LC,UL} SoC's. SYSC block contains the LSI_DEVID register which is used to retrieve SoC product information. Signed-off-by: Lad Prabhakar Reviewed-by: Biju Das Link: https://lore.kernel.org/r/20210609163717.3083-2-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Geert Uytterhoeven --- .../bindings/power/renesas,rzg2l-sysc.yaml | 63 ++++++++++++++++++++++ 1 file changed, 63 insertions(+) create mode 100644 Documentation/devicetree/bindings/power/renesas,rzg2l-sysc.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/power/renesas,rzg2l-sysc.yaml b/Documentation/devicetree/bindings/power/renesas,rzg2l-sysc.yaml new file mode 100644 index 000000000000..84ddc772b003 --- /dev/null +++ b/Documentation/devicetree/bindings/power/renesas,rzg2l-sysc.yaml @@ -0,0 +1,63 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/power/renesas,rzg2l-sysc.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: Renesas RZ/G2L System Controller (SYSC) + +maintainers: + - Geert Uytterhoeven + +description: + The RZ/G2L System Controller (SYSC) performs system control of the LSI and + supports following functions, + - External terminal state capture function + - 34-bit address space access function + - Low power consumption control + - WDT stop control + +properties: + compatible: + enum: + - renesas,r9a07g044-sysc # RZ/G2{L,LC} + + reg: + maxItems: 1 + + interrupts: + items: + - description: CA55/CM33 Sleep/Software Standby Mode request interrupt + - description: CA55 Software Standby Mode release request interrupt + - description: CM33 Software Standby Mode release request interrupt + - description: CA55 ACE Asynchronous Bridge Master/Slave interface deny request interrupt + + interrupt-names: + items: + - const: lpm_int + - const: ca55stbydone_int + - const: cm33stbyr_int + - const: ca55_deny + +required: + - compatible + - reg + - interrupts + - interrupt-names + +additionalProperties: false + +examples: + - | + #include + + sysc: system-controller@11020000 { + compatible = "renesas,r9a07g044-sysc"; + reg = <0x11020000 0x10000>; + interrupts = , + , + , + ; + interrupt-names = "lpm_int", "ca55stbydone_int", "cm33stbyr_int", + "ca55_deny"; + }; -- cgit v1.2.3 From f8ec89126a72b399e63399d8d21fd413f4059f00 Mon Sep 17 00:00:00 2001 From: Lad Prabhakar Date: Wed, 9 Jun 2021 16:32:26 +0100 Subject: dt-bindings: clock: renesas: Document RZ/G2L SoC CPG driver Document the device tree bindings of the Renesas RZ/G2L SoC clock driver in Documentation/devicetree/bindings/clock/renesas,rzg2l-cpg.yaml. Signed-off-by: Lad Prabhakar Reviewed-by: Biju Das Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20210609153230.6967-8-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Geert Uytterhoeven --- .../bindings/clock/renesas,rzg2l-cpg.yaml | 83 ++++++++++++++++++++++ 1 file changed, 83 insertions(+) create mode 100644 Documentation/devicetree/bindings/clock/renesas,rzg2l-cpg.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/renesas,rzg2l-cpg.yaml b/Documentation/devicetree/bindings/clock/renesas,rzg2l-cpg.yaml new file mode 100644 index 000000000000..30b2e3d0d25d --- /dev/null +++ b/Documentation/devicetree/bindings/clock/renesas,rzg2l-cpg.yaml @@ -0,0 +1,83 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/clock/renesas,rzg2l-cpg.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: Renesas RZ/G2L Clock Pulse Generator / Module Standby Mode + +maintainers: + - Geert Uytterhoeven + +description: | + On Renesas RZ/G2L SoC, the CPG (Clock Pulse Generator) and Module + Standby Mode share the same register block. + + They provide the following functionalities: + - The CPG block generates various core clocks, + - The Module Standby Mode block provides two functions: + 1. Module Standby, providing a Clock Domain to control the clock supply + to individual SoC devices, + 2. Reset Control, to perform a software reset of individual SoC devices. + +properties: + compatible: + const: renesas,r9a07g044-cpg # RZ/G2{L,LC} + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + + clock-names: + description: + Clock source to CPG can be either from external clock input (EXCLK) or + crystal oscillator (XIN/XOUT). + const: extal + + '#clock-cells': + description: | + - For CPG core clocks, the two clock specifier cells must be "CPG_CORE" + and a core clock reference, as defined in + + - For module clocks, the two clock specifier cells must be "CPG_MOD" and + a module number, as defined in the . + const: 2 + + '#power-domain-cells': + description: + SoC devices that are part of the CPG/Module Standby Mode Clock Domain and + can be power-managed through Module Standby should refer to the CPG device + node in their "power-domains" property, as documented by the generic PM + Domain bindings in Documentation/devicetree/bindings/power/power-domain.yaml. + const: 0 + + '#reset-cells': + description: + The single reset specifier cell must be the module number, as defined in + the . + const: 1 + +required: + - compatible + - reg + - clocks + - clock-names + - '#clock-cells' + - '#power-domain-cells' + - '#reset-cells' + +additionalProperties: false + +examples: + - | + cpg: clock-controller@11010000 { + compatible = "renesas,r9a07g044-cpg"; + reg = <0x11010000 0x10000>; + clocks = <&extal_clk>; + clock-names = "extal"; + #clock-cells = <2>; + #power-domain-cells = <0>; + #reset-cells = <1>; + }; -- cgit v1.2.3 From a70eb9165e2a0f2867f0eb78f12665893d135ee1 Mon Sep 17 00:00:00 2001 From: Miquel Raynal Date: Thu, 10 Jun 2021 10:20:23 +0200 Subject: dt-binding: memory: pl353-smc: Rephrase the binding Reword this document before converting it to yaml. Signed-off-by: Miquel Raynal Acked-by: Rob Herring Link: https://lore.kernel.org/r/20210610082040.2075611-2-miquel.raynal@bootlin.com Signed-off-by: Krzysztof Kozlowski --- .../devicetree/bindings/memory-controllers/pl353-smc.txt | 11 +++++------ 1 file changed, 5 insertions(+), 6 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/memory-controllers/pl353-smc.txt b/Documentation/devicetree/bindings/memory-controllers/pl353-smc.txt index d56615fd343a..f0b7fe173668 100644 --- a/Documentation/devicetree/bindings/memory-controllers/pl353-smc.txt +++ b/Documentation/devicetree/bindings/memory-controllers/pl353-smc.txt @@ -1,8 +1,7 @@ Device tree bindings for ARM PL353 static memory controller -PL353 static memory controller supports two kinds of memory -interfaces.i.e NAND and SRAM/NOR interfaces. -The actual devices are instantiated from the child nodes of pl353 smc node. +PL353 Static Memory Controller is a bus where you can connect two kinds +of memory interfaces: NAND and memory mapped interfaces (such as SRAM or NOR). Required properties: - compatible : Should be "arm,pl353-smc-r2p1", "arm,primecell". @@ -13,9 +12,9 @@ Required properties: - address-cells : Must be 2. - size-cells : Must be 1. -Child nodes: - For NAND the "arm,pl353-nand-r2p1" and for NOR the "cfi-flash" drivers are -supported as child nodes. +The child device node represents the controller connected to the SMC +bus. Only one between: NAND controller, NOR controller and SRAM controller +is allowed in a single system. for NAND partition information please refer the below file Documentation/devicetree/bindings/mtd/partition.txt -- cgit v1.2.3 From 386783ea6d9f21374cb11e0e8b8b4bd9770ef485 Mon Sep 17 00:00:00 2001 From: Miquel Raynal Date: Thu, 10 Jun 2021 10:20:24 +0200 Subject: dt-binding: memory: pl353-smc: Document the range property The ranges property is missing in the description while actually used in the example. This property is actually needed, so mention it. Signed-off-by: Miquel Raynal Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20210610082040.2075611-3-miquel.raynal@bootlin.com Signed-off-by: Krzysztof Kozlowski --- Documentation/devicetree/bindings/memory-controllers/pl353-smc.txt | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/memory-controllers/pl353-smc.txt b/Documentation/devicetree/bindings/memory-controllers/pl353-smc.txt index f0b7fe173668..4210acf46a55 100644 --- a/Documentation/devicetree/bindings/memory-controllers/pl353-smc.txt +++ b/Documentation/devicetree/bindings/memory-controllers/pl353-smc.txt @@ -11,6 +11,8 @@ Required properties: - clocks : Clock phandles (see clock bindings for details). - address-cells : Must be 2. - size-cells : Must be 1. +- ranges : Memory bus areas for interacting with the devices. + Encodes CS to memory region association. The child device node represents the controller connected to the SMC bus. Only one between: NAND controller, NOR controller and SRAM controller -- cgit v1.2.3 From f1d19f7400132b45cab4ee60e974150699fe28b5 Mon Sep 17 00:00:00 2001 From: Miquel Raynal Date: Thu, 10 Jun 2021 10:20:25 +0200 Subject: dt-binding: memory: pl353-smc: Drop the partitioning section This sentence does not belong to this file as this file describes the bus on which various controllers are wired to. Signed-off-by: Miquel Raynal Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20210610082040.2075611-4-miquel.raynal@bootlin.com Signed-off-by: Krzysztof Kozlowski --- Documentation/devicetree/bindings/memory-controllers/pl353-smc.txt | 2 -- 1 file changed, 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/memory-controllers/pl353-smc.txt b/Documentation/devicetree/bindings/memory-controllers/pl353-smc.txt index 4210acf46a55..233b2fd8525b 100644 --- a/Documentation/devicetree/bindings/memory-controllers/pl353-smc.txt +++ b/Documentation/devicetree/bindings/memory-controllers/pl353-smc.txt @@ -18,8 +18,6 @@ The child device node represents the controller connected to the SMC bus. Only one between: NAND controller, NOR controller and SRAM controller is allowed in a single system. -for NAND partition information please refer the below file -Documentation/devicetree/bindings/mtd/partition.txt Example: smcc: memory-controller@e000e000 -- cgit v1.2.3 From 6c74a55e1d791be9758d9f23b1c5375854949188 Mon Sep 17 00:00:00 2001 From: Miquel Raynal Date: Thu, 10 Jun 2021 10:20:26 +0200 Subject: dt-binding: memory: pl353-smc: Describe the child reg property Each chil node should have a reg property, no matter the type of controller (NAND, NOR, SRAM). This should be part of the bindings. Signed-off-by: Miquel Raynal Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20210610082040.2075611-5-miquel.raynal@bootlin.com Signed-off-by: Krzysztof Kozlowski --- Documentation/devicetree/bindings/memory-controllers/pl353-smc.txt | 4 ++++ 1 file changed, 4 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/memory-controllers/pl353-smc.txt b/Documentation/devicetree/bindings/memory-controllers/pl353-smc.txt index 233b2fd8525b..105160c795a1 100644 --- a/Documentation/devicetree/bindings/memory-controllers/pl353-smc.txt +++ b/Documentation/devicetree/bindings/memory-controllers/pl353-smc.txt @@ -18,6 +18,10 @@ The child device node represents the controller connected to the SMC bus. Only one between: NAND controller, NOR controller and SRAM controller is allowed in a single system. +Required device node properties: + +- reg: Contains the chip-select id, the offset and the length + of the memory region requested by the device. Example: smcc: memory-controller@e000e000 -- cgit v1.2.3 From 540148ce3455f0dc4fac9414ac12337ae0ab7cf2 Mon Sep 17 00:00:00 2001 From: Miquel Raynal Date: Thu, 10 Jun 2021 10:20:27 +0200 Subject: dt-binding: memory: pl353-smc: Fix the example syntax and style Enhance the spacing, the comment style, add { }, remove (...). Signed-off-by: Miquel Raynal Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20210610082040.2075611-6-miquel.raynal@bootlin.com Signed-off-by: Krzysztof Kozlowski --- .../bindings/memory-controllers/pl353-smc.txt | 48 +++++++++++----------- 1 file changed, 25 insertions(+), 23 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/memory-controllers/pl353-smc.txt b/Documentation/devicetree/bindings/memory-controllers/pl353-smc.txt index 105160c795a1..46e17f5bc45b 100644 --- a/Documentation/devicetree/bindings/memory-controllers/pl353-smc.txt +++ b/Documentation/devicetree/bindings/memory-controllers/pl353-smc.txt @@ -24,27 +24,29 @@ Required device node properties: of the memory region requested by the device. Example: - smcc: memory-controller@e000e000 - compatible = "arm,pl353-smc-r2p1", "arm,primecell"; - clock-names = "memclk", "apb_pclk"; - clocks = <&clkc 11>, <&clkc 44>; - reg = <0xe000e000 0x1000>; - #address-cells = <2>; - #size-cells = <1>; - ranges = <0x0 0x0 0xe1000000 0x1000000 //Nand CS Region - 0x1 0x0 0xe2000000 0x2000000 //SRAM/NOR CS Region - 0x2 0x0 0xe4000000 0x2000000>; //SRAM/NOR CS Region - nand_0: flash@e1000000 { - compatible = "arm,pl353-nand-r2p1" - reg = <0 0 0x1000000>; - (...) - }; - nor0: flash@e2000000 { - compatible = "cfi-flash"; - reg = <1 0 0x2000000>; - }; - nor1: flash@e4000000 { - compatible = "cfi-flash"; - reg = <2 0 0x2000000>; - }; + smcc: memory-controller@e000e000 { + compatible = "arm,pl353-smc-r2p1", "arm,primecell"; + clock-names = "memclk", "apb_pclk"; + clocks = <&clkc 11>, <&clkc 44>; + reg = <0xe000e000 0x1000>; + #address-cells = <2>; + #size-cells = <1>; + ranges = <0x0 0x0 0xe1000000 0x1000000 /* Nand CS region */ + 0x1 0x0 0xe2000000 0x2000000 /* SRAM/NOR CS0 region */ + 0x2 0x0 0xe4000000 0x2000000>; /* SRAM/NOR CS1 region */ + + nand_0: flash@e1000000 { + compatible = "arm,pl353-nand-r2p1"; + reg = <0 0 0x1000000>; + }; + + nor0: flash@e2000000 { + compatible = "cfi-flash"; + reg = <1 0 0x2000000>; + }; + + nor1: flash@e4000000 { + compatible = "cfi-flash"; + reg = <2 0 0x2000000>; + }; }; -- cgit v1.2.3 From 29c6d09f39591eb3ea5e8e64ed42b28b9ae31f99 Mon Sep 17 00:00:00 2001 From: Miquel Raynal Date: Thu, 10 Jun 2021 10:20:28 +0200 Subject: dt-binding: memory: pl353-smc: Drop unsupported nodes from the example These nodes are given as examples and are not described nor used anywhere else. There is also no hardware of my knowledge compatible with these yet. If we want to be backward compatible, then we should avoid partially describing nodes and their content while there are no users. Plus, the examples are wrong (the addresses should be updated) so let's drop them before converting this file to yaml (only the NAND node, which will be fixed in the example and described somewhere else is kept). Signed-off-by: Miquel Raynal Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20210610082040.2075611-7-miquel.raynal@bootlin.com Signed-off-by: Krzysztof Kozlowski --- .../devicetree/bindings/memory-controllers/pl353-smc.txt | 10 ---------- 1 file changed, 10 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/memory-controllers/pl353-smc.txt b/Documentation/devicetree/bindings/memory-controllers/pl353-smc.txt index 46e17f5bc45b..3ff6a4a49302 100644 --- a/Documentation/devicetree/bindings/memory-controllers/pl353-smc.txt +++ b/Documentation/devicetree/bindings/memory-controllers/pl353-smc.txt @@ -39,14 +39,4 @@ Example: compatible = "arm,pl353-nand-r2p1"; reg = <0 0 0x1000000>; }; - - nor0: flash@e2000000 { - compatible = "cfi-flash"; - reg = <1 0 0x2000000>; - }; - - nor1: flash@e4000000 { - compatible = "cfi-flash"; - reg = <2 0 0x2000000>; - }; }; -- cgit v1.2.3 From 9af22e1169dd6b0f498fa8f9bff7c44f721b1b20 Mon Sep 17 00:00:00 2001 From: Miquel Raynal Date: Thu, 10 Jun 2021 10:20:29 +0200 Subject: dt-binding: memory: pl353-smc: Fix the NAND controller node in the example To be fully valid, the NAND controller node in the example should be named nand-controller instead of flash, should be at the address @0,0 instead of @e1000000 and should have a couple of: - #address-cells - #size-cells properties. The label is being renamed nfc0 as well which is more usual than nand_0. Signed-off-by: Miquel Raynal Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20210610082040.2075611-8-miquel.raynal@bootlin.com Signed-off-by: Krzysztof Kozlowski --- Documentation/devicetree/bindings/memory-controllers/pl353-smc.txt | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/memory-controllers/pl353-smc.txt b/Documentation/devicetree/bindings/memory-controllers/pl353-smc.txt index 3ff6a4a49302..ecd46856f139 100644 --- a/Documentation/devicetree/bindings/memory-controllers/pl353-smc.txt +++ b/Documentation/devicetree/bindings/memory-controllers/pl353-smc.txt @@ -35,8 +35,10 @@ Example: 0x1 0x0 0xe2000000 0x2000000 /* SRAM/NOR CS0 region */ 0x2 0x0 0xe4000000 0x2000000>; /* SRAM/NOR CS1 region */ - nand_0: flash@e1000000 { + nfc0: nand-controller@0,0 { compatible = "arm,pl353-nand-r2p1"; reg = <0 0 0x1000000>; + #address-cells = <1>; + #size-cells = <0>; }; }; -- cgit v1.2.3 From ee0a07017ae34f2dbf5775956d8fc3f6d36be985 Mon Sep 17 00:00:00 2001 From: Masami Hiramatsu Date: Wed, 2 Jun 2021 23:33:09 +0900 Subject: Documentation: tracing: Add per-group/all events enablement desciption Add ftrace.event..enable and ftrace.event.enable bootconfig description in the boot-time tracing document. Link: https://lkml.kernel.org/r/162264438901.302580.10697703336929432947.stgit@devnote2 Signed-off-by: Masami Hiramatsu Signed-off-by: Steven Rostedt (VMware) --- Documentation/trace/boottime-trace.rst | 6 ++++++ 1 file changed, 6 insertions(+) (limited to 'Documentation') diff --git a/Documentation/trace/boottime-trace.rst b/Documentation/trace/boottime-trace.rst index 89b64334929b..8053898cfeb4 100644 --- a/Documentation/trace/boottime-trace.rst +++ b/Documentation/trace/boottime-trace.rst @@ -99,6 +99,12 @@ These options are setting per-event options. ftrace.[instance.INSTANCE.]event.GROUP.EVENT.enable Enable GROUP:EVENT tracing. +ftrace.[instance.INSTANCE.]event.GROUP.enable + Enable all event tracing within GROUP. + +ftrace.[instance.INSTANCE.]event.enable + Enable all event tracing. + ftrace.[instance.INSTANCE.]event.GROUP.EVENT.filter = FILTER Set FILTER rule to the GROUP:EVENT. -- cgit v1.2.3 From f0b65f39ac505e8f1dcdaa165aa7b8c0bd6fd454 Mon Sep 17 00:00:00 2001 From: Al Viro Date: Fri, 30 Apr 2021 10:26:41 -0400 Subject: iov_iter: replace iov_iter_copy_from_user_atomic() with iterator-advancing variant Replacement is called copy_page_from_iter_atomic(); unlike the old primitive the callers do *not* need to do iov_iter_advance() after it. In case when they end up consuming less than they'd been given they need to do iov_iter_revert() on everything they had not consumed. That, however, needs to be done only on slow paths. All in-tree callers converted. And that kills the last user of iterate_all_kinds() Signed-off-by: Al Viro --- Documentation/filesystems/porting.rst | 9 +++++++++ 1 file changed, 9 insertions(+) (limited to 'Documentation') diff --git a/Documentation/filesystems/porting.rst b/Documentation/filesystems/porting.rst index 0302035781be..43b492d08dec 100644 --- a/Documentation/filesystems/porting.rst +++ b/Documentation/filesystems/porting.rst @@ -890,3 +890,12 @@ been called or returned with non -EIOCBQUEUED code. mnt_want_write_file() can now only be paired with mnt_drop_write_file(), whereas previously it could be paired with mnt_drop_write() as well. + +--- + +**mandatory** + +iov_iter_copy_from_user_atomic() is gone; use copy_page_from_iter_atomic(). +The difference is copy_page_from_iter_atomic() advances the iterator and +you don't need iov_iter_advance() after it. However, if you decide to use +only a part of obtained data, you should do iov_iter_revert(). -- cgit v1.2.3 From 0e5a89dbb49920cea22193044bbbfd76a9b0f458 Mon Sep 17 00:00:00 2001 From: Hubert Jasudowicz Date: Wed, 9 Jun 2021 23:51:12 +0200 Subject: doc: Remove references to IBM Calgary The Calgary IOMMU driver has been removed in 90dc392fc445 ("x86: Remove the calgary IOMMU driver") Clean up stale docs that refer to it. Signed-off-by: Hubert Jasudowicz Signed-off-by: Borislav Petkov Link: https://lkml.kernel.org/r/1bd2b57dd1db53df09e520b8170ff61418805de4.1623274832.git.hubert.jasudowicz@gmail.com --- Documentation/x86/x86_64/boot-options.rst | 31 +------------------------------ 1 file changed, 1 insertion(+), 30 deletions(-) (limited to 'Documentation') diff --git a/Documentation/x86/x86_64/boot-options.rst b/Documentation/x86/x86_64/boot-options.rst index 324cefff92e7..5f62b3b86357 100644 --- a/Documentation/x86/x86_64/boot-options.rst +++ b/Documentation/x86/x86_64/boot-options.rst @@ -247,16 +247,11 @@ Multiple x86-64 PCI-DMA mapping implementations exist, for example: Kernel boot message: "PCI-DMA: Using software bounce buffering for IO (SWIOTLB)" - 4. : IBM Calgary hardware IOMMU. Used in IBM - pSeries and xSeries servers. This hardware IOMMU supports DMA address - mapping with memory protection, etc. - Kernel boot message: "PCI-DMA: Using Calgary IOMMU" - :: iommu=[][,noagp][,off][,force][,noforce] [,memaper[=]][,merge][,fullflush][,nomerge] - [,noaperture][,calgary] + [,noaperture] General iommu options: @@ -295,8 +290,6 @@ iommu options only relevant to the AMD GART hardware IOMMU: Don't initialize the AGP driver and use full aperture. panic Always panic when IOMMU overflows. - calgary - Use the Calgary IOMMU if it is available iommu options only relevant to the software bounce buffering (SWIOTLB) IOMMU implementation: @@ -307,28 +300,6 @@ implementation: force Force all IO through the software TLB. -Settings for the IBM Calgary hardware IOMMU currently found in IBM -pSeries and xSeries machines - - calgary=[64k,128k,256k,512k,1M,2M,4M,8M] - Set the size of each PCI slot's translation table when using the - Calgary IOMMU. This is the size of the translation table itself - in main memory. The smallest table, 64k, covers an IO space of - 32MB; the largest, 8MB table, can cover an IO space of 4GB. - Normally the kernel will make the right choice by itself. - calgary=[translate_empty_slots] - Enable translation even on slots that have no devices attached to - them, in case a device will be hotplugged in the future. - calgary=[disable=] - Disable translation on a given PHB. For - example, the built-in graphics adapter resides on the first bridge - (PCI bus number 0); if translation (isolation) is enabled on this - bridge, X servers that access the hardware directly from user - space might stop working. Use this option if you have devices that - are accessed from userspace directly on some PCI host bridge. - panic - Always panic when IOMMU overflows - Miscellaneous ============= -- cgit v1.2.3 From af32011f76b759d68a6e3005d450ef7b82e1479a Mon Sep 17 00:00:00 2001 From: Konrad Dybcio Date: Sun, 31 Jan 2021 02:32:32 +0100 Subject: soc: qcom: rpmpd: Add MDM9607 RPM Power Domains This SoC while being from 8916 era, makes use of the newer-style, floor-level management, instead of the older floor-corner. Acked-by: Rob Herring Signed-off-by: Konrad Dybcio Link: https://lore.kernel.org/r/20210131013233.54666-1-konrad.dybcio@somainline.org Signed-off-by: Bjorn Andersson --- Documentation/devicetree/bindings/power/qcom,rpmpd.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml b/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml index c01bb5f0d6ea..4807b560f00d 100644 --- a/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml +++ b/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml @@ -16,6 +16,7 @@ description: properties: compatible: enum: + - qcom,mdm9607-rpmpd - qcom,msm8916-rpmpd - qcom,msm8939-rpmpd - qcom,msm8976-rpmpd -- cgit v1.2.3 From 82a6cbf007648e2c07c29a133cce060fc30aa48f Mon Sep 17 00:00:00 2001 From: Konrad Dybcio Date: Sun, 31 Jan 2021 02:30:57 +0100 Subject: firmware: qcom_scm: Add MDM9607 compatible Add a compatible for MDM9607. It uses the "legacy" calling convention. Acked-by: Rob Herring Signed-off-by: Konrad Dybcio Link: https://lore.kernel.org/r/20210131013058.54299-1-konrad.dybcio@somainline.org Signed-off-by: Bjorn Andersson --- Documentation/devicetree/bindings/firmware/qcom,scm.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/firmware/qcom,scm.txt b/Documentation/devicetree/bindings/firmware/qcom,scm.txt index e747d73687cb..a7333ad938d2 100644 --- a/Documentation/devicetree/bindings/firmware/qcom,scm.txt +++ b/Documentation/devicetree/bindings/firmware/qcom,scm.txt @@ -12,6 +12,7 @@ Required properties: * "qcom,scm-ipq4019" * "qcom,scm-ipq806x" * "qcom,scm-ipq8074" + * "qcom,scm-mdm9607" * "qcom,scm-msm8660" * "qcom,scm-msm8916" * "qcom,scm-msm8960" -- cgit v1.2.3 From 26594678d00f94c62f2e43162bd6d10fd0b74917 Mon Sep 17 00:00:00 2001 From: Leandro Ribeiro Date: Wed, 9 Jun 2021 20:00:38 -0300 Subject: drm/doc: document how userspace should find out CRTC index In this patch we add a section to document what userspace should do to find out the CRTC index. This is important as they may be many places in the documentation that need this, so it's better to just point to this section and avoid repetition. Signed-off-by: Leandro Ribeiro Reviewed-by: Pekka Paalanen Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20210609230039.73307-2-leandro.ribeiro@collabora.com --- Documentation/gpu/drm-uapi.rst | 13 +++++++++++++ 1 file changed, 13 insertions(+) (limited to 'Documentation') diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst index 04bdc7a91d53..7e51dd40bf6e 100644 --- a/Documentation/gpu/drm-uapi.rst +++ b/Documentation/gpu/drm-uapi.rst @@ -457,6 +457,19 @@ Userspace API Structures .. kernel-doc:: include/uapi/drm/drm_mode.h :doc: overview +.. _crtc_index: + +CRTC index +---------- + +CRTC's have both an object ID and an index, and they are not the same thing. +The index is used in cases where a densely packed identifier for a CRTC is +needed, for instance a bitmask of CRTC's. The member possible_crtcs of struct +drm_mode_get_plane is an example. + +DRM_IOCTL_MODE_GETRESOURCES populates a structure with an array of CRTC ID's, +and the CRTC index is its position in this array. + .. kernel-doc:: include/uapi/drm/drm.h :internal: -- cgit v1.2.3 From 0ff2bb7d42c36ee60bbf3e60993666a8e0c06a24 Mon Sep 17 00:00:00 2001 From: Masami Hiramatsu Date: Wed, 2 Jun 2021 17:19:25 +0900 Subject: docs: bootconfig: Update for mixing value and subkeys Update document for the mixing value and subkeys on a key. Link: https://lkml.kernel.org/r/162262196510.264090.15044943496205914148.stgit@devnote2 Signed-off-by: Masami Hiramatsu Signed-off-by: Steven Rostedt (VMware) --- Documentation/admin-guide/bootconfig.rst | 30 ++++++++++++++++++++++++++---- 1 file changed, 26 insertions(+), 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/admin-guide/bootconfig.rst b/Documentation/admin-guide/bootconfig.rst index 452b7dcd7f6b..6a79f2e59396 100644 --- a/Documentation/admin-guide/bootconfig.rst +++ b/Documentation/admin-guide/bootconfig.rst @@ -89,13 +89,35 @@ you can use ``+=`` operator. For example:: In this case, the key ``foo`` has ``bar``, ``baz`` and ``qux``. -However, a sub-key and a value can not co-exist under a parent key. -For example, following config is NOT allowed.:: +Moreover, sub-keys and a value can coexist under a parent key. +For example, following config is allowed.:: foo = value1 - foo.bar = value2 # !ERROR! subkey "bar" and value "value1" can NOT co-exist - foo.bar := value2 # !ERROR! even with the override operator, this is NOT allowed. + foo.bar = value2 + foo := value3 # This will update foo's value. + +Note, since there is no syntax to put a raw value directly under a +structured key, you have to define it outside of the brace. For example:: + + foo { + bar = value1 + bar { + baz = value2 + qux = value3 + } + } + +Also, the order of the value node under a key is fixed. If there +are a value and subkeys, the value is always the first child node +of the key. Thus if user specifies subkeys first, e.g.:: + + foo.bar = value1 + foo = value2 + +In the program (and /proc/bootconfig), it will be shown as below:: + foo = value2 + foo.bar = value1 Comments -------- -- cgit v1.2.3 From d3d0e1e857110a2f8147b1aa3a045b1fccc1e7c3 Mon Sep 17 00:00:00 2001 From: Miquel Raynal Date: Thu, 10 Jun 2021 10:20:30 +0200 Subject: dt-binding: memory: pl353-smc: Convert to yaml Convert this binding file to yaml schema. Signed-off-by: Miquel Raynal Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20210610082040.2075611-10-miquel.raynal@bootlin.com Signed-off-by: Krzysztof Kozlowski --- .../bindings/memory-controllers/arm,pl353-smc.yaml | 131 +++++++++++++++++++++ .../bindings/memory-controllers/pl353-smc.txt | 44 ------- 2 files changed, 131 insertions(+), 44 deletions(-) create mode 100644 Documentation/devicetree/bindings/memory-controllers/arm,pl353-smc.yaml delete mode 100644 Documentation/devicetree/bindings/memory-controllers/pl353-smc.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/memory-controllers/arm,pl353-smc.yaml b/Documentation/devicetree/bindings/memory-controllers/arm,pl353-smc.yaml new file mode 100644 index 000000000000..7a63c85ef8c5 --- /dev/null +++ b/Documentation/devicetree/bindings/memory-controllers/arm,pl353-smc.yaml @@ -0,0 +1,131 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/memory-controllers/arm,pl353-smc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: ARM PL353 Static Memory Controller (SMC) device-tree bindings + +maintainers: + - Miquel Raynal + - Naga Sureshkumar Relli + +description: + The PL353 Static Memory Controller is a bus where you can connect two kinds + of memory interfaces, which are NAND and memory mapped interfaces (such as + SRAM or NOR). + +# We need a select here so we don't match all nodes with 'arm,primecell' +select: + properties: + compatible: + contains: + const: arm,pl353-smc-r2p1 + required: + - compatible + +properties: + $nodename: + pattern: "^memory-controller@[0-9a-f]+$" + + compatible: + items: + - const: arm,pl353-smc-r2p1 + - const: arm,primecell + + "#address-cells": + const: 2 + + "#size-cells": + const: 1 + + reg: + items: + - description: + Configuration registers for the host and sub-controllers. + The three chip select regions are defined in 'ranges'. + + clocks: + items: + - description: clock for the memory device bus + - description: main clock of the SMC + + clock-names: + items: + - const: memclk + - const: apb_pclk + + ranges: + minItems: 1 + maxItems: 3 + description: | + Memory bus areas for interacting with the devices. Reflects + the memory layout with four integer values following: + 0 + items: + - description: NAND bank 0 + - description: NOR/SRAM bank 0 + - description: NOR/SRAM bank 1 + + interrupts: true + +patternProperties: + "@[0-3],[a-f0-9]+$": + type: object + description: | + The child device node represents the controller connected to the SMC + bus. The controller can be a NAND controller or a pair of any memory + mapped controllers such as NOR and SRAM controllers. + + properties: + compatible: + description: + Compatible of memory controller. + + reg: + items: + - items: + - description: | + Chip-select ID, as in the parent range property. + minimum: 0 + maximum: 2 + - description: | + Offset of the memory region requested by the device. + - description: | + Length of the memory region requested by the device. + + required: + - compatible + - reg + +required: + - compatible + - reg + - clock-names + - clocks + - "#address-cells" + - "#size-cells" + - ranges + +additionalProperties: false + +examples: + - | + smcc: memory-controller@e000e000 { + compatible = "arm,pl353-smc-r2p1", "arm,primecell"; + reg = <0xe000e000 0x0001000>; + clock-names = "memclk", "apb_pclk"; + clocks = <&clkc 11>, <&clkc 44>; + ranges = <0x0 0x0 0xe1000000 0x1000000 /* Nand CS region */ + 0x1 0x0 0xe2000000 0x2000000 /* SRAM/NOR CS0 region */ + 0x2 0x0 0xe4000000 0x2000000>; /* SRAM/NOR CS1 region */ + #address-cells = <2>; + #size-cells = <1>; + + nfc0: nand-controller@0,0 { + compatible = "arm,pl353-nand-r2p1"; + reg = <0 0 0x1000000>; + #address-cells = <1>; + #size-cells = <0>; + }; + }; diff --git a/Documentation/devicetree/bindings/memory-controllers/pl353-smc.txt b/Documentation/devicetree/bindings/memory-controllers/pl353-smc.txt deleted file mode 100644 index ecd46856f139..000000000000 --- a/Documentation/devicetree/bindings/memory-controllers/pl353-smc.txt +++ /dev/null @@ -1,44 +0,0 @@ -Device tree bindings for ARM PL353 static memory controller - -PL353 Static Memory Controller is a bus where you can connect two kinds -of memory interfaces: NAND and memory mapped interfaces (such as SRAM or NOR). - -Required properties: -- compatible : Should be "arm,pl353-smc-r2p1", "arm,primecell". -- reg : Controller registers map and length. -- clock-names : List of input clock names - "memclk", "apb_pclk" - (See clock bindings for details). -- clocks : Clock phandles (see clock bindings for details). -- address-cells : Must be 2. -- size-cells : Must be 1. -- ranges : Memory bus areas for interacting with the devices. - Encodes CS to memory region association. - -The child device node represents the controller connected to the SMC -bus. Only one between: NAND controller, NOR controller and SRAM controller -is allowed in a single system. - -Required device node properties: - -- reg: Contains the chip-select id, the offset and the length - of the memory region requested by the device. - -Example: - smcc: memory-controller@e000e000 { - compatible = "arm,pl353-smc-r2p1", "arm,primecell"; - clock-names = "memclk", "apb_pclk"; - clocks = <&clkc 11>, <&clkc 44>; - reg = <0xe000e000 0x1000>; - #address-cells = <2>; - #size-cells = <1>; - ranges = <0x0 0x0 0xe1000000 0x1000000 /* Nand CS region */ - 0x1 0x0 0xe2000000 0x2000000 /* SRAM/NOR CS0 region */ - 0x2 0x0 0xe4000000 0x2000000>; /* SRAM/NOR CS1 region */ - - nfc0: nand-controller@0,0 { - compatible = "arm,pl353-nand-r2p1"; - reg = <0 0 0x1000000>; - #address-cells = <1>; - #size-cells = <0>; - }; - }; -- cgit v1.2.3 From 810e4441946ca17542db334bbcb579e84177b299 Mon Sep 17 00:00:00 2001 From: Jamin Lin Date: Thu, 3 Jun 2021 10:48:19 +0800 Subject: dt-bindings: aspeed-i2c: Convert txt to yaml format Convert aspeed i2c to yaml. Signed-off-by: Jamin Lin Link: https://lore.kernel.org/r/20210603024839.27976-2-jamin_lin@aspeedtech.com Signed-off-by: Rob Herring --- .../devicetree/bindings/i2c/aspeed,i2c.yaml | 75 ++++++++++++++++++++++ .../devicetree/bindings/i2c/i2c-aspeed.txt | 49 -------------- 2 files changed, 75 insertions(+), 49 deletions(-) create mode 100644 Documentation/devicetree/bindings/i2c/aspeed,i2c.yaml delete mode 100644 Documentation/devicetree/bindings/i2c/i2c-aspeed.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/i2c/aspeed,i2c.yaml b/Documentation/devicetree/bindings/i2c/aspeed,i2c.yaml new file mode 100644 index 000000000000..9a40605c3433 --- /dev/null +++ b/Documentation/devicetree/bindings/i2c/aspeed,i2c.yaml @@ -0,0 +1,75 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/i2c/aspeed,i2c.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: ASPEED I2C on the AST24XX, AST25XX, and AST26XX SoCs Device Tree Bindings + +maintainers: + - Rayn Chen + +allOf: + - $ref: /schemas/i2c/i2c-controller.yaml# + +properties: + compatible: + enum: + - aspeed,ast2400-i2c-bus + - aspeed,ast2500-i2c-bus + - aspeed,ast2600-i2c-bus + + reg: + minItems: 1 + maxItems: 2 + items: + - description: address offset and range of bus + - description: address offset and range of bus buffer + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + description: + root clock of bus, should reference the APB + clock in the second cell + + resets: + maxItems: 1 + + bus-frequency: + minimum: 500 + maximum: 4000000 + default: 100000 + description: frequency of the bus clock in Hz defaults to 100 kHz when not + specified + + multi-master: + type: boolean + description: + states that there is another master active on this bus + +required: + - reg + - compatible + - clocks + - resets + +unevaluatedProperties: false + +examples: + - | + #include + i2c0: i2c-bus@40 { + #address-cells = <1>; + #size-cells = <0>; + #interrupt-cells = <1>; + compatible = "aspeed,ast2500-i2c-bus"; + reg = <0x40 0x40>; + clocks = <&syscon ASPEED_CLK_APB>; + resets = <&syscon ASPEED_RESET_I2C>; + bus-frequency = <100000>; + interrupts = <0>; + interrupt-parent = <&i2c_ic>; + }; diff --git a/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt b/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt deleted file mode 100644 index b47f6ccb196a..000000000000 --- a/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt +++ /dev/null @@ -1,49 +0,0 @@ -Device tree configuration for the I2C busses on the AST24XX, AST25XX, and AST26XX SoCs. - -Required Properties: -- #address-cells : should be 1 -- #size-cells : should be 0 -- reg : address offset and range of bus -- compatible : should be "aspeed,ast2400-i2c-bus" - or "aspeed,ast2500-i2c-bus" - or "aspeed,ast2600-i2c-bus" -- clocks : root clock of bus, should reference the APB - clock in the second cell -- resets : phandle to reset controller with the reset number in - the second cell -- interrupts : interrupt number - -Optional Properties: -- bus-frequency : frequency of the bus clock in Hz defaults to 100 kHz when not - specified -- multi-master : states that there is another master active on this bus. - -Example: - -i2c { - compatible = "simple-bus"; - #address-cells = <1>; - #size-cells = <1>; - ranges = <0 0x1e78a000 0x1000>; - - i2c_ic: interrupt-controller@0 { - #interrupt-cells = <1>; - compatible = "aspeed,ast2400-i2c-ic"; - reg = <0x0 0x40>; - interrupts = <12>; - interrupt-controller; - }; - - i2c0: i2c-bus@40 { - #address-cells = <1>; - #size-cells = <0>; - #interrupt-cells = <1>; - reg = <0x40 0x40>; - compatible = "aspeed,ast2400-i2c-bus"; - clocks = <&syscon ASPEED_CLK_APB>; - resets = <&syscon ASPEED_RESET_I2C>; - bus-frequency = <100000>; - interrupts = <0>; - interrupt-parent = <&i2c_ic>; - }; -}; -- cgit v1.2.3 From 4287861dca9d77490ee50de42aa3ada92da86c9d Mon Sep 17 00:00:00 2001 From: Thierry Reding Date: Thu, 3 Jun 2021 18:46:25 +0200 Subject: dt-bindings: arm-smmu: Add Tegra186 compatible string The ARM SMMU instantiations found on Tegra186 and later need inter- operation with the memory controller in order to correctly program stream ID overrides. Furthermore, on Tegra194 multiple instances of the SMMU can gang up to achieve higher throughput. In order to do this, they have to be programmed identically so that the memory controller can interleave memory accesses between them. Add the Tegra186 compatible string to make sure the interoperation with the memory controller can be enabled on that SoC generation. Signed-off-by: Thierry Reding Link: https://lore.kernel.org/r/20210603164632.1000458-3-thierry.reding@gmail.com Signed-off-by: Krzysztof Kozlowski --- Documentation/devicetree/bindings/iommu/arm,smmu.yaml | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml index 9d27aa5111d4..1181b590db71 100644 --- a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml +++ b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml @@ -54,8 +54,14 @@ properties: - const: arm,mmu-500 - description: NVIDIA SoCs that program two ARM MMU-500s identically items: + - description: NVIDIA SoCs that require memory controller interaction + and may program multiple ARM MMU-500s identically with the memory + controller interleaving translations between multiple instances + for improved performance. + items: - enum: - - nvidia,tegra194-smmu + - const: nvidia,tegra194-smmu + - const: nvidia,tegra186-smmu - const: nvidia,smmu-500 - items: - const: arm,mmu-500 @@ -165,10 +171,11 @@ allOf: contains: enum: - nvidia,tegra194-smmu + - nvidia,tegra186-smmu then: properties: reg: - minItems: 2 + minItems: 1 maxItems: 2 else: properties: -- cgit v1.2.3 From 124d77c22c6183c76aa4bb71c29ee0c842562a5f Mon Sep 17 00:00:00 2001 From: Corentin Labbe Date: Tue, 1 Jun 2021 15:11:28 +0000 Subject: dt-bindings: crypto: Add documentation for sl3516-ce This patch adds documentation for Device-Tree bindings for the SL3516-ce cryptographic offloader driver. Reviewed-by: Linus Walleij Reviewed-by: Rob Herring Signed-off-by: Corentin Labbe Signed-off-by: Herbert Xu --- .../bindings/crypto/cortina,sl3516-crypto.yaml | 50 ++++++++++++++++++++++ 1 file changed, 50 insertions(+) create mode 100644 Documentation/devicetree/bindings/crypto/cortina,sl3516-crypto.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/crypto/cortina,sl3516-crypto.yaml b/Documentation/devicetree/bindings/crypto/cortina,sl3516-crypto.yaml new file mode 100644 index 000000000000..b633b8d0e6f0 --- /dev/null +++ b/Documentation/devicetree/bindings/crypto/cortina,sl3516-crypto.yaml @@ -0,0 +1,50 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/crypto/cortina,sl3516-crypto.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: SL3516 cryptographic offloader driver + +maintainers: + - Corentin Labbe + +properties: + compatible: + enum: + - cortina,sl3516-crypto + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + + resets: + maxItems: 1 + +required: + - compatible + - reg + - interrupts + - clocks + - resets + +additionalProperties: false + +examples: + - | + #include + #include + #include + + crypto@62000000 { + compatible = "cortina,sl3516-crypto"; + reg = <0x62000000 0x10000>; + interrupts = <7 IRQ_TYPE_EDGE_RISING>; + resets = <&syscon GEMINI_RESET_SECURITY>; + clocks = <&syscon GEMINI_CLK_GATE_SECURITY>; + }; -- cgit v1.2.3 From fd307a4ad332ef50be5569c92490219e7cd84ce5 Mon Sep 17 00:00:00 2001 From: Jiri Prchal Date: Fri, 11 Jun 2021 11:45:58 +0200 Subject: nvmem: prepare basics for FRAM support Added enum and string for FRAM (ferroelectric RAM) to expose it as file named "fram". Added documentation of sysfs file. Signed-off-by: Jiri Prchal Link: https://lore.kernel.org/r/20210611094601.95131-2-jiri.prchal@aksignal.cz Signed-off-by: Greg Kroah-Hartman --- Documentation/ABI/testing/sysfs-class-spi-eeprom | 19 +++++++++++++ Documentation/devicetree/bindings/eeprom/at25.yaml | 31 +++++++++++++++++----- 2 files changed, 44 insertions(+), 6 deletions(-) create mode 100644 Documentation/ABI/testing/sysfs-class-spi-eeprom (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-class-spi-eeprom b/Documentation/ABI/testing/sysfs-class-spi-eeprom new file mode 100644 index 000000000000..1ff757982079 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-class-spi-eeprom @@ -0,0 +1,19 @@ +What: /sys/class/spi_master/spi/spi./fram +Date: June 2021 +KernelVersion: 5.14 +Contact: Jiri Prchal +Description: + Contains the FRAM binary data. Same as EEPROM, just another file + name to indicate that it employs ferroelectric process. + It performs write operations at bus speed - no write delays. + +What: /sys/class/spi_master/spi/spi./sernum +Date: May 2021 +KernelVersion: 5.14 +Contact: Jiri Prchal +Description: + Contains the serial number of the Cypress FRAM (FM25VN) if it is + present. It will be displayed as a 8 byte hex string, as read + from the device. + + This is a read-only attribute. diff --git a/Documentation/devicetree/bindings/eeprom/at25.yaml b/Documentation/devicetree/bindings/eeprom/at25.yaml index 6a2dc8b3ed14..fbf99e346966 100644 --- a/Documentation/devicetree/bindings/eeprom/at25.yaml +++ b/Documentation/devicetree/bindings/eeprom/at25.yaml @@ -4,14 +4,16 @@ $id: "http://devicetree.org/schemas/eeprom/at25.yaml#" $schema: "http://devicetree.org/meta-schemas/core.yaml#" -title: SPI EEPROMs compatible with Atmel's AT25 +title: SPI EEPROMs or FRAMs compatible with Atmel's AT25 maintainers: - Christian Eggers properties: $nodename: - pattern: "^eeprom@[0-9a-f]{1,2}$" + anyOf: + - pattern: "^eeprom@[0-9a-f]{1,2}$" + - pattern: "^fram@[0-9a-f]{1,2}$" # There are multiple known vendors who manufacture EEPROM chips compatible # with Atmel's AT25. The compatible string requires two items where the @@ -31,6 +33,7 @@ properties: - microchip,25lc040 - st,m95m02 - st,m95256 + - cypress,fm25 - const: atmel,at25 @@ -47,7 +50,7 @@ properties: $ref: /schemas/types.yaml#/definitions/uint32 enum: [1, 8, 16, 32, 64, 128, 256, 512, 1024, 2048, 4096, 8192, 16384, 32768, 65536, 131072] description: - Size of the eeprom page. + Size of the eeprom page. FRAMs don't have pages. size: $ref: /schemas/types.yaml#/definitions/uint32 @@ -100,9 +103,19 @@ required: - compatible - reg - spi-max-frequency - - pagesize - - size - - address-width + +allOf: + - if: + properties: + compatible: + not: + contains: + const: cypress,fm25 + then: + required: + - pagesize + - size + - address-width additionalProperties: false @@ -125,4 +138,10 @@ examples: size = <32768>; address-width = <16>; }; + + fram@1 { + compatible = "cypress,fm25", "atmel,at25"; + reg = <1>; + spi-max-frequency = <40000000>; + }; }; -- cgit v1.2.3 From 4e08a559a18c1b6424e56859c74adb4b29c17318 Mon Sep 17 00:00:00 2001 From: Lad Prabhakar Date: Wed, 9 Jun 2021 16:51:08 +0100 Subject: dt-bindings: interrupt-controller: arm,gic-v3: Describe GICv3 optional properties Describe the optional GICv3 properties: - clocks - clock-names - power-domains - resets Signed-off-by: Lad Prabhakar Reviewed-by: Biju Das Reviewed-by: Geert Uytterhoeven Signed-off-by: Marc Zyngier Link: https://lore.kernel.org/r/20210609155108.16590-1-prabhakar.mahadev-lad.rj@bp.renesas.com --- .../bindings/interrupt-controller/arm,gic-v3.yaml | 13 +++++++++++++ 1 file changed, 13 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml b/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml index 1ecd1831cf02..c84f9fe7f254 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml +++ b/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml @@ -145,6 +145,19 @@ properties: required: - affinity + clocks: + maxItems: 1 + + clock-names: + items: + - const: aclk + + power-domains: + maxItems: 1 + + resets: + maxItems: 1 + dependencies: mbi-ranges: [ msi-controller ] msi-controller: [ mbi-ranges ] -- cgit v1.2.3 From 154ae8bb3c830f0a568a5194ce7e631aa6bcfe8b Mon Sep 17 00:00:00 2001 From: "Rafael J. Wysocki" Date: Wed, 2 Jun 2021 20:18:02 +0200 Subject: cpuidle: teo: Use kerneldoc documentation in admin-guide There are two descriptions of the TEO (Timer Events Oriented) cpuidle governor in the kernel source tree, one in the C file containing its code and one in cpuidle.rst which is part of admin-guide. Instead of trying to keep them both in sync and in order to reduce text duplication, include the governor description from the C file directly into cpuidle.rst. Signed-off-by: Rafael J. Wysocki --- Documentation/admin-guide/pm/cpuidle.rst | 77 +------------------------------- 1 file changed, 2 insertions(+), 75 deletions(-) (limited to 'Documentation') diff --git a/Documentation/admin-guide/pm/cpuidle.rst b/Documentation/admin-guide/pm/cpuidle.rst index 10fde58d0869..aec2cd2aaea7 100644 --- a/Documentation/admin-guide/pm/cpuidle.rst +++ b/Documentation/admin-guide/pm/cpuidle.rst @@ -347,81 +347,8 @@ for tickless systems. It follows the same basic strategy as the ``menu`` `one `_: it always tries to find the deepest idle state suitable for the given conditions. However, it applies a different approach to that problem. -First, it does not use sleep length correction factors, but instead it attempts -to correlate the observed idle duration values with the available idle states -and use that information to pick up the idle state that is most likely to -"match" the upcoming CPU idle interval. Second, it does not take the tasks -that were running on the given CPU in the past and are waiting on some I/O -operations to complete now at all (there is no guarantee that they will run on -the same CPU when they become runnable again) and the pattern detection code in -it avoids taking timer wakeups into account. It also only uses idle duration -values less than the current time till the closest timer (with the scheduler -tick excluded) for that purpose. - -Like in the ``menu`` governor `case `_, the first step is to obtain -the *sleep length*, which is the time until the closest timer event with the -assumption that the scheduler tick will be stopped (that also is the upper bound -on the time until the next CPU wakeup). That value is then used to preselect an -idle state on the basis of three metrics maintained for each idle state provided -by the ``CPUIdle`` driver: ``hits``, ``misses`` and ``early_hits``. - -The ``hits`` and ``misses`` metrics measure the likelihood that a given idle -state will "match" the observed (post-wakeup) idle duration if it "matches" the -sleep length. They both are subject to decay (after a CPU wakeup) every time -the target residency of the idle state corresponding to them is less than or -equal to the sleep length and the target residency of the next idle state is -greater than the sleep length (that is, when the idle state corresponding to -them "matches" the sleep length). The ``hits`` metric is increased if the -former condition is satisfied and the target residency of the given idle state -is less than or equal to the observed idle duration and the target residency of -the next idle state is greater than the observed idle duration at the same time -(that is, it is increased when the given idle state "matches" both the sleep -length and the observed idle duration). In turn, the ``misses`` metric is -increased when the given idle state "matches" the sleep length only and the -observed idle duration is too short for its target residency. - -The ``early_hits`` metric measures the likelihood that a given idle state will -"match" the observed (post-wakeup) idle duration if it does not "match" the -sleep length. It is subject to decay on every CPU wakeup and it is increased -when the idle state corresponding to it "matches" the observed (post-wakeup) -idle duration and the target residency of the next idle state is less than or -equal to the sleep length (i.e. the idle state "matching" the sleep length is -deeper than the given one). - -The governor walks the list of idle states provided by the ``CPUIdle`` driver -and finds the last (deepest) one with the target residency less than or equal -to the sleep length. Then, the ``hits`` and ``misses`` metrics of that idle -state are compared with each other and it is preselected if the ``hits`` one is -greater (which means that that idle state is likely to "match" the observed idle -duration after CPU wakeup). If the ``misses`` one is greater, the governor -preselects the shallower idle state with the maximum ``early_hits`` metric -(or if there are multiple shallower idle states with equal ``early_hits`` -metric which also is the maximum, the shallowest of them will be preselected). -[If there is a wakeup latency constraint coming from the `PM QoS framework -`_ which is hit before reaching the deepest idle state with the -target residency within the sleep length, the deepest idle state with the exit -latency within the constraint is preselected without consulting the ``hits``, -``misses`` and ``early_hits`` metrics.] - -Next, the governor takes several idle duration values observed most recently -into consideration and if at least a half of them are greater than or equal to -the target residency of the preselected idle state, that idle state becomes the -final candidate to ask for. Otherwise, the average of the most recent idle -duration values below the target residency of the preselected idle state is -computed and the governor walks the idle states shallower than the preselected -one and finds the deepest of them with the target residency within that average. -That idle state is then taken as the final candidate to ask for. - -Still, at this point the governor may need to refine the idle state selection if -it has not decided to `stop the scheduler tick `_. That -generally happens if the target residency of the idle state selected so far is -less than the tick period and the tick has not been stopped already (in a -previous iteration of the idle loop). Then, like in the ``menu`` governor -`case `_, the sleep length used in the previous computations may not -reflect the real time until the closest timer event and if it really is greater -than that time, a shallower state with a suitable target residency may need to -be selected. - +.. kernel-doc:: drivers/cpuidle/governors/teo.c + :doc: teo-description .. _idle-states-representation: -- cgit v1.2.3 From 4ec4f059088b48585c337328e05fa930c64d1ba8 Mon Sep 17 00:00:00 2001 From: Ulf Hansson Date: Wed, 9 Jun 2021 12:06:10 +0200 Subject: PM: runtime: Clarify documentation when callbacks are unassigned Recent changes to the PM core allows ->runtime_suspend|resume callbacks to be unassigned. In the earlier behaviour the PM core would return -ENOSYS, when trying to runtime resume a device, for example. Let's update the documentation to clarify this. Signed-off-by: Ulf Hansson Acked-by: Alan Stern Signed-off-by: Rafael J. Wysocki --- Documentation/power/runtime_pm.rst | 9 +++++++++ 1 file changed, 9 insertions(+) (limited to 'Documentation') diff --git a/Documentation/power/runtime_pm.rst b/Documentation/power/runtime_pm.rst index b48cac5f9048..d6bf84f061f4 100644 --- a/Documentation/power/runtime_pm.rst +++ b/Documentation/power/runtime_pm.rst @@ -831,6 +831,15 @@ or driver about runtime power changes. Instead, the driver for the device's parent must take responsibility for telling the device's driver when the parent's power state changes. +Note that, in some cases it may not be desirable for subsystems/drivers to call +pm_runtime_no_callbacks() for their devices. This could be because a subset of +the runtime PM callbacks needs to be implemented, a platform dependent PM +domain could get attached to the device or that the device is power managed +through a supplier device link. For these reasons and to avoid boilerplate code +in subsystems/drivers, the PM core allows runtime PM callbacks to be +unassigned. More precisely, if a callback pointer is NULL, the PM core will act +as though there was a callback and it returned 0. + 9. Autosuspend, or automatically-delayed suspends ================================================= -- cgit v1.2.3 From 9fd795eab2dbe90ee21cb3774892ba9a7ec73ff4 Mon Sep 17 00:00:00 2001 From: Heiko Schocher Date: Mon, 7 Jun 2021 05:39:08 +0200 Subject: mtd: devices: add devicetree documentation for microchip 48l640 The Microchip 48l640 is a 8KByte EERAM connected via SPI. Add devicetree bindings documentation. Reviewed-by: Rob Herring Signed-off-by: Heiko Schocher Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20210607033909.1424605-2-hs@denx.de --- .../bindings/mtd/microchip,mchp48l640.yaml | 45 ++++++++++++++++++++++ 1 file changed, 45 insertions(+) create mode 100644 Documentation/devicetree/bindings/mtd/microchip,mchp48l640.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mtd/microchip,mchp48l640.yaml b/Documentation/devicetree/bindings/mtd/microchip,mchp48l640.yaml new file mode 100644 index 000000000000..2cdf6bf3dc4a --- /dev/null +++ b/Documentation/devicetree/bindings/mtd/microchip,mchp48l640.yaml @@ -0,0 +1,45 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/mtd/microchip,mchp48l640.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: Microchip 48l640 (and similar) serial EERAM bindings + +maintainers: + - Heiko Schocher + +description: | + The Microchip 48l640 is a 8KByte EERAM connected via SPI. + + datasheet: http://ww1.microchip.com/downloads/en/DeviceDoc/20006055B.pdf + +properties: + compatible: + items: + - const: microchip,48l640 + + reg: + maxItems: 1 + + spi-max-frequency: true + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + spi { + #address-cells = <1>; + #size-cells = <0>; + + eeram@0 { + compatible = "microchip,48l640"; + reg = <0>; + spi-max-frequency = <20000000>; + }; + }; +... -- cgit v1.2.3 From 6947ad674944f9e38b229be532a2dddd6a1921ed Mon Sep 17 00:00:00 2001 From: Vignesh Raghavendra Date: Fri, 11 Jun 2021 11:05:33 +0530 Subject: dt-bindings: mtd: Convert ti, am654-hbmc.txt to YAML schema Convert ti,am654-hbmc.txt to YAML schema for better checks and validations of DT. Signed-off-by: Vignesh Raghavendra Reviewed-by: Rob Herring Signed-off-by: Miquel Raynal --- .../devicetree/bindings/mtd/ti,am654-hbmc.txt | 51 ---------------- .../devicetree/bindings/mtd/ti,am654-hbmc.yaml | 69 ++++++++++++++++++++++ 2 files changed, 69 insertions(+), 51 deletions(-) delete mode 100644 Documentation/devicetree/bindings/mtd/ti,am654-hbmc.txt create mode 100644 Documentation/devicetree/bindings/mtd/ti,am654-hbmc.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mtd/ti,am654-hbmc.txt b/Documentation/devicetree/bindings/mtd/ti,am654-hbmc.txt deleted file mode 100644 index faa81c2e5da6..000000000000 --- a/Documentation/devicetree/bindings/mtd/ti,am654-hbmc.txt +++ /dev/null @@ -1,51 +0,0 @@ -Bindings for HyperBus Memory Controller (HBMC) on TI's K3 family of SoCs - -Required properties: -- compatible : "ti,am654-hbmc" for AM654 SoC -- reg : Two entries: - First entry pointed to the register space of HBMC controller - Second entry pointing to the memory map region dedicated for - MMIO access to attached flash devices -- ranges : Address translation from offset within CS to allocated MMIO - space in SoC - -Optional properties: -- mux-controls : phandle to the multiplexer that controls selection of - HBMC vs OSPI inside Flash SubSystem (FSS). Default is OSPI, - if property is absent. - See Documentation/devicetree/bindings/mux/reg-mux.txt - for mmio-mux binding details - -Example: - - system-controller@47000000 { - compatible = "syscon", "simple-mfd"; - reg = <0x0 0x47000000 0x0 0x100>; - #address-cells = <2>; - #size-cells = <2>; - ranges; - - hbmc_mux: multiplexer { - compatible = "mmio-mux"; - #mux-control-cells = <1>; - mux-reg-masks = <0x4 0x2>; /* 0: reg 0x4, bit 1 */ - }; - }; - - hbmc: hyperbus@47034000 { - compatible = "ti,am654-hbmc"; - reg = <0x0 0x47034000 0x0 0x100>, - <0x5 0x00000000 0x1 0x0000000>; - power-domains = <&k3_pds 55>; - #address-cells = <2>; - #size-cells = <1>; - ranges = <0x0 0x0 0x5 0x00000000 0x4000000>, /* CS0 - 64MB */ - <0x1 0x0 0x5 0x04000000 0x4000000>; /* CS1 - 64MB */ - mux-controls = <&hbmc_mux 0>; - - /* Slave flash node */ - flash@0,0 { - compatible = "cypress,hyperflash", "cfi-flash"; - reg = <0x0 0x0 0x4000000>; - }; - }; diff --git a/Documentation/devicetree/bindings/mtd/ti,am654-hbmc.yaml b/Documentation/devicetree/bindings/mtd/ti,am654-hbmc.yaml new file mode 100644 index 000000000000..30b458c41cac --- /dev/null +++ b/Documentation/devicetree/bindings/mtd/ti,am654-hbmc.yaml @@ -0,0 +1,69 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mtd/ti,am654-hbmc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: HyperBus Memory Controller (HBMC) on TI's K3 family of SoCs + +maintainers: + - Vignesh Raghavendra + +properties: + compatible: + const: ti,am654-hbmc + + reg: + maxItems: 2 + + power-domains: true + '#address-cells': true + '#size-cells': true + ranges: true + + mux-controls: + description: MMIO mux controller node to select b/w OSPI and HBMC. + + clocks: + maxItems: 1 + +patternProperties: + "^flash@[0-1],[0-9a-f]+$": + type: object + +required: + - compatible + - reg + - ranges + - clocks + - '#address-cells' + - '#size-cells' + +additionalProperties: false + +examples: + - | + bus { + #address-cells = <2>; + #size-cells = <2>; + + hbmc: memory-controller@47034000 { + compatible = "ti,am654-hbmc"; + reg = <0x0 0x47034000 0x0 0x100>, + <0x5 0x00000000 0x1 0x0000000>; + ranges = <0x0 0x0 0x5 0x00000000 0x4000000>, /* CS0 - 64MB */ + <0x1 0x0 0x5 0x04000000 0x4000000>; /* CS1 - 64MB */ + clocks = <&k3_clks 102 0>; + #address-cells = <2>; + #size-cells = <1>; + power-domains = <&k3_pds 55>; + mux-controls = <&hbmc_mux 0>; + + flash@0,0 { + compatible = "cypress,hyperflash", "cfi-flash"; + reg = <0x0 0x0 0x4000000>; + #address-cells = <1>; + #size-cells = <1>; + }; + }; + }; -- cgit v1.2.3 From 557acb5ffd458dbd76c84b2caa303dfd113d50c7 Mon Sep 17 00:00:00 2001 From: Douglas Anderson Date: Fri, 11 Jun 2021 10:17:37 -0700 Subject: dt-bindings: display: simple: List hpd properties in panel-simple The HPD (Hot Plug Detect) signal is present in many (probably even "most") eDP panels. For eDP, this signal isn't actually used for detecting hot-plugs of the panel but is more akin to a "panel ready" signal. After you provide power to the panel, panel timing diagrams typically say that you should wait for HPD to be asserted (or wait a fixed amount of time) before talking to the panel. The panel-simple bindings describes many eDP panels and many of these panels provide the HPD signal. We should add the HPD-related properties to the panel-simple bindings. The HPD properties are actually defined in panel-common.yaml, so adding them here just documents that they are OK for panels handled by the panel-simple bindings. NOTE: whether or not we'd include HPD properties in the panel node is more a property of the board design than the panel itself. For most boards using these eDP panels everything "magically" works without specifying any HPD properties and that's been why we haven't needed to allow the HPD properties earlier. On these boards the HPD signal goes directly to a dedicated "HPD" input to the eDP controller and this connection doesn't need to be described in the device tree. The only time the HPD properties are needed in the device tree are if HPD is hooked up to a GPIO or if HPD is normally on the panel but isn't used on a given board. That means that if we don't allow the HPD properties in panel-simple then one could argue that we've got to boot all eDP panels (or at least all those that someone could conceivably put on a system where HPD goes to a GPIO or isn't hooked up) from panel-simple. Signed-off-by: Douglas Anderson Reviewed-by: Rob Herring Link: https://patchwork.freedesktop.org/patch/msgid/20210611101711.v10.1.Ieb731d23680db4700cc41fe51ccc73ba0b785fb7@changeid --- Documentation/devicetree/bindings/display/panel/panel-simple.yaml | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml index b3797ba2698b..4a0a5e1ee252 100644 --- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml +++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml @@ -298,6 +298,8 @@ properties: enable-gpios: true port: true power-supply: true + no-hpd: true + hpd-gpios: true additionalProperties: false -- cgit v1.2.3 From feac44bad7d7bcbac3f91bc38392e94133813ac8 Mon Sep 17 00:00:00 2001 From: Douglas Anderson Date: Fri, 11 Jun 2021 10:17:38 -0700 Subject: dt-bindings: drm: Introduce the DP AUX bus We want to be able to list an eDP panel as a child of an eDP controller node to represent the fact that the panel is connected to the controller's DP AUX bus. Though the panel and the controller are connected in several ways, the DP AUX bus is the primary control interface between the two and thus makes the most sense to model in device tree hierarchy. Listing a panel in this way makes it possible for the panel driver to easily get access to the DP AUX bus that it resides on, which can be useful to help in auto-detecting the panel and for turning on various bits. NOTE: historically eDP panels were _not_ listed under their controller but were listed at the top level of the device tree. This will still be supported for backward compatibility (and while DP controller drivers are adapted to support the new DT syntax) but should be considered deprecated since there is no downside to listing the panel under the controller. For now, the DP AUX bus bindings will only support an eDP panel underneath. It's possible it could be extended to allow having a DP connector under it in the future. NOTE: there is no "Example" in this bindings file. Yikes! This avoids duplicating the same example lots of places. See users of the aux bus (like ti-sn65dsi86) for examples. The idea for this bus's design was hashed out over IRC [1]. [1] https://people.freedesktop.org/~cbrill/dri-log/?channel=dri-devel&date=2021-05-11 Signed-off-by: Douglas Anderson Reviewed-by: Rob Herring Reviewed-by: Linus Walleij Link: https://patchwork.freedesktop.org/patch/msgid/20210611101711.v10.2.Id3c048d22e72a9f90084a543b5b4e3f43bc9ab62@changeid --- .../devicetree/bindings/display/dp-aux-bus.yaml | 37 ++++++++++++++++++++++ 1 file changed, 37 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/dp-aux-bus.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/dp-aux-bus.yaml b/Documentation/devicetree/bindings/display/dp-aux-bus.yaml new file mode 100644 index 000000000000..5e4afe9f98fb --- /dev/null +++ b/Documentation/devicetree/bindings/display/dp-aux-bus.yaml @@ -0,0 +1,37 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/dp-aux-bus.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: DisplayPort AUX bus + +maintainers: + - Douglas Anderson + +description: + DisplayPort controllers provide a control channel to the sinks that + are hooked up to them. This is the DP AUX bus. Over the DP AUX bus + we can query properties about a sink and also configure it. In + particular, DP sinks support DDC over DP AUX which allows tunneling + a standard I2C DDC connection over the AUX channel. + + To model this relationship, DP sinks should be placed as children + of the DP controller under the "aux-bus" node. + + At the moment, this binding only handles the eDP case. It is + possible it will be extended in the future to handle the DP case. + For DP, presumably a connector would be listed under the DP AUX + bus instead of a panel. + +properties: + $nodename: + const: "aux-bus" + + panel: + $ref: panel/panel-common.yaml# + +additionalProperties: false + +required: + - panel -- cgit v1.2.3 From 476c864dd4655bea0f7aed2845ab18ef47c4bf94 Mon Sep 17 00:00:00 2001 From: Douglas Anderson Date: Fri, 11 Jun 2021 10:17:39 -0700 Subject: dt-bindings: drm/bridge: ti-sn65dsi86: Add aux-bus child The patch ("dt-bindings: drm: Introduce the DP AUX bus") talks about how using the DP AUX bus is better than learning how to slice bread. Let's add it to the ti-sn65dsi86 bindings. Signed-off-by: Douglas Anderson Reviewed-by: Rob Herring Reviewed-by: Linus Walleij Link: https://patchwork.freedesktop.org/patch/msgid/20210611101711.v10.3.I98bf729846c37c4c143f6ab88b1e299280e2fe26@changeid --- .../bindings/display/bridge/ti,sn65dsi86.yaml | 20 +++++++++++++++++++- 1 file changed, 19 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml index 26932d2e86ab..12b876a20574 100644 --- a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml +++ b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml @@ -70,6 +70,9 @@ properties: const: 1 description: See ../../pwm/pwm.yaml for description of the cell formats. + aux-bus: + $ref: /schemas/display/dp-aux-bus.yaml# + ports: $ref: /schemas/graph.yaml#/properties/ports @@ -201,11 +204,26 @@ examples: port@1 { reg = <1>; - endpoint { + sn65dsi86_out: endpoint { remote-endpoint = <&panel_in_edp>; }; }; }; + + aux-bus { + panel { + compatible = "boe,nv133fhm-n62"; + power-supply = <&pp3300_dx_edp>; + backlight = <&backlight>; + hpd-gpios = <&sn65dsi86_bridge 2 GPIO_ACTIVE_HIGH>; + + port { + panel_in_edp: endpoint { + remote-endpoint = <&sn65dsi86_out>; + }; + }; + }; + }; }; }; - | -- cgit v1.2.3 From 4e50025129efabb07714c1f27a80526897da374b Mon Sep 17 00:00:00 2001 From: Vladimir Oltean Date: Fri, 11 Jun 2021 22:01:24 +0300 Subject: net: dsa: generalize overhead for taggers that use both headers and trailers Some really really weird switches just couldn't decide whether to use a normal or a tail tagger, so they just did both. This creates problems for DSA, because we only have the concept of an 'overhead' which can be applied to the headroom or to the tailroom of the skb (like for example during the central TX reallocation procedure), depending on the value of bool tail_tag, but not to both. We need to generalize DSA to cater for these odd switches by transforming the 'overhead / tail_tag' pair into 'needed_headroom / needed_tailroom'. The DSA master's MTU is increased to account for both. The flow dissector code is modified such that it only calls the DSA adjustment callback if the tagger has a non-zero header length. Taggers are trivially modified to declare either needed_headroom or needed_tailroom, based on the tail_tag value that they currently declare. Signed-off-by: Vladimir Oltean Signed-off-by: David S. Miller --- Documentation/networking/dsa/dsa.rst | 21 +++++++++++---------- 1 file changed, 11 insertions(+), 10 deletions(-) (limited to 'Documentation') diff --git a/Documentation/networking/dsa/dsa.rst b/Documentation/networking/dsa/dsa.rst index 8688009514cc..20baacf2bc5c 100644 --- a/Documentation/networking/dsa/dsa.rst +++ b/Documentation/networking/dsa/dsa.rst @@ -93,14 +93,15 @@ A tagging protocol may tag all packets with switch tags of the same length, or the tag length might vary (for example packets with PTP timestamps might require an extended switch tag, or there might be one tag length on TX and a different one on RX). Either way, the tagging protocol driver must populate the -``struct dsa_device_ops::overhead`` with the length in octets of the longest -switch frame header. The DSA framework will automatically adjust the MTU of the -master interface to accomodate for this extra size in order for DSA user ports -to support the standard MTU (L2 payload length) of 1500 octets. The ``overhead`` -is also used to request from the network stack, on a best-effort basis, the -allocation of packets with a ``needed_headroom`` or ``needed_tailroom`` -sufficient such that the act of pushing the switch tag on transmission of a -packet does not cause it to reallocate due to lack of memory. +``struct dsa_device_ops::needed_headroom`` and/or ``struct dsa_device_ops::needed_tailroom`` +with the length in octets of the longest switch frame header/trailer. The DSA +framework will automatically adjust the MTU of the master interface to +accommodate for this extra size in order for DSA user ports to support the +standard MTU (L2 payload length) of 1500 octets. The ``needed_headroom`` and +``needed_tailroom`` properties are also used to request from the network stack, +on a best-effort basis, the allocation of packets with enough extra space such +that the act of pushing the switch tag on transmission of a packet does not +cause it to reallocate due to lack of memory. Even though applications are not expected to parse DSA-specific frame headers, the format on the wire of the tagging protocol represents an Application Binary @@ -169,8 +170,8 @@ The job of this method is to prepare the skb in a way that the switch will understand what egress port the packet is for (and not deliver it towards other ports). Typically this is fulfilled by pushing a frame header. Checking for insufficient size in the skb headroom or tailroom is unnecessary provided that -the ``overhead`` and ``tail_tag`` properties were filled out properly, because -DSA ensures there is enough space before calling this method. +the ``needed_headroom`` and ``needed_tailroom`` properties were filled out +properly, because DSA ensures there is enough space before calling this method. The reception of a packet goes through the tagger's ``rcv`` function. The passed ``struct sk_buff *skb`` has ``skb->data`` pointing at -- cgit v1.2.3 From e71305acd81cac222c41849e538c5c661b12c584 Mon Sep 17 00:00:00 2001 From: Calvin Johnson Date: Fri, 11 Jun 2021 13:53:47 +0300 Subject: Documentation: ACPI: DSD: Document MDIO PHY Introduce a mechanism based on generic ACPI _DSD device properties definition [1] to get PHYs registered on a MDIO bus and provide them to be connected to MAC. [1] http://www.uefi.org/sites/default/files/resources/_DSD-device-properties-UUID.pdf Describe properties "phy-handle" and "phy-mode". Signed-off-by: Calvin Johnson Signed-off-by: Ioana Ciornei Acked-by: Rafael J. Wysocki Acked-by: Grant Likely Signed-off-by: David S. Miller --- Documentation/firmware-guide/acpi/dsd/phy.rst | 133 ++++++++++++++++++++++++++ 1 file changed, 133 insertions(+) create mode 100644 Documentation/firmware-guide/acpi/dsd/phy.rst (limited to 'Documentation') diff --git a/Documentation/firmware-guide/acpi/dsd/phy.rst b/Documentation/firmware-guide/acpi/dsd/phy.rst new file mode 100644 index 000000000000..7d01ae8b3cc6 --- /dev/null +++ b/Documentation/firmware-guide/acpi/dsd/phy.rst @@ -0,0 +1,133 @@ +.. SPDX-License-Identifier: GPL-2.0 + +========================= +MDIO bus and PHYs in ACPI +========================= + +The PHYs on an MDIO bus [1] are probed and registered using +fwnode_mdiobus_register_phy(). + +Later, for connecting these PHYs to their respective MACs, the PHYs registered +on the MDIO bus have to be referenced. + +This document introduces two _DSD properties that are to be used +for connecting PHYs on the MDIO bus [3] to the MAC layer. + +These properties are defined in accordance with the "Device +Properties UUID For _DSD" [2] document and the +daffd814-6eba-4d8c-8a91-bc9bbf4aa301 UUID must be used in the Device +Data Descriptors containing them. + +phy-handle +---------- +For each MAC node, a device property "phy-handle" is used to reference +the PHY that is registered on an MDIO bus. This is mandatory for +network interfaces that have PHYs connected to MAC via MDIO bus. + +During the MDIO bus driver initialization, PHYs on this bus are probed +using the _ADR object as shown below and are registered on the MDIO bus. + +:: + Scope(\_SB.MDI0) + { + Device(PHY1) { + Name (_ADR, 0x1) + } // end of PHY1 + + Device(PHY2) { + Name (_ADR, 0x2) + } // end of PHY2 + } + +Later, during the MAC driver initialization, the registered PHY devices +have to be retrieved from the MDIO bus. For this, the MAC driver needs +references to the previously registered PHYs which are provided +as device object references (e.g. \_SB.MDI0.PHY1). + +phy-mode +-------- +The "phy-mode" _DSD property is used to describe the connection to +the PHY. The valid values for "phy-mode" are defined in [4]. + +The following ASL example illustrates the usage of these properties. + +DSDT entry for MDIO node +------------------------ + +The MDIO bus has an SoC component (MDIO controller) and a platform +component (PHYs on the MDIO bus). + +a) Silicon Component +This node describes the MDIO controller, MDI0 +--------------------------------------------- +:: + Scope(_SB) + { + Device(MDI0) { + Name(_HID, "NXP0006") + Name(_CCA, 1) + Name(_UID, 0) + Name(_CRS, ResourceTemplate() { + Memory32Fixed(ReadWrite, MDI0_BASE, MDI_LEN) + Interrupt(ResourceConsumer, Level, ActiveHigh, Shared) + { + MDI0_IT + } + }) // end of _CRS for MDI0 + } // end of MDI0 + } + +b) Platform Component +The PHY1 and PHY2 nodes represent the PHYs connected to MDIO bus MDI0 +--------------------------------------------------------------------- +:: + Scope(\_SB.MDI0) + { + Device(PHY1) { + Name (_ADR, 0x1) + } // end of PHY1 + + Device(PHY2) { + Name (_ADR, 0x2) + } // end of PHY2 + } + +DSDT entries representing MAC nodes +----------------------------------- + +Below are the MAC nodes where PHY nodes are referenced. +phy-mode and phy-handle are used as explained earlier. +------------------------------------------------------ +:: + Scope(\_SB.MCE0.PR17) + { + Name (_DSD, Package () { + ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), + Package () { + Package (2) {"phy-mode", "rgmii-id"}, + Package (2) {"phy-handle", \_SB.MDI0.PHY1} + } + }) + } + + Scope(\_SB.MCE0.PR18) + { + Name (_DSD, Package () { + ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), + Package () { + Package (2) {"phy-mode", "rgmii-id"}, + Package (2) {"phy-handle", \_SB.MDI0.PHY2}} + } + }) + } + +References +========== + +[1] Documentation/networking/phy.rst + +[2] https://www.uefi.org/sites/default/files/resources/_DSD-device-properties-UUID.pdf + +[3] Documentation/firmware-guide/acpi/DSD-properties-rules.rst + +[4] Documentation/devicetree/bindings/net/ethernet-controller.yaml -- cgit v1.2.3 From 2e3cf97f4741b320e8f4639fcca732b17614a55f Mon Sep 17 00:00:00 2001 From: Alex Elder Date: Fri, 11 Jun 2021 15:39:40 -0500 Subject: net: ipa: introduce sysfs code Add IPA device attributes to expose information known by the IPA driver about the hardware and its configuration. All pointers used to display these attribute values (i.e., IPA pointer and endpoint pointers) will have been initialized by the time IPA probe has completed, so they may be safely dereferenced. Signed-off-by: Alex Elder Signed-off-by: David S. Miller --- .../ABI/testing/sysfs-devices-platform-soc-ipa | 78 ++++++++++++++++++++++ 1 file changed, 78 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-devices-platform-soc-ipa (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-devices-platform-soc-ipa b/Documentation/ABI/testing/sysfs-devices-platform-soc-ipa new file mode 100644 index 000000000000..c56dcf15bf29 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-devices-platform-soc-ipa @@ -0,0 +1,78 @@ +What: /sys/devices/platform/soc@X/XXXXXXX.ipa/ +Date: June 2021 +KernelVersion: v5.14 +Contact: Alex Elder +Description: + The /sys/devices/platform/soc@X/XXXXXXX.ipa/ directory + contains read-only attributes exposing information about + an IPA device. The X values could vary, but are typically + "soc@0/1e40000.ipa". + +What: .../XXXXXXX.ipa/version +Date: June 2021 +KernelVersion: v5.14 +Contact: Alex Elder +Description: + The .../XXXXXXX.ipa/version file contains the IPA hardware + version, as a period-separated set of two or three integers + (e.g., "3.5.1" or "4.2"). + +What: .../XXXXXXX.ipa/feature/ +Date: June 2021 +KernelVersion: v5.14 +Contact: Alex Elder +Description: + The .../XXXXXXX.ipa/feature/ directory contains a set of + attributes describing features implemented by the IPA + hardware. + +What: .../XXXXXXX.ipa/feature/rx_offload +Date: June 2021 +KernelVersion: v5.14 +Contact: Alex Elder +Description: + The .../XXXXXXX.ipa/feature/rx_offload file contains a + string indicating the type of receive checksum offload + that is supported by the hardware. The possible values + are "MAPv4" or "MAPv5". + +What: .../XXXXXXX.ipa/feature/tx_offload +Date: June 2021 +KernelVersion: v5.14 +Contact: Alex Elder +Description: + The .../XXXXXXX.ipa/feature/tx_offload file contains a + string indicating the type of transmit checksum offload + that is supported by the hardware. The possible values + are "MAPv4" or "MAPv5". + +What: .../XXXXXXX.ipa/modem/ +Date: June 2021 +KernelVersion: v5.14 +Contact: Alex Elder +Description: + The .../XXXXXXX.ipa/modem/ directory contains a set of + attributes describing properties of the modem execution + environment reachable by the IPA hardware. + +What: .../XXXXXXX.ipa/modem/rx_endpoint_id +Date: June 2021 +KernelVersion: v5.14 +Contact: Alex Elder +Description: + The .../XXXXXXX.ipa/feature/rx_endpoint_id file contains + the AP endpoint ID that receives packets originating from + the modem execution environment. The "rx" is from the + perspective of the AP; this endpoint is considered an "IPA + producer". An endpoint ID is a small unsigned integer. + +What: .../XXXXXXX.ipa/modem/tx_endpoint_id +Date: June 2021 +KernelVersion: v5.14 +Contact: Alex Elder +Description: + The .../XXXXXXX.ipa/feature/tx_endpoint_id file contains + the AP endpoint ID used to transmit packets destined for + the modem execution environment. The "tx" is from the + perspective of the AP; this endpoint is considered an "IPA + consumer". An endpoint ID is a small unsigned integer. -- cgit v1.2.3 From 12ca7a893d543a64130d15c765fc18497b2ea65f Mon Sep 17 00:00:00 2001 From: Brendan Higgins Date: Wed, 26 May 2021 14:24:07 -0700 Subject: Documentation: kunit: document support for QEMU in kunit_tool Document QEMU support, what it does, and how to use it in kunit_tool. Signed-off-by: Brendan Higgins Reviewed-by: David Gow Signed-off-by: Shuah Khan --- Documentation/dev-tools/kunit/kunit-tool.rst | 48 ++++++++++++++++++++++++++ Documentation/dev-tools/kunit/usage.rst | 50 ++++++++++++++++++++++------ 2 files changed, 87 insertions(+), 11 deletions(-) (limited to 'Documentation') diff --git a/Documentation/dev-tools/kunit/kunit-tool.rst b/Documentation/dev-tools/kunit/kunit-tool.rst index 4247b7420e3b..c7ff9afe407a 100644 --- a/Documentation/dev-tools/kunit/kunit-tool.rst +++ b/Documentation/dev-tools/kunit/kunit-tool.rst @@ -145,6 +145,54 @@ to run KUnit resource tests, you could use: This uses the standard glob format for wildcards. +Running Tests on QEMU +===================== + +kunit_tool supports running tests on QEMU as well as via UML (as mentioned +elsewhere). The default way of running tests on QEMU requires two flags: + +``--arch`` + Selects a collection of configs (Kconfig as well as QEMU configs + options, etc) that allow KUnit tests to be run on the specified + architecture in a minimal way; this is usually not much slower than + using UML. The architecture argument is the same as the name of the + option passed to the ``ARCH`` variable used by Kbuild. Not all + architectures are currently supported by this flag, but can be handled + by the ``--qemu_config`` discussed later. If ``um`` is passed (or this + this flag is ignored) the tests will run via UML. Non-UML architectures, + e.g. i386, x86_64, arm, um, etc. Non-UML run on QEMU. + +``--cross_compile`` + Specifies the use of a toolchain by Kbuild. The argument passed here is + the same passed to the ``CROSS_COMPILE`` variable used by Kbuild. As a + reminder this will be the prefix for the toolchain binaries such as gcc + for example ``sparc64-linux-gnu-`` if you have the sparc toolchain + installed on your system, or + ``$HOME/toolchains/microblaze/gcc-9.2.0-nolibc/microblaze-linux/bin/microblaze-linux-`` + if you have downloaded the microblaze toolchain from the 0-day website + to a directory in your home directory called ``toolchains``. + +In many cases it is likely that you may want to run an architecture which is +not supported by the ``--arch`` flag, or you may want to just run KUnit tests +on QEMU using a non-default configuration. For this use case, you can write +your own QemuConfig. These QemuConfigs are written in Python. They must have an +import line ``from ..qemu_config import QemuArchParams`` at the top of the file +and the file must contain a variable called ``QEMU_ARCH`` that has an instance +of ``QemuArchParams`` assigned to it. An example can be seen in +``tools/testing/kunit/qemu_configs/x86_64.py``. + +Once you have a QemuConfig you can pass it into kunit_tool using the +``--qemu_config`` flag; when used this flag replaces the ``--arch`` flag. If we +were to do this with the ``x86_64.py`` example from above, the invocation would +look something like this: + +.. code-block:: bash + + ./tools/testing/kunit/kunit.py run \ + --timeout=60 \ + --jobs=12 \ + --qemu_config=./tools/testing/kunit/qemu_configs/x86_64.py + Other Useful Options ==================== diff --git a/Documentation/dev-tools/kunit/usage.rst b/Documentation/dev-tools/kunit/usage.rst index 650f99590df5..888c341701da 100644 --- a/Documentation/dev-tools/kunit/usage.rst +++ b/Documentation/dev-tools/kunit/usage.rst @@ -609,17 +609,45 @@ non-UML architectures: None of these are reasons not to run your KUnit tests on real hardware; they are only things to be aware of when doing so. -The biggest impediment will likely be that certain KUnit features and -infrastructure may not support your target environment. For example, at this -time the KUnit Wrapper (``tools/testing/kunit/kunit.py``) does not work outside -of UML. Unfortunately, there is no way around this. Using UML (or even just a -particular architecture) allows us to make a lot of assumptions that make it -possible to do things which might otherwise be impossible. - -Nevertheless, all core KUnit framework features are fully supported on all -architectures, and using them is straightforward: all you need to do is to take -your kunitconfig, your Kconfig options for the tests you would like to run, and -merge them into whatever config your are using for your platform. That's it! +Currently, the KUnit Wrapper (``tools/testing/kunit/kunit.py``) (aka +kunit_tool) only fully supports running tests inside of UML and QEMU; however, +this is only due to our own time limitations as humans working on KUnit. It is +entirely possible to support other emulators and even actual hardware, but for +now QEMU and UML is what is fully supported within the KUnit Wrapper. Again, to +be clear, this is just the Wrapper. The actualy KUnit tests and the KUnit +library they are written in is fully architecture agnostic and can be used in +virtually any setup, you just won't have the benefit of typing a single command +out of the box and having everything magically work perfectly. + +Again, all core KUnit framework features are fully supported on all +architectures, and using them is straightforward: Most popular architectures +are supported directly in the KUnit Wrapper via QEMU. Currently, supported +architectures on QEMU include: + +* i386 +* x86_64 +* arm +* arm64 +* alpha +* powerpc +* riscv +* s390 +* sparc + +In order to run KUnit tests on one of these architectures via QEMU with the +KUnit wrapper, all you need to do is specify the flags ``--arch`` and +``--cross_compile`` when invoking the KUnit Wrapper. For example, we could run +the default KUnit tests on ARM in the following manner (assuming we have an ARM +toolchain installed): + +.. code-block:: bash + + tools/testing/kunit/kunit.py run --timeout=60 --jobs=12 --arch=arm --cross_compile=arm-linux-gnueabihf- + +Alternatively, if you want to run your tests on real hardware or in some other +emulation environment, all you need to do is to take your kunitconfig, your +Kconfig options for the tests you would like to run, and merge them into +whatever config your are using for your platform. That's it! For example, let's say you have the following kunitconfig: -- cgit v1.2.3 From ee9889dfa969544ea4bbc3a406f2135a2bcaea69 Mon Sep 17 00:00:00 2001 From: Andreas Kaessens Date: Thu, 10 Jun 2021 15:24:38 +0200 Subject: dt-bindings: pinctrl: mcp23s08: add documentation for reset-gpios The reset-gpios property is added to the optional dt-bindings and also an example for it's usage. Signed-off-by: Andreas Kaessens Signed-off-by: Darian Biastoch Link: https://lore.kernel.org/r/20210610132438.3085841-2-akaessens@gmail.com Signed-off-by: Linus Walleij --- Documentation/devicetree/bindings/pinctrl/pinctrl-mcp23s08.txt | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-mcp23s08.txt b/Documentation/devicetree/bindings/pinctrl/pinctrl-mcp23s08.txt index 6ec3c8d79f49..2fa5edac7a35 100644 --- a/Documentation/devicetree/bindings/pinctrl/pinctrl-mcp23s08.txt +++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-mcp23s08.txt @@ -49,6 +49,7 @@ Optional properties: - interrupt-controller: Marks the device node as a interrupt controller. - drive-open-drain: Sets the ODR flag in the IOCON register. This configures the IRQ output as open drain active low. +- reset-gpios: Corresponds to the active-low RESET# pin for the chip Optional device specific properties: - microchip,irq-mirror: Sets the mirror flag in the IOCON register. Devices @@ -135,6 +136,7 @@ gpio21: gpio@21 { microchip,irq-mirror; pinctrl-names = "default"; pinctrl-0 = <&i2cgpio0irq>, <&gpio21pullups>; + reset-gpios = <&gpio6 15 GPIO_ACTIVE_LOW>; gpio21pullups: pinmux { pins = "gpio0", "gpio1", "gpio2", "gpio3", -- cgit v1.2.3 From 212c1242a9ac3f9e94a6c6edef2c09bf39650a16 Mon Sep 17 00:00:00 2001 From: Adam Ford Date: Mon, 24 May 2021 20:07:28 -0500 Subject: dt-bindings: add defines for i.MX8MN power domains The i.MX8M Nano has a similar power domain controller to that of the mini, but it isn't fully compatible, so it needs a separate binding and power domain tables. Add the bindings and tables. Signed-off-by: Adam Ford Reviewed-by: Krzysztof Kozlowski Acked-by: Rob Herring Signed-off-by: Shawn Guo --- Documentation/devicetree/bindings/power/fsl,imx-gpcv2.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/power/fsl,imx-gpcv2.yaml b/Documentation/devicetree/bindings/power/fsl,imx-gpcv2.yaml index cac2869af3d0..b6f4c586049d 100644 --- a/Documentation/devicetree/bindings/power/fsl,imx-gpcv2.yaml +++ b/Documentation/devicetree/bindings/power/fsl,imx-gpcv2.yaml @@ -25,6 +25,7 @@ properties: compatible: enum: - fsl,imx7d-gpc + - fsl,imx8mn-gpc - fsl,imx8mq-gpc - fsl,imx8mm-gpc -- cgit v1.2.3 From 7ef9a86dfc5092d8873b04ce10846110eeb68d0f Mon Sep 17 00:00:00 2001 From: Sebastian Reichel Date: Wed, 26 May 2021 17:22:41 +0200 Subject: dt-bindings: vendor-prefixes: add congatec Document binding for congatec. Acked-by: Rob Herring Signed-off-by: Sebastian Reichel Signed-off-by: Shawn Guo --- Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index 71ca69ca9142..fa951ba1c738 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -249,6 +249,8 @@ patternProperties: description: Colorful GRP, Shenzhen Xueyushi Technology Ltd. "^compulab,.*": description: CompuLab Ltd. + "^congatec,.*": + description: congatec GmbH "^coreriver,.*": description: CORERIVER Semiconductor Co.,Ltd. "^corpro,.*": -- cgit v1.2.3 From cd044eafd7105275220f6b7140a8a8fb64e0e5af Mon Sep 17 00:00:00 2001 From: Sebastian Reichel Date: Wed, 26 May 2021 17:22:42 +0200 Subject: dt-bindings: arm: fsl: add GE B1x5pv2 boards Document the compatible for GE B1x5pv2 boards. Acked-by: Rob Herring Signed-off-by: Sebastian Reichel Signed-off-by: Shawn Guo --- Documentation/devicetree/bindings/arm/fsl.yaml | 11 +++++++++++ 1 file changed, 11 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml index fce2a8670b49..1c827c1954dc 100644 --- a/Documentation/devicetree/bindings/arm/fsl.yaml +++ b/Documentation/devicetree/bindings/arm/fsl.yaml @@ -401,6 +401,17 @@ properties: - const: armadeus,imx6dl-apf6 # APF6 (Solo) SoM - const: fsl,imx6dl + - description: i.MX6DL based congatec QMX6 Boards + items: + - enum: + - ge,imx6dl-b105v2 # General Electric B105v2 + - ge,imx6dl-b105pv2 # General Electric B105Pv2 + - ge,imx6dl-b125v2 # General Electric B125v2 + - ge,imx6dl-b125pv2 # General Electric B125Pv2 + - ge,imx6dl-b155v2 # General Electric B155v2 + - const: congatec,qmx6 + - const: fsl,imx6dl + - description: i.MX6DL based DFI FS700-M60-6DL Board items: - const: dfi,fs700-m60-6dl -- cgit v1.2.3 From 388b7e223985f64c322619a1c75be4b0a49623d3 Mon Sep 17 00:00:00 2001 From: Corentin Labbe Date: Tue, 4 May 2021 19:34:55 +0000 Subject: dt-bindings: add vendor prefix for welltech Add vendor prefix for Welltech computer Co Ld. Link: https://lore.kernel.org/r/20210504193457.4008384-4-clabbe@baylibre.com Signed-off-by: Corentin Labbe Acked-by: Rob Herring Signed-off-by: Olof Johansson --- Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index b868cefc7c55..5ff8ec97bd86 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -1244,6 +1244,8 @@ patternProperties: description: Western Digital Corp. "^we,.*": description: Würth Elektronik GmbH. + "^welltech,.*": + description: Welltech Computer Co., Limited. "^wetek,.*": description: WeTek Electronics, limited. "^wexler,.*": -- cgit v1.2.3 From b0a2fbd2a6fcb8dccd88363fc8e2163fd92cd102 Mon Sep 17 00:00:00 2001 From: Corentin Labbe Date: Tue, 4 May 2021 19:34:56 +0000 Subject: dt-bindings: arm: intel-ixp4xx: add welltech,epbx100 Adds welltech,epbx100 as a valid intel-ixp4xx board. Link: https://lore.kernel.org/r/20210504193457.4008384-5-clabbe@baylibre.com Signed-off-by: Corentin Labbe Acked-by: Rob Herring Signed-off-by: Olof Johansson --- Documentation/devicetree/bindings/arm/intel-ixp4xx.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/intel-ixp4xx.yaml b/Documentation/devicetree/bindings/arm/intel-ixp4xx.yaml index d72e92bdf7c1..230bffeec0e5 100644 --- a/Documentation/devicetree/bindings/arm/intel-ixp4xx.yaml +++ b/Documentation/devicetree/bindings/arm/intel-ixp4xx.yaml @@ -17,6 +17,7 @@ properties: - items: - enum: - linksys,nslu2 + - welltech,epbx100 - const: intel,ixp42x - items: - enum: -- cgit v1.2.3 From c6e66f5c21147567f0a09c1d0cbfc32fc894b083 Mon Sep 17 00:00:00 2001 From: Rajeshwari Ravindra Kamble Date: Fri, 7 May 2021 11:37:19 +0530 Subject: dt-bindings: thermal: tsens: Add compatible string to TSENS binding for SC7280 Adding compatible string in TSENS dt-bindings for SC7280. Signed-off-by: Rajeshwari Ravindra Kamble Reviewed-by: Matthias Kaehlcke Acked-by: Rob Herring Signed-off-by: Daniel Lezcano Link: https://lore.kernel.org/r/1620367641-23383-2-git-send-email-rkambl@codeaurora.org --- Documentation/devicetree/bindings/thermal/qcom-tsens.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml b/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml index 0242fd91b622..0d4cfe04648f 100644 --- a/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml +++ b/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml @@ -46,6 +46,7 @@ properties: - qcom,msm8996-tsens - qcom,msm8998-tsens - qcom,sc7180-tsens + - qcom,sc7280-tsens - qcom,sdm845-tsens - qcom,sm8150-tsens - qcom,sm8250-tsens -- cgit v1.2.3 From 858252c9c3463abc3f7b13e42aae3b8845f0479d Mon Sep 17 00:00:00 2001 From: Steen Hegelund Date: Fri, 11 Jun 2021 14:54:50 +0200 Subject: dt-bindings: net: Add 25G BASE-R phy interface Add 25gbase-r PHY interface mode. Signed-off-by: Steen Hegelund Signed-off-by: Bjarni Jonasson Reviewed-by: Andrew Lunn Reviewed-by: Russell King (Oracle) Signed-off-by: David S. Miller --- Documentation/devicetree/bindings/net/ethernet-controller.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/ethernet-controller.yaml b/Documentation/devicetree/bindings/net/ethernet-controller.yaml index d97b561003ed..b0933a8c295a 100644 --- a/Documentation/devicetree/bindings/net/ethernet-controller.yaml +++ b/Documentation/devicetree/bindings/net/ethernet-controller.yaml @@ -98,6 +98,7 @@ properties: - 10gbase-kr - usxgmii - 10gbase-r + - 25gbase-r phy-mode: $ref: "#/properties/phy-connection-type" -- cgit v1.2.3 From a56c286865692ac12291afe4c66198915c6b08f9 Mon Sep 17 00:00:00 2001 From: Steen Hegelund Date: Fri, 11 Jun 2021 14:54:51 +0200 Subject: net: phy: Add 25G BASE-R interface mode Add 25gbase-r phy interface mode Signed-off-by: Steen Hegelund Signed-off-by: Bjarni Jonasson Reviewed-by: Andrew Lunn Reviewed-by: Russell King (Oracle) Signed-off-by: David S. Miller --- Documentation/networking/phy.rst | 6 ++++++ 1 file changed, 6 insertions(+) (limited to 'Documentation') diff --git a/Documentation/networking/phy.rst b/Documentation/networking/phy.rst index 3f05d50ecd6e..571ba08386e7 100644 --- a/Documentation/networking/phy.rst +++ b/Documentation/networking/phy.rst @@ -292,6 +292,12 @@ Some of the interface modes are described below: Note: due to legacy usage, some 10GBASE-R usage incorrectly makes use of this definition. +``PHY_INTERFACE_MODE_25GBASER`` + This is the IEEE 802.3 PCS Clause 107 defined 25GBASE-R protocol. + The PCS is identical to 10GBASE-R, i.e. 64B/66B encoded + running 2.5 as fast, giving a fixed bit rate of 25.78125 Gbaud. + Please refer to the IEEE standard for further information. + ``PHY_INTERFACE_MODE_100BASEX`` This defines IEEE 802.3 Clause 24. The link operates at a fixed data rate of 125Mpbs using a 4B/5B encoding scheme, resulting in an underlying -- cgit v1.2.3 From c3a16200c72e44d20c3468455182f76f3797dc8f Mon Sep 17 00:00:00 2001 From: Stephan Gerhold Date: Fri, 11 Jun 2021 10:08:59 +0200 Subject: dt-bindings: iio: accel: bma255: Document bosch,bma253 BMA253 is mostly like BMA255 that is already supported by the bmc150-accel driver. Document an extra bosch,bma253 compatible for it. Reviewed-by: Linus Walleij Reviewed-by: Hans de Goede Reviewed-by: Andy Shevchenko Signed-off-by: Stephan Gerhold Link: https://lore.kernel.org/r/20210611080903.14384-7-stephan@gerhold.net Signed-off-by: Jonathan Cameron --- Documentation/devicetree/bindings/iio/accel/bosch,bma255.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/iio/accel/bosch,bma255.yaml b/Documentation/devicetree/bindings/iio/accel/bosch,bma255.yaml index c2efbb813ca2..8afb0fe8ef5c 100644 --- a/Documentation/devicetree/bindings/iio/accel/bosch,bma255.yaml +++ b/Documentation/devicetree/bindings/iio/accel/bosch,bma255.yaml @@ -18,6 +18,7 @@ properties: enum: - bosch,bmc150_accel - bosch,bmi055_accel + - bosch,bma253 - bosch,bma255 - bosch,bma250e - bosch,bma222 -- cgit v1.2.3 From d1e7ff89e6f1f883450559cb3cebb632da962b49 Mon Sep 17 00:00:00 2001 From: Stephan Gerhold Date: Fri, 11 Jun 2021 10:09:01 +0200 Subject: dt-bindings: iio: bma255: Allow multiple interrupts BMA253 has two interrupt pins (INT1 and INT2) that can be configured independently. At the moment the bmc150-accel driver does not make use of them but it might be able to in the future, so it's useful to already specify all available interrupts in the device tree. Set maxItems: 2 for interrupts to allow specifying a second one. This is necessary as preparation to move the bosch,bma254 compatible from bosch,bma180.yaml to bosch,bma255.yaml since bma180 allows two interrupts, but BMA254 is better supported by the bmc150-accel driver. Reviewed-by: Linus Walleij Reviewed-by: Hans de Goede Reviewed-by: Andy Shevchenko Signed-off-by: Stephan Gerhold Link: https://lore.kernel.org/r/20210611080903.14384-9-stephan@gerhold.net Signed-off-by: Jonathan Cameron --- Documentation/devicetree/bindings/iio/accel/bosch,bma255.yaml | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/iio/accel/bosch,bma255.yaml b/Documentation/devicetree/bindings/iio/accel/bosch,bma255.yaml index 8afb0fe8ef5c..65b299a5619b 100644 --- a/Documentation/devicetree/bindings/iio/accel/bosch,bma255.yaml +++ b/Documentation/devicetree/bindings/iio/accel/bosch,bma255.yaml @@ -32,7 +32,12 @@ properties: vddio-supply: true interrupts: - maxItems: 1 + minItems: 1 + maxItems: 2 + description: | + The first interrupt listed must be the one connected to the INT1 pin, + the second (optional) interrupt listed must be the one connected to the + INT2 pin (if available). mount-matrix: description: an optional 3x3 mounting rotation matrix. -- cgit v1.2.3 From 5640fed3035e88c3ce1361e6fc93f4e72468f307 Mon Sep 17 00:00:00 2001 From: Stephan Gerhold Date: Fri, 11 Jun 2021 10:09:02 +0200 Subject: dt-bindings: iio: accel: bma180/bma255: Move bma254 to bma255 schema BMA254 is very similar to BMA253/BMA255 which are both supported by the bmc150-accel driver. In general, there is quite some overlap between the bma180 and bmc150-accel driver, but the bmc150-accel driver has a few more features (e.g. motion trigger/interrupt). Let's move bma254 over to the bma255 schema (bmc150-accel driver). Reviewed-by: Linus Walleij Reviewed-by: Hans de Goede Reviewed-by: Andy Shevchenko Signed-off-by: Stephan Gerhold Link: https://lore.kernel.org/r/20210611080903.14384-10-stephan@gerhold.net Signed-off-by: Jonathan Cameron --- Documentation/devicetree/bindings/iio/accel/bosch,bma180.yaml | 3 +-- Documentation/devicetree/bindings/iio/accel/bosch,bma255.yaml | 1 + 2 files changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/iio/accel/bosch,bma180.yaml b/Documentation/devicetree/bindings/iio/accel/bosch,bma180.yaml index 45b3abde298f..a7e84089cc3d 100644 --- a/Documentation/devicetree/bindings/iio/accel/bosch,bma180.yaml +++ b/Documentation/devicetree/bindings/iio/accel/bosch,bma180.yaml @@ -4,7 +4,7 @@ $id: http://devicetree.org/schemas/iio/accel/bosch,bma180.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# -title: Bosch BMA023 / BMA150/ BMA180 / BMA25x / SMB380 triaxial accelerometers +title: Bosch BMA023 / BMA150/ BMA180 / BMA250 / SMB380 triaxial accelerometers maintainers: - Jonathan Cameron @@ -21,7 +21,6 @@ properties: - bosch,bma150 - bosch,bma180 - bosch,bma250 - - bosch,bma254 - bosch,smb380 reg: diff --git a/Documentation/devicetree/bindings/iio/accel/bosch,bma255.yaml b/Documentation/devicetree/bindings/iio/accel/bosch,bma255.yaml index 65b299a5619b..e830d5295b92 100644 --- a/Documentation/devicetree/bindings/iio/accel/bosch,bma255.yaml +++ b/Documentation/devicetree/bindings/iio/accel/bosch,bma255.yaml @@ -19,6 +19,7 @@ properties: - bosch,bmc150_accel - bosch,bmi055_accel - bosch,bma253 + - bosch,bma254 - bosch,bma255 - bosch,bma250e - bosch,bma222 -- cgit v1.2.3 From f7af616c632ee2ac3af0876fe33bf9e0232e665a Mon Sep 17 00:00:00 2001 From: M Chetan Kumar Date: Sun, 13 Jun 2021 18:20:23 +0530 Subject: net: iosm: infrastructure 1) Kconfig & Makefile changes for IOSM Driver compilation. 2) Add IOSM Driver documentation. 3) Modified MAINTAINER file for IOSM Driver addition. Signed-off-by: M Chetan Kumar Signed-off-by: David S. Miller --- Documentation/networking/device_drivers/index.rst | 1 + .../networking/device_drivers/wwan/index.rst | 18 ++++ .../networking/device_drivers/wwan/iosm.rst | 96 ++++++++++++++++++++++ 3 files changed, 115 insertions(+) create mode 100644 Documentation/networking/device_drivers/wwan/index.rst create mode 100644 Documentation/networking/device_drivers/wwan/iosm.rst (limited to 'Documentation') diff --git a/Documentation/networking/device_drivers/index.rst b/Documentation/networking/device_drivers/index.rst index d8279de7bf25..3a5a1d46e77e 100644 --- a/Documentation/networking/device_drivers/index.rst +++ b/Documentation/networking/device_drivers/index.rst @@ -18,6 +18,7 @@ Contents: qlogic/index wan/index wifi/index + wwan/index .. only:: subproject and html diff --git a/Documentation/networking/device_drivers/wwan/index.rst b/Documentation/networking/device_drivers/wwan/index.rst new file mode 100644 index 000000000000..1cb8c7371401 --- /dev/null +++ b/Documentation/networking/device_drivers/wwan/index.rst @@ -0,0 +1,18 @@ +.. SPDX-License-Identifier: GPL-2.0-only + +WWAN Device Drivers +=================== + +Contents: + +.. toctree:: + :maxdepth: 2 + + iosm + +.. only:: subproject and html + + Indices + ======= + + * :ref:`genindex` diff --git a/Documentation/networking/device_drivers/wwan/iosm.rst b/Documentation/networking/device_drivers/wwan/iosm.rst new file mode 100644 index 000000000000..cd12f57d980a --- /dev/null +++ b/Documentation/networking/device_drivers/wwan/iosm.rst @@ -0,0 +1,96 @@ +.. SPDX-License-Identifier: GPL-2.0-only + +.. Copyright (C) 2020-21 Intel Corporation + +.. _iosm_driver_doc: + +=========================================== +IOSM Driver for Intel M.2 PCIe based Modems +=========================================== +The IOSM (IPC over Shared Memory) driver is a WWAN PCIe host driver developed +for linux or chrome platform for data exchange over PCIe interface between +Host platform & Intel M.2 Modem. The driver exposes interface conforming to the +MBIM protocol [1]. Any front end application ( eg: Modem Manager) could easily +manage the MBIM interface to enable data communication towards WWAN. + +Basic usage +=========== +MBIM functions are inactive when unmanaged. The IOSM driver only provides a +userspace interface MBIM "WWAN PORT" representing MBIM control channel and does +not play any role in managing the functionality. It is the job of a userspace +application to detect port enumeration and enable MBIM functionality. + +Examples of few such userspace application are: +- mbimcli (included with the libmbim [2] library), and +- Modem Manager [3] + +Management Applications to carry out below required actions for establishing +MBIM IP session: +- open the MBIM control channel +- configure network connection settings +- connect to network +- configure IP network interface + +Management application development +================================== +The driver and userspace interfaces are described below. The MBIM protocol is +described in [1] Mobile Broadband Interface Model v1.0 Errata-1. + +MBIM control channel userspace ABI +---------------------------------- + +/dev/wwan0mbim0 character device +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +The driver exposes an MBIM interface to the MBIM function by implementing +MBIM WWAN Port. The userspace end of the control channel pipe is a +/dev/wwan0mbim0 character device. Application shall use this interface for +MBIM protocol communication. + +Fragmentation +~~~~~~~~~~~~~ +The userspace application is responsible for all control message fragmentation +and defragmentation as per MBIM specification. + +/dev/wwan0mbim0 write() +~~~~~~~~~~~~~~~~~~~~~ +The MBIM control messages from the management application must not exceed the +negotiated control message size. + +/dev/wwan0mbim0 read() +~~~~~~~~~~~~~~~~~~~~ +The management application must accept control messages of up the negotiated +control message size. + +MBIM data channel userspace ABI +------------------------------- + +wwan0-X network device +~~~~~~~~~~~~~~~~~~~~ +The IOSM driver exposes IP link interface "wwan0-X" of type "wwan" for IP +traffic. Iproute network utility is used for creating "wwan0-X" network +interface and for associating it with MBIM IP session. The Driver supports +upto 8 IP sessions for simultaneous IP communication. + +The userspace management application is responsible for creating new IP link +prior to establishing MBIM IP session where the SessionId is greater than 0. + +For example, creating new IP link for a MBIM IP session with SessionId 1: + + ip link add dev wwan0-1 parentdev-name wwan0 type wwan linkid 1 + +The driver will automatically map the "wwan0-1" network device to MBIM IP +session 1. + +References +========== +[1] "MBIM (Mobile Broadband Interface Model) Errata-1" + - https://www.usb.org/document-library/ + +[2] libmbim - "a glib-based library for talking to WWAN modems and + devices which speak the Mobile Interface Broadband Model (MBIM) + protocol" + - http://www.freedesktop.org/wiki/Software/libmbim/ + +[3] Modem Manager - "a DBus-activated daemon which controls mobile + broadband (2G/3G/4G) devices and connections" + - http://www.freedesktop.org/wiki/Software/ModemManager/ -- cgit v1.2.3 From a9edc03f13dbd51095b38ef0371d24e7ec7ae693 Mon Sep 17 00:00:00 2001 From: Kir Kolyshkin Date: Thu, 10 Jun 2021 20:00:44 -0700 Subject: docs: fix a cross-ref Commit acda97acb2e98c9 changes dax.txt to dax.rst. Fix the references accordingly. Cc: Igor Matheus Andrade Torrente Signed-off-by: Kir Kolyshkin Link: https://lore.kernel.org/r/20210611030044.1982911-4-kolyshkin@gmail.com Signed-off-by: Jonathan Corbet --- Documentation/admin-guide/ext4.rst | 2 +- Documentation/filesystems/ext2.rst | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/admin-guide/ext4.rst b/Documentation/admin-guide/ext4.rst index d2795ca6821e..4c559e08d11e 100644 --- a/Documentation/admin-guide/ext4.rst +++ b/Documentation/admin-guide/ext4.rst @@ -392,7 +392,7 @@ When mounting an ext4 filesystem, the following option are accepted: dax Use direct access (no page cache). See - Documentation/filesystems/dax.txt. Note that this option is + Documentation/filesystems/dax.rst. Note that this option is incompatible with data=journal. inlinecrypt diff --git a/Documentation/filesystems/ext2.rst b/Documentation/filesystems/ext2.rst index c2fce22cfd03..154101cf0e4f 100644 --- a/Documentation/filesystems/ext2.rst +++ b/Documentation/filesystems/ext2.rst @@ -25,7 +25,7 @@ check=none, nocheck (*) Don't do extra checking of bitmaps on mount (check=normal and check=strict options removed) dax Use direct access (no page cache). See - Documentation/filesystems/dax.txt. + Documentation/filesystems/dax.rst. debug Extra debugging information is sent to the kernel syslog. Useful for developers. -- cgit v1.2.3 From ad92330614b93933088764e9098ebaec042bada6 Mon Sep 17 00:00:00 2001 From: Aswath Govindraju Date: Mon, 10 May 2021 10:40:04 +0530 Subject: dt-bindings: phy: Add binding for TI TCAN104x CAN transceivers Add binding documentation for TI TCAN104x CAN transceivers. Signed-off-by: Aswath Govindraju Reviewed-by: Rob Herring Acked-by: Marc Kleine-Budde Link: https://lore.kernel.org/r/20210510051006.11393-3-a-govindraju@ti.com Signed-off-by: Vinod Koul --- .../devicetree/bindings/phy/ti,tcan104x-can.yaml | 56 ++++++++++++++++++++++ 1 file changed, 56 insertions(+) create mode 100644 Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml b/Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml new file mode 100644 index 000000000000..6107880e5246 --- /dev/null +++ b/Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml @@ -0,0 +1,56 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/phy/ti,tcan104x-can.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: TCAN104x CAN TRANSCEIVER PHY + +maintainers: + - Aswath Govindraju + +properties: + $nodename: + pattern: "^can-phy" + + compatible: + enum: + - ti,tcan1042 + - ti,tcan1043 + + '#phy-cells': + const: 0 + + standby-gpios: + description: + gpio node to toggle standby signal on transceiver + maxItems: 1 + + enable-gpios: + description: + gpio node to toggle enable signal on transceiver + maxItems: 1 + + max-bitrate: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + max bit rate supported in bps + minimum: 1 + +required: + - compatible + - '#phy-cells' + +additionalProperties: false + +examples: + - | + #include + + transceiver1: can-phy { + compatible = "ti,tcan1043"; + #phy-cells = <0>; + max-bitrate = <5000000>; + standby-gpios = <&wakeup_gpio1 16 GPIO_ACTIVE_LOW>; + enable-gpios = <&main_gpio1 67 GPIO_ACTIVE_HIGH>; + }; -- cgit v1.2.3 From e446441a058a39f092cc536402230e852f658c4f Mon Sep 17 00:00:00 2001 From: Dong Aisheng Date: Fri, 23 Apr 2021 11:33:29 +0800 Subject: dt-bindings: arm: imx: scu: fix naming typo of clk compatible string There is a typo in binding doc that the name of compatible string of scu clock should be "fsl,xxx-clk" rather than "fsl,xxx-clock". In reality, both example and dts using "fsl,xxx-clk", so fixing the doc is enough. Cc: devicetree@vger.kernel.org Signed-off-by: Dong Aisheng Acked-by: Rob Herring Signed-off-by: Abel Vesa --- Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt index 395359dc94fd..3adf3f6f2beb 100644 --- a/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt +++ b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt @@ -86,8 +86,8 @@ This binding uses the common clock binding[1]. Required properties: - compatible: Should be one of: - "fsl,imx8qm-clock" - "fsl,imx8qxp-clock" + "fsl,imx8qm-clk" + "fsl,imx8qxp-clk" followed by "fsl,scu-clk" - #clock-cells: Should be either 2: Contains the Resource and Clock ID value. -- cgit v1.2.3 From 659c12c7f5ceda8a62c92da1b730307c537247fa Mon Sep 17 00:00:00 2001 From: Dong Aisheng Date: Fri, 23 Apr 2021 11:33:30 +0800 Subject: dt-bindings: arm: imx: scu: drop deprecated legacy clock binding The legacy clock binding are not maintained anymore. It has only a very preliminary supported clocks during initial upstream and meaningless for users. So drop it from binding doc now. Cc: devicetree@vger.kernel.org Signed-off-by: Dong Aisheng Acked-by: Rob Herring Signed-off-by: Abel Vesa --- Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt index 3adf3f6f2beb..fd0061712443 100644 --- a/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt +++ b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt @@ -89,10 +89,8 @@ Required properties: "fsl,imx8qm-clk" "fsl,imx8qxp-clk" followed by "fsl,scu-clk" -- #clock-cells: Should be either - 2: Contains the Resource and Clock ID value. - or - 1: Contains the Clock ID value. (DEPRECATED) +- #clock-cells: Should be 2. + Contains the Resource and Clock ID value. - clocks: List of clock specifiers, must contain an entry for each required entry in clock-names - clock-names: Should include entries "xtal_32KHz", "xtal_24MHz" -- cgit v1.2.3 From 10ee3e07d32bede6cd007fb76150a1ccd0628852 Mon Sep 17 00:00:00 2001 From: Srinivas Kandagatla Date: Wed, 9 Jun 2021 10:09:35 +0100 Subject: ASoC: dt-bindings: wcd938x: add bindings for wcd938x Qualcomm WCD9380/WCD9385 Codec is a standalone Hi-Fi audio codec IC connected over SoundWire. This device has two SoundWire device RX and TX respectively, supporting 4 x ADCs, ClassH, Ear, Aux PA, 2xHPH, 7 x TX diff inputs, 8 DMICs, MBHC. Signed-off-by: Srinivas Kandagatla Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20210609090943.7896-2-srinivas.kandagatla@linaro.org Signed-off-by: Mark Brown --- .../devicetree/bindings/sound/qcom,wcd938x.yaml | 146 +++++++++++++++++++++ 1 file changed, 146 insertions(+) create mode 100644 Documentation/devicetree/bindings/sound/qcom,wcd938x.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/qcom,wcd938x.yaml b/Documentation/devicetree/bindings/sound/qcom,wcd938x.yaml new file mode 100644 index 000000000000..cb74ce40c2e6 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/qcom,wcd938x.yaml @@ -0,0 +1,146 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/qcom,wcd938x.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Bindings for Qualcomm WCD9380/WCD9385 Audio Codec + +maintainers: + - Srinivas Kandagatla + +description: | + Qualcomm WCD9380/WCD9385 Codec is a standalone Hi-Fi audio codec IC. + It has RX and TX Soundwire slave devices. + +properties: + compatible: + enum: + - qcom,wcd9380-codec + - qcom,wcd9385-codec + + reset-gpios: + description: GPIO spec for reset line to use + maxItems: 1 + + vdd-buck-supply: + description: A reference to the 1.8V buck supply + + vdd-rxtx-supply: + description: A reference to the 1.8V rx supply + + vdd-io-supply: + description: A reference to the 1.8V I/O supply + + qcom,tx-device: + $ref: /schemas/types.yaml#/definitions/phandle-array + description: A reference to Soundwire tx device phandle + + qcom,rx-device: + $ref: /schemas/types.yaml#/definitions/phandle-array + description: A reference to Soundwire rx device phandle + + qcom,micbias1-microvolt: + description: micbias1 voltage + minimum: 1800000 + maximum: 2850000 + + qcom,micbias2-microvolt: + description: micbias2 voltage + minimum: 1800000 + maximum: 2850000 + + qcom,micbias3-microvolt: + description: micbias3 voltage + minimum: 1800000 + maximum: 2850000 + + qcom,micbias4-microvolt: + description: micbias4 voltage + minimum: 1800000 + maximum: 2850000 + + qcom,hphl-jack-type-normally-closed: + description: Indicates that HPHL jack switch type is normally closed + type: boolean + + qcom,ground-jack-type-normally-closed: + description: Indicates that Headset Ground switch type is normally closed + type: boolean + + qcom,mbhc-headset-vthreshold-microvolt: + description: Voltage threshold value for headset detection + minimum: 0 + maximum: 2850000 + + qcom,mbhc-headphone-vthreshold-microvolt: + description: Voltage threshold value for headphone detection + minimum: 0 + maximum: 2850000 + + qcom,mbhc-buttons-vthreshold-microvolt: + description: + Array of 8 Voltage threshold values corresponding to headset + button0 - button7 + minItems: 8 + maxItems: 8 + + '#sound-dai-cells': + const: 1 + +required: + - compatible + - reset-gpios + - qcom,tx-device + - qcom,rx-device + - qcom,micbias1-microvolt + - qcom,micbias2-microvolt + - qcom,micbias3-microvolt + - qcom,micbias4-microvolt + - "#sound-dai-cells" + +additionalProperties: false + +examples: + - | + codec { + compatible = "qcom,wcd9380-codec"; + reset-gpios = <&tlmm 32 0>; + #sound-dai-cells = <1>; + qcom,tx-device = <&wcd938x_tx>; + qcom,rx-device = <&wcd938x_rx>; + qcom,micbias1-microvolt = <1800000>; + qcom,micbias2-microvolt = <1800000>; + qcom,micbias3-microvolt = <1800000>; + qcom,micbias4-microvolt = <1800000>; + qcom,hphl-jack-type-normally-closed; + qcom,ground-jack-type-normally-closed; + qcom,mbhc-buttons-vthreshold-microvolt = <75000 150000 237000 500000 500000 500000 500000 500000>; + qcom,mbhc-headphone-vthreshold-microvolt = <50000>; + }; + + /* ... */ + + soundwire@3210000 { + #address-cells = <2>; + #size-cells = <0>; + reg = <0x03210000 0x2000>; + wcd938x_rx: codec@0,4 { + compatible = "sdw20217010d00"; + reg = <0 4>; + qcom,rx-port-mapping = <1 2 3 4 5>; + }; + }; + + soundwire@3230000 { + #address-cells = <2>; + #size-cells = <0>; + reg = <0x03230000 0x2000>; + wcd938x_tx: codec@0,3 { + compatible = "sdw20217010d00"; + reg = <0 3>; + qcom,tx-port-mapping = <2 3 4 5>; + }; + }; + +... -- cgit v1.2.3 From e02c65f3a7ce11ce522e805c78ed2f1da5d96975 Mon Sep 17 00:00:00 2001 From: Srinivas Kandagatla Date: Wed, 9 Jun 2021 10:09:38 +0100 Subject: ASoC: dt-bindings: wcd938x-sdw: add bindings for wcd938x-sdw Qualcomm WCD9380/WCD9385 Codec is a standalone Hi-Fi audio codec IC connected over SoundWire. This device has two SoundWire devices RX and TX respectively. This bindings is for those slave devices on WCD9380/WCD9385. Signed-off-by: Srinivas Kandagatla Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20210609090943.7896-5-srinivas.kandagatla@linaro.org Signed-off-by: Mark Brown --- .../bindings/sound/qcom,wcd938x-sdw.yaml | 70 ++++++++++++++++++++++ 1 file changed, 70 insertions(+) create mode 100644 Documentation/devicetree/bindings/sound/qcom,wcd938x-sdw.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/qcom,wcd938x-sdw.yaml b/Documentation/devicetree/bindings/sound/qcom,wcd938x-sdw.yaml new file mode 100644 index 000000000000..49a267b306f6 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/qcom,wcd938x-sdw.yaml @@ -0,0 +1,70 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/qcom,wcd938x-sdw.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Bindings for Qualcomm SoundWire Slave devices on WCD9380/WCD9385 + +maintainers: + - Srinivas Kandagatla + +description: | + Qualcomm WCD9380/WCD9385 Codec is a standalone Hi-Fi audio codec IC. + It has RX and TX Soundwire slave devices. This bindings is for the + slave devices. + +properties: + compatible: + const: sdw20217010d00 + + reg: + maxItems: 1 + + qcom,tx-port-mapping: + description: | + Specifies static port mapping between slave and master tx ports. + In the order of slave port index. + $ref: /schemas/types.yaml#/definitions/uint32-array + minItems: 4 + maxItems: 4 + + qcom,rx-port-mapping: + description: | + Specifies static port mapping between slave and master rx ports. + In the order of slave port index. + $ref: /schemas/types.yaml#/definitions/uint32-array + minItems: 5 + maxItems: 5 + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + soundwire@3210000 { + #address-cells = <2>; + #size-cells = <0>; + reg = <0x03210000 0x2000>; + wcd938x_rx: codec@0,4 { + compatible = "sdw20217010d00"; + reg = <0 4>; + qcom,rx-port-mapping = <1 2 3 4 5>; + }; + }; + + soundwire@3230000 { + #address-cells = <2>; + #size-cells = <0>; + reg = <0x03230000 0x2000>; + wcd938x_tx: codec@0,3 { + compatible = "sdw20217010d00"; + reg = <0 3>; + qcom,tx-port-mapping = <2 3 4 5>; + }; + }; + +... -- cgit v1.2.3 From 6a45d70cda6a6e3fa3cffe37d47495fb3c4a4bfa Mon Sep 17 00:00:00 2001 From: Suman Anna Date: Wed, 28 Apr 2021 18:05:00 -0500 Subject: dt-bindings: mmc: sdhci-am654: Remove duplicate ti,j721e-sdhci-4bit The commit 7c7905df68c5 ("dt-bindings: mmc: sdhci-am654: fix compatible for j7200") switched the compatible property from a regular enum to an more appropriate combinatorial oneOf convention, and in the process has introduced a duplicate ti,j721e-sdhci-4bit. This generated the following warning on J721E boards that use the ti,j721e-sdhci-4bit for two nodes: "mmc@4fb0000: compatible: More than one condition true in oneOf schema" "mmc@4f98000: compatible: More than one condition true in oneOf schema" Remove the duplicate to fix this. Fixes: 7c7905df68c5 ("dt-bindings: mmc: sdhci-am654: fix compatible for j7200") Signed-off-by: Suman Anna Link: https://lore.kernel.org/r/20210428230500.19214-1-s-anna@ti.com Signed-off-by: Ulf Hansson --- Documentation/devicetree/bindings/mmc/sdhci-am654.yaml | 1 - 1 file changed, 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mmc/sdhci-am654.yaml b/Documentation/devicetree/bindings/mmc/sdhci-am654.yaml index 3a79e39253d2..29399e88ac53 100644 --- a/Documentation/devicetree/bindings/mmc/sdhci-am654.yaml +++ b/Documentation/devicetree/bindings/mmc/sdhci-am654.yaml @@ -19,7 +19,6 @@ properties: - const: ti,am654-sdhci-5.1 - const: ti,j721e-sdhci-8bit - const: ti,j721e-sdhci-4bit - - const: ti,j721e-sdhci-4bit - const: ti,am64-sdhci-8bit - const: ti,am64-sdhci-4bit - items: -- cgit v1.2.3 From 873e90883069a4e32bc6ecd150b0107f9aa542b8 Mon Sep 17 00:00:00 2001 From: Liang Chen Date: Thu, 29 Apr 2021 16:11:44 +0800 Subject: dt-bindings: mmc: rockchip-dw-mshc: add description for rk3568 Add "rockchip,rk3568-dw-mshc", "rockchip,rk3288-dw-mshc" compatibles for mmc nodes on a rk3568 platform to rockchip-dw-mshc.yaml. Let's also take to opportunity to clean up some old redundant comments around previous compatibles. Signed-off-by: Liang Chen Acked-by: Rob Herring Link: https://lore.kernel.org/r/20210429081151.17558-4-cl@rock-chips.com Signed-off-by: Ulf Hansson --- Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.yaml | 9 +-------- 1 file changed, 1 insertion(+), 8 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.yaml b/Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.yaml index 3762f1c8de96..eaa3b0ef24f6 100644 --- a/Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.yaml +++ b/Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.yaml @@ -29,21 +29,14 @@ properties: - const: rockchip,rk3288-dw-mshc - items: - enum: - # for Rockchip PX30 - rockchip,px30-dw-mshc - # for Rockchip RK3036 - rockchip,rk3036-dw-mshc - # for Rockchip RK322x - rockchip,rk3228-dw-mshc - # for Rockchip RK3308 - rockchip,rk3308-dw-mshc - # for Rockchip RK3328 - rockchip,rk3328-dw-mshc - # for Rockchip RK3368 - rockchip,rk3368-dw-mshc - # for Rockchip RK3399 - rockchip,rk3399-dw-mshc - # for Rockchip RV1108 + - rockchip,rk3568-dw-mshc - rockchip,rv1108-dw-mshc - const: rockchip,rk3288-dw-mshc -- cgit v1.2.3 From 110a8688c6cd11e81a1805d5dc24a7a6b5d86a18 Mon Sep 17 00:00:00 2001 From: Geert Uytterhoeven Date: Mon, 10 May 2021 14:13:21 +0200 Subject: dt-bindings: mmc: renesas,mmcif: Convert to json-schema Convert the Renesas Multi Media Card Interface (MMCIF) Device Tree binding documentation to json-schema. Document missing properties. Update the example to match reality. Signed-off-by: Geert Uytterhoeven Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/04b97315fed0f4f512356b68f9f5bb6ed7adc41f.1620648698.git.geert+renesas@glider.be Signed-off-by: Ulf Hansson --- .../devicetree/bindings/mmc/renesas,mmcif.txt | 53 -------- .../devicetree/bindings/mmc/renesas,mmcif.yaml | 135 +++++++++++++++++++++ 2 files changed, 135 insertions(+), 53 deletions(-) delete mode 100644 Documentation/devicetree/bindings/mmc/renesas,mmcif.txt create mode 100644 Documentation/devicetree/bindings/mmc/renesas,mmcif.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mmc/renesas,mmcif.txt b/Documentation/devicetree/bindings/mmc/renesas,mmcif.txt deleted file mode 100644 index 291532ac0446..000000000000 --- a/Documentation/devicetree/bindings/mmc/renesas,mmcif.txt +++ /dev/null @@ -1,53 +0,0 @@ -* Renesas Multi Media Card Interface (MMCIF) Controller - -This file documents differences between the core properties in mmc.txt -and the properties used by the MMCIF device. - - -Required properties: - -- compatible: should be "renesas,mmcif-", "renesas,sh-mmcif" as a - fallback. Examples with are: - - "renesas,mmcif-r7s72100" for the MMCIF found in r7s72100 SoCs - - "renesas,mmcif-r8a73a4" for the MMCIF found in r8a73a4 SoCs - - "renesas,mmcif-r8a7740" for the MMCIF found in r8a7740 SoCs - - "renesas,mmcif-r8a7742" for the MMCIF found in r8a7742 SoCs - - "renesas,mmcif-r8a7743" for the MMCIF found in r8a7743 SoCs - - "renesas,mmcif-r8a7744" for the MMCIF found in r8a7744 SoCs - - "renesas,mmcif-r8a7745" for the MMCIF found in r8a7745 SoCs - - "renesas,mmcif-r8a7778" for the MMCIF found in r8a7778 SoCs - - "renesas,mmcif-r8a7790" for the MMCIF found in r8a7790 SoCs - - "renesas,mmcif-r8a7791" for the MMCIF found in r8a7791 SoCs - - "renesas,mmcif-r8a7793" for the MMCIF found in r8a7793 SoCs - - "renesas,mmcif-r8a7794" for the MMCIF found in r8a7794 SoCs - - "renesas,mmcif-sh73a0" for the MMCIF found in sh73a0 SoCs - -- interrupts: Some SoCs have only 1 shared interrupt, while others have either - 2 or 3 individual interrupts (error, int, card detect). Below is the number - of interrupts for each SoC: - 1: r8a73a4, r8a7742, r8a7743, r8a7744, r8a7745, r8a7778, r8a7790, r8a7791, - r8a7793, r8a7794 - 2: r8a7740, sh73a0 - 3: r7s72100 - -- clocks: reference to the functional clock - -- dmas: reference to the DMA channels, one per channel name listed in the - dma-names property. -- dma-names: must contain "tx" for the transmit DMA channel and "rx" for the - receive DMA channel. -- max-frequency: Maximum operating clock frequency, driver uses default clock - frequency if it is not set. - - -Example: R8A7790 (R-Car H2) MMCIF0 - - mmcif0: mmc@ee200000 { - compatible = "renesas,mmcif-r8a7790", "renesas,sh-mmcif"; - reg = <0 0xee200000 0 0x80>; - interrupts = <0 169 IRQ_TYPE_LEVEL_HIGH>; - clocks = <&mstp3_clks R8A7790_CLK_MMCIF0>; - dmas = <&dmac0 0xd1>, <&dmac0 0xd2>; - dma-names = "tx", "rx"; - max-frequency = <97500000>; - }; diff --git a/Documentation/devicetree/bindings/mmc/renesas,mmcif.yaml b/Documentation/devicetree/bindings/mmc/renesas,mmcif.yaml new file mode 100644 index 000000000000..c36ba561c387 --- /dev/null +++ b/Documentation/devicetree/bindings/mmc/renesas,mmcif.yaml @@ -0,0 +1,135 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mmc/renesas,mmcif.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Renesas Multi Media Card Interface (MMCIF) Controller + +maintainers: + - Wolfram Sang + +allOf: + - $ref: "mmc-controller.yaml" + +properties: + compatible: + items: + - enum: + - renesas,mmcif-r7s72100 # RZ/A1H + - renesas,mmcif-r8a73a4 # R-Mobile APE6 + - renesas,mmcif-r8a7740 # R-Mobile A1 + - renesas,mmcif-r8a7742 # RZ/G1H + - renesas,mmcif-r8a7743 # RZ/G1M + - renesas,mmcif-r8a7744 # RZ/G1N + - renesas,mmcif-r8a7745 # RZ/G1E + - renesas,mmcif-r8a7778 # R-Car M1A + - renesas,mmcif-r8a7790 # R-Car H2 + - renesas,mmcif-r8a7791 # R-Car M2-W + - renesas,mmcif-r8a7793 # R-Car M2-N + - renesas,mmcif-r8a7794 # R-Car E2 + - renesas,mmcif-sh73a0 # SH-Mobile AG5 + - const: renesas,sh-mmcif + + reg: + maxItems: 1 + + interrupts: true + + clocks: + maxItems: 1 + + power-domains: + maxItems: 1 + + resets: + maxItems: 1 + + dmas: + minItems: 2 + maxItems: 4 + description: + Must contain a list of pairs of references to DMA specifiers, one for + transmission, and one for reception. + + dma-names: + minItems: 2 + maxItems: 4 + items: + enum: + - tx + - rx + + max-frequency: true + +required: + - compatible + - reg + - interrupts + - clocks + - power-domains + +if: + properties: + compatible: + contains: + const: renesas,mmcif-r7s72100 +then: + properties: + interrupts: + items: + - description: Error interrupt + - description: Normal operation interrupt + - description: Card detection interrupt +else: + if: + properties: + compatible: + contains: + enum: + - renesas,mmcif-r8a7740 + - renesas,mmcif-sh73a0 + then: + properties: + interrupts: + items: + - description: Error interrupt + - description: Normal operation interrupt + else: + if: + properties: + compatible: + contains: + enum: + - renesas,mmcif-r8a73a4 + - renesas,mmcif-r8a7778 + then: + properties: + interrupts: + maxItems: 1 + else: + properties: + interrupts: + maxItems: 1 + required: + - resets + +unevaluatedProperties: false + +examples: + - | + #include + #include + #include + + mmcif0: mmc@ee200000 { + compatible = "renesas,mmcif-r8a7790", "renesas,sh-mmcif"; + reg = <0xee200000 0x80>; + interrupts = ; + clocks = <&cpg CPG_MOD 315>; + power-domains = <&sysc R8A7790_PD_ALWAYS_ON>; + resets = <&cpg 315>; + dmas = <&dmac0 0xd1>, <&dmac0 0xd2>, <&dmac1 0xd1>, <&dmac1 0xd2>; + dma-names = "tx", "rx", "tx", "rx"; + max-frequency = <97500000>; + }; -- cgit v1.2.3 From 4d895de3505f7eb9734f679a340c976f8949ab43 Mon Sep 17 00:00:00 2001 From: Lucas Stach Date: Mon, 10 May 2021 21:03:58 +0200 Subject: dt-bindings: mmc: add no-mmc-hs400 flag HS400 requires a data strobe line in addition to the usual MMC signal lines. If a board design neglects to wire up this signal, HS400 mode is not available, even if both the controller and the eMMC are claiming to support this mode. Add a DT flag to allow boards to disable the HS400 support in this case. Signed-off-by: Lucas Stach Acked-by: Rob Herring Link: https://lore.kernel.org/r/20210510190400.105162-1-l.stach@pengutronix.de Signed-off-by: Ulf Hansson --- Documentation/devicetree/bindings/mmc/mmc-controller.yaml | 5 +++++ 1 file changed, 5 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mmc/mmc-controller.yaml b/Documentation/devicetree/bindings/mmc/mmc-controller.yaml index e141330c1114..ac80d09df3a9 100644 --- a/Documentation/devicetree/bindings/mmc/mmc-controller.yaml +++ b/Documentation/devicetree/bindings/mmc/mmc-controller.yaml @@ -220,6 +220,11 @@ properties: description: eMMC HS400 enhanced strobe mode is supported + no-mmc-hs400: + $ref: /schemas/types.yaml#/definitions/flag + description: + All eMMC HS400 modes are not supported. + dsr: description: Value the card Driver Stage Register (DSR) should be programmed -- cgit v1.2.3 From 8931acce6b771dfe01d23e6d36e0b09f717c90c2 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Andreas=20F=C3=A4rber?= Date: Mon, 17 May 2021 01:05:48 +0200 Subject: dt-bindings: mmc: rockchip-dw-mshc: Add Rockchip RK1808 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Add a compatible string for Rockchip RK1808 SoC. Signed-off-by: Andreas Färber Acked-by: Rob Herring Link: https://lore.kernel.org/r/20210516230551.12469-7-afaerber@suse.de Signed-off-by: Ulf Hansson --- Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.yaml b/Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.yaml index eaa3b0ef24f6..54fb59820d2b 100644 --- a/Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.yaml +++ b/Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.yaml @@ -30,6 +30,7 @@ properties: - items: - enum: - rockchip,px30-dw-mshc + - rockchip,rk1808-dw-mshc - rockchip,rk3036-dw-mshc - rockchip,rk3228-dw-mshc - rockchip,rk3308-dw-mshc -- cgit v1.2.3 From 1e9daaf616a2f053eb80e20a84b47ebf2d5e20d3 Mon Sep 17 00:00:00 2001 From: Rob Herring Date: Wed, 19 May 2021 10:37:12 -0500 Subject: dt-bindings: mmc: Clean-up examples to match documented bindings The "sdhci" compatible is not documented though used as a fallback in a few cases. It is also not supported by a Linux driver. Just remove the example as part of ridding examples of undocumented bindings. The "brcm,bcm43xx-fmac" compatible is also not documented. Update the example to use one of the correct ones, "brcm,bcm4329-fmac", instead and use a device class based nodename. Cc: Ulf Hansson Cc: linux-mmc@vger.kernel.org Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20210519153712.3146025-1-robh@kernel.org Signed-off-by: Ulf Hansson --- .../devicetree/bindings/mmc/mmc-controller.yaml | 20 ++------------------ 1 file changed, 2 insertions(+), 18 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mmc/mmc-controller.yaml b/Documentation/devicetree/bindings/mmc/mmc-controller.yaml index ac80d09df3a9..25ac8e200970 100644 --- a/Documentation/devicetree/bindings/mmc/mmc-controller.yaml +++ b/Documentation/devicetree/bindings/mmc/mmc-controller.yaml @@ -362,22 +362,6 @@ dependencies: additionalProperties: true examples: - - | - mmc@ab000000 { - compatible = "sdhci"; - reg = <0xab000000 0x200>; - interrupts = <23>; - bus-width = <4>; - cd-gpios = <&gpio 69 0>; - cd-inverted; - wp-gpios = <&gpio 70 0>; - max-frequency = <50000000>; - keep-power-in-suspend; - wakeup-source; - mmc-pwrseq = <&sdhci0_pwrseq>; - clk-phase-sd-hs = <63>, <72>; - }; - - | mmc3: mmc@1c12000 { #address-cells = <1>; @@ -390,9 +374,9 @@ examples: non-removable; mmc-pwrseq = <&sdhci0_pwrseq>; - brcmf: bcrmf@1 { + brcmf: wifi@1 { reg = <1>; - compatible = "brcm,bcm43xx-fmac"; + compatible = "brcm,bcm4329-fmac"; interrupt-parent = <&pio>; interrupts = <10 8>; interrupt-names = "host-wake"; -- cgit v1.2.3 From 3160e025361fad1085e527a898c5dcfedf7e796d Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=E5=91=A8=E7=90=B0=E6=9D=B0=20=28Zhou=20Yanjie=29?= Date: Thu, 10 Jun 2021 20:58:49 +0800 Subject: dt-bindings: mmc: JZ4740: Add bindings for JZ4775 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Add a compatible to the mmc DT bindings for the JZ4775 SoC from Ingenic. Signed-off-by: 周琰杰 (Zhou Yanjie) Acked-by: Paul Cercueil Link: https://lore.kernel.org/r/1623329930-14387-2-git-send-email-zhouyanjie@wanyeetech.com Signed-off-by: Ulf Hansson --- Documentation/devicetree/bindings/mmc/ingenic,mmc.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mmc/ingenic,mmc.yaml b/Documentation/devicetree/bindings/mmc/ingenic,mmc.yaml index 04ba8b7fc054..546480f41141 100644 --- a/Documentation/devicetree/bindings/mmc/ingenic,mmc.yaml +++ b/Documentation/devicetree/bindings/mmc/ingenic,mmc.yaml @@ -19,6 +19,7 @@ properties: - ingenic,jz4740-mmc - ingenic,jz4725b-mmc - ingenic,jz4760-mmc + - ingenic,jz4775-mmc - ingenic,jz4780-mmc - ingenic,x1000-mmc - items: -- cgit v1.2.3 From f1905ab2a8a2103b7fa74a5f96fb50cce0dee6f5 Mon Sep 17 00:00:00 2001 From: Marek Vasut Date: Thu, 10 Jun 2021 17:01:35 +0200 Subject: ASoC: sgtl5000: Add audio-graph-card port The SGTL5000 codec can be connected via audio-graph-card, add the missing port: entry into the bindings. Signed-off-by: Marek Vasut Link: https://lore.kernel.org/r/20210610150135.29905-1-marex@denx.de Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/sound/sgtl5000.yaml | 4 ++++ 1 file changed, 4 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/sgtl5000.yaml b/Documentation/devicetree/bindings/sound/sgtl5000.yaml index 70b4a8831073..e762c320b574 100644 --- a/Documentation/devicetree/bindings/sound/sgtl5000.yaml +++ b/Documentation/devicetree/bindings/sound/sgtl5000.yaml @@ -75,6 +75,10 @@ properties: $ref: "/schemas/types.yaml#/definitions/uint32" enum: [ 0, 1, 2, 3 ] + port: + $ref: audio-graph-port.yaml# + unevaluatedProperties: false + required: - compatible - reg -- cgit v1.2.3 From d7c176e9b5329b4a490b3d8ea49564fc9ff11071 Mon Sep 17 00:00:00 2001 From: Carlos Llamas Date: Wed, 9 Jun 2021 19:50:58 +0000 Subject: docs: printk-formats: update size-casting examples Since commit 72deb455b5ec ("block: remove CONFIG_LBDAF") sector_t and blkcnt_t types are no longer variable in size, making them unsuitable examples for casting to the largest possible type. This patch replaces such examples with cycles_t and blk_status_t types, whose sizes depend on architecture and config options respectively. Signed-off-by: Carlos Llamas Link: https://lore.kernel.org/r/20210609195058.3518943-1-cmllamas@google.com Signed-off-by: Jonathan Corbet --- Documentation/core-api/printk-formats.rst | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) (limited to 'Documentation') diff --git a/Documentation/core-api/printk-formats.rst b/Documentation/core-api/printk-formats.rst index f063a384c7c8..385c0cc52f1f 100644 --- a/Documentation/core-api/printk-formats.rst +++ b/Documentation/core-api/printk-formats.rst @@ -37,14 +37,13 @@ Integer types u64 %llu or %llx -If is dependent on a config option for its size (e.g., sector_t, -blkcnt_t) or is architecture-dependent for its size (e.g., tcflag_t), use a -format specifier of its largest possible type and explicitly cast to it. +If is architecture-dependent for its size (e.g., cycles_t, tcflag_t) or +is dependent on a config option for its size (e.g., blk_status_t), use a format +specifier of its largest possible type and explicitly cast to it. Example:: - printk("test: sector number/total blocks: %llu/%llu\n", - (unsigned long long)sector, (unsigned long long)blockcount); + printk("test: latency: %llu cycles\n", (unsigned long long)time); Reminder: sizeof() returns type size_t. -- cgit v1.2.3 From b1f4c363666c31f289b26bfc7c38378f0db79b55 Mon Sep 17 00:00:00 2001 From: Baoquan He Date: Wed, 9 Jun 2021 16:32:18 +0800 Subject: Documentation: kdump: update kdump guide Some parts of the guide are aged, hence need be updated. 1) The backup area of the 1st 640K on X86_64 has been removed by below commits, update the description accordingly. commit 7c321eb2b843 ("x86/kdump: Remove the backup region handling") commit 6f599d84231f ("x86/kdump: Always reserve the low 1M when the crashkernel option is specified") 2) Sort out the descripiton of "crashkernel syntax" part. 3) And some other minor cleanups. Signed-off-by: Baoquan He Acked-by: Dave Young Link: https://lore.kernel.org/r/20210609083218.GB591017@MiWiFi-R3L-srv [jc: added blank line to fix added build warning] Signed-off-by: Jonathan Corbet --- Documentation/admin-guide/kdump/kdump.rst | 170 +++++++++++++++++++----------- 1 file changed, 109 insertions(+), 61 deletions(-) (limited to 'Documentation') diff --git a/Documentation/admin-guide/kdump/kdump.rst b/Documentation/admin-guide/kdump/kdump.rst index 75a9dd98e76e..cb30ca3df27c 100644 --- a/Documentation/admin-guide/kdump/kdump.rst +++ b/Documentation/admin-guide/kdump/kdump.rst @@ -2,7 +2,7 @@ Documentation for Kdump - The kexec-based Crash Dumping Solution ================================================================ -This document includes overview, setup and installation, and analysis +This document includes overview, setup, installation, and analysis information. Overview @@ -13,9 +13,9 @@ dump of the system kernel's memory needs to be taken (for example, when the system panics). The system kernel's memory image is preserved across the reboot and is accessible to the dump-capture kernel. -You can use common commands, such as cp and scp, to copy the -memory image to a dump file on the local disk, or across the network to -a remote system. +You can use common commands, such as cp, scp or makedumpfile to copy +the memory image to a dump file on the local disk, or across the network +to a remote system. Kdump and kexec are currently supported on the x86, x86_64, ppc64, ia64, s390x, arm and arm64 architectures. @@ -26,13 +26,15 @@ the dump-capture kernel. This ensures that ongoing Direct Memory Access The kexec -p command loads the dump-capture kernel into this reserved memory. -On x86 machines, the first 640 KB of physical memory is needed to boot, -regardless of where the kernel loads. Therefore, kexec backs up this -region just before rebooting into the dump-capture kernel. +On x86 machines, the first 640 KB of physical memory is needed for boot, +regardless of where the kernel loads. For simpler handling, the whole +low 1M is reserved to avoid any later kernel or device driver writing +data into this area. Like this, the low 1M can be reused as system RAM +by kdump kernel without extra handling. -Similarly on PPC64 machines first 32KB of physical memory is needed for -booting regardless of where the kernel is loaded and to support 64K page -size kexec backs up the first 64KB memory. +On PPC64 machines first 32KB of physical memory is needed for booting +regardless of where the kernel is loaded and to support 64K page size +kexec backs up the first 64KB memory. For s390x, when kdump is triggered, the crashkernel region is exchanged with the region [0, crashkernel region size] and then the kdump kernel @@ -46,14 +48,14 @@ passed to the dump-capture kernel through the elfcorehdr= boot parameter. Optionally the size of the ELF header can also be passed when using the elfcorehdr=[size[KMG]@]offset[KMG] syntax. - With the dump-capture kernel, you can access the memory image through /proc/vmcore. This exports the dump as an ELF-format file that you can -write out using file copy commands such as cp or scp. Further, you can -use analysis tools such as the GNU Debugger (GDB) and the Crash tool to -debug the dump file. This method ensures that the dump pages are correctly -ordered. - +write out using file copy commands such as cp or scp. You can also use +makedumpfile utility to analyze and write out filtered contents with +options, e.g with '-d 31' it will only write out kernel data. Further, +you can use analysis tools such as the GNU Debugger (GDB) and the Crash +tool to debug the dump file. This method ensures that the dump pages are +correctly ordered. Setup and Installation ====================== @@ -125,9 +127,18 @@ dump-capture kernels for enabling kdump support. System kernel config options ---------------------------- -1) Enable "kexec system call" in "Processor type and features.":: +1) Enable "kexec system call" or "kexec file based system call" in + "Processor type and features.":: + + CONFIG_KEXEC=y or CONFIG_KEXEC_FILE=y + + And both of them will select KEXEC_CORE:: - CONFIG_KEXEC=y + CONFIG_KEXEC_CORE=y + + Subsequently, CRASH_CORE is selected by KEXEC_CORE:: + + CONFIG_CRASH_CORE=y 2) Enable "sysfs file system support" in "Filesystem" -> "Pseudo filesystems." This is usually enabled by default:: @@ -175,17 +186,19 @@ Dump-capture kernel config options (Arch Dependent, i386 and x86_64) CONFIG_HIGHMEM4G -2) On i386 and x86_64, disable symmetric multi-processing support - under "Processor type and features":: +2) With CONFIG_SMP=y, usually nr_cpus=1 need specified on the kernel + command line when loading the dump-capture kernel because one + CPU is enough for kdump kernel to dump vmcore on most of systems. - CONFIG_SMP=n + However, you can also specify nr_cpus=X to enable multiple processors + in kdump kernel. In this case, "disable_cpu_apicid=" is needed to + tell kdump kernel which cpu is 1st kernel's BSP. Please refer to + admin-guide/kernel-parameters.txt for more details. - (If CONFIG_SMP=y, then specify maxcpus=1 on the kernel command line - when loading the dump-capture kernel, see section "Load the Dump-capture - Kernel".) + With CONFIG_SMP=n, the above things are not related. -3) If one wants to build and use a relocatable kernel, - Enable "Build a relocatable kernel" support under "Processor type and +3) A relocatable kernel is suggested to be built by default. If not yet, + enable "Build a relocatable kernel" support under "Processor type and features":: CONFIG_RELOCATABLE=y @@ -232,7 +245,7 @@ Dump-capture kernel config options (Arch Dependent, ia64) as a dump-capture kernel if desired. The crashkernel region can be automatically placed by the system - kernel at run time. This is done by specifying the base address as 0, + kernel at runtime. This is done by specifying the base address as 0, or omitting it all together:: crashkernel=256M@0 @@ -241,10 +254,6 @@ Dump-capture kernel config options (Arch Dependent, ia64) crashkernel=256M - If the start address is specified, note that the start address of the - kernel will be aligned to 64Mb, so if the start address is not then - any space below the alignment point will be wasted. - Dump-capture kernel config options (Arch Dependent, arm) ---------------------------------------------------------- @@ -260,46 +269,82 @@ Dump-capture kernel config options (Arch Dependent, arm64) on non-VHE systems even if it is configured. This is because the CPU will not be reset to EL2 on panic. -Extended crashkernel syntax +crashkernel syntax =========================== +1) crashkernel=size@offset -While the "crashkernel=size[@offset]" syntax is sufficient for most -configurations, sometimes it's handy to have the reserved memory dependent -on the value of System RAM -- that's mostly for distributors that pre-setup -the kernel command line to avoid a unbootable system after some memory has -been removed from the machine. + Here 'size' specifies how much memory to reserve for the dump-capture kernel + and 'offset' specifies the beginning of this reserved memory. For example, + "crashkernel=64M@16M" tells the system kernel to reserve 64 MB of memory + starting at physical address 0x01000000 (16MB) for the dump-capture kernel. -The syntax is:: + The crashkernel region can be automatically placed by the system + kernel at run time. This is done by specifying the base address as 0, + or omitting it all together:: - crashkernel=:[,:,...][@offset] - range=start-[end] + crashkernel=256M@0 -For example:: + or:: - crashkernel=512M-2G:64M,2G-:128M + crashkernel=256M -This would mean: + If the start address is specified, note that the start address of the + kernel will be aligned to a value (which is Arch dependent), so if the + start address is not then any space below the alignment point will be + wasted. - 1) if the RAM is smaller than 512M, then don't reserve anything - (this is the "rescue" case) - 2) if the RAM size is between 512M and 2G (exclusive), then reserve 64M - 3) if the RAM size is larger than 2G, then reserve 128M +2) range1:size1[,range2:size2,...][@offset] + While the "crashkernel=size[@offset]" syntax is sufficient for most + configurations, sometimes it's handy to have the reserved memory dependent + on the value of System RAM -- that's mostly for distributors that pre-setup + the kernel command line to avoid a unbootable system after some memory has + been removed from the machine. + The syntax is:: -Boot into System Kernel -======================= + crashkernel=:[,:,...][@offset] + range=start-[end] + + For example:: + + crashkernel=512M-2G:64M,2G-:128M + This would mean: + + 1) if the RAM is smaller than 512M, then don't reserve anything + (this is the "rescue" case) + 2) if the RAM size is between 512M and 2G (exclusive), then reserve 64M + 3) if the RAM size is larger than 2G, then reserve 128M + +3) crashkernel=size,high and crashkernel=size,low + + If memory above 4G is preferred, crashkernel=size,high can be used to + fulfill that. With it, physical memory is allowed to be allocated from top, + so could be above 4G if system has more than 4G RAM installed. Otherwise, + memory region will be allocated below 4G if available. + + When crashkernel=X,high is passed, kernel could allocate physical memory + region above 4G, low memory under 4G is needed in this case. There are + three ways to get low memory: + + 1) Kernel will allocate at least 256M memory below 4G automatically + if crashkernel=Y,low is not specified. + 2) Let user specify low memory size instead. + 3) Specified value 0 will disable low memory allocation:: + + crashkernel=0,low + +Boot into System Kernel +----------------------- 1) Update the boot loader (such as grub, yaboot, or lilo) configuration files as necessary. -2) Boot the system kernel with the boot parameter "crashkernel=Y@X", - where Y specifies how much memory to reserve for the dump-capture kernel - and X specifies the beginning of this reserved memory. For example, - "crashkernel=64M@16M" tells the system kernel to reserve 64 MB of memory - starting at physical address 0x01000000 (16MB) for the dump-capture kernel. +2) Boot the system kernel with the boot parameter "crashkernel=Y@X". - On x86 and x86_64, use "crashkernel=64M@16M". + On x86 and x86_64, use "crashkernel=Y[@X]". Most of the time, the + start address 'X' is not necessary, kernel will search a suitable + area. Unless an explicit start address is expected. On ppc64, use "crashkernel=128M@32M". @@ -331,8 +376,8 @@ of dump-capture kernel. Following is the summary. For i386 and x86_64: - - Use vmlinux if kernel is not relocatable. - Use bzImage/vmlinuz if kernel is relocatable. + - Use vmlinux if kernel is not relocatable. For ppc64: @@ -392,7 +437,7 @@ loading dump-capture kernel. For i386, x86_64 and ia64: - "1 irqpoll maxcpus=1 reset_devices" + "1 irqpoll nr_cpus=1 reset_devices" For ppc64: @@ -400,7 +445,7 @@ For ppc64: For s390x: - "1 maxcpus=1 cgroup_disable=memory" + "1 nr_cpus=1 cgroup_disable=memory" For arm: @@ -408,7 +453,7 @@ For arm: For arm64: - "1 maxcpus=1 reset_devices" + "1 nr_cpus=1 reset_devices" Notes on loading the dump-capture kernel: @@ -488,6 +533,10 @@ the following command:: cp /proc/vmcore +You can also use makedumpfile utility to write out the dump file +with specified options to filter out unwanted contents, e.g:: + + makedumpfile -l --message-level 1 -d 31 /proc/vmcore Analysis ======== @@ -535,8 +584,7 @@ This will cause a kdump to occur at the add_taint()->panic() call. Contact ======= -- Vivek Goyal (vgoyal@redhat.com) -- Maneesh Soni (maneesh@in.ibm.com) +- kexec@lists.infradead.org GDB macros ========== -- cgit v1.2.3 From 66826c43e63d5c5e8307bd36862d6334db9d98b7 Mon Sep 17 00:00:00 2001 From: Oleksandr Mazur Date: Mon, 14 Jun 2021 16:01:18 +0300 Subject: documentation: networking: devlink: add prestera switched driver Documentation Add documentation for the devlink feature prestera switchdev driver supports: add description for the support of the driver-specific devlink traps (include both traps with action TRAP and action DROP); Signed-off-by: Oleksandr Mazur Signed-off-by: David S. Miller --- Documentation/networking/devlink/prestera.rst | 141 ++++++++++++++++++++++++++ 1 file changed, 141 insertions(+) create mode 100644 Documentation/networking/devlink/prestera.rst (limited to 'Documentation') diff --git a/Documentation/networking/devlink/prestera.rst b/Documentation/networking/devlink/prestera.rst new file mode 100644 index 000000000000..e8b52ffd4707 --- /dev/null +++ b/Documentation/networking/devlink/prestera.rst @@ -0,0 +1,141 @@ +.. SPDX-License-Identifier: GPL-2.0 + +===================== +prestera devlink support +===================== + +This document describes the devlink features implemented by the ``prestera`` +device driver. + +Driver-specific Traps +===================== + +.. list-table:: List of Driver-specific Traps Registered by ``prestera`` + :widths: 5 5 90 + + * - Name + - Type + - Description +.. list-table:: List of Driver-specific Traps Registered by ``prestera`` + :widths: 5 5 90 + + * - Name + - Type + - Description + * - ``arp_bc`` + - ``trap`` + - Traps ARP broadcast packets (both requests/responses) + * - ``is_is`` + - ``trap`` + - Traps IS-IS packets + * - ``ospf`` + - ``trap`` + - Traps OSPF packets + * - ``ip_bc_mac`` + - ``trap`` + - Traps IPv4 packets with broadcast DA Mac address + * - ``stp`` + - ``trap`` + - Traps STP BPDU + * - ``lacp`` + - ``trap`` + - Traps LACP packets + * - ``lldp`` + - ``trap`` + - Traps LLDP packets + * - ``router_mc`` + - ``trap`` + - Traps multicast packets + * - ``vrrp`` + - ``trap`` + - Traps VRRP packets + * - ``dhcp`` + - ``trap`` + - Traps DHCP packets + * - ``mtu_error`` + - ``trap`` + - Traps (exception) packets that exceeded port's MTU + * - ``mac_to_me`` + - ``trap`` + - Traps packets with switch-port's DA Mac address + * - ``ttl_error`` + - ``trap`` + - Traps (exception) IPv4 packets whose TTL exceeded + * - ``ipv4_options`` + - ``trap`` + - Traps (exception) packets due to the malformed IPV4 header options + * - ``ip_default_route`` + - ``trap`` + - Traps packets that have no specific IP interface (IP to me) and no forwarding prefix + * - ``local_route`` + - ``trap`` + - Traps packets that have been send to one of switch IP interfaces addresses + * - ``ipv4_icmp_redirect`` + - ``trap`` + - Traps (exception) IPV4 ICMP redirect packets + * - ``arp_response`` + - ``trap`` + - Traps ARP replies packets that have switch-port's DA Mac address + * - ``acl_code_0`` + - ``trap`` + - Traps packets that have ACL priority set to 0 (tc pref 0) + * - ``acl_code_1`` + - ``trap`` + - Traps packets that have ACL priority set to 1 (tc pref 1) + * - ``acl_code_2`` + - ``trap`` + - Traps packets that have ACL priority set to 2 (tc pref 2) + * - ``acl_code_3`` + - ``trap`` + - Traps packets that have ACL priority set to 3 (tc pref 3) + * - ``acl_code_4`` + - ``trap`` + - Traps packets that have ACL priority set to 4 (tc pref 4) + * - ``acl_code_5`` + - ``trap`` + - Traps packets that have ACL priority set to 5 (tc pref 5) + * - ``acl_code_6`` + - ``trap`` + - Traps packets that have ACL priority set to 6 (tc pref 6) + * - ``acl_code_7`` + - ``trap`` + - Traps packets that have ACL priority set to 7 (tc pref 7) + * - ``ipv4_bgp`` + - ``trap`` + - Traps IPv4 BGP packets + * - ``ssh`` + - ``trap`` + - Traps SSH packets + * - ``telnet`` + - ``trap`` + - Traps Telnet packets + * - ``icmp`` + - ``trap`` + - Traps ICMP packets + * - ``rxdma_drop`` + - ``drop`` + - Drops packets (RxDMA) due to the lack of ingress buffers etc. + * - ``port_no_vlan`` + - ``drop`` + - Drops packets due to faulty-configured network or due to internal bug (config issue). + * - ``local_port`` + - ``drop`` + - Drops packets whose decision (FDB entry) is to bridge packet back to the incoming port/trunk. + * - ``invalid_sa`` + - ``drop`` + - Drops packets with multicast source MAC address. + * - ``illegal_ip_addr`` + - ``drop`` + - Drops packets with illegal SIP/DIP multicast/unicast addresses. + * - ``illegal_ipv4_hdr`` + - ``drop`` + - Drops packets with illegal IPV4 header. + * - ``ip_uc_dip_da_mismatch`` + - ``drop`` + - Drops packets with destination MAC being unicast, but destination IP address being multicast. + * - ``ip_sip_is_zero`` + - ``drop`` + - Drops packets with zero (0) IPV4 source address. + * - ``met_red`` + - ``drop`` + - Drops non-conforming packets (dropped by Ingress policer, metering drop), e.g. packet rate exceeded configured bandwith. -- cgit v1.2.3 From 3b8401066e5a8ee465891cc8bad614c797701348 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=E5=91=A8=E7=90=B0=E6=9D=B0=20=28Zhou=20Yanjie=29?= Date: Tue, 15 Jun 2021 01:15:36 +0800 Subject: dt-bindings: dwmac: Add bindings for new Ingenic SoCs. MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Add the dwmac bindings for the JZ4775 SoC, the X1000 SoC, the X1600 SoC, the X1830 SoC and the X2000 SoC from Ingenic. Signed-off-by: 周琰杰 (Zhou Yanjie) Reviewed-by: Andrew Lunn Signed-off-by: David S. Miller --- .../devicetree/bindings/net/ingenic,mac.yaml | 76 ++++++++++++++++++++++ .../devicetree/bindings/net/snps,dwmac.yaml | 15 +++++ 2 files changed, 91 insertions(+) create mode 100644 Documentation/devicetree/bindings/net/ingenic,mac.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/ingenic,mac.yaml b/Documentation/devicetree/bindings/net/ingenic,mac.yaml new file mode 100644 index 000000000000..5e93d4f9a080 --- /dev/null +++ b/Documentation/devicetree/bindings/net/ingenic,mac.yaml @@ -0,0 +1,76 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/ingenic,mac.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Bindings for MAC in Ingenic SoCs + +maintainers: + - 周琰杰 (Zhou Yanjie) + +description: + The Ethernet Media Access Controller in Ingenic SoCs. + +properties: + compatible: + enum: + - ingenic,jz4775-mac + - ingenic,x1000-mac + - ingenic,x1600-mac + - ingenic,x1830-mac + - ingenic,x2000-mac + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + interrupt-names: + const: macirq + + clocks: + maxItems: 1 + + clock-names: + const: stmmaceth + + mode-reg: + description: An extra syscon register that control ethernet interface and timing delay + + rx-clk-delay-ps: + description: RGMII receive clock delay defined in pico seconds + + tx-clk-delay-ps: + description: RGMII transmit clock delay defined in pico seconds + +required: + - compatible + - reg + - interrupts + - interrupt-names + - clocks + - clock-names + - mode-reg + +additionalProperties: false + +examples: + - | + #include + + mac: ethernet@134b0000 { + compatible = "ingenic,x1000-mac", "snps,dwmac"; + reg = <0x134b0000 0x2000>; + + interrupt-parent = <&intc>; + interrupts = <55>; + interrupt-names = "macirq"; + + clocks = <&cgu X1000_CLK_MAC>; + clock-names = "stmmaceth"; + + mode-reg = <&mac_phy_ctrl>; + }; +... diff --git a/Documentation/devicetree/bindings/net/snps,dwmac.yaml b/Documentation/devicetree/bindings/net/snps,dwmac.yaml index 2edd8bea993e..9c0ce92e9212 100644 --- a/Documentation/devicetree/bindings/net/snps,dwmac.yaml +++ b/Documentation/devicetree/bindings/net/snps,dwmac.yaml @@ -56,6 +56,11 @@ properties: - amlogic,meson8m2-dwmac - amlogic,meson-gxbb-dwmac - amlogic,meson-axg-dwmac + - ingenic,jz4775-mac + - ingenic,x1000-mac + - ingenic,x1600-mac + - ingenic,x1830-mac + - ingenic,x2000-mac - rockchip,px30-gmac - rockchip,rk3128-gmac - rockchip,rk3228-gmac @@ -310,6 +315,11 @@ allOf: - allwinner,sun8i-r40-emac - allwinner,sun8i-v3s-emac - allwinner,sun50i-a64-emac + - ingenic,jz4775-mac + - ingenic,x1000-mac + - ingenic,x1600-mac + - ingenic,x1830-mac + - ingenic,x2000-mac - snps,dwxgmac - snps,dwxgmac-2.10 - st,spear600-gmac @@ -353,6 +363,11 @@ allOf: - allwinner,sun8i-r40-emac - allwinner,sun8i-v3s-emac - allwinner,sun50i-a64-emac + - ingenic,jz4775-mac + - ingenic,x1000-mac + - ingenic,x1600-mac + - ingenic,x1830-mac + - ingenic,x2000-mac - snps,dwmac-4.00 - snps,dwmac-4.10a - snps,dwmac-4.20a -- cgit v1.2.3 From 234462bc7f2303afce4b61125d2107ecd7611bff Mon Sep 17 00:00:00 2001 From: Suman Anna Date: Thu, 3 Jun 2021 09:42:16 -0500 Subject: dt-bindings: hwlock: sun6i: Fix various warnings in binding The allwinner,sun6i-a31-hwspinlock.yaml binding has a mismatched $id and fails to compile the example due to undefined args specifier values for clocks and resets. Fix both of these issues. Acked-by: Rob Herring Fixes: f9e784dcb63f ("dt-bindings: hwlock: add sun6i_hwspinlock") Signed-off-by: Suman Anna Link: https://lore.kernel.org/r/20210603144216.10327-1-s-anna@ti.com Signed-off-by: Bjorn Andersson --- .../devicetree/bindings/hwlock/allwinner,sun6i-a31-hwspinlock.yaml | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/hwlock/allwinner,sun6i-a31-hwspinlock.yaml b/Documentation/devicetree/bindings/hwlock/allwinner,sun6i-a31-hwspinlock.yaml index 733c3d01e56c..10e5a53e447b 100644 --- a/Documentation/devicetree/bindings/hwlock/allwinner,sun6i-a31-hwspinlock.yaml +++ b/Documentation/devicetree/bindings/hwlock/allwinner,sun6i-a31-hwspinlock.yaml @@ -1,7 +1,7 @@ # SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause) %YAML 1.2 --- -$id: http://devicetree.org/schemas/hwlock/allwinner,sun6i-hwspinlock.yaml# +$id: http://devicetree.org/schemas/hwlock/allwinner,sun6i-a31-hwspinlock.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# title: SUN6I hardware spinlock driver for Allwinner sun6i compatible SoCs @@ -36,6 +36,9 @@ additionalProperties: false examples: - | + #include + #include + hwlock@1c18000 { compatible = "allwinner,sun6i-a31-hwspinlock"; reg = <0x01c18000 0x1000>; -- cgit v1.2.3 From 30da589dba53d2a0b64efe0bb93919833bc43366 Mon Sep 17 00:00:00 2001 From: Suman Anna Date: Thu, 3 Jun 2021 09:26:39 -0500 Subject: dt-bindings: remoteproc: qcom: pas: Fix indentation warnings The list indentation should always be 2 spaces more than the preceding keyword. A few of the items are only using 1 space, and resulting in warnings with dt_binding_check. Fix these. Fixes: cf107e98d024 ("dt-bindings: remoteproc: qcom: pas: Convert binding to YAML") Signed-off-by: Suman Anna Link: https://lore.kernel.org/r/20210603142639.8335-1-s-anna@ti.com Signed-off-by: Bjorn Andersson --- .../devicetree/bindings/remoteproc/qcom,adsp.yaml | 38 +++++++++++----------- 1 file changed, 19 insertions(+), 19 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,adsp.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,adsp.yaml index 6c11812385ca..9ea05e608bc1 100644 --- a/Documentation/devicetree/bindings/remoteproc/qcom,adsp.yaml +++ b/Documentation/devicetree/bindings/remoteproc/qcom,adsp.yaml @@ -329,7 +329,7 @@ allOf: - description: CX power domain power-domain-names: items: - - const: cx + - const: cx - if: properties: @@ -345,7 +345,7 @@ allOf: - description: SSC-CX power domain power-domain-names: items: - - const: ssc_cx + - const: ssc_cx required: - px-supply @@ -365,10 +365,10 @@ allOf: - description: MSS power domain power-domain-names: items: - - const: load_state - - const: cx - - const: mx - - const: mss + - const: load_state + - const: cx + - const: mx + - const: mss - if: properties: @@ -385,8 +385,8 @@ allOf: - description: CX power domain power-domain-names: items: - - const: load_state - - const: cx + - const: load_state + - const: cx - if: properties: @@ -404,9 +404,9 @@ allOf: - description: MSS power domain power-domain-names: items: - - const: load_state - - const: cx - - const: mss + - const: load_state + - const: cx + - const: mss - if: properties: @@ -422,8 +422,8 @@ allOf: - description: MSS power domain power-domain-names: items: - - const: cx - - const: mss + - const: cx + - const: mss - if: properties: @@ -444,9 +444,9 @@ allOf: - description: LMX power domain power-domain-names: items: - - const: load_state - - const: lcx - - const: lmx + - const: load_state + - const: lcx + - const: lmx - if: properties: @@ -463,9 +463,9 @@ allOf: - description: MXC power domain power-domain-names: items: - - const: load_state - - const: cx - - const: mxc + - const: load_state + - const: cx + - const: mxc - if: properties: -- cgit v1.2.3 From 91a1265cacdd96229304adddf18dcf64a4b8c040 Mon Sep 17 00:00:00 2001 From: Dwaipayan Ray Date: Mon, 14 Jun 2021 19:41:32 +0530 Subject: docs: checkpatch: Document and segregate more checkpatch message types Add and document more checkpatch message types. About 50% of all message types are documented now. In addition to this: - Create a new subsection 'Indentation and Line Breaks'. - Rename subsection 'Comment style' to simply 'Comments'. - Refactor some of the existing types to appropriate subsections. Reviewed-by: Lukas Bulwahn Tested-by: Lukas Bulwahn Signed-off-by: Dwaipayan Ray Link: https://lore.kernel.org/r/20210614141132.6881-1-dwaipayanray1@gmail.com Signed-off-by: Jonathan Corbet --- Documentation/dev-tools/checkpatch.rst | 399 +++++++++++++++++++++++++++------ 1 file changed, 328 insertions(+), 71 deletions(-) (limited to 'Documentation') diff --git a/Documentation/dev-tools/checkpatch.rst b/Documentation/dev-tools/checkpatch.rst index 87b859f321de..f0956e9ea2d8 100644 --- a/Documentation/dev-tools/checkpatch.rst +++ b/Documentation/dev-tools/checkpatch.rst @@ -298,10 +298,148 @@ API usage See: https://www.kernel.org/doc/html/latest/process/deprecated.html#simple-strtol-simple-strtoll-simple-strtoul-simple-strtoull + **CONSTANT_CONVERSION** + Use of __constant_ form is discouraged for the following functions:: + + __constant_cpu_to_be[x] + __constant_cpu_to_le[x] + __constant_be[x]_to_cpu + __constant_le[x]_to_cpu + __constant_htons + __constant_ntohs + + Using any of these outside of include/uapi/ is not preferred as using the + function without __constant_ is identical when the argument is a + constant. + + In big endian systems, the macros like __constant_cpu_to_be32(x) and + cpu_to_be32(x) expand to the same expression:: + + #define __constant_cpu_to_be32(x) ((__force __be32)(__u32)(x)) + #define __cpu_to_be32(x) ((__force __be32)(__u32)(x)) + + In little endian systems, the macros __constant_cpu_to_be32(x) and + cpu_to_be32(x) expand to __constant_swab32 and __swab32. __swab32 + has a __builtin_constant_p check:: + + #define __swab32(x) \ + (__builtin_constant_p((__u32)(x)) ? \ + ___constant_swab32(x) : \ + __fswab32(x)) + + So ultimately they have a special case for constants. + Similar is the case with all of the macros in the list. Thus + using the __constant_... forms are unnecessarily verbose and + not preferred outside of include/uapi. + + See: https://lore.kernel.org/lkml/1400106425.12666.6.camel@joe-AO725/ + + **DEPRECATED_API** + Usage of a deprecated RCU API is detected. It is recommended to replace + old flavourful RCU APIs by their new vanilla-RCU counterparts. + + The full list of available RCU APIs can be viewed from the kernel docs. + + See: https://www.kernel.org/doc/html/latest/RCU/whatisRCU.html#full-list-of-rcu-apis + + **DEPRECATED_VARIABLE** + EXTRA_{A,C,CPP,LD}FLAGS are deprecated and should be replaced by the new + flags added via commit f77bf01425b1 ("kbuild: introduce ccflags-y, + asflags-y and ldflags-y"). + + The following conversion scheme maybe used:: + + EXTRA_AFLAGS -> asflags-y + EXTRA_CFLAGS -> ccflags-y + EXTRA_CPPFLAGS -> cppflags-y + EXTRA_LDFLAGS -> ldflags-y + + See: + + 1. https://lore.kernel.org/lkml/20070930191054.GA15876@uranus.ravnborg.org/ + 2. https://lore.kernel.org/lkml/1313384834-24433-12-git-send-email-lacombar@gmail.com/ + 3. https://www.kernel.org/doc/html/latest/kbuild/makefiles.html#compilation-flags + + **DEVICE_ATTR_FUNCTIONS** + The function names used in DEVICE_ATTR is unusual. + Typically, the store and show functions are used with _store and + _show, where is a named attribute variable of the device. + + Consider the following examples:: + + static DEVICE_ATTR(type, 0444, type_show, NULL); + static DEVICE_ATTR(power, 0644, power_show, power_store); + + The function names should preferably follow the above pattern. + + See: https://www.kernel.org/doc/html/latest/driver-api/driver-model/device.html#attributes + + **DEVICE_ATTR_RO** + The DEVICE_ATTR_RO(name) helper macro can be used instead of + DEVICE_ATTR(name, 0444, name_show, NULL); + + Note that the macro automatically appends _show to the named + attribute variable of the device for the show method. + + See: https://www.kernel.org/doc/html/latest/driver-api/driver-model/device.html#attributes + + **DEVICE_ATTR_RW** + The DEVICE_ATTR_RW(name) helper macro can be used instead of + DEVICE_ATTR(name, 0644, name_show, name_store); + + Note that the macro automatically appends _show and _store to the + named attribute variable of the device for the show and store methods. + + See: https://www.kernel.org/doc/html/latest/driver-api/driver-model/device.html#attributes + + **DEVICE_ATTR_WO** + The DEVICE_AATR_WO(name) helper macro can be used instead of + DEVICE_ATTR(name, 0200, NULL, name_store); + + Note that the macro automatically appends _store to the + named attribute variable of the device for the store method. + + See: https://www.kernel.org/doc/html/latest/driver-api/driver-model/device.html#attributes + + **DUPLICATED_SYSCTL_CONST** + Commit d91bff3011cf ("proc/sysctl: add shared variables for range + check") added some shared const variables to be used instead of a local + copy in each source file. + + Consider replacing the sysctl range checking value with the shared + one in include/linux/sysctl.h. The following conversion scheme may + be used:: + + &zero -> SYSCTL_ZERO + &one -> SYSCTL_ONE + &int_max -> SYSCTL_INT_MAX + + See: + + 1. https://lore.kernel.org/lkml/20190430180111.10688-1-mcroce@redhat.com/ + 2. https://lore.kernel.org/lkml/20190531131422.14970-1-mcroce@redhat.com/ + + **ENOSYS** + ENOSYS means that a nonexistent system call was called. + Earlier, it was wrongly used for things like invalid operations on + otherwise valid syscalls. This should be avoided in new code. + + See: https://lore.kernel.org/lkml/5eb299021dec23c1a48fa7d9f2c8b794e967766d.1408730669.git.luto@amacapital.net/ + + **ENOTSUPP** + ENOTSUPP is not a standard error code and should be avoided in new patches. + EOPNOTSUPP should be used instead. + + See: https://lore.kernel.org/netdev/20200510182252.GA411829@lunn.ch/ + + **EXPORT_SYMBOL** + EXPORT_SYMBOL should immediately follow the symbol to be exported. + **IN_ATOMIC** in_atomic() is not for driver use so any such use is reported as an ERROR. - Also in_atomic() is often used to determine if we may sleep, but it is not - reliable in this use model therefore its use is strongly discouraged. + Also in_atomic() is often used to determine if sleeping is permitted, + but it is not reliable in this use model. Therefore its use is + strongly discouraged. However, in_atomic() is ok for core kernel use. @@ -335,8 +473,8 @@ API usage See: https://www.kernel.org/doc/html/latest/timers/timers-howto.html#delays-information-on-the-various-kernel-delay-sleep-mechanisms -Comment style -------------- +Comments +-------- **BLOCK_COMMENT_STYLE** The comment style is incorrect. The preferred style for multi- @@ -362,6 +500,21 @@ Comment style See: https://www.kernel.org/doc/html/latest/process/coding-style.html#commenting + **DATA_RACE** + Applications of data_race() should have a comment so as to document the + reasoning behind why it was deemed safe. + + See: https://lore.kernel.org/lkml/20200401101714.44781-1-elver@google.com/ + + **FSF_MAILING_ADDRESS** + Kernel maintainers reject new instances of the GPL boilerplate paragraph + directing people to write to the FSF for a copy of the GPL, since the + FSF has moved in the past and may do so again. + So do not write paragraphs about writing to the Free Software Foundation's + mailing address. + + See: https://lore.kernel.org/lkml/20131006222342.GT19510@leaf/ + Commit message -------------- @@ -394,6 +547,13 @@ Commit message See: https://www.kernel.org/doc/html/latest/process/submitting-patches.html#describe-your-changes + **EMAIL_SUBJECT** + Naming the tool that found the issue is not very useful in the + subject line. A good subject line summarizes the change that + the patch brings. + + See: https://www.kernel.org/doc/html/latest/process/submitting-patches.html#describe-your-changes + **FROM_SIGN_OFF_MISMATCH** The author's email does not match with that in the Signed-off-by: line(s). This can be sometimes caused due to an improperly configured @@ -482,6 +642,87 @@ Comparison style side of the test should be avoided. +Indentation and Line Breaks +--------------------------- + + **CODE_INDENT** + Code indent should use tabs instead of spaces. + Outside of comments, documentation and Kconfig, + spaces are never used for indentation. + + See: https://www.kernel.org/doc/html/latest/process/coding-style.html#indentation + + **DEEP_INDENTATION** + Indentation with 6 or more tabs usually indicate overly indented + code. + + It is suggested to refactor excessive indentation of + if/else/for/do/while/switch statements. + + See: https://lore.kernel.org/lkml/1328311239.21255.24.camel@joe2Laptop/ + + **SWITCH_CASE_INDENT_LEVEL** + switch should be at the same indent as case. + Example:: + + switch (suffix) { + case 'G': + case 'g': + mem <<= 30; + break; + case 'M': + case 'm': + mem <<= 20; + break; + case 'K': + case 'k': + mem <<= 10; + fallthrough; + default: + break; + } + + See: https://www.kernel.org/doc/html/latest/process/coding-style.html#indentation + + **LONG_LINE** + The line has exceeded the specified maximum length. + To use a different maximum line length, the --max-line-length=n option + may be added while invoking checkpatch. + + Earlier, the default line length was 80 columns. Commit bdc48fa11e46 + ("checkpatch/coding-style: deprecate 80-column warning") increased the + limit to 100 columns. This is not a hard limit either and it's + preferable to stay within 80 columns whenever possible. + + See: https://www.kernel.org/doc/html/latest/process/coding-style.html#breaking-long-lines-and-strings + + **LONG_LINE_STRING** + A string starts before but extends beyond the maximum line length. + To use a different maximum line length, the --max-line-length=n option + may be added while invoking checkpatch. + + See: https://www.kernel.org/doc/html/latest/process/coding-style.html#breaking-long-lines-and-strings + + **LONG_LINE_COMMENT** + A comment starts before but extends beyond the maximum line length. + To use a different maximum line length, the --max-line-length=n option + may be added while invoking checkpatch. + + See: https://www.kernel.org/doc/html/latest/process/coding-style.html#breaking-long-lines-and-strings + + **TRAILING_STATEMENTS** + Trailing statements (for example after any conditional) should be + on the next line. + Statements, such as:: + + if (x == y) break; + + should be:: + + if (x == y) + break; + + Macros, Attributes and Symbols ------------------------------ @@ -546,6 +787,9 @@ Macros, Attributes and Symbols See: https://lore.kernel.org/lkml/CA+55aFycQ9XJvEOsiM3txHL5bjUc8CeKWJNR_H+MiicaddB42Q@mail.gmail.com/ + **DO_WHILE_MACRO_WITH_TRAILING_SEMICOLON** + do {} while(0) macros should not have a trailing semicolon. + **INIT_ATTRIBUTE** Const init definitions should use __initconst instead of __initdata. @@ -614,6 +858,48 @@ Functions and Variables See: https://www.kernel.org/doc/html/latest/process/coding-style.html#naming + **CONST_CONST** + Using `const const *` is generally meant to be + written `const * const`. + + **CONST_STRUCT** + Using const is generally a good idea. Checkpatch reads + a list of frequently used structs that are always or + almost always constant. + + The existing structs list can be viewed from + `scripts/const_structs.checkpatch`. + + See: https://lore.kernel.org/lkml/alpine.DEB.2.10.1608281509480.3321@hadrien/ + + **EMBEDDED_FUNCTION_NAME** + Embedded function names are less appropriate to use as + refactoring can cause function renaming. Prefer the use of + "%s", __func__ to embedded function names. + + Note that this does not work with -f (--file) checkpatch option + as it depends on patch context providing the function name. + + **FUNCTION_ARGUMENTS** + This warning is emitted due to any of the following reasons: + + 1. Arguments for the function declaration do not follow + the identifier name. Example:: + + void foo + (int bar, int baz) + + This should be corrected to:: + + void foo(int bar, int baz) + + 2. Some arguments for the function definition do not + have an identifier name. Example:: + + void foo(int) + + All arguments should have identifier names. + **FUNCTION_WITHOUT_ARGS** Function declarations without arguments like:: @@ -647,6 +933,13 @@ Functions and Variables Permissions ----------- + **DEVICE_ATTR_PERMS** + The permissions used in DEVICE_ATTR are unusual. + Typically only three permissions are used - 0644 (RW), 0444 (RO) + and 0200 (WO). + + See: https://www.kernel.org/doc/html/latest/filesystems/sysfs.html#attributes + **EXECUTE_PERMISSIONS** There is no reason for source files to be executable. The executable bit can be removed safely. @@ -708,13 +1001,6 @@ Spacing and Brackets = { [0...10] = 5 } - **CODE_INDENT** - Code indent should use tabs instead of spaces. - Outside of comments, documentation and Kconfig, - spaces are never used for indentation. - - See: https://www.kernel.org/doc/html/latest/process/coding-style.html#indentation - **CONCATENATED_STRING** Concatenated elements should have a space in between. Example:: @@ -760,29 +1046,6 @@ Spacing and Brackets See: https://www.kernel.org/doc/html/latest/process/coding-style.html#spaces - **SWITCH_CASE_INDENT_LEVEL** - switch should be at the same indent as case. - Example:: - - switch (suffix) { - case 'G': - case 'g': - mem <<= 30; - break; - case 'M': - case 'm': - mem <<= 20; - break; - case 'K': - case 'k': - mem <<= 10; - /* fall through */ - default: - break; - } - - See: https://www.kernel.org/doc/html/latest/process/coding-style.html#indentation - **TRAILING_WHITESPACE** Trailing whitespace should always be removed. Some editors highlight the trailing whitespace and cause visual @@ -791,7 +1054,7 @@ Spacing and Brackets See: https://www.kernel.org/doc/html/latest/process/coding-style.html#spaces **UNNECESSARY_PARENTHESES** - Parentheses are not required in the following cases:: + Parentheses are not required in the following cases: 1. Function pointer uses:: @@ -842,40 +1105,46 @@ Others The patch seems to be corrupted or lines are wrapped. Please regenerate the patch file before sending it to the maintainer. + **CVS_KEYWORD** + Since linux moved to git, the CVS markers are no longer used. + So, CVS style keywords ($Id$, $Revision$, $Log$) should not be + added. + + **DEFAULT_NO_BREAK** + switch default case is sometimes written as "default:;". This can + cause new cases added below default to be defective. + + A "break;" should be added after empty default statement to avoid + unwanted fallthrough. + **DOS_LINE_ENDINGS** For DOS-formatted patches, there are extra ^M symbols at the end of the line. These should be removed. - **FSF_MAILING_ADDRESS** - Kernel maintainers reject new instances of the GPL boilerplate paragraph - directing people to write to the FSF for a copy of the GPL, since the - FSF has moved in the past and may do so again. - So do not write paragraphs about writing to the Free Software Foundation's - mailing address. + **DT_SCHEMA_BINDING_PATCH** + DT bindings moved to a json-schema based format instead of + freeform text. - See: https://lore.kernel.org/lkml/20131006222342.GT19510@leaf/ + See: https://www.kernel.org/doc/html/latest/devicetree/bindings/writing-schema.html - **LONG_LINE** - The line has exceeded the specified maximum length. Consider refactoring - it. - To use a different maximum line length, the --max-line-length=n option - may be added while invoking checkpatch. + **DT_SPLIT_BINDING_PATCH** + Devicetree bindings should be their own patch. This is because + bindings are logically independent from a driver implementation, + they have a different maintainer (even though they often + are applied via the same tree), and it makes for a cleaner history in the + DT only tree created with git-filter-branch. - See: https://www.kernel.org/doc/html/latest/process/coding-style.html#breaking-long-lines-and-strings + See: https://www.kernel.org/doc/html/latest/devicetree/bindings/submitting-patches.html#i-for-patch-submitters - **LONG_LINE_STRING** - A string starts before but extends beyond the maximum line length. - To use a different maximum line length, the --max-line-length=n option - may be added while invoking checkpatch. + **EMBEDDED_FILENAME** + Embedding the complete filename path inside the file isn't particularly + useful as often the path is moved around and becomes incorrect. - See: https://www.kernel.org/doc/html/latest/process/coding-style.html#breaking-long-lines-and-strings + **FILE_PATH_CHANGES** + Whenever files are added, moved, or deleted, the MAINTAINERS file + patterns can be out of sync or outdated. - **LONG_LINE_COMMENT** - A comment starts before but extends beyond the maximum line length. - To use a different maximum line length, the --max-line-length=n option - may be added while invoking checkpatch. - - See: https://www.kernel.org/doc/html/latest/process/coding-style.html#breaking-long-lines-and-strings + So MAINTAINERS might need updating in these cases. **MEMSET** The memset use appears to be incorrect. This may be caused due to @@ -895,17 +1164,5 @@ Others See: https://www.kernel.org/doc/html/latest/process/license-rules.html - **TRAILING_STATEMENTS** - Trailing statements (for example after any conditional) should be - on the next line. - Like:: - - if (x == y) break; - - should be:: - - if (x == y) - break; - **TYPO_SPELLING** Some words may have been misspelled. Consider reviewing them. -- cgit v1.2.3 From 005747526d4f3c2ec995891e95cb7625161022f9 Mon Sep 17 00:00:00 2001 From: Wolfram Sang Date: Thu, 3 Jun 2021 14:58:41 +0200 Subject: docs: fault-injection: fix non-working usage of negative values Fault injection uses debugfs in a way that the provided values via sysfs are interpreted as u64. Providing negative numbers results in an error: /sys/kernel/debug/fail_function# echo -1 > times sh: write error: Invalid argument Update the docs and examples to use "printf %#x " in these cases. For "retval", reword the paragraph a little and fix a typo. Signed-off-by: Wolfram Sang Link: https://lore.kernel.org/r/20210603125841.27436-1-wsa+renesas@sang-engineering.com Signed-off-by: Jonathan Corbet --- Documentation/fault-injection/fault-injection.rst | 24 +++++++++++++---------- 1 file changed, 14 insertions(+), 10 deletions(-) (limited to 'Documentation') diff --git a/Documentation/fault-injection/fault-injection.rst b/Documentation/fault-injection/fault-injection.rst index 31ecfe44e5b4..f47d05ed0d94 100644 --- a/Documentation/fault-injection/fault-injection.rst +++ b/Documentation/fault-injection/fault-injection.rst @@ -78,8 +78,10 @@ configuration of fault-injection capabilities. - /sys/kernel/debug/fail*/times: - specifies how many times failures may happen at most. - A value of -1 means "no limit". + specifies how many times failures may happen at most. A value of -1 + means "no limit". Note, though, that this file only accepts unsigned + values. So, if you want to specify -1, you better use 'printf' instead + of 'echo', e.g.: $ printf %#x -1 > times - /sys/kernel/debug/fail*/space: @@ -167,11 +169,13 @@ configuration of fault-injection capabilities. - ERRNO: retval must be -1 to -MAX_ERRNO (-4096). - ERR_NULL: retval must be 0 or -1 to -MAX_ERRNO (-4096). -- /sys/kernel/debug/fail_function//retval: +- /sys/kernel/debug/fail_function//retval: - specifies the "error" return value to inject to the given - function for given function. This will be created when - user specifies new injection entry. + specifies the "error" return value to inject to the given function. + This will be created when the user specifies a new injection entry. + Note that this file only accepts unsigned values. So, if you want to + use a negative errno, you better use 'printf' instead of 'echo', e.g.: + $ printf %#x -12 > retval Boot option ^^^^^^^^^^^ @@ -255,7 +259,7 @@ Application Examples echo Y > /sys/kernel/debug/$FAILTYPE/task-filter echo 10 > /sys/kernel/debug/$FAILTYPE/probability echo 100 > /sys/kernel/debug/$FAILTYPE/interval - echo -1 > /sys/kernel/debug/$FAILTYPE/times + printf %#x -1 > /sys/kernel/debug/$FAILTYPE/times echo 0 > /sys/kernel/debug/$FAILTYPE/space echo 2 > /sys/kernel/debug/$FAILTYPE/verbose echo 1 > /sys/kernel/debug/$FAILTYPE/ignore-gfp-wait @@ -309,7 +313,7 @@ Application Examples echo N > /sys/kernel/debug/$FAILTYPE/task-filter echo 10 > /sys/kernel/debug/$FAILTYPE/probability echo 100 > /sys/kernel/debug/$FAILTYPE/interval - echo -1 > /sys/kernel/debug/$FAILTYPE/times + printf %#x -1 > /sys/kernel/debug/$FAILTYPE/times echo 0 > /sys/kernel/debug/$FAILTYPE/space echo 2 > /sys/kernel/debug/$FAILTYPE/verbose echo 1 > /sys/kernel/debug/$FAILTYPE/ignore-gfp-wait @@ -336,11 +340,11 @@ Application Examples FAILTYPE=fail_function FAILFUNC=open_ctree echo $FAILFUNC > /sys/kernel/debug/$FAILTYPE/inject - echo -12 > /sys/kernel/debug/$FAILTYPE/$FAILFUNC/retval + printf %#x -12 > /sys/kernel/debug/$FAILTYPE/$FAILFUNC/retval echo N > /sys/kernel/debug/$FAILTYPE/task-filter echo 100 > /sys/kernel/debug/$FAILTYPE/probability echo 0 > /sys/kernel/debug/$FAILTYPE/interval - echo -1 > /sys/kernel/debug/$FAILTYPE/times + printf %#x -1 > /sys/kernel/debug/$FAILTYPE/times echo 0 > /sys/kernel/debug/$FAILTYPE/space echo 1 > /sys/kernel/debug/$FAILTYPE/verbose -- cgit v1.2.3 From 05a463ec1bd4fd564312d6dbc0ea1e3a4701e4a4 Mon Sep 17 00:00:00 2001 From: Tian Tao Date: Fri, 11 Jun 2021 17:22:49 +1200 Subject: docs: cputopology: move the sysfs ABI description to right place Documentation/admin-guide/cputopology.rst is the wrong place to describe sysfs ABI. So move the cputopology ABI things to Documentation/ABI/stable/sysfs-devices-system-cpu and add a reference to ABI doc in Documentation/admin-guide/cputopology.rst. Link: https://lkml.kernel.org/r/20210319041618.14316-1-song.bao.hua@hisilicon.com Cc: Greg Kroah-Hartman Signed-off-by: Tian Tao Signed-off-by: Barry Song Link: https://lore.kernel.org/r/20210611052249.25776-1-song.bao.hua@hisilicon.com Signed-off-by: Jonathan Corbet --- Documentation/ABI/stable/sysfs-devices-system-cpu | 83 ++++++++++++++++++++++ Documentation/admin-guide/cputopology.rst | 85 ++--------------------- 2 files changed, 87 insertions(+), 81 deletions(-) (limited to 'Documentation') diff --git a/Documentation/ABI/stable/sysfs-devices-system-cpu b/Documentation/ABI/stable/sysfs-devices-system-cpu index 33c133e2a631..516dafea03eb 100644 --- a/Documentation/ABI/stable/sysfs-devices-system-cpu +++ b/Documentation/ABI/stable/sysfs-devices-system-cpu @@ -23,3 +23,86 @@ Description: Default value for the Data Stream Control Register (DSCR) on here). If set by a process it will be inherited by child processes. Values: 64 bit unsigned integer (bit field) + +What: /sys/devices/system/cpu/cpuX/topology/physical_package_id +Description: physical package id of cpuX. Typically corresponds to a physical + socket number, but the actual value is architecture and platform + dependent. +Values: integer + +What: /sys/devices/system/cpu/cpuX/topology/die_id +Description: the CPU die ID of cpuX. Typically it is the hardware platform's + identifier (rather than the kernel's). The actual value is + architecture and platform dependent. +Values: integer + +What: /sys/devices/system/cpu/cpuX/topology/core_id +Description: the CPU core ID of cpuX. Typically it is the hardware platform's + identifier (rather than the kernel's). The actual value is + architecture and platform dependent. +Values: integer + +What: /sys/devices/system/cpu/cpuX/topology/book_id +Description: the book ID of cpuX. Typically it is the hardware platform's + identifier (rather than the kernel's). The actual value is + architecture and platform dependent. it's only used on s390. +Values: integer + +What: /sys/devices/system/cpu/cpuX/topology/drawer_id +Description: the drawer ID of cpuX. Typically it is the hardware platform's + identifier (rather than the kernel's). The actual value is + architecture and platform dependent. it's only used on s390. +Values: integer + +What: /sys/devices/system/cpu/cpuX/topology/core_cpus +Description: internal kernel map of CPUs within the same core. + (deprecated name: "thread_siblings") +Values: hexadecimal bitmask. + +What: /sys/devices/system/cpu/cpuX/topology/core_cpus_list +Description: human-readable list of CPUs within the same core. + The format is like 0-3, 8-11, 14,17. + (deprecated name: "thread_siblings_list"). +Values: decimal list. + +What: /sys/devices/system/cpu/cpuX/topology/package_cpus +Description: internal kernel map of the CPUs sharing the same physical_package_id. + (deprecated name: "core_siblings"). +Values: hexadecimal bitmask. + +What: /sys/devices/system/cpu/cpuX/topology/package_cpus_list +Description: human-readable list of CPUs sharing the same physical_package_id. + The format is like 0-3, 8-11, 14,17. + (deprecated name: "core_siblings_list") +Values: decimal list. + +What: /sys/devices/system/cpu/cpuX/topology/die_cpus +Description: internal kernel map of CPUs within the same die. +Values: hexadecimal bitmask. + +What: /sys/devices/system/cpu/cpuX/topology/die_cpus_list +Description: human-readable list of CPUs within the same die. + The format is like 0-3, 8-11, 14,17. +Values: decimal list. + +What: /sys/devices/system/cpu/cpuX/topology/book_siblings +Description: internal kernel map of cpuX's hardware threads within the same + book_id. it's only used on s390. +Values: hexadecimal bitmask. + +What: /sys/devices/system/cpu/cpuX/topology/book_siblings_list +Description: human-readable list of cpuX's hardware threads within the same + book_id. + The format is like 0-3, 8-11, 14,17. it's only used on s390. +Values: decimal list. + +What: /sys/devices/system/cpu/cpuX/topology/drawer_siblings +Description: internal kernel map of cpuX's hardware threads within the same + drawer_id. it's only used on s390. +Values: hexadecimal bitmask. + +What: /sys/devices/system/cpu/cpuX/topology/drawer_siblings_list +Description: human-readable list of cpuX's hardware threads within the same + drawer_id. + The format is like 0-3, 8-11, 14,17. it's only used on s390. +Values: decimal list. diff --git a/Documentation/admin-guide/cputopology.rst b/Documentation/admin-guide/cputopology.rst index b90dafcc8237..8632a1db36e4 100644 --- a/Documentation/admin-guide/cputopology.rst +++ b/Documentation/admin-guide/cputopology.rst @@ -2,87 +2,10 @@ How CPU topology info is exported via sysfs =========================================== -Export CPU topology info via sysfs. Items (attributes) are similar -to /proc/cpuinfo output of some architectures. They reside in -/sys/devices/system/cpu/cpuX/topology/: - -physical_package_id: - - physical package id of cpuX. Typically corresponds to a physical - socket number, but the actual value is architecture and platform - dependent. - -die_id: - - the CPU die ID of cpuX. Typically it is the hardware platform's - identifier (rather than the kernel's). The actual value is - architecture and platform dependent. - -core_id: - - the CPU core ID of cpuX. Typically it is the hardware platform's - identifier (rather than the kernel's). The actual value is - architecture and platform dependent. - -book_id: - - the book ID of cpuX. Typically it is the hardware platform's - identifier (rather than the kernel's). The actual value is - architecture and platform dependent. - -drawer_id: - - the drawer ID of cpuX. Typically it is the hardware platform's - identifier (rather than the kernel's). The actual value is - architecture and platform dependent. - -core_cpus: - - internal kernel map of CPUs within the same core. - (deprecated name: "thread_siblings") - -core_cpus_list: - - human-readable list of CPUs within the same core. - (deprecated name: "thread_siblings_list"); - -package_cpus: - - internal kernel map of the CPUs sharing the same physical_package_id. - (deprecated name: "core_siblings") - -package_cpus_list: - - human-readable list of CPUs sharing the same physical_package_id. - (deprecated name: "core_siblings_list") - -die_cpus: - - internal kernel map of CPUs within the same die. - -die_cpus_list: - - human-readable list of CPUs within the same die. - -book_siblings: - - internal kernel map of cpuX's hardware threads within the same - book_id. - -book_siblings_list: - - human-readable list of cpuX's hardware threads within the same - book_id. - -drawer_siblings: - - internal kernel map of cpuX's hardware threads within the same - drawer_id. - -drawer_siblings_list: - - human-readable list of cpuX's hardware threads within the same - drawer_id. +CPU topology info is exported via sysfs. Items (attributes) are similar +to /proc/cpuinfo output of some architectures. They reside in +/sys/devices/system/cpu/cpuX/topology/. Please refer to the ABI file: +Documentation/ABI/stable/sysfs-devices-system-cpu. Architecture-neutral, drivers/base/topology.c, exports these attributes. However, the book and drawer related sysfs files will only be created if -- cgit v1.2.3 From bdb8d06dfefd666d5981d884b535b04105869fcc Mon Sep 17 00:00:00 2001 From: Hridya Valsaraju Date: Thu, 3 Jun 2021 14:47:51 -0700 Subject: dmabuf: Add the capability to expose DMA-BUF stats in sysfs MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Overview ======== The patch adds DMA-BUF statistics to /sys/kernel/dmabuf/buffers. It allows statistics to be enabled for each DMA-BUF in sysfs by enabling the config CONFIG_DMABUF_SYSFS_STATS. The following stats will be exposed by the interface: /sys/kernel/dmabuf/buffers//exporter_name /sys/kernel/dmabuf/buffers//size /sys/kernel/dmabuf/buffers//attachments//device /sys/kernel/dmabuf/buffers//attachments//map_counter The inode_number is unique for each DMA-BUF and was added earlier [1] in order to allow userspace to track DMA-BUF usage across different processes. Use Cases ========= The interface provides a way to gather DMA-BUF per-buffer statistics from production devices. These statistics will be used to derive DMA-BUF per-exporter stats and per-device usage stats for Android Bug reports. The corresponding userspace changes can be found at [2]. Telemetry tools will also capture this information(along with other memory metrics) periodically as well as on important events like a foreground app kill (which might have been triggered by Low Memory Killer). It will also contribute to provide a snapshot of the system memory usage on other events such as OOM kills and Application Not Responding events. Background ========== Currently, there are two existing interfaces that provide information about DMA-BUFs. 1) /sys/kernel/debug/dma_buf/bufinfo debugfs is however unsuitable to be mounted in production systems and cannot be considered as an alternative to the sysfs interface being proposed. 2) proc//fdinfo/ The proc//fdinfo/ files expose information about DMA-BUF fds. However, the existing procfs interfaces can only provide information about the buffers for which processes hold fds or have the buffers mmapped into their address space. Since the procfs interfaces alone cannot provide a full picture of all DMA-BUFs in the system, there is the need for an alternate interface to provide this information on production systems. The patch contains the following major improvements over v1: 1) Each attachment is represented by its own directory to allow creating a symlink to the importing device and to also provide room for future expansion. 2) The number of distinct mappings of each attachment is exposed in a separate file. 3) The per-buffer statistics are now in /sys/kernel/dmabuf/buffers inorder to make the interface expandable in future. All of the improvements above are based on suggestions/feedback from Daniel Vetter and Christian König. A shell script that can be run on a classic Linux environment to read out the DMA-BUF statistics can be found at [3](suggested by John Stultz). [1]: https://lore.kernel.org/patchwork/patch/1088791/ [2]: https://android-review.googlesource.com/q/topic:%22dmabuf-sysfs%22+(status:open%20OR%20status:merged) [3]: https://android-review.googlesource.com/c/platform/system/memory/libmeminfo/+/1549734 Reviewed-by: Greg Kroah-Hartman Signed-off-by: Hridya Valsaraju Reported-by: kernel test robot Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20210603214758.2955251-1-hridya@google.com --- .../ABI/testing/sysfs-kernel-dmabuf-buffers | 52 ++++++++++++++++++++++ Documentation/driver-api/dma-buf.rst | 5 +++ 2 files changed, 57 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-kernel-dmabuf-buffers (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-kernel-dmabuf-buffers b/Documentation/ABI/testing/sysfs-kernel-dmabuf-buffers new file mode 100644 index 000000000000..a243984ed420 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-kernel-dmabuf-buffers @@ -0,0 +1,52 @@ +What: /sys/kernel/dmabuf/buffers +Date: May 2021 +KernelVersion: v5.13 +Contact: Hridya Valsaraju +Description: The /sys/kernel/dmabuf/buffers directory contains a + snapshot of the internal state of every DMA-BUF. + /sys/kernel/dmabuf/buffers/ will contain the + statistics for the DMA-BUF with the unique inode number + +Users: kernel memory tuning/debugging tools + +What: /sys/kernel/dmabuf/buffers//exporter_name +Date: May 2021 +KernelVersion: v5.13 +Contact: Hridya Valsaraju +Description: This file is read-only and contains the name of the exporter of + the DMA-BUF. + +What: /sys/kernel/dmabuf/buffers//size +Date: May 2021 +KernelVersion: v5.13 +Contact: Hridya Valsaraju +Description: This file is read-only and specifies the size of the DMA-BUF in + bytes. + +What: /sys/kernel/dmabuf/buffers//attachments +Date: May 2021 +KernelVersion: v5.13 +Contact: Hridya Valsaraju +Description: This directory will contain subdirectories representing every + attachment of the DMA-BUF. + +What: /sys/kernel/dmabuf/buffers//attachments/ +Date: May 2021 +KernelVersion: v5.13 +Contact: Hridya Valsaraju +Description: This directory will contain information on the attached device + and the number of current distinct device mappings. + +What: /sys/kernel/dmabuf/buffers//attachments//device +Date: May 2021 +KernelVersion: v5.13 +Contact: Hridya Valsaraju +Description: This file is read-only and is a symlink to the attached device's + sysfs entry. + +What: /sys/kernel/dmabuf/buffers//attachments//map_counter +Date: May 2021 +KernelVersion: v5.13 +Contact: Hridya Valsaraju +Description: This file is read-only and contains a map_counter indicating the + number of distinct device mappings of the attachment. diff --git a/Documentation/driver-api/dma-buf.rst b/Documentation/driver-api/dma-buf.rst index 7f21425d9435..84aab65c4962 100644 --- a/Documentation/driver-api/dma-buf.rst +++ b/Documentation/driver-api/dma-buf.rst @@ -106,6 +106,11 @@ Implicit Fence Poll Support .. kernel-doc:: drivers/dma-buf/dma-buf.c :doc: implicit fence polling +DMA-BUF statistics +~~~~~~~~~~~~~~~~~~ +.. kernel-doc:: drivers/dma-buf/dma-buf-sysfs-stats.c + :doc: overview + Kernel Functions and Structures Reference ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -- cgit v1.2.3 From cb7d734ea9b85f49f26d04d8de09ece363cbd6fc Mon Sep 17 00:00:00 2001 From: Shengjiu Wang Date: Wed, 2 Jun 2021 14:04:09 +0800 Subject: ASoC: dt-bindings: fsl,spdif: Add compatible string for imx8ulp Add compatible string for imx8ulp, which supports spdif module Signed-off-by: Shengjiu Wang Acked-by: Rob Herring Link: https://lore.kernel.org/r/1622613849-10271-1-git-send-email-shengjiu.wang@nxp.com Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/sound/fsl,spdif.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/fsl,spdif.yaml b/Documentation/devicetree/bindings/sound/fsl,spdif.yaml index 4454aca34d56..f226ec13167a 100644 --- a/Documentation/devicetree/bindings/sound/fsl,spdif.yaml +++ b/Documentation/devicetree/bindings/sound/fsl,spdif.yaml @@ -25,6 +25,7 @@ properties: - fsl,imx8mq-spdif - fsl,imx8mm-spdif - fsl,imx8mn-spdif + - fsl,imx8ulp-spdif reg: maxItems: 1 -- cgit v1.2.3 From 6f73de7da10b9476232820558fb7b3eb6bb9afe4 Mon Sep 17 00:00:00 2001 From: Shengjiu Wang Date: Wed, 2 Jun 2021 14:02:50 +0800 Subject: ASoC: dt-bindings: fsl-sai: Add compatible string for imx8mm/8mn/8mp/8ulp Add compatible string for imx8mm/8mn/8mp/8ulp, these platforms all support SAI IP. Signed-off-by: Shengjiu Wang Acked-by: Rob Herring Link: https://lore.kernel.org/r/1622613770-10220-1-git-send-email-shengjiu.wang@nxp.com Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/sound/fsl-sai.txt | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/fsl-sai.txt b/Documentation/devicetree/bindings/sound/fsl-sai.txt index 0dc83cc4a236..c71c5861d787 100644 --- a/Documentation/devicetree/bindings/sound/fsl-sai.txt +++ b/Documentation/devicetree/bindings/sound/fsl-sai.txt @@ -9,8 +9,10 @@ Required properties: - compatible : Compatible list, contains "fsl,vf610-sai", "fsl,imx6sx-sai", "fsl,imx6ul-sai", - "fsl,imx7ulp-sai", "fsl,imx8mq-sai" or - "fsl,imx8qm-sai". + "fsl,imx7ulp-sai", "fsl,imx8mq-sai", + "fsl,imx8qm-sai", "fsl,imx8mm-sai", + "fsl,imx8mn-sai", "fsl,imx8mp-sai", or + "fsl,imx8ulp-sai". - reg : Offset and length of the register set for the device. -- cgit v1.2.3 From 80ee6fc281b7f7b63db46b0eb0c95c0f9500767b Mon Sep 17 00:00:00 2001 From: Matthias Kaehlcke Date: Wed, 9 Jun 2021 15:02:45 -0700 Subject: dt-bindings: usb: Add binding for Realtek RTS5411 hub controller The Realtek RTS5411 is a USB 3.0 hub controller with 4 ports. This initial version of the binding only describes USB related aspects of the RTS5411, it does not cover the option of connecting the controller as an i2c slave. Reviewed-by: Rob Herring Signed-off-by: Matthias Kaehlcke Link: https://lore.kernel.org/r/20210609150159.v12.1.I248292623d3d0f6a4f0c5bc58478ca3c0062b49a@changeid Signed-off-by: Greg Kroah-Hartman --- .../devicetree/bindings/usb/realtek,rts5411.yaml | 62 ++++++++++++++++++++++ 1 file changed, 62 insertions(+) create mode 100644 Documentation/devicetree/bindings/usb/realtek,rts5411.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/usb/realtek,rts5411.yaml b/Documentation/devicetree/bindings/usb/realtek,rts5411.yaml new file mode 100644 index 000000000000..04ee255eb4f0 --- /dev/null +++ b/Documentation/devicetree/bindings/usb/realtek,rts5411.yaml @@ -0,0 +1,62 @@ +# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/usb/realtek,rts5411.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Binding for the Realtek RTS5411 USB 3.0 hub controller + +maintainers: + - Matthias Kaehlcke + +allOf: + - $ref: usb-device.yaml# + +properties: + compatible: + items: + - enum: + - usbbda,5411 + - usbbda,411 + + reg: true + + vdd-supply: + description: + phandle to the regulator that provides power to the hub. + + companion-hub: + $ref: '/schemas/types.yaml#/definitions/phandle' + description: + phandle to the companion hub on the controller. + +required: + - companion-hub + - compatible + - reg + +additionalProperties: false + +examples: + - | + usb { + dr_mode = "host"; + #address-cells = <1>; + #size-cells = <0>; + + /* 2.0 hub on port 1 */ + hub_2_0: hub@1 { + compatible = "usbbda,5411"; + reg = <1>; + vdd-supply = <&pp3300_hub>; + companion-hub = <&hub_3_0>; + }; + + /* 3.0 hub on port 2 */ + hub_3_0: hub@2 { + compatible = "usbbda,411"; + reg = <2>; + vdd-supply = <&pp3300_hub>; + companion-hub = <&hub_2_0>; + }; + }; -- cgit v1.2.3 From b4e326165e21d6a11483f6a4de2174b933413554 Mon Sep 17 00:00:00 2001 From: Matthias Kaehlcke Date: Wed, 9 Jun 2021 15:02:46 -0700 Subject: USB: misc: Add onboard_usb_hub driver The main issue this driver addresses is that a USB hub needs to be powered before it can be discovered. For discrete onboard hubs (an example for such a hub is the Realtek RTS5411) this is often solved by supplying the hub with an 'always-on' regulator, which is kind of a hack. Some onboard hubs may require further initialization steps, like changing the state of a GPIO or enabling a clock, which requires even more hacks. This driver creates a platform device representing the hub which performs the necessary initialization. Currently it only supports switching on a single regulator, support for multiple regulators or other actions can be added as needed. Different initialization sequences can be supported based on the compatible string. Besides performing the initialization the driver can be configured to power the hub off during system suspend. This can help to extend battery life on battery powered devices which have no requirements to keep the hub powered during suspend. The driver can also be configured to leave the hub powered when a wakeup capable USB device is connected when suspending, and power it off otherwise. Technically the driver consists of two drivers, the platform driver described above and a very thin USB driver that subclasses the generic driver. The purpose of this driver is to provide the platform driver with the USB devices corresponding to the hub(s) (a hub controller may provide multiple 'logical' hubs, e.g. one to support USB 2.0 and another for USB 3.x). Note: the current series only supports hubs connected directly to a root hub (through xhci-plat), support for other configurations could be added if needed. Co-developed-by: Ravi Chandra Sadineni Acked-by: Alan Stern Signed-off-by: Ravi Chandra Sadineni Signed-off-by: Matthias Kaehlcke Link: https://lore.kernel.org/r/20210609150159.v12.2.I7c9a1f1d6ced41dd8310e8a03da666a32364e790@changeid Signed-off-by: Greg Kroah-Hartman --- Documentation/ABI/testing/sysfs-bus-platform-onboard-usb-hub | 8 ++++++++ 1 file changed, 8 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-bus-platform-onboard-usb-hub (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-bus-platform-onboard-usb-hub b/Documentation/ABI/testing/sysfs-bus-platform-onboard-usb-hub new file mode 100644 index 000000000000..e981d83648e6 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-bus-platform-onboard-usb-hub @@ -0,0 +1,8 @@ +What: /sys/bus/platform/devices//always_powered_in_suspend +Date: March 2021 +KernelVersion: 5.13 +Contact: Matthias Kaehlcke + linux-usb@vger.kernel.org +Description: + (RW) Controls whether the USB hub remains always powered + during system suspend or not. \ No newline at end of file -- cgit v1.2.3 From 09a8ec9a2d03efa2813d9d306424eb6802146b57 Mon Sep 17 00:00:00 2001 From: Al Cooper Date: Wed, 2 Jun 2021 15:27:57 -0400 Subject: dt-bindings: mmc: sdhci-iproc: Add brcm,bcm7211a0-sdhci Add new compatible string for the legacy sdhci controller on the BCM7211 family of SoC's. Signed-off-by: Al Cooper Link: https://lore.kernel.org/r/20210602192758.38735-1-alcooperx@gmail.com Signed-off-by: Ulf Hansson --- Documentation/devicetree/bindings/mmc/brcm,iproc-sdhci.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mmc/brcm,iproc-sdhci.yaml b/Documentation/devicetree/bindings/mmc/brcm,iproc-sdhci.yaml index 6f569fbfa134..2f63f2cdeb71 100644 --- a/Documentation/devicetree/bindings/mmc/brcm,iproc-sdhci.yaml +++ b/Documentation/devicetree/bindings/mmc/brcm,iproc-sdhci.yaml @@ -21,6 +21,7 @@ properties: - brcm,bcm2711-emmc2 - brcm,sdhci-iproc-cygnus - brcm,sdhci-iproc + - brcm,bcm7211a0-sdhci reg: minItems: 1 -- cgit v1.2.3 From f9ac779f881c2ec3d1cdcd7fa9d4f9442bf60e80 Mon Sep 17 00:00:00 2001 From: Kuniyuki Iwashima Date: Sat, 12 Jun 2021 21:32:14 +0900 Subject: net: Introduce net.ipv4.tcp_migrate_req. This commit adds a new sysctl option: net.ipv4.tcp_migrate_req. If this option is enabled or eBPF program is attached, we will be able to migrate child sockets from a listener to another in the same reuseport group after close() or shutdown() syscalls. Signed-off-by: Kuniyuki Iwashima Signed-off-by: Daniel Borkmann Reviewed-by: Benjamin Herrenschmidt Reviewed-by: Eric Dumazet Acked-by: Martin KaFai Lau Link: https://lore.kernel.org/bpf/20210612123224.12525-2-kuniyu@amazon.co.jp --- Documentation/networking/ip-sysctl.rst | 25 +++++++++++++++++++++++++ 1 file changed, 25 insertions(+) (limited to 'Documentation') diff --git a/Documentation/networking/ip-sysctl.rst b/Documentation/networking/ip-sysctl.rst index a5c250044500..b0436d3a4f11 100644 --- a/Documentation/networking/ip-sysctl.rst +++ b/Documentation/networking/ip-sysctl.rst @@ -761,6 +761,31 @@ tcp_syncookies - INTEGER network connections you can set this knob to 2 to enable unconditionally generation of syncookies. +tcp_migrate_req - BOOLEAN + The incoming connection is tied to a specific listening socket when + the initial SYN packet is received during the three-way handshake. + When a listener is closed, in-flight request sockets during the + handshake and established sockets in the accept queue are aborted. + + If the listener has SO_REUSEPORT enabled, other listeners on the + same port should have been able to accept such connections. This + option makes it possible to migrate such child sockets to another + listener after close() or shutdown(). + + The BPF_SK_REUSEPORT_SELECT_OR_MIGRATE type of eBPF program should + usually be used to define the policy to pick an alive listener. + Otherwise, the kernel will randomly pick an alive listener only if + this option is enabled. + + Note that migration between listeners with different settings may + crash applications. Let's say migration happens from listener A to + B, and only B has TCP_SAVE_SYN enabled. B cannot read SYN data from + the requests migrated from A. To avoid such a situation, cancel + migration by returning SK_DROP in the type of eBPF program, or + disable this option. + + Default: 0 + tcp_fastopen - INTEGER Enable TCP Fast Open (RFC7413) to send and accept data in the opening SYN packet. -- cgit v1.2.3 From 36ac0228626585ba718186b9db2e5986a198152c Mon Sep 17 00:00:00 2001 From: Michael Walle Date: Mon, 3 May 2021 17:56:51 +0200 Subject: mtd: spi-nor: add initial sysfs support Add support to show the manufacturer, the partname and JEDEC identifier as well as to dump the SFDP table. Not all flashes list their SFDP table contents in their datasheet. So having that is useful. It might also be helpful in bug reports from users. Signed-off-by: Michael Walle Signed-off-by: Vignesh Raghavendra Acked-by: Pratyush Yadav --- .../ABI/testing/sysfs-bus-spi-devices-spi-nor | 31 ++++++++++++++++++++++ 1 file changed, 31 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-bus-spi-devices-spi-nor (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-bus-spi-devices-spi-nor b/Documentation/ABI/testing/sysfs-bus-spi-devices-spi-nor new file mode 100644 index 000000000000..d76cd3946434 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-bus-spi-devices-spi-nor @@ -0,0 +1,31 @@ +What: /sys/bus/spi/devices/.../spi-nor/jedec_id +Date: April 2021 +KernelVersion: 5.14 +Contact: linux-mtd@lists.infradead.org +Description: (RO) The JEDEC ID of the SPI NOR flash as reported by the + flash device. + + +What: /sys/bus/spi/devices/.../spi-nor/manufacturer +Date: April 2021 +KernelVersion: 5.14 +Contact: linux-mtd@lists.infradead.org +Description: (RO) Manufacturer of the SPI NOR flash. + + +What: /sys/bus/spi/devices/.../spi-nor/partname +Date: April 2021 +KernelVersion: 5.14 +Contact: linux-mtd@lists.infradead.org +Description: (RO) Part name of the SPI NOR flash. + + +What: /sys/bus/spi/devices/.../spi-nor/sfdp +Date: April 2021 +KernelVersion: 5.14 +Contact: linux-mtd@lists.infradead.org +Description: (RO) This attribute is only present if the SPI NOR flash + device supports the "Read SFDP" command (5Ah). + + If present, it contains the complete SFDP (serial flash + discoverable parameters) binary data of the flash. -- cgit v1.2.3 From 925a56b2c085a7c6f5c741c8516e21c3aa6134b4 Mon Sep 17 00:00:00 2001 From: M Chetan Kumar Date: Tue, 15 Jun 2021 18:38:22 +0530 Subject: net: wwan: iosm: Fix htmldocs warnings Fixes .rst file warnings seen on linux-next build. Fixes: f7af616c632e ("net: iosm: infrastructure") Reported-by: Stephen Rothwell Signed-off-by: M Chetan Kumar Signed-off-by: David S. Miller --- Documentation/networking/device_drivers/wwan/iosm.rst | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/networking/device_drivers/wwan/iosm.rst b/Documentation/networking/device_drivers/wwan/iosm.rst index cd12f57d980a..aceb0223eb46 100644 --- a/Documentation/networking/device_drivers/wwan/iosm.rst +++ b/Documentation/networking/device_drivers/wwan/iosm.rst @@ -40,7 +40,7 @@ MBIM control channel userspace ABI ---------------------------------- /dev/wwan0mbim0 character device -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The driver exposes an MBIM interface to the MBIM function by implementing MBIM WWAN Port. The userspace end of the control channel pipe is a /dev/wwan0mbim0 character device. Application shall use this interface for @@ -52,12 +52,12 @@ The userspace application is responsible for all control message fragmentation and defragmentation as per MBIM specification. /dev/wwan0mbim0 write() -~~~~~~~~~~~~~~~~~~~~~ +~~~~~~~~~~~~~~~~~~~~~~~ The MBIM control messages from the management application must not exceed the negotiated control message size. /dev/wwan0mbim0 read() -~~~~~~~~~~~~~~~~~~~~ +~~~~~~~~~~~~~~~~~~~~~~ The management application must accept control messages of up the negotiated control message size. @@ -65,7 +65,7 @@ MBIM data channel userspace ABI ------------------------------- wwan0-X network device -~~~~~~~~~~~~~~~~~~~~ +~~~~~~~~~~~~~~~~~~~~~~ The IOSM driver exposes IP link interface "wwan0-X" of type "wwan" for IP traffic. Iproute network utility is used for creating "wwan0-X" network interface and for associating it with MBIM IP session. The Driver supports -- cgit v1.2.3 From 1534fac32fc6a4320c54b2007e2f5b6f9a8ff336 Mon Sep 17 00:00:00 2001 From: Bhupesh Sharma Date: Tue, 15 Jun 2021 13:15:36 +0530 Subject: dt-bindings: arm: qcom: Add compatible for sm8150-mtp board sm8150-mtp board is based on Qualcomm Snapdragon sm8150 SoC. Add support for the same in dt-bindings. Signed-off-by: Bhupesh Sharma Link: https://lore.kernel.org/r/20210615074543.26700-4-bhupesh.sharma@linaro.org Signed-off-by: Bjorn Andersson --- Documentation/devicetree/bindings/arm/qcom.yaml | 6 ++++++ 1 file changed, 6 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml index 2babb95de354..5567029044cb 100644 --- a/Documentation/devicetree/bindings/arm/qcom.yaml +++ b/Documentation/devicetree/bindings/arm/qcom.yaml @@ -42,6 +42,7 @@ description: | sdm660 sdm845 sdx55 + sm8150 sm8250 sm8350 @@ -199,6 +200,11 @@ properties: - qcom,ipq6018-cp01-c1 - const: qcom,ipq6018 + - items: + - enum: + - qcom,sm8150-mtp + - const: qcom,sm8150 + - items: - enum: - qcom,qrb5165-rb5 -- cgit v1.2.3 From 0bc14d4ad3a7646052b98e9e332a514167a7052f Mon Sep 17 00:00:00 2001 From: Bhupesh Sharma Date: Tue, 15 Jun 2021 13:15:37 +0530 Subject: dt-bindings: arm: qcom: Add compatible for SA8155p-adp board SA8155p-adp board is based on Qualcomm Snapdragon sa8155p SoC which is similar to the sm8150 SoC. Add support for the same in dt-bindings. Signed-off-by: Bhupesh Sharma Link: https://lore.kernel.org/r/20210615074543.26700-5-bhupesh.sharma@linaro.org Signed-off-by: Bjorn Andersson --- Documentation/devicetree/bindings/arm/qcom.yaml | 7 +++++++ 1 file changed, 7 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml index 5567029044cb..9720b00c41d2 100644 --- a/Documentation/devicetree/bindings/arm/qcom.yaml +++ b/Documentation/devicetree/bindings/arm/qcom.yaml @@ -36,6 +36,7 @@ description: | msm8992 msm8994 msm8996 + sa8155p sc7180 sc7280 sdm630 @@ -48,6 +49,7 @@ description: | The 'board' element must be one of the following strings: + adp cdp cp01-c1 dragonboard @@ -200,6 +202,11 @@ properties: - qcom,ipq6018-cp01-c1 - const: qcom,ipq6018 + - items: + - enum: + - qcom,sa8155p-adp + - const: qcom,sa8155p + - items: - enum: - qcom,sm8150-mtp -- cgit v1.2.3 From 703ac06a88f07f1fdde795d00c0296750e2b8e4c Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Sat, 5 Jun 2021 14:00:54 +0200 Subject: media: docs: */media/index.rst: don't use ReST doc:`foo` The :doc:`foo` tag is auto-generated via automarkup.py. So, use the filename at the sources, instead of :doc:`foo`. Signed-off-by: Mauro Carvalho Chehab --- Documentation/admin-guide/media/index.rst | 12 +++++++----- Documentation/driver-api/media/index.rst | 10 ++++++---- Documentation/userspace-api/media/index.rst | 12 +++++++----- 3 files changed, 20 insertions(+), 14 deletions(-) (limited to 'Documentation') diff --git a/Documentation/admin-guide/media/index.rst b/Documentation/admin-guide/media/index.rst index 6e0d2bae7154..c676af665111 100644 --- a/Documentation/admin-guide/media/index.rst +++ b/Documentation/admin-guide/media/index.rst @@ -11,12 +11,14 @@ its supported drivers. Please see: -- :doc:`/userspace-api/media/index` - for the userspace APIs used on media devices. +Documentation/userspace-api/media/index.rst -- :doc:`/driver-api/media/index` - for driver development information and Kernel APIs used by - media devices; + - for the userspace APIs used on media devices. + +Documentation/driver-api/media/index.rst + + - for driver development information and Kernel APIs used by + media devices; The media subsystem =================== diff --git a/Documentation/driver-api/media/index.rst b/Documentation/driver-api/media/index.rst index 2ad71dfa8828..813d7db59da7 100644 --- a/Documentation/driver-api/media/index.rst +++ b/Documentation/driver-api/media/index.rst @@ -11,11 +11,13 @@ its supported drivers. Please see: -- :doc:`/admin-guide/media/index` - for usage information about media subsystem and supported drivers; +Documentation/admin-guide/media/index.rst -- :doc:`/userspace-api/media/index` - for the userspace APIs used on media devices. + - for usage information about media subsystem and supported drivers; + +Documentation/userspace-api/media/index.rst + + - for the userspace APIs used on media devices. .. only:: html diff --git a/Documentation/userspace-api/media/index.rst b/Documentation/userspace-api/media/index.rst index 7f42f83b9f59..d839904be085 100644 --- a/Documentation/userspace-api/media/index.rst +++ b/Documentation/userspace-api/media/index.rst @@ -11,12 +11,14 @@ used by media devices. Please see: -- :doc:`/admin-guide/media/index` - for usage information about media subsystem and supported drivers; +Documentation/admin-guide/media/index.rst -- :doc:`/driver-api/media/index` - for driver development information and Kernel APIs used by - media devices; + - for usage information about media subsystem and supported drivers; + +Documentation/driver-api/media/index.rst + + - for driver development information and Kernel APIs used by + media devices; .. only:: html -- cgit v1.2.3 From d759cd46b9f15180321b6f246a6e0964d4510aef Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Sat, 5 Jun 2021 14:40:12 +0200 Subject: media: userspace-api: avoid using ReST :doc:`foo` markup The :doc:`foo` tag is auto-generated via automarkup.py. So, use the filename at the sources, instead of :doc:`foo`. Signed-off-by: Mauro Carvalho Chehab --- Documentation/userspace-api/media/glossary.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/userspace-api/media/glossary.rst b/Documentation/userspace-api/media/glossary.rst index cb165d7176b7..96a360edbf3b 100644 --- a/Documentation/userspace-api/media/glossary.rst +++ b/Documentation/userspace-api/media/glossary.rst @@ -116,7 +116,7 @@ Glossary - :term:`RC API`; and - :term:`V4L2 API`. - See :doc:`index`. + See Documentation/userspace-api/media/index.rst. MC API **Media Controller API** -- cgit v1.2.3 From a169c44e58190bbdaf9c8d345cd445eec2c2b010 Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Sat, 5 Jun 2021 14:40:12 +0200 Subject: media: driver-api: drivers: avoid using ReST :doc:`foo` markup The :doc:`foo` tag is auto-generated via automarkup.py. So, use the filename at the sources, instead of :doc:`foo`. Signed-off-by: Mauro Carvalho Chehab --- Documentation/driver-api/media/drivers/bttv-devel.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/driver-api/media/drivers/bttv-devel.rst b/Documentation/driver-api/media/drivers/bttv-devel.rst index c9aa8b95a5e5..0885a04563a9 100644 --- a/Documentation/driver-api/media/drivers/bttv-devel.rst +++ b/Documentation/driver-api/media/drivers/bttv-devel.rst @@ -21,7 +21,7 @@ log, telling which card type is used. Like this one:: You should verify this is correct. If it isn't, you have to pass the correct board type as insmod argument, ``insmod bttv card=2`` for -example. The file :doc:`/admin-guide/media/bttv-cardlist` has a list +example. The file Documentation/admin-guide/media/bttv-cardlist.rst has a list of valid arguments for card. If your card isn't listed there, you might check the source code for -- cgit v1.2.3 From 6ef43d273e8562366035d8086008e4000a270fd8 Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Sat, 5 Jun 2021 14:40:12 +0200 Subject: media: admin-guide: avoid using ReST :doc:`foo` markup The :doc:`foo` tag is auto-generated via automarkup.py. So, use the filename at the sources, instead of :doc:`foo`. Signed-off-by: Mauro Carvalho Chehab --- Documentation/admin-guide/media/bt8xx.rst | 15 ++++++++------- Documentation/admin-guide/media/bttv.rst | 21 +++++++++++---------- Documentation/admin-guide/media/saa7134.rst | 3 ++- 3 files changed, 21 insertions(+), 18 deletions(-) (limited to 'Documentation') diff --git a/Documentation/admin-guide/media/bt8xx.rst b/Documentation/admin-guide/media/bt8xx.rst index 1382ada1e38e..3589f6ab7e46 100644 --- a/Documentation/admin-guide/media/bt8xx.rst +++ b/Documentation/admin-guide/media/bt8xx.rst @@ -15,11 +15,12 @@ Authors: 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. +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 :doc:`bttv-cardlist` for a complete list of Cards based on the -Conexant Bt8xx PCI bridge supported by the Linux Kernel. +Please see Documentation/admin-guide/media/bttv-cardlist.rst for a complete +list of Cards based on the Conexant Bt8xx PCI bridge supported by the +Linux Kernel. In order to be able to compile the kernel, some config options should be enabled:: @@ -80,7 +81,7 @@ for dvb-bt8xx drivers by passing modprobe parameters may be necessary. Running TwinHan and Clones ~~~~~~~~~~~~~~~~~~~~~~~~~~ -As shown at :doc:`bttv-cardlist`, TwinHan and +As shown at Documentation/admin-guide/media/bttv-cardlist.rst, TwinHan and clones use ``card=113`` modprobe parameter. So, in order to properly detect it for devices without EEPROM, you should use:: @@ -105,12 +106,12 @@ 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 :doc:`ci`. +Please also see Documentation/admin-guide/media/ci.rst. Running multiple cards ~~~~~~~~~~~~~~~~~~~~~~ -See :doc:`bttv-cardlist` for a complete list of +See Documentation/admin-guide/media/bttv-cardlist.rst for a complete list of Card ID. Some examples: =========================== === diff --git a/Documentation/admin-guide/media/bttv.rst b/Documentation/admin-guide/media/bttv.rst index 0ef1f203104d..125f6f47123d 100644 --- a/Documentation/admin-guide/media/bttv.rst +++ b/Documentation/admin-guide/media/bttv.rst @@ -24,7 +24,8 @@ If your board has digital TV, you'll also need:: ./scripts/config -m DVB_BT8XX -In this case, please see :doc:`bt8xx` for additional notes. +In this case, please see Documentation/admin-guide/media/bt8xx.rst +for additional notes. Make bttv work with your card ----------------------------- @@ -39,7 +40,7 @@ If it doesn't bttv likely could not autodetect your card and needs some insmod options. The most important insmod option for bttv is "card=n" to select the correct card type. If you get video but no sound you've very likely specified the wrong (or no) card type. A list of supported -cards is in :doc:`bttv-cardlist`. +cards is in Documentation/admin-guide/media/bttv-cardlist.rst. If bttv takes very long to load (happens sometimes with the cheap cards which have no tuner), try adding this to your modules configuration @@ -57,8 +58,8 @@ directory should be enough for it to be autoload during the driver's probing mode (e. g. when the Kernel boots or when the driver is manually loaded via ``modprobe`` command). -If your card isn't listed in :doc:`bttv-cardlist` or if you have -trouble making audio work, please read :ref:`still_doesnt_work`. +If your card isn't listed in Documentation/admin-guide/media/bttv-cardlist.rst +or if you have trouble making audio work, please read :ref:`still_doesnt_work`. Autodetecting cards @@ -77,8 +78,8 @@ the Subsystem ID in the second line, looks like this: only bt878-based cards can have a subsystem ID (which does not mean that every card really has one). bt848 cards can't have a Subsystem ID and therefore can't be autodetected. There is a list with the ID's -at :doc:`bttv-cardlist` (in case you are interested or want to mail -patches with updates). +at Documentation/admin-guide/media/bttv-cardlist.rst +(in case you are interested or want to mail patches with updates). .. _still_doesnt_work: @@ -259,15 +260,15 @@ bug. It is very helpful if you can tell where exactly it broke With a hard freeze you probably doesn't find anything in the logfiles. The only way to capture any kernel messages is to hook up a serial console and let some terminal application log the messages. /me uses -screen. See :doc:`/admin-guide/serial-console` for details on setting -up a serial console. +screen. See Documentation/admin-guide/serial-console.rst for details on +setting up a serial console. -Read :doc:`/admin-guide/bug-hunting` 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"). If you run into some kind of deadlock, you can try to dump a call trace -for each process using sysrq-t (see :doc:`/admin-guide/sysrq`). +for each process using sysrq-t (see Documentation/admin-guide/sysrq.rst). This way it is possible to figure where *exactly* some process in "D" state is stuck. diff --git a/Documentation/admin-guide/media/saa7134.rst b/Documentation/admin-guide/media/saa7134.rst index 7ab9c70b9abe..51eae7eb5ab7 100644 --- a/Documentation/admin-guide/media/saa7134.rst +++ b/Documentation/admin-guide/media/saa7134.rst @@ -50,7 +50,8 @@ To build and install, you should run:: Once the new Kernel is booted, saa7134 driver should be loaded automatically. Depending on the card you might have to pass ``card=`` as insmod option. -If so, please check :doc:`saa7134-cardlist` for valid choices. +If so, please check Documentation/admin-guide/media/saa7134-cardlist.rst +for valid choices. Once you have your card type number, you can pass a modules configuration via a file (usually, it is either ``/etc/modules.conf`` or some file at -- cgit v1.2.3 From 1882441cd788a496b378f4d2684fa66cec195051 Mon Sep 17 00:00:00 2001 From: Vignesh Raghavendra Date: Thu, 10 Jun 2021 23:52:27 +0530 Subject: dt-bindings: serial: Move omap-serial.txt to YAML schema Convert serial-omap.txt to YAML schema for better checks and documentation. Acked-by: Tony Lindgren Signed-off-by: Vignesh Raghavendra Link: https://lore.kernel.org/r/20210610182227.2480-1-vigneshr@ti.com Signed-off-by: Greg Kroah-Hartman --- .../devicetree/bindings/serial/8250_omap.yaml | 118 +++++++++++++++++++++ .../devicetree/bindings/serial/omap_serial.txt | 40 ------- 2 files changed, 118 insertions(+), 40 deletions(-) create mode 100644 Documentation/devicetree/bindings/serial/8250_omap.yaml delete mode 100644 Documentation/devicetree/bindings/serial/omap_serial.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/serial/8250_omap.yaml b/Documentation/devicetree/bindings/serial/8250_omap.yaml new file mode 100644 index 000000000000..1c826fcf5828 --- /dev/null +++ b/Documentation/devicetree/bindings/serial/8250_omap.yaml @@ -0,0 +1,118 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/serial/8250_omap.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Bindings for 8250 compliant UARTs on TI's OMAP2+ and K3 SoCs + +maintainers: + - Vignesh Raghavendra + +allOf: + - $ref: /schemas/serial/serial.yaml# + - $ref: /schemas/serial/rs485.yaml# + +properties: + compatible: + oneOf: + - enum: + - ti,am3352-uart + - ti,am4372-uart + - ti,am654-uart + - ti,dra742-uart + - ti,omap2-uart + - ti,omap3-uart + - ti,omap4-uart + - items: + - enum: + - ti,am64-uart + - ti,j721e-uart + - const: ti,am654-uart + + ti,hwmods: + description: + Must be "uart", n being the instance number (1-based) + This property is applicable only on legacy platforms mainly omap2/3 + and ti81xx and should not be used on other platforms. + $ref: /schemas/types.yaml#/definitions/string + deprecated: true + + dmas: + minItems: 1 + maxItems: 2 + + dma-names: + items: + - const: tx + - const: rx + + reg: + maxItems: 1 + + interrupts: + minItems: 1 + maxItems: 2 + description: + First entry is module IRQ required for normal IO operation. + Second entry is optional and corresponds to system wakeup IRQ + where supported. + + clocks: + maxItems: 1 + + clock-names: + const: fclk + + rts-gpios: true + cts-gpios: true + dtr-gpios: true + dsr-gpios: true + rng-gpios: true + dcd-gpios: true + rs485-rts-delay: true + rs485-rts-active-low: true + rs485-rx-during-tx: true + rs485-rts-active-high: true + linux,rs485-enabled-at-boot-time: true + rts-gpio: true + power-domains: true + clock-frequency: true + current-speed: true + +required: + - compatible + - reg + - interrupts + +additionalProperties: false + +if: + properties: + compatible: + oneOf: + - const: ti,omap2-uart + - const: ti,omap3-uart + - const: ti,omap4-uart + +then: + properties: + ti,hwmods: + items: + - pattern: "^uart([1-9])$" + +else: + properties: + ti,hwmods: false + +examples: + - | + serial@49042000 { + compatible = "ti,omap3-uart"; + reg = <0x49042000 0x400>; + interrupts = <80>; + dmas = <&sdma 81 &sdma 82>; + dma-names = "tx", "rx"; + ti,hwmods = "uart4"; + clock-frequency = <48000000>; + }; diff --git a/Documentation/devicetree/bindings/serial/omap_serial.txt b/Documentation/devicetree/bindings/serial/omap_serial.txt deleted file mode 100644 index c2db8cabf2ab..000000000000 --- a/Documentation/devicetree/bindings/serial/omap_serial.txt +++ /dev/null @@ -1,40 +0,0 @@ -OMAP UART controller - -Required properties: -- compatible : should be "ti,am64-uart", "ti,am654-uart" for AM64 controllers -- compatible : should be "ti,j721e-uart", "ti,am654-uart" for J721E controllers -- compatible : should be "ti,am654-uart" for AM654 controllers -- compatible : should be "ti,omap2-uart" for OMAP2 controllers -- compatible : should be "ti,omap3-uart" for OMAP3 controllers -- compatible : should be "ti,omap4-uart" for OMAP4 controllers -- compatible : should be "ti,am4372-uart" for AM437x controllers -- compatible : should be "ti,am3352-uart" for AM335x controllers -- compatible : should be "ti,dra742-uart" for DRA7x controllers -- reg : address and length of the register space -- interrupts or interrupts-extended : Should contain the uart interrupt - specifier or both the interrupt - controller phandle and interrupt - specifier. -- ti,hwmods : Must be "uart", n being the instance number (1-based) - -Optional properties: -- clock-frequency : frequency of the clock input to the UART -- 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 -- rs485-rts-active-high: drive RTS high when sending (default is low). -- clocks: phandle to the functional clock as per - Documentation/devicetree/bindings/clock/clock-bindings.txt - -Example: - - uart4: serial@49042000 { - compatible = "ti,omap3-uart"; - reg = <0x49042000 0x400>; - interrupts = <80>; - dmas = <&sdma 81 &sdma 82>; - dma-names = "tx", "rx"; - ti,hwmods = "uart4"; - clock-frequency = <48000000>; - }; -- cgit v1.2.3 From 14f259c8be0168f11333bad30b2d716002cfdcbc Mon Sep 17 00:00:00 2001 From: Konrad Dybcio Date: Tue, 15 Jun 2021 01:53:56 +0200 Subject: dt-bindings: dmaengine: qcom: gpi: add compatible for sm8250 No functional changes, just adding a new compatible for a different SoC. Signed-off-by: Konrad Dybcio Reviewed-by: Bjorn Andersson Link: https://lore.kernel.org/r/20210614235358.444834-1-konrad.dybcio@somainline.org Signed-off-by: Vinod Koul --- Documentation/devicetree/bindings/dma/qcom,gpi.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/dma/qcom,gpi.yaml b/Documentation/devicetree/bindings/dma/qcom,gpi.yaml index e302147e53c6..e614fe3187bb 100644 --- a/Documentation/devicetree/bindings/dma/qcom,gpi.yaml +++ b/Documentation/devicetree/bindings/dma/qcom,gpi.yaml @@ -21,6 +21,7 @@ properties: enum: - qcom,sdm845-gpi-dma - qcom,sm8150-gpi-dma + - qcom,sm8250-gpi-dma reg: maxItems: 1 -- cgit v1.2.3 From 2451eeb4ebc051ad1f753580066f20dbf4c5174e Mon Sep 17 00:00:00 2001 From: Geert Uytterhoeven Date: Fri, 11 Jun 2021 12:18:39 +0200 Subject: dt-bindings: dmaengine: Remove SHDMA Device Tree bindings Remove the Renesas SHDMA Device Tree bindings, as they are unused. The DMA multiplexer node and one DMA controller instance were added to the R-Mobile APE6 .dtsi file, but DMA support was never fully enabled, cfr. commit a19788612f51b787 ("dmaengine: sh: Remove R-Mobile APE6 support"). Note that the mux idea was dropped when implementing support for DMA on R-Car Gen2, cfr. renesas,rcar-dmac.yaml. Signed-off-by: Geert Uytterhoeven Link: https://lore.kernel.org/r/ba56b7199fcf3516f202389d2c8f836c9ec51e7a.1623406640.git.geert+renesas@glider.be Signed-off-by: Vinod Koul --- .../devicetree/bindings/dma/renesas,shdma.txt | 84 ---------------------- 1 file changed, 84 deletions(-) delete mode 100644 Documentation/devicetree/bindings/dma/renesas,shdma.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/dma/renesas,shdma.txt b/Documentation/devicetree/bindings/dma/renesas,shdma.txt deleted file mode 100644 index a91920a49433..000000000000 --- a/Documentation/devicetree/bindings/dma/renesas,shdma.txt +++ /dev/null @@ -1,84 +0,0 @@ -* SHDMA Device Tree bindings - -Sh-/r-mobile and R-Car systems often have multiple identical DMA controller -instances, capable of serving any of a common set of DMA slave devices, using -the same configuration. To describe this topology we require all compatible -SHDMA DT nodes to be placed under a DMA multiplexer node. All such compatible -DMAC instances have the same number of channels and use the same DMA -descriptors. Therefore respective DMA DT bindings can also all be placed in the -multiplexer node. Even if there is only one such DMAC instance on a system, it -still has to be placed under such a multiplexer node. - -* DMA multiplexer - -Required properties: -- compatible: should be "renesas,shdma-mux" -- #dma-cells: should be <1>, see "dmas" property below - -Optional properties (currently unused): -- dma-channels: number of DMA channels -- dma-requests: number of DMA request signals - -* DMA controller - -Required properties: -- compatible: should be of the form "renesas,shdma-", where should - be replaced with the desired SoC model, e.g. - "renesas,shdma-r8a73a4" for the system DMAC on r8a73a4 SoC - -Example: - dmac: dma-multiplexer@0 { - compatible = "renesas,shdma-mux"; - #dma-cells = <1>; - dma-channels = <20>; - dma-requests = <256>; - #address-cells = <2>; - #size-cells = <2>; - ranges; - - dma0: dma-controller@e6700020 { - compatible = "renesas,shdma-r8a73a4"; - reg = <0 0xe6700020 0 0x89e0>; - interrupt-parent = <&gic>; - interrupts = <0 220 4 - 0 200 4 - 0 201 4 - 0 202 4 - 0 203 4 - 0 204 4 - 0 205 4 - 0 206 4 - 0 207 4 - 0 208 4 - 0 209 4 - 0 210 4 - 0 211 4 - 0 212 4 - 0 213 4 - 0 214 4 - 0 215 4 - 0 216 4 - 0 217 4 - 0 218 4 - 0 219 4>; - interrupt-names = "error", - "ch0", "ch1", "ch2", "ch3", - "ch4", "ch5", "ch6", "ch7", - "ch8", "ch9", "ch10", "ch11", - "ch12", "ch13", "ch14", "ch15", - "ch16", "ch17", "ch18", "ch19"; - }; - }; - -* DMA client - -Required properties: -- dmas: a list of <[DMA multiplexer phandle] [MID/RID value]> pairs, - where MID/RID values are fixed handles, specified in the SoC - manual -- dma-names: a list of DMA channel names, one per "dmas" entry - -Example: - dmas = <&dmac 0xd1 - &dmac 0xd2>; - dma-names = "tx", "rx"; -- cgit v1.2.3 From 90ad30310a352bf029169d6805eb69a2551c73e8 Mon Sep 17 00:00:00 2001 From: Olivier Dautricourt Date: Wed, 9 Jun 2021 17:20:13 +0200 Subject: dt-bindings: dma: add schema for altera-msgdma add yaml schema for Altera mSGDMA bindings in devicetree. Reviewed-by: Stefan Roese Reviewed-by: Rob Herring Signed-off-by: Olivier Dautricourt Link: https://lore.kernel.org/r/7487a25cdb240d1be4a8593aa602c3c73d8f5acb.1623251990.git.olivier.dautricourt@orolia.com Signed-off-by: Vinod Koul --- .../devicetree/bindings/dma/altr,msgdma.yaml | 61 ++++++++++++++++++++++ 1 file changed, 61 insertions(+) create mode 100644 Documentation/devicetree/bindings/dma/altr,msgdma.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/dma/altr,msgdma.yaml b/Documentation/devicetree/bindings/dma/altr,msgdma.yaml new file mode 100644 index 000000000000..a4f9fe23dcd9 --- /dev/null +++ b/Documentation/devicetree/bindings/dma/altr,msgdma.yaml @@ -0,0 +1,61 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/dma/altr,msgdma.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Altera mSGDMA IP core + +maintainers: + - Olivier Dautricourt + +description: | + Altera / Intel modular Scatter-Gather Direct Memory Access (mSGDMA) + intellectual property (IP) + +allOf: + - $ref: "dma-controller.yaml#" + +properties: + compatible: + const: altr,socfpga-msgdma + + reg: + items: + - description: Control and Status Register Slave Port + - description: Descriptor Slave Port + - description: Response Slave Port + + reg-names: + items: + - const: csr + - const: desc + - const: resp + + interrupts: + maxItems: 1 + + "#dma-cells": + const: 1 + description: + The cell identifies the channel id (must be 0) + +required: + - compatible + - reg + - reg-names + - interrupts + +unevaluatedProperties: false + +examples: + - | + #include + + msgdma_controller: dma-controller@ff200b00 { + compatible = "altr,socfpga-msgdma"; + reg = <0xff200b00 0x100>, <0xff200c00 0x100>, <0xff200d00 0x100>; + reg-names = "csr", "desc", "resp"; + interrupts = <0 67 IRQ_TYPE_LEVEL_HIGH>; + #dma-cells = <1>; + }; -- cgit v1.2.3 From ace5219f81f169ce7a02c7a6fc53b87c68f2b070 Mon Sep 17 00:00:00 2001 From: Linus Walleij Date: Mon, 3 May 2021 16:43:40 +0200 Subject: PCI: ixp4xx: Add device tree bindings for IXP4xx This adds device tree bindings for the Intel IXP4xx PCI controller which can be used as both host and option. Cc: devicetree@vger.kernel.org Cc: Arnd Bergmann Cc: Imre Kaloz Cc: Krzysztof Halasa Cc: Zoltan HERPAI Cc: Raylynn Knight Reviewed-by: Rob Herring Signed-off-by: Linus Walleij --- .../devicetree/bindings/pci/intel,ixp4xx-pci.yaml | 100 +++++++++++++++++++++ 1 file changed, 100 insertions(+) create mode 100644 Documentation/devicetree/bindings/pci/intel,ixp4xx-pci.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pci/intel,ixp4xx-pci.yaml b/Documentation/devicetree/bindings/pci/intel,ixp4xx-pci.yaml new file mode 100644 index 000000000000..debfb54a8042 --- /dev/null +++ b/Documentation/devicetree/bindings/pci/intel,ixp4xx-pci.yaml @@ -0,0 +1,100 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pci/intel,ixp4xx-pci.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Intel IXP4xx PCI controller + +maintainers: + - Linus Walleij + +description: PCI host controller found in the Intel IXP4xx SoC series. + +allOf: + - $ref: /schemas/pci/pci-bus.yaml# + +properties: + compatible: + items: + - enum: + - intel,ixp42x-pci + - intel,ixp43x-pci + description: The two supported variants are ixp42x and ixp43x, + though more variants may exist. + + reg: + items: + - description: IXP4xx-specific registers + + interrupts: + items: + - description: Main PCI interrupt + - description: PCI DMA interrupt 1 + - description: PCI DMA interrupt 2 + + ranges: + maxItems: 2 + description: Typically one memory range of 64MB and one IO + space range of 64KB. + + dma-ranges: + maxItems: 1 + description: The DMA range tells the PCI host which addresses + the RAM is at. It can map only 64MB so if the RAM is bigger + than 64MB the DMA access has to be restricted to these + addresses. + + "#interrupt-cells": true + + interrupt-map: true + + interrupt-map-mask: + items: + - const: 0xf800 + - const: 0 + - const: 0 + - const: 7 + +required: + - compatible + - reg + - dma-ranges + - "#interrupt-cells" + - interrupt-map + - interrupt-map-mask + +unevaluatedProperties: false + +examples: + - | + pci@c0000000 { + compatible = "intel,ixp43x-pci"; + reg = <0xc0000000 0x1000>; + #address-cells = <3>; + #size-cells = <2>; + device_type = "pci"; + bus-range = <0x00 0xff>; + + ranges = + <0x02000000 0 0x48000000 0x48000000 0 0x04000000>, + <0x01000000 0 0x00000000 0x4c000000 0 0x00010000>; + dma-ranges = + <0x02000000 0 0x00000000 0x00000000 0 0x04000000>; + + #interrupt-cells = <1>; + interrupt-map-mask = <0xf800 0 0 7>; + interrupt-map = + <0x0800 0 0 1 &gpio0 11 3>, /* INT A on slot 1 is irq 11 */ + <0x0800 0 0 2 &gpio0 10 3>, /* INT B on slot 1 is irq 10 */ + <0x0800 0 0 3 &gpio0 9 3>, /* INT C on slot 1 is irq 9 */ + <0x0800 0 0 4 &gpio0 8 3>, /* INT D on slot 1 is irq 8 */ + <0x1000 0 0 1 &gpio0 10 3>, /* INT A on slot 2 is irq 10 */ + <0x1000 0 0 2 &gpio0 9 3>, /* INT B on slot 2 is irq 9 */ + <0x1000 0 0 3 &gpio0 8 3>, /* INT C on slot 2 is irq 8 */ + <0x1000 0 0 4 &gpio0 11 3>, /* INT D on slot 2 is irq 11 */ + <0x1800 0 0 1 &gpio0 9 3>, /* INT A on slot 3 is irq 9 */ + <0x1800 0 0 2 &gpio0 8 3>, /* INT B on slot 3 is irq 8 */ + <0x1800 0 0 3 &gpio0 11 3>, /* INT C on slot 3 is irq 11 */ + <0x1800 0 0 4 &gpio0 10 3>; /* INT D on slot 3 is irq 10 */ + }; -- cgit v1.2.3 From b7fb14d3ac63117e0e8beabe75f4ea52051fbe3a Mon Sep 17 00:00:00 2001 From: Christoph Hellwig Date: Wed, 16 Jun 2021 15:46:58 +0200 Subject: ide: remove the legacy ide driver The legay ide driver has been replace with libata starting in 2003 and has been scheduled for removal for a while. Finally kill it off so that we can start cleaning up various bits of cruft it forced on the block layer. Signed-off-by: Christoph Hellwig Signed-off-by: Jens Axboe --- Documentation/userspace-api/ioctl/hdio.rst | 845 +---------------------------- 1 file changed, 25 insertions(+), 820 deletions(-) (limited to 'Documentation') diff --git a/Documentation/userspace-api/ioctl/hdio.rst b/Documentation/userspace-api/ioctl/hdio.rst index 817371bf94e9..6ee8fc88699f 100644 --- a/Documentation/userspace-api/ioctl/hdio.rst +++ b/Documentation/userspace-api/ioctl/hdio.rst @@ -7,8 +7,8 @@ Summary of `HDIO_` ioctl calls November, 2004 This document attempts to describe the ioctl(2) calls supported by -the HD/IDE layer. These are by-and-large implemented (as of Linux 2.6) -in drivers/ide/ide.c and drivers/block/scsi_ioctl.c +the HD/IDE layer. These are by-and-large implemented (as of Linux 5.11) +drivers/ata/libata-scsi.c. ioctl values are listed in . As of this writing, they are as follows: @@ -17,50 +17,17 @@ are as follows: ======================= ======================================= HDIO_GETGEO get device geometry - HDIO_GET_UNMASKINTR get current unmask setting - HDIO_GET_MULTCOUNT get current IDE blockmode setting - HDIO_GET_QDMA get use-qdma flag - HDIO_SET_XFER set transfer rate via proc - HDIO_OBSOLETE_IDENTITY OBSOLETE, DO NOT USE - HDIO_GET_KEEPSETTINGS get keep-settings-on-reset flag HDIO_GET_32BIT get current io_32bit setting - HDIO_GET_NOWERR get ignore-write-error flag - HDIO_GET_DMA get use-dma flag - HDIO_GET_NICE get nice flags HDIO_GET_IDENTITY get IDE identification info - HDIO_GET_WCACHE get write cache mode on|off - HDIO_GET_ACOUSTIC get acoustic value - HDIO_GET_ADDRESS get sector addressing mode - HDIO_GET_BUSSTATE get the bus state of the hwif - HDIO_TRISTATE_HWIF execute a channel tristate - HDIO_DRIVE_RESET execute a device reset HDIO_DRIVE_TASKFILE execute raw taskfile HDIO_DRIVE_TASK execute task and special drive command HDIO_DRIVE_CMD execute a special drive command - HDIO_DRIVE_CMD_AEB HDIO_DRIVE_TASK ======================= ======================================= ioctls that pass non-pointer values: ======================= ======================================= - HDIO_SET_MULTCOUNT change IDE blockmode - HDIO_SET_UNMASKINTR permit other irqs during I/O - HDIO_SET_KEEPSETTINGS keep ioctl settings on reset HDIO_SET_32BIT change io_32bit flags - HDIO_SET_NOWERR change ignore-write-error flag - HDIO_SET_DMA change use-dma flag - HDIO_SET_PIO_MODE reconfig interface to new speed - HDIO_SCAN_HWIF register and (re)scan interface - HDIO_SET_NICE set nice flags - HDIO_UNREGISTER_HWIF unregister interface - HDIO_SET_WCACHE change write cache enable-disable - HDIO_SET_ACOUSTIC change acoustic behavior - HDIO_SET_BUSSTATE set the bus state of the hwif - HDIO_SET_QDMA change use-qdma flag - HDIO_SET_ADDRESS change lba addressing modes - - HDIO_SET_IDE_SCSI Set scsi emulation mode on/off - HDIO_SET_SCSI_IDE not implemented yet ======================= ======================================= @@ -137,512 +104,49 @@ HDIO_GETGEO - -HDIO_GET_UNMASKINTR - get current unmask setting - - - usage:: - - long val; - - ioctl(fd, HDIO_GET_UNMASKINTR, &val); - - inputs: - none - - - - outputs: - The value of the drive's current unmask setting - - - - - -HDIO_SET_UNMASKINTR - permit other irqs during I/O - - - usage:: - - unsigned long val; - - ioctl(fd, HDIO_SET_UNMASKINTR, val); - - inputs: - New value for unmask flag - - - - outputs: - none - - - - error return: - - EINVAL Called on a partition instead of the whole disk device - - EACCES Access denied: requires CAP_SYS_ADMIN - - EINVAL value out of range [0 1] - - EBUSY Controller busy - - - - -HDIO_GET_MULTCOUNT - get current IDE blockmode setting - - - usage:: - - long val; - - ioctl(fd, HDIO_GET_MULTCOUNT, &val); - - inputs: - none - - - - outputs: - The value of the current IDE block mode setting. This - controls how many sectors the drive will transfer per - interrupt. - - - -HDIO_SET_MULTCOUNT - change IDE blockmode - - - usage:: - - int val; - - ioctl(fd, HDIO_SET_MULTCOUNT, val); - - inputs: - New value for IDE block mode setting. This controls how many - sectors the drive will transfer per interrupt. - - outputs: - none - - - - error return: - - EINVAL Called on a partition instead of the whole disk device - - EACCES Access denied: requires CAP_SYS_ADMIN - - EINVAL value out of range supported by disk. - - EBUSY Controller busy or blockmode already set. - - EIO Drive did not accept new block mode. - - notes: - Source code comments read:: - - This is tightly woven into the driver->do_special cannot - touch. DON'T do it again until a total personality rewrite - is committed. - - If blockmode has already been set, this ioctl will fail with - -EBUSY - - - -HDIO_GET_QDMA - get use-qdma flag - - - Not implemented, as of 2.6.8.1 - - - -HDIO_SET_XFER - set transfer rate via proc - - - Not implemented, as of 2.6.8.1 - - - -HDIO_OBSOLETE_IDENTITY - OBSOLETE, DO NOT USE - - - Same as HDIO_GET_IDENTITY (see below), except that it only - returns the first 142 bytes of drive identity information. - - - -HDIO_GET_IDENTITY - get IDE identification info - - - usage:: - - unsigned char identity[512]; - - ioctl(fd, HDIO_GET_IDENTITY, identity); - - inputs: - none - - - - outputs: - ATA drive identity information. For full description, see - the IDENTIFY DEVICE and IDENTIFY PACKET DEVICE commands in - the ATA specification. - - error returns: - - EINVAL Called on a partition instead of the whole disk device - - ENOMSG IDENTIFY DEVICE information not available - - notes: - Returns information that was obtained when the drive was - probed. Some of this information is subject to change, and - this ioctl does not re-probe the drive to update the - information. - - This information is also available from /proc/ide/hdX/identify - - - -HDIO_GET_KEEPSETTINGS - get keep-settings-on-reset flag - - - usage:: - - long val; - - ioctl(fd, HDIO_GET_KEEPSETTINGS, &val); - - inputs: - none - - - - outputs: - The value of the current "keep settings" flag - - - - notes: - When set, indicates that kernel should restore settings - after a drive reset. - - - -HDIO_SET_KEEPSETTINGS - keep ioctl settings on reset - - - usage:: - - long val; - - ioctl(fd, HDIO_SET_KEEPSETTINGS, val); - - inputs: - New value for keep_settings flag - - - - outputs: - none - - - - error return: - - EINVAL Called on a partition instead of the whole disk device - - EACCES Access denied: requires CAP_SYS_ADMIN - - EINVAL value out of range [0 1] - - EBUSY Controller busy - - - -HDIO_GET_32BIT - get current io_32bit setting - - - usage:: - - long val; - - ioctl(fd, HDIO_GET_32BIT, &val); - - inputs: - none - - - - outputs: - The value of the current io_32bit setting - - - - notes: - 0=16-bit, 1=32-bit, 2,3 = 32bit+sync - - - - - -HDIO_GET_NOWERR - get ignore-write-error flag - - - usage:: - - long val; - - ioctl(fd, HDIO_GET_NOWERR, &val); - - inputs: - none - - - - outputs: - The value of the current ignore-write-error flag - - - - - -HDIO_GET_DMA - get use-dma flag - - - usage:: - - long val; - - ioctl(fd, HDIO_GET_DMA, &val); - - inputs: - none - - - - outputs: - The value of the current use-dma flag - - - - - -HDIO_GET_NICE - get nice flags - - - usage:: - - long nice; - - ioctl(fd, HDIO_GET_NICE, &nice); - - inputs: - none - - - - outputs: - The drive's "nice" values. - - - - notes: - Per-drive flags which determine when the system will give more - bandwidth to other devices sharing the same IDE bus. - - See , near symbol IDE_NICE_DSC_OVERLAP. - - - - -HDIO_SET_NICE - set nice flags - - - usage:: - - unsigned long nice; - - ... - ioctl(fd, HDIO_SET_NICE, nice); - - inputs: - bitmask of nice flags. - - - - outputs: - none - - - - error returns: - - EACCES Access denied: requires CAP_SYS_ADMIN - - EPERM Flags other than DSC_OVERLAP and NICE_1 set. - - EPERM DSC_OVERLAP specified but not supported by drive - - notes: - This ioctl sets the DSC_OVERLAP and NICE_1 flags from values - provided by the user. - - Nice flags are listed in , starting with - IDE_NICE_DSC_OVERLAP. These values represent shifts. - - - - - -HDIO_GET_WCACHE - get write cache mode on|off - - - usage:: - - long val; - - ioctl(fd, HDIO_GET_WCACHE, &val); - - inputs: - none - - - - outputs: - The value of the current write cache mode - - - - - -HDIO_GET_ACOUSTIC - get acoustic value - - - usage:: - - long val; - - ioctl(fd, HDIO_GET_ACOUSTIC, &val); - - inputs: - none - - - - outputs: - The value of the current acoustic settings - - - - notes: - See HDIO_SET_ACOUSTIC - - - - - -HDIO_GET_ADDRESS - usage:: - - - long val; - - ioctl(fd, HDIO_GET_ADDRESS, &val); - - inputs: - none - - - - outputs: - The value of the current addressing mode: - - = =================== - 0 28-bit - 1 48-bit - 2 48-bit doing 28-bit - 3 64-bit - = =================== - - - -HDIO_GET_BUSSTATE - get the bus state of the hwif - - - usage:: - - long state; - - ioctl(fd, HDIO_SCAN_HWIF, &state); - - inputs: - none - - - - outputs: - Current power state of the IDE bus. One of BUSSTATE_OFF, - BUSSTATE_ON, or BUSSTATE_TRISTATE - - error returns: - - EACCES Access denied: requires CAP_SYS_ADMIN - - - - -HDIO_SET_BUSSTATE - set the bus state of the hwif +HDIO_GET_IDENTITY + get IDE identification info usage:: - int state; + unsigned char identity[512]; - ... - ioctl(fd, HDIO_SCAN_HWIF, state); + ioctl(fd, HDIO_GET_IDENTITY, identity); inputs: - Desired IDE power state. One of BUSSTATE_OFF, BUSSTATE_ON, - or BUSSTATE_TRISTATE - - outputs: none - error returns: - - EACCES Access denied: requires CAP_SYS_RAWIO - - EOPNOTSUPP Hardware interface does not support bus power control - - - + outputs: + ATA drive identity information. For full description, see + the IDENTIFY DEVICE and IDENTIFY PACKET DEVICE commands in + the ATA specification. -HDIO_TRISTATE_HWIF - execute a channel tristate + error returns: + - EINVAL Called on a partition instead of the whole disk device + - ENOMSG IDENTIFY DEVICE information not available + notes: + Returns information that was obtained when the drive was + probed. Some of this information is subject to change, and + this ioctl does not re-probe the drive to update the + information. - Not implemented, as of 2.6.8.1. See HDIO_SET_BUSSTATE + This information is also available from /proc/ide/hdX/identify -HDIO_DRIVE_RESET - execute a device reset +HDIO_GET_32BIT + get current io_32bit setting usage:: - int args[3] + long val; - ... - ioctl(fd, HDIO_DRIVE_RESET, args); + ioctl(fd, HDIO_GET_32BIT, &val); inputs: none @@ -650,22 +154,12 @@ HDIO_DRIVE_RESET outputs: - none - + The value of the current io_32bit setting - error returns: - - EACCES Access denied: requires CAP_SYS_ADMIN - - ENXIO No such device: phy dead or ctl_addr == 0 - - EIO I/O error: reset timed out or hardware error notes: - - - Execute a reset on the device as soon as the current IO - operation has completed. - - - Executes an ATAPI soft reset if applicable, otherwise - executes an ATA soft reset on the controller. + 0=16-bit, 1=32-bit, 2,3 = 32bit+sync @@ -1026,14 +520,6 @@ HDIO_DRIVE_TASK -HDIO_DRIVE_CMD_AEB - HDIO_DRIVE_TASK - - - Not implemented, as of 2.6.8.1 - - - HDIO_SET_32BIT change io_32bit flags @@ -1059,284 +545,3 @@ HDIO_SET_32BIT - EACCES Access denied: requires CAP_SYS_ADMIN - EINVAL value out of range [0 3] - EBUSY Controller busy - - - - -HDIO_SET_NOWERR - change ignore-write-error flag - - - usage:: - - int val; - - ioctl(fd, HDIO_SET_NOWERR, val); - - inputs: - New value for ignore-write-error flag. Used for ignoring - - - WRERR_STAT - - outputs: - none - - - - error return: - - EINVAL Called on a partition instead of the whole disk device - - EACCES Access denied: requires CAP_SYS_ADMIN - - EINVAL value out of range [0 1] - - EBUSY Controller busy - - - -HDIO_SET_DMA - change use-dma flag - - - usage:: - - long val; - - ioctl(fd, HDIO_SET_DMA, val); - - inputs: - New value for use-dma flag - - - - outputs: - none - - - - error return: - - EINVAL Called on a partition instead of the whole disk device - - EACCES Access denied: requires CAP_SYS_ADMIN - - EINVAL value out of range [0 1] - - EBUSY Controller busy - - - -HDIO_SET_PIO_MODE - reconfig interface to new speed - - - usage:: - - long val; - - ioctl(fd, HDIO_SET_PIO_MODE, val); - - inputs: - New interface speed. - - - - outputs: - none - - - - error return: - - EINVAL Called on a partition instead of the whole disk device - - EACCES Access denied: requires CAP_SYS_ADMIN - - EINVAL value out of range [0 255] - - EBUSY Controller busy - - - -HDIO_SCAN_HWIF - register and (re)scan interface - - - usage:: - - int args[3] - - ... - ioctl(fd, HDIO_SCAN_HWIF, args); - - inputs: - - ======= ========================= - args[0] io address to probe - - - args[1] control address to probe - args[2] irq number - ======= ========================= - - outputs: - none - - - - error returns: - - EACCES Access denied: requires CAP_SYS_RAWIO - - EIO Probe failed. - - notes: - This ioctl initializes the addresses and irq for a disk - controller, probes for drives, and creates /proc/ide - interfaces as appropriate. - - - -HDIO_UNREGISTER_HWIF - unregister interface - - - usage:: - - int index; - - ioctl(fd, HDIO_UNREGISTER_HWIF, index); - - inputs: - index index of hardware interface to unregister - - - - outputs: - none - - - - error returns: - - EACCES Access denied: requires CAP_SYS_RAWIO - - notes: - This ioctl removes a hardware interface from the kernel. - - Currently (2.6.8) this ioctl silently fails if any drive on - the interface is busy. - - - -HDIO_SET_WCACHE - change write cache enable-disable - - - usage:: - - int val; - - ioctl(fd, HDIO_SET_WCACHE, val); - - inputs: - New value for write cache enable - - - - outputs: - none - - - - error return: - - EINVAL Called on a partition instead of the whole disk device - - EACCES Access denied: requires CAP_SYS_ADMIN - - EINVAL value out of range [0 1] - - EBUSY Controller busy - - - -HDIO_SET_ACOUSTIC - change acoustic behavior - - - usage:: - - int val; - - ioctl(fd, HDIO_SET_ACOUSTIC, val); - - inputs: - New value for drive acoustic settings - - - - outputs: - none - - - - error return: - - EINVAL Called on a partition instead of the whole disk device - - EACCES Access denied: requires CAP_SYS_ADMIN - - EINVAL value out of range [0 254] - - EBUSY Controller busy - - - -HDIO_SET_QDMA - change use-qdma flag - - - Not implemented, as of 2.6.8.1 - - - -HDIO_SET_ADDRESS - change lba addressing modes - - - usage:: - - int val; - - ioctl(fd, HDIO_SET_ADDRESS, val); - - inputs: - New value for addressing mode - - = =================== - 0 28-bit - 1 48-bit - 2 48-bit doing 28-bit - = =================== - - outputs: - none - - - - error return: - - EINVAL Called on a partition instead of the whole disk device - - EACCES Access denied: requires CAP_SYS_ADMIN - - EINVAL value out of range [0 2] - - EBUSY Controller busy - - EIO Drive does not support lba48 mode. - - -HDIO_SET_IDE_SCSI - usage:: - - - long val; - - ioctl(fd, HDIO_SET_IDE_SCSI, val); - - inputs: - New value for scsi emulation mode (?) - - - - outputs: - none - - - - error return: - - EINVAL Called on a partition instead of the whole disk device - - EACCES Access denied: requires CAP_SYS_ADMIN - - EINVAL value out of range [0 1] - - EBUSY Controller busy - - - -HDIO_SET_SCSI_IDE - Not implemented, as of 2.6.8.1 -- cgit v1.2.3 From 8af9fa37b8a3637832cbf8fdd9bd828bd5f0de66 Mon Sep 17 00:00:00 2001 From: Perry Yuan Date: Thu, 6 May 2021 19:56:05 +0800 Subject: platform/x86: dell-privacy: Add support for Dell hardware privacy add support for Dell privacy driver for the Dell units equipped hardware privacy design, which protect users privacy of audio and camera from hardware level. Once the audio or camera privacy mode activated, any applications will not get any audio or video stream when user pressed ctrl+F4 hotkey, audio privacy mode will be enabled, micmute led will be also changed accordingly The micmute led is fully controlled by hardware & EC(embedded controller) and camera mute hotkey is Ctrl+F9. Currently design only emits SW_CAMERA_LENS_COVER event while the camera lens shutter will be changed by EC & HW(hardware) control *The flow is like this: 1) User presses key. HW does stuff with this key (timeout timer is started) 2) WMI event is emitted from BIOS to kernel 3) WMI event is received by dell-privacy 4) KEY_MICMUTE emitted from dell-privacy 5) Userland picks up key and modifies kcontrol for SW mute 6) Codec kernel driver catches and calls ledtrig_audio_set 7) dell-privacy notifies EC, the timeout is cancelled and the HW mute is activated. If the EC is not notified then the HW mic mute will activate when the timeout triggers, just a bit later than with the active ack. Signed-off-by: Perry Yuan Link: https://lore.kernel.org/r/20210506115605.1504-1-Perry_Yuan@Dell.com [hdegoede@redhat.com: Rework Kconfig/Makefile bits + other small fixups] Reviewed-by: Hans de Goede Signed-off-by: Hans de Goede --- .../ABI/testing/sysfs-platform-dell-privacy-wmi | 55 ++++++++++++++++++++++ 1 file changed, 55 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-platform-dell-privacy-wmi (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-platform-dell-privacy-wmi b/Documentation/ABI/testing/sysfs-platform-dell-privacy-wmi new file mode 100644 index 000000000000..7f9e18705861 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-platform-dell-privacy-wmi @@ -0,0 +1,55 @@ +What: /sys/bus/wmi/devices/6932965F-1671-4CEB-B988-D3AB0A901919/dell_privacy_supported_type +Date: Apr 2021 +KernelVersion: 5.13 +Contact: "perry.yuan@dell.com>" +Description: + Display which dell hardware level privacy devices are supported + “Dell Privacy” is a set of HW, FW, and SW features to enhance + Dell’s commitment to platform privacy for MIC, Camera, and + ePrivacy screens. + The supported hardware privacy devices are: +Attributes: + Microphone Mute: + Identifies the local microphone can be muted by hardware, no applications + is available to capture system mic sound + + Camera Shutter: + Identifies camera shutter controlled by hardware, which is a micromechanical + shutter assembly that is built onto the camera module to block capturing images + from outside the laptop + + supported: + The privacy device is supported by this system + + unsupported: + The privacy device is not supported on this system + + For example to check which privacy devices are supported: + + # cat /sys/bus/wmi/drivers/dell-privacy/6932965F-1671-4CEB-B988-D3AB0A901919/dell_privacy_supported_type + [Microphone Mute] [supported] + [Camera Shutter] [supported] + [ePrivacy Screen] [unsupported] + +What: /sys/bus/wmi/devices/6932965F-1671-4CEB-B988-D3AB0A901919/dell_privacy_current_state +Date: Apr 2021 +KernelVersion: 5.13 +Contact: "perry.yuan@dell.com>" +Description: + Allow user space to check current dell privacy device state. + Describes the Device State class exposed by BIOS which can be + consumed by various applications interested in knowing the Privacy + feature capabilities +Attributes: + muted: + Identifies the privacy device is turned off and cannot send stream to OS applications + + unmuted: + Identifies the privacy device is turned on ,audio or camera driver can get + stream from mic and camera module to OS applications + + For example to check all supported current privacy device states: + + # cat /sys/bus/wmi/drivers/dell-privacy/6932965F-1671-4CEB-B988-D3AB0A901919/dell_privacy_current_state + [Microphone] [unmuted] + [Camera Shutter] [unmuted] -- cgit v1.2.3 From a40cd7ef22fbb11229cf982920f4ec96c1f49282 Mon Sep 17 00:00:00 2001 From: Mark Pearson Date: Sun, 30 May 2021 18:31:11 -0400 Subject: platform/x86: think-lmi: Add WMI interface support on Lenovo platforms For Lenovo platforms that support a WMI interface to the BIOS add support, using the firmware-attributes class, to allow users to access and modify various BIOS related settings. Signed-off-by: Mark Pearson Link: https://lore.kernel.org/r/20210530223111.25929-3-markpearson@lenovo.com Reviewed-by: Hans de Goede Signed-off-by: Hans de Goede --- .../ABI/testing/sysfs-class-firmware-attributes | 18 +++++++++++++++++- 1 file changed, 17 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-class-firmware-attributes b/Documentation/ABI/testing/sysfs-class-firmware-attributes index 8ea59fea4709..3348bf80a37c 100644 --- a/Documentation/ABI/testing/sysfs-class-firmware-attributes +++ b/Documentation/ABI/testing/sysfs-class-firmware-attributes @@ -197,8 +197,24 @@ Description: Drivers may emit a CHANGE uevent when a password is set or unset userspace may check it again. - On Dell systems, if Admin password is set, then all BIOS attributes + On Dell and Lenovo systems, if Admin password is set, then all BIOS attributes require password validation. + On Lenovo systems if you change the Admin password the new password is not active until + the next boot. + + Lenovo specific class extensions + ------------------------------ + + On Lenovo systems the following additional settings are available: + + lenovo_encoding: + The encoding method that is used. This can be either "ascii" + or "scancode". Default is set to "ascii" + + lenovo_kbdlang: + The keyboard language method that is used. This is generally a + two char code (e.g. "us", "fr", "gr") and may vary per platform. + Default is set to "us" What: /sys/class/firmware-attributes/*/attributes/pending_reboot Date: February 2021 -- cgit v1.2.3 From 776c53c6a448905d8b9b161805b67f82301bfe91 Mon Sep 17 00:00:00 2001 From: Maximilian Luz Date: Fri, 4 Jun 2021 15:47:52 +0200 Subject: platform/surface: aggregator_cdev: Add support for forwarding events to user-space Currently, debugging unknown events requires writing a custom driver. This is somewhat difficult, slow to adapt, and not entirely user-friendly for quickly trying to figure out things on devices of some third-party user. We can do better. We already have a user-space interface intended for debugging SAM EC requests, so let's add support for receiving events to that. This commit provides support for receiving events by reading from the controller file. It additionally introduces two new IOCTLs to control which event categories will be forwarded. Specifically, a user-space client can specify which target categories it wants to receive events from by registering the corresponding notifier(s) via the IOCTLs and after that, read the received events by reading from the controller device. Signed-off-by: Maximilian Luz Reviewed-by: Hans de Goede Link: https://lore.kernel.org/r/20210604134755.535590-5-luzmaximilian@gmail.com Signed-off-by: Hans de Goede --- Documentation/userspace-api/ioctl/ioctl-number.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/userspace-api/ioctl/ioctl-number.rst b/Documentation/userspace-api/ioctl/ioctl-number.rst index 9bfc2b510c64..1409e40e6345 100644 --- a/Documentation/userspace-api/ioctl/ioctl-number.rst +++ b/Documentation/userspace-api/ioctl/ioctl-number.rst @@ -325,7 +325,7 @@ Code Seq# Include File Comments 0xA3 90-9F linux/dtlk.h 0xA4 00-1F uapi/linux/tee.h Generic TEE subsystem 0xA4 00-1F uapi/asm/sgx.h -0xA5 01 linux/surface_aggregator/cdev.h Microsoft Surface Platform System Aggregator +0xA5 01-05 linux/surface_aggregator/cdev.h Microsoft Surface Platform System Aggregator 0xA5 20-2F linux/surface_aggregator/dtx.h Microsoft Surface DTX driver -- cgit v1.2.3 From 8ae200547aa9dbb1001c22325d251b825113bdb3 Mon Sep 17 00:00:00 2001 From: Maximilian Luz Date: Fri, 4 Jun 2021 15:47:55 +0200 Subject: docs: driver-api: Update Surface Aggregator user-space interface documentation Update the controller-device user-space interface (cdev) documentation for the newly introduced IOCTLs and event interface. Signed-off-by: Maximilian Luz Reviewed-by: Hans de Goede Link: https://lore.kernel.org/r/20210604134755.535590-8-luzmaximilian@gmail.com Signed-off-by: Hans de Goede --- .../driver-api/surface_aggregator/clients/cdev.rst | 127 ++++++++++++++++++++- 1 file changed, 122 insertions(+), 5 deletions(-) (limited to 'Documentation') diff --git a/Documentation/driver-api/surface_aggregator/clients/cdev.rst b/Documentation/driver-api/surface_aggregator/clients/cdev.rst index 248c1372d879..0134a841a079 100644 --- a/Documentation/driver-api/surface_aggregator/clients/cdev.rst +++ b/Documentation/driver-api/surface_aggregator/clients/cdev.rst @@ -1,9 +1,8 @@ .. SPDX-License-Identifier: GPL-2.0+ -.. |u8| replace:: :c:type:`u8 ` -.. |u16| replace:: :c:type:`u16 ` .. |ssam_cdev_request| replace:: :c:type:`struct ssam_cdev_request ` .. |ssam_cdev_request_flags| replace:: :c:type:`enum ssam_cdev_request_flags ` +.. |ssam_cdev_event| replace:: :c:type:`struct ssam_cdev_event ` ============================== User-Space EC Interface (cdev) @@ -23,6 +22,40 @@ These IOCTLs and their respective input/output parameter structs are defined in A small python library and scripts for accessing this interface can be found at https://github.com/linux-surface/surface-aggregator-module/tree/master/scripts/ssam. +.. contents:: + + +Receiving Events +================ + +Events can be received by reading from the device-file. The are represented by +the |ssam_cdev_event| datatype. + +Before events are available to be read, however, the desired notifiers must be +registered via the ``SSAM_CDEV_NOTIF_REGISTER`` IOCTL. Notifiers are, in +essence, callbacks, called when the EC sends an event. They are, in this +interface, associated with a specific target category and device-file-instance. +They forward any event of this category to the buffer of the corresponding +instance, from which it can then be read. + +Notifiers themselves do not enable events on the EC. Thus, it may additionally +be necessary to enable events via the ``SSAM_CDEV_EVENT_ENABLE`` IOCTL. While +notifiers work per-client (i.e. per-device-file-instance), events are enabled +globally, for the EC and all of its clients (regardless of userspace or +non-userspace). The ``SSAM_CDEV_EVENT_ENABLE`` and ``SSAM_CDEV_EVENT_DISABLE`` +IOCTLs take care of reference counting the events, such that an event is +enabled as long as there is a client that has requested it. + +Note that enabled events are not automatically disabled once the client +instance is closed. Therefore any client process (or group of processes) should +balance their event enable calls with the corresponding event disable calls. It +is, however, perfectly valid to enable and disable events on different client +instances. For example, it is valid to set up notifiers and read events on +client instance ``A``, enable those events on instance ``B`` (note that these +will also be received by A since events are enabled/disabled globally), and +after no more events are desired, disable the previously enabled events via +instance ``C``. + Controller IOCTLs ================= @@ -45,9 +78,33 @@ The following IOCTLs are provided: - ``REQUEST`` - Perform synchronous SAM request. + * - ``0xA5`` + - ``2`` + - ``W`` + - ``NOTIF_REGISTER`` + - Register event notifier. -``REQUEST`` ------------ + * - ``0xA5`` + - ``3`` + - ``W`` + - ``NOTIF_UNREGISTER`` + - Unregister event notifier. + + * - ``0xA5`` + - ``4`` + - ``W`` + - ``EVENT_ENABLE`` + - Enable event source. + + * - ``0xA5`` + - ``5`` + - ``W`` + - ``EVENT_DISABLE`` + - Disable event source. + + +``SSAM_CDEV_REQUEST`` +--------------------- Defined as ``_IOWR(0xA5, 1, struct ssam_cdev_request)``. @@ -82,6 +139,66 @@ submitted, and completed (i.e. handed back to user-space) successfully from inside the IOCTL, but the request ``status`` member may still be negative in case the actual execution of the request failed after it has been submitted. -A full definition of the argument struct is provided below: +A full definition of the argument struct is provided below. + +``SSAM_CDEV_NOTIF_REGISTER`` +---------------------------- + +Defined as ``_IOW(0xA5, 2, struct ssam_cdev_notifier_desc)``. + +Register a notifier for the event target category specified in the given +notifier description with the specified priority. Notifiers registration is +required to receive events, but does not enable events themselves. After a +notifier for a specific target category has been registered, all events of that +category will be forwarded to the userspace client and can then be read from +the device file instance. Note that events may have to be enabled, e.g. via the +``SSAM_CDEV_EVENT_ENABLE`` IOCTL, before the EC will send them. + +Only one notifier can be registered per target category and client instance. If +a notifier has already been registered, this IOCTL will fail with ``-EEXIST``. + +Notifiers will automatically be removed when the device file instance is +closed. + +``SSAM_CDEV_NOTIF_UNREGISTER`` +------------------------------ + +Defined as ``_IOW(0xA5, 3, struct ssam_cdev_notifier_desc)``. + +Unregisters the notifier associated with the specified target category. The +priority field will be ignored by this IOCTL. If no notifier has been +registered for this client instance and the given category, this IOCTL will +fail with ``-ENOENT``. + +``SSAM_CDEV_EVENT_ENABLE`` +-------------------------- + +Defined as ``_IOW(0xA5, 4, struct ssam_cdev_event_desc)``. + +Enable the event associated with the given event descriptor. + +Note that this call will not register a notifier itself, it will only enable +events on the controller. If you want to receive events by reading from the +device file, you will need to register the corresponding notifier(s) on that +instance. + +Events are not automatically disabled when the device file is closed. This must +be done manually, via a call to the ``SSAM_CDEV_EVENT_DISABLE`` IOCTL. + +``SSAM_CDEV_EVENT_DISABLE`` +--------------------------- + +Defined as ``_IOW(0xA5, 5, struct ssam_cdev_event_desc)``. + +Disable the event associated with the given event descriptor. + +Note that this will not unregister any notifiers. Events may still be received +and forwarded to user-space after this call. The only safe way of stopping +events from being received is unregistering all previously registered +notifiers. + + +Structures and Enums +==================== .. kernel-doc:: include/uapi/linux/surface_aggregator/cdev.h -- cgit v1.2.3 From 7bb9557b48fcabaa12750a8775352740def381a8 Mon Sep 17 00:00:00 2001 From: Kees Cook Date: Mon, 14 Jun 2021 12:39:51 -0700 Subject: pstore/blk: Use the normal block device I/O path Stop poking into block layer internals and just open the block device file an use kernel_read and kernel_write on it. Note that this means the transformation from name_to_dev_t can't be used anymore when pstore_blk is loaded as a module: a full filesystem device path name must be used instead. Additionally removes ":internal:" kerndoc link, since no such documentation remains. Co-developed-by: Christoph Hellwig Signed-off-by: Christoph Hellwig Reviewed-by: Christoph Hellwig Signed-off-by: Kees Cook --- Documentation/admin-guide/pstore-blk.rst | 3 --- 1 file changed, 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/admin-guide/pstore-blk.rst b/Documentation/admin-guide/pstore-blk.rst index 49d8149f8d32..79f6d23e8cda 100644 --- a/Documentation/admin-guide/pstore-blk.rst +++ b/Documentation/admin-guide/pstore-blk.rst @@ -227,8 +227,5 @@ For developer reference, here are all the important structures and APIs: .. kernel-doc:: include/linux/pstore_zone.h :internal: -.. kernel-doc:: fs/pstore/blk.c - :internal: - .. kernel-doc:: include/linux/pstore_blk.h :internal: -- cgit v1.2.3 From c811659bb9a09b319842bf61602ce858b1d1920a Mon Sep 17 00:00:00 2001 From: Kees Cook Date: Tue, 15 Jun 2021 10:33:00 -0700 Subject: pstore/blk: Fix kerndoc and redundancy on blkdev param Remove redundant details of blkdev and fix up resulting kerndoc. Reviewed-by: Christoph Hellwig Signed-off-by: Kees Cook --- Documentation/admin-guide/pstore-blk.rst | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/admin-guide/pstore-blk.rst b/Documentation/admin-guide/pstore-blk.rst index 79f6d23e8cda..2d22ead9520e 100644 --- a/Documentation/admin-guide/pstore-blk.rst +++ b/Documentation/admin-guide/pstore-blk.rst @@ -45,15 +45,18 @@ blkdev The block device to use. Most of the time, it is a partition of block device. It's required for pstore/blk. It is also used for MTD device. -It accepts the following variants for block device: +When pstore/blk is built as a module, "blkdev" accepts the following variants: -1. device number in hexadecimal represents itself; no - leading 0x, for example b302. -#. /dev/ represents the device number of disk +1. /dev/ represents the device number of disk #. /dev/ represents the device number of partition - device number of disk plus the partition number #. /dev/p - same as the above; this form is used when disk name of partitioned disk ends with a digit. + +When pstore/blk is built into the kernel, "blkdev" accepts the following variants: + +#. device number in hexadecimal representation, + with no leading 0x, for example b302. #. PARTUUID=00112233-4455-6677-8899-AABBCCDDEEFF represents the unique id of a partition if the partition table provides it. The UUID may be either an EFI/GPT UUID, or refer to an MSDOS partition using the format SSSSSSSS-PP, -- cgit v1.2.3 From fda0b5ba9d5a9f6bfab9bc195f7a8fce13aedf61 Mon Sep 17 00:00:00 2001 From: Kir Kolyshkin Date: Mon, 14 Jun 2021 14:41:09 -0700 Subject: docs: block/bfq: describe per-device weight The functionality of setting per-device weight for BFQ was added in v5.4 (commit 795fe54c2a828099), but the documentation was never updated. While at it, improve formatting a bit. Signed-off-by: Kir Kolyshkin Link: https://lore.kernel.org/r/20210614214109.207430-1-kolyshkin@gmail.com Acked-by: Tejun Heo Signed-off-by: Jens Axboe --- Documentation/block/bfq-iosched.rst | 38 ++++++++++++++++++++++++++----------- 1 file changed, 27 insertions(+), 11 deletions(-) (limited to 'Documentation') diff --git a/Documentation/block/bfq-iosched.rst b/Documentation/block/bfq-iosched.rst index 66c5a4e54130..df3a8a47f58c 100644 --- a/Documentation/block/bfq-iosched.rst +++ b/Documentation/block/bfq-iosched.rst @@ -553,20 +553,36 @@ throughput sustainable with bfq, because updating the blkio.bfq.* stats is rather costly, especially for some of the stats enabled by CONFIG_BFQ_CGROUP_DEBUG. -Parameters to set ------------------ +Parameters +---------- -For each group, there is only the following parameter to set. +For each group, the following parameters can be set: -weight (namely blkio.bfq.weight or io.bfq-weight): the weight of the -group inside its parent. Available values: 1..1000 (default 100). The -linear mapping between ioprio and weights, described at the beginning -of the tunable section, is still valid, but all weights higher than -IOPRIO_BE_NR*10 are mapped to ioprio 0. + weight + This specifies the default weight for the cgroup inside its parent. + Available values: 1..1000 (default: 100). -Recall that, if low-latency is set, then BFQ automatically raises the -weight of the queues associated with interactive and soft real-time -applications. Unset this tunable if you need/want to control weights. + For cgroup v1, it is set by writing the value to `blkio.bfq.weight`. + + For cgroup v2, it is set by writing the value to `io.bfq.weight`. + (with an optional prefix of `default` and a space). + + The linear mapping between ioprio and weights, described at the beginning + of the tunable section, is still valid, but all weights higher than + IOPRIO_BE_NR*10 are mapped to ioprio 0. + + Recall that, if low-latency is set, then BFQ automatically raises the + weight of the queues associated with interactive and soft real-time + applications. Unset this tunable if you need/want to control weights. + + weight_device + This specifies a per-device weight for the cgroup. The syntax is + `minor:major weight`. A weight of `0` may be used to reset to the default + weight. + + For cgroup v1, it is set by writing the value to `blkio.bfq.weight_device`. + + For cgroup v2, the file name is `io.bfq.weight`. [1] -- cgit v1.2.3 From 37fe403898b2fa5fc9d3616fcda2ee6629318aab Mon Sep 17 00:00:00 2001 From: Kir Kolyshkin Date: Thu, 10 Jun 2021 20:07:36 -0700 Subject: docs/cgroup-v1/blkio: stop abusing itemized list Fix many formatting issues by stop (ab)using itemized lists for everything (mostly replaced by definition lists). Acked-by: Tejun Heo Signed-off-by: Kir Kolyshkin Signed-off-by: Jens Axboe --- .../admin-guide/cgroup-v1/blkio-controller.rst | 130 +++++++++++---------- 1 file changed, 67 insertions(+), 63 deletions(-) (limited to 'Documentation') diff --git a/Documentation/admin-guide/cgroup-v1/blkio-controller.rst b/Documentation/admin-guide/cgroup-v1/blkio-controller.rst index 36d43ae7dc13..8101dcba381d 100644 --- a/Documentation/admin-guide/cgroup-v1/blkio-controller.rst +++ b/Documentation/admin-guide/cgroup-v1/blkio-controller.rst @@ -17,36 +17,37 @@ level logical devices like device mapper. HOWTO ===== + Throttling/Upper Limit policy ----------------------------- -- Enable Block IO controller:: +Enable Block IO controller:: CONFIG_BLK_CGROUP=y -- Enable throttling in block layer:: +Enable throttling in block layer:: CONFIG_BLK_DEV_THROTTLING=y -- Mount blkio controller (see cgroups.txt, Why are cgroups needed?):: +Mount blkio controller (see cgroups.txt, Why are cgroups needed?):: mount -t cgroup -o blkio none /sys/fs/cgroup/blkio -- Specify a bandwidth rate on particular device for root group. The format - for policy is ": ":: +Specify a bandwidth rate on particular device for root group. The format +for policy is ": ":: echo "8:16 1048576" > /sys/fs/cgroup/blkio/blkio.throttle.read_bps_device - Above will put a limit of 1MB/second on reads happening for root group - on device having major/minor number 8:16. +This will put a limit of 1MB/second on reads happening for root group +on device having major/minor number 8:16. -- Run dd to read a file and see if rate is throttled to 1MB/s or not:: +Run dd to read a file and see if rate is throttled to 1MB/s or not:: # dd iflag=direct if=/mnt/common/zerofile of=/dev/null bs=4K count=1024 1024+0 records in 1024+0 records out 4194304 bytes (4.2 MB) copied, 4.0001 s, 1.0 MB/s - Limits for writes can be put using blkio.throttle.write_bps_device file. +Limits for writes can be put using blkio.throttle.write_bps_device file. Hierarchical Cgroups ==================== @@ -79,28 +80,31 @@ following:: Various user visible config options =================================== -CONFIG_BLK_CGROUP - - Block IO controller. -CONFIG_BFQ_CGROUP_DEBUG - - Debug help. Right now some additional stats file show up in cgroup + CONFIG_BLK_CGROUP + Block IO controller. + + CONFIG_BFQ_CGROUP_DEBUG + Debug help. Right now some additional stats file show up in cgroup if this option is enabled. -CONFIG_BLK_DEV_THROTTLING - - Enable block device throttling support in block layer. + CONFIG_BLK_DEV_THROTTLING + Enable block device throttling support in block layer. Details of cgroup files ======================= + Proportional weight policy files -------------------------------- -- blkio.weight - - Specifies per cgroup weight. This is default weight of the group + + blkio.weight + Specifies per cgroup weight. This is default weight of the group on all the devices until and unless overridden by per device rule. (See blkio.weight_device). Currently allowed range of weights is from 10 to 1000. -- blkio.weight_device - - One can specify per cgroup per device rules using this interface. + blkio.weight_device + One can specify per cgroup per device rules using this interface. These rules override the default value of group weight as specified by blkio.weight. @@ -130,34 +134,34 @@ Proportional weight policy files dev weight 8:16 300 -- blkio.time - - disk time allocated to cgroup per device in milliseconds. First + blkio.time + Disk time allocated to cgroup per device in milliseconds. First two fields specify the major and minor number of the device and third field specifies the disk time allocated to group in milliseconds. -- blkio.sectors - - number of sectors transferred to/from disk by the group. First + blkio.sectors + Number of sectors transferred to/from disk by the group. First two fields specify the major and minor number of the device and third field specifies the number of sectors transferred by the group to/from the device. -- blkio.io_service_bytes - - Number of bytes transferred to/from the disk by the group. These + blkio.io_service_bytes + Number of bytes transferred to/from the disk by the group. These are further divided by the type of operation - read or write, sync or async. First two fields specify the major and minor number of the device, third field specifies the operation type and the fourth field specifies the number of bytes. -- blkio.io_serviced - - Number of IOs (bio) issued to the disk by the group. These + blkio.io_serviced + Number of IOs (bio) issued to the disk by the group. These are further divided by the type of operation - read or write, sync or async. First two fields specify the major and minor number of the device, third field specifies the operation type and the fourth field specifies the number of IOs. -- blkio.io_service_time - - Total amount of time between request dispatch and request completion + blkio.io_service_time + Total amount of time between request dispatch and request completion for the IOs done by this cgroup. This is in nanoseconds to make it meaningful for flash devices too. For devices with queue depth of 1, this time represents the actual service time. When queue_depth > 1, @@ -170,8 +174,8 @@ Proportional weight policy files specifies the operation type and the fourth field specifies the io_service_time in ns. -- blkio.io_wait_time - - Total amount of time the IOs for this cgroup spent waiting in the + blkio.io_wait_time + Total amount of time the IOs for this cgroup spent waiting in the scheduler queues for service. This can be greater than the total time elapsed since it is cumulative io_wait_time for all IOs. It is not a measure of total time the cgroup spent waiting but rather a measure of @@ -185,24 +189,24 @@ Proportional weight policy files minor number of the device, third field specifies the operation type and the fourth field specifies the io_wait_time in ns. -- blkio.io_merged - - Total number of bios/requests merged into requests belonging to this + blkio.io_merged + Total number of bios/requests merged into requests belonging to this cgroup. This is further divided by the type of operation - read or write, sync or async. -- blkio.io_queued - - Total number of requests queued up at any given instant for this + blkio.io_queued + Total number of requests queued up at any given instant for this cgroup. This is further divided by the type of operation - read or write, sync or async. -- blkio.avg_queue_size - - Debugging aid only enabled if CONFIG_BFQ_CGROUP_DEBUG=y. + blkio.avg_queue_size + Debugging aid only enabled if CONFIG_BFQ_CGROUP_DEBUG=y. The average queue size for this cgroup over the entire time of this cgroup's existence. Queue size samples are taken each time one of the queues of this cgroup gets a timeslice. -- blkio.group_wait_time - - Debugging aid only enabled if CONFIG_BFQ_CGROUP_DEBUG=y. + blkio.group_wait_time + Debugging aid only enabled if CONFIG_BFQ_CGROUP_DEBUG=y. This is the amount of time the cgroup had to wait since it became busy (i.e., went from 0 to 1 request queued) to get a timeslice for one of its queues. This is different from the io_wait_time which is the @@ -212,8 +216,8 @@ Proportional weight policy files will only report the group_wait_time accumulated till the last time it got a timeslice and will not include the current delta. -- blkio.empty_time - - Debugging aid only enabled if CONFIG_BFQ_CGROUP_DEBUG=y. + blkio.empty_time + Debugging aid only enabled if CONFIG_BFQ_CGROUP_DEBUG=y. This is the amount of time a cgroup spends without any pending requests when not being served, i.e., it does not include any time spent idling for one of the queues of the cgroup. This is in @@ -221,8 +225,8 @@ Proportional weight policy files the stat will only report the empty_time accumulated till the last time it had a pending request and will not include the current delta. -- blkio.idle_time - - Debugging aid only enabled if CONFIG_BFQ_CGROUP_DEBUG=y. + blkio.idle_time + Debugging aid only enabled if CONFIG_BFQ_CGROUP_DEBUG=y. This is the amount of time spent by the IO scheduler idling for a given cgroup in anticipation of a better request than the existing ones from other queues/cgroups. This is in nanoseconds. If this is read @@ -230,60 +234,60 @@ Proportional weight policy files idle_time accumulated till the last idle period and will not include the current delta. -- blkio.dequeue - - Debugging aid only enabled if CONFIG_BFQ_CGROUP_DEBUG=y. This + blkio.dequeue + Debugging aid only enabled if CONFIG_BFQ_CGROUP_DEBUG=y. This gives the statistics about how many a times a group was dequeued from service tree of the device. First two fields specify the major and minor number of the device and third field specifies the number of times a group was dequeued from a particular device. -- blkio.*_recursive - - Recursive version of various stats. These files show the + blkio.*_recursive + Recursive version of various stats. These files show the same information as their non-recursive counterparts but include stats from all the descendant cgroups. Throttling/Upper limit policy files ----------------------------------- -- blkio.throttle.read_bps_device - - Specifies upper limit on READ rate from the device. IO rate is + blkio.throttle.read_bps_device + Specifies upper limit on READ rate from the device. IO rate is specified in bytes per second. Rules are per device. Following is the format:: echo ": " > /cgrp/blkio.throttle.read_bps_device -- blkio.throttle.write_bps_device - - Specifies upper limit on WRITE rate to the device. IO rate is + blkio.throttle.write_bps_device + Specifies upper limit on WRITE rate to the device. IO rate is specified in bytes per second. Rules are per device. Following is the format:: echo ": " > /cgrp/blkio.throttle.write_bps_device -- blkio.throttle.read_iops_device - - Specifies upper limit on READ rate from the device. IO rate is + blkio.throttle.read_iops_device + Specifies upper limit on READ rate from the device. IO rate is specified in IO per second. Rules are per device. Following is the format:: echo ": " > /cgrp/blkio.throttle.read_iops_device -- blkio.throttle.write_iops_device - - Specifies upper limit on WRITE rate to the device. IO rate is + blkio.throttle.write_iops_device + Specifies upper limit on WRITE rate to the device. IO rate is specified in io per second. Rules are per device. Following is the format:: echo ": " > /cgrp/blkio.throttle.write_iops_device -Note: If both BW and IOPS rules are specified for a device, then IO is - subjected to both the constraints. + Note: If both BW and IOPS rules are specified for a device, then IO is + subjected to both the constraints. -- blkio.throttle.io_serviced - - Number of IOs (bio) issued to the disk by the group. These + blkio.throttle.io_serviced + Number of IOs (bio) issued to the disk by the group. These are further divided by the type of operation - read or write, sync or async. First two fields specify the major and minor number of the device, third field specifies the operation type and the fourth field specifies the number of IOs. -- blkio.throttle.io_service_bytes - - Number of bytes transferred to/from the disk by the group. These + blkio.throttle.io_service_bytes + Number of bytes transferred to/from the disk by the group. These are further divided by the type of operation - read or write, sync or async. First two fields specify the major and minor number of the device, third field specifies the operation type and the fourth field @@ -291,6 +295,6 @@ Note: If both BW and IOPS rules are specified for a device, then IO is Common files among various policies ----------------------------------- -- blkio.reset_stats - - Writing an int to this file will result in resetting all the stats + blkio.reset_stats + Writing an int to this file will result in resetting all the stats for that cgroup. -- cgit v1.2.3 From 828615950b5876e75587fdd5e9d1185be9cabba7 Mon Sep 17 00:00:00 2001 From: Kir Kolyshkin Date: Thu, 10 Jun 2021 20:07:37 -0700 Subject: docs/cgroup-v1/blkio: update for 5.x kernels Commit bf382fb0bcef4 ("block: remove legacy IO schedulers", Oct 12 2018) removes the CFQ scheduler, together with blkio.weight and blkio.weight_device described in cgroup v1 documentation. Users are supposed to use the BFQ scheduler, which cgroup file for setting weight is blkio.bfq.weight, but there is no way to set per-device weight. Later, commit 795fe54c2a8 per-device weights for BFQ, meaning that blkio.bfq.weight and blkio.bfq.weight_device can be used in a way similar to the old CFQ cgroup interface. Yet, the cgroup v1 docs were never updated. Fix this: - use the new file names; - fix the range for weight (used to be 10..1000, now 1..1000); - link to BFQ scheduler docs. Acked-by: Tejun Heo Signed-off-by: Kir Kolyshkin Signed-off-by: Jens Axboe --- .../admin-guide/cgroup-v1/blkio-controller.rst | 31 +++++++++++----------- 1 file changed, 16 insertions(+), 15 deletions(-) (limited to 'Documentation') diff --git a/Documentation/admin-guide/cgroup-v1/blkio-controller.rst b/Documentation/admin-guide/cgroup-v1/blkio-controller.rst index 8101dcba381d..16253eda192e 100644 --- a/Documentation/admin-guide/cgroup-v1/blkio-controller.rst +++ b/Documentation/admin-guide/cgroup-v1/blkio-controller.rst @@ -97,40 +97,41 @@ Details of cgroup files Proportional weight policy files -------------------------------- - blkio.weight + blkio.bfq.weight Specifies per cgroup weight. This is default weight of the group - on all the devices until and unless overridden by per device rule. - (See blkio.weight_device). - Currently allowed range of weights is from 10 to 1000. + on all the devices until and unless overridden by per device rule + (see `blkio.bfq.weight_device` below). - blkio.weight_device - One can specify per cgroup per device rules using this interface. - These rules override the default value of group weight as specified - by blkio.weight. + Currently allowed range of weights is from 1 to 1000. For more details, + see Documentation/block/bfq-iosched.rst. + + blkio.bfq.weight_device + Specifes per cgroup per device weights, overriding the default group + weight. For more details, see Documentation/block/bfq-iosched.rst. Following is the format:: - # echo dev_maj:dev_minor weight > blkio.weight_device + # echo dev_maj:dev_minor weight > blkio.bfq.weight_device Configure weight=300 on /dev/sdb (8:16) in this cgroup:: - # echo 8:16 300 > blkio.weight_device - # cat blkio.weight_device + # echo 8:16 300 > blkio.bfq.weight_device + # cat blkio.bfq.weight_device dev weight 8:16 300 Configure weight=500 on /dev/sda (8:0) in this cgroup:: - # echo 8:0 500 > blkio.weight_device - # cat blkio.weight_device + # echo 8:0 500 > blkio.bfq.weight_device + # cat blkio.bfq.weight_device dev weight 8:0 500 8:16 300 Remove specific weight for /dev/sda in this cgroup:: - # echo 8:0 0 > blkio.weight_device - # cat blkio.weight_device + # echo 8:0 0 > blkio.bfq.weight_device + # cat blkio.bfq.weight_device dev weight 8:16 300 -- cgit v1.2.3 From 797920a8498e420532ca6a63f9ac30fea477b3ff Mon Sep 17 00:00:00 2001 From: Bartosz Dudziak Date: Sat, 12 Jun 2021 22:53:34 +0200 Subject: dt-bindings: arm: msm: Add SAW2 for MSM8226 Add the dt-binding compatible in the SPM AVS Wrapper 2 (SAW2) for the MSM8226 SoC platform. Acked-by: Rob Herring Signed-off-by: Bartosz Dudziak Signed-off-by: Daniel Lezcano Link: https://lore.kernel.org/r/20210612205335.9730-2-bartosz.dudziak@snejp.pl --- Documentation/devicetree/bindings/arm/msm/qcom,saw2.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/msm/qcom,saw2.txt b/Documentation/devicetree/bindings/arm/msm/qcom,saw2.txt index ae4afc6dcfe0..94d50a949be1 100644 --- a/Documentation/devicetree/bindings/arm/msm/qcom,saw2.txt +++ b/Documentation/devicetree/bindings/arm/msm/qcom,saw2.txt @@ -25,6 +25,7 @@ PROPERTIES "qcom,saw2" A more specific value could be one of: "qcom,apq8064-saw2-v1.1-cpu" + "qcom,msm8226-saw2-v2.1-cpu" "qcom,msm8974-saw2-v2.1-cpu" "qcom,apq8084-saw2-v2.1-cpu" -- cgit v1.2.3 From 8676e8e71c04dd3d651bb5db7d04456413d56406 Mon Sep 17 00:00:00 2001 From: Sudeep Holla Date: Mon, 7 Jun 2021 19:42:57 +0100 Subject: dt-bindings: interrupt-controller: Fix compatible used in ti,pruss-intc As per soc/ti/ti,pruss.yaml schema, only ti,am4376-pruss0 and ti,am4376-pruss1 are valid compatibles. Replace ti,am4376-pruss with ti,am4376-pruss1 based on example in soc/ti/ti,pruss.yaml This fixes the below warning with 'make DT_CHECKER_FLAGS=-m dt_binding_check': interrupt-controller/ti,pruss-intc.example.dt.yaml:0:0: /example-1/pruss@0: failed to match any schema with compatible: ['ti,am4376-pruss'] Cc: Rob Herring Cc: Suman Anna Signed-off-by: Sudeep Holla Acked-by: Suman Anna Link: https://lore.kernel.org/r/20210607184257.2010276-1-sudeep.holla@arm.com Signed-off-by: Rob Herring --- .../devicetree/bindings/interrupt-controller/ti,pruss-intc.yaml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/interrupt-controller/ti,pruss-intc.yaml b/Documentation/devicetree/bindings/interrupt-controller/ti,pruss-intc.yaml index 9731dd4421a1..051beb45d998 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/ti,pruss-intc.yaml +++ b/Documentation/devicetree/bindings/interrupt-controller/ti,pruss-intc.yaml @@ -134,7 +134,7 @@ examples: /* AM4376 PRU-ICSS */ #include pruss@0 { - compatible = "ti,am4376-pruss"; + compatible = "ti,am4376-pruss1"; reg = <0x0 0x40000>; #address-cells = <1>; #size-cells = <1>; -- cgit v1.2.3 From ca622ed60a46a19a0bd45407439760694dcdaf17 Mon Sep 17 00:00:00 2001 From: Sudeep Holla Date: Tue, 8 Jun 2021 22:58:34 +0100 Subject: dt-bindings: pwm: Use examples with documented/matching schema 'nvidia,tegra20-pwm' is not yet documented in the YAML schema. Use 'allwinner,sun7i-a20-pwm' instead to get rid of the following warning with 'make DT_CHECKER_FLAGS=-m dt_binding_check': pwm/pwm.example.dt.yaml:0:0: /example-0/pwm@7000a000: failed to match any schema with compatible: ['nvidia,tegra20-pwm'] Signed-off-by: Sudeep Holla Link: https://lore.kernel.org/r/20210608215834.2236920-1-sudeep.holla@arm.com Signed-off-by: Rob Herring --- Documentation/devicetree/bindings/pwm/pwm.yaml | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pwm/pwm.yaml b/Documentation/devicetree/bindings/pwm/pwm.yaml index 7d1f687cee9c..2effe6c0de6b 100644 --- a/Documentation/devicetree/bindings/pwm/pwm.yaml +++ b/Documentation/devicetree/bindings/pwm/pwm.yaml @@ -24,8 +24,9 @@ additionalProperties: true examples: - | - pwm: pwm@7000a000 { - compatible = "nvidia,tegra20-pwm"; - reg = <0x7000a000 0x100>; - #pwm-cells = <2>; + pwm: pwm@1c20e00 { + compatible = "allwinner,sun7i-a20-pwm"; + reg = <0x01c20e00 0xc>; + clocks = <&osc24M>; + #pwm-cells = <3>; }; -- cgit v1.2.3 From 90b8cadfe447d7299c7061b07d50da5a6160bcc5 Mon Sep 17 00:00:00 2001 From: Geert Uytterhoeven Date: Fri, 11 Jun 2021 15:01:45 +0200 Subject: dt-bindings: rtc: nxp,pcf8563: Absorb pcf85263/pcf85363 bindings The NXP PCF85263/PCF85363 Real Time Clock is very similar to the NXP PCF8563. Signed-off-by: Geert Uytterhoeven Link: https://lore.kernel.org/r/e4f48d97f0e16d78a796f02b77ea3a0018904185.1623416431.git.geert+renesas@glider.be Signed-off-by: Rob Herring --- Documentation/devicetree/bindings/rtc/nxp,pcf8563.yaml | 4 +++- Documentation/devicetree/bindings/rtc/pcf85363.txt | 17 ----------------- 2 files changed, 3 insertions(+), 18 deletions(-) delete mode 100644 Documentation/devicetree/bindings/rtc/pcf85363.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/rtc/nxp,pcf8563.yaml b/Documentation/devicetree/bindings/rtc/nxp,pcf8563.yaml index a542b6c7ff44..a98b72752349 100644 --- a/Documentation/devicetree/bindings/rtc/nxp,pcf8563.yaml +++ b/Documentation/devicetree/bindings/rtc/nxp,pcf8563.yaml @@ -17,8 +17,10 @@ properties: enum: - epson,rtc8564 - microcrystal,rv8564 - - nxp,pcf8563 - nxp,pca8565 + - nxp,pcf8563 + - nxp,pcf85263 + - nxp,pcf85363 reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/rtc/pcf85363.txt b/Documentation/devicetree/bindings/rtc/pcf85363.txt deleted file mode 100644 index 94adc1cf93d9..000000000000 --- a/Documentation/devicetree/bindings/rtc/pcf85363.txt +++ /dev/null @@ -1,17 +0,0 @@ -NXP PCF85263/PCF85363 Real Time Clock -============================ - -Required properties: -- compatible: Should contain "nxp,pcf85263" or "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 271ca53cb0c8b3a45c73e1140fc3336c2da42315 Mon Sep 17 00:00:00 2001 From: Dmitry Osipenko Date: Tue, 1 Jun 2021 05:23:18 +0300 Subject: dt-bindings: devfreq: tegra30-actmon: Convert to schema Convert NVIDIA Tegra ACTMON binding to schema. Reviewed-by: Rob Herring Acked-by: Chanwoo Choi Acked-by: Thierry Reding Signed-off-by: Dmitry Osipenko Signed-off-by: Chanwoo Choi --- .../bindings/arm/tegra/nvidia,tegra30-actmon.txt | 57 ---------- .../bindings/devfreq/nvidia,tegra30-actmon.yaml | 121 +++++++++++++++++++++ 2 files changed, 121 insertions(+), 57 deletions(-) delete mode 100644 Documentation/devicetree/bindings/arm/tegra/nvidia,tegra30-actmon.txt create mode 100644 Documentation/devicetree/bindings/devfreq/nvidia,tegra30-actmon.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra30-actmon.txt b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra30-actmon.txt deleted file mode 100644 index 897eedfa2bc8..000000000000 --- a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra30-actmon.txt +++ /dev/null @@ -1,57 +0,0 @@ -NVIDIA Tegra Activity Monitor - -The activity monitor block collects statistics about the behaviour of other -components in the system. This information can be used to derive the rate at -which the external memory needs to be clocked in order to serve all requests -from the monitored clients. - -Required properties: -- compatible: should be "nvidia,tegra-actmon" -- reg: offset and length of the register set for the device -- interrupts: standard interrupt property -- clocks: Must contain a phandle and clock specifier pair for each entry in -clock-names. See ../../clock/clock-bindings.txt for details. -- clock-names: Must include the following entries: - - actmon - - emc -- resets: Must contain an entry for each entry in reset-names. See -../../reset/reset.txt for details. -- reset-names: Must include the following entries: - - actmon -- operating-points-v2: See ../bindings/opp/opp.txt for details. -- interconnects: Should contain entries for memory clients sitting on - MC->EMC memory interconnect path. -- interconnect-names: Should include name of the interconnect path for each - interconnect entry. Consult TRM documentation for - information about available memory clients, see MEMORY - CONTROLLER section. - -For each opp entry in 'operating-points-v2' table: -- opp-supported-hw: bitfield indicating SoC speedo ID mask -- opp-peak-kBps: peak bandwidth of the memory channel - -Example: - dfs_opp_table: opp-table { - compatible = "operating-points-v2"; - - opp@12750000 { - opp-hz = /bits/ 64 <12750000>; - opp-supported-hw = <0x000F>; - opp-peak-kBps = <51000>; - }; - ... - }; - - actmon@6000c800 { - compatible = "nvidia,tegra124-actmon"; - reg = <0x0 0x6000c800 0x0 0x400>; - interrupts = ; - clocks = <&tegra_car TEGRA124_CLK_ACTMON>, - <&tegra_car TEGRA124_CLK_EMC>; - clock-names = "actmon", "emc"; - resets = <&tegra_car 119>; - reset-names = "actmon"; - operating-points-v2 = <&dfs_opp_table>; - interconnects = <&mc TEGRA124_MC_MPCORER &emc>; - interconnect-names = "cpu"; - }; diff --git a/Documentation/devicetree/bindings/devfreq/nvidia,tegra30-actmon.yaml b/Documentation/devicetree/bindings/devfreq/nvidia,tegra30-actmon.yaml new file mode 100644 index 000000000000..ba938eed28ee --- /dev/null +++ b/Documentation/devicetree/bindings/devfreq/nvidia,tegra30-actmon.yaml @@ -0,0 +1,121 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/devfreq/nvidia,tegra30-actmon.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NVIDIA Tegra30 Activity Monitor + +maintainers: + - Dmitry Osipenko + - Jon Hunter + - Thierry Reding + +description: | + The activity monitor block collects statistics about the behaviour of other + components in the system. This information can be used to derive the rate at + which the external memory needs to be clocked in order to serve all requests + from the monitored clients. + +properties: + compatible: + enum: + - nvidia,tegra30-actmon + - nvidia,tegra114-actmon + - nvidia,tegra124-actmon + - nvidia,tegra210-actmon + + reg: + maxItems: 1 + + clocks: + maxItems: 2 + + clock-names: + items: + - const: actmon + - const: emc + + resets: + maxItems: 1 + + reset-names: + items: + - const: actmon + + interrupts: + maxItems: 1 + + interconnects: + minItems: 1 + maxItems: 12 + + interconnect-names: + minItems: 1 + maxItems: 12 + description: + Should include name of the interconnect path for each interconnect + entry. Consult TRM documentation for information about available + memory clients, see MEMORY CONTROLLER and ACTIVITY MONITOR sections. + + operating-points-v2: + description: + Should contain freqs and voltages and opp-supported-hw property, which + is a bitfield indicating SoC speedo ID mask. + +required: + - compatible + - reg + - clocks + - clock-names + - resets + - reset-names + - interrupts + - interconnects + - interconnect-names + - operating-points-v2 + +additionalProperties: false + +examples: + - | + #include + + mc: memory-controller@7000f000 { + compatible = "nvidia,tegra30-mc"; + reg = <0x7000f000 0x400>; + clocks = <&clk 32>; + clock-names = "mc"; + + interrupts = <0 77 4>; + + #iommu-cells = <1>; + #reset-cells = <1>; + #interconnect-cells = <1>; + }; + + emc: external-memory-controller@7000f400 { + compatible = "nvidia,tegra30-emc"; + reg = <0x7000f400 0x400>; + interrupts = <0 78 4>; + clocks = <&clk 57>; + + nvidia,memory-controller = <&mc>; + operating-points-v2 = <&dvfs_opp_table>; + power-domains = <&domain>; + + #interconnect-cells = <0>; + }; + + actmon@6000c800 { + compatible = "nvidia,tegra30-actmon"; + reg = <0x6000c800 0x400>; + interrupts = <0 45 4>; + clocks = <&clk 119>, <&clk 57>; + clock-names = "actmon", "emc"; + resets = <&rst 119>; + reset-names = "actmon"; + operating-points-v2 = <&dvfs_opp_table>; + interconnects = <&mc TEGRA30_MC_MPCORER &emc>; + interconnect-names = "cpu-read"; + }; -- cgit v1.2.3 From 6b61f55ecbe693d9d0d7ae14ebce01dabe10ecf1 Mon Sep 17 00:00:00 2001 From: Dmitry Osipenko Date: Tue, 1 Jun 2021 05:23:19 +0300 Subject: dt-bindings: devfreq: tegra30-actmon: Add cooling-cells The ACTMON watches activity of memory clients. Decisions about a minimum required frequency are made based on the info from ACTMON. We can use ACTMON as a thermal cooling device by limiting the required frequency. Document new cooling-cells property of NVIDIA Tegra ACTMON hardware unit. Reviewed-by: Rob Herring Acked-by: Chanwoo Choi Acked-by: Thierry Reding Signed-off-by: Dmitry Osipenko Signed-off-by: Chanwoo Choi --- Documentation/devicetree/bindings/devfreq/nvidia,tegra30-actmon.yaml | 5 +++++ 1 file changed, 5 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/devfreq/nvidia,tegra30-actmon.yaml b/Documentation/devicetree/bindings/devfreq/nvidia,tegra30-actmon.yaml index ba938eed28ee..e3379d106728 100644 --- a/Documentation/devicetree/bindings/devfreq/nvidia,tegra30-actmon.yaml +++ b/Documentation/devicetree/bindings/devfreq/nvidia,tegra30-actmon.yaml @@ -63,6 +63,9 @@ properties: Should contain freqs and voltages and opp-supported-hw property, which is a bitfield indicating SoC speedo ID mask. + "#cooling-cells": + const: 2 + required: - compatible - reg @@ -74,6 +77,7 @@ required: - interconnects - interconnect-names - operating-points-v2 + - "#cooling-cells" additionalProperties: false @@ -118,4 +122,5 @@ examples: operating-points-v2 = <&dvfs_opp_table>; interconnects = <&mc TEGRA30_MC_MPCORER &emc>; interconnect-names = "cpu-read"; + #cooling-cells = <2>; }; -- cgit v1.2.3 From 5cd57605771216755bd6f98748d4f11d1e65b780 Mon Sep 17 00:00:00 2001 From: Irui Wang Date: Sat, 5 Jun 2021 04:29:14 +0200 Subject: media: dt-bindings: media: mtk-vcodec: Add dma-ranges property The mt8192 iommu support 0~16GB iova. We separate it to four banks: 0~4G; 4G~8G; 8G~12G; 12G~16G. The "dma-ranges" could be used to adjust the bank we locate. If we don't set this property. The default range always is 0~4G. This is optional and only needed in mt8192, the dma ranges should not cross 4G/8G/12G. Here we don't have actual bus/parent concept here. And the iova requirement is for our HW. Thus put the property in our node. Acked-by: Rob Herring Signed-off-by: Irui Wang Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab --- Documentation/devicetree/bindings/media/mediatek-vcodec.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/media/mediatek-vcodec.txt b/Documentation/devicetree/bindings/media/mediatek-vcodec.txt index 06db6837cefd..5bb9e6e191b7 100644 --- a/Documentation/devicetree/bindings/media/mediatek-vcodec.txt +++ b/Documentation/devicetree/bindings/media/mediatek-vcodec.txt @@ -22,6 +22,7 @@ Required properties: - iommus : should point to the respective IOMMU block with master port as argument, see Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml for details. +- dma-ranges : describes the dma address range space that the codec hw access. One of the two following nodes: - mediatek,vpu : the node of the video processor unit, if using VPU. - mediatek,scp : the node of the SCP unit, if using SCP. -- cgit v1.2.3 From aa950d8619694fb1a7d0e68aa556976e2f34476d Mon Sep 17 00:00:00 2001 From: Irui Wang Date: Sat, 5 Jun 2021 04:29:16 +0200 Subject: media: dt-bindings: media: mtk-vcodec: Add binding for MT8192 VENC Updates binding document for mt8192 encoder driver. Acked-by: Rob Herring Signed-off-by: Irui Wang Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab --- Documentation/devicetree/bindings/media/mediatek-vcodec.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/media/mediatek-vcodec.txt b/Documentation/devicetree/bindings/media/mediatek-vcodec.txt index 5bb9e6e191b7..ad1321e5a22d 100644 --- a/Documentation/devicetree/bindings/media/mediatek-vcodec.txt +++ b/Documentation/devicetree/bindings/media/mediatek-vcodec.txt @@ -9,6 +9,7 @@ Required properties: "mediatek,mt8173-vcodec-enc" for mt8173 avc encoder. "mediatek,mt8183-vcodec-enc" for MT8183 encoder. "mediatek,mt8173-vcodec-dec" for MT8173 decoder. + "mediatek,mt8192-vcodec-enc" for MT8192 encoder. - reg : Physical base address of the video codec registers and length of memory mapped region. - interrupts : interrupt number to the cpu. -- cgit v1.2.3 From b32178e77d257c148b8ad8c31db36bb0c2d49bab Mon Sep 17 00:00:00 2001 From: Alex Bee Date: Mon, 14 Jun 2021 23:32:10 +0200 Subject: media: dt-bindings: media: rockchip-vpu: add new compatibles Add compatibles for RK3036, RK3066, RK3188 and RK3228. Also reflect the changes to the additional clocks for RK3066/RK3188. Signed-off-by: Alex Bee Reviewed-by: Rob Herring Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab --- .../devicetree/bindings/media/rockchip-vpu.yaml | 33 ++++++++++++++++------ 1 file changed, 25 insertions(+), 8 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/media/rockchip-vpu.yaml b/Documentation/devicetree/bindings/media/rockchip-vpu.yaml index c81dbc3e8960..b88172a59de7 100644 --- a/Documentation/devicetree/bindings/media/rockchip-vpu.yaml +++ b/Documentation/devicetree/bindings/media/rockchip-vpu.yaml @@ -15,10 +15,19 @@ description: properties: compatible: - enum: - - rockchip,rk3288-vpu - - rockchip,rk3328-vpu - - rockchip,rk3399-vpu + oneOf: + - enum: + - rockchip,rk3036-vpu + - rockchip,rk3066-vpu + - rockchip,rk3288-vpu + - rockchip,rk3328-vpu + - rockchip,rk3399-vpu + - items: + - const: rockchip,rk3188-vpu + - const: rockchip,rk3066-vpu + - items: + - const: rockchip,rk3228-vpu + - const: rockchip,rk3399-vpu reg: maxItems: 1 @@ -35,12 +44,20 @@ properties: - const: vdpu clocks: - maxItems: 2 + oneOf: + - maxItems: 2 + - maxItems: 4 clock-names: - items: - - const: aclk - - const: hclk + oneOf: + - items: + - const: aclk + - const: hclk + - items: + - const: aclk_vdpu + - const: hclk_vdpu + - const: aclk_vepu + - const: hclk_vepu power-domains: maxItems: 1 -- cgit v1.2.3 From 502cf736419aba4cfa0a6737cf66d286c699f144 Mon Sep 17 00:00:00 2001 From: Alex Bee Date: Mon, 14 Jun 2021 23:32:11 +0200 Subject: media: dt-bindings: media: rockchip-vdec: add RK3228 compatible Document the RK3228 compatible for rockchip-vdec. Also add the optional assigned-clocks and assigned-clock-rates properties. Signed-off-by: Alex Bee Reviewed-by: Rob Herring Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab --- Documentation/devicetree/bindings/media/rockchip,vdec.yaml | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/media/rockchip,vdec.yaml b/Documentation/devicetree/bindings/media/rockchip,vdec.yaml index 8d35c327018b..089f11d21b25 100644 --- a/Documentation/devicetree/bindings/media/rockchip,vdec.yaml +++ b/Documentation/devicetree/bindings/media/rockchip,vdec.yaml @@ -15,7 +15,11 @@ description: |- properties: compatible: - const: rockchip,rk3399-vdec + oneOf: + - const: rockchip,rk3399-vdec + - items: + - const: rockchip,rk3228-vdec + - const: rockchip,rk3399-vdec reg: maxItems: 1 @@ -37,6 +41,10 @@ properties: - const: cabac - const: core + assigned-clocks: true + + assigned-clock-rates: true + power-domains: maxItems: 1 -- cgit v1.2.3 From 6e954d2e649a373cdebb4d2b0de5197ca3f6b87e Mon Sep 17 00:00:00 2001 From: Erik Rosen Date: Fri, 23 Apr 2021 17:33:29 +0200 Subject: hwmon: (pmbus/zl6100) Update documentation for zl6100 driver Update documentation for zl6100 driver and fix dead links to technical specifications Signed-off-by: Erik Rosen Link: https://lore.kernel.org/r/20210423153329.33457-3-erik.rosen@metormote.com Signed-off-by: Guenter Roeck --- Documentation/hwmon/zl6100.rst | 132 +++++++++++++++++++++++++++-------------- 1 file changed, 89 insertions(+), 43 deletions(-) (limited to 'Documentation') diff --git a/Documentation/hwmon/zl6100.rst b/Documentation/hwmon/zl6100.rst index 968aff10ce0a..d42ed9d3ac69 100644 --- a/Documentation/hwmon/zl6100.rst +++ b/Documentation/hwmon/zl6100.rst @@ -3,87 +3,103 @@ Kernel driver zl6100 Supported chips: - * Intersil / Zilker Labs ZL2004 + * Renesas / Intersil / Zilker Labs ZL2004 Prefix: 'zl2004' Addresses scanned: - - Datasheet: http://www.intersil.com/data/fn/fn6847.pdf + Datasheet: https://www.renesas.com/us/en/document/dst/zl2004-datasheet.pdf - * Intersil / Zilker Labs ZL2005 + * Renesas / Intersil / Zilker Labs ZL2005 Prefix: 'zl2005' Addresses scanned: - - Datasheet: http://www.intersil.com/data/fn/fn6848.pdf + Datasheet: https://www.renesas.com/us/en/document/dst/zl2005-datasheet.pdf - * Intersil / Zilker Labs ZL2006 + * Renesas / Intersil / Zilker Labs ZL2006 Prefix: 'zl2006' Addresses scanned: - - Datasheet: http://www.intersil.com/data/fn/fn6850.pdf + Datasheet: https://www.renesas.com/us/en/document/dst/zl2006-datasheet.pdf - * Intersil / Zilker Labs ZL2008 + * Renesas / Intersil / Zilker Labs ZL2008 Prefix: 'zl2008' Addresses scanned: - - Datasheet: http://www.intersil.com/data/fn/fn6859.pdf + Datasheet: https://www.renesas.com/us/en/document/dst/zl2008-datasheet.pdf - * Intersil / Zilker Labs ZL2105 + * Renesas / Intersil / Zilker Labs ZL2105 Prefix: 'zl2105' Addresses scanned: - - Datasheet: http://www.intersil.com/data/fn/fn6851.pdf + Datasheet: https://www.renesas.com/us/en/document/dst/zl2105-datasheet.pdf - * Intersil / Zilker Labs ZL2106 + * Renesas / Intersil / Zilker Labs ZL2106 Prefix: 'zl2106' Addresses scanned: - - Datasheet: http://www.intersil.com/data/fn/fn6852.pdf + Datasheet: https://www.renesas.com/us/en/document/dst/zl2106-datasheet.pdf - * Intersil / Zilker Labs ZL6100 + * Renesas / Intersil / Zilker Labs ZL6100 Prefix: 'zl6100' Addresses scanned: - - Datasheet: http://www.intersil.com/data/fn/fn6876.pdf + Datasheet: https://www.renesas.com/us/en/document/dst/zl6100-datasheet.pdf - * Intersil / Zilker Labs ZL6105 + * Renesas / Intersil / Zilker Labs ZL6105 Prefix: 'zl6105' Addresses scanned: - - Datasheet: http://www.intersil.com/data/fn/fn6906.pdf + Datasheet: https://www.renesas.com/us/en/document/dst/zl6105-datasheet.pdf - * Intersil / Zilker Labs ZL9101M + * Renesas / Intersil / Zilker Labs ZL8802 + + Prefix: 'zl8802' + + Addresses scanned: - + + Datasheet: https://www.renesas.com/us/en/document/dst/zl8802-datasheet + + * Renesas / Intersil / Zilker Labs ZL9101M Prefix: 'zl9101' Addresses scanned: - - Datasheet: http://www.intersil.com/data/fn/fn7669.pdf + Datasheet: https://www.renesas.com/us/en/document/dst/zl9101m-datasheet - * Intersil / Zilker Labs ZL9117M + * Renesas / Intersil / Zilker Labs ZL9117M Prefix: 'zl9117' Addresses scanned: - - Datasheet: http://www.intersil.com/data/fn/fn7914.pdf + Datasheet: https://www.renesas.com/us/en/document/dst/zl9117m-datasheet + + * Renesas / Intersil / Zilker Labs ZLS1003, ZLS4009 + + Prefix: 'zls1003', zls4009 + + Addresses scanned: - + + Datasheet: Not published - * Ericsson BMR450, BMR451 + * Flex BMR450, BMR451 Prefix: 'bmr450', 'bmr451' @@ -91,17 +107,39 @@ Supported chips: Datasheet: -http://archive.ericsson.net/service/internet/picov/get?DocNo=28701-EN/LZT146401 +https://flexpowermodules.com/resources/fpm-techspec-bmr450-digital-pol-regulators-20a - * Ericsson BMR462, BMR463, BMR464 + * Flex BMR462, BMR463, BMR464 Prefixes: 'bmr462', 'bmr463', 'bmr464' Addresses scanned: - - Datasheet: + Datasheet: https://flexpowermodules.com/resources/fpm-techspec-bmr462 + + * Flex BMR465, BMR467 + + Prefixes: 'bmr465', 'bmr467' + + Addresses scanned: - + + Datasheet: https://flexpowermodules.com/resources/fpm-techspec-bmr465-digital-pol + + * Flex BMR466 + + Prefixes: 'bmr466' + + Addresses scanned: - + + Datasheet: https://flexpowermodules.com/resources/fpm-techspec-bmr466-8x12 - http://archive.ericsson.net/service/internet/picov/get?DocNo=28701-EN/LZT146256 + * Flex BMR469 + + Prefixes: 'bmr469' + + Addresses scanned: - + + Datasheet: https://flexpowermodules.com/resources/fpm-techspec-bmr4696001 Author: Guenter Roeck @@ -109,8 +147,8 @@ Author: Guenter Roeck Description ----------- -This driver supports hardware monitoring for Intersil / Zilker Labs ZL6100 and -compatible digital DC-DC controllers. +This driver supports hardware monitoring for Renesas / Intersil / Zilker Labs +ZL6100 and compatible digital DC-DC controllers. The driver is a client driver to the core PMBus driver. Please see Documentation/hwmon/pmbus.rst and Documentation.hwmon/pmbus-core for details @@ -147,12 +185,12 @@ Module parameters delay ----- -Intersil/Zilker Labs DC-DC controllers require a minimum interval between I2C -bus accesses. According to Intersil, the minimum interval is 2 ms, though 1 ms -appears to be sufficient and has not caused any problems in testing. The problem -is known to affect all currently supported chips. For manual override, the -driver provides a writeable module parameter, 'delay', which can be used to set -the interval to a value between 0 and 65,535 microseconds. +Renesas/Intersil/Zilker Labs DC-DC controllers require a minimum interval +between I2C bus accesses. According to Intersil, the minimum interval is 2 ms, +though 1 ms appears to be sufficient and has not caused any problems in testing. +The problem is known to affect all currently supported chips. For manual override, +the driver provides a writeable module parameter, 'delay', which can be used +to set the interval to a value between 0 and 65,535 microseconds. Sysfs entries @@ -182,24 +220,32 @@ in2_crit Critical maximum VMON/VDRV voltage. in2_lcrit_alarm VMON/VDRV voltage critical low alarm. in2_crit_alarm VMON/VDRV voltage critical high alarm. - vmon attributes are supported on ZL2004, ZL9101M, - and ZL9117M only. + vmon attributes are supported on ZL2004, ZL8802, + ZL9101M, ZL9117M and ZLS4009 only. -inX_label "vout1" +inX_label "vout[12]" inX_input Measured output voltage. inX_lcrit Critical minimum output Voltage. inX_crit Critical maximum output voltage. inX_lcrit_alarm Critical output voltage critical low alarm. inX_crit_alarm Critical output voltage critical high alarm. - X is 3 for ZL2004, ZL9101M, and ZL9117M, 2 otherwise. + X is 3 for ZL2004, ZL9101M, and ZL9117M, + 3, 4 for ZL8802 and 2 otherwise. + +curr1_label "iin" +curr1_input Measured input current. + + iin attributes are supported on ZL8802 only + +currY_label "iout[12]" +currY_input Measured output current. +currY_lcrit Critical minimum output current. +currY_crit Critical maximum output current. +currY_lcrit_alarm Output current critical low alarm. +currY_crit_alarm Output current critical high alarm. -curr1_label "iout1" -curr1_input Measured output current. -curr1_lcrit Critical minimum output current. -curr1_crit Critical maximum output current. -curr1_lcrit_alarm Output current critical low alarm. -curr1_crit_alarm Output current critical high alarm. + Y is 2, 3 for ZL8802, 1 otherwise temp[12]_input Measured temperature. temp[12]_min Minimum temperature. -- cgit v1.2.3 From ec081f9154766be98b7be6e4c4483b580c5b12e7 Mon Sep 17 00:00:00 2001 From: Robert Marko Date: Thu, 29 Apr 2021 14:11:49 +0200 Subject: hwmon: (lm75) Add TI TMP1075 support TI TMP1075 is a LM75 compatible sensor, so lets add support for it. Signed-off-by: Robert Marko Link: https://lore.kernel.org/r/20210429121150.106804-1-robert.marko@sartura.hr Signed-off-by: Guenter Roeck --- Documentation/hwmon/lm75.rst | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/hwmon/lm75.rst b/Documentation/hwmon/lm75.rst index 81257d5fc48f..8d0ab4ad5fb5 100644 --- a/Documentation/hwmon/lm75.rst +++ b/Documentation/hwmon/lm75.rst @@ -93,9 +93,9 @@ Supported chips: https://www.st.com/resource/en/datasheet/stlm75.pdf - * Texas Instruments TMP100, TMP101, TMP105, TMP112, TMP75, TMP75B, TMP75C, TMP175, TMP275 + * Texas Instruments TMP100, TMP101, TMP105, TMP112, TMP75, TMP75B, TMP75C, TMP175, TMP275, TMP1075 - Prefixes: 'tmp100', 'tmp101', 'tmp105', 'tmp112', 'tmp175', 'tmp75', 'tmp75b', 'tmp75c', 'tmp275' + Prefixes: 'tmp100', 'tmp101', 'tmp105', 'tmp112', 'tmp175', 'tmp75', 'tmp75b', 'tmp75c', 'tmp275', 'tmp1075' Addresses scanned: none @@ -119,6 +119,8 @@ Supported chips: https://www.ti.com/product/tmp275 + https://www.ti.com/product/TMP1075 + * NXP LM75B, PCT2075 Prefix: 'lm75b', 'pct2075' -- cgit v1.2.3 From 42c7fd53aeff8241d64cdcfaffe06bb955852112 Mon Sep 17 00:00:00 2001 From: Robert Marko Date: Thu, 29 Apr 2021 14:11:50 +0200 Subject: dt-bindings: hwmon: Add Texas Instruments TMP1075 Document the DT compatible for TI TMP1075 which is a LM75 compatible sensor. Signed-off-by: Robert Marko Link: https://lore.kernel.org/r/20210429121150.106804-2-robert.marko@sartura.hr Acked-by: Rob Herring Signed-off-by: Guenter Roeck --- Documentation/devicetree/bindings/hwmon/lm75.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/hwmon/lm75.yaml b/Documentation/devicetree/bindings/hwmon/lm75.yaml index 96eed5cc7841..72980d083c21 100644 --- a/Documentation/devicetree/bindings/hwmon/lm75.yaml +++ b/Documentation/devicetree/bindings/hwmon/lm75.yaml @@ -30,6 +30,7 @@ properties: - st,stds75 - st,stlm75 - microchip,tcn75 + - ti,tmp1075 - ti,tmp100 - ti,tmp101 - ti,tmp105 -- cgit v1.2.3 From f0635523c8b57aea6b1b75e99ea9c86ccc2a8b45 Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Sun, 16 May 2021 12:18:18 +0200 Subject: docs: hwmon: ir36021.rst: replace some characters MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The conversion tools used during DocBook/LaTeX/html/Markdown->ReST conversion and some cut-and-pasted text contain some characters that aren't easily reachable on standard keyboards and/or could cause troubles when parsed by the documentation build system. Replace the occurences of the following characters: - U+2010 ('‐'): HYPHEN as ASCII HYPHEN is preferred over U+2010 Signed-off-by: Mauro Carvalho Chehab Link: https://lore.kernel.org/r/ba8b5122ac9d4918fd966d0eb0a5ca9d89044b04.1621159997.git.mchehab+huawei@kernel.org Signed-off-by: Guenter Roeck --- Documentation/hwmon/ir36021.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/hwmon/ir36021.rst b/Documentation/hwmon/ir36021.rst index ca3436b04e20..1faa85c39f1b 100644 --- a/Documentation/hwmon/ir36021.rst +++ b/Documentation/hwmon/ir36021.rst @@ -19,7 +19,7 @@ Authors: Description ----------- -The IR36021 is a dual‐loop digital multi‐phase buck controller designed for +The IR36021 is a dual-loop digital multi-phase buck controller designed for point of load applications. Usage Notes -- cgit v1.2.3 From b3ea2fe7e2814d17426674eff3d440c4e9c3a107 Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Mon, 10 May 2021 12:26:17 +0200 Subject: docs: hwmon: avoid using UTF-8 chars MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit While UTF-8 characters can be used at the Linux documentation, the best is to use them only when ASCII doesn't offer a good replacement. So, replace the occurences of the following UTF-8 characters: - U+2010 ('‐'): HYPHEN - U+2013 ('–'): EN DASH - U+2019 ('’'): RIGHT SINGLE QUOTATION MARK Signed-off-by: Mauro Carvalho Chehab Link: https://lore.kernel.org/r/ccdd1bf45963a7748188a97c75f667b37bd43d2f.1620641727.git.mchehab+huawei@kernel.org Signed-off-by: Guenter Roeck --- Documentation/hwmon/ltc2992.rst | 2 +- Documentation/hwmon/pm6764tr.rst | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/hwmon/ltc2992.rst b/Documentation/hwmon/ltc2992.rst index 46aa1aa84a1a..a0bcd867a0f5 100644 --- a/Documentation/hwmon/ltc2992.rst +++ b/Documentation/hwmon/ltc2992.rst @@ -19,7 +19,7 @@ This driver supports hardware monitoring for Linear Technology LTC2992 power mon LTC2992 is a rail-to-rail system monitor that measures current, voltage, and power of two supplies. -Two ADCs simultaneously measure each supply’s current. A third ADC monitors +Two ADCs simultaneously measure each supply's current. A third ADC monitors the input voltages and four auxiliary external voltages. diff --git a/Documentation/hwmon/pm6764tr.rst b/Documentation/hwmon/pm6764tr.rst index a1fb8fea2326..294a8ffc8bd8 100644 --- a/Documentation/hwmon/pm6764tr.rst +++ b/Documentation/hwmon/pm6764tr.rst @@ -20,7 +20,7 @@ Description: ------------ This driver supports the STMicroelectronics PM6764TR chip. The PM6764TR is a high -performance digital controller designed to power Intel’s VR12.5 processors and memories. +performance digital controller designed to power Intel's VR12.5 processors and memories. The device utilizes digital technology to implement all control and power management functions to provide maximum flexibility and performance. The NVM is embedded to store -- cgit v1.2.3 From b976760dc4efd1de7965bf020195a22fce4f456c Mon Sep 17 00:00:00 2001 From: Erik Rosen Date: Fri, 7 May 2021 21:40:22 +0200 Subject: hwmon: (pmbus) Add documentation for new flags Add documentation for the new pmbus flags PMBUS_WRITE_PROTECTED, PMBUS_NO_CAPABILITY and PMBUS_READ_STATUS_AFTER_FAILED_CHECK Signed-off-by: Erik Rosen Link: https://lore.kernel.org/r/20210507194023.61138-3-erik.rosen@metormote.com [groeck: Added newline at end of file] Signed-off-by: Guenter Roeck --- Documentation/hwmon/pmbus-core.rst | 42 ++++++++++++++++++++++++++++++++++---- 1 file changed, 38 insertions(+), 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/hwmon/pmbus-core.rst b/Documentation/hwmon/pmbus-core.rst index 73e23ab42cc3..e7e0c9ef10be 100644 --- a/Documentation/hwmon/pmbus-core.rst +++ b/Documentation/hwmon/pmbus-core.rst @@ -289,12 +289,22 @@ PMBus driver platform data ========================== PMBus platform data is defined in include/linux/pmbus.h. Platform data -currently only provides a flag field with a single bit used:: +currently provides a flags field with four bits used:: - #define PMBUS_SKIP_STATUS_CHECK (1 << 0) + #define PMBUS_SKIP_STATUS_CHECK BIT(0) + + #define PMBUS_WRITE_PROTECTED BIT(1) + + #define PMBUS_NO_CAPABILITY BIT(2) + + #define PMBUS_READ_STATUS_AFTER_FAILED_CHECK BIT(3) struct pmbus_platform_data { u32 flags; /* Device specific flags */ + + /* regulator support */ + int num_regulators; + struct regulator_init_data *reg_init_data; }; @@ -302,8 +312,9 @@ Flags ----- PMBUS_SKIP_STATUS_CHECK - During register detection, skip checking the status register for - communication or command errors. + +During register detection, skip checking the status register for +communication or command errors. Some PMBus chips respond with valid data when trying to read an unsupported register. For such chips, checking the status register is mandatory when @@ -315,3 +326,26 @@ status register must be disabled. Some i2c controllers do not support single-byte commands (write commands with no data, i2c_smbus_write_byte()). With such controllers, clearing the status register is impossible, and the PMBUS_SKIP_STATUS_CHECK flag must be set. + +PMBUS_WRITE_PROTECTED + +Set if the chip is write protected and write protection is not determined +by the standard WRITE_PROTECT command. + +PMBUS_NO_CAPABILITY + +Some PMBus chips don't respond with valid data when reading the CAPABILITY +register. For such chips, this flag should be set so that the PMBus core +driver doesn't use CAPABILITY to determine it's behavior. + +PMBUS_READ_STATUS_AFTER_FAILED_CHECK + +Read the STATUS register after each failed register check. + +Some PMBus chips end up in an undefined state when trying to read an +unsupported register. For such chips, it is necessary to reset the +chip pmbus controller to a known state after a failed register check. +This can be done by reading a known register. By setting this flag the +driver will try to read the STATUS register after each failed +register check. This read may fail, but it will put the chip into a +known state. -- cgit v1.2.3 From ea541c185c358f870ccb0d5fce6f726c5146daae Mon Sep 17 00:00:00 2001 From: Erik Rosen Date: Fri, 7 May 2021 21:40:23 +0200 Subject: hwmon: (pmbus) Add support for additional Flex BMR converters to pmbus Add support for Flex BMR310, BMR456, BMR457, BMR458, BMR480, BMR490, BMR491 and BMR492 to the pmbus driver Signed-off-by: Erik Rosen Link: https://lore.kernel.org/r/20210507194023.61138-4-erik.rosen@metormote.com [groeck: Fixed minor whitespace error] Signed-off-by: Guenter Roeck --- Documentation/hwmon/pmbus.rst | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/hwmon/pmbus.rst b/Documentation/hwmon/pmbus.rst index c44f14115413..7ecfec6ca2db 100644 --- a/Documentation/hwmon/pmbus.rst +++ b/Documentation/hwmon/pmbus.rst @@ -3,15 +3,18 @@ Kernel driver pmbus Supported chips: - * Ericsson BMR453, BMR454 + * Flex BMR310, BMR453, BMR454, BMR456, BMR457, BMR458, BMR480, + BMR490, BMR491, BMR492 - Prefixes: 'bmr453', 'bmr454' + Prefixes: 'bmr310', 'bmr453', 'bmr454', 'bmr456', 'bmr457', 'bmr458', 'bmr480', + 'bmr490', 'bmr491', 'bmr492' Addresses scanned: - - Datasheet: + Datasheets: + + https://flexpowermodules.com/products - http://archive.ericsson.net/service/internet/picov/get?DocNo=28701-EN/LZT146395 * ON Semiconductor ADP4000, NCP4200, NCP4208 -- cgit v1.2.3 From e4db7719d037b820024a213f74703ae1abf5b00c Mon Sep 17 00:00:00 2001 From: Vadim Pasternak Date: Tue, 11 May 2021 08:56:18 +0300 Subject: hwmon: (pmbus) Add support for MPS Multi-phase mp2888 controller Add support for mp2888 device from Monolithic Power Systems, Inc. (MPS) vendor. This is a digital, multi-phase, pulse-width modulation controller. This device supports: - One power rail. - Programmable Multi-Phase up to 10 Phases. - PWM-VID Interface - One pages 0 for telemetry. - Programmable pins for PMBus Address. - Built-In EEPROM to Store Custom Configurations. - Can configured VOUT readout in direct or VID format and allows setting of different formats on rails 1 and 2. For VID the following protocols are available: VR13 mode with 5-mV DAC; VR13 mode with 10-mV DAC, IMVP9 mode with 5-mV DAC. Signed-off-by: Vadim Pasternak Reported-by: kernel test robot Link: https://lore.kernel.org/r/20210511055619.118104-3-vadimp@nvidia.com [groeck: Add MODULE_IMPORT_NS] Signed-off-by: Guenter Roeck --- Documentation/hwmon/mp2888.rst | 113 +++++++++++++++++++++++++++++++++++++++++ 1 file changed, 113 insertions(+) create mode 100644 Documentation/hwmon/mp2888.rst (limited to 'Documentation') diff --git a/Documentation/hwmon/mp2888.rst b/Documentation/hwmon/mp2888.rst new file mode 100644 index 000000000000..5e578fd7b147 --- /dev/null +++ b/Documentation/hwmon/mp2888.rst @@ -0,0 +1,113 @@ +.. SPDX-License-Identifier: GPL-2.0 + +Kernel driver mp2888 +==================== + +Supported chips: + + * MPS MP12254 + + Prefix: 'mp2888' + +Author: + + Vadim Pasternak + +Description +----------- + +This driver implements support for Monolithic Power Systems, Inc. (MPS) +vendor dual-loop, digital, multi-phase controller MP2888. + +This device: supports: + +- One power rail. +- Programmable Multi-Phase up to 10 Phases. +- PWM-VID Interface +- One pages 0 for telemetry. +- Programmable pins for PMBus Address. +- Built-In EEPROM to Store Custom Configurations. + +Device complaint with: + +- PMBus rev 1.3 interface. + +Device supports direct format for reading output current, output voltage, +input and output power and temperature. +Device supports linear format for reading input voltage and input power. + +The driver provides the next attributes for the current: + +- for current out input and maximum alarm; +- for phase current: input and label. + +The driver exports the following attributes via the 'sysfs' files, where: + +- 'n' is number of configured phases (from 1 to 10); +- index 1 for "iout"; +- indexes 2 ... 1 + n for phases. + +**curr[1-{1+n}]_input** + +**curr[1-{1+n}]_label** + +**curr1_max** + +**curr1_max_alarm** + +The driver provides the next attributes for the voltage: + +- for voltage in: input, low and high critical thresholds, low and high + critical alarms; +- for voltage out: input and high alarm; + +The driver exports the following attributes via the 'sysfs' files, where + +**in1_crit** + +**in1_crit_alarm** + +**in1_input** + +**in1_label** + +**in1_min** + +**in1_min_alarm** + +**in2_alarm** + +**in2_input** + +**in2_label** + +The driver provides the next attributes for the power: + +- for power in alarm and input. +- for power out: cap, cap alarm an input. + +The driver exports the following attributes via the 'sysfs' files, where +- indexes 1 for "pin"; +- indexes 2 for "pout"; + +**power1_alarm** + +**power1_input** + +**power1_label** + +**power2_input** + +**power2_label** + +**power2_max** + +**power2_max_alarm** + +The driver provides the next attributes for the temperature: + +**temp1_input** + +**temp1_max** + +**temp1_max_alarm** -- cgit v1.2.3 From 9abfb52b502889f1528316cf0b7d4116d40abebe Mon Sep 17 00:00:00 2001 From: Vadim Pasternak Date: Tue, 11 May 2021 08:56:19 +0300 Subject: dt-bindings: Add MP2888 voltage regulator device Monolithic Power Systems, Inc. (MPS) dual-loop, digital, multi-phase controller. Signed-off-by: Vadim Pasternak Acked-by: Rob Herring Link: https://lore.kernel.org/r/20210511055619.118104-4-vadimp@nvidia.com Signed-off-by: Guenter Roeck --- Documentation/devicetree/bindings/trivial-devices.yaml | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/trivial-devices.yaml b/Documentation/devicetree/bindings/trivial-devices.yaml index 8341e9d23c1e..f8824e1dd24c 100644 --- a/Documentation/devicetree/bindings/trivial-devices.yaml +++ b/Documentation/devicetree/bindings/trivial-devices.yaml @@ -103,6 +103,8 @@ properties: - fsl,mpl3115 # MPR121: Proximity Capacitive Touch Sensor Controller - fsl,mpr121 + # Monolithic Power Systems Inc. multi-phase controller mp2888 + - mps,mp2888 # Monolithic Power Systems Inc. multi-phase controller mp2975 - mps,mp2975 # G751: Digital Temperature Sensor and Thermal Watchdog with Two-Wire Interface -- cgit v1.2.3 From f20f7363e7e1d24defc27b1cb814071791a535b0 Mon Sep 17 00:00:00 2001 From: Fabio Estevam Date: Fri, 21 May 2021 14:22:18 -0300 Subject: docs: hwmon: Add an entry for mp2888 The entry for mp2888 is missing and it causes the following 'make htmldocs' build warning: Documentation/hwmon/mp2888.rst: WARNING: document isn't included in any toctree Add the mp2888 entry. Signed-off-by: Fabio Estevam Link: https://lore.kernel.org/r/20210521172218.37592-1-festevam@gmail.com Signed-off-by: Guenter Roeck --- Documentation/hwmon/index.rst | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/hwmon/index.rst b/Documentation/hwmon/index.rst index 9ed60fa84cbe..6925a8a70511 100644 --- a/Documentation/hwmon/index.rst +++ b/Documentation/hwmon/index.rst @@ -137,6 +137,7 @@ Hardware Monitoring Kernel Drivers mcp3021 menf21bmc mlxreg-fan + mp2888 mp2975 nct6683 nct6775 -- cgit v1.2.3 From 505c2549373f3aa9ee16493f872e57876ffb70b1 Mon Sep 17 00:00:00 2001 From: Navin Sankar Velliangiri Date: Mon, 24 May 2021 19:50:38 +0530 Subject: hwmon: Add sht4x Temperature and Humidity Sensor Driver This patch adds a hwmon driver for the SHT4x Temperature and Humidity sensor. Signed-off-by: Navin Sankar Velliangiri [groeck: dropped unnecessary empty line and continuation lines] Signed-off-by: Guenter Roeck --- Documentation/hwmon/index.rst | 1 + Documentation/hwmon/sht4x.rst | 45 +++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 46 insertions(+) create mode 100644 Documentation/hwmon/sht4x.rst (limited to 'Documentation') diff --git a/Documentation/hwmon/index.rst b/Documentation/hwmon/index.rst index 6925a8a70511..61e5d4532622 100644 --- a/Documentation/hwmon/index.rst +++ b/Documentation/hwmon/index.rst @@ -165,6 +165,7 @@ Hardware Monitoring Kernel Drivers sht15 sht21 sht3x + sht4x shtc1 sis5595 sl28cpld diff --git a/Documentation/hwmon/sht4x.rst b/Documentation/hwmon/sht4x.rst new file mode 100644 index 000000000000..3b37abcd4a46 --- /dev/null +++ b/Documentation/hwmon/sht4x.rst @@ -0,0 +1,45 @@ +.. SPDX-License-Identifier: GPL-2.0 + +Kernel driver sht4x +=================== + +Supported Chips: + + * Sensirion SHT4X + + Prefix: 'sht4x' + + Addresses scanned: None + + Datasheet: + + English: https://www.sensirion.com/fileadmin/user_upload/customers/sensirion/Dokumente/2_Humidity_Sensors/Datasheets/Sensirion_Humidity_Sensors_SHT4x_Datasheet.pdf + +Author: Navin Sankar Velliangiri + + +Description +----------- + +This driver implements support for the Sensirion SHT4x chip, a humidity +and temperature sensor. Temperature is measured in degree celsius, relative +humidity is expressed as a percentage. In sysfs interface, all values are +scaled by 1000, i.e. the value for 31.5 degrees celsius is 31500. + +Usage Notes +----------- + +The device communicates with the I2C protocol. Sensors can have the I2C +address 0x44. See Documentation/i2c/instantiating-devices.rst for methods +to instantiate the device. + +Sysfs entries +------------- + +=============== ============================================ +temp1_input Measured temperature in millidegrees Celcius +humidity1_input Measured humidity in %H +update_interval The minimum interval for polling the sensor, + in milliseconds. Writable. Must be at least + 2000. +============== ============================================= -- cgit v1.2.3 From 897f6339893b741a5d68ae8e2475df65946041c2 Mon Sep 17 00:00:00 2001 From: Guenter Roeck Date: Wed, 26 May 2021 08:40:17 -0700 Subject: hwmon: (max31790) Report correct current pwm duty cycles MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The MAX31790 has two sets of registers for pwm duty cycles, one to request a duty cycle and one to read the actual current duty cycle. Both do not have to be the same. When reporting the pwm duty cycle to the user, the actual pwm duty cycle from pwm duty cycle registers needs to be reported. When setting it, the pwm target duty cycle needs to be written. Since we don't know the actual pwm duty cycle after a target pwm duty cycle has been written, set the valid flag to false to indicate that actual pwm duty cycle should be read from the chip instead of using cached values. Cc: Jan Kundrát Cc: Václav Kubernát Signed-off-by: Guenter Roeck Tested-by: Václav Kubernát Reviewed-by: Jan Kundrát Link: https://lore.kernel.org/r/20210526154022.3223012-3-linux@roeck-us.net --- Documentation/hwmon/max31790.rst | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/hwmon/max31790.rst b/Documentation/hwmon/max31790.rst index f301385d8cef..54ff0f49e28f 100644 --- a/Documentation/hwmon/max31790.rst +++ b/Documentation/hwmon/max31790.rst @@ -39,5 +39,6 @@ fan[1-12]_input RO fan tachometer speed in RPM fan[1-12]_fault RO fan experienced fault fan[1-6]_target RW desired fan speed in RPM pwm[1-6]_enable RW regulator mode, 0=disabled, 1=manual mode, 2=rpm mode -pwm[1-6] RW fan target duty cycle (0-255) +pwm[1-6] RW read: current pwm duty cycle, + write: target pwm duty cycle (0-255) ================== === ======================================================= -- cgit v1.2.3 From 148c847c9e5a54b99850617bf9c143af9a344f92 Mon Sep 17 00:00:00 2001 From: Guenter Roeck Date: Wed, 26 May 2021 08:40:18 -0700 Subject: hwmon: (max31790) Fix pwmX_enable attributes MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit pwmX_enable supports three possible values: 0: Fan control disabled. Duty cycle is fixed to 0% 1: Fan control enabled, pwm mode. Duty cycle is determined by values written into Target Duty Cycle registers. 2: Fan control enabled, rpm mode Duty cycle is adjusted such that fan speed matches the values in Target Count registers The current code does not do this; instead, it mixes pwm control configuration with fan speed monitoring configuration. Worse, it reports that pwm control would be disabled (pwmX_enable==0) when it is in fact enabled in pwm mode. Part of the problem may be that the chip sets the "TACH input enable" bit on its own whenever the mode bit is set to RPM mode, but that doesn't mean that "TACH input enable" accurately reflects the pwm mode. Fix it up and only handle pwm control with the pwmX_enable attributes. In the documentation, clarify that disabling pwm control (pwmX_enable=0) sets the pwm duty cycle to 0%. In the code, explain why TACH_INPUT_EN is set together with RPM_MODE. While at it, only update the configuration register if the configuration has changed, and only update the cached configuration if updating the chip configuration was successful. Cc: Jan Kundrát Cc: Václav Kubernát Signed-off-by: Guenter Roeck Tested-by: Václav Kubernát Reviewed-by: Jan Kundrát Link: https://lore.kernel.org/r/20210526154022.3223012-4-linux@roeck-us.net --- Documentation/hwmon/max31790.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/hwmon/max31790.rst b/Documentation/hwmon/max31790.rst index 54ff0f49e28f..7b097c3b9b90 100644 --- a/Documentation/hwmon/max31790.rst +++ b/Documentation/hwmon/max31790.rst @@ -38,7 +38,7 @@ Sysfs entries fan[1-12]_input RO fan tachometer speed in RPM fan[1-12]_fault RO fan experienced fault fan[1-6]_target RW desired fan speed in RPM -pwm[1-6]_enable RW regulator mode, 0=disabled, 1=manual mode, 2=rpm mode +pwm[1-6]_enable RW regulator mode, 0=disabled (duty cycle=0%), 1=manual mode, 2=rpm mode pwm[1-6] RW read: current pwm duty cycle, write: target pwm duty cycle (0-255) ================== === ======================================================= -- cgit v1.2.3 From ff53b77e1e1bc9fd21e087e37a8444e8559d8d36 Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Sat, 5 Jun 2021 15:18:21 +0200 Subject: docs: hwmon: adm1177.rst: avoid using ReSt :doc:`foo` markup The :doc:`foo` tag is auto-generated via automarkup.py. So, use the filename at the sources, instead of :doc:`foo`. Signed-off-by: Mauro Carvalho Chehab Link: https://lore.kernel.org/r/32b0db7e79a3ed0e817213113c607a1b819e3867.1622898327.git.mchehab+huawei@kernel.org Signed-off-by: Guenter Roeck --- Documentation/hwmon/adm1177.rst | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/hwmon/adm1177.rst b/Documentation/hwmon/adm1177.rst index 471be1e98d6f..1c85a2af92bf 100644 --- a/Documentation/hwmon/adm1177.rst +++ b/Documentation/hwmon/adm1177.rst @@ -20,7 +20,8 @@ Usage Notes ----------- This driver does not auto-detect devices. You will have to instantiate the -devices explicitly. Please see :doc:`/i2c/instantiating-devices` for details. +devices explicitly. Please see Documentation/i2c/instantiating-devices.rst +for details. Sysfs entries -- cgit v1.2.3 From bf8e0cd8d6b2c9be365ea53d36e9368f07880a2f Mon Sep 17 00:00:00 2001 From: Erik Rosen Date: Wed, 9 Jun 2021 11:32:09 +0200 Subject: hwmon: (pmbus/pim4328) Add documentation for the pim4328 PMBus driver Add documentation and index link for pim4328 PMBus driver. Signed-off-by: Erik Rosen Signed-off-by: Guenter Roeck --- Documentation/hwmon/index.rst | 1 + Documentation/hwmon/pim4328.rst | 105 ++++++++++++++++++++++++++++++++++++++++ 2 files changed, 106 insertions(+) create mode 100644 Documentation/hwmon/pim4328.rst (limited to 'Documentation') diff --git a/Documentation/hwmon/index.rst b/Documentation/hwmon/index.rst index 61e5d4532622..9d4f5b2b84b0 100644 --- a/Documentation/hwmon/index.rst +++ b/Documentation/hwmon/index.rst @@ -151,6 +151,7 @@ Hardware Monitoring Kernel Drivers pc87360 pc87427 pcf8591 + pim4328 pm6764tr pmbus powr1220 diff --git a/Documentation/hwmon/pim4328.rst b/Documentation/hwmon/pim4328.rst new file mode 100644 index 000000000000..70c9e7a6882c --- /dev/null +++ b/Documentation/hwmon/pim4328.rst @@ -0,0 +1,105 @@ +.. SPDX-License-Identifier: GPL-2.0 + +Kernel driver pim4328 +===================== + +Supported chips: + + * Flex PIM4328 + + Prefix: 'pim4328', 'bmr455' + + Addresses scanned: - + + Datasheet: + +https://flexpowermodules.com/resources/fpm-techspec-pim4328 + + * Flex PIM4820 + + Prefixes: 'pim4820' + + Addresses scanned: - + + Datasheet: https://flexpowermodules.com/resources/fpm-techspec-pim4820 + + * Flex PIM4006, PIM4106, PIM4206, PIM4306, PIM4406 + + Prefixes: 'pim4006', 'pim4106', 'pim4206', 'pim4306', 'pim4406' + + Addresses scanned: - + + Datasheet: https://flexpowermodules.com/resources/fpm-techspec-pim4006 + +Author: Erik Rosen + + +Description +----------- + +This driver supports hardware monitoring for Flex PIM4328 and +compatible digital power interface modules. + +The driver is a client driver to the core PMBus driver. Please see +Documentation/hwmon/pmbus.rst and Documentation.hwmon/pmbus-core for details +on PMBus client drivers. + + +Usage Notes +----------- + +This driver does not auto-detect devices. You will have to instantiate the +devices explicitly. Please see Documentation/i2c/instantiating-devices.rst for +details. + + +Platform data support +--------------------- + +The driver supports standard PMBus driver platform data. + + +Sysfs entries +------------- + +The following attributes are supported. All attributes are read-only. + +======================= ======================================================== +in1_label "vin" +in1_input Measured input voltage. +in1_alarm Input voltage alarm. + +in2_label "vin.0" +in2_input Measured input voltage on input A. + + PIM4328 and PIM4X06 + +in3_label "vin.1" +in3_input Measured input voltage on input B. + + PIM4328 and PIM4X06 + +in4_label "vcap" +in4_input Measured voltage on holdup capacitor. + + PIM4328 + +curr1_label "iin.0" +curr1_input Measured input current on input A. + + PIM4X06 + +curr2_label "iin.1" +curr2_input Measured input current on input B. + + PIM4X06 + +currX_label "iout1" +currX_input Measured output current. +currX_alarm Output current alarm. + + X is 1 for PIM4820, 3 otherwise. + +temp1_input Measured temperature. +temp1_alarm High temperature alarm. +======================= ======================================================== -- cgit v1.2.3 From 3efbcee8d4029795fa0a1ef90dc5b9ea763ed207 Mon Sep 17 00:00:00 2001 From: Robert Marko Date: Mon, 7 Jun 2021 12:34:29 +0200 Subject: hwmon: (pmbus) Add driver for Delta DPS-920AB PSU This adds support for the Delta DPS-920AB PSU. Only missing feature is fan control which the PSU supports. Signed-off-by: Robert Marko Link: https://lore.kernel.org/r/20210607103431.2039073-1-robert.marko@sartura.hr [groeck: Add MODULE_IMPORT_NS(PMBUS);] Signed-off-by: Guenter Roeck --- Documentation/hwmon/dps920ab.rst | 73 ++++++++++++++++++++++++++++++++++++++++ Documentation/hwmon/index.rst | 1 + 2 files changed, 74 insertions(+) create mode 100644 Documentation/hwmon/dps920ab.rst (limited to 'Documentation') diff --git a/Documentation/hwmon/dps920ab.rst b/Documentation/hwmon/dps920ab.rst new file mode 100644 index 000000000000..c33b4cdc0a60 --- /dev/null +++ b/Documentation/hwmon/dps920ab.rst @@ -0,0 +1,73 @@ +.. SPDX-License-Identifier: GPL-2.0-or-later + +Kernel driver dps920ab +======================== + +Supported chips: + + * Delta DPS920AB + + Prefix: 'dps920ab' + + Addresses scanned: - + +Authors: + Robert Marko + + +Description +----------- + +This driver implements support for Delta DPS920AB 920W 54V DC single output +power supply with PMBus support. + +The driver is a client driver to the core PMBus driver. +Please see Documentation/hwmon/pmbus.rst for details on PMBus client drivers. + + +Usage Notes +----------- + +This driver does not auto-detect devices. You will have to instantiate the +devices explicitly. Please see Documentation/i2c/instantiating-devices.rst for +details. + + +Sysfs entries +------------- + +======================= ====================================================== +curr1_label "iin" +curr1_input Measured input current +curr1_alarm Input current high alarm + +curr2_label "iout1" +curr2_input Measured output current +curr2_max Maximum output current +curr2_rated_max Maximum rated output current + +in1_label "vin" +in1_input Measured input voltage +in1_alarm Input voltage alarm + +in2_label "vout1" +in2_input Measured output voltage +in2_rated_min Minimum rated output voltage +in2_rated_max Maximum rated output voltage +in2_alarm Output voltage alarm + +power1_label "pin" +power1_input Measured input power +power1_alarm Input power high alarm + +power2_label "pout1" +power2_input Measured output power +power2_rated_max Maximum rated output power + +temp[1-3]_input Measured temperature +temp[1-3]_alarm Temperature alarm + +fan1_alarm Fan 1 warning. +fan1_fault Fan 1 fault. +fan1_input Fan 1 speed in RPM. +======================= ====================================================== diff --git a/Documentation/hwmon/index.rst b/Documentation/hwmon/index.rst index 9d4f5b2b84b0..bc01601ea81a 100644 --- a/Documentation/hwmon/index.rst +++ b/Documentation/hwmon/index.rst @@ -53,6 +53,7 @@ Hardware Monitoring Kernel Drivers da9055 dell-smm-hwmon dme1737 + dps920ab drivetemp ds1621 ds620 -- cgit v1.2.3 From 8b1d61cd47ccea482a3f68c99d7358e3daea35fa Mon Sep 17 00:00:00 2001 From: Robert Marko Date: Mon, 7 Jun 2021 12:34:30 +0200 Subject: dt-bindings: trivial-devices: Add Delta DPS920AB Add trivial device entry for Delta DPS920AB PSU. Signed-off-by: Robert Marko Link: https://lore.kernel.org/r/20210607103431.2039073-2-robert.marko@sartura.hr Signed-off-by: Guenter Roeck --- Documentation/devicetree/bindings/trivial-devices.yaml | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/trivial-devices.yaml b/Documentation/devicetree/bindings/trivial-devices.yaml index f8824e1dd24c..37ac0a3ae3b4 100644 --- a/Documentation/devicetree/bindings/trivial-devices.yaml +++ b/Documentation/devicetree/bindings/trivial-devices.yaml @@ -73,6 +73,8 @@ properties: - dallas,ds4510 # Digital Thermometer and Thermostat - dallas,ds75 + # Delta Electronics DPS920AB 920W 54V Power Supply + - delta,dps920ab # 1/4 Brick DC/DC Regulated Power Module - delta,q54sj108a2 # Devantech SRF02 ultrasonic ranger in I2C mode -- cgit v1.2.3 From aa7968682a2b8a9cecf1d7d07e1c8ae8c08d211e Mon Sep 17 00:00:00 2001 From: Nobuhiro Iwamatsu Date: Sat, 5 Jun 2021 09:38:11 +0900 Subject: spi: convert Cadence SPI bindings to YAML Convert spi for Cadence SPI bindings documentation to YAML. Signed-off-by: Nobuhiro Iwamatsu Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20210605003811.858676-1-iwamatsu@nigauri.org Signed-off-by: Mark Brown --- .../devicetree/bindings/spi/spi-cadence.txt | 30 ---------- .../devicetree/bindings/spi/spi-cadence.yaml | 66 ++++++++++++++++++++++ 2 files changed, 66 insertions(+), 30 deletions(-) delete mode 100644 Documentation/devicetree/bindings/spi/spi-cadence.txt create mode 100644 Documentation/devicetree/bindings/spi/spi-cadence.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/spi/spi-cadence.txt b/Documentation/devicetree/bindings/spi/spi-cadence.txt deleted file mode 100644 index 05a2ef945664..000000000000 --- a/Documentation/devicetree/bindings/spi/spi-cadence.txt +++ /dev/null @@ -1,30 +0,0 @@ -Cadence SPI controller Device Tree Bindings -------------------------------------------- - -Required properties: -- compatible : Should be "cdns,spi-r1p6" or "xlnx,zynq-spi-r1p6". -- reg : Physical base address and size of SPI registers map. -- interrupts : Property with a value describing the interrupt - number. -- clock-names : List of input clock names - "ref_clk", "pclk" - (See clock bindings for details). -- clocks : Clock phandles (see clock bindings for details). - -Optional properties: -- num-cs : Number of chip selects used. - If a decoder is used, this will be the number of - chip selects after the decoder. -- is-decoded-cs : Flag to indicate whether decoder is used or not. - -Example: - - spi@e0007000 { - compatible = "xlnx,zynq-spi-r1p6"; - clock-names = "ref_clk", "pclk"; - clocks = <&clkc 26>, <&clkc 35>; - interrupt-parent = <&intc>; - interrupts = <0 49 4>; - num-cs = <4>; - is-decoded-cs = <0>; - reg = <0xe0007000 0x1000>; - } ; diff --git a/Documentation/devicetree/bindings/spi/spi-cadence.yaml b/Documentation/devicetree/bindings/spi/spi-cadence.yaml new file mode 100644 index 000000000000..9787be21318e --- /dev/null +++ b/Documentation/devicetree/bindings/spi/spi-cadence.yaml @@ -0,0 +1,66 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/spi/spi-cadence.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Cadence SPI controller Device Tree Bindings + +maintainers: + - Michal Simek + +allOf: + - $ref: "spi-controller.yaml#" + +properties: + compatible: + enum: + - cdns,spi-r1p6 + - xlnx,zynq-spi-r1p6 + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clock-names: + items: + - const: ref_clk + - const: pclk + + clocks: + maxItems: 2 + + num-cs: + description: | + Number of chip selects used. If a decoder is used, + this will be the number of chip selects after the + decoder. + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 1 + maximum: 4 + default: 4 + + is-decoded-cs: + description: | + Flag to indicate whether decoder is used or not. + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [ 0, 1 ] + default: 0 + +unevaluatedProperties: false + +examples: + - | + spi@e0007000 { + compatible = "xlnx,zynq-spi-r1p6"; + clock-names = "ref_clk", "pclk"; + clocks = <&clkc 26>, <&clkc 35>; + interrupt-parent = <&intc>; + interrupts = <0 49 4>; + num-cs = <4>; + is-decoded-cs = <0>; + reg = <0xe0007000 0x1000>; + }; +... -- cgit v1.2.3 From 476ad3ff8952db3569a77d9ed4a067c5f0f4b733 Mon Sep 17 00:00:00 2001 From: Nobuhiro Iwamatsu Date: Sat, 5 Jun 2021 09:29:31 +0900 Subject: spi: xilinx: convert to yaml Convert SPI for Xilinx bindings documentation to YAML schemas. Signed-off-by: Nobuhiro Iwamatsu Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20210605002931.858031-1-iwamatsu@nigauri.org Signed-off-by: Mark Brown --- .../devicetree/bindings/spi/spi-xilinx.txt | 23 --------- .../devicetree/bindings/spi/spi-xilinx.yaml | 57 ++++++++++++++++++++++ 2 files changed, 57 insertions(+), 23 deletions(-) delete mode 100644 Documentation/devicetree/bindings/spi/spi-xilinx.txt create mode 100644 Documentation/devicetree/bindings/spi/spi-xilinx.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/spi/spi-xilinx.txt b/Documentation/devicetree/bindings/spi/spi-xilinx.txt deleted file mode 100644 index 5f4ed3e5c994..000000000000 --- a/Documentation/devicetree/bindings/spi/spi-xilinx.txt +++ /dev/null @@ -1,23 +0,0 @@ -Xilinx SPI controller Device Tree Bindings -------------------------------------------------- - -Required properties: -- compatible : Should be "xlnx,xps-spi-2.00.a", "xlnx,xps-spi-2.00.b" or "xlnx,axi-quad-spi-1.00.a" -- reg : Physical base address and size of SPI registers map. -- interrupts : Property with a value describing the interrupt - number. - -Optional properties: -- xlnx,num-ss-bits : Number of chip selects used. -- xlnx,num-transfer-bits : Number of bits per transfer. This will be 8 if not specified - -Example: - axi_quad_spi@41e00000 { - compatible = "xlnx,xps-spi-2.00.a"; - interrupt-parent = <&intc>; - interrupts = <0 31 1>; - reg = <0x41e00000 0x10000>; - xlnx,num-ss-bits = <0x1>; - xlnx,num-transfer-bits = <32>; - }; - diff --git a/Documentation/devicetree/bindings/spi/spi-xilinx.yaml b/Documentation/devicetree/bindings/spi/spi-xilinx.yaml new file mode 100644 index 000000000000..593f7693bace --- /dev/null +++ b/Documentation/devicetree/bindings/spi/spi-xilinx.yaml @@ -0,0 +1,57 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/spi/spi-xilinx.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Xilinx SPI controller Device Tree Bindings + +maintainers: + - Michal Simek + +allOf: + - $ref: "spi-controller.yaml#" + +properties: + compatible: + enum: + - xlnx,xps-spi-2.00.a + - xlnx,xps-spi-2.00.b + - xlnx,axi-quad-spi-1.00.a + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + xlnx,num-ss-bits: + description: Number of chip selects used. + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 1 + maximum: 32 + + xlnx,num-transfer-bits: + description: Number of bits per transfer. This will be 8 if not specified. + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [8, 16, 32] + default: 8 + +required: + - compatible + - reg + - interrupts + +unevaluatedProperties: false + +examples: + - | + spi0: spi@41e00000 { + compatible = "xlnx,xps-spi-2.00.a"; + interrupt-parent = <&intc>; + interrupts = <0 31 1>; + reg = <0x41e00000 0x10000>; + xlnx,num-ss-bits = <0x1>; + xlnx,num-transfer-bits = <32>; + }; +... -- cgit v1.2.3 From cca061b04c0de4c8a0b2cfcdf534ab0a566178c3 Mon Sep 17 00:00:00 2001 From: Linus Walleij Date: Tue, 11 May 2021 15:06:40 +0200 Subject: hw_random: ixp4xx: Add DT bindings This adds device tree bindings for the simple random number generator found in the IXP46x SoCs. Cc: Deepak Saxena Cc: devicetree@vger.kernel.org Reviewed-by: Rob Herring Signed-off-by: Linus Walleij --- .../devicetree/bindings/rng/intel,ixp46x-rng.yaml | 36 ++++++++++++++++++++++ 1 file changed, 36 insertions(+) create mode 100644 Documentation/devicetree/bindings/rng/intel,ixp46x-rng.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/rng/intel,ixp46x-rng.yaml b/Documentation/devicetree/bindings/rng/intel,ixp46x-rng.yaml new file mode 100644 index 000000000000..61963fa9347e --- /dev/null +++ b/Documentation/devicetree/bindings/rng/intel,ixp46x-rng.yaml @@ -0,0 +1,36 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/rng/intel,ixp46x-rng.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Intel IXP46x RNG bindings + +description: | + The Intel IXP46x has a random number generator at a fixed physical + location in memory. Each read is guaranteed to provide a unique + 32 bit random number. + +maintainers: + - Linus Walleij + +properties: + compatible: + const: intel,ixp46x-rng + + reg: + maxItems: 1 + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + rng@70002100 { + compatible = "intel,ixp46x-rng"; + reg = <0x70002100 4>; + }; + -- cgit v1.2.3 From 1fc4f5238d9680c7889cbd56c3c6a8ddd1f74d5c Mon Sep 17 00:00:00 2001 From: Kishon Vijay Abraham I Date: Thu, 3 Jun 2021 19:04:50 +0530 Subject: dt-bindings: PCI: ti,am65: Convert PCIe host/endpoint mode dt-bindings to YAML Convert PCIe host/endpoint mode dt-bindings for TI's AM65/Keystone SoC to YAML binding. Signed-off-by: Kishon Vijay Abraham I Link: https://lore.kernel.org/r/20210603133450.24710-1-kishon@ti.com Signed-off-by: Rob Herring --- .../devicetree/bindings/pci/pci-keystone.txt | 115 --------------------- .../devicetree/bindings/pci/ti,am65-pci-ep.yaml | 74 +++++++++++++ .../devicetree/bindings/pci/ti,am65-pci-host.yaml | 96 +++++++++++++++++ 3 files changed, 170 insertions(+), 115 deletions(-) delete mode 100644 Documentation/devicetree/bindings/pci/pci-keystone.txt create mode 100644 Documentation/devicetree/bindings/pci/ti,am65-pci-ep.yaml create mode 100644 Documentation/devicetree/bindings/pci/ti,am65-pci-host.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pci/pci-keystone.txt b/Documentation/devicetree/bindings/pci/pci-keystone.txt deleted file mode 100644 index 47202a2938f2..000000000000 --- a/Documentation/devicetree/bindings/pci/pci-keystone.txt +++ /dev/null @@ -1,115 +0,0 @@ -TI Keystone PCIe interface - -Keystone PCI host Controller is based on the Synopsys DesignWare PCI -hardware version 3.65. It shares common functions with the PCIe DesignWare -core driver and inherits common properties defined in -Documentation/devicetree/bindings/pci/designware-pcie.txt - -Please refer to Documentation/devicetree/bindings/pci/designware-pcie.txt -for the details of DesignWare DT bindings. Additional properties are -described here as well as properties that are not applicable. - -Required Properties:- - -compatibility: Should be "ti,keystone-pcie" for RC on Keystone2 SoC - Should be "ti,am654-pcie-rc" for RC on AM654x SoC -reg: Three register ranges as listed in the reg-names property -reg-names: "dbics" for the DesignWare PCIe registers, "app" for the - TI specific application registers, "config" for the - configuration space address - -pcie_msi_intc : Interrupt controller device node for MSI IRQ chip - interrupt-cells: should be set to 1 - interrupts: GIC interrupt lines connected to PCI MSI interrupt lines - (required if the compatible is "ti,keystone-pcie") -msi-map: As specified in Documentation/devicetree/bindings/pci/pci-msi.txt - (required if the compatible is "ti,am654-pcie-rc". - -ti,syscon-pcie-id : phandle to the device control module required to set device - id and vendor id. -ti,syscon-pcie-mode : phandle to the device control module required to configure - PCI in either RC mode or EP mode. - - Example: - pcie_msi_intc: msi-interrupt-controller { - interrupt-controller; - #interrupt-cells = <1>; - interrupt-parent = <&gic>; - interrupts = , - , - , - , - , - , - , - ; - }; - -pcie_intc: Interrupt controller device node for Legacy IRQ chip - interrupt-cells: should be set to 1 - - Example: - pcie_intc: legacy-interrupt-controller { - interrupt-controller; - #interrupt-cells = <1>; - interrupt-parent = <&gic>; - interrupts = , - , - , - ; - }; - -Optional properties:- - phys: phandle to generic Keystone SerDes PHY for PCI - phy-names: name of the generic Keystone SerDes PHY for PCI - - If boot loader already does PCI link establishment, then phys and - phy-names shouldn't be present. - interrupts: platform interrupt for error interrupts. - -DesignWare DT Properties not applicable for Keystone PCI - -1. pcie_bus clock-names not used. Instead, a phandle to phys is used. - -AM654 PCIe Endpoint -=================== - -Required Properties:- - -compatibility: Should be "ti,am654-pcie-ep" for EP on AM654x SoC -reg: Four register ranges as listed in the reg-names property -reg-names: "dbics" for the DesignWare PCIe registers, "app" for the - TI specific application registers, "atu" for the - Address Translation Unit configuration registers and - "addr_space" used to map remote RC address space -num-ib-windows: As specified in - Documentation/devicetree/bindings/pci/designware-pcie.txt -num-ob-windows: As specified in - Documentation/devicetree/bindings/pci/designware-pcie.txt -num-lanes: As specified in - Documentation/devicetree/bindings/pci/designware-pcie.txt -power-domains: As documented by the generic PM domain bindings in - Documentation/devicetree/bindings/power/power_domain.txt. -ti,syscon-pcie-mode: phandle to the device control module required to configure - PCI in either RC mode or EP mode. - -Optional properties:- - -phys: list of PHY specifiers (used by generic PHY framework) -phy-names: must be "pcie-phy0", "pcie-phy1", "pcie-phyN".. based on the - number of lanes as specified in *num-lanes* property. -("phys" and "phy-names" DT bindings are specified in -Documentation/devicetree/bindings/phy/phy-bindings.txt) -interrupts: platform interrupt for error interrupts. - -pcie-ep { - compatible = "ti,am654-pcie-ep"; - reg = <0x5500000 0x1000>, <0x5501000 0x1000>, - <0x10000000 0x8000000>, <0x5506000 0x1000>; - reg-names = "app", "dbics", "addr_space", "atu"; - power-domains = <&k3_pds 120>; - ti,syscon-pcie-mode = <&pcie0_mode>; - num-lanes = <1>; - num-ib-windows = <16>; - num-ob-windows = <16>; - interrupts = ; -}; diff --git a/Documentation/devicetree/bindings/pci/ti,am65-pci-ep.yaml b/Documentation/devicetree/bindings/pci/ti,am65-pci-ep.yaml new file mode 100644 index 000000000000..78c217d362a7 --- /dev/null +++ b/Documentation/devicetree/bindings/pci/ti,am65-pci-ep.yaml @@ -0,0 +1,74 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +# Copyright (C) 2021 Texas Instruments Incorporated - http://www.ti.com/ +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pci/ti,am65-pci-ep.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: TI AM65 PCI Endpoint + +maintainers: + - Kishon Vijay Abraham I + +allOf: + - $ref: pci-ep.yaml# + +properties: + compatible: + enum: + - ti,am654-pcie-ep + + reg: + maxItems: 4 + + reg-names: + items: + - const: app + - const: dbics + - const: addr_space + - const: atu + + power-domains: + maxItems: 1 + + ti,syscon-pcie-mode: + description: Phandle to the SYSCON entry required for configuring PCIe in RC or EP mode. + $ref: /schemas/types.yaml#/definitions/phandle + + interrupts: + minItems: 1 + + dma-coherent: true + +required: + - compatible + - reg + - reg-names + - max-link-speed + - power-domains + - ti,syscon-pcie-mode + - dma-coherent + +unevaluatedProperties: false + +examples: + - | + #include + #include + #include + + pcie0_ep: pcie-ep@5500000 { + compatible = "ti,am654-pcie-ep"; + reg = <0x5500000 0x1000>, + <0x5501000 0x1000>, + <0x10000000 0x8000000>, + <0x5506000 0x1000>; + reg-names = "app", "dbics", "addr_space", "atu"; + power-domains = <&k3_pds 120 TI_SCI_PD_EXCLUSIVE>; + ti,syscon-pcie-mode = <&pcie0_mode>; + num-ib-windows = <16>; + num-ob-windows = <16>; + max-link-speed = <2>; + dma-coherent; + interrupts = ; + }; diff --git a/Documentation/devicetree/bindings/pci/ti,am65-pci-host.yaml b/Documentation/devicetree/bindings/pci/ti,am65-pci-host.yaml new file mode 100644 index 000000000000..834dc1c1743c --- /dev/null +++ b/Documentation/devicetree/bindings/pci/ti,am65-pci-host.yaml @@ -0,0 +1,96 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +# Copyright (C) 2021 Texas Instruments Incorporated - http://www.ti.com/ +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pci/ti,am65-pci-host.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: TI AM65 PCI Host + +maintainers: + - Kishon Vijay Abraham I + +allOf: + - $ref: /schemas/pci/pci-bus.yaml# + +properties: + compatible: + enum: + - ti,am654-pcie-rc + - ti,keystone-pcie + + reg: + maxItems: 4 + + reg-names: + items: + - const: app + - const: dbics + - const: config + - const: atu + + power-domains: + maxItems: 1 + + ti,syscon-pcie-id: + description: Phandle to the SYSCON entry required for getting PCIe device/vendor ID + $ref: /schemas/types.yaml#/definitions/phandle + + ti,syscon-pcie-mode: + description: Phandle to the SYSCON entry required for configuring PCIe in RC or EP mode. + $ref: /schemas/types.yaml#/definitions/phandle + + msi-map: true + + dma-coherent: true + +required: + - compatible + - reg + - reg-names + - max-link-speed + - ti,syscon-pcie-id + - ti,syscon-pcie-mode + - ranges + +if: + properties: + compatible: + enum: + - ti,am654-pcie-rc +then: + required: + - dma-coherent + - power-domains + - msi-map + +unevaluatedProperties: false + +examples: + - | + #include + #include + #include + + pcie0_rc: pcie@5500000 { + compatible = "ti,am654-pcie-rc"; + reg = <0x5500000 0x1000>, + <0x5501000 0x1000>, + <0x10000000 0x2000>, + <0x5506000 0x1000>; + reg-names = "app", "dbics", "config", "atu"; + power-domains = <&k3_pds 120 TI_SCI_PD_EXCLUSIVE>; + #address-cells = <3>; + #size-cells = <2>; + ranges = <0x81000000 0 0 0x10020000 0 0x00010000>, + <0x82000000 0 0x10030000 0x10030000 0 0x07FD0000>; + ti,syscon-pcie-id = <&pcie_devid>; + ti,syscon-pcie-mode = <&pcie0_mode>; + bus-range = <0x0 0xff>; + num-viewport = <16>; + max-link-speed = <2>; + dma-coherent; + interrupts = ; + msi-map = <0x0 &gic_its 0x0 0x10000>; + device_type = "pci"; + }; -- cgit v1.2.3 From cfe34bb7a770c5d8af053d53f5b76d5033667a73 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ricardo=20Ca=C3=B1uelo?= Date: Tue, 15 Jun 2021 15:13:33 +0200 Subject: dt-bindings: drm: bridge: adi,adv7511.txt: convert to yaml MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Convert the ADV7511/11w/13/33/35 DT bindings to json-schema. The original binding has been split into two files: adi,adv7511.yaml for ADV7511/11W/13 and adi,adv7533.yaml for ADV7533/35. Signed-off-by: Ricardo Cañuelo Reviewed-by: Rob Herring Reviewed-by: Laurent Pinchart Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20210615131333.2272473-4-ricardo.canuelo@collabora.com --- .../bindings/display/bridge/adi,adv7511.txt | 143 ------------ .../bindings/display/bridge/adi,adv7511.yaml | 241 +++++++++++++++++++++ .../bindings/display/bridge/adi,adv7533.yaml | 184 ++++++++++++++++ 3 files changed, 425 insertions(+), 143 deletions(-) delete mode 100644 Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt create mode 100644 Documentation/devicetree/bindings/display/bridge/adi,adv7511.yaml create mode 100644 Documentation/devicetree/bindings/display/bridge/adi,adv7533.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt deleted file mode 100644 index 659523f538bf..000000000000 --- a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt +++ /dev/null @@ -1,143 +0,0 @@ -Analog Devices ADV7511(W)/13/33/35 HDMI Encoders ------------------------------------------------- - -The ADV7511, ADV7511W, ADV7513, ADV7533 and ADV7535 are HDMI audio and video -transmitters compatible with HDMI 1.4 and DVI 1.0. They support color space -conversion, S/PDIF, CEC and HDCP. ADV7533/5 supports the DSI interface for input -pixels, while the others support RGB interface. - -Required properties: - -- compatible: Should be one of: - "adi,adv7511" - "adi,adv7511w" - "adi,adv7513" - "adi,adv7533" - "adi,adv7535" - -- reg: I2C slave addresses - The ADV7511 internal registers are split into four pages exposed through - different I2C addresses, creating four register maps. Each map has it own - I2C address and acts as a standard slave device on the I2C bus. The main - address is mandatory, others are optional and revert to defaults if not - specified. - - -The ADV7511 supports a large number of input data formats that differ by their -color depth, color format, clock mode, bit justification and random -arrangement of components on the data bus. The combination of the following -properties describe the input and map directly to the video input tables of the -ADV7511 datasheet that document all the supported combinations. - -- adi,input-depth: Number of bits per color component at the input (8, 10 or - 12). -- adi,input-colorspace: The input color space, one of "rgb", "yuv422" or - "yuv444". -- adi,input-clock: The input clock type, one of "1x" (one clock cycle per - pixel), "2x" (two clock cycles per pixel), "ddr" (one clock cycle per pixel, - data driven on both edges). - -The following input format properties are required except in "rgb 1x" and -"yuv444 1x" modes, in which case they must not be specified. - -- adi,input-style: The input components arrangement variant (1, 2 or 3), as - listed in the input format tables in the datasheet. -- adi,input-justification: The input bit justification ("left", "evenly", - "right"). - -- avdd-supply: A 1.8V supply that powers up the AVDD pin on the chip. -- dvdd-supply: A 1.8V supply that powers up the DVDD pin on the chip. -- pvdd-supply: A 1.8V supply that powers up the PVDD pin on the chip. -- dvdd-3v-supply: A 3.3V supply that powers up the pin called DVDD_3V - on the chip. -- bgvdd-supply: A 1.8V supply that powers up the BGVDD pin. This is - needed only for ADV7511. - -The following properties are required for ADV7533 and ADV7535: - -- adi,dsi-lanes: Number of DSI data lanes connected to the DSI host. It should - be one of 1, 2, 3 or 4. -- a2vdd-supply: 1.8V supply that powers up the A2VDD pin on the chip. -- v3p3-supply: A 3.3V supply that powers up the V3P3 pin on the chip. -- v1p2-supply: A supply that powers up the V1P2 pin on the chip. It can be - either 1.2V or 1.8V for ADV7533 but only 1.8V for ADV7535. - -Optional properties: - -- interrupts: Specifier for the ADV7511 interrupt -- pd-gpios: Specifier for the GPIO connected to the power down signal - -- adi,clock-delay: Video data clock delay relative to the pixel clock, in ps - (-1200 ps .. 1600 ps). Defaults to no delay. -- adi,embedded-sync: The input uses synchronization signals embedded in the - data stream (similar to BT.656). Defaults to separate H/V synchronization - signals. -- adi,disable-timing-generator: Only for ADV7533 and ADV7535. 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". -- reg-names : Names of maps with programmable addresses. - It can contain any map needing a non-default address. - Possible maps names are : "main", "edid", "cec", "packet" - -Required nodes: - -The ADV7511 has two video ports. Their connections are modelled using the OF -graph bindings specified in Documentation/devicetree/bindings/graph.txt. - -- Video port 0 for the RGB, YUV or DSI input. In the case of ADV7533/5, the - remote endpoint phandle should be a reference to a valid mipi_dsi_host device - node. -- Video port 1 for the HDMI output -- Audio port 2 for the HDMI audio input - - -Example -------- - - adv7511w: hdmi@39 { - compatible = "adi,adv7511w"; - /* - * The EDID page will be accessible on address 0x66 on the I2C - * bus. All other maps continue to use their default addresses. - */ - reg = <0x39>, <0x66>; - reg-names = "main", "edid"; - interrupt-parent = <&gpio3>; - interrupts = <29 IRQ_TYPE_EDGE_FALLING>; - clocks = <&cec_clock>; - clock-names = "cec"; - - adi,input-depth = <8>; - adi,input-colorspace = "rgb"; - adi,input-clock = "1x"; - adi,input-style = <1>; - adi,input-justification = "evenly"; - - ports { - #address-cells = <1>; - #size-cells = <0>; - - port@0 { - reg = <0>; - adv7511w_in: endpoint { - remote-endpoint = <&dpi_out>; - }; - }; - - port@1 { - reg = <1>; - adv7511_out: endpoint { - remote-endpoint = <&hdmi_connector_in>; - }; - }; - - port@2 { - reg = <2>; - codec_endpoint: endpoint { - remote-endpoint = <&i2s0_cpu_endpoint>; - }; - }; - }; - }; diff --git a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.yaml b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.yaml new file mode 100644 index 000000000000..87f485ee2fb5 --- /dev/null +++ b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.yaml @@ -0,0 +1,241 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/bridge/adi,adv7511.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Analog Devices ADV7511/11W/13 HDMI Encoders + +maintainers: + - Laurent Pinchart + +description: | + The ADV7511, ADV7511W and ADV7513 are HDMI audio and video + transmitters compatible with HDMI 1.4 and DVI 1.0. They support color + space conversion, S/PDIF, CEC and HDCP. The transmitter input is + parallel RGB or YUV data. + +properties: + compatible: + enum: + - adi,adv7511 + - adi,adv7511w + - adi,adv7513 + + reg: + description: | + I2C slave addresses. + + The ADV7511/11W/13 internal registers are split into four pages + exposed through different I2C addresses, creating four register + maps. Each map has it own I2C address and acts as a standard slave + device on the I2C bus. The main address is mandatory, others are + optional and revert to defaults if not specified. + minItems: 1 + maxItems: 4 + + reg-names: + description: + Names of maps with programmable addresses. It can contain any map + needing a non-default address. + minItems: 1 + maxItems: 4 + items: + - const: main + - const: edid + - const: cec + - const: packet + + clocks: + description: Reference to the CEC clock. + maxItems: 1 + + clock-names: + const: cec + + interrupts: + maxItems: 1 + + pd-gpios: + description: GPIO connected to the power down signal. + maxItems: 1 + + avdd-supply: + description: A 1.8V supply that powers up the AVDD pin. + + dvdd-supply: + description: A 1.8V supply that powers up the DVDD pin. + + pvdd-supply: + description: A 1.8V supply that powers up the PVDD pin. + + dvdd-3v-supply: + description: A 3.3V supply that powers up the DVDD_3V pin. + + bgvdd-supply: + description: A 1.8V supply that powers up the BGVDD pin. + + adi,input-depth: + description: Number of bits per color component at the input. + allOf: + - $ref: /schemas/types.yaml#/definitions/uint32 + - enum: [ 8, 10, 12 ] + + adi,input-colorspace: + description: Input color space. + enum: [ rgb, yuv422, yuv444 ] + + adi,input-clock: + description: | + Input clock type. + "1x": one clock cycle per pixel + "2x": two clock cycles per pixel + "dd": one clock cycle per pixel, data driven on both edges + enum: [ 1x, 2x, dd ] + + adi,clock-delay: + description: + Video data clock delay relative to the pixel clock, in ps + (-1200ps .. 1600 ps). + $ref: /schemas/types.yaml#/definitions/uint32 + default: 0 + + adi,embedded-sync: + description: + If defined, the input uses synchronization signals embedded in the + data stream (similar to BT.656). + type: boolean + + adi,input-style: + description: + Input components arrangement variant as listed in the input + format tables in the datasheet. + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [ 1, 2, 3 ] + + adi,input-justification: + description: Input bit justification. + enum: [ left, evenly, right ] + + ports: + description: + The ADV7511(W)/13 has two video ports and one audio port. This node + models their connections as documented in + Documentation/devicetree/bindings/media/video-interfaces.txt + Documentation/devicetree/bindings/graph.txt + type: object + properties: + port@0: + description: Video port for the RGB or YUV input. + type: object + + port@1: + description: Video port for the HDMI output. + type: object + + port@2: + description: Audio port for the HDMI output. + type: object + +# adi,input-colorspace and adi,input-clock are required except in +# "rgb 1x" and "yuv444 1x" modes, in which case they must not be +# specified. +if: + not: + properties: + adi,input-colorspace: + contains: + enum: [ rgb, yuv444 ] + adi,input-clock: + contains: + const: 1x + +then: + required: + - adi,input-style + - adi,input-justification + +else: + properties: + adi,input-style: false + adi,input-justification: false + + +required: + - compatible + - reg + - ports + - adi,input-depth + - adi,input-colorspace + - adi,input-clock + - avdd-supply + - dvdd-supply + - pvdd-supply + - dvdd-3v-supply + - bgvdd-supply + +additionalProperties: false + +examples: + - | + #include + + i2c@e6500000 { + #address-cells = <1>; + #size-cells = <0>; + + reg = <0 0xe6500000>; + + adv7511w: hdmi@39 { + compatible = "adi,adv7511w"; + /* + * The EDID page will be accessible on address 0x66 on the I2C + * bus. All other maps continue to use their default addresses. + */ + reg = <0x39>, <0x66>; + reg-names = "main", "edid"; + interrupt-parent = <&gpio3>; + interrupts = <29 IRQ_TYPE_EDGE_FALLING>; + clocks = <&cec_clock>; + clock-names = "cec"; + avdd-supply = <&v1v8>; + dvdd-supply = <&v1v8>; + pvdd-supply = <&v1v8>; + dvdd-3v-supply = <&v3v3>; + bgvdd-supply = <&v1v8>; + + adi,input-depth = <8>; + adi,input-colorspace = "yuv422"; + adi,input-clock = "1x"; + + adi,input-style = <3>; + adi,input-justification = "right"; + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + adv7511w_in: endpoint { + remote-endpoint = <&dpi_out>; + }; + }; + + port@1 { + reg = <1>; + adv7511_out: endpoint { + remote-endpoint = <&hdmi_connector_in>; + }; + }; + + port@2 { + reg = <2>; + codec_endpoint: endpoint { + remote-endpoint = <&i2s0_cpu_endpoint>; + }; + }; + }; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/display/bridge/adi,adv7533.yaml b/Documentation/devicetree/bindings/display/bridge/adi,adv7533.yaml new file mode 100644 index 000000000000..f36209137c8a --- /dev/null +++ b/Documentation/devicetree/bindings/display/bridge/adi,adv7533.yaml @@ -0,0 +1,184 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/bridge/adi,adv7533.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Analog Devices ADV7533/35 HDMI Encoders + +maintainers: + - Laurent Pinchart + +description: | + The ADV7533 and ADV7535 are HDMI audio and video transmitters + compatible with HDMI 1.4 and DVI 1.0. They support color space + conversion, S/PDIF, CEC and HDCP. The transmitter input is MIPI DSI. + +properties: + compatible: + enum: + - adi,adv7533 + - adi,adv7535 + + reg: + description: | + I2C slave addresses. + + The ADV7533/35 internal registers are split into four pages + exposed through different I2C addresses, creating four register + maps. Each map has it own I2C address and acts as a standard slave + device on the I2C bus. The main address is mandatory, others are + optional and revert to defaults if not specified. + minItems: 1 + maxItems: 4 + + reg-names: + description: + Names of maps with programmable addresses. It can contain any map + needing a non-default address. + minItems: 1 + items: + - const: main + - const: edid + - const: cec + - const: packet + + clocks: + description: Reference to the CEC clock. + maxItems: 1 + + clock-names: + const: cec + + interrupts: + maxItems: 1 + + pd-gpios: + description: GPIO connected to the power down signal. + maxItems: 1 + + avdd-supply: + description: A 1.8V supply that powers up the AVDD pin. + + dvdd-supply: + description: A 1.8V supply that powers up the DVDD pin. + + pvdd-supply: + description: A 1.8V supply that powers up the PVDD pin. + + a2vdd-supply: + description: A 1.8V supply that powers up the A2VDD pin. + + v3p3-supply: + description: A 3.3V supply that powers up the V3P3 pin. + + v1p2-supply: + description: + A supply that powers up the V1P2 pin. It can be either 1.2V + or 1.8V for ADV7533 but only 1.8V for ADV7535. + + adi,disable-timing-generator: + description: + Disables the internal timing generator. The chip will rely on the + sync signals in the DSI data lanes, rather than generating its own + timings for HDMI output. + type: boolean + + adi,dsi-lanes: + description: Number of DSI data lanes connected to the DSI host. + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [ 1, 2, 3, 4 ] + + ports: + description: + The ADV7533/35 has two video ports and one audio port. This node + models their connections as documented in + Documentation/devicetree/bindings/media/video-interfaces.txt + Documentation/devicetree/bindings/graph.txt + type: object + properties: + port@0: + description: + Video port for the DSI input. The remote endpoint phandle + should be a reference to a valid mipi_dsi_host_device. + type: object + + port@1: + description: Video port for the HDMI output. + type: object + + port@2: + description: Audio port for the HDMI output. + type: object + +required: + - compatible + - reg + - ports + - adi,dsi-lanes + - avdd-supply + - dvdd-supply + - pvdd-supply + - a2vdd-supply + - v3p3-supply + +additionalProperties: false + +examples: + - | + #include + + i2c@e6500000 { + #address-cells = <1>; + #size-cells = <0>; + + reg = <0 0xe6500000>; + + adv7533: hdmi@39 { + compatible = "adi,adv7533"; + /* + * The EDID page will be accessible on address 0x66 on the I2C + * bus. All other maps continue to use their default addresses. + */ + reg = <0x39>, <0x66>; + reg-names = "main", "edid"; + interrupt-parent = <&gpio3>; + interrupts = <29 IRQ_TYPE_EDGE_FALLING>; + clocks = <&cec_clock>; + clock-names = "cec"; + adi,dsi-lanes = <4>; + avdd-supply = <&v1v8>; + dvdd-supply = <&v1v8>; + pvdd-supply = <&v1v8>; + a2vdd-supply = <&v1v8>; + v3p3-supply = <&v3v3>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + adv7533_in: endpoint { + remote-endpoint = <&dsi_out>; + }; + }; + + port@1 { + reg = <1>; + adv7533_out: endpoint { + remote-endpoint = <&hdmi_connector_in>; + }; + }; + + port@2 { + reg = <2>; + codec_endpoint: endpoint { + remote-endpoint = <&i2s0_cpu_endpoint>; + }; + }; + }; + }; + }; + +... -- cgit v1.2.3 From 3a0dc9fbe2b24a620e41d62cfe852e53b55f0bd8 Mon Sep 17 00:00:00 2001 From: Grzegorz Jaszczyk Date: Tue, 9 Feb 2021 15:46:06 +0200 Subject: Documentation/bindings: phy: update references to cp11x The cp11x references in dts has changed, reflect it in comphy documentation. Signed-off-by: Grzegorz Jaszczyk Signed-off-by: Konstantin Porotchkin Signed-off-by: Gregory CLEMENT --- Documentation/devicetree/bindings/phy/phy-mvebu-comphy.txt | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/phy/phy-mvebu-comphy.txt b/Documentation/devicetree/bindings/phy/phy-mvebu-comphy.txt index 8c60e6985950..5ffd0f55d010 100644 --- a/Documentation/devicetree/bindings/phy/phy-mvebu-comphy.txt +++ b/Documentation/devicetree/bindings/phy/phy-mvebu-comphy.txt @@ -42,22 +42,22 @@ Required properties (child nodes): Examples: - cpm_comphy: phy@120000 { + CP11X_LABEL(comphy): phy@120000 { compatible = "marvell,comphy-cp110"; reg = <0x120000 0x6000>; - marvell,system-controller = <&cpm_syscon0>; - clocks = <&CP110_LABEL(clk) 1 5>, <&CP110_LABEL(clk) 1 6>, - <&CP110_LABEL(clk) 1 18>; + marvell,system-controller = <&CP11X_LABEL(syscon0)>; + clocks = <&CP11X_LABEL(clk) 1 5>, <&CP11X_LABEL(clk) 1 6>, + <&CP11X_LABEL(clk) 1 18>; clock-names = "mg_clk", "mg_core_clk", "axi_clk"; #address-cells = <1>; #size-cells = <0>; - cpm_comphy0: phy@0 { + CP11X_LABEL(comphy0): phy@0 { reg = <0>; #phy-cells = <1>; }; - cpm_comphy1: phy@1 { + CP11X_LABEL(comphy1): phy@1 { reg = <1>; #phy-cells = <1>; }; -- cgit v1.2.3 From f38601368f4a0c2a9f859511768dc3957e2e1769 Mon Sep 17 00:00:00 2001 From: "Steven Rostedt (VMware)" Date: Thu, 17 Jun 2021 10:51:02 -0400 Subject: tracing: Add tp_printk_stop_on_boot option Add a kernel command line option that disables printing of events to console at late_initcall_sync(). This is useful when needing to see specific events written to console on boot up, but not wanting it when user space starts, as user space may make the console so noisy that the system becomes inoperable. Signed-off-by: Steven Rostedt (VMware) --- Documentation/admin-guide/kernel-parameters.txt | 13 +++++++++++++ 1 file changed, 13 insertions(+) (limited to 'Documentation') diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index cb89dbdedc46..0fcc725105cd 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -5605,12 +5605,25 @@ Note, echoing 1 into this file without the tracepoint_printk kernel cmdline option has no effect. + The tp_printk_stop_on_boot (see below) can also be used + to stop the printing of events to console at + late_initcall_sync. + ** CAUTION ** Having tracepoints sent to printk() and activating high frequency tracepoints such as irq or sched, can cause the system to live lock. + tp_printk_stop_on_boot[FTRACE] + When tp_printk (above) is set, it can cause a lot of noise + on the console. It may be useful to only include the + printing of events during boot up, as user space may + make the system inoperable. + + This command line option will stop the printing of events + to console at the late_initcall_sync() time frame. + traceoff_on_warning [FTRACE] enable this option to disable tracing when a warning is hit. This turns off "tracing_on". Tracing can -- cgit v1.2.3 From 531353e650db087e61ce84f8e6b7e0982c1dc1b0 Mon Sep 17 00:00:00 2001 From: Robin Murphy Date: Mon, 14 Jun 2021 15:57:26 +0100 Subject: iommu: Update "iommu.strict" documentation Consolidating the flush queue logic also meant that the "iommu.strict" option started taking effect on x86 as well. Make sure we document that. Fixes: a250c23f15c2 ("iommu: remove DOMAIN_ATTR_DMA_USE_FLUSH_QUEUE") Signed-off-by: Robin Murphy Reviewed-by: Lu Baolu Reviewed-by: John Garry Link: https://lore.kernel.org/r/2c8c06e1b449d6b060c5bf9ad3b403cd142f405d.1623682646.git.robin.murphy@arm.com Signed-off-by: Joerg Roedel --- Documentation/admin-guide/kernel-parameters.txt | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index cb89dbdedc46..20a32de990ed 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -1987,7 +1987,7 @@ forcing Dual Address Cycle for PCI cards supporting greater than 32-bit addressing. - iommu.strict= [ARM64] Configure TLB invalidation behaviour + iommu.strict= [ARM64, X86] Configure TLB invalidation behaviour Format: { "0" | "1" } 0 - Lazy mode. Request that DMA unmap operations use deferred @@ -1998,6 +1998,10 @@ 1 - Strict mode (default). DMA unmap operations invalidate IOMMU hardware TLBs synchronously. + Note: on x86, the default behaviour depends on the + equivalent driver-specific parameters, but a strict + mode explicitly specified by either method takes + precedence. iommu.passthrough= [ARM64, X86] Configure DMA to bypass the IOMMU by default. -- cgit v1.2.3 From d3121e64ad78ba944596d43d23914cf5f0131666 Mon Sep 17 00:00:00 2001 From: Andy Shevchenko Date: Wed, 16 Jun 2021 20:03:33 +0300 Subject: ACPI: sysfs: Allow bitmap list to be supplied to acpi_mask_gpe Currently we need to use as many acpi_mask_gpe options as we want to have GPEs to be masked. Even with two it already becomes inconveniently large the kernel command line. Instead, allow acpi_mask_gpe to represent bitmap list. Signed-off-by: Andy Shevchenko Signed-off-by: Rafael J. Wysocki --- 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 cb89dbdedc46..a161e58af5cc 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -113,7 +113,7 @@ the GPE dispatcher. This facility can be used to prevent such uncontrolled GPE floodings. - Format: + Format: or acpi_no_auto_serialize [HW,ACPI] Disable auto-serialization of AML methods -- cgit v1.2.3 From b10a038e84d188e15819058b2978b2daa9853aeb Mon Sep 17 00:00:00 2001 From: Ben Gardon Date: Tue, 18 May 2021 10:34:11 -0700 Subject: KVM: mmu: Add slots_arch_lock for memslot arch fields Add a new lock to protect the arch-specific fields of memslots if they need to be modified in a kvm->srcu read critical section. A future commit will use this lock to lazily allocate memslot rmaps for x86. Signed-off-by: Ben Gardon Message-Id: <20210518173414.450044-5-bgardon@google.com> [Add Documentation/ hunk. - Paolo] Signed-off-by: Paolo Bonzini --- Documentation/virt/kvm/locking.rst | 5 +++++ 1 file changed, 5 insertions(+) (limited to 'Documentation') diff --git a/Documentation/virt/kvm/locking.rst b/Documentation/virt/kvm/locking.rst index 1fc860c007a3..35eca377543d 100644 --- a/Documentation/virt/kvm/locking.rst +++ b/Documentation/virt/kvm/locking.rst @@ -16,6 +16,11 @@ The acquisition orders for mutexes are as follows: - kvm->slots_lock is taken outside kvm->irq_lock, though acquiring them together is quite rare. +- Unlike kvm->slots_lock, kvm->slots_arch_lock is released before + synchronize_srcu(&kvm->srcu). Therefore kvm->slots_arch_lock + can be taken inside a kvm->srcu read-side critical section, + while kvm->slots_lock cannot. + On x86: - vcpu->mutex is taken outside kvm->arch.hyperv.hv_lock -- cgit v1.2.3 From 644f706719f0297bc5f65c8891de1c32f042eae5 Mon Sep 17 00:00:00 2001 From: Vitaly Kuznetsov Date: Fri, 21 May 2021 11:51:36 +0200 Subject: KVM: x86: hyper-v: Introduce KVM_CAP_HYPERV_ENFORCE_CPUID Modeled after KVM_CAP_ENFORCE_PV_FEATURE_CPUID, the new capability allows for limiting Hyper-V features to those exposed to the guest in Hyper-V CPUIDs (0x40000003, 0x40000004, ...). Signed-off-by: Vitaly Kuznetsov Signed-off-by: Paolo Bonzini Message-Id: <20210521095204.2161214-3-vkuznets@redhat.com> Signed-off-by: Paolo Bonzini --- Documentation/virt/kvm/api.rst | 11 +++++++++++ 1 file changed, 11 insertions(+) (limited to 'Documentation') diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst index 7fcb2fd38f42..80154d5d98a1 100644 --- a/Documentation/virt/kvm/api.rst +++ b/Documentation/virt/kvm/api.rst @@ -6891,3 +6891,14 @@ This capability is always enabled. This capability indicates that the KVM virtual PTP service is supported in the host. A VMM can check whether the service is available to the guest on migration. + +8.33 KVM_CAP_HYPERV_ENFORCE_CPUID +----------------------------- + +Architectures: x86 + +When enabled, KVM will disable emulated Hyper-V features provided to the +guest according to the bits Hyper-V CPUID feature leaves. Otherwise, all +currently implmented Hyper-V features are provided unconditionally when +Hyper-V identification is set in the HYPERV_CPUID_INTERFACE (0x40000001) +leaf. -- cgit v1.2.3 From 6dba940352038b56db9b591b172fb2ec76a5fd5e Mon Sep 17 00:00:00 2001 From: Maxim Levitsky Date: Mon, 7 Jun 2021 12:02:02 +0300 Subject: KVM: x86: Introduce KVM_GET_SREGS2 / KVM_SET_SREGS2 This is a new version of KVM_GET_SREGS / KVM_SET_SREGS. It has the following changes: * Has flags for future extensions * Has vcpu's PDPTRs, allowing to save/restore them on migration. * Lacks obsolete interrupt bitmap (done now via KVM_SET_VCPU_EVENTS) New capability, KVM_CAP_SREGS2 is added to signal the userspace of this ioctl. Signed-off-by: Maxim Levitsky Message-Id: <20210607090203.133058-8-mlevitsk@redhat.com> Signed-off-by: Paolo Bonzini --- Documentation/virt/kvm/api.rst | 48 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 48 insertions(+) (limited to 'Documentation') diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst index 80154d5d98a1..cded99561adf 100644 --- a/Documentation/virt/kvm/api.rst +++ b/Documentation/virt/kvm/api.rst @@ -5034,6 +5034,54 @@ see KVM_XEN_VCPU_SET_ATTR above. The KVM_XEN_VCPU_ATTR_TYPE_RUNSTATE_ADJUST type may not be used with the KVM_XEN_VCPU_GET_ATTR ioctl. + +4.131 KVM_GET_SREGS2 +------------------ + +:Capability: KVM_CAP_SREGS2 +:Architectures: x86 +:Type: vcpu ioctl +:Parameters: struct kvm_sregs2 (out) +:Returns: 0 on success, -1 on error + +Reads special registers from the vcpu. +This ioctl (when supported) replaces the KVM_GET_SREGS. + +:: + +struct kvm_sregs2 { + /* out (KVM_GET_SREGS2) / in (KVM_SET_SREGS2) */ + struct kvm_segment cs, ds, es, fs, gs, ss; + struct kvm_segment tr, ldt; + struct kvm_dtable gdt, idt; + __u64 cr0, cr2, cr3, cr4, cr8; + __u64 efer; + __u64 apic_base; + __u64 flags; + __u64 pdptrs[4]; +}; + +flags values for ``kvm_sregs2``: + +``KVM_SREGS2_FLAGS_PDPTRS_VALID`` + + Indicates thats the struct contain valid PDPTR values. + + +4.132 KVM_SET_SREGS2 +------------------ + +:Capability: KVM_CAP_SREGS2 +:Architectures: x86 +:Type: vcpu ioctl +:Parameters: struct kvm_sregs2 (in) +:Returns: 0 on success, -1 on error + +Writes special registers into the vcpu. +See KVM_GET_SREGS2 for the data structures. +This ioctl (when supported) replaces the KVM_SET_SREGS. + + 5. The kvm_run structure ======================== -- cgit v1.2.3 From 01f1b6ed2b846ae124bb54c636ddadb4dd1813a3 Mon Sep 17 00:00:00 2001 From: Oleksandr Mazur Date: Wed, 16 Jun 2021 20:46:07 +0300 Subject: documentation: networking: devlink: fix prestera.rst formatting that causes build warnings Fixes: 66826c43e63d ("documentation: networking: devlink: add prestera switched driver Documentation") Signed-off-by: Oleksandr Mazur Signed-off-by: David S. Miller --- Documentation/networking/devlink/devlink-trap.rst | 1 + Documentation/networking/devlink/index.rst | 1 + Documentation/networking/devlink/prestera.rst | 4 ++-- 3 files changed, 4 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/networking/devlink/devlink-trap.rst b/Documentation/networking/devlink/devlink-trap.rst index 935b6397e8cf..ef8928c355df 100644 --- a/Documentation/networking/devlink/devlink-trap.rst +++ b/Documentation/networking/devlink/devlink-trap.rst @@ -497,6 +497,7 @@ drivers: * :doc:`netdevsim` * :doc:`mlxsw` + * :doc:`prestera` .. _Generic-Packet-Trap-Groups: diff --git a/Documentation/networking/devlink/index.rst b/Documentation/networking/devlink/index.rst index 8428a1220723..b3b9e0692088 100644 --- a/Documentation/networking/devlink/index.rst +++ b/Documentation/networking/devlink/index.rst @@ -46,3 +46,4 @@ parameters, info versions, and other features it supports. qed ti-cpsw-switch am65-nuss-cpsw-switch + prestera diff --git a/Documentation/networking/devlink/prestera.rst b/Documentation/networking/devlink/prestera.rst index e8b52ffd4707..49409d1d3081 100644 --- a/Documentation/networking/devlink/prestera.rst +++ b/Documentation/networking/devlink/prestera.rst @@ -1,8 +1,8 @@ .. SPDX-License-Identifier: GPL-2.0 -===================== +======================== prestera devlink support -===================== +======================== This document describes the devlink features implemented by the ``prestera`` device driver. -- cgit v1.2.3 From 0dbb11230437895f7cd6fc55da61cef011e997d8 Mon Sep 17 00:00:00 2001 From: Ashish Kalra Date: Tue, 8 Jun 2021 18:05:43 +0000 Subject: KVM: X86: Introduce KVM_HC_MAP_GPA_RANGE hypercall This hypercall is used by the SEV guest to notify a change in the page encryption status to the hypervisor. The hypercall should be invoked only when the encryption attribute is changed from encrypted -> decrypted and vice versa. By default all guest pages are considered encrypted. The hypercall exits to userspace to manage the guest shared regions and integrate with the userspace VMM's migration code. Cc: Thomas Gleixner Cc: Ingo Molnar Cc: "H. Peter Anvin" Cc: Paolo Bonzini Cc: Joerg Roedel Cc: Borislav Petkov Cc: Tom Lendacky Cc: x86@kernel.org Cc: kvm@vger.kernel.org Cc: linux-kernel@vger.kernel.org Reviewed-by: Steve Rutherford Signed-off-by: Brijesh Singh Signed-off-by: Ashish Kalra Co-developed-by: Sean Christopherson Signed-off-by: Sean Christopherson Co-developed-by: Paolo Bonzini Signed-off-by: Paolo Bonzini Message-Id: <90778988e1ee01926ff9cac447aacb745f954c8c.1623174621.git.ashish.kalra@amd.com> Signed-off-by: Paolo Bonzini --- Documentation/virt/kvm/api.rst | 19 +++++++++++++++++++ Documentation/virt/kvm/cpuid.rst | 7 +++++++ Documentation/virt/kvm/hypercalls.rst | 21 +++++++++++++++++++++ Documentation/virt/kvm/msr.rst | 13 +++++++++++++ 4 files changed, 60 insertions(+) (limited to 'Documentation') diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst index cded99561adf..e328caa35d6c 100644 --- a/Documentation/virt/kvm/api.rst +++ b/Documentation/virt/kvm/api.rst @@ -6950,3 +6950,22 @@ guest according to the bits Hyper-V CPUID feature leaves. Otherwise, all currently implmented Hyper-V features are provided unconditionally when Hyper-V identification is set in the HYPERV_CPUID_INTERFACE (0x40000001) leaf. + +8.34 KVM_CAP_EXIT_HYPERCALL +--------------------------- + +:Capability: KVM_CAP_EXIT_HYPERCALL +:Architectures: x86 +:Type: vm + +This capability, if enabled, will cause KVM to exit to userspace +with KVM_EXIT_HYPERCALL exit reason to process some hypercalls. + +Calling KVM_CHECK_EXTENSION for this capability will return a bitmask +of hypercalls that can be configured to exit to userspace. +Right now, the only such hypercall is KVM_HC_MAP_GPA_RANGE. + +The argument to KVM_ENABLE_CAP is also a bitmask, and must be a subset +of the result of KVM_CHECK_EXTENSION. KVM will forward to userspace +the hypercalls whose corresponding bit is in the argument, and return +ENOSYS for the others. diff --git a/Documentation/virt/kvm/cpuid.rst b/Documentation/virt/kvm/cpuid.rst index cf62162d4be2..bda3e3e737d7 100644 --- a/Documentation/virt/kvm/cpuid.rst +++ b/Documentation/virt/kvm/cpuid.rst @@ -96,6 +96,13 @@ KVM_FEATURE_MSI_EXT_DEST_ID 15 guest checks this feature bit before using extended destination ID bits in MSI address bits 11-5. +KVM_FEATURE_HC_MAP_GPA_RANGE 16 guest checks this feature bit before + using the map gpa range hypercall + to notify the page state change + +KVM_FEATURE_MIGRATION_CONTROL 17 guest checks this feature bit before + using MSR_KVM_MIGRATION_CONTROL + KVM_FEATURE_CLOCKSOURCE_STABLE_BIT 24 host will warn if no guest-side per-cpu warps are expected in kvmclock diff --git a/Documentation/virt/kvm/hypercalls.rst b/Documentation/virt/kvm/hypercalls.rst index ed4fddd364ea..e56fa8b9cfca 100644 --- a/Documentation/virt/kvm/hypercalls.rst +++ b/Documentation/virt/kvm/hypercalls.rst @@ -169,3 +169,24 @@ a0: destination APIC ID :Usage example: When sending a call-function IPI-many to vCPUs, yield if any of the IPI target vCPUs was preempted. + +8. KVM_HC_MAP_GPA_RANGE +------------------------- +:Architecture: x86 +:Status: active +:Purpose: Request KVM to map a GPA range with the specified attributes. + +a0: the guest physical address of the start page +a1: the number of (4kb) pages (must be contiguous in GPA space) +a2: attributes + + Where 'attributes' : + * bits 3:0 - preferred page size encoding 0 = 4kb, 1 = 2mb, 2 = 1gb, etc... + * bit 4 - plaintext = 0, encrypted = 1 + * bits 63:5 - reserved (must be zero) + +**Implementation note**: this hypercall is implemented in userspace via +the KVM_CAP_EXIT_HYPERCALL capability. Userspace must enable that capability +before advertising KVM_FEATURE_HC_MAP_GPA_RANGE in the guest CPUID. In +addition, if the guest supports KVM_FEATURE_MIGRATION_CONTROL, userspace +must also set up an MSR filter to process writes to MSR_KVM_MIGRATION_CONTROL. diff --git a/Documentation/virt/kvm/msr.rst b/Documentation/virt/kvm/msr.rst index e37a14c323d2..9315fc385fb0 100644 --- a/Documentation/virt/kvm/msr.rst +++ b/Documentation/virt/kvm/msr.rst @@ -376,3 +376,16 @@ data: write '1' to bit 0 of the MSR, this causes the host to re-scan its queue and check if there are more notifications pending. The MSR is available if KVM_FEATURE_ASYNC_PF_INT is present in CPUID. + +MSR_KVM_MIGRATION_CONTROL: + 0x4b564d08 + +data: + This MSR is available if KVM_FEATURE_MIGRATION_CONTROL is present in + CPUID. Bit 0 represents whether live migration of the guest is allowed. + + When a guest is started, bit 0 will be 0 if the guest has encrypted + memory and 1 if the guest does not have encrypted memory. If the + guest is communicating page encryption status to the host using the + ``KVM_HC_MAP_GPA_RANGE`` hypercall, it can set bit 0 in this MSR to + allow live migration of the guest. -- cgit v1.2.3 From ae1b2aaee7e215f985bf10aad8978f524d8dca60 Mon Sep 17 00:00:00 2001 From: Hao Chen Date: Thu, 17 Jun 2021 10:33:00 +0800 Subject: Documentation: ACPI: fix error script name The correct script name should be 'divergence.sh' instead of 'divergences.sh'. I didn't find divergences.sh in the path of acpica/generate/linux/. Signed-off-by: Hao Chen Link: https://lore.kernel.org/r/20210617023300.30114-1-chenhaoa@uniontech.com Signed-off-by: Jonathan Corbet --- Documentation/driver-api/acpi/linuxized-acpica.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/driver-api/acpi/linuxized-acpica.rst b/Documentation/driver-api/acpi/linuxized-acpica.rst index 6bee03383225..cc234353d2c4 100644 --- a/Documentation/driver-api/acpi/linuxized-acpica.rst +++ b/Documentation/driver-api/acpi/linuxized-acpica.rst @@ -276,4 +276,4 @@ before they become available from the ACPICA release process. # git clone https://github.com/acpica/acpica # git clone https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git # cd acpica - # generate/linux/divergences.sh -s ../linux + # generate/linux/divergence.sh -s ../linux -- cgit v1.2.3 From 349660e944b5bcb82df1dbb2156ced9fc9c05351 Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Wed, 16 Jun 2021 08:55:07 +0200 Subject: docs: admin-guide: reporting-issues.rst: replace some characters MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The conversion tools used during DocBook/LaTeX/html/Markdown->ReST conversion and some cut-and-pasted text contain some characters that aren't easily reachable on standard keyboards and/or could cause troubles when parsed by the documentation build system. Replace the occurences of the following characters: - U+00a0 (' '): NO-BREAK SPACE as it can cause lines being truncated on PDF output Signed-off-by: Mauro Carvalho Chehab Link: https://lore.kernel.org/r/551a2af0e654226067e5c376d3e2d959cc738f39.1623826294.git.mchehab+huawei@kernel.org Signed-off-by: Jonathan Corbet --- Documentation/admin-guide/reporting-issues.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/admin-guide/reporting-issues.rst b/Documentation/admin-guide/reporting-issues.rst index 18d8e25ba9df..d7ac13f789cc 100644 --- a/Documentation/admin-guide/reporting-issues.rst +++ b/Documentation/admin-guide/reporting-issues.rst @@ -1248,7 +1248,7 @@ paragraph makes the severeness obvious. In case you performed a successful bisection, use the title of the change that introduced the regression as the second part of your subject. Make the report -also mention the commit id of the culprit. In case of an unsuccessful bisection, +also mention the commit id of the culprit. In case of an unsuccessful bisection, make your report mention the latest tested version that's working fine (say 5.7) and the oldest where the issue occurs (say 5.8-rc1). -- cgit v1.2.3 From 90f40f514f907f0b12873a7337ea638731848ff2 Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Wed, 16 Jun 2021 08:55:08 +0200 Subject: docs: trace: coresight: coresight-etm4x-reference.rst: replace some characters MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The conversion tools used during DocBook/LaTeX/html/Markdown->ReST conversion and some cut-and-pasted text contain some characters that aren't easily reachable on standard keyboards and/or could cause troubles when parsed by the documentation build system. Replace the occurences of the following characters: - U+00a0 (' '): NO-BREAK SPACE as it can cause lines being truncated on PDF output Signed-off-by: Mauro Carvalho Chehab Link: https://lore.kernel.org/r/b6a04e881bc80a3c1d3d23ccbc8208ca3c9053fd.1623826294.git.mchehab+huawei@kernel.org Signed-off-by: Jonathan Corbet --- Documentation/trace/coresight/coresight-etm4x-reference.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/trace/coresight/coresight-etm4x-reference.rst b/Documentation/trace/coresight/coresight-etm4x-reference.rst index b64d9a9c79df..d25dfe86af9b 100644 --- a/Documentation/trace/coresight/coresight-etm4x-reference.rst +++ b/Documentation/trace/coresight/coresight-etm4x-reference.rst @@ -427,7 +427,7 @@ the ‘TRC’ prefix. :Syntax: ``echo idx > vmid_idx`` - Where idx <  numvmidc + Where idx < numvmidc ---- -- cgit v1.2.3 From f40c2a25b9c33b08ad2098f64b7d1cbaa3daab9f Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Wed, 16 Jun 2021 08:55:09 +0200 Subject: docs: driver-api: ioctl.rst: replace some characters MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The conversion tools used during DocBook/LaTeX/html/Markdown->ReST conversion and some cut-and-pasted text contain some characters that aren't easily reachable on standard keyboards and/or could cause troubles when parsed by the documentation build system. Replace the occurences of the following characters: - U+00a0 (' '): NO-BREAK SPACE as it can cause lines being truncated on PDF output Signed-off-by: Mauro Carvalho Chehab Link: https://lore.kernel.org/r/b2186e313f990488ded56d9b8d35a2d1fe479aa1.1623826294.git.mchehab+huawei@kernel.org Signed-off-by: Jonathan Corbet --- Documentation/driver-api/ioctl.rst | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/driver-api/ioctl.rst b/Documentation/driver-api/ioctl.rst index c455db0e1627..5b76e765827d 100644 --- a/Documentation/driver-api/ioctl.rst +++ b/Documentation/driver-api/ioctl.rst @@ -25,9 +25,9 @@ ioctl commands that follow modern conventions: ``_IO``, ``_IOR``, with the correct parameters: _IO/_IOR/_IOW/_IOWR - The macro name specifies how the argument will be used.  It may be a + The macro name specifies how the argument will be used. It may be a pointer to data to be passed into the kernel (_IOW), out of the kernel - (_IOR), or both (_IOWR).  _IO can indicate either commands with no + (_IOR), or both (_IOWR). _IO can indicate either commands with no argument or those passing an integer value instead of a pointer. It is recommended to only use _IO for commands without arguments, and use pointers for passing data. @@ -200,10 +200,10 @@ cause an information leak, which can be used to defeat kernel address space layout randomization (KASLR), helping in an attack. For this reason (and for compat support) it is best to avoid any -implicit padding in data structures.  Where there is implicit padding +implicit padding in data structures. Where there is implicit padding in an existing structure, kernel drivers must be careful to fully initialize an instance of the structure before copying it to user -space.  This is usually done by calling memset() before assigning to +space. This is usually done by calling memset() before assigning to individual members. Subsystem abstractions -- cgit v1.2.3 From 570eb861243c07f2c3923af428ed20cd3f9d0a29 Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Wed, 16 Jun 2021 08:55:10 +0200 Subject: docs: usb: replace some characters MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The conversion tools used during DocBook/LaTeX/html/Markdown->ReST conversion and some cut-and-pasted text contain some characters that aren't easily reachable on standard keyboards and/or could cause troubles when parsed by the documentation build system. Replace the occurences of the following characters: - U+feff (''): BOM as it is not needed on UTF-8 Signed-off-by: Mauro Carvalho Chehab Reviewed-by: Greg Kroah-Hartman Link: https://lore.kernel.org/r/0a4b0c38a9cd1133402a04a7ff60fefd9682d42e.1623826294.git.mchehab+huawei@kernel.org Signed-off-by: Jonathan Corbet --- Documentation/usb/ehci.rst | 2 +- Documentation/usb/gadget_printer.rst | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/usb/ehci.rst b/Documentation/usb/ehci.rst index 31f650e7c1b4..76190501907a 100644 --- a/Documentation/usb/ehci.rst +++ b/Documentation/usb/ehci.rst @@ -1,4 +1,4 @@ -=========== +=========== EHCI driver =========== diff --git a/Documentation/usb/gadget_printer.rst b/Documentation/usb/gadget_printer.rst index 5e5516c69075..e611a6d91093 100644 --- a/Documentation/usb/gadget_printer.rst +++ b/Documentation/usb/gadget_printer.rst @@ -1,4 +1,4 @@ -=============================== +=============================== Linux USB Printer Gadget Driver =============================== -- cgit v1.2.3 From 1a967a312270356c249466b10bb39890a96e301e Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Wed, 16 Jun 2021 08:55:11 +0200 Subject: docs: vm: zswap.rst: replace some characters MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The conversion tools used during DocBook/LaTeX/html/Markdown->ReST conversion and some cut-and-pasted text contain some characters that aren't easily reachable on standard keyboards and/or could cause troubles when parsed by the documentation build system. Replace the occurences of the following characters: - U+00a0 (' '): NO-BREAK SPACE as it can cause lines being truncated on PDF output Signed-off-by: Mauro Carvalho Chehab Link: https://lore.kernel.org/r/9a93b72f99f8f3328269076ceff50248ac9c5af5.1623826294.git.mchehab+huawei@kernel.org Signed-off-by: Jonathan Corbet --- Documentation/vm/zswap.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/vm/zswap.rst b/Documentation/vm/zswap.rst index d8d9fa4a1f0d..8edb8d578caf 100644 --- a/Documentation/vm/zswap.rst +++ b/Documentation/vm/zswap.rst @@ -10,7 +10,7 @@ Overview Zswap is a lightweight compressed cache for swap pages. It takes pages that are in the process of being swapped out and attempts to compress them into a dynamically allocated RAM-based memory pool. zswap basically trades CPU cycles -for potentially reduced swap I/O.  This trade-off can also result in a +for potentially reduced swap I/O. This trade-off can also result in a significant performance improvement if reads from the compressed cache are faster than reads from a swap device. @@ -26,7 +26,7 @@ faster than reads from a swap device. performance impact of swapping. * Overcommitted guests that share a common I/O resource can dramatically reduce their swap I/O pressure, avoiding heavy handed I/O - throttling by the hypervisor. This allows more work to get done with less + throttling by the hypervisor. This allows more work to get done with less impact to the guest workload and guests sharing the I/O subsystem * Users with SSDs as swap devices can extend the life of the device by drastically reducing life-shortening writes. -- cgit v1.2.3 From d9d2c82738b7cacefde30b701d2ddc4879f6c39a Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Wed, 16 Jun 2021 08:55:12 +0200 Subject: docs: filesystems: ext4: blockgroup.rst: replace some characters MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The conversion tools used during DocBook/LaTeX/html/Markdown->ReST conversion and some cut-and-pasted text contain some characters that aren't easily reachable on standard keyboards and/or could cause troubles when parsed by the documentation build system. Replace the occurences of the following characters: - U+2217 ('∗'): ASTERISK OPERATOR use ASCII asterisk instead of the ASTERISK OPERATOR Signed-off-by: Mauro Carvalho Chehab Acked-by: Theodore Ts'o Link: https://lore.kernel.org/r/c5c3c384c48779ca7c9dcd90183cefe20ac82928.1623826294.git.mchehab+huawei@kernel.org Signed-off-by: Jonathan Corbet --- Documentation/filesystems/ext4/blockgroup.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/filesystems/ext4/blockgroup.rst b/Documentation/filesystems/ext4/blockgroup.rst index 3da156633339..d5d652addce5 100644 --- a/Documentation/filesystems/ext4/blockgroup.rst +++ b/Documentation/filesystems/ext4/blockgroup.rst @@ -84,7 +84,7 @@ Without the option META\_BG, for safety concerns, all block group descriptors copies are kept in the first block group. Given the default 128MiB(2^27 bytes) block group size and 64-byte group descriptors, ext4 can have at most 2^27/64 = 2^21 block groups. This limits the entire -filesystem size to 2^21 ∗ 2^27 = 2^48bytes or 256TiB. +filesystem size to 2^21 * 2^27 = 2^48bytes or 256TiB. The solution to this problem is to use the metablock group feature (META\_BG), which is already in ext3 for all 2.6 releases. With the -- cgit v1.2.3 From 729979ebef22b7527ea377bb2814df97ad7d4078 Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Wed, 16 Jun 2021 08:55:13 +0200 Subject: docs: networking: device_drivers: replace some characters MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The conversion tools used during DocBook/LaTeX/html/Markdown->ReST conversion and some cut-and-pasted text contain some characters that aren't easily reachable on standard keyboards and/or could cause troubles when parsed by the documentation build system. Replace the occurences of the following characters: - U+00a0 (' '): NO-BREAK SPACE as it can cause lines being truncated on PDF output Reviewed-by: Jesse Brandeburg Signed-off-by: Mauro Carvalho Chehab Link: https://lore.kernel.org/r/9bd9f5c067c4b068a974730a14fe8d68e1be0c9a.1623826294.git.mchehab+huawei@kernel.org Signed-off-by: Jonathan Corbet --- Documentation/networking/device_drivers/ethernet/intel/i40e.rst | 6 +++--- Documentation/networking/device_drivers/ethernet/intel/iavf.rst | 2 +- 2 files changed, 4 insertions(+), 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/networking/device_drivers/ethernet/intel/i40e.rst b/Documentation/networking/device_drivers/ethernet/intel/i40e.rst index 2d3f6bd969a2..ac35bd472bdc 100644 --- a/Documentation/networking/device_drivers/ethernet/intel/i40e.rst +++ b/Documentation/networking/device_drivers/ethernet/intel/i40e.rst @@ -466,7 +466,7 @@ network. PTP support varies among Intel devices that support this driver. Use "ethtool -T " to get a definitive list of PTP capabilities supported by the device. -IEEE 802.1ad (QinQ) Support +IEEE 802.1ad (QinQ) Support --------------------------- The IEEE 802.1ad standard, informally known as QinQ, allows for multiple VLAN IDs within a single Ethernet frame. VLAN IDs are sometimes referred to as @@ -523,8 +523,8 @@ of a port's bandwidth (should it be available). The sum of all the values for Maximum Bandwidth is not restricted, because no more than 100% of a port's bandwidth can ever be used. -NOTE: X710/XXV710 devices fail to enable Max VFs (64) when Multiple Functions -per Port (MFP) and SR-IOV are enabled. An error from i40e is logged that says +NOTE: X710/XXV710 devices fail to enable Max VFs (64) when Multiple Functions +per Port (MFP) and SR-IOV are enabled. An error from i40e is logged that says "add vsi failed for VF N, aq_err 16". To workaround the issue, enable less than 64 virtual functions (VFs). diff --git a/Documentation/networking/device_drivers/ethernet/intel/iavf.rst b/Documentation/networking/device_drivers/ethernet/intel/iavf.rst index 25330b7b5168..151af0a8da9c 100644 --- a/Documentation/networking/device_drivers/ethernet/intel/iavf.rst +++ b/Documentation/networking/device_drivers/ethernet/intel/iavf.rst @@ -113,7 +113,7 @@ which the AVF is associated. The following are base mode features: - AVF device ID - HW mailbox is used for VF to PF communications (including on Windows) -IEEE 802.1ad (QinQ) Support +IEEE 802.1ad (QinQ) Support --------------------------- The IEEE 802.1ad standard, informally known as QinQ, allows for multiple VLAN IDs within a single Ethernet frame. VLAN IDs are sometimes referred to as -- cgit v1.2.3 From a557f67cd70344bf28442baac4c9b6c94aecb60b Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Wed, 16 Jun 2021 08:55:14 +0200 Subject: docs: PCI: Replace non-breaking spaces to avoid PDF issues MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The conversion tools used during DocBook/LaTeX/html/Markdown->ReST conversion and some cut-and-pasted text contain some characters that aren't easily reachable on standard keyboards and/or could cause troubles when parsed by the documentation build system. Replace the occurences of the following characters: - U+00a0 (' '): NO-BREAK SPACE as it can cause lines being truncated on PDF output Acked-by: Bjorn Helgaas Signed-off-by: Mauro Carvalho Chehab Link: https://lore.kernel.org/r/8036126a59adb720dbc9233341ad5a08531cf73f.1623826294.git.mchehab+huawei@kernel.org Signed-off-by: Jonathan Corbet --- Documentation/PCI/acpi-info.rst | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) (limited to 'Documentation') diff --git a/Documentation/PCI/acpi-info.rst b/Documentation/PCI/acpi-info.rst index 060217081c79..34c64a5a66ec 100644 --- a/Documentation/PCI/acpi-info.rst +++ b/Documentation/PCI/acpi-info.rst @@ -22,9 +22,9 @@ or if the device has INTx interrupts connected by platform interrupt controllers and a _PRT is needed to describe those connections. ACPI resource description is done via _CRS objects of devices in the ACPI -namespace [2].   The _CRS is like a generalized PCI BAR: the OS can read +namespace [2]. The _CRS is like a generalized PCI BAR: the OS can read _CRS and figure out what resource is being consumed even if it doesn't have -a driver for the device [3].  That's important because it means an old OS +a driver for the device [3]. That's important because it means an old OS can work correctly even on a system with new devices unknown to the OS. The new devices might not do anything, but the OS can at least make sure no resources conflict with them. @@ -41,15 +41,15 @@ ACPI, that device will have a specific _HID/_CID that tells the OS what driver to bind to it, and the _CRS tells the OS and the driver where the device's registers are. -PCI host bridges are PNP0A03 or PNP0A08 devices.  Their _CRS should -describe all the address space they consume.  This includes all the windows +PCI host bridges are PNP0A03 or PNP0A08 devices. Their _CRS should +describe all the address space they consume. This includes all the windows they forward down to the PCI bus, as well as registers of the host bridge -itself that are not forwarded to PCI.  The host bridge registers include +itself that are not forwarded to PCI. The host bridge registers include things like secondary/subordinate bus registers that determine the bus range below the bridge, window registers that describe the apertures, etc. These are all device-specific, non-architected things, so the only way a PNP0A03/PNP0A08 driver can manage them is via _PRS/_CRS/_SRS, which contain -the device-specific details.  The host bridge registers also include ECAM +the device-specific details. The host bridge registers also include ECAM space, since it is consumed by the host bridge. ACPI defines a Consumer/Producer bit to distinguish the bridge registers @@ -66,7 +66,7 @@ the PNP0A03/PNP0A08 device itself. The workaround was to describe the bridge registers (including ECAM space) in PNP0C02 catch-all devices [6]. With the exception of ECAM, the bridge register space is device-specific anyway, so the generic PNP0A03/PNP0A08 driver (pci_root.c) has no need to -know about it.   +know about it. New architectures should be able to use "Consumer" Extended Address Space descriptors in the PNP0A03 device for bridge registers, including ECAM, @@ -75,9 +75,9 @@ ia64 kernels assume all address space descriptors, including "Consumer" Extended Address Space ones, are windows, so it would not be safe to describe bridge registers this way on those architectures. -PNP0C02 "motherboard" devices are basically a catch-all.  There's no +PNP0C02 "motherboard" devices are basically a catch-all. There's no programming model for them other than "don't use these resources for -anything else."  So a PNP0C02 _CRS should claim any address space that is +anything else." So a PNP0C02 _CRS should claim any address space that is (1) not claimed by _CRS under any other device object in the ACPI namespace and (2) should not be assigned by the OS to something else. -- cgit v1.2.3 From 559a66b868d987dca55894218d11d59e5bafafe0 Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Wed, 16 Jun 2021 08:27:16 +0200 Subject: docs: devices.rst: better reference documentation docs There's no need to use either :file: or :doc: tags for documentation, as automarkup.py automatically converts Documentation/*.rst into a cross-reference. Signed-off-by: Mauro Carvalho Chehab Link: https://lore.kernel.org/r/5d9c9949a104d10b537a2d780bccad69a2dc58f9.1623824363.git.mchehab+huawei@kernel.org Signed-off-by: Jonathan Corbet --- Documentation/driver-api/pm/devices.rst | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/driver-api/pm/devices.rst b/Documentation/driver-api/pm/devices.rst index 6b3bfd29fd84..d448cb57df86 100644 --- a/Documentation/driver-api/pm/devices.rst +++ b/Documentation/driver-api/pm/devices.rst @@ -217,7 +217,7 @@ system-wide transition to a sleep state even though its :c:member:`runtime_auto` flag is clear. For more information about the runtime power management framework, refer to -:file:`Documentation/power/runtime_pm.rst`. +Documentation/power/runtime_pm.rst. Calling Drivers to Enter and Leave System Sleep States @@ -655,7 +655,7 @@ been thawed. Generally speaking, the PM notifiers are suitable for performing actions that either require user space to be available, or at least won't interfere with user space. -For details refer to :doc:`notifiers`. +For details refer to Documentation/driver-api/pm/notifiers.rst. Device Low-Power (suspend) States @@ -726,7 +726,7 @@ it into account in any way. Devices may be defined as IRQ-safe which indicates to the PM core that their runtime PM callbacks may be invoked with disabled interrupts (see -:file:`Documentation/power/runtime_pm.rst` for more information). If an +Documentation/power/runtime_pm.rst for more information). If an IRQ-safe device belongs to a PM domain, the runtime PM of the domain will be disallowed, unless the domain itself is defined as IRQ-safe. However, it makes sense to define a PM domain as IRQ-safe only if all the devices in it @@ -805,7 +805,7 @@ The ``DPM_FLAG_MAY_SKIP_RESUME`` Driver Flag -------------------------------------------- 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.rst`. +the full-power state, as explained in Documentation/power/runtime_pm.rst. [Refer to that document for more information regarding this particular issue as well as for information on the device runtime power management framework in general.] However, it often is desirable to leave devices in suspend after -- cgit v1.2.3 From 9129faf9040d9005e70c604a163faa9f183b00ee Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Wed, 16 Jun 2021 08:27:17 +0200 Subject: docs: dev-tools: kunit: don't use a table for docs name We'll be replacing :doc:`foo` references to Documentation/foo.rst. Yet, here it happens inside a table. Doing a search-and-replace would break it. Yet, as there's no good reason to use a table there, let's just convert it into a list. Reviewed-by: David Gow Acked-by: Brendan Higgins Signed-off-by: Mauro Carvalho Chehab Link: https://lore.kernel.org/r/07d3a8ccafbb6345d6e78fb090290859e84361a1.1623824363.git.mchehab+huawei@kernel.org Signed-off-by: Jonathan Corbet --- Documentation/dev-tools/kunit/api/index.rst | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/dev-tools/kunit/api/index.rst b/Documentation/dev-tools/kunit/api/index.rst index 9b9bffe5d41a..b33ad72bcf0b 100644 --- a/Documentation/dev-tools/kunit/api/index.rst +++ b/Documentation/dev-tools/kunit/api/index.rst @@ -10,7 +10,7 @@ API Reference This section documents the KUnit kernel testing API. It is divided into the following sections: -================================= ============================================== -:doc:`test` documents all of the standard testing API - excluding mocking or mocking related features. -================================= ============================================== +Documentation/dev-tools/kunit/api/test.rst + + - documents all of the standard testing API excluding mocking + or mocking related features. -- cgit v1.2.3 From 17420f3138b957e571144f337b866f8c7a7c1682 Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Wed, 16 Jun 2021 08:27:18 +0200 Subject: docs: admin-guide: pm: avoid using ReST :doc:`foo` markup The :doc:`foo` tag is auto-generated via automarkup.py. So, use the filename at the sources, instead of :doc:`foo`. Signed-off-by: Mauro Carvalho Chehab Link: https://lore.kernel.org/r/04616d9fc0b4a0d33486fa0018631a2db2eba860.1623824363.git.mchehab+huawei@kernel.org Signed-off-by: Jonathan Corbet --- Documentation/admin-guide/pm/intel_idle.rst | 16 ++++++++++------ Documentation/admin-guide/pm/intel_pstate.rst | 9 +++++---- 2 files changed, 15 insertions(+), 10 deletions(-) (limited to 'Documentation') diff --git a/Documentation/admin-guide/pm/intel_idle.rst b/Documentation/admin-guide/pm/intel_idle.rst index 89309e1b0e48..b799a43da62e 100644 --- a/Documentation/admin-guide/pm/intel_idle.rst +++ b/Documentation/admin-guide/pm/intel_idle.rst @@ -20,8 +20,8 @@ Nehalem and later generations of Intel processors, but the level of support for a particular processor model in it depends on whether or not it recognizes that processor model and may also depend on information coming from the platform firmware. [To understand ``intel_idle`` it is necessary to know how ``CPUIdle`` -works in general, so this is the time to get familiar with :doc:`cpuidle` if you -have not done that yet.] +works in general, so this is the time to get familiar with +Documentation/admin-guide/pm/cpuidle.rst if you have not done that yet.] ``intel_idle`` uses the ``MWAIT`` instruction to inform the processor that the logical CPU executing it is idle and so it may be possible to put some of the @@ -53,7 +53,8 @@ processor) corresponding to them depends on the processor model and it may also depend on the configuration of the platform. In order to create a list of available idle states required by the ``CPUIdle`` -subsystem (see :ref:`idle-states-representation` in :doc:`cpuidle`), +subsystem (see :ref:`idle-states-representation` in +Documentation/admin-guide/pm/cpuidle.rst), ``intel_idle`` can use two sources of information: static tables of idle states for different processor models included in the driver itself and the ACPI tables of the system. The former are always used if the processor model at hand is @@ -98,7 +99,8 @@ states may not be enabled by default if there are no matching entries in the preliminary list of idle states coming from the ACPI tables. In that case user space still can enable them later (on a per-CPU basis) with the help of the ``disable`` idle state attribute in ``sysfs`` (see -:ref:`idle-states-representation` in :doc:`cpuidle`). This basically means that +:ref:`idle-states-representation` in +Documentation/admin-guide/pm/cpuidle.rst). This basically means that the idle states "known" to the driver may not be enabled by default if they have not been exposed by the platform firmware (through the ACPI tables). @@ -186,7 +188,8 @@ be desirable. In practice, it is only really necessary to do that if the idle states in question cannot be enabled during system startup, because in the working state of the system the CPU power management quality of service (PM QoS) feature can be used to prevent ``CPUIdle`` from touching those idle states -even if they have been enumerated (see :ref:`cpu-pm-qos` in :doc:`cpuidle`). +even if they have been enumerated (see :ref:`cpu-pm-qos` in +Documentation/admin-guide/pm/cpuidle.rst). Setting ``max_cstate`` to 0 causes the ``intel_idle`` initialization to fail. The ``no_acpi`` and ``use_acpi`` module parameters (recognized by ``intel_idle`` @@ -202,7 +205,8 @@ Namely, the positions of the bits that are set in the ``states_off`` value are the indices of idle states to be disabled by default (as reflected by the names of the corresponding idle state directories in ``sysfs``, :file:`state0`, :file:`state1` ... :file:`state` ..., where ```` is the index of the given -idle state; see :ref:`idle-states-representation` in :doc:`cpuidle`). +idle state; see :ref:`idle-states-representation` in +Documentation/admin-guide/pm/cpuidle.rst). For example, if ``states_off`` is equal to 3, the driver will disable idle states 0 and 1 by default, and if it is equal to 8, idle state 3 will be diff --git a/Documentation/admin-guide/pm/intel_pstate.rst b/Documentation/admin-guide/pm/intel_pstate.rst index df29b4f1f219..7a7d4b041eac 100644 --- a/Documentation/admin-guide/pm/intel_pstate.rst +++ b/Documentation/admin-guide/pm/intel_pstate.rst @@ -18,8 +18,8 @@ General Information (``CPUFreq``). It is a scaling driver for the Sandy Bridge and later generations of Intel processors. Note, however, that some of those processors may not be supported. [To understand ``intel_pstate`` it is necessary to know -how ``CPUFreq`` works in general, so this is the time to read :doc:`cpufreq` if -you have not done that yet.] +how ``CPUFreq`` works in general, so this is the time to read +Documentation/admin-guide/pm/cpufreq.rst if you have not done that yet.] For the processors supported by ``intel_pstate``, the P-state concept is broader than just an operating frequency or an operating performance point (see the @@ -445,8 +445,9 @@ Interpretation of Policy Attributes ----------------------------------- The interpretation of some ``CPUFreq`` policy attributes described in -:doc:`cpufreq` is special with ``intel_pstate`` as the current scaling driver -and it generally depends on the driver's `operation mode `_. +Documentation/admin-guide/pm/cpufreq.rst is special with ``intel_pstate`` +as the current scaling driver and it generally depends on the driver's +`operation mode `_. First of all, the values of the ``cpuinfo_max_freq``, ``cpuinfo_min_freq`` and ``scaling_cur_freq`` attributes are produced by applying a processor-specific -- cgit v1.2.3 From e499f4c297e9136a579b4eaee75a3c6ba7172eac Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Wed, 16 Jun 2021 08:27:19 +0200 Subject: docs: admin-guide: hw-vuln: avoid using ReST :doc:`foo` markup The :doc:`foo` tag is auto-generated via automarkup.py. So, use the filename at the sources, instead of :doc:`foo`. Signed-off-by: Mauro Carvalho Chehab Link: https://lore.kernel.org/r/4e378517761f3df07165d5ecdac5a0a81577e68f.1623824363.git.mchehab+huawei@kernel.org Signed-off-by: Jonathan Corbet --- .../admin-guide/hw-vuln/special-register-buffer-data-sampling.rst | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/admin-guide/hw-vuln/special-register-buffer-data-sampling.rst b/Documentation/admin-guide/hw-vuln/special-register-buffer-data-sampling.rst index 3b1ce68d2456..966c9b3296ea 100644 --- a/Documentation/admin-guide/hw-vuln/special-register-buffer-data-sampling.rst +++ b/Documentation/admin-guide/hw-vuln/special-register-buffer-data-sampling.rst @@ -3,7 +3,8 @@ SRBDS - Special Register Buffer Data Sampling ============================================= -SRBDS is a hardware vulnerability that allows MDS :doc:`mds` techniques to +SRBDS is a hardware vulnerability that allows MDS +Documentation/admin-guide/hw-vuln/mds.rst techniques to infer values returned from special register accesses. Special register accesses are accesses to off core registers. According to Intel's evaluation, the special register reads that have a security expectation of privacy are -- cgit v1.2.3 From 2793e19d63275304da0359409a1f28b689df1ed8 Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Wed, 16 Jun 2021 08:27:20 +0200 Subject: docs: admin-guide: sysctl: avoid using ReST :doc:`foo` markup The :doc:`foo` tag is auto-generated via automarkup.py. So, use the filename at the sources, instead of :doc:`foo`. Signed-off-by: Mauro Carvalho Chehab Link: https://lore.kernel.org/r/12abd2290c7ebc05c89178d2556bea740bd70fac.1623824363.git.mchehab+huawei@kernel.org Signed-off-by: Jonathan Corbet --- Documentation/admin-guide/sysctl/abi.rst | 2 +- Documentation/admin-guide/sysctl/kernel.rst | 37 ++++++++++++++++------------- 2 files changed, 21 insertions(+), 18 deletions(-) (limited to 'Documentation') diff --git a/Documentation/admin-guide/sysctl/abi.rst b/Documentation/admin-guide/sysctl/abi.rst index 77b1d1b2ad42..4e6db0a2a4c0 100644 --- a/Documentation/admin-guide/sysctl/abi.rst +++ b/Documentation/admin-guide/sysctl/abi.rst @@ -11,7 +11,7 @@ Documentation for /proc/sys/abi/ Copyright (c) 2020, Stephen Kitt -For general info, see :doc:`index`. +For general info, see Documentation/admin-guide/sysctl/index.rst. ------------------------------------------------------------------------------ diff --git a/Documentation/admin-guide/sysctl/kernel.rst b/Documentation/admin-guide/sysctl/kernel.rst index c24f57f2c782..10df7fc6495f 100644 --- a/Documentation/admin-guide/sysctl/kernel.rst +++ b/Documentation/admin-guide/sysctl/kernel.rst @@ -9,7 +9,8 @@ Copyright (c) 1998, 1999, Rik van Riel Copyright (c) 2009, Shen Feng -For general info and legal blurb, please look in :doc:`index`. +For general info and legal blurb, please look in +Documentation/admin-guide/sysctl/index.rst. ------------------------------------------------------------------------------ @@ -54,7 +55,7 @@ free space valid for 30 seconds. acpi_video_flags ================ -See :doc:`/power/video`. This allows the video resume mode to be set, +See Documentation/power/video.rst. This allows the video resume mode to be set, in a similar fashion to the ``acpi_sleep`` kernel parameter, by combining the following values: @@ -89,7 +90,7 @@ is 0x15 and the full version number is 0x234, this file will contain the value 340 = 0x154. See the ``type_of_loader`` and ``ext_loader_type`` fields in -:doc:`/x86/boot` for additional information. +Documentation/x86/boot.rst for additional information. bootloader_version (x86 only) @@ -99,7 +100,7 @@ The complete bootloader version number. In the example above, this file will contain the value 564 = 0x234. See the ``type_of_loader`` and ``ext_loader_ver`` fields in -:doc:`/x86/boot` for additional information. +Documentation/x86/boot.rst for additional information. bpf_stats_enabled @@ -269,7 +270,7 @@ see the ``hostname(1)`` man page. firmware_config =============== -See :doc:`/driver-api/firmware/fallback-mechanisms`. +See Documentation/driver-api/firmware/fallback-mechanisms.rst. The entries in this directory allow the firmware loader helper fallback to be controlled: @@ -297,7 +298,7 @@ crashes and outputting them to a serial console. ftrace_enabled, stack_tracer_enabled ==================================== -See :doc:`/trace/ftrace`. +See Documentation/trace/ftrace.rst. hardlockup_all_cpu_backtrace @@ -325,7 +326,7 @@ when a hard lockup is detected. 1 Panic on hard lockup. = =========================== -See :doc:`/admin-guide/lockup-watchdogs` for more information. +See Documentation/admin-guide/lockup-watchdogs.rst for more information. This can also be set using the nmi_watchdog kernel parameter. @@ -586,7 +587,8 @@ in a KVM virtual machine. This default can be overridden by adding:: nmi_watchdog=1 -to the guest kernel command line (see :doc:`/admin-guide/kernel-parameters`). +to the guest kernel command line (see +Documentation/admin-guide/kernel-parameters.rst). numa_balancing @@ -1071,7 +1073,7 @@ that support this feature. real-root-dev ============= -See :doc:`/admin-guide/initrd`. +See Documentation/admin-guide/initrd.rst. reboot-cmd (SPARC only) @@ -1158,7 +1160,7 @@ will take effect. seccomp ======= -See :doc:`/userspace-api/seccomp_filter`. +See Documentation/userspace-api/seccomp_filter.rst. sg-big-buff @@ -1329,7 +1331,7 @@ the boot PROM. sysrq ===== -See :doc:`/admin-guide/sysrq`. +See Documentation/admin-guide/sysrq.rst. tainted @@ -1359,15 +1361,16 @@ ORed together. The letters are seen in "Tainted" line of Oops reports. 131072 `(T)` The kernel was built with the struct randomization plugin ====== ===== ============================================================== -See :doc:`/admin-guide/tainted-kernels` for more information. +See Documentation/admin-guide/tainted-kernels.rst for more information. Note: writes to this sysctl interface will fail with ``EINVAL`` if the kernel is booted with the command line option ``panic_on_taint=,nousertaint`` and any of the ORed together values being written to ``tainted`` match with the bitmask declared on panic_on_taint. - See :doc:`/admin-guide/kernel-parameters` for more details on that particular - kernel command line option and its optional ``nousertaint`` switch. + See Documentation/admin-guide/kernel-parameters.rst for more details on + that particular kernel command line option and its optional + ``nousertaint`` switch. threads-max =========== @@ -1391,7 +1394,7 @@ If a value outside of this range is written to ``threads-max`` an traceoff_on_warning =================== -When set, disables tracing (see :doc:`/trace/ftrace`) when a +When set, disables tracing (see Documentation/trace/ftrace.rst) when a ``WARN()`` is hit. @@ -1411,8 +1414,8 @@ will send them to printk() again. This only works if the kernel was booted with ``tp_printk`` enabled. -See :doc:`/admin-guide/kernel-parameters` and -:doc:`/trace/boottime-trace`. +See Documentation/admin-guide/kernel-parameters.rst and +Documentation/trace/boottime-trace.rst. .. _unaligned-dump-stack: -- cgit v1.2.3 From 4cd4bdf85c79a87a3510b2e729b074d97546ee52 Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Wed, 16 Jun 2021 08:27:21 +0200 Subject: docs: block: biodoc.rst: avoid using ReST :doc:`foo` markup The :doc:`foo` tag is auto-generated via automarkup.py. So, use the filename at the sources, instead of :doc:`foo`. Signed-off-by: Mauro Carvalho Chehab Link: https://lore.kernel.org/r/1d26256b305e02da82a6a990910a5b5fb9a0355e.1623824363.git.mchehab+huawei@kernel.org Signed-off-by: Jonathan Corbet --- Documentation/block/biodoc.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/block/biodoc.rst b/Documentation/block/biodoc.rst index 1d4d71e391af..2098477851a4 100644 --- a/Documentation/block/biodoc.rst +++ b/Documentation/block/biodoc.rst @@ -196,7 +196,7 @@ a virtual address mapping (unlike the earlier scheme of virtual address do not have a corresponding kernel virtual address space mapping) and low-memory pages. -Note: Please refer to :doc:`/core-api/dma-api-howto` for a discussion +Note: Please refer to Documentation/core-api/dma-api-howto.rst for a discussion on PCI high mem DMA aspects and mapping of scatter gather lists, and support for 64 bit PCI. -- cgit v1.2.3 From 6aadf740aab962702ef97cdba29877867cbc0e31 Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Wed, 16 Jun 2021 08:27:22 +0200 Subject: docs: bpf: bpf_lsm.rst: avoid using ReST :doc:`foo` markup The :doc:`foo` tag is auto-generated via automarkup.py. So, use the filename at the sources, instead of :doc:`foo`. Signed-off-by: Mauro Carvalho Chehab Link: https://lore.kernel.org/r/fcee73b9bb55a8d0efd07cf04076c66278a42db4.1623824363.git.mchehab+huawei@kernel.org Signed-off-by: Jonathan Corbet --- Documentation/bpf/bpf_lsm.rst | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) (limited to 'Documentation') diff --git a/Documentation/bpf/bpf_lsm.rst b/Documentation/bpf/bpf_lsm.rst index 1c0a75a51d79..0dc3fb0d9544 100644 --- a/Documentation/bpf/bpf_lsm.rst +++ b/Documentation/bpf/bpf_lsm.rst @@ -20,10 +20,10 @@ LSM hook: Other LSM hooks which can be instrumented can be found in ``include/linux/lsm_hooks.h``. -eBPF programs that use :doc:`/bpf/btf` do not need to include kernel headers -for accessing information from the attached eBPF program's context. They can -simply declare the structures in the eBPF program and only specify the fields -that need to be accessed. +eBPF programs that use Documentation/bpf/btf.rst do not need to include kernel +headers for accessing information from the attached eBPF program's context. +They can simply declare the structures in the eBPF program and only specify +the fields that need to be accessed. .. code-block:: c @@ -88,8 +88,9 @@ example: The ``__attribute__((preserve_access_index))`` is a clang feature that allows the BPF verifier to update the offsets for the access at runtime using the -:doc:`/bpf/btf` information. Since the BPF verifier is aware of the types, it -also validates all the accesses made to the various types in the eBPF program. +Documentation/bpf/btf.rst information. Since the BPF verifier is aware of the +types, it also validates all the accesses made to the various types in the +eBPF program. Loading ------- -- cgit v1.2.3 From a822b2ee266587c3665c471f0de86a3ccbc280b1 Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Wed, 16 Jun 2021 08:27:23 +0200 Subject: docs: core-api: avoid using ReST :doc:`foo` markup The :doc:`foo` tag is auto-generated via automarkup.py. So, use the filename at the sources, instead of :doc:`foo`. Signed-off-by: Mauro Carvalho Chehab Link: https://lore.kernel.org/r/d967d490b6655735b7df292f88859b5a1b07d0d7.1623824363.git.mchehab+huawei@kernel.org Signed-off-by: Jonathan Corbet --- Documentation/core-api/bus-virt-phys-mapping.rst | 2 +- Documentation/core-api/dma-api.rst | 5 +++-- Documentation/core-api/dma-isa-lpc.rst | 2 +- Documentation/core-api/index.rst | 4 ++-- 4 files changed, 7 insertions(+), 6 deletions(-) (limited to 'Documentation') diff --git a/Documentation/core-api/bus-virt-phys-mapping.rst b/Documentation/core-api/bus-virt-phys-mapping.rst index c7bc99cd2e21..c72b24a7d52c 100644 --- a/Documentation/core-api/bus-virt-phys-mapping.rst +++ b/Documentation/core-api/bus-virt-phys-mapping.rst @@ -8,7 +8,7 @@ How to access I/O mapped memory from within device drivers The virt_to_bus() and bus_to_virt() functions have been superseded by the functionality provided by the PCI DMA interface - (see :doc:`/core-api/dma-api-howto`). They continue + (see Documentation/core-api/dma-api-howto.rst). They continue to be documented below for historical purposes, but new code must not use them. --davidm 00/12/12 diff --git a/Documentation/core-api/dma-api.rst b/Documentation/core-api/dma-api.rst index 00a1d4fa3f9e..6d6d0edd2d27 100644 --- a/Documentation/core-api/dma-api.rst +++ b/Documentation/core-api/dma-api.rst @@ -5,7 +5,7 @@ Dynamic DMA mapping using the generic device :Author: James E.J. Bottomley This document describes the DMA API. For a more gentle introduction -of the API (and actual examples), see :doc:`/core-api/dma-api-howto`. +of the API (and actual examples), see Documentation/core-api/dma-api-howto.rst. This API is split into two pieces. Part I describes the basic API. Part II describes extensions for supporting non-consistent memory @@ -479,7 +479,8 @@ without the _attrs suffixes, except that they pass an optional dma_attrs. The interpretation of DMA attributes is architecture-specific, and -each attribute should be documented in :doc:`/core-api/dma-attributes`. +each attribute should be documented in +Documentation/core-api/dma-attributes.rst. If dma_attrs are 0, the semantics of each of these functions is identical to those of the corresponding function diff --git a/Documentation/core-api/dma-isa-lpc.rst b/Documentation/core-api/dma-isa-lpc.rst index e59a3d35a93d..17b193603f0a 100644 --- a/Documentation/core-api/dma-isa-lpc.rst +++ b/Documentation/core-api/dma-isa-lpc.rst @@ -17,7 +17,7 @@ To do ISA style DMA you need to include two headers:: #include The first is the generic DMA API used to convert virtual addresses to -bus addresses (see :doc:`/core-api/dma-api` for details). +bus addresses (see Documentation/core-api/dma-api.rst for details). The second contains the routines specific to ISA DMA transfers. Since this is not present on all platforms make sure you construct your diff --git a/Documentation/core-api/index.rst b/Documentation/core-api/index.rst index f1c9d20bd42d..5de2c7a4b1b3 100644 --- a/Documentation/core-api/index.rst +++ b/Documentation/core-api/index.rst @@ -48,7 +48,7 @@ Concurrency primitives ====================== How Linux keeps everything from happening at the same time. See -:doc:`/locking/index` for more related documentation. +Documentation/locking/index.rst for more related documentation. .. toctree:: :maxdepth: 1 @@ -77,7 +77,7 @@ Memory management ================= How to allocate and use memory in the kernel. Note that there is a lot -more memory-management documentation in :doc:`/vm/index`. +more memory-management documentation in Documentation/vm/index.rst. .. toctree:: :maxdepth: 1 -- cgit v1.2.3 From 3a8b57d27a19a341e8d6222630a2c532ef594c42 Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Wed, 16 Jun 2021 08:27:24 +0200 Subject: docs: dev-tools: testing-overview.rst: avoid using ReST :doc:`foo` markup The :doc:`foo` tag is auto-generated via automarkup.py. So, use the filename at the sources, instead of :doc:`foo`. Signed-off-by: Mauro Carvalho Chehab Link: https://lore.kernel.org/r/6bbecd4170ee08f36f8060b0719a46c64a21aefc.1623824363.git.mchehab+huawei@kernel.org Signed-off-by: Jonathan Corbet --- Documentation/dev-tools/testing-overview.rst | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) (limited to 'Documentation') diff --git a/Documentation/dev-tools/testing-overview.rst b/Documentation/dev-tools/testing-overview.rst index b5b46709969c..65feb81edb14 100644 --- a/Documentation/dev-tools/testing-overview.rst +++ b/Documentation/dev-tools/testing-overview.rst @@ -71,15 +71,15 @@ can be used to verify that a test is executing particular functions or lines of code. This is useful for determining how much of the kernel is being tested, and for finding corner-cases which are not covered by the appropriate test. -:doc:`gcov` is GCC's coverage testing tool, which can be used with the kernel -to get global or per-module coverage. Unlike KCOV, it does not record per-task -coverage. Coverage data can be read from debugfs, and interpreted using the -usual gcov tooling. - -:doc:`kcov` is a feature which can be built in to the kernel to allow -capturing coverage on a per-task level. It's therefore useful for fuzzing and -other situations where information about code executed during, for example, a -single syscall is useful. +Documentation/dev-tools/gcov.rst is GCC's coverage testing tool, which can be +used with the kernel to get global or per-module coverage. Unlike KCOV, it +does not record per-task coverage. Coverage data can be read from debugfs, +and interpreted using the usual gcov tooling. + +Documentation/dev-tools/kcov.rst is a feature which can be built in to the +kernel to allow capturing coverage on a per-task level. It's therefore useful +for fuzzing and other situations where information about code executed during, +for example, a single syscall is useful. Dynamic Analysis Tools -- cgit v1.2.3 From 654a5bd0eadbef5f7196215b755dcecd965f11c1 Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Wed, 16 Jun 2021 08:27:25 +0200 Subject: docs: dev-tools: kunit: avoid using ReST :doc:`foo` markup The :doc:`foo` tag is auto-generated via automarkup.py. So, use the filename at the sources, instead of :doc:`foo`. Reviewed-by: David Gow Acked-by: Brendan Higgins Signed-off-by: Mauro Carvalho Chehab Link: https://lore.kernel.org/r/6fde409079959a95b62b9b2692503608d7ff0dbd.1623824363.git.mchehab+huawei@kernel.org Signed-off-by: Jonathan Corbet --- Documentation/dev-tools/kunit/faq.rst | 2 +- Documentation/dev-tools/kunit/index.rst | 14 +++++++------- Documentation/dev-tools/kunit/start.rst | 4 ++-- Documentation/dev-tools/kunit/tips.rst | 5 +++-- Documentation/dev-tools/kunit/usage.rst | 8 +++++--- 5 files changed, 18 insertions(+), 15 deletions(-) (limited to 'Documentation') diff --git a/Documentation/dev-tools/kunit/faq.rst b/Documentation/dev-tools/kunit/faq.rst index 8d5029ad210a..5c6555d020f3 100644 --- a/Documentation/dev-tools/kunit/faq.rst +++ b/Documentation/dev-tools/kunit/faq.rst @@ -97,7 +97,7 @@ things to try. modules will automatically execute associated tests when loaded. Test results can be collected from ``/sys/kernel/debug/kunit//results``, and can be parsed with ``kunit.py parse``. For more details, see "KUnit on - non-UML architectures" in :doc:`usage`. + non-UML architectures" in Documentation/dev-tools/kunit/usage.rst. If none of the above tricks help, you are always welcome to email any issues to kunit-dev@googlegroups.com. diff --git a/Documentation/dev-tools/kunit/index.rst b/Documentation/dev-tools/kunit/index.rst index 848478838347..25d92a9a05ea 100644 --- a/Documentation/dev-tools/kunit/index.rst +++ b/Documentation/dev-tools/kunit/index.rst @@ -36,7 +36,7 @@ To make running these tests (and reading the results) easier, KUnit offers results. This provides a quick way of running KUnit tests during development, without requiring a virtual machine or separate hardware. -Get started now: :doc:`start` +Get started now: Documentation/dev-tools/kunit/start.rst Why KUnit? ========== @@ -88,9 +88,9 @@ it takes to read their test log? How do I use it? ================ -* :doc:`start` - for new users of KUnit -* :doc:`tips` - for short examples of best practices -* :doc:`usage` - for a more detailed explanation of KUnit features -* :doc:`api/index` - for the list of KUnit APIs used for testing -* :doc:`kunit-tool` - for more information on the kunit_tool helper script -* :doc:`faq` - for answers to some common questions about KUnit +* Documentation/dev-tools/kunit/start.rst - for new users of KUnit +* Documentation/dev-tools/kunit/tips.rst - for short examples of best practices +* Documentation/dev-tools/kunit/usage.rst - for a more detailed explanation of KUnit features +* Documentation/dev-tools/kunit/api/index.rst - for the list of KUnit APIs used for testing +* Documentation/dev-tools/kunit/kunit-tool.rst - for more information on the kunit_tool helper script +* Documentation/dev-tools/kunit/faq.rst - for answers to some common questions about KUnit diff --git a/Documentation/dev-tools/kunit/start.rst b/Documentation/dev-tools/kunit/start.rst index 0e65cabe08eb..63ef7b625c13 100644 --- a/Documentation/dev-tools/kunit/start.rst +++ b/Documentation/dev-tools/kunit/start.rst @@ -21,7 +21,7 @@ The wrapper can be run with: ./tools/testing/kunit/kunit.py run For more information on this wrapper (also called kunit_tool) check out the -:doc:`kunit-tool` page. +Documentation/dev-tools/kunit/kunit-tool.rst page. Creating a .kunitconfig ----------------------- @@ -234,7 +234,7 @@ Congrats! You just wrote your first KUnit test! Next Steps ========== -* Check out the :doc:`tips` page for tips on +* Check out the Documentation/dev-tools/kunit/tips.rst page for tips on writing idiomatic KUnit tests. * Optional: see the :doc:`usage` page for a more in-depth explanation of KUnit. diff --git a/Documentation/dev-tools/kunit/tips.rst b/Documentation/dev-tools/kunit/tips.rst index 8d8c238f7f79..492d2ded2f5a 100644 --- a/Documentation/dev-tools/kunit/tips.rst +++ b/Documentation/dev-tools/kunit/tips.rst @@ -125,7 +125,8 @@ Here's a slightly in-depth example of how one could implement "mocking": Note: here we're able to get away with using ``test->priv``, but if you wanted -something more flexible you could use a named ``kunit_resource``, see :doc:`api/test`. +something more flexible you could use a named ``kunit_resource``, see +Documentation/dev-tools/kunit/api/test.rst. Failing the current test ------------------------ @@ -185,5 +186,5 @@ Alternatively, one can take full control over the error message by using ``KUNIT Next Steps ========== -* Optional: see the :doc:`usage` page for a more +* Optional: see the Documentation/dev-tools/kunit/usage.rst page for a more in-depth explanation of KUnit. diff --git a/Documentation/dev-tools/kunit/usage.rst b/Documentation/dev-tools/kunit/usage.rst index 650f99590df5..3ee7ab91f712 100644 --- a/Documentation/dev-tools/kunit/usage.rst +++ b/Documentation/dev-tools/kunit/usage.rst @@ -10,7 +10,7 @@ understand it. This guide assumes a working knowledge of the Linux kernel and some basic knowledge of testing. For a high level introduction to KUnit, including setting up KUnit for your -project, see :doc:`start`. +project, see Documentation/dev-tools/kunit/start.rst. Organization of this document ============================= @@ -99,7 +99,8 @@ violated; however, the test will continue running, potentially trying other expectations until the test case ends or is otherwise terminated. This is as opposed to *assertions* which are discussed later. -To learn about more expectations supported by KUnit, see :doc:`api/test`. +To learn about more expectations supported by KUnit, see +Documentation/dev-tools/kunit/api/test.rst. .. note:: A single test case should be pretty short, pretty easy to understand, @@ -216,7 +217,8 @@ test suite in a special linker section so that it can be run by KUnit either after late_init, or when the test module is loaded (depending on whether the test was built in or not). -For more information on these types of things see the :doc:`api/test`. +For more information on these types of things see the +Documentation/dev-tools/kunit/api/test.rst. Common Patterns =============== -- cgit v1.2.3 From 6dce82b28a93492af7a817b2b3166aaf775e4aba Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Wed, 16 Jun 2021 08:27:26 +0200 Subject: docs: devicetree: bindings: submitting-patches.rst: avoid using ReST :doc:`foo` markup The :doc:`foo` tag is auto-generated via automarkup.py. So, use the filename at the sources, instead of :doc:`foo`. Signed-off-by: Mauro Carvalho Chehab Link: https://lore.kernel.org/r/0048c23d47b582dd1a1959628fd2b895209ac826.1623824363.git.mchehab+huawei@kernel.org Signed-off-by: Jonathan Corbet --- Documentation/devicetree/bindings/submitting-patches.rst | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/submitting-patches.rst b/Documentation/devicetree/bindings/submitting-patches.rst index 104fa8fb2c17..8087780f1685 100644 --- a/Documentation/devicetree/bindings/submitting-patches.rst +++ b/Documentation/devicetree/bindings/submitting-patches.rst @@ -7,8 +7,8 @@ Submitting Devicetree (DT) binding patches I. For patch submitters ======================= - 0) Normal patch submission rules from Documentation/process/submitting-patches.rst - applies. + 0) Normal patch submission rules from + Documentation/process/submitting-patches.rst applies. 1) The Documentation/ and include/dt-bindings/ portion of the patch should be a separate patch. The preferred subject prefix for binding patches is:: @@ -25,8 +25,8 @@ I. For patch submitters make dt_binding_check - See Documentation/devicetree/bindings/writing-schema.rst for more details about - schema and tools setup. + See Documentation/devicetree/bindings/writing-schema.rst for more details + about schema and tools setup. 3) DT binding files should be dual licensed. The preferred license tag is (GPL-2.0-only OR BSD-2-Clause). @@ -84,7 +84,8 @@ II. For kernel maintainers III. Notes ========== - 0) Please see :doc:`ABI` for details regarding devicetree ABI. + 0) Please see Documentation/devicetree/bindings/ABI.rst for details + regarding devicetree ABI. 1) This document is intended as a general familiarization with the process as decided at the 2013 Kernel Summit. When in doubt, the current word of the -- cgit v1.2.3 From fd88d2e598dcd13807ecabfc6e1170d2c0ab830a Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Wed, 16 Jun 2021 08:27:27 +0200 Subject: docs: doc-guide: avoid using ReST :doc:`foo` markup The :doc:`foo` tag is auto-generated via automarkup.py. So, use the filename at the sources, instead of :doc:`foo`. Signed-off-by: Mauro Carvalho Chehab Link: https://lore.kernel.org/r/d6cbe5183406e3378ed4bd0f84f4bcf85a15009c.1623824363.git.mchehab+huawei@kernel.org Signed-off-by: Jonathan Corbet --- Documentation/doc-guide/contributing.rst | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/doc-guide/contributing.rst b/Documentation/doc-guide/contributing.rst index 67ee3691f91f..207fd93d7c80 100644 --- a/Documentation/doc-guide/contributing.rst +++ b/Documentation/doc-guide/contributing.rst @@ -237,10 +237,10 @@ We have been trying to improve the situation through the creation of a set of "books" that group documentation for specific readers. These include: - - :doc:`../admin-guide/index` - - :doc:`../core-api/index` - - :doc:`../driver-api/index` - - :doc:`../userspace-api/index` + - Documentation/admin-guide/index.rst + - Documentation/core-api/index.rst + - Documentation/driver-api/index.rst + - Documentation/userspace-api/index.rst As well as this book on documentation itself. -- cgit v1.2.3 From 29602b7c1ecc4a4692e903ac85b09d6b79e0e57d Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Wed, 16 Jun 2021 08:27:28 +0200 Subject: docs: driver-api: avoid using ReST :doc:`foo` markup The :doc:`foo` tag is auto-generated via automarkup.py. So, use the filename at the sources, instead of :doc:`foo`. Signed-off-by: Mauro Carvalho Chehab Link: https://lore.kernel.org/r/095b04bff6d49b4097382398bb91102eaa3f0fd3.1623824363.git.mchehab+huawei@kernel.org Signed-off-by: Jonathan Corbet --- Documentation/driver-api/ioctl.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/driver-api/ioctl.rst b/Documentation/driver-api/ioctl.rst index 5b76e765827d..35795f6a151a 100644 --- a/Documentation/driver-api/ioctl.rst +++ b/Documentation/driver-api/ioctl.rst @@ -34,7 +34,7 @@ _IO/_IOR/_IOW/_IOWR type An 8-bit number, often a character literal, specific to a subsystem - or driver, and listed in :doc:`../userspace-api/ioctl/ioctl-number` + or driver, and listed in Documentation/userspace-api/ioctl/ioctl-number.rst nr An 8-bit number identifying the specific command, unique for a give -- cgit v1.2.3 From 85aa9afd7bf1b239480dd73d5535978b99300fe7 Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Wed, 16 Jun 2021 08:27:29 +0200 Subject: docs: driver-api: gpio: using-gpio.rst: avoid using ReST :doc:`foo` markup The :doc:`foo` tag is auto-generated via automarkup.py. So, use the filename at the sources, instead of :doc:`foo`. Reviewed-by: Linus Walleij Signed-off-by: Mauro Carvalho Chehab Link: https://lore.kernel.org/r/506a41353937c455c2e79b5960b0976edc8aa9e9.1623824363.git.mchehab+huawei@kernel.org Signed-off-by: Jonathan Corbet --- Documentation/driver-api/gpio/using-gpio.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/driver-api/gpio/using-gpio.rst b/Documentation/driver-api/gpio/using-gpio.rst index dda069444032..64c8d3f76c3a 100644 --- a/Documentation/driver-api/gpio/using-gpio.rst +++ b/Documentation/driver-api/gpio/using-gpio.rst @@ -9,13 +9,13 @@ with them. For examples of already existing generic drivers that will also be good examples for any other kernel drivers you want to author, refer to -:doc:`drivers-on-gpio` +Documentation/driver-api/gpio/drivers-on-gpio.rst For any kind of mass produced system you want to support, such as servers, laptops, phones, tablets, routers, and any consumer or office or business goods using appropriate kernel drivers is paramount. Submit your code for inclusion in the upstream Linux kernel when you feel it is mature enough and you will get -help to refine it, see :doc:`../../process/submitting-patches`. +help to refine it, see Documentation/process/submitting-patches.rst. In Linux GPIO lines also have a userspace ABI. -- cgit v1.2.3 From bbbaf2264db0f0a29d69e3690df67348d95f1cb3 Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Wed, 16 Jun 2021 08:27:30 +0200 Subject: docs: driver-api: surface_aggregator: avoid using ReST :doc:`foo` markup The :doc:`foo` tag is auto-generated via automarkup.py. So, use the filename at the sources, instead of :doc:`foo`. Acked-by: Maximilian Luz Signed-off-by: Mauro Carvalho Chehab Link: https://lore.kernel.org/r/6097027b4de4c9015485cb73b297b98660c4296d.1623824363.git.mchehab+huawei@kernel.org Signed-off-by: Jonathan Corbet --- .../driver-api/surface_aggregator/clients/index.rst | 3 ++- Documentation/driver-api/surface_aggregator/internal.rst | 15 ++++++++------- Documentation/driver-api/surface_aggregator/overview.rst | 6 ++++-- 3 files changed, 14 insertions(+), 10 deletions(-) (limited to 'Documentation') diff --git a/Documentation/driver-api/surface_aggregator/clients/index.rst b/Documentation/driver-api/surface_aggregator/clients/index.rst index 98ea9946b8a2..30160513afa5 100644 --- a/Documentation/driver-api/surface_aggregator/clients/index.rst +++ b/Documentation/driver-api/surface_aggregator/clients/index.rst @@ -5,7 +5,8 @@ Client Driver Documentation =========================== This is the documentation for client drivers themselves. Refer to -:doc:`../client` for documentation on how to write client drivers. +Documentation/driver-api/surface_aggregator/client.rst for documentation +on how to write client drivers. .. toctree:: :maxdepth: 1 diff --git a/Documentation/driver-api/surface_aggregator/internal.rst b/Documentation/driver-api/surface_aggregator/internal.rst index 72704734982a..8c7c80c9f418 100644 --- a/Documentation/driver-api/surface_aggregator/internal.rst +++ b/Documentation/driver-api/surface_aggregator/internal.rst @@ -87,10 +87,11 @@ native SSAM devices, i.e. devices that are not defined in ACPI and not implemented as platform devices, via |ssam_device| and |ssam_device_driver| simplify management of client devices and client drivers. -Refer to :doc:`client` for documentation regarding the client device/driver -API and interface options for other kernel drivers. It is recommended to -familiarize oneself with that chapter and the :doc:`ssh` before continuing -with the architectural overview below. +Refer to Documentation/driver-api/surface_aggregator/client.rst for +documentation regarding the client device/driver API and interface options +for other kernel drivers. It is recommended to familiarize oneself with +that chapter and the Documentation/driver-api/surface_aggregator/ssh.rst +before continuing with the architectural overview below. Packet Transport Layer @@ -190,9 +191,9 @@ with success on the transmitter thread. Transmission of sequenced packets is limited by the number of concurrently pending packets, i.e. a limit on how many packets may be waiting for an ACK -from the EC in parallel. This limit is currently set to one (see :doc:`ssh` -for the reasoning behind this). Control packets (i.e. ACK and NAK) can -always be transmitted. +from the EC in parallel. This limit is currently set to one (see +Documentation/driver-api/surface_aggregator/ssh.rst for the reasoning behind +this). Control packets (i.e. ACK and NAK) can always be transmitted. Receiver Thread --------------- diff --git a/Documentation/driver-api/surface_aggregator/overview.rst b/Documentation/driver-api/surface_aggregator/overview.rst index 1e9d57e50063..26415e1ab7da 100644 --- a/Documentation/driver-api/surface_aggregator/overview.rst +++ b/Documentation/driver-api/surface_aggregator/overview.rst @@ -73,5 +73,7 @@ being a direct response to a previous request. We may also refer to requests without response as commands. In general, events need to be enabled via one of multiple dedicated requests before they are sent by the EC. -See :doc:`ssh` for a more technical protocol documentation and -:doc:`internal` for an overview of the internal driver architecture. +See Documentation/driver-api/surface_aggregator/ssh.rst for a +more technical protocol documentation and +Documentation/driver-api/surface_aggregator/internal.rst for an +overview of the internal driver architecture. -- cgit v1.2.3 From ab8e8da694d4921252c2dd3fecbd2ab64eaf0eb2 Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Wed, 16 Jun 2021 08:27:31 +0200 Subject: docs: driver-api: usb: avoid using ReST :doc:`foo` markup The :doc:`foo` tag is auto-generated via automarkup.py. So, use the filename at the sources, instead of :doc:`foo`. Signed-off-by: Mauro Carvalho Chehab Link: https://lore.kernel.org/r/2cd2dc3e6bacde587aeb09a3951594cfb0102014.1623824363.git.mchehab+huawei@kernel.org Signed-off-by: Jonathan Corbet --- Documentation/driver-api/usb/dma.rst | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/driver-api/usb/dma.rst b/Documentation/driver-api/usb/dma.rst index 2b3dbd3265b4..d32c27e11b90 100644 --- a/Documentation/driver-api/usb/dma.rst +++ b/Documentation/driver-api/usb/dma.rst @@ -10,7 +10,7 @@ API overview The big picture is that USB drivers can continue to ignore most DMA issues, though they still must provide DMA-ready buffers (see -:doc:`/core-api/dma-api-howto`). That's how they've worked through +Documentation/core-api/dma-api-howto.rst). That's how they've worked through the 2.4 (and earlier) kernels, or they can now be DMA-aware. DMA-aware usb drivers: @@ -60,7 +60,7 @@ and effects like cache-trashing can impose subtle penalties. force a consistent memory access ordering by using memory barriers. It's not using a streaming DMA mapping, so it's good for small transfers on systems where the I/O would otherwise thrash an IOMMU mapping. (See - :doc:`/core-api/dma-api-howto` for definitions of "coherent" and + Documentation/core-api/dma-api-howto.rst for definitions of "coherent" and "streaming" DMA mappings.) Asking for 1/Nth of a page (as well as asking for N pages) is reasonably @@ -91,7 +91,7 @@ Working with existing buffers Existing buffers aren't usable for DMA without first being mapped into the DMA address space of the device. However, most buffers passed to your driver can safely be used with such DMA mapping. (See the first section -of :doc:`/core-api/dma-api-howto`, titled "What memory is DMA-able?") +of Documentation/core-api/dma-api-howto.rst, titled "What memory is DMA-able?") - When you're using scatterlists, you can map everything at once. On some systems, this kicks in an IOMMU and turns the scatterlists into single -- cgit v1.2.3 From 4d361d6cc74512308beac8997e4b66d5231e8bfe Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Wed, 16 Jun 2021 08:27:32 +0200 Subject: docs: firmware-guide: acpi: avoid using ReST :doc:`foo` markup The :doc:`foo` tag is auto-generated via automarkup.py. So, use the filename at the sources, instead of :doc:`foo`. Signed-off-by: Mauro Carvalho Chehab Reviewed-by: Sakari Ailus Link: https://lore.kernel.org/r/7162043c18f1ea96c446b332400e44e8087ba142.1623824363.git.mchehab+huawei@kernel.org Signed-off-by: Jonathan Corbet --- Documentation/firmware-guide/acpi/dsd/data-node-references.rst | 3 ++- Documentation/firmware-guide/acpi/dsd/graph.rst | 2 +- Documentation/firmware-guide/acpi/enumeration.rst | 7 ++++--- 3 files changed, 7 insertions(+), 5 deletions(-) (limited to 'Documentation') diff --git a/Documentation/firmware-guide/acpi/dsd/data-node-references.rst b/Documentation/firmware-guide/acpi/dsd/data-node-references.rst index 9b17dc77d18c..b7ad47df49de 100644 --- a/Documentation/firmware-guide/acpi/dsd/data-node-references.rst +++ b/Documentation/firmware-guide/acpi/dsd/data-node-references.rst @@ -79,7 +79,8 @@ the ANOD object which is also the final target node of the reference. }) } -Please also see a graph example in :doc:`graph`. +Please also see a graph example in +Documentation/firmware-guide/acpi/dsd/graph.rst. References ========== diff --git a/Documentation/firmware-guide/acpi/dsd/graph.rst b/Documentation/firmware-guide/acpi/dsd/graph.rst index 7072db801aeb..4341299aa937 100644 --- a/Documentation/firmware-guide/acpi/dsd/graph.rst +++ b/Documentation/firmware-guide/acpi/dsd/graph.rst @@ -174,4 +174,4 @@ References referenced 2016-10-04. [7] _DSD Device Properties Usage Rules. - :doc:`../DSD-properties-rules` + Documentation/firmware-guide/acpi/DSD-properties-rules.rst diff --git a/Documentation/firmware-guide/acpi/enumeration.rst b/Documentation/firmware-guide/acpi/enumeration.rst index 9f0d5c854fa4..18074eb71860 100644 --- a/Documentation/firmware-guide/acpi/enumeration.rst +++ b/Documentation/firmware-guide/acpi/enumeration.rst @@ -339,8 +339,8 @@ a code like this:: There are also devm_* versions of these functions which release the descriptors once the device is released. -See Documentation/firmware-guide/acpi/gpio-properties.rst for more information about the -_DSD binding related to GPIOs. +See Documentation/firmware-guide/acpi/gpio-properties.rst for more information +about the _DSD binding related to GPIOs. MFD devices =========== @@ -460,7 +460,8 @@ the _DSD of the device object itself or the _DSD of its ancestor in the Otherwise, the _DSD itself is regarded as invalid and therefore the "compatible" property returned by it is meaningless. -Refer to :doc:`DSD-properties-rules` for more information. +Refer to Documentation/firmware-guide/acpi/DSD-properties-rules.rst for more +information. PCI hierarchy representation ============================ -- cgit v1.2.3 From 25edd3a1625f76ac2265f3357550a782bd2ac7ff Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Wed, 16 Jun 2021 08:27:33 +0200 Subject: docs: i2c: avoid using ReST :doc:`foo` markup The :doc:`foo` tag is auto-generated via automarkup.py. So, use the filename at the sources, instead of :doc:`foo`. Acked-by: Wolfram Sang Signed-off-by: Mauro Carvalho Chehab Link: https://lore.kernel.org/r/569722e3f7d73d746c145ea78d2b4fbe5defee90.1623824363.git.mchehab+huawei@kernel.org Signed-off-by: Jonathan Corbet --- Documentation/i2c/instantiating-devices.rst | 2 +- Documentation/i2c/old-module-parameters.rst | 3 ++- Documentation/i2c/smbus-protocol.rst | 4 ++-- 3 files changed, 5 insertions(+), 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/i2c/instantiating-devices.rst b/Documentation/i2c/instantiating-devices.rst index e558e0a77e0c..890c9360ce19 100644 --- a/Documentation/i2c/instantiating-devices.rst +++ b/Documentation/i2c/instantiating-devices.rst @@ -59,7 +59,7 @@ Declare the I2C devices via ACPI ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ACPI can also describe I2C devices. There is special documentation for this -which is currently located at :doc:`../firmware-guide/acpi/enumeration`. +which is currently located at Documentation/firmware-guide/acpi/enumeration.rst. Declare the I2C devices in board files diff --git a/Documentation/i2c/old-module-parameters.rst b/Documentation/i2c/old-module-parameters.rst index 38e55829dee8..b08b6daabce9 100644 --- a/Documentation/i2c/old-module-parameters.rst +++ b/Documentation/i2c/old-module-parameters.rst @@ -17,7 +17,8 @@ address), ``force`` (to forcibly attach the driver to a given device) and With the conversion of the I2C subsystem to the standard device driver binding model, it became clear that these per-module parameters were no longer needed, and that a centralized implementation was possible. The new, -sysfs-based interface is described in :doc:`instantiating-devices`, section +sysfs-based interface is described in +Documentation/i2c/instantiating-devices.rst, section "Method 4: Instantiate from user-space". Below is a mapping from the old module parameters to the new interface. diff --git a/Documentation/i2c/smbus-protocol.rst b/Documentation/i2c/smbus-protocol.rst index 64689d19dd51..9e07e6bbe6a3 100644 --- a/Documentation/i2c/smbus-protocol.rst +++ b/Documentation/i2c/smbus-protocol.rst @@ -27,8 +27,8 @@ a different protocol operation entirely. Each transaction type corresponds to a functionality flag. Before calling a transaction function, a device driver should always check (just once) for the corresponding functionality flag to ensure that the underlying I2C -adapter supports the transaction in question. See :doc:`functionality` for -the details. +adapter supports the transaction in question. See +Documentation/i2c/functionality.rst for the details. Key to symbols -- cgit v1.2.3 From 7f3f7bfbbe02cdfeacf9375c73fd33787554bf8f Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Wed, 16 Jun 2021 08:27:34 +0200 Subject: docs: kernel-hacking: hacking.rst: avoid using ReST :doc:`foo` markup The :doc:`foo` tag is auto-generated via automarkup.py. So, use the filename at the sources, instead of :doc:`foo`. Signed-off-by: Mauro Carvalho Chehab Link: https://lore.kernel.org/r/9537b74d897fab13552535d79337060a3b241b8c.1623824363.git.mchehab+huawei@kernel.org Signed-off-by: Jonathan Corbet --- Documentation/kernel-hacking/hacking.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/kernel-hacking/hacking.rst b/Documentation/kernel-hacking/hacking.rst index 451523424942..df65c19aa7df 100644 --- a/Documentation/kernel-hacking/hacking.rst +++ b/Documentation/kernel-hacking/hacking.rst @@ -601,7 +601,7 @@ Defined in ``include/linux/export.h`` This is the variant of `EXPORT_SYMBOL()` that allows specifying a symbol namespace. Symbol Namespaces are documented in -:doc:`../core-api/symbol-namespaces` +Documentation/core-api/symbol-namespaces.rst :c:func:`EXPORT_SYMBOL_NS_GPL()` -------------------------------- @@ -610,7 +610,7 @@ Defined in ``include/linux/export.h`` This is the variant of `EXPORT_SYMBOL_GPL()` that allows specifying a symbol namespace. Symbol Namespaces are documented in -:doc:`../core-api/symbol-namespaces` +Documentation/core-api/symbol-namespaces.rst Routines and Conventions ======================== -- cgit v1.2.3 From 8d4a0adc9cab0d2a5643bacfd42cd64d1f09ae09 Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Wed, 16 Jun 2021 08:27:35 +0200 Subject: docs: networking: devlink: avoid using ReST :doc:`foo` markup The :doc:`foo` tag is auto-generated via automarkup.py. So, use the filename at the sources, instead of :doc:`foo`. Signed-off-by: Mauro Carvalho Chehab Link: https://lore.kernel.org/r/4553858bc9a5442eba6d71caff8047e84ece4d9b.1623824363.git.mchehab+huawei@kernel.org Signed-off-by: Jonathan Corbet --- Documentation/networking/devlink/devlink-region.rst | 2 +- Documentation/networking/devlink/devlink-trap.rst | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/networking/devlink/devlink-region.rst b/Documentation/networking/devlink/devlink-region.rst index 3654c3e9658f..58fe95e9a49d 100644 --- a/Documentation/networking/devlink/devlink-region.rst +++ b/Documentation/networking/devlink/devlink-region.rst @@ -22,7 +22,7 @@ The major benefit to creating a region is to provide access to internal address regions that are otherwise inaccessible to the user. Regions may also be used to provide an additional way to debug complex error -states, but see also :doc:`devlink-health` +states, but see also Documentation/networking/devlink/devlink-health.rst Regions may optionally support capturing a snapshot on demand via the ``DEVLINK_CMD_REGION_NEW`` netlink message. A driver wishing to allow diff --git a/Documentation/networking/devlink/devlink-trap.rst b/Documentation/networking/devlink/devlink-trap.rst index 935b6397e8cf..efa5f7f42c88 100644 --- a/Documentation/networking/devlink/devlink-trap.rst +++ b/Documentation/networking/devlink/devlink-trap.rst @@ -495,8 +495,8 @@ help debug packet drops caused by these exceptions. The following list includes links to the description of driver-specific traps registered by various device drivers: - * :doc:`netdevsim` - * :doc:`mlxsw` + * Documentation/networking/devlink/netdevsim.rst + * Documentation/networking/devlink/mlxsw.rst .. _Generic-Packet-Trap-Groups: -- cgit v1.2.3 From e5424f0aec76abd6567e844fbd9a0eb7d138374b Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Wed, 16 Jun 2021 08:27:36 +0200 Subject: docs: PCI: endpoint: pci-endpoint-cfs.rst: avoid using ReST :doc:`foo` markup The :doc:`foo` tag is auto-generated via automarkup.py. So, use the filename at the sources, instead of :doc:`foo`. Acked-by: Bjorn Helgaas Signed-off-by: Mauro Carvalho Chehab Link: https://lore.kernel.org/r/4b18febe4a4f030dd9d43e5e6a2a0aa28bd5b734.1623824363.git.mchehab+huawei@kernel.org Signed-off-by: Jonathan Corbet --- Documentation/PCI/endpoint/pci-endpoint-cfs.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/PCI/endpoint/pci-endpoint-cfs.rst b/Documentation/PCI/endpoint/pci-endpoint-cfs.rst index 696f8eeb4738..db609b97ad58 100644 --- a/Documentation/PCI/endpoint/pci-endpoint-cfs.rst +++ b/Documentation/PCI/endpoint/pci-endpoint-cfs.rst @@ -125,4 +125,4 @@ all the EPF devices are created and linked with the EPC device. | interrupt_pin | function -[1] :doc:`pci-endpoint` +[1] Documentation/PCI/endpoint/pci-endpoint.rst -- cgit v1.2.3 From bffbae6d19edc72a408cdbe915d482be0c91e047 Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Wed, 16 Jun 2021 08:27:37 +0200 Subject: docs: PCI: pci.rst: avoid using ReST :doc:`foo` markup The :doc:`foo` tag is auto-generated via automarkup.py. So, use the filename at the sources, instead of :doc:`foo`. Signed-off-by: Mauro Carvalho Chehab Acked-by: Bjorn Helgaas Link: https://lore.kernel.org/r/8697cf945390f6b45fefb4c5fe22ed1c8070e32e.1623824363.git.mchehab+huawei@kernel.org Signed-off-by: Jonathan Corbet --- Documentation/PCI/pci.rst | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/PCI/pci.rst b/Documentation/PCI/pci.rst index 814b40f8360b..fa651e25d98c 100644 --- a/Documentation/PCI/pci.rst +++ b/Documentation/PCI/pci.rst @@ -265,7 +265,7 @@ Set the DMA mask size --------------------- .. note:: If anything below doesn't make sense, please refer to - :doc:`/core-api/dma-api`. This section is just a reminder that + Documentation/core-api/dma-api.rst. This section is just a reminder that drivers need to indicate DMA capabilities of the device and is not an authoritative source for DMA interfaces. @@ -291,7 +291,7 @@ Many 64-bit "PCI" devices (before PCI-X) and some PCI-X devices are Setup shared control data ------------------------- Once the DMA masks are set, the driver can allocate "consistent" (a.k.a. shared) -memory. See :doc:`/core-api/dma-api` for a full description of +memory. See Documentation/core-api/dma-api.rst for a full description of the DMA APIs. This section is just a reminder that it needs to be done before enabling DMA on the device. @@ -421,7 +421,7 @@ owners if there is one. Then clean up "consistent" buffers which contain the control data. -See :doc:`/core-api/dma-api` for details on unmapping interfaces. +See Documentation/core-api/dma-api.rst for details on unmapping interfaces. Unregister from other subsystems -- cgit v1.2.3 From 9912d0bb9deeaa4b0680a94fbdaa3ae31e891c1b Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Wed, 16 Jun 2021 08:27:38 +0200 Subject: docs: process: submitting-patches.rst: avoid using ReST :doc:`foo` markup The :doc:`foo` tag is auto-generated via automarkup.py. So, use the filename at the sources, instead of :doc:`foo`. Signed-off-by: Mauro Carvalho Chehab Link: https://lore.kernel.org/r/d172ab629c3e32c8d27ed4b9d2a209933e2a7178.1623824363.git.mchehab+huawei@kernel.org Signed-off-by: Jonathan Corbet --- Documentation/process/submitting-patches.rst | 32 +++++++++++++--------------- 1 file changed, 15 insertions(+), 17 deletions(-) (limited to 'Documentation') diff --git a/Documentation/process/submitting-patches.rst b/Documentation/process/submitting-patches.rst index c66a19201deb..0852bcf73630 100644 --- a/Documentation/process/submitting-patches.rst +++ b/Documentation/process/submitting-patches.rst @@ -10,10 +10,11 @@ can greatly increase the chances of your change being accepted. This document contains a large number of suggestions in a relatively terse format. For detailed information on how the kernel development process -works, see :doc:`development-process`. Also, read :doc:`submit-checklist` +works, see Documentation/process/development-process.rst. Also, read +Documentation/process/submit-checklist.rst for a list of items to check before submitting code. If you are submitting -a driver, also read :doc:`submitting-drivers`; for device tree binding patches, -read :doc:`submitting-patches`. +a driver, also read Documentation/process/submitting-drivers.rst; for device +tree binding patches, read Documentation/process/submitting-patches.rst. This documentation assumes that you're using ``git`` to prepare your patches. If you're unfamiliar with ``git``, you would be well-advised to learn how to @@ -178,8 +179,7 @@ Style-check your changes ------------------------ Check your patch for basic style violations, details of which can be -found in -:ref:`Documentation/process/coding-style.rst `. +found in Documentation/process/coding-style.rst. Failure to do so simply wastes the reviewers time and will get your patch rejected, probably without even being read. @@ -238,7 +238,7 @@ If you have a patch that fixes an exploitable security bug, send that patch to security@kernel.org. For severe bugs, a short embargo may be considered to allow distributors to get the patch out to users; in such cases, obviously, the patch should not be sent to any public lists. See also -:doc:`/admin-guide/security-bugs`. +Documentation/admin-guide/security-bugs.rst. Patches that fix a severe bug in a released kernel should be directed toward the stable maintainers by putting a line like this:: @@ -246,9 +246,8 @@ toward the stable maintainers by putting a line like this:: Cc: stable@vger.kernel.org into the sign-off area of your patch (note, NOT an email recipient). You -should also read -:ref:`Documentation/process/stable-kernel-rules.rst ` -in addition to this file. +should also read Documentation/process/stable-kernel-rules.rst +in addition to this document. If changes affect userland-kernel interfaces, please send the MAN-PAGES maintainer (as listed in the MAINTAINERS file) a man-pages patch, or at @@ -305,8 +304,8 @@ decreasing the likelihood of your MIME-attached change being accepted. Exception: If your mailer is mangling patches then someone may ask you to re-send them using MIME. -See :doc:`/process/email-clients` for hints about configuring your e-mail -client so that it sends your patches untouched. +See Documentation/process/email-clients.rst for hints about configuring +your e-mail client so that it sends your patches untouched. Respond to review comments -------------------------- @@ -324,7 +323,7 @@ for their time. Code review is a tiring and time-consuming process, and reviewers sometimes get grumpy. Even in that case, though, respond politely and address the problems they have pointed out. -See :doc:`email-clients` for recommendations on email +See Documentation/process/email-clients.rst for recommendations on email clients and mailing list etiquette. @@ -562,10 +561,10 @@ method for indicating a bug fixed by the patch. See :ref:`describe_changes` for more details. Note: Attaching a Fixes: tag does not subvert the stable kernel rules -process nor the requirement to Cc: stable@vger.kernel.org on all stable +process nor the requirement to Cc: stable@vger.kernel.org on all stable patch candidates. For more information, please read -:ref:`Documentation/process/stable-kernel-rules.rst ` - +Documentation/process/stable-kernel-rules.rst. + .. _the_canonical_patch_format: The canonical patch format @@ -824,8 +823,7 @@ Greg Kroah-Hartman, "How to piss off a kernel subsystem maintainer". NO!!!! No more huge patch bombs to linux-kernel@vger.kernel.org people! -Kernel Documentation/process/coding-style.rst: - :ref:`Documentation/process/coding-style.rst ` +Kernel Documentation/process/coding-style.rst Linus Torvalds's mail on the canonical patch format: -- cgit v1.2.3 From d3122273bd852f532c0d4632b7ade1b11953873d Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Wed, 16 Jun 2021 08:27:39 +0200 Subject: docs: security: landlock.rst: avoid using ReST :doc:`foo` markup The :doc:`foo` tag is auto-generated via automarkup.py. So, use the filename at the sources, instead of :doc:`foo`. Signed-off-by: Mauro Carvalho Chehab Link: https://lore.kernel.org/r/9174021ef2c87f395a4cc0895a4b2f7fd97db626.1623824363.git.mchehab+huawei@kernel.org Signed-off-by: Jonathan Corbet --- Documentation/security/landlock.rst | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/security/landlock.rst b/Documentation/security/landlock.rst index 2e84925ae971..3df68cb1d10f 100644 --- a/Documentation/security/landlock.rst +++ b/Documentation/security/landlock.rst @@ -25,7 +25,8 @@ Any user can enforce Landlock rulesets on their processes. They are merged and evaluated according to the inherited ones in a way that ensures that only more constraints can be added. -User space documentation can be found here: :doc:`/userspace-api/landlock`. +User space documentation can be found here: +Documentation/userspace-api/landlock.rst. Guiding principles for safe access controls =========================================== -- cgit v1.2.3 From e480336c25d3dbdfdc5d18225b6f26804369ddba Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Wed, 16 Jun 2021 08:27:40 +0200 Subject: docs: trace: coresight: coresight.rst: avoid using ReST :doc:`foo` markup The :doc:`foo` tag is auto-generated via automarkup.py. So, use the filename at the sources, instead of :doc:`foo`. Signed-off-by: Mauro Carvalho Chehab Reviewed-by: Mathieu Poirier Link: https://lore.kernel.org/r/c79be625f7c90468e13d5380f0e4e1c1ccfa2fc8.1623824363.git.mchehab+huawei@kernel.org Signed-off-by: Jonathan Corbet --- Documentation/trace/coresight/coresight.rst | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/trace/coresight/coresight.rst b/Documentation/trace/coresight/coresight.rst index 169749efd8d1..1ec8dc35b1d8 100644 --- a/Documentation/trace/coresight/coresight.rst +++ b/Documentation/trace/coresight/coresight.rst @@ -315,7 +315,8 @@ intermediate links as required. Note: ``cti_sys0`` appears in two of the connections lists above. CTIs can connect to multiple devices and are arranged in a star topology -via the CTM. See (:doc:`coresight-ect`) [#fourth]_ for further details. +via the CTM. See (Documentation/trace/coresight/coresight-ect.rst) +[#fourth]_ for further details. Looking at this device we see 4 connections:: linaro-developer:~# ls -l /sys/bus/coresight/devices/cti_sys0/connections @@ -606,7 +607,8 @@ interface provided for that purpose by the generic STM API:: crw------- 1 root root 10, 61 Jan 3 18:11 /dev/stm0 root@genericarmv8:~# -Details on how to use the generic STM API can be found here:- :doc:`../stm` [#second]_. +Details on how to use the generic STM API can be found here: +- Documentation/trace/stm.rst [#second]_. The CTI & CTM Modules --------------------- @@ -616,7 +618,7 @@ individual CTIs and components, and can propagate these between all CTIs via channels on the CTM (Cross Trigger Matrix). A separate documentation file is provided to explain the use of these devices. -(:doc:`coresight-ect`) [#fourth]_. +(Documentation/trace/coresight/coresight-ect.rst) [#fourth]_. .. [#first] Documentation/ABI/testing/sysfs-bus-coresight-devices-stm -- cgit v1.2.3 From 81a2d57873d94b030de789ebe9b8009241abc775 Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Wed, 16 Jun 2021 08:27:41 +0200 Subject: docs: trace: ftrace.rst: avoid using ReST :doc:`foo` markup The :doc:`foo` tag is auto-generated via automarkup.py. So, use the filename at the sources, instead of :doc:`foo`. Signed-off-by: Mauro Carvalho Chehab Link: https://lore.kernel.org/r/cf9b03ff4b7917d9846503f198372bc6b821445b.1623824363.git.mchehab+huawei@kernel.org Signed-off-by: Jonathan Corbet --- Documentation/trace/ftrace.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/trace/ftrace.rst b/Documentation/trace/ftrace.rst index b88c6b79db3e..cfc81e98e0b8 100644 --- a/Documentation/trace/ftrace.rst +++ b/Documentation/trace/ftrace.rst @@ -40,7 +40,7 @@ See events.rst for more information. Implementation Details ---------------------- -See :doc:`ftrace-design` for details for arch porters and such. +See Documentation/trace/ftrace-design.rst for details for arch porters and such. The File System -- cgit v1.2.3 From 69fe5540153ff7d7ed4ee36ad4037603eb9c45c9 Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Wed, 16 Jun 2021 08:27:42 +0200 Subject: docs: userspace-api: landlock.rst: avoid using ReST :doc:`foo` markup The :doc:`foo` tag is auto-generated via automarkup.py. So, use the filename at the sources, instead of :doc:`foo`. Signed-off-by: Mauro Carvalho Chehab Link: https://lore.kernel.org/r/24888a9c5da3c505b2bc274fcd83be348dbaf972.1623824363.git.mchehab+huawei@kernel.org Signed-off-by: Jonathan Corbet --- Documentation/userspace-api/landlock.rst | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) (limited to 'Documentation') diff --git a/Documentation/userspace-api/landlock.rst b/Documentation/userspace-api/landlock.rst index 62c9361a3c7f..f35552ff19ba 100644 --- a/Documentation/userspace-api/landlock.rst +++ b/Documentation/userspace-api/landlock.rst @@ -145,7 +145,8 @@ Bind mounts and OverlayFS Landlock enables to restrict access to file hierarchies, which means that these access rights can be propagated with bind mounts (cf. -:doc:`/filesystems/sharedsubtree`) but not with :doc:`/filesystems/overlayfs`. +Documentation/filesystems/sharedsubtree.rst) but not with +Documentation/filesystems/overlayfs.rst. A bind mount mirrors a source file hierarchy to a destination. The destination hierarchy is then composed of the exact same files, on which Landlock rules can @@ -170,8 +171,8 @@ Inheritance Every new thread resulting from a :manpage:`clone(2)` inherits Landlock domain restrictions from its parent. This is similar to the seccomp inheritance (cf. -:doc:`/userspace-api/seccomp_filter`) or any other LSM dealing with task's -:manpage:`credentials(7)`. For instance, one process's thread may apply +Documentation/userspace-api/seccomp_filter.rst) or any other LSM dealing with +task's :manpage:`credentials(7)`. For instance, one process's thread may apply Landlock rules to itself, but they will not be automatically applied to other sibling threads (unlike POSIX thread credential changes, cf. :manpage:`nptl(7)`). @@ -278,7 +279,7 @@ Memory usage ------------ Kernel memory allocated to create rulesets is accounted and can be restricted -by the :doc:`/admin-guide/cgroup-v1/memory`. +by the Documentation/admin-guide/cgroup-v1/memory.rst. Questions and answers ===================== @@ -303,7 +304,7 @@ issues, especially when untrusted processes can manipulate them (cf. Additional documentation ======================== -* :doc:`/security/landlock` +* Documentation/security/landlock.rst * https://landlock.io .. Links -- cgit v1.2.3 From c6c032bf2c5483c668461d5f33d83034c791fd91 Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Wed, 16 Jun 2021 08:27:43 +0200 Subject: docs: virt: kvm: s390-pv-boot.rst: avoid using ReST :doc:`foo` markup The :doc:`foo` tag is auto-generated via automarkup.py. So, use the filename at the sources, instead of :doc:`foo`. Signed-off-by: Mauro Carvalho Chehab Link: https://lore.kernel.org/r/8c0fc6578ff6384580fd0d622f363bbbd4fe91da.1623824363.git.mchehab+huawei@kernel.org Signed-off-by: Jonathan Corbet --- Documentation/virt/kvm/s390-pv-boot.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/virt/kvm/s390-pv-boot.rst b/Documentation/virt/kvm/s390-pv-boot.rst index ad1f7866c001..73a6083cb5e7 100644 --- a/Documentation/virt/kvm/s390-pv-boot.rst +++ b/Documentation/virt/kvm/s390-pv-boot.rst @@ -10,7 +10,7 @@ The memory of Protected Virtual Machines (PVMs) is not accessible to I/O or the hypervisor. In those cases where the hypervisor needs to access the memory of a PVM, that memory must be made accessible. Memory made accessible to the hypervisor will be encrypted. See -:doc:`s390-pv` for details." +Documentation/virt/kvm/s390-pv.rst for details." On IPL (boot) a small plaintext bootloader is started, which provides information about the encrypted components and necessary metadata to -- cgit v1.2.3 From 0ffd643875d3f7dac3cd9fbc637a3645c48ba21f Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Wed, 16 Jun 2021 08:27:44 +0200 Subject: docs: x86: avoid using ReST :doc:`foo` markup The :doc:`foo` tag is auto-generated via automarkup.py. So, use the filename at the sources, instead of :doc:`foo`. Acked-by: Peter Zijlstra (Intel) Signed-off-by: Mauro Carvalho Chehab Link: https://lore.kernel.org/r/17c68b5f1d72488431c77c1de9f13683fe9f536c.1623824363.git.mchehab+huawei@kernel.org Signed-off-by: Jonathan Corbet --- Documentation/x86/boot.rst | 4 ++-- Documentation/x86/mtrr.rst | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/x86/boot.rst b/Documentation/x86/boot.rst index fc844913dece..894a19897005 100644 --- a/Documentation/x86/boot.rst +++ b/Documentation/x86/boot.rst @@ -1343,7 +1343,7 @@ follow:: In addition to read/modify/write the setup header of the struct boot_params as that of 16-bit boot protocol, the boot loader should also fill the additional fields of the struct boot_params as -described in chapter :doc:`zero-page`. +described in chapter Documentation/x86/zero-page.rst. After setting up the struct boot_params, the boot loader can load the 32/64-bit kernel in the same way as that of 16-bit boot protocol. @@ -1379,7 +1379,7 @@ can be calculated as follows:: In addition to read/modify/write the setup header of the struct boot_params as that of 16-bit boot protocol, the boot loader should also fill the additional fields of the struct boot_params as described -in chapter :doc:`zero-page`. +in chapter Documentation/x86/zero-page.rst. After setting up the struct boot_params, the boot loader can load 64-bit kernel in the same way as that of 16-bit boot protocol, but diff --git a/Documentation/x86/mtrr.rst b/Documentation/x86/mtrr.rst index c5b695d75349..9f0b1851771a 100644 --- a/Documentation/x86/mtrr.rst +++ b/Documentation/x86/mtrr.rst @@ -28,7 +28,7 @@ are aligned with platform MTRR setup. If MTRRs are only set up by the platform firmware code though and the OS does not make any specific MTRR mapping requests mtrr_type_lookup() should always return MTRR_TYPE_INVALID. -For details refer to :doc:`pat`. +For details refer to Documentation/x86/pat.rst. .. tip:: On Intel P6 family processors (Pentium Pro, Pentium II and later) -- cgit v1.2.3 From 51f52547df700819db0d0e2b17b677cb209212b4 Mon Sep 17 00:00:00 2001 From: Jason Ekstrand Date: Thu, 17 Jun 2021 14:42:58 -0500 Subject: dma-buf: Document DMA_BUF_IOCTL_SYNC (v3) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit This adds a new "DMA Buffer ioctls" section to the dma-buf docs and adds documentation for DMA_BUF_IOCTL_SYNC. v2 (Daniel Vetter): - Fix a couple typos - Add commentary about synchronization with other devices - Use item list format for describing flags v3 (Pekka Paalanen): - Clarify stalling requirements. - Be more clear that that DMA_BUF_IOCTL_SYNC with SINC_END has to be called before more GPU work happens. Signed-off-by: Jason Ekstrand Reviewed-by: Daniel Vetter Acked-by: Christian König Acked-by: Pekka Paalanen Cc: Sumit Semwal Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20210617194258.579011-1-jason@jlekstrand.net --- Documentation/driver-api/dma-buf.rst | 8 ++++++++ 1 file changed, 8 insertions(+) (limited to 'Documentation') diff --git a/Documentation/driver-api/dma-buf.rst b/Documentation/driver-api/dma-buf.rst index 84aab65c4962..f5ac4c90b237 100644 --- a/Documentation/driver-api/dma-buf.rst +++ b/Documentation/driver-api/dma-buf.rst @@ -88,6 +88,9 @@ consider though: - The DMA buffer FD is also pollable, see `Implicit Fence Poll Support`_ below for details. +- The DMA buffer FD also supports a few dma-buf-specific ioctls, see + `DMA Buffer ioctls`_ below for details. + Basic Operation and Device DMA Access ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -111,6 +114,11 @@ DMA-BUF statistics .. kernel-doc:: drivers/dma-buf/dma-buf-sysfs-stats.c :doc: overview +DMA Buffer ioctls +~~~~~~~~~~~~~~~~~ + +.. kernel-doc:: include/uapi/linux/dma-buf.h + Kernel Functions and Structures Reference ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -- cgit v1.2.3 From 102caec1075fe993fb1ef95368ec1c3b2e5d0d77 Mon Sep 17 00:00:00 2001 From: Jonathan Corbet Date: Mon, 14 Jun 2021 16:07:24 -0600 Subject: docs: Take a little noise out of the build process Sphinx 3.0 works at this point (albeit slowly) so stop scaring people with a loud warning. We also don't need to babble about CJK support in the LaTeX build. Signed-off-by: Jonathan Corbet --- Documentation/conf.py | 9 --------- 1 file changed, 9 deletions(-) (limited to 'Documentation') diff --git a/Documentation/conf.py b/Documentation/conf.py index a05225056e08..7d92ec3e5b6e 100644 --- a/Documentation/conf.py +++ b/Documentation/conf.py @@ -41,15 +41,7 @@ extensions = ['kerneldoc', 'rstFlatTable', 'kernel_include', 'maintainers_include', 'sphinx.ext.autosectionlabel', 'kernel_abi', 'kernel_feat'] -# -# cdomain is badly broken in Sphinx 3+. Leaving it out generates *most* -# of the docs correctly, but not all. Scream bloody murder but allow -# the process to proceed; hopefully somebody will fix this properly soon. -# if major >= 3: - sys.stderr.write('''WARNING: The kernel documentation build process - support for Sphinx v3.0 and above is brand new. Be prepared for - possible issues in the generated output.\n''') if (major > 3) or (minor > 0 or patch >= 2): # Sphinx c function parser is more pedantic with regards to type # checking. Due to that, having macros at c:function cause problems. @@ -368,7 +360,6 @@ latex_elements = { cjk_cmd = check_output(['fc-list', '--format="%{family[0]}\n"']).decode('utf-8', 'ignore') if cjk_cmd.find("Noto Sans CJK SC") >= 0: - print ("enabling CJK for LaTeX builder") latex_elements['preamble'] += ''' % This is needed for translations \\usepackage{xeCJK} -- cgit v1.2.3 From 04d72afa34edd14d99db7536d22819cdbb2b2e4c Mon Sep 17 00:00:00 2001 From: Greg Kroah-Hartman Date: Fri, 18 Jun 2021 08:39:24 +0200 Subject: Revert "USB: misc: Add onboard_usb_hub driver" This reverts commit b4e326165e21d6a11483f6a4de2174b933413554 as the patch series is causing build issues in linux-next at the moment. Cc: Matthias Kaehlcke Link: https://lore.kernel.org/r/YMuRcrE8xlWnFSWW@google.com Signed-off-by: Greg Kroah-Hartman --- Documentation/ABI/testing/sysfs-bus-platform-onboard-usb-hub | 8 -------- 1 file changed, 8 deletions(-) delete mode 100644 Documentation/ABI/testing/sysfs-bus-platform-onboard-usb-hub (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-bus-platform-onboard-usb-hub b/Documentation/ABI/testing/sysfs-bus-platform-onboard-usb-hub deleted file mode 100644 index e981d83648e6..000000000000 --- a/Documentation/ABI/testing/sysfs-bus-platform-onboard-usb-hub +++ /dev/null @@ -1,8 +0,0 @@ -What: /sys/bus/platform/devices//always_powered_in_suspend -Date: March 2021 -KernelVersion: 5.13 -Contact: Matthias Kaehlcke - linux-usb@vger.kernel.org -Description: - (RW) Controls whether the USB hub remains always powered - during system suspend or not. \ No newline at end of file -- cgit v1.2.3 From 2f86102bd5484f145870213e79f6fbcf90f494c0 Mon Sep 17 00:00:00 2001 From: Miquel Raynal Date: Thu, 10 Jun 2021 10:20:39 +0200 Subject: dt-bindings: mtd: pl353-nand: Describe this hardware controller Add a yaml description of this NAND controller which is described as a subnode of the SMC bus. Signed-off-by: Miquel Raynal Reviewed-by: Rob Herring Link: https://lore.kernel.org/linux-mtd/20210610082040.2075611-18-miquel.raynal@bootlin.com --- .../bindings/mtd/arm,pl353-nand-r2p1.yaml | 53 ++++++++++++++++++++++ 1 file changed, 53 insertions(+) create mode 100644 Documentation/devicetree/bindings/mtd/arm,pl353-nand-r2p1.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mtd/arm,pl353-nand-r2p1.yaml b/Documentation/devicetree/bindings/mtd/arm,pl353-nand-r2p1.yaml new file mode 100644 index 000000000000..5f126bb9b202 --- /dev/null +++ b/Documentation/devicetree/bindings/mtd/arm,pl353-nand-r2p1.yaml @@ -0,0 +1,53 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mtd/arm,pl353-nand-r2p1.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: PL353 NAND Controller device tree bindings + +allOf: + - $ref: "nand-controller.yaml" + +maintainers: + - Miquel Raynal + - Naga Sureshkumar Relli + +properties: + compatible: + items: + - const: arm,pl353-nand-r2p1 + + reg: + items: + - items: + - description: CS with regard to the parent ranges property + - description: Offset of the memory region requested by the device + - description: Length of the memory region requested by the device + +required: + - compatible + - reg + +unevaluatedProperties: false + +examples: + - | + smcc: memory-controller@e000e000 { + compatible = "arm,pl353-smc-r2p1", "arm,primecell"; + reg = <0xe000e000 0x0001000>; + clock-names = "memclk", "apb_pclk"; + clocks = <&clkc 11>, <&clkc 44>; + ranges = <0x0 0x0 0xe1000000 0x1000000 /* Nand CS region */ + 0x1 0x0 0xe2000000 0x2000000 /* SRAM/NOR CS0 region */ + 0x2 0x0 0xe4000000 0x2000000>; /* SRAM/NOR CS1 region */ + #address-cells = <2>; + #size-cells = <1>; + + nfc0: nand-controller@0,0 { + compatible = "arm,pl353-nand-r2p1"; + reg = <0 0 0x1000000>; + #address-cells = <1>; + #size-cells = <0>; + }; + }; -- cgit v1.2.3 From d3decc70d0793c2e2126bcced9e99877ea27a96d Mon Sep 17 00:00:00 2001 From: Martin Botka Date: Mon, 14 Jun 2021 19:27:09 +0200 Subject: dt-bindings: pinctrl: qcom: sm6125: Document SM6125 pinctrl driver Document the newly added SM6125 pinctrl driver Signed-off-by: Martin Botka Reviewed-by: Bjorn Andersson Link: https://lore.kernel.org/r/20210614172713.558192-1-martin.botka@somainline.org Signed-off-by: Linus Walleij --- .../bindings/pinctrl/qcom,sm6125-pinctrl.yaml | 132 +++++++++++++++++++++ 1 file changed, 132 insertions(+) create mode 100644 Documentation/devicetree/bindings/pinctrl/qcom,sm6125-pinctrl.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sm6125-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sm6125-pinctrl.yaml new file mode 100644 index 000000000000..5f7adaa81f83 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/qcom,sm6125-pinctrl.yaml @@ -0,0 +1,132 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pinctrl/qcom,sm6125-pinctrl.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# +title: Qualcomm Technologies, Inc. SM6125 TLMM block + +maintainers: + - Martin Botka + +description: | + This binding describes the Top Level Mode Multiplexer (TLMM) block found + in the SM6125 platform. + +allOf: + - $ref: /schemas/pinctrl/qcom,tlmm-common.yaml# + +properties: + compatible: + const: qcom,sm6125-tlmm + + reg: + minItems: 3 + maxItems: 3 + + reg-names: + items: + - const: "west" + - const: "south" + - const: "east" + + interrupts: true + interrupt-controller: true + '#interrupt-cells': true + gpio-controller: true + gpio-reserved-ranges: true + '#gpio-cells': true + gpio-ranges: true + wakeup-parent: true + +required: + - compatible + - reg + - reg-names + +additionalProperties: false + +patternProperties: + '-state$': + oneOf: + - $ref: "#/$defs/qcom-sm6125-tlmm-state" + - patternProperties: + ".*": + $ref: "#/$defs/qcom-sm6125-tlmm-state" + +$defs: + qcom-sm6125-tlmm-state: + type: object + description: + Pinctrl node's client devices use subnodes for desired pin configuration. + Client device subnodes use below standard properties. + $ref: "qcom,tlmm-common.yaml#/$defs/qcom-tlmm-state" + + properties: + pins: + description: + List of gpio pins affected by the properties specified in this + subnode. + items: + oneOf: + - pattern: "^gpio[0-9]|[1-9][0-9]|1[0-2][0-9]|13[0-2]$" + - enum: [ sdc1_clk, sdc1_cmd, sdc1_data, sdc2_clk, sdc2_cmd, sdc2_data ] + minItems: 1 + maxItems: 36 + + function: + description: + Specify the alternative function to be configured for the specified + pins. + + enum: [ adsp_ext, agera_pll, atest_char, atest_char0, atest_char1, + atest_char2, atest_char3, atest_tsens, atest_tsens2, atest_usb1, + atest_usb10, atest_usb11, atest_usb12, atest_usb13, atest_usb2, + atest_usb20, atest_usb21, atest_usb22, atest_usb23, aud_sb, + audio_ref, cam_mclk, cci_async, cci_i2c, cci_timer0, cci_timer1, + cci_timer2, cci_timer3, cci_timer4, copy_gp, copy_phase, cri_trng, + cri_trng0, cri_trng1, dbg_out, ddr_bist, ddr_pxi0, ddr_pxi1, + ddr_pxi2, ddr_pxi3, debug_hot, dmic0_clk, dmic0_data, dmic1_clk, + dmic1_data, dp_hot, edp_hot, edp_lcd, gcc_gp1, gcc_gp2, gcc_gp3, + gp_pdm0, gp_pdm1, gp_pdm2, gpio, gps_tx, jitter_bist, ldo_en, + ldo_update, m_voc, mclk1, mclk2, mdp_vsync, mdp_vsync0, mdp_vsync1, + mdp_vsync2, mdp_vsync3, mdp_vsync4, mdp_vsync5, mpm_pwr, mss_lte, + nav_pps, pa_indicator, phase_flag, pll_bist, pll_bypassnl, pll_reset, + pri_mi2s, pri_mi2s_ws, prng_rosc, qca_sb, qdss_cti, qdss, qlink_enable, + qlink_request, qua_mi2s, qui_mi2s, qup00, qup01, qup02, qup03, qup04, + qup10, qup11, qup12, qup13, qup14, sd_write, sec_mi2s, sp_cmu, swr_rx, + swr_tx, ter_mi2s, tgu_ch0, tgu_ch1, tgu_ch2, tgu_ch3, tsense_pwm, + uim1_clk, uim1_data, uim1_present, uim1_reset, uim2_clk, uim2_data, + uim2_present, uim2_reset, unused1, unused2, usb_phy, vfr_1, vsense_trigger, + wlan1_adc0, wlan1_adc1, wlan2_adc0, wlan2_adc1, wsa_clk, wsa_data ] + + + bias-disable: true + bias-pull-down: true + bias-pull-up: true + drive-strength: true + input-enable: true + output-high: true + output-low: true + + required: + - pins + - function + + additionalProperties: false + +examples: + - | + #include + pinctrl@500000 { + compatible = "qcom,sm6125-tlmm"; + reg = <0x00500000 0x400000>, + <0x00900000 0x400000>, + <0x00d00000 0x400000>; + reg-names = "west", "south", "east"; + interrupts = ; + gpio-controller; + gpio-ranges = <&tlmm 0 0 134>; + #gpio-cells = <2>; + interrupt-controller; + #interrupt-cells = <2>; + }; -- cgit v1.2.3 From 291343676e328e1493204faa149746829c488b06 Mon Sep 17 00:00:00 2001 From: Jiri Slaby Date: Fri, 18 Jun 2021 08:14:07 +0200 Subject: mxser: drop ISA support While mxser PCI cards are still around and produced (Moxa provided me with two recently), ISA cards are obsolete for a long time. I haven't seen anyone using the cards and the ISA code paths are barely tested. Hence, remove ISA support from mxser driver so that we can clean the driver up. Signed-off-by: Jiri Slaby Link: https://lore.kernel.org/r/20210618061516.662-2-jslaby@suse.cz Signed-off-by: Greg Kroah-Hartman --- Documentation/driver-api/serial/moxa-smartio.rst | 107 ++--------------------- 1 file changed, 9 insertions(+), 98 deletions(-) (limited to 'Documentation') diff --git a/Documentation/driver-api/serial/moxa-smartio.rst b/Documentation/driver-api/serial/moxa-smartio.rst index 156100f17c3f..aedda2546242 100644 --- a/Documentation/driver-api/serial/moxa-smartio.rst +++ b/Documentation/driver-api/serial/moxa-smartio.rst @@ -37,8 +37,7 @@ Date: 01/21/2008 CP-102U, CP-102UL, CP-102UF CP-132U-I, CP-132UL, CP-132, CP-132I, CP132S, CP-132IS, - CI-132, CI-132I, CI-132IS, - (C102H, C102HI, C102HIS, C102P, CP-102, CP-102S) + (CP-102, CP-102S) - 4 ports multiport board CP-104EL, @@ -46,10 +45,7 @@ Date: 01/21/2008 CP-134U, CP-134U-I, C104H/PCI, C104HS/PCI, CP-114, CP-114I, CP-114S, CP-114IS, CP-114UL, - C104H, C104HS, - CI-104J, CI-104JS, - CI-134, CI-134I, CI-134IS, - (C114HI, CT-114I, C104P), + (C114HI, CT-114I), POS-104UL, CB-114, CB-134I @@ -58,8 +54,6 @@ Date: 01/21/2008 CP-118EL, CP-168EL, CP-118U, CP-168U, C168H/PCI, - C168H, C168HS, - (C168P), CB-108 This driver and installation procedure have been developed upon Linux Kernel @@ -78,9 +72,6 @@ Date: 01/21/2008 Monitor program to observe data count and line status signals. - msterm A simple terminal program which is useful in testing serial ports. - - io-irq.exe - Configuration program to setup ISA boards. Please note that - this program can only be executed under DOS. All the drivers and utilities are published in form of source code under GNU General Public License in this version. Please refer to GNU General @@ -112,17 +103,6 @@ Date: 01/21/2008 3.1 Hardware installation ========================= - There are two types of buses, ISA and PCI, for Smartio/Industio - family multiport board. - -ISA board ---------- - - You'll have to configure CAP address, I/O address, Interrupt Vector - as well as IRQ before installing this driver. Please refer to hardware - installation procedure in User's Manual before proceed any further. - Please make sure the JP1 is open after the ISA board is set properly. - PCI/UPCI board -------------- @@ -194,16 +174,6 @@ Device naming when more than 2 boards installed Under Kernel 2.6 and upper, the cum Device is Obsolete. So use ttyM* device instead. -Board sequence --------------- - - This driver will activate ISA boards according to the parameter set - in the driver. After all specified ISA board activated, PCI board - will be installed in the system automatically driven. - Therefore the board number is sorted by the CAP address of ISA boards. - For PCI boards, their sequence will be after ISA boards and C168H/PCI - has higher priority than C104H/PCI boards. - 3.4 Module driver configuration =============================== @@ -274,12 +244,10 @@ Board sequence :: - # modprobe mxser + # modprobe mxser will activate the module driver. You may run "lsmod" to check - if "mxser" is activated. If the MOXA board is ISA board, the - is needed. Please refer to section "3.4.5" for more - information. + if "mxser" is activated. ------------- Load MOXA driver on boot -------------------- @@ -296,13 +264,6 @@ Board sequence achieved by rc file. We offer one "rc.mxser" file to simplify the procedure under "moxa/mxser/driver". - But if you use ISA board, please modify the "modprobe ..." command - to add the argument (see "3.4.5" section). After modifying the - rc.mxser, please try to execute "/moxa/mxser/driver/rc.mxser" - manually to make sure the modification is ok. If any error - encountered, please try to modify again. If the modification is - completed, follow the below step. - Run following command for setting rc files:: # cd /moxa/mxser/driver @@ -316,21 +277,6 @@ Board sequence Reboot and check if moxa.o activated by "lsmod" command. -3.4.5. specify CAP address --------------------------- - - If you'd like to drive Smartio/Industio ISA boards in the system, - you'll have to add parameter to specify CAP address of given - board while activating "mxser.o". The format for parameters are - as follows.:: - - modprobe mxser ioaddr=0x???,0x???,0x???,0x??? - | | | | - | | | +- 4th ISA board - | | +------ 3rd ISA board - | +------------ 2nd ISA board - +-------------------1st ISA board - 3.5 Static driver configuration for Linux kernel 2.4.x and 2.6.x ================================================================ @@ -357,35 +303,7 @@ Board sequence # cd /usr/src/linux/drivers/char # ln -s /moxa/mxser/driver/mxser.c mxser.c -3.5.3 Add CAP address list for ISA boards. ------------------------------------------- - - For PCI boards user, please skip this step. - - In module mode, the CAP address for ISA board is given by - parameter. In static driver configuration, you'll have to - assign it within driver's source code. If you will not - install any ISA boards, you may skip to next portion. - The instructions to modify driver source code are as - below. - - a. run:: - - # cd /moxa/mxser/driver - # vi mxser.c - - b. Find the array mxserBoardCAP[] as below:: - - static int mxserBoardCAP[] = {0x00, 0x00, 0x00, 0x00}; - - c. Change the address within this array using vi. For - example, to driver 2 ISA boards with CAP address - 0x280 and 0x180 as 1st and 2nd board. Just to change - the source code as follows:: - - static int mxserBoardCAP[] = {0x280, 0x180, 0x00, 0x00}; - -3.5.4 Setup kernel configuration +3.5.3 Setup kernel configuration -------------------------------- Configure the kernel:: @@ -398,7 +316,7 @@ Board sequence SmartIO support] driver with "[*]" for built-in (not "[M]"), then select [Exit] to exit this program. -3.5.5 Rebuild kernel +3.5.4 Rebuild kernel -------------------- The following are for Linux kernel rebuilding, for your @@ -426,14 +344,14 @@ Board sequence directory /usr/src/linux. -3.5.6 Make tty device and special file +3.5.5 Make tty device and special file -------------------------------------- :: # cd /moxa/mxser/driver # ./msmknod -3.5.7 Make utility +3.5.6 Make utility ------------------ :: @@ -441,7 +359,7 @@ Board sequence # cd /moxa/mxser/utility # make clean; make install -3.5.8 Reboot +3.5.7 Reboot ------------ @@ -591,13 +509,6 @@ msterm - Terminal Emulation Each port within the same multiport board shares the same IRQ. Please set one IRQ (IRQ doesn't equal to zero) for one Moxa board. - Error msg: - No interrupt vector be set for Moxa ISA board(CAP=xxx). - - Solution: - Moxa ISA board needs an interrupt vector.Please refer to user's manual - "Hardware Installation" chapter to set interrupt vector. - Error msg: Couldn't install MOXA Smartio/Industio family driver! -- cgit v1.2.3 From a7f6afcd4ec61136fda54abd3555125a32a9d34e Mon Sep 17 00:00:00 2001 From: Jiri Slaby Date: Fri, 18 Jun 2021 08:15:13 +0200 Subject: mxser: Documentation, remove traces of callout device Callout devices are ancient history, so remove its traces from mxser's documentation. Signed-off-by: Jiri Slaby Link: https://lore.kernel.org/r/20210618061516.662-68-jslaby@suse.cz Signed-off-by: Greg Kroah-Hartman --- Documentation/driver-api/serial/moxa-smartio.rst | 46 +++++++----------------- 1 file changed, 12 insertions(+), 34 deletions(-) (limited to 'Documentation') diff --git a/Documentation/driver-api/serial/moxa-smartio.rst b/Documentation/driver-api/serial/moxa-smartio.rst index aedda2546242..3a0a8b502898 100644 --- a/Documentation/driver-api/serial/moxa-smartio.rst +++ b/Documentation/driver-api/serial/moxa-smartio.rst @@ -147,13 +147,7 @@ or:: run the driver. If you prefer module driver, please refer to 3.4. If static driver is required, please refer to 3.5. -Dialin and callout port ------------------------ - - This driver remains traditional serial device properties. There are - two special file name for each serial port. One is dial-in port - which is named "ttyMxx". For callout port, the naming convention - is "cumxx". + The device node is named "ttyMxx". Device naming when more than 2 boards installed ----------------------------------------------- @@ -161,18 +155,13 @@ Device naming when more than 2 boards installed Naming convention for each Smartio/Industio multiport board is pre-defined as below. - ============ =============== ============== - Board Num. Dial-in Port Callout port - 1st board ttyM0 - ttyM7 cum0 - cum7 - 2nd board ttyM8 - ttyM15 cum8 - cum15 - 3rd board ttyM16 - ttyM23 cum16 - cum23 - 4th board ttyM24 - ttym31 cum24 - cum31 - ============ =============== ============== - -.. note:: - - Under Kernel 2.6 and upper, the cum Device is Obsolete. So use ttyM* - device instead. + ============ =============== + Board Num. Device node + 1st board ttyM0 - ttyM7 + 2nd board ttyM8 - ttyM15 + 3rd board ttyM16 - ttyM23 + 4th board ttyM24 - ttyM31 + ============ =============== 3.4 Module driver configuration =============================== @@ -204,13 +193,10 @@ Device naming when more than 2 boards installed # cd /moxa/mxser/driver # ./msmknod - This shell script will require the major number for dial-in - device and callout device to create tty device. You also need - to specify the total installed MOXA board number. Default major - numbers for dial-in device and callout device are 30, 35. If - you need to change to other number, please refer section "3.7" - for more detailed procedure. - Msmknod will delete any special files occupying the same device + This shell script will require the major number for the device. You also + need to specify the total installed MOXA board number. If you need to + change to other number, please refer section "3.7" for more detailed + procedure. Msmknod will delete any special files occupying the same device naming. 3.4.2 Build the MOXA driver and utilities @@ -516,11 +502,3 @@ msterm - Terminal Emulation Load Moxa driver fail, the major number may conflict with other devices. Please refer to previous section 3.7 to change a free major number for Moxa driver. - - Error msg: - Couldn't install MOXA Smartio/Industio family callout driver! - - Solution: - Load Moxa callout driver fail, the callout device major number may - conflict with other devices. Please refer to previous section 3.7 to - change a free callout device major number for Moxa driver. -- cgit v1.2.3 From b34440ffada76527dd39a7a6e753ac31ede3ae88 Mon Sep 17 00:00:00 2001 From: Jiri Slaby Date: Fri, 18 Jun 2021 08:15:14 +0200 Subject: mxser: Documentation, make the docs up-to-date Remove all the obsolete information from the documentation of mxser driver. Either it was about the out-of-tree driver, or it was superseded by udev et al. Signed-off-by: Jiri Slaby Link: https://lore.kernel.org/r/20210618061516.662-69-jslaby@suse.cz Signed-off-by: Greg Kroah-Hartman --- Documentation/driver-api/serial/moxa-smartio.rst | 325 +---------------------- 1 file changed, 9 insertions(+), 316 deletions(-) (limited to 'Documentation') diff --git a/Documentation/driver-api/serial/moxa-smartio.rst b/Documentation/driver-api/serial/moxa-smartio.rst index 3a0a8b502898..838888f81b6d 100644 --- a/Documentation/driver-api/serial/moxa-smartio.rst +++ b/Documentation/driver-api/serial/moxa-smartio.rst @@ -2,14 +2,8 @@ MOXA Smartio/Industio Family Device Driver Installation Guide ============================================================= -.. note:: - - This file is outdated. It needs some care in order to make it - updated to Kernel 5.0 and upper - Copyright (C) 2008, Moxa Inc. - -Date: 01/21/2008 +Copyright (C) 2021, Jiri Slaby .. Content @@ -17,12 +11,7 @@ Date: 01/21/2008 2. System Requirement 3. Installation 3.1 Hardware installation - 3.2 Driver files - 3.3 Device naming convention - 3.4 Module driver configuration - 3.5 Static driver configuration for Linux kernel 2.4.x and 2.6.x. - 3.6 Custom configuration - 3.7 Verify driver installation + 3.2 Device naming convention 4. Utilities 5. Setserial 6. Troubleshooting @@ -56,11 +45,8 @@ Date: 01/21/2008 C168H/PCI, CB-108 - This driver and installation procedure have been developed upon Linux Kernel - 2.4.x and 2.6.x. This driver supports Intel x86 hardware platform. In order - to maintain compatibility, this version has also been properly tested with - RedHat, Mandrake, Fedora and S.u.S.E Linux. However, if compatibility problem - occurs, please contact Moxa at support@moxa.com.tw. + If a compatibility problem occurs, please contact Moxa at + support@moxa.com.tw. In addition to device driver, useful utilities are also provided in this version. They are: @@ -77,14 +63,14 @@ Date: 01/21/2008 GNU General Public License in this version. Please refer to GNU General Public License announcement in each source code file for more detail. - In Moxa's Web sites, you may always find latest driver at http://www.moxa.com/. + In Moxa's Web sites, you may always find latest driver at + https://www.moxa.com/. This version of driver can be installed as Loadable Module (Module driver) - or built-in into kernel (Static driver). You may refer to following - installation procedure for suitable one. Before you install the driver, + or built-in into kernel (Static driver). Before you install the driver, please refer to hardware installation procedure in the User's Manual. - We assume the user should be familiar with following documents. + We assume the user should be familiar with following documents: - Serial-HOWTO - Kernel-HOWTO @@ -92,9 +78,6 @@ Date: 01/21/2008 2. System Requirement ^^^^^^^^^^^^^^^^^^^^^ - - Hardware platform: Intel x86 machine - - Kernel version: 2.4.x or 2.6.x - - gcc version 2.72 or later - Maximum 4 boards can be installed in combination 3. Installation @@ -118,35 +101,10 @@ PCI IRQ Sharing together on one system and they can share the same IRQ. -3.2 Driver files -================ - - The driver file may be obtained from ftp, CD-ROM or floppy disk. The - first step, anyway, is to copy driver file "mxser.tgz" into specified - directory. e.g. /moxa. The execute commands as below:: - - # cd / - # mkdir moxa - # cd /moxa - # tar xvf /dev/fd0 - -or:: - - # cd / - # mkdir moxa - # cd /moxa - # cp /mnt/cdrom//mxser.tgz . - # tar xvfz mxser.tgz - -3.3 Device naming convention +3.2 Device naming convention ============================ - You may find all the driver and utilities files in /moxa/mxser. - Following installation procedure depends on the model you'd like to - run the driver. If you prefer module driver, please refer to 3.4. - If static driver is required, please refer to 3.5. - The device node is named "ttyMxx". Device naming when more than 2 boards installed @@ -163,245 +121,6 @@ Device naming when more than 2 boards installed 4th board ttyM24 - ttyM31 ============ =============== -3.4 Module driver configuration -=============================== - - Module driver is easiest way to install. If you prefer static driver - installation, please skip this paragraph. - - - ------------- Prepare to use the MOXA driver -------------------- - -3.4.1 Create tty device with correct major number -------------------------------------------------- - - Before using MOXA driver, your system must have the tty devices - which are created with driver's major number. We offer one shell - script "msmknod" to simplify the procedure. - This step is only needed to be executed once. But you still - need to do this procedure when: - - a. You change the driver's major number. Please refer the "3.7" - section. - b. Your total installed MOXA boards number is changed. Maybe you - add/delete one MOXA board. - c. You want to change the tty name. This needs to modify the - shell script "msmknod" - - The procedure is:: - - # cd /moxa/mxser/driver - # ./msmknod - - This shell script will require the major number for the device. You also - need to specify the total installed MOXA board number. If you need to - change to other number, please refer section "3.7" for more detailed - procedure. Msmknod will delete any special files occupying the same device - naming. - -3.4.2 Build the MOXA driver and utilities ------------------------------------------ - - Before using the MOXA driver and utilities, you need compile the - all the source code. This step is only need to be executed once. - But you still re-compile the source code if you modify the source - code. For example, if you change the driver's major number (see - "3.7" section), then you need to do this step again. - - Find "Makefile" in /moxa/mxser, then run - - # make clean; make install - - ..note:: - - For Red Hat 9, Red Hat Enterprise Linux AS3/ES3/WS3 & Fedora Core1: - # make clean; make installsp1 - - For Red Hat Enterprise Linux AS4/ES4/WS4: - # make clean; make installsp2 - - The driver files "mxser.o" and utilities will be properly compiled - and copied to system directories respectively. - -------------- Load MOXA driver-------------------- - -3.4.3 Load the MOXA driver --------------------------- - - :: - - # modprobe mxser - - will activate the module driver. You may run "lsmod" to check - if "mxser" is activated. - -------------- Load MOXA driver on boot -------------------- - -3.4.4 Load the mxser driver ---------------------------- - - - For the above description, you may manually execute - "modprobe mxser" to activate this driver and run - "rmmod mxser" to remove it. - - However, it's better to have a boot time configuration to - eliminate manual operation. Boot time configuration can be - achieved by rc file. We offer one "rc.mxser" file to simplify - the procedure under "moxa/mxser/driver". - - Run following command for setting rc files:: - - # cd /moxa/mxser/driver - # cp ./rc.mxser /etc/rc.d - # cd /etc/rc.d - - Check "rc.serial" is existed or not. If "rc.serial" doesn't exist, - create it by vi, run "chmod 755 rc.serial" to change the permission. - - Add "/etc/rc.d/rc.mxser" in last line. - - Reboot and check if moxa.o activated by "lsmod" command. - -3.5 Static driver configuration for Linux kernel 2.4.x and 2.6.x -================================================================ - - Note: - To use static driver, you must install the linux kernel - source package. - -3.5.1 Backup the built-in driver in the kernel ----------------------------------------------- - - :: - - # cd /usr/src/linux/drivers/char - # mv mxser.c mxser.c.old - - For Red Hat 7.x user, you need to create link: - # cd /usr/src - # ln -s linux-2.4 linux - -3.5.2 Create link ------------------ - :: - - # cd /usr/src/linux/drivers/char - # ln -s /moxa/mxser/driver/mxser.c mxser.c - -3.5.3 Setup kernel configuration --------------------------------- - - Configure the kernel:: - - # cd /usr/src/linux - # make menuconfig - - You will go into a menu-driven system. Please select [Character - devices][Non-standard serial port support], enable the [Moxa - SmartIO support] driver with "[*]" for built-in (not "[M]"), then - select [Exit] to exit this program. - -3.5.4 Rebuild kernel --------------------- - - The following are for Linux kernel rebuilding, for your - reference only. - - For appropriate details, please refer to the Linux document: - - a. Run the following commands:: - - cd /usr/src/linux - make clean # take a few minutes - make dep # take a few minutes - make bzImage # take probably 10-20 minutes - make install # copy boot image to correct position - - f. Please make sure the boot kernel (vmlinuz) is in the - correct position. - g. If you use 'lilo' utility, you should check /etc/lilo.conf - 'image' item specified the path which is the 'vmlinuz' path, - or you will load wrong (or old) boot kernel image (vmlinuz). - After checking /etc/lilo.conf, please run "lilo". - - Note that if the result of "make bzImage" is ERROR, then you have to - go back to Linux configuration Setup. Type "make menuconfig" in - directory /usr/src/linux. - - -3.5.5 Make tty device and special file --------------------------------------- - - :: - # cd /moxa/mxser/driver - # ./msmknod - -3.5.6 Make utility ------------------- - - :: - - # cd /moxa/mxser/utility - # make clean; make install - -3.5.7 Reboot ------------- - - - -3.6 Custom configuration -======================== - - Although this driver already provides you default configuration, you - still can change the device name and major number. The instruction to - change these parameters are shown as below. - -a. Change Device name - - If you'd like to use other device names instead of default naming - convention, all you have to do is to modify the internal code - within the shell script "msmknod". First, you have to open "msmknod" - by vi. Locate each line contains "ttyM" and "cum" and change them - to the device name you desired. "msmknod" creates the device names - you need next time executed. - -b. Change Major number - - If major number 30 and 35 had been occupied, you may have to select - 2 free major numbers for this driver. There are 3 steps to change - major numbers. - -3.6.1 Find free major numbers ------------------------------ - - In /proc/devices, you may find all the major numbers occupied - in the system. Please select 2 major numbers that are available. - e.g. 40, 45. - -3.6.2 Create special files --------------------------- - - Run /moxa/mxser/driver/msmknod to create special files with - specified major numbers. - -3.6.3 Modify driver with new major number ------------------------------------------ - - Run vi to open /moxa/mxser/driver/mxser.c. Locate the line - contains "MXSERMAJOR". Change the content as below:: - - #define MXSERMAJOR 40 - #define MXSERCUMAJOR 45 - - 3.6.4 Run "make clean; make install" in /moxa/mxser/driver. - -3.7 Verify driver installation -============================== - - You may refer to /var/log/messages to check the latest status - log reported by this driver whenever it's activated. - 4. Utilities ^^^^^^^^^^^^ @@ -409,9 +128,6 @@ b. Change Major number msterm. These 3 utilities are released in form of source code. They should be compiled into executable file and copied into /usr/bin. - Before using these utilities, please load driver (refer 3.4 & 3.5) and - make sure you had run the "msmknod" utility. - msdiag - Diagnostic =================== @@ -479,26 +195,3 @@ msterm - Terminal Emulation Solution: To avoid this problem, please unplug fifth and after board, because Moxa driver supports up to 4 boards. - - Error msg: - Request_irq fail, IRQ(?) may be conflict with another device. - - Solution: - Other PCI or ISA devices occupy the assigned IRQ. If you are not sure - which device causes the situation, please check /proc/interrupts to find - free IRQ and simply change another free IRQ for Moxa board. - - Error msg: - Board #: C1xx Series(CAP=xxx) interrupt number invalid. - - Solution: - Each port within the same multiport board shares the same IRQ. Please set - one IRQ (IRQ doesn't equal to zero) for one Moxa board. - - Error msg: - Couldn't install MOXA Smartio/Industio family driver! - - Solution: - Load Moxa driver fail, the major number may conflict with other devices. - Please refer to previous section 3.7 to change a free major number for - Moxa driver. -- cgit v1.2.3 From 0dd77d02c3333c14f8892b379fae3f731af23897 Mon Sep 17 00:00:00 2001 From: Jiri Slaby Date: Fri, 18 Jun 2021 08:15:15 +0200 Subject: mxser: Documentation, fix typos Fix some typos in the mxser's documentation. Signed-off-by: Jiri Slaby Link: https://lore.kernel.org/r/20210618061516.662-70-jslaby@suse.cz Signed-off-by: Greg Kroah-Hartman --- Documentation/driver-api/serial/moxa-smartio.rst | 42 ++++++++++++------------ 1 file changed, 21 insertions(+), 21 deletions(-) (limited to 'Documentation') diff --git a/Documentation/driver-api/serial/moxa-smartio.rst b/Documentation/driver-api/serial/moxa-smartio.rst index 838888f81b6d..af25bc5cc3e6 100644 --- a/Documentation/driver-api/serial/moxa-smartio.rst +++ b/Documentation/driver-api/serial/moxa-smartio.rst @@ -20,7 +20,7 @@ Copyright (C) 2021, Jiri Slaby ^^^^^^^^^^^^^^^ The Smartio/Industio/UPCI family Linux driver supports following multiport - boards. + boards: - 2 ports multiport board CP-102U, CP-102UL, CP-102UF @@ -63,10 +63,10 @@ Copyright (C) 2021, Jiri Slaby GNU General Public License in this version. Please refer to GNU General Public License announcement in each source code file for more detail. - In Moxa's Web sites, you may always find latest driver at + In Moxa's Web sites, you may always find the latest driver at https://www.moxa.com/. - This version of driver can be installed as Loadable Module (Module driver) + This version of driver can be installed as a Loadable Module (Module driver) or built-in into kernel (Static driver). Before you install the driver, please refer to hardware installation procedure in the User's Manual. @@ -89,9 +89,9 @@ Copyright (C) 2021, Jiri Slaby PCI/UPCI board -------------- - You may need to adjust IRQ usage in BIOS to avoid from IRQ conflict - with other ISA devices. Please refer to hardware installation - procedure in User's Manual in advance. + You may need to adjust IRQ usage in BIOS to avoid IRQ conflict with other + ISA devices. Please refer to hardware installation procedure in User's + Manual in advance. PCI IRQ Sharing --------------- @@ -132,7 +132,7 @@ msdiag - Diagnostic =================== This utility provides the function to display what Moxa Smartio/Industio - board found by driver in the system. + board was found by the driver in the system. msmon - Port Monitoring ======================= @@ -162,23 +162,23 @@ msterm - Terminal Emulation Supported Setserial parameters are listed as below. - ============== ========================================================= - uart set UART type(16450-->disable FIFO, 16550A-->enable FIFO) - close_delay set the amount of time(in 1/100 of a second) that DTR + ============== ============================================================= + uart set UART type(16450 --> disable FIFO, 16550A --> enable FIFO) + close_delay set the amount of time (in 1/100 of a second) that DTR should be kept low while being closed. - closing_wait set the amount of time(in 1/100 of a second) that the + closing_wait set the amount of time (in 1/100 of a second) that the serial port should wait for data to be drained while - being closed, before the receiver is disable. - spd_hi Use 57.6kb when the application requests 38.4kb. - spd_vhi Use 115.2kb when the application requests 38.4kb. - spd_shi Use 230.4kb when the application requests 38.4kb. - spd_warp Use 460.8kb when the application requests 38.4kb. - spd_normal Use 38.4kb when the application requests 38.4kb. - spd_cust Use the custom divisor to set the speed when the + being closed, before the receiver is disabled. + spd_hi Use 57.6kb when the application requests 38.4kb. + spd_vhi Use 115.2kb when the application requests 38.4kb. + spd_shi Use 230.4kb when the application requests 38.4kb. + spd_warp Use 460.8kb when the application requests 38.4kb. + spd_normal Use 38.4kb when the application requests 38.4kb. + spd_cust Use the custom divisor to set the speed when the application requests 38.4kb. - divisor This option set the custom division. - baud_base This option set the base baud rate. - ============== ========================================================= + divisor This option sets the custom division. + baud_base This option sets the base baud rate. + ============== ============================================================= 6. Troubleshooting ^^^^^^^^^^^^^^^^^^ -- cgit v1.2.3 From 4d041216c83dd9933c7c72b40511bb3585fa1724 Mon Sep 17 00:00:00 2001 From: Yuri Nudelman Date: Sun, 13 Jun 2021 09:22:20 +0300 Subject: debugfs: add skip_reset_on_timeout option To be able to debug long-running CS better, without changing the userspace code, we are adding a new option through debugfs interface to skip the reset of the device in case of CS timeout. Signed-off-by: Yuri Nudelman Reviewed-by: Oded Gabbay Signed-off-by: Oded Gabbay --- Documentation/ABI/testing/debugfs-driver-habanalabs | 8 ++++++++ 1 file changed, 8 insertions(+) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/debugfs-driver-habanalabs b/Documentation/ABI/testing/debugfs-driver-habanalabs index c78fc9282876..e78ceb1f70b3 100644 --- a/Documentation/ABI/testing/debugfs-driver-habanalabs +++ b/Documentation/ABI/testing/debugfs-driver-habanalabs @@ -207,6 +207,14 @@ Contact: ogabbay@kernel.org Description: Sets the PCI power state. Valid values are "1" for D0 and "2" for D3Hot +What: /sys/kernel/debug/habanalabs/hl/skip_reset_on_timeout +Date: Jun 2021 +KernelVersion: 5.13 +Contact: ynudelman@habana.ai +Description: Sets the skip reset on timeout option for the device. Value of + "0" means device will be reset in case some CS has timed out, + otherwise it will not be reset. + What: /sys/kernel/debug/habanalabs/hl/stop_on_err Date: Mar 2020 KernelVersion: 5.6 -- cgit v1.2.3 From 222a28edce38b62074a950fb243df621c602b4d3 Mon Sep 17 00:00:00 2001 From: Kees Cook Date: Thu, 17 Jun 2021 15:58:08 -0700 Subject: docs: Makefile: Use CONFIG_SHELL not SHELL Fix think-o about which variable to find the Kbuild-configured shell. This has accidentally worked due to most shells setting $SHELL by default. Fixes: 51e46c7a4007 ("docs, parallelism: Rearrange how jobserver reservations are made") Cc: stable@vger.kernel.org Signed-off-by: Kees Cook Link: https://lore.kernel.org/r/20210617225808.3907377-1-keescook@chromium.org Signed-off-by: Jonathan Corbet --- Documentation/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/Makefile b/Documentation/Makefile index 9c42dde97671..c3feb657b654 100644 --- a/Documentation/Makefile +++ b/Documentation/Makefile @@ -76,7 +76,7 @@ quiet_cmd_sphinx = SPHINX $@ --> file://$(abspath $(BUILDDIR)/$3/$4) PYTHONDONTWRITEBYTECODE=1 \ BUILDDIR=$(abspath $(BUILDDIR)) SPHINX_CONF=$(abspath $(srctree)/$(src)/$5/$(SPHINX_CONF)) \ $(PYTHON3) $(srctree)/scripts/jobserver-exec \ - $(SHELL) $(srctree)/Documentation/sphinx/parallel-wrapper.sh \ + $(CONFIG_SHELL) $(srctree)/Documentation/sphinx/parallel-wrapper.sh \ $(SPHINXBUILD) \ -b $2 \ -c $(abspath $(srctree)/$(src)) \ -- cgit v1.2.3 From 993b892610d159dc16f6556dd0bf111ddc3ce0b9 Mon Sep 17 00:00:00 2001 From: Fox Chen Date: Thu, 27 May 2021 17:16:06 +0800 Subject: docs: path-lookup: update follow_managed() part No follow_managed() anymore, handle_mounts(), traverse_mounts(), will do the job. see commit 9deed3ebca24 ("new helper: traverse_mounts()") Signed-off-by: Fox Chen Reviewed-by: NeilBrown Link: https://lore.kernel.org/r/20210527091618.287093-2-foxhlchen@gmail.com Signed-off-by: Jonathan Corbet --- Documentation/filesystems/path-lookup.rst | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) (limited to 'Documentation') diff --git a/Documentation/filesystems/path-lookup.rst b/Documentation/filesystems/path-lookup.rst index c482e1619e77..751082d469e8 100644 --- a/Documentation/filesystems/path-lookup.rst +++ b/Documentation/filesystems/path-lookup.rst @@ -448,10 +448,11 @@ described. If it finds a ``LAST_NORM`` component it first calls filesystem to revalidate the result if it is that sort of filesystem. If that doesn't get a good result, it calls "``lookup_slow()``" which takes ``i_rwsem``, rechecks the cache, and then asks the filesystem -to find a definitive answer. Each of these will call -``follow_managed()`` (as described below) to handle any mount points. +to find a definitive answer. -In the absence of symbolic links, ``walk_component()`` creates a new +As the last step of ``walk_component()``, ``step_into()`` will be called either +directly from walk_component() or from handle_dots(). It calls +``handle_mounts()``, to check and handle mount points, in which a new ``struct path`` containing a counted reference to the new dentry and a reference to the new ``vfsmount`` which is only counted if it is different from the previous ``vfsmount``. It then calls @@ -535,8 +536,7 @@ covered in greater detail in autofs.txt in the Linux documentation tree, but a few notes specifically related to path lookup are in order here. -The Linux VFS has a concept of "managed" dentries which is reflected -in function names such as "``follow_managed()``". There are three +The Linux VFS has a concept of "managed" dentries. There are three potentially interesting things about these dentries corresponding to three different flags that might be set in ``dentry->d_flags``: -- cgit v1.2.3 From 084c86837a3583c7cf56d74f91fb8e6191f99a8a Mon Sep 17 00:00:00 2001 From: Fox Chen Date: Thu, 27 May 2021 17:16:07 +0800 Subject: docs: path-lookup: update path_to_nameidata() part No path_to_namei() anymore, step_into() will be called. Related commit: commit c99687a03a78 ("fold path_to_nameidata() into its only remaining caller") Signed-off-by: Fox Chen Reviewed-by: NeilBrown Link: https://lore.kernel.org/r/20210527091618.287093-3-foxhlchen@gmail.com Signed-off-by: Jonathan Corbet --- Documentation/filesystems/path-lookup.rst | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) (limited to 'Documentation') diff --git a/Documentation/filesystems/path-lookup.rst b/Documentation/filesystems/path-lookup.rst index 751082d469e8..6ea0880fb982 100644 --- a/Documentation/filesystems/path-lookup.rst +++ b/Documentation/filesystems/path-lookup.rst @@ -453,11 +453,12 @@ to find a definitive answer. As the last step of ``walk_component()``, ``step_into()`` will be called either directly from walk_component() or from handle_dots(). It calls ``handle_mounts()``, to check and handle mount points, in which a new -``struct path`` containing a counted reference to the new dentry and a -reference to the new ``vfsmount`` which is only counted if it is -different from the previous ``vfsmount``. It then calls -``path_to_nameidata()`` to install the new ``struct path`` in the -``struct nameidata`` and drop the unneeded references. +``struct path`` is created containing a counted reference to the new dentry and +a reference to the new ``vfsmount`` which is only counted if it is +different from the previous ``vfsmount``. Then if there is +a symbolic link, ``step_into()`` calls ``pick_link()`` to deal with it, +otherwise it installs the new ``struct path`` in the ``struct nameidata``, and +drops the unneeded references. This "hand-over-hand" sequencing of getting a reference to the new dentry before dropping the reference to the previous dentry may -- cgit v1.2.3 From 8593d2cc8c2f09164d674b2318661ede00dd4d0e Mon Sep 17 00:00:00 2001 From: Fox Chen Date: Thu, 27 May 2021 17:16:08 +0800 Subject: docs: path-lookup: update path_mountpoint() part path_mountpoint() doesn't exist anymore. Have been folded into path_lookup_at when flag is set with LOOKUP_MOUNTPOINT. Check commit: commit 161aff1d93abf0e ("LOOKUP_MOUNTPOINT: fold path_mountpointat() into path_lookupat()") Signed-off-by: Fox Chen Reviewed-by: NeilBrown Link: https://lore.kernel.org/r/20210527091618.287093-4-foxhlchen@gmail.com Signed-off-by: Jonathan Corbet --- Documentation/filesystems/path-lookup.rst | 12 +++++------- 1 file changed, 5 insertions(+), 7 deletions(-) (limited to 'Documentation') diff --git a/Documentation/filesystems/path-lookup.rst b/Documentation/filesystems/path-lookup.rst index 6ea0880fb982..652d3284f178 100644 --- a/Documentation/filesystems/path-lookup.rst +++ b/Documentation/filesystems/path-lookup.rst @@ -472,7 +472,7 @@ Handling the final component ``nd->last_type`` to refer to the final component of the path. It does not call ``walk_component()`` that last time. Handling that final component remains for the caller to sort out. Those callers are -``path_lookupat()``, ``path_parentat()``, ``path_mountpoint()`` and +``path_lookupat()``, ``path_parentat()`` and ``path_openat()`` each of which handles the differing requirements of different system calls. @@ -488,12 +488,10 @@ perform their operation. object is wanted such as by ``stat()`` or ``chmod()``. It essentially just calls ``walk_component()`` on the final component through a call to ``lookup_last()``. ``path_lookupat()`` returns just the final dentry. - -``path_mountpoint()`` handles the special case of unmounting which must -not try to revalidate the mounted filesystem. It effectively -contains, through a call to ``mountpoint_last()``, an alternate -implementation of ``lookup_slow()`` which skips that step. This is -important when unmounting a filesystem that is inaccessible, such as +It is worth noting that when flag ``LOOKUP_MOUNTPOINT`` is set, +``path_lookupat()`` will unset LOOKUP_JUMPED in nameidata so that in the +subsequent path traversal ``d_weak_revalidate()`` won't be called. +This is important when unmounting a filesystem that is inaccessible, such as one provided by a dead NFS server. Finally ``path_openat()`` is used for the ``open()`` system call; it -- cgit v1.2.3 From 71e0a67dc6c26018e27fe0c670e2db023aa72d22 Mon Sep 17 00:00:00 2001 From: Fox Chen Date: Thu, 27 May 2021 17:16:09 +0800 Subject: docs: path-lookup: update do_last() part traling_symlink() was merged into lookup_last, do_last(). do_last() has later been split into open_last_lookups() and do_open(). see related commit: commit c5971b8c6354 ("take post-lookup part of do_last() out of loop") Signed-off-by: Fox Chen Reviewed-by: NeilBrown Link: https://lore.kernel.org/r/20210527091618.287093-5-foxhlchen@gmail.com Signed-off-by: Jonathan Corbet --- Documentation/filesystems/path-lookup.rst | 47 +++++++++++++++---------------- 1 file changed, 22 insertions(+), 25 deletions(-) (limited to 'Documentation') diff --git a/Documentation/filesystems/path-lookup.rst b/Documentation/filesystems/path-lookup.rst index 652d3284f178..2b0b33168067 100644 --- a/Documentation/filesystems/path-lookup.rst +++ b/Documentation/filesystems/path-lookup.rst @@ -495,11 +495,11 @@ This is important when unmounting a filesystem that is inaccessible, such as one provided by a dead NFS server. Finally ``path_openat()`` is used for the ``open()`` system call; it -contains, in support functions starting with "``do_last()``", all the +contains, in support functions starting with "``open_last_lookups()``", all the complexity needed to handle the different subtleties of O_CREAT (with or without O_EXCL), final "``/``" characters, and trailing symbolic links. We will revisit this in the final part of this series, which -focuses on those symbolic links. "``do_last()``" will sometimes, but +focuses on those symbolic links. "``open_last_lookups()``" will sometimes, but not always, take ``i_rwsem``, depending on what it finds. Each of these, or the functions which call them, need to be alert to @@ -1196,29 +1196,26 @@ potentially need to call ``link_path_walk()`` again and again on successive symlinks until one is found that doesn't point to another symlink. -This case is handled by the relevant caller of ``link_path_walk()``, such as -``path_lookupat()`` using a loop that calls ``link_path_walk()``, and then -handles the final component. If the final component is a symlink -that needs to be followed, then ``trailing_symlink()`` is called to set -things up properly and the loop repeats, calling ``link_path_walk()`` -again. This could loop as many as 40 times if the last component of -each symlink is another symlink. - -The various functions that examine the final component and possibly -report that it is a symlink are ``lookup_last()``, ``mountpoint_last()`` -and ``do_last()``, each of which use the same convention as -``walk_component()`` of returning ``1`` if a symlink was found that needs -to be followed. - -Of these, ``do_last()`` is the most interesting as it is used for -opening a file. Part of ``do_last()`` runs with ``i_rwsem`` held and this -part is in a separate function: ``lookup_open()``. - -Explaining ``do_last()`` completely is beyond the scope of this article, -but a few highlights should help those interested in exploring the -code. - -1. Rather than just finding the target file, ``do_last()`` needs to open +This case is handled by relevant callers of ``link_path_walk()``, such as +``path_lookupat()``, ``path_openat()`` using a loop that calls ``link_path_walk()``, +and then handles the final component by calling ``open_last_lookups()`` or +``lookup_last()``. If it is a symlink that needs to be followed, +``open_last_lookups()`` or ``lookup_last()`` will set things up properly and +return the path so that the loop repeats, calling +``link_path_walk()`` again. This could loop as many as 40 times if the last +component of each symlink is another symlink. + +Of the various functions that examine the final component, +``open_last_lookups()`` is the most interesting as it works in tandem +with ``do_open()`` for opening a file. Part of ``open_last_lookups()`` runs +with ``i_rwsem`` held and this part is in a separate function: ``lookup_open()``. + +Explaining ``open_last_lookups()`` and ``do_open()`` completely is beyond the scope +of this article, but a few highlights should help those interested in exploring +the code. + +1. Rather than just finding the target file, ``do_open()`` is used after + ``open_last_lookup()`` to open it. If the file was found in the dcache, then ``vfs_open()`` is used for this. If not, then ``lookup_open()`` will either call ``atomic_open()`` (if the filesystem provides it) to combine the final lookup with the open, or -- cgit v1.2.3 From 34ef75ef25c6fdea899acdb0a466f8ed0c365644 Mon Sep 17 00:00:00 2001 From: Fox Chen Date: Thu, 27 May 2021 17:16:10 +0800 Subject: docs: path-lookup: remove filename_mountpoint No filename_mountpoint any more see commit: commit 161aff1d93ab ("LOOKUP_MOUNTPOINT: fold path_mountpointat() into path_lookupat()") Without filename_mountpoint and path_mountpoint(), the numbers should be four & three: "These four correspond roughly to the three path_*() functions" Signed-off-by: Fox Chen Reviewed-by: NeilBrown Link: https://lore.kernel.org/r/20210527091618.287093-6-foxhlchen@gmail.com Signed-off-by: Jonathan Corbet --- Documentation/filesystems/path-lookup.rst | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/filesystems/path-lookup.rst b/Documentation/filesystems/path-lookup.rst index 2b0b33168067..3cbaf30b0f83 100644 --- a/Documentation/filesystems/path-lookup.rst +++ b/Documentation/filesystems/path-lookup.rst @@ -652,9 +652,9 @@ restarts from the top with REF-walk. This pattern of "try RCU-walk, if that fails try REF-walk" can be clearly seen in functions like ``filename_lookup()``, -``filename_parentat()``, ``filename_mountpoint()``, -``do_filp_open()``, and ``do_file_open_root()``. These five -correspond roughly to the four ``path_*()`` functions we met earlier, +``filename_parentat()``, +``do_filp_open()``, and ``do_file_open_root()``. These four +correspond roughly to the three ``path_*()`` functions we met earlier, each of which calls ``link_path_walk()``. The ``path_*()`` functions are called using different mode flags until a mode is found which works. They are first called with ``LOOKUP_RCU`` set to request "RCU-walk". If -- cgit v1.2.3 From d2d3dd5ecce11ba560ff024e63ddb1640b7b27b0 Mon Sep 17 00:00:00 2001 From: Fox Chen Date: Thu, 27 May 2021 17:16:11 +0800 Subject: docs: path-lookup: Add macro name to symlink limit description Add macro name MAXSYMLINKS to the symlink limit description, so that it is consistent with path name length description above. Signed-off-by: Fox Chen Reviewed-by: NeilBrown Link: https://lore.kernel.org/r/20210527091618.287093-7-foxhlchen@gmail.com Signed-off-by: Jonathan Corbet --- Documentation/filesystems/path-lookup.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/filesystems/path-lookup.rst b/Documentation/filesystems/path-lookup.rst index 3cbaf30b0f83..40b9afec4d60 100644 --- a/Documentation/filesystems/path-lookup.rst +++ b/Documentation/filesystems/path-lookup.rst @@ -992,8 +992,8 @@ is 4096. There are a number of reasons for this limit; not letting the kernel spend too much time on just one path is one of them. With symbolic links you can effectively generate much longer paths so some sort of limit is needed for the same reason. Linux imposes a limit of -at most 40 symlinks in any one path lookup. It previously imposed a -further limit of eight on the maximum depth of recursion, but that was +at most 40 (MAXSYMLINKS) symlinks in any one path lookup. It previously imposed +a further limit of eight on the maximum depth of recursion, but that was raised to 40 when a separate stack was implemented, so there is now just the one limit. -- cgit v1.2.3 From 4a00e4bd59bbd5eac26f1792eb8d7d60f6cafe9a Mon Sep 17 00:00:00 2001 From: Fox Chen Date: Thu, 27 May 2021 17:16:12 +0800 Subject: docs: path-lookup: i_op->follow_link replaced with i_op->get_link follow_link has been replaced by get_link() which can be called in RCU mode. see commit: commit 6b2553918d8b ("replace ->follow_link() with new method that could stay in RCU mode") Signed-off-by: Fox Chen Reviewed-by: NeilBrown Link: https://lore.kernel.org/r/20210527091618.287093-8-foxhlchen@gmail.com Signed-off-by: Jonathan Corbet --- Documentation/filesystems/path-lookup.rst | 12 +++++------- 1 file changed, 5 insertions(+), 7 deletions(-) (limited to 'Documentation') diff --git a/Documentation/filesystems/path-lookup.rst b/Documentation/filesystems/path-lookup.rst index 40b9afec4d60..4650c6427963 100644 --- a/Documentation/filesystems/path-lookup.rst +++ b/Documentation/filesystems/path-lookup.rst @@ -1060,13 +1060,11 @@ filesystem cannot successfully get a reference in RCU-walk mode, it must return ``-ECHILD`` and ``unlazy_walk()`` will be called to return to REF-walk mode in which the filesystem is allowed to sleep. -The place for all this to happen is the ``i_op->follow_link()`` inode -method. In the present mainline code this is never actually called in -RCU-walk mode as the rewrite is not quite complete. It is likely that -in a future release this method will be passed an ``inode`` pointer when -called in RCU-walk mode so it both (1) knows to be careful, and (2) has the -validated pointer. Much like the ``i_op->permission()`` method we -looked at previously, ``->follow_link()`` would need to be careful that +The place for all this to happen is the ``i_op->get_link()`` inode +method. This is called both in RCU-walk and REF-walk. In RCU-walk the +``dentry*`` argument is NULL, ``->get_link()`` can return -ECHILD to drop out of +RCU-walk. Much like the ``i_op->permission()`` method we +looked at previously, ``->get_link()`` would need to be careful that all the data structures it references are safe to be accessed while holding no counted reference, only the RCU lock. Though getting a reference with ``->follow_link()`` is not yet done in RCU-walk mode, the -- cgit v1.2.3 From 671f73356f6a2aa2fb1bb71f8fdeeba858b6fec6 Mon Sep 17 00:00:00 2001 From: Fox Chen Date: Thu, 27 May 2021 17:16:13 +0800 Subject: docs: path-lookup: update i_op->put_link and cookie description No inode->put_link operation anymore. We use delayed_call to deal with link destruction. Cookie has been replaced with struct delayed_call. Related commit: commit fceef393a538 ("switch ->get_link() to delayed_call, kill ->put_link()") Signed-off-by: Fox Chen Reviewed-by: NeilBrown Link: https://lore.kernel.org/r/20210527091618.287093-9-foxhlchen@gmail.com Signed-off-by: Jonathan Corbet --- Documentation/filesystems/path-lookup.rst | 30 ++++++++---------------------- 1 file changed, 8 insertions(+), 22 deletions(-) (limited to 'Documentation') diff --git a/Documentation/filesystems/path-lookup.rst b/Documentation/filesystems/path-lookup.rst index 4650c6427963..3855809784cf 100644 --- a/Documentation/filesystems/path-lookup.rst +++ b/Documentation/filesystems/path-lookup.rst @@ -1066,34 +1066,20 @@ method. This is called both in RCU-walk and REF-walk. In RCU-walk the RCU-walk. Much like the ``i_op->permission()`` method we looked at previously, ``->get_link()`` would need to be careful that all the data structures it references are safe to be accessed while -holding no counted reference, only the RCU lock. Though getting a -reference with ``->follow_link()`` is not yet done in RCU-walk mode, the -code is ready to release the reference when that does happen. - -This need to drop the reference to a symlink adds significant -complexity. It requires a reference to the inode so that the -``i_op->put_link()`` inode operation can be called. In REF-walk, that -reference is kept implicitly through a reference to the dentry, so -keeping the ``struct path`` of the symlink is easiest. For RCU-walk, -the pointer to the inode is kept separately. To allow switching from -RCU-walk back to REF-walk in the middle of processing nested symlinks -we also need the seq number for the dentry so we can confirm that -switching back was safe. - -Finally, when providing a reference to a symlink, the filesystem also -provides an opaque "cookie" that must be passed to ``->put_link()`` so that it -knows what to free. This might be the allocated memory area, or a -pointer to the ``struct page`` in the page cache, or something else -completely. Only the filesystem knows what it is. +holding no counted reference, only the RCU lock. A callback +``struct delayed_called`` will be passed to ``->get_link()``: +file systems can set their own put_link function and argument through +``set_delayed_call()``. Later on, when VFS wants to put link, it will call +``do_delayed_call()`` to invoke that callback function with the argument. In order for the reference to each symlink to be dropped when the walk completes, whether in RCU-walk or REF-walk, the symlink stack needs to contain, along with the path remnants: -- the ``struct path`` to provide a reference to the inode in REF-walk -- the ``struct inode *`` to provide a reference to the inode in RCU-walk +- the ``struct path`` to provide a reference to the previous path +- the ``const char *`` to provide a reference to the to previous name - the ``seq`` to allow the path to be safely switched from RCU-walk to REF-walk -- the ``cookie`` that tells ``->put_path()`` what to put. +- the ``struct delayed_call`` for later invocation. This means that each entry in the symlink stack needs to hold five pointers and an integer instead of just one pointer (the path -- cgit v1.2.3 From 18edb95a88a947b10536be4dc86b4a190715f816 Mon Sep 17 00:00:00 2001 From: Fox Chen Date: Thu, 27 May 2021 17:16:14 +0800 Subject: docs: path-lookup: no get_link() no get_link() anymore. we have step_into() and pick_link(). walk_component() will call step_into(), in turn call pick_link, and return symlink name. Signed-off-by: Fox Chen Reviewed-by: NeilBrown Link: https://lore.kernel.org/r/20210527091618.287093-10-foxhlchen@gmail.com Signed-off-by: Jonathan Corbet --- Documentation/filesystems/path-lookup.rst | 10 ++++------ 1 file changed, 4 insertions(+), 6 deletions(-) (limited to 'Documentation') diff --git a/Documentation/filesystems/path-lookup.rst b/Documentation/filesystems/path-lookup.rst index 3855809784cf..0a125673a8fe 100644 --- a/Documentation/filesystems/path-lookup.rst +++ b/Documentation/filesystems/path-lookup.rst @@ -1103,12 +1103,10 @@ doesn't need to notice. Getting this ``name`` variable on and off the stack is very straightforward; pushing and popping the references is a little more complex. -When a symlink is found, ``walk_component()`` returns the value ``1`` -(``0`` is returned for any other sort of success, and a negative number -is, as usual, an error indicator). This causes ``get_link()`` to be -called; it then gets the link from the filesystem. Providing that -operation is successful, the old path ``name`` is placed on the stack, -and the new value is used as the ``name`` for a while. When the end of +When a symlink is found, ``walk_component()`` calls ``pick_link()`` via ``step_into()`` +which returns the link from the filesystem. +Providing that operation is successful, the old path ``name`` is placed on the +stack, and the new value is used as the ``name`` for a while. When the end of the path is found (i.e. ``*name`` is ``'\0'``) the old ``name`` is restored off the stack and path walking continues. -- cgit v1.2.3 From de9414adafe4da174212909e054222948aa620fc Mon Sep 17 00:00:00 2001 From: Fox Chen Date: Thu, 27 May 2021 17:16:15 +0800 Subject: docs: path-lookup: update WALK_GET, WALK_PUT desc WALK_GET is changed to WALK_TRAILING with a different meaning. Here it should be WALK_NOFOLLOW. WALK_PUT dosn't exist, we have WALK_MORE. WALK_PUT == !WALK_MORE And there is not should_follow_link(). Related commits: commit 8c4efe22e7c4 ("namei: invert the meaning of WALK_FOLLOW") commit 1c4ff1a87e46 ("namei: invert WALK_PUT logics") Signed-off-by: Fox Chen Reviewed-by: NeilBrown [jc: applied language tweaks suggested by Neil] Link: https://lore.kernel.org/r/20210527091618.287093-11-foxhlchen@gmail.com Signed-off-by: Jonathan Corbet --- Documentation/filesystems/path-lookup.rst | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) (limited to 'Documentation') diff --git a/Documentation/filesystems/path-lookup.rst b/Documentation/filesystems/path-lookup.rst index 0a125673a8fe..1102252cbc7a 100644 --- a/Documentation/filesystems/path-lookup.rst +++ b/Documentation/filesystems/path-lookup.rst @@ -1123,13 +1123,13 @@ stack in ``walk_component()`` immediately when the symlink is found; old symlink as it walks that last component. So it is quite convenient for ``walk_component()`` to release the old symlink and pop the references just before pushing the reference information for the -new symlink. It is guided in this by two flags; ``WALK_GET``, which -gives it permission to follow a symlink if it finds one, and -``WALK_PUT``, which tells it to release the current symlink after it has been -followed. ``WALK_PUT`` is tested first, leading to a call to -``put_link()``. ``WALK_GET`` is tested subsequently (by -``should_follow_link()``) leading to a call to ``pick_link()`` which sets -up the stack frame. +new symlink. It is guided in this by three flags: ``WALK_NOFOLLOW`` which +forbids it from following a symlink if it finds one, ``WALK_MORE`` +which indicates that it is yet too early to release the +current symlink, and ``WALK_TRAILING`` which indicates that it is on the final +component of the lookup, so we will check userspace flag ``LOOKUP_FOLLOW`` to +decide whether follow it when it is a symlink and call ``may_follow_link()`` to +check if we have privilege to follow it. Symlinks with no final component ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -- cgit v1.2.3 From 3c1be84b8d82959a6b7fedb598b8781fa1d09421 Mon Sep 17 00:00:00 2001 From: Fox Chen Date: Thu, 27 May 2021 17:16:16 +0800 Subject: docs: path-lookup: update get_link() ->follow_link description get_link() is merged into pick_link(). i_op->follow_link is replaced with i_op->get_link(). get_link() can return ERR_PTR(0) which equals NULL. Signed-off-by: Fox Chen Reviewed-by: NeilBrown Link: https://lore.kernel.org/r/20210527091618.287093-12-foxhlchen@gmail.com Signed-off-by: Jonathan Corbet --- Documentation/filesystems/path-lookup.rst | 13 ++++++------- 1 file changed, 6 insertions(+), 7 deletions(-) (limited to 'Documentation') diff --git a/Documentation/filesystems/path-lookup.rst b/Documentation/filesystems/path-lookup.rst index 1102252cbc7a..c150f076abbf 100644 --- a/Documentation/filesystems/path-lookup.rst +++ b/Documentation/filesystems/path-lookup.rst @@ -1136,10 +1136,10 @@ Symlinks with no final component A pair of special-case symlinks deserve a little further explanation. Both result in a new ``struct path`` (with mount and dentry) being set -up in the ``nameidata``, and result in ``get_link()`` returning ``NULL``. +up in the ``nameidata``, and result in ``pick_link()`` returning ``NULL``. The more obvious case is a symlink to "``/``". All symlinks starting -with "``/``" are detected in ``get_link()`` which resets the ``nameidata`` +with "``/``" are detected in ``pick_link()`` which resets the ``nameidata`` to point to the effective filesystem root. If the symlink only contains "``/``" then there is nothing more to do, no components at all, so ``NULL`` is returned to indicate that the symlink can be released and @@ -1156,12 +1156,11 @@ something that looks like a symlink. It is really a reference to the target file, not just the name of it. When you ``readlink`` these objects you get a name that might refer to the same file - unless it has been unlinked or mounted over. When ``walk_component()`` follows -one of these, the ``->follow_link()`` method in "procfs" doesn't return +one of these, the ``->get_link()`` method in "procfs" doesn't return a string name, but instead calls ``nd_jump_link()`` which updates the -``nameidata`` in place to point to that target. ``->follow_link()`` then -returns ``NULL``. Again there is no final component and ``get_link()`` -reports this by leaving the ``last_type`` field of ``nameidata`` as -``LAST_BIND``. +``nameidata`` in place to point to that target. ``->get_link()`` then +returns ``NULL``. Again there is no final component and ``pick_link()`` +returns ``NULL``. Following the symlink in the final component -------------------------------------------- -- cgit v1.2.3 From ef4aa53f36a932e656a3b91cdc8a9a9dcb9cef81 Mon Sep 17 00:00:00 2001 From: Fox Chen Date: Thu, 27 May 2021 17:16:17 +0800 Subject: docs: path-lookup: update symlink description instead of lookup_real()/vfs_create(), i_op->lookup() and i_op->create() will be called directly. update vfs_open() logic should_follow_link is merged into lookup_last() or open_last_lookup() which returns symlink name instead of an integer. Signed-off-by: Fox Chen Reviewed-by: NeilBrown Link: https://lore.kernel.org/r/20210527091618.287093-13-foxhlchen@gmail.com Signed-off-by: Jonathan Corbet --- Documentation/filesystems/path-lookup.rst | 13 ++++++------- 1 file changed, 6 insertions(+), 7 deletions(-) (limited to 'Documentation') diff --git a/Documentation/filesystems/path-lookup.rst b/Documentation/filesystems/path-lookup.rst index c150f076abbf..b746e974393a 100644 --- a/Documentation/filesystems/path-lookup.rst +++ b/Documentation/filesystems/path-lookup.rst @@ -1200,16 +1200,15 @@ the code. it. If the file was found in the dcache, then ``vfs_open()`` is used for this. If not, then ``lookup_open()`` will either call ``atomic_open()`` (if the filesystem provides it) to combine the final lookup with the open, or - will perform the separate ``lookup_real()`` and ``vfs_create()`` steps + will perform the separate ``i_op->lookup()`` and ``i_op->create()`` steps directly. In the later case the actual "open" of this newly found or created file will be performed by ``vfs_open()``, just as if the name were found in the dcache. 2. ``vfs_open()`` can fail with ``-EOPENSTALE`` if the cached information - wasn't quite current enough. Rather than restarting the lookup from - the top with ``LOOKUP_REVAL`` set, ``lookup_open()`` is called instead, - giving the filesystem a chance to resolve small inconsistencies. - If that doesn't work, only then is the lookup restarted from the top. + wasn't quite current enough. If it's in RCU-walk ``-ECHILD`` will be returned + otherwise ``-ESTALE`` is returned. When ``-ESTALE`` is returned, the caller may + retry with ``LOOKUP_REVAL`` flag set. 3. An open with O_CREAT **does** follow a symlink in the final component, unlike other creation system calls (like ``mkdir``). So the sequence:: @@ -1219,8 +1218,8 @@ the code. will create a file called ``/tmp/bar``. This is not permitted if ``O_EXCL`` is set but otherwise is handled for an O_CREAT open much - like for a non-creating open: ``should_follow_link()`` returns ``1``, and - so does ``do_last()`` so that ``trailing_symlink()`` gets called and the + like for a non-creating open: ``lookup_last()`` or ``open_last_lookup()`` + returns a non ``NULL`` value, and ``link_path_walk()`` gets called and the open process continues on the symlink that was found. Updating the access time -- cgit v1.2.3 From 8943474a416c0d2eac2366c22be1458ad0ceb812 Mon Sep 17 00:00:00 2001 From: Fox Chen Date: Thu, 27 May 2021 17:16:18 +0800 Subject: docs: path-lookup: use bare function() rather than literals As suggested by Matthew Wilcox and Jonathan Corbet, drop ``...`` literals around function names of this patchset. Signed-off-by: Fox Chen Reviewed-by: NeilBrown Link: https://lore.kernel.org/r/20210527091618.287093-14-foxhlchen@gmail.com Signed-off-by: Jonathan Corbet --- Documentation/filesystems/path-lookup.rst | 70 +++++++++++++++---------------- 1 file changed, 35 insertions(+), 35 deletions(-) (limited to 'Documentation') diff --git a/Documentation/filesystems/path-lookup.rst b/Documentation/filesystems/path-lookup.rst index b746e974393a..a6fa7619b69e 100644 --- a/Documentation/filesystems/path-lookup.rst +++ b/Documentation/filesystems/path-lookup.rst @@ -450,13 +450,13 @@ If that doesn't get a good result, it calls "``lookup_slow()``" which takes ``i_rwsem``, rechecks the cache, and then asks the filesystem to find a definitive answer. -As the last step of ``walk_component()``, ``step_into()`` will be called either +As the last step of walk_component(), step_into() will be called either directly from walk_component() or from handle_dots(). It calls -``handle_mounts()``, to check and handle mount points, in which a new +handle_mounts(), to check and handle mount points, in which a new ``struct path`` is created containing a counted reference to the new dentry and a reference to the new ``vfsmount`` which is only counted if it is different from the previous ``vfsmount``. Then if there is -a symbolic link, ``step_into()`` calls ``pick_link()`` to deal with it, +a symbolic link, step_into() calls pick_link() to deal with it, otherwise it installs the new ``struct path`` in the ``struct nameidata``, and drops the unneeded references. @@ -472,8 +472,8 @@ Handling the final component ``nd->last_type`` to refer to the final component of the path. It does not call ``walk_component()`` that last time. Handling that final component remains for the caller to sort out. Those callers are -``path_lookupat()``, ``path_parentat()`` and -``path_openat()`` each of which handles the differing requirements of +path_lookupat(), path_parentat() and +path_openat() each of which handles the differing requirements of different system calls. ``path_parentat()`` is clearly the simplest - it just wraps a little bit @@ -489,17 +489,17 @@ object is wanted such as by ``stat()`` or ``chmod()``. It essentially just calls ``walk_component()`` on the final component through a call to ``lookup_last()``. ``path_lookupat()`` returns just the final dentry. It is worth noting that when flag ``LOOKUP_MOUNTPOINT`` is set, -``path_lookupat()`` will unset LOOKUP_JUMPED in nameidata so that in the -subsequent path traversal ``d_weak_revalidate()`` won't be called. +path_lookupat() will unset LOOKUP_JUMPED in nameidata so that in the +subsequent path traversal d_weak_revalidate() won't be called. This is important when unmounting a filesystem that is inaccessible, such as one provided by a dead NFS server. Finally ``path_openat()`` is used for the ``open()`` system call; it -contains, in support functions starting with "``open_last_lookups()``", all the +contains, in support functions starting with "open_last_lookups()", all the complexity needed to handle the different subtleties of O_CREAT (with or without O_EXCL), final "``/``" characters, and trailing symbolic links. We will revisit this in the final part of this series, which -focuses on those symbolic links. "``open_last_lookups()``" will sometimes, but +focuses on those symbolic links. "open_last_lookups()" will sometimes, but not always, take ``i_rwsem``, depending on what it finds. Each of these, or the functions which call them, need to be alert to @@ -651,9 +651,9 @@ RCU-walk finds it cannot stop gracefully, it simply gives up and restarts from the top with REF-walk. This pattern of "try RCU-walk, if that fails try REF-walk" can be -clearly seen in functions like ``filename_lookup()``, -``filename_parentat()``, -``do_filp_open()``, and ``do_file_open_root()``. These four +clearly seen in functions like filename_lookup(), +filename_parentat(), +do_filp_open(), and do_file_open_root(). These four correspond roughly to the three ``path_*()`` functions we met earlier, each of which calls ``link_path_walk()``. The ``path_*()`` functions are called using different mode flags until a mode is found which works. @@ -1069,8 +1069,8 @@ all the data structures it references are safe to be accessed while holding no counted reference, only the RCU lock. A callback ``struct delayed_called`` will be passed to ``->get_link()``: file systems can set their own put_link function and argument through -``set_delayed_call()``. Later on, when VFS wants to put link, it will call -``do_delayed_call()`` to invoke that callback function with the argument. +set_delayed_call(). Later on, when VFS wants to put link, it will call +do_delayed_call() to invoke that callback function with the argument. In order for the reference to each symlink to be dropped when the walk completes, whether in RCU-walk or REF-walk, the symlink stack needs to contain, @@ -1103,7 +1103,7 @@ doesn't need to notice. Getting this ``name`` variable on and off the stack is very straightforward; pushing and popping the references is a little more complex. -When a symlink is found, ``walk_component()`` calls ``pick_link()`` via ``step_into()`` +When a symlink is found, walk_component() calls pick_link() via step_into() which returns the link from the filesystem. Providing that operation is successful, the old path ``name`` is placed on the stack, and the new value is used as the ``name`` for a while. When the end of @@ -1136,10 +1136,10 @@ Symlinks with no final component A pair of special-case symlinks deserve a little further explanation. Both result in a new ``struct path`` (with mount and dentry) being set -up in the ``nameidata``, and result in ``pick_link()`` returning ``NULL``. +up in the ``nameidata``, and result in pick_link() returning ``NULL``. The more obvious case is a symlink to "``/``". All symlinks starting -with "``/``" are detected in ``pick_link()`` which resets the ``nameidata`` +with "``/``" are detected in pick_link() which resets the ``nameidata`` to point to the effective filesystem root. If the symlink only contains "``/``" then there is nothing more to do, no components at all, so ``NULL`` is returned to indicate that the symlink can be released and @@ -1157,9 +1157,9 @@ target file, not just the name of it. When you ``readlink`` these objects you get a name that might refer to the same file - unless it has been unlinked or mounted over. When ``walk_component()`` follows one of these, the ``->get_link()`` method in "procfs" doesn't return -a string name, but instead calls ``nd_jump_link()`` which updates the +a string name, but instead calls nd_jump_link() which updates the ``nameidata`` in place to point to that target. ``->get_link()`` then -returns ``NULL``. Again there is no final component and ``pick_link()`` +returns ``NULL``. Again there is no final component and pick_link() returns ``NULL``. Following the symlink in the final component @@ -1177,35 +1177,35 @@ potentially need to call ``link_path_walk()`` again and again on successive symlinks until one is found that doesn't point to another symlink. -This case is handled by relevant callers of ``link_path_walk()``, such as -``path_lookupat()``, ``path_openat()`` using a loop that calls ``link_path_walk()``, -and then handles the final component by calling ``open_last_lookups()`` or -``lookup_last()``. If it is a symlink that needs to be followed, -``open_last_lookups()`` or ``lookup_last()`` will set things up properly and +This case is handled by relevant callers of link_path_walk(), such as +path_lookupat(), path_openat() using a loop that calls link_path_walk(), +and then handles the final component by calling open_last_lookups() or +lookup_last(). If it is a symlink that needs to be followed, +open_last_lookups() or lookup_last() will set things up properly and return the path so that the loop repeats, calling -``link_path_walk()`` again. This could loop as many as 40 times if the last +link_path_walk() again. This could loop as many as 40 times if the last component of each symlink is another symlink. Of the various functions that examine the final component, -``open_last_lookups()`` is the most interesting as it works in tandem -with ``do_open()`` for opening a file. Part of ``open_last_lookups()`` runs -with ``i_rwsem`` held and this part is in a separate function: ``lookup_open()``. +open_last_lookups() is the most interesting as it works in tandem +with do_open() for opening a file. Part of open_last_lookups() runs +with ``i_rwsem`` held and this part is in a separate function: lookup_open(). -Explaining ``open_last_lookups()`` and ``do_open()`` completely is beyond the scope +Explaining open_last_lookups() and do_open() completely is beyond the scope of this article, but a few highlights should help those interested in exploring the code. -1. Rather than just finding the target file, ``do_open()`` is used after - ``open_last_lookup()`` to open +1. Rather than just finding the target file, do_open() is used after + open_last_lookup() to open it. If the file was found in the dcache, then ``vfs_open()`` is used for this. If not, then ``lookup_open()`` will either call ``atomic_open()`` (if the filesystem provides it) to combine the final lookup with the open, or will perform the separate ``i_op->lookup()`` and ``i_op->create()`` steps directly. In the later case the actual "open" of this newly found or - created file will be performed by ``vfs_open()``, just as if the name + created file will be performed by vfs_open(), just as if the name were found in the dcache. -2. ``vfs_open()`` can fail with ``-EOPENSTALE`` if the cached information +2. vfs_open() can fail with ``-EOPENSTALE`` if the cached information wasn't quite current enough. If it's in RCU-walk ``-ECHILD`` will be returned otherwise ``-ESTALE`` is returned. When ``-ESTALE`` is returned, the caller may retry with ``LOOKUP_REVAL`` flag set. @@ -1218,8 +1218,8 @@ the code. will create a file called ``/tmp/bar``. This is not permitted if ``O_EXCL`` is set but otherwise is handled for an O_CREAT open much - like for a non-creating open: ``lookup_last()`` or ``open_last_lookup()`` - returns a non ``NULL`` value, and ``link_path_walk()`` gets called and the + like for a non-creating open: lookup_last() or open_last_lookup() + returns a non ``NULL`` value, and link_path_walk() gets called and the open process continues on the symlink that was found. Updating the access time -- cgit v1.2.3 From 79ab2b37034b7790bd598597faddf689f5b10676 Mon Sep 17 00:00:00 2001 From: Ioana Ciornei Date: Thu, 17 Jun 2021 18:55:51 +0300 Subject: Documentation: ACPI: DSD: include phy.rst in the toctree Include the new phy.rst into the index of the ACPI support documentation. Fixes: e71305acd81c ("Documentation: ACPI: DSD: Document MDIO PHY") Reported-by: Stephen Rothwell Signed-off-by: Ioana Ciornei Signed-off-by: David S. Miller --- Documentation/firmware-guide/acpi/index.rst | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/firmware-guide/acpi/index.rst b/Documentation/firmware-guide/acpi/index.rst index f72b5f1769fb..a99ee402b212 100644 --- a/Documentation/firmware-guide/acpi/index.rst +++ b/Documentation/firmware-guide/acpi/index.rst @@ -11,6 +11,7 @@ ACPI Support dsd/graph dsd/data-node-references dsd/leds + dsd/phy enumeration osi method-customizing -- cgit v1.2.3 From 5a336f97f1f5011cdca5467ef96372fd6d2fd128 Mon Sep 17 00:00:00 2001 From: Ioana Ciornei Date: Thu, 17 Jun 2021 18:55:52 +0300 Subject: Documentation: ACPI: DSD: fix block code comments Use the '.. code-block:: none' to properly highlight the documented DSDT entries. This also fixes warnings in the documentation build process. Fixes: e71305acd81c ("Documentation: ACPI: DSD: Document MDIO PHY") Reported-by: Stephen Rothwell Signed-off-by: Ioana Ciornei Signed-off-by: David S. Miller --- Documentation/firmware-guide/acpi/dsd/phy.rst | 15 +++++++++++---- 1 file changed, 11 insertions(+), 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/firmware-guide/acpi/dsd/phy.rst b/Documentation/firmware-guide/acpi/dsd/phy.rst index 7d01ae8b3cc6..0d49bad2ea9c 100644 --- a/Documentation/firmware-guide/acpi/dsd/phy.rst +++ b/Documentation/firmware-guide/acpi/dsd/phy.rst @@ -27,7 +27,8 @@ network interfaces that have PHYs connected to MAC via MDIO bus. During the MDIO bus driver initialization, PHYs on this bus are probed using the _ADR object as shown below and are registered on the MDIO bus. -:: +.. code-block:: none + Scope(\_SB.MDI0) { Device(PHY1) { @@ -60,7 +61,9 @@ component (PHYs on the MDIO bus). a) Silicon Component This node describes the MDIO controller, MDI0 --------------------------------------------- -:: + +.. code-block:: none + Scope(_SB) { Device(MDI0) { @@ -80,7 +83,9 @@ This node describes the MDIO controller, MDI0 b) Platform Component The PHY1 and PHY2 nodes represent the PHYs connected to MDIO bus MDI0 --------------------------------------------------------------------- -:: + +.. code-block:: none + Scope(\_SB.MDI0) { Device(PHY1) { @@ -98,7 +103,9 @@ DSDT entries representing MAC nodes Below are the MAC nodes where PHY nodes are referenced. phy-mode and phy-handle are used as explained earlier. ------------------------------------------------------ -:: + +.. code-block:: none + Scope(\_SB.MCE0.PR17) { Name (_DSD, Package () { -- cgit v1.2.3 From fc3c82eebf8e2e193412612f509530b4ff5611bf Mon Sep 17 00:00:00 2001 From: Geliang Tang Date: Thu, 17 Jun 2021 16:46:19 -0700 Subject: mptcp: add a new sysctl checksum_enabled This patch added a new sysctl, named checksum_enabled, to control whether DSS checksum can be enabled. Acked-by: Paolo Abeni Co-developed-by: Matthieu Baerts Signed-off-by: Matthieu Baerts Signed-off-by: Geliang Tang Signed-off-by: Mat Martineau Signed-off-by: David S. Miller --- Documentation/networking/mptcp-sysctl.rst | 8 ++++++++ 1 file changed, 8 insertions(+) (limited to 'Documentation') diff --git a/Documentation/networking/mptcp-sysctl.rst b/Documentation/networking/mptcp-sysctl.rst index 3b352e5f6300..ee06fd782465 100644 --- a/Documentation/networking/mptcp-sysctl.rst +++ b/Documentation/networking/mptcp-sysctl.rst @@ -24,3 +24,11 @@ add_addr_timeout - INTEGER (seconds) sysctl. Default: 120 + +checksum_enabled - BOOLEAN + Control whether DSS checksum can be enabled. + + DSS checksum can be enabled if the value is nonzero. This is a + per-namespace sysctl. + + Default: 0 -- cgit v1.2.3 From 68277749a0133fa6f9f5ec8576691e5fc9718610 Mon Sep 17 00:00:00 2001 From: Qing Zhang Date: Fri, 18 Jun 2021 10:53:37 +0800 Subject: dt-bindings: dwmac: Add bindings for new Loongson SoC and bridge chip Add the dwmac bindings for the Loongson-2K SoC and the LS7A bridge chip. Signed-off-by: Qing Zhang Signed-off-by: David S. Miller --- Documentation/devicetree/bindings/net/snps,dwmac.yaml | 6 ++++++ 1 file changed, 6 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/snps,dwmac.yaml b/Documentation/devicetree/bindings/net/snps,dwmac.yaml index 9c0ce92e9212..56f2235f5fb5 100644 --- a/Documentation/devicetree/bindings/net/snps,dwmac.yaml +++ b/Documentation/devicetree/bindings/net/snps,dwmac.yaml @@ -51,11 +51,15 @@ properties: - allwinner,sun8i-r40-emac - allwinner,sun8i-v3s-emac - allwinner,sun50i-a64-emac + - loongson,ls2k-dwmac + - loongson,ls7a-dwmac - amlogic,meson6-dwmac - amlogic,meson8b-dwmac - amlogic,meson8m2-dwmac - amlogic,meson-gxbb-dwmac - amlogic,meson-axg-dwmac + - loongson,ls2k-dwmac + - loongson,ls7a-dwmac - ingenic,jz4775-mac - ingenic,x1000-mac - ingenic,x1600-mac @@ -363,6 +367,8 @@ allOf: - allwinner,sun8i-r40-emac - allwinner,sun8i-v3s-emac - allwinner,sun50i-a64-emac + - loongson,ls2k-dwmac + - loongson,ls7a-dwmac - ingenic,jz4775-mac - ingenic,x1000-mac - ingenic,x1600-mac -- cgit v1.2.3 From f42cfb469f9b4a1c002a03cce3d9329376800a6f Mon Sep 17 00:00:00 2001 From: Grant Seltzer Date: Fri, 18 Jun 2021 14:04:59 +0000 Subject: bpf: Add documentation for libbpf including API autogen This patch is meant to start the initiative to document libbpf. It includes .rst files which are text documentation describing building, API naming convention, as well as an index to generated API documentation. In this approach the generated API documentation is enabled by the kernels existing kernel documentation system which uses sphinx. The resulting docs would then be synced to kernel.org/doc You can test this by running `make htmldocs` and serving the html in Documentation/output. Since libbpf does not yet have comments in kernel doc format, see kernel.org/doc/html/latest/doc-guide/kernel-doc.html for an example so you can test this. The advantage of this approach is to use the existing sphinx infrastructure that the kernel has, and have libbpf docs in the same place as everything else. The current plan is to have the libbpf mirror sync the generated docs and version them based on the libbpf releases which are cut on github. This patch includes the addition of libbpf_api.rst which pulls comment documentation from header files in libbpf under tools/lib/bpf/. The comment docs would be of the standard kernel doc format. Signed-off-by: Grant Seltzer Signed-off-by: Andrii Nakryiko Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20210618140459.9887-2-grantseltzer@gmail.com --- Documentation/bpf/index.rst | 13 ++ Documentation/bpf/libbpf/libbpf.rst | 14 ++ Documentation/bpf/libbpf/libbpf_api.rst | 27 ++++ Documentation/bpf/libbpf/libbpf_build.rst | 37 +++++ .../bpf/libbpf/libbpf_naming_convention.rst | 162 +++++++++++++++++++++ 5 files changed, 253 insertions(+) create mode 100644 Documentation/bpf/libbpf/libbpf.rst create mode 100644 Documentation/bpf/libbpf/libbpf_api.rst create mode 100644 Documentation/bpf/libbpf/libbpf_build.rst create mode 100644 Documentation/bpf/libbpf/libbpf_naming_convention.rst (limited to 'Documentation') diff --git a/Documentation/bpf/index.rst b/Documentation/bpf/index.rst index 93e8cf12a6d4..baea6c2abba5 100644 --- a/Documentation/bpf/index.rst +++ b/Documentation/bpf/index.rst @@ -12,6 +12,19 @@ BPF instruction-set. The Cilium project also maintains a `BPF and XDP Reference Guide`_ that goes into great technical depth about the BPF Architecture. +libbpf +====== + +Libbpf is a userspace library for loading and interacting with bpf programs. + +.. toctree:: + :maxdepth: 1 + + libbpf/libbpf + libbpf/libbpf_api + libbpf/libbpf_build + libbpf/libbpf_naming_convention + BPF Type Format (BTF) ===================== diff --git a/Documentation/bpf/libbpf/libbpf.rst b/Documentation/bpf/libbpf/libbpf.rst new file mode 100644 index 000000000000..1b1e61d5ead1 --- /dev/null +++ b/Documentation/bpf/libbpf/libbpf.rst @@ -0,0 +1,14 @@ +.. SPDX-License-Identifier: (LGPL-2.1 OR BSD-2-Clause) + +libbpf +====== + +This is documentation for libbpf, a userspace library for loading and +interacting with bpf programs. + +All general BPF questions, including kernel functionality, libbpf APIs and +their application, should be sent to bpf@vger.kernel.org mailing list. +You can `subscribe `_ to the +mailing list search its `archive `_. +Please search the archive before asking new questions. It very well might +be that this was already addressed or answered before. diff --git a/Documentation/bpf/libbpf/libbpf_api.rst b/Documentation/bpf/libbpf/libbpf_api.rst new file mode 100644 index 000000000000..f07eecd054da --- /dev/null +++ b/Documentation/bpf/libbpf/libbpf_api.rst @@ -0,0 +1,27 @@ +.. SPDX-License-Identifier: (LGPL-2.1 OR BSD-2-Clause) + +API +=== + +This documentation is autogenerated from header files in libbpf, tools/lib/bpf + +.. kernel-doc:: tools/lib/bpf/libbpf.h + :internal: + +.. kernel-doc:: tools/lib/bpf/bpf.h + :internal: + +.. kernel-doc:: tools/lib/bpf/btf.h + :internal: + +.. kernel-doc:: tools/lib/bpf/xsk.h + :internal: + +.. kernel-doc:: tools/lib/bpf/bpf_tracing.h + :internal: + +.. kernel-doc:: tools/lib/bpf/bpf_core_read.h + :internal: + +.. kernel-doc:: tools/lib/bpf/bpf_endian.h + :internal: \ No newline at end of file diff --git a/Documentation/bpf/libbpf/libbpf_build.rst b/Documentation/bpf/libbpf/libbpf_build.rst new file mode 100644 index 000000000000..8e8c23e8093d --- /dev/null +++ b/Documentation/bpf/libbpf/libbpf_build.rst @@ -0,0 +1,37 @@ +.. SPDX-License-Identifier: (LGPL-2.1 OR BSD-2-Clause) + +Building libbpf +=============== + +libelf and zlib are internal dependencies of libbpf and thus are required to link +against and must be installed on the system for applications to work. +pkg-config is used by default to find libelf, and the program called +can be overridden with PKG_CONFIG. + +If using pkg-config at build time is not desired, it can be disabled by +setting NO_PKG_CONFIG=1 when calling make. + +To build both static libbpf.a and shared libbpf.so: + +.. code-block:: bash + + $ cd src + $ make + +To build only static libbpf.a library in directory build/ and install them +together with libbpf headers in a staging directory root/: + +.. code-block:: bash + + $ cd src + $ mkdir build root + $ BUILD_STATIC_ONLY=y OBJDIR=build DESTDIR=root make install + +To build both static libbpf.a and shared libbpf.so against a custom libelf +dependency installed in /build/root/ and install them together with libbpf +headers in a build directory /build/root/: + +.. code-block:: bash + + $ cd src + $ PKG_CONFIG_PATH=/build/root/lib64/pkgconfig DESTDIR=/build/root make \ No newline at end of file diff --git a/Documentation/bpf/libbpf/libbpf_naming_convention.rst b/Documentation/bpf/libbpf/libbpf_naming_convention.rst new file mode 100644 index 000000000000..3de1d51e41da --- /dev/null +++ b/Documentation/bpf/libbpf/libbpf_naming_convention.rst @@ -0,0 +1,162 @@ +.. SPDX-License-Identifier: (LGPL-2.1 OR BSD-2-Clause) + +API naming convention +===================== + +libbpf API provides access to a few logically separated groups of +functions and types. Every group has its own naming convention +described here. It's recommended to follow these conventions whenever a +new function or type is added to keep libbpf API clean and consistent. + +All types and functions provided by libbpf API should have one of the +following prefixes: ``bpf_``, ``btf_``, ``libbpf_``, ``xsk_``, +``btf_dump_``, ``ring_buffer_``, ``perf_buffer_``. + +System call wrappers +-------------------- + +System call wrappers are simple wrappers for commands supported by +sys_bpf system call. These wrappers should go to ``bpf.h`` header file +and map one to one to corresponding commands. + +For example ``bpf_map_lookup_elem`` wraps ``BPF_MAP_LOOKUP_ELEM`` +command of sys_bpf, ``bpf_prog_attach`` wraps ``BPF_PROG_ATTACH``, etc. + +Objects +------- + +Another class of types and functions provided by libbpf API is "objects" +and functions to work with them. Objects are high-level abstractions +such as BPF program or BPF map. They're represented by corresponding +structures such as ``struct bpf_object``, ``struct bpf_program``, +``struct bpf_map``, etc. + +Structures are forward declared and access to their fields should be +provided via corresponding getters and setters rather than directly. + +These objects are associated with corresponding parts of ELF object that +contains compiled BPF programs. + +For example ``struct bpf_object`` represents ELF object itself created +from an ELF file or from a buffer, ``struct bpf_program`` represents a +program in ELF object and ``struct bpf_map`` is a map. + +Functions that work with an object have names built from object name, +double underscore and part that describes function purpose. + +For example ``bpf_object__open`` consists of the name of corresponding +object, ``bpf_object``, double underscore and ``open`` that defines the +purpose of the function to open ELF file and create ``bpf_object`` from +it. + +All objects and corresponding functions other than BTF related should go +to ``libbpf.h``. BTF types and functions should go to ``btf.h``. + +Auxiliary functions +------------------- + +Auxiliary functions and types that don't fit well in any of categories +described above should have ``libbpf_`` prefix, e.g. +``libbpf_get_error`` or ``libbpf_prog_type_by_name``. + +AF_XDP functions +------------------- + +AF_XDP functions should have an ``xsk_`` prefix, e.g. +``xsk_umem__get_data`` or ``xsk_umem__create``. The interface consists +of both low-level ring access functions and high-level configuration +functions. These can be mixed and matched. Note that these functions +are not reentrant for performance reasons. + +ABI +========== + +libbpf can be both linked statically or used as DSO. To avoid possible +conflicts with other libraries an application is linked with, all +non-static libbpf symbols should have one of the prefixes mentioned in +API documentation above. See API naming convention to choose the right +name for a new symbol. + +Symbol visibility +----------------- + +libbpf follow the model when all global symbols have visibility "hidden" +by default and to make a symbol visible it has to be explicitly +attributed with ``LIBBPF_API`` macro. For example: + +.. code-block:: c + + LIBBPF_API int bpf_prog_get_fd_by_id(__u32 id); + +This prevents from accidentally exporting a symbol, that is not supposed +to be a part of ABI what, in turn, improves both libbpf developer- and +user-experiences. + +ABI versionning +--------------- + +To make future ABI extensions possible libbpf ABI is versioned. +Versioning is implemented by ``libbpf.map`` version script that is +passed to linker. + +Version name is ``LIBBPF_`` prefix + three-component numeric version, +starting from ``0.0.1``. + +Every time ABI is being changed, e.g. because a new symbol is added or +semantic of existing symbol is changed, ABI version should be bumped. +This bump in ABI version is at most once per kernel development cycle. + +For example, if current state of ``libbpf.map`` is: + +.. code-block:: c + + LIBBPF_0.0.1 { + global: + bpf_func_a; + bpf_func_b; + local: + \*; + }; + +, and a new symbol ``bpf_func_c`` is being introduced, then +``libbpf.map`` should be changed like this: + +.. code-block:: c + + LIBBPF_0.0.1 { + global: + bpf_func_a; + bpf_func_b; + local: + \*; + }; + LIBBPF_0.0.2 { + global: + bpf_func_c; + } LIBBPF_0.0.1; + +, where new version ``LIBBPF_0.0.2`` depends on the previous +``LIBBPF_0.0.1``. + +Format of version script and ways to handle ABI changes, including +incompatible ones, described in details in [1]. + +Stand-alone build +------------------- + +Under https://github.com/libbpf/libbpf there is a (semi-)automated +mirror of the mainline's version of libbpf for a stand-alone build. + +However, all changes to libbpf's code base must be upstreamed through +the mainline kernel tree. + +License +------------------- + +libbpf is dual-licensed under LGPL 2.1 and BSD 2-Clause. + +Links +------------------- + +[1] https://www.akkadia.org/drepper/dsohowto.pdf + (Chapter 3. Maintaining APIs and ABIs). -- cgit v1.2.3 From 5fd953a3f6e25859ad1633ccd9f6320f1067a46d Mon Sep 17 00:00:00 2001 From: Rodrigo Siqueira Date: Tue, 8 Jun 2021 13:37:18 -0400 Subject: drm/amd/display: Add Freesync video documentation Recently, we added support for an experimental feature named Freesync video; for more details on that, refer to: commit 6f59f229f8ed ("drm/amd/display: Skip modeset for front porch change") commit d10cd527f5e5 ("drm/amd/display: Add freesync video modes based on preferred modes") commit 0eb1af2e8205 ("drm/amd/display: Add module parameter for freesync video mode") Nevertheless, we did not document it in detail in our driver. This commit introduces a kernel-doc and expands the module parameter description. Cc: Aurabindo Pillai Cc: Sean Paul Cc: Harry Wentland Signed-off-by: Rodrigo Siqueira Reviewed by: Aurabindo Pillai Signed-off-by: Alex Deucher --- Documentation/gpu/amdgpu-dc.rst | 6 ++++++ 1 file changed, 6 insertions(+) (limited to 'Documentation') diff --git a/Documentation/gpu/amdgpu-dc.rst b/Documentation/gpu/amdgpu-dc.rst index cc89b0fc11df..f7ff7e1309de 100644 --- a/Documentation/gpu/amdgpu-dc.rst +++ b/Documentation/gpu/amdgpu-dc.rst @@ -66,3 +66,9 @@ Display Core ============ **WIP** + +FreeSync Video +-------------- + +.. kernel-doc:: drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c + :doc: FreeSync Video -- cgit v1.2.3 From 3078d964c0fe6cf8eba197c862d1011cb7c0e7b4 Mon Sep 17 00:00:00 2001 From: Oz Shlomo Date: Thu, 17 Jun 2021 09:50:06 +0300 Subject: docs: networking: Update connection tracking offload sysctl parameters Document the following connection offload configuration parameters: - nf_flowtable_tcp_timeout - nf_flowtable_tcp_pickup - nf_flowtable_udp_timeout - nf_flowtable_udp_pickup Signed-off-by: Oz Shlomo Signed-off-by: Pablo Neira Ayuso --- Documentation/networking/nf_conntrack-sysctl.rst | 24 ++++++++++++++++++++++++ 1 file changed, 24 insertions(+) (limited to 'Documentation') diff --git a/Documentation/networking/nf_conntrack-sysctl.rst b/Documentation/networking/nf_conntrack-sysctl.rst index 11a9b76786cb..0467b30e4abe 100644 --- a/Documentation/networking/nf_conntrack-sysctl.rst +++ b/Documentation/networking/nf_conntrack-sysctl.rst @@ -177,3 +177,27 @@ nf_conntrack_gre_timeout_stream - INTEGER (seconds) This extended timeout will be used in case there is an GRE stream detected. + +nf_flowtable_tcp_timeout - INTEGER (seconds) + default 30 + + Control offload timeout for tcp connections. + TCP connections may be offloaded from nf conntrack to nf flow table. + Once aged, the connection is returned to nf conntrack with tcp pickup timeout. + +nf_flowtable_tcp_pickup - INTEGER (seconds) + default 120 + + TCP connection timeout after being aged from nf flow table offload. + +nf_flowtable_udp_timeout - INTEGER (seconds) + default 30 + + Control offload timeout for udp connections. + UDP connections may be offloaded from nf conntrack to nf flow table. + Once aged, the connection is returned to nf conntrack with udp pickup timeout. + +nf_flowtable_udp_pickup - INTEGER (seconds) + default 30 + + UDP connection timeout after being aged from nf flow table offload. -- cgit v1.2.3 From 3e28d37146db5dd49c469bc62a93ca791067d391 Mon Sep 17 00:00:00 2001 From: Matthew Brost Date: Thu, 17 Jun 2021 18:06:31 -0700 Subject: drm/i915: Move priolist to new i915_sched_engine object Introduce i915_sched_engine object which is lower level data structure that i915_scheduler / generic code can operate on without touching execlist specific structures. This allows additional submission backends to be added without breaking the layering. Currently the execlists backend uses 1 of these object per each engine (physical or virtual) but future backends like the GuC will point to less instances utilizing the reference counting. This is a bit of detour to integrating the i915 with the DRM scheduler but this object will still exist when the DRM scheduler lands in the i915. It will however look a bit different. It will encapsulate the drm_gpu_scheduler object plus and common variables (to the backends) related to scheduling. Regardless this is a step in the right direction. This patch starts the aforementioned transition by moving the priolist into the i915_sched_engine object. v3: (Jason Ekstrand) Update comment next to intel_engine_cs.virtual Add kernel doc (Checkpatch) Fix double the in commit message v4: (Daniele) Update comment message. Add comment about subclass field Signed-off-by: Matthew Brost Reviewed-by: Daniele Ceraolo Spurio Signed-off-by: Matt Roper Link: https://patchwork.freedesktop.org/patch/msgid/20210618010638.98941-2-matthew.brost@intel.com --- Documentation/gpu/i915.rst | 5 +++++ 1 file changed, 5 insertions(+) (limited to 'Documentation') diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst index 42ce0196930a..1d5ce5676d35 100644 --- a/Documentation/gpu/i915.rst +++ b/Documentation/gpu/i915.rst @@ -425,6 +425,11 @@ User Batchbuffer Execution .. kernel-doc:: drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c :doc: User command execution +Scheduling +---------- +.. kernel-doc:: drivers/gpu/drm/i915/i915_scheduler_types.h + :functions: i915_sched_engine + Logical Rings, Logical Ring Contexts and Execlists -------------------------------------------------- -- cgit v1.2.3 From bfde26df7af4e8ea894008dfda1d7d54a834dcd4 Mon Sep 17 00:00:00 2001 From: Michal Wajdeczko Date: Tue, 15 Jun 2021 17:13:02 -0700 Subject: drm/i915/doc: Include GuC ABI documentation MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit GuC ABI documentation is now ready to be included in i915.rst Signed-off-by: Michal Wajdeczko Signed-off-by: Matthew Brost Cc: Piotr Piórkowski Reviewed-by: Matthew Brost Signed-off-by: Matt Roper Link: https://patchwork.freedesktop.org/patch/msgid/20210616001302.84233-4-matthew.brost@intel.com --- Documentation/gpu/i915.rst | 8 ++++++++ 1 file changed, 8 insertions(+) (limited to 'Documentation') diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst index 1d5ce5676d35..e6fd9608e9c6 100644 --- a/Documentation/gpu/i915.rst +++ b/Documentation/gpu/i915.rst @@ -523,6 +523,14 @@ GuC-based command submission .. kernel-doc:: drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c :doc: GuC-based command submission +GuC ABI +~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +.. kernel-doc:: drivers/gpu/drm/i915/gt/uc/abi/guc_messages_abi.h +.. kernel-doc:: drivers/gpu/drm/i915/gt/uc/abi/guc_communication_mmio_abi.h +.. kernel-doc:: drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h +.. kernel-doc:: drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h + HuC --- .. kernel-doc:: drivers/gpu/drm/i915/gt/uc/intel_huc.c -- cgit v1.2.3 From cdbbe6ce26f6e991014596e50d6be280fbc302be Mon Sep 17 00:00:00 2001 From: Wolfram Sang Date: Mon, 7 Jun 2021 14:48:28 +0200 Subject: dt-bindings: timer: renesas,tmu: add r8a779a0 TMU support MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Signed-off-by: Wolfram Sang Reviewed-by: Niklas Söderlund Reviewed-by: Geert Uytterhoeven Link: https://lore.kernel.org/r/20210607124828.1984-1-wsa+renesas@sang-engineering.com Signed-off-by: Rob Herring --- Documentation/devicetree/bindings/timer/renesas,tmu.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/timer/renesas,tmu.yaml b/Documentation/devicetree/bindings/timer/renesas,tmu.yaml index f0f0f121c355..c57169118b68 100644 --- a/Documentation/devicetree/bindings/timer/renesas,tmu.yaml +++ b/Documentation/devicetree/bindings/timer/renesas,tmu.yaml @@ -36,6 +36,7 @@ properties: - renesas,tmu-r8a77980 # R-Car V3H - renesas,tmu-r8a77990 # R-Car E3 - renesas,tmu-r8a77995 # R-Car D3 + - renesas,tmu-r8a779a0 # R-Car V3U - const: renesas,tmu reg: -- cgit v1.2.3 From 5690951154f7bd084e5e3676021c5bbf2042797e Mon Sep 17 00:00:00 2001 From: Geert Uytterhoeven Date: Fri, 18 Jun 2021 13:04:07 +0200 Subject: dt-bindings: i2c: renesas,iic: Always declare generic compatibility According to the Hardware User's Manual, automatic transmission for PMIC control (DVFS) is not available on the R-Car E3 and RZ/G2E SoC. Experiments showed this really means that support for automatic DVFS is not present, while the IIC automatic transmission feature itself is still available, albeit not super useful. Hence there is no longer a reason not to declare compatibility with the R-Car Gen3-specific and generic versions, and the corresponding paragraph can be dropped. Signed-off-by: Geert Uytterhoeven Signed-off-by: Wolfram Sang --- Documentation/devicetree/bindings/i2c/renesas,iic.txt | 5 ----- 1 file changed, 5 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/i2c/renesas,iic.txt b/Documentation/devicetree/bindings/i2c/renesas,iic.txt index 93d412832e66..5de808f79b06 100644 --- a/Documentation/devicetree/bindings/i2c/renesas,iic.txt +++ b/Documentation/devicetree/bindings/i2c/renesas,iic.txt @@ -37,11 +37,6 @@ Required properties: When compatible with "renesas,rmobile-iic" it should be the last compatibility string listed. - The r8a77990 (R-Car E3) and r8a774c0 (RZ/G2E) - controllers are not considered compatible with - "renesas,rcar-gen3-iic" or "renesas,rmobile-iic" - due to the absence of automatic transmission registers. - - reg : address start and address range size of device - interrupts : interrupt of device - clocks : clock for device -- cgit v1.2.3 From 7e124917809705f05e0c9f0f72a38102e6aa4eff Mon Sep 17 00:00:00 2001 From: Marek Vasut Date: Thu, 10 Jun 2021 17:00:44 +0200 Subject: dt-bindings: rtc: rx8900: Convert to YAML schema Convert the Epson RX8900 DT bindings to YAML schema. Signed-off-by: Marek Vasut Cc: Alexandre Belloni Cc: Rob Herring Cc: kernel@dh-electronics.com Cc: linux-rtc@vger.kernel.org To: devicetree@vger.kernel.org Reviewed-by: Rob Herring Signed-off-by: Alexandre Belloni Link: https://lore.kernel.org/r/20210610150044.29792-1-marex@denx.de --- .../devicetree/bindings/rtc/epson,rx8900.txt | 22 ---------- .../devicetree/bindings/rtc/epson,rx8900.yaml | 49 ++++++++++++++++++++++ 2 files changed, 49 insertions(+), 22 deletions(-) delete mode 100644 Documentation/devicetree/bindings/rtc/epson,rx8900.txt create mode 100644 Documentation/devicetree/bindings/rtc/epson,rx8900.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/rtc/epson,rx8900.txt b/Documentation/devicetree/bindings/rtc/epson,rx8900.txt deleted file mode 100644 index 3f61e516ecf6..000000000000 --- a/Documentation/devicetree/bindings/rtc/epson,rx8900.txt +++ /dev/null @@ -1,22 +0,0 @@ -Real Time Clock driver for: - - Epson RX8900 - - Micro Crystal rv8803 - -Required properties: -- compatible: should be: "microcrystal,rv8803" or "epson,rx8900" -- reg : the I2C address of the device for I2C - -Optional properties: -- epson,vdet-disable : boolean, if present will disable voltage detector. - Should be set if no backup battery is used. -- trickle-diode-disable : boolean, if present will disable internal trickle - charger diode - -Example: - - rtc: rtc@32 { - compatible = "epson,rx8900" - reg = <0x32>; - epson,vdet-disable; - trickle-diode-disable; - }; diff --git a/Documentation/devicetree/bindings/rtc/epson,rx8900.yaml b/Documentation/devicetree/bindings/rtc/epson,rx8900.yaml new file mode 100644 index 000000000000..29fe39bb08ad --- /dev/null +++ b/Documentation/devicetree/bindings/rtc/epson,rx8900.yaml @@ -0,0 +1,49 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/rtc/epson,rx8900.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: EPSON RX8900 / Microcrystal RV8803 Real-Time Clock DT bindings + +maintainers: + - Marek Vasut + +allOf: + - $ref: rtc.yaml# + +properties: + compatible: + enum: + - epson,rx8900 + - microcrystal,rv8803 + + reg: + maxItems: 1 + + epson,vdet-disable: + type: boolean + description: | + Disable voltage detector. Should be set if no backup battery is used. + + trickle-diode-disable: true + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + rtc@32 { + compatible = "epson,rx8900"; + reg = <0x32>; + epson,vdet-disable; + trickle-diode-disable; + }; + }; -- cgit v1.2.3 From 632ce67773dace482a8c4fcbedd4c19154e38d37 Mon Sep 17 00:00:00 2001 From: Geert Uytterhoeven Date: Fri, 18 Jun 2021 13:04:11 +0200 Subject: dt-bindings: i2c: renesas,iic: Convert to json-schema Convert the Renesas R-Mobile I2C Bus Interface (IIC) Device Tree binding documentation to json-schema. Document missing properties. R-Mobile A1 and SH-Mobile have multiple interrupts. Update the example to match reality. Signed-off-by: Geert Uytterhoeven Reviewed-by: Rob Herring Signed-off-by: Wolfram Sang --- .../devicetree/bindings/i2c/renesas,iic.txt | 67 --------- .../bindings/i2c/renesas,rmobile-iic.yaml | 149 +++++++++++++++++++++ 2 files changed, 149 insertions(+), 67 deletions(-) delete mode 100644 Documentation/devicetree/bindings/i2c/renesas,iic.txt create mode 100644 Documentation/devicetree/bindings/i2c/renesas,rmobile-iic.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/i2c/renesas,iic.txt b/Documentation/devicetree/bindings/i2c/renesas,iic.txt deleted file mode 100644 index 5de808f79b06..000000000000 --- a/Documentation/devicetree/bindings/i2c/renesas,iic.txt +++ /dev/null @@ -1,67 +0,0 @@ -Device tree configuration for Renesas IIC (sh_mobile) driver - -Required properties: -- compatible : - - "renesas,iic-r8a73a4" (R-Mobile APE6) - - "renesas,iic-r8a7740" (R-Mobile A1) - - "renesas,iic-r8a7742" (RZ/G1H) - - "renesas,iic-r8a7743" (RZ/G1M) - - "renesas,iic-r8a7744" (RZ/G1N) - - "renesas,iic-r8a7745" (RZ/G1E) - - "renesas,iic-r8a774a1" (RZ/G2M) - - "renesas,iic-r8a774b1" (RZ/G2N) - - "renesas,iic-r8a774c0" (RZ/G2E) - - "renesas,iic-r8a774e1" (RZ/G2H) - - "renesas,iic-r8a7790" (R-Car H2) - - "renesas,iic-r8a7791" (R-Car M2-W) - - "renesas,iic-r8a7792" (R-Car V2H) - - "renesas,iic-r8a7793" (R-Car M2-N) - - "renesas,iic-r8a7794" (R-Car E2) - - "renesas,iic-r8a7795" (R-Car H3) - - "renesas,iic-r8a7796" (R-Car M3-W) - - "renesas,iic-r8a77961" (R-Car M3-W+) - - "renesas,iic-r8a77965" (R-Car M3-N) - - "renesas,iic-r8a77990" (R-Car E3) - - "renesas,iic-sh73a0" (SH-Mobile AG5) - - "renesas,rcar-gen2-iic" (generic R-Car Gen2 or RZ/G1 - compatible device) - - "renesas,rcar-gen3-iic" (generic R-Car Gen3 or RZ/G2 - compatible device) - - "renesas,rmobile-iic" (generic device) - - When compatible with a generic R-Car version, nodes - must list the SoC-specific version corresponding to - the platform first followed by the generic R-Car - version. - - When compatible with "renesas,rmobile-iic" it should - be the last compatibility string listed. - -- reg : address start and address range size of device -- interrupts : interrupt of device -- clocks : clock for device -- #address-cells : should be <1> -- #size-cells : should be <0> - -Optional properties: -- clock-frequency : frequency of bus clock in Hz. Default 100kHz if unset. -- dmas : Must contain a list of two references to DMA - specifiers, one for transmission, and one for - reception. -- dma-names : Must contain a list of two DMA names, "tx" and "rx". - - -Pinctrl properties might be needed, too. See there. - -Example: - - iic0: i2c@e6500000 { - compatible = "renesas,iic-r8a7790", "renesas,rcar-gen2-iic", - "renesas,rmobile-iic"; - reg = <0 0xe6500000 0 0x425>; - interrupts = <0 174 IRQ_TYPE_LEVEL_HIGH>; - clocks = <&mstp3_clks R8A7790_CLK_IIC0>; - clock-frequency = <400000>; - #address-cells = <1>; - #size-cells = <0>; - }; diff --git a/Documentation/devicetree/bindings/i2c/renesas,rmobile-iic.yaml b/Documentation/devicetree/bindings/i2c/renesas,rmobile-iic.yaml new file mode 100644 index 000000000000..04e4ffd80bc0 --- /dev/null +++ b/Documentation/devicetree/bindings/i2c/renesas,rmobile-iic.yaml @@ -0,0 +1,149 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/i2c/renesas,rmobile-iic.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Renesas R-Mobile I2C Bus Interface (IIC) + +maintainers: + - Wolfram Sang + +properties: + compatible: + oneOf: + - items: + - enum: + - renesas,iic-r8a73a4 # R-Mobile APE6 + - renesas,iic-r8a7740 # R-Mobile A1 + - renesas,iic-sh73a0 # SH-Mobile AG5 + - const: renesas,rmobile-iic # Generic + + - items: + - enum: + - renesas,iic-r8a7742 # RZ/G1H + - renesas,iic-r8a7743 # RZ/G1M + - renesas,iic-r8a7744 # RZ/G1N + - renesas,iic-r8a7745 # RZ/G1E + - renesas,iic-r8a7790 # R-Car H2 + - renesas,iic-r8a7791 # R-Car M2-W + - renesas,iic-r8a7792 # R-Car V2H + - renesas,iic-r8a7793 # R-Car M2-N + - renesas,iic-r8a7794 # R-Car E2 + - const: renesas,rcar-gen2-iic # R-Car Gen2 and RZ/G1 + - const: renesas,rmobile-iic # Generic + + - items: + - enum: + - renesas,iic-r8a774a1 # RZ/G2M + - renesas,iic-r8a774b1 # RZ/G2N + - renesas,iic-r8a774c0 # RZ/G2E + - renesas,iic-r8a774e1 # RZ/G2H + - renesas,iic-r8a7795 # R-Car H3 + - renesas,iic-r8a7796 # R-Car M3-W + - renesas,iic-r8a77961 # R-Car M3-W+ + - renesas,iic-r8a77965 # R-Car M3-N + - renesas,iic-r8a77990 # R-Car E3 + - const: renesas,rcar-gen3-iic # R-Car Gen3 and RZ/G2 + - const: renesas,rmobile-iic # Generic + + reg: + maxItems: 1 + + interrupts: true + + clock-frequency: + description: + Desired I2C bus clock frequency in Hz. The absence of this property + indicates the default frequency 100 kHz. + + clocks: + maxItems: 1 + + power-domains: + maxItems: 1 + + resets: + maxItems: 1 + + dmas: + minItems: 2 + maxItems: 4 + description: + Must contain a list of pairs of references to DMA specifiers, one for + transmission, and one for reception. + + dma-names: + minItems: 2 + maxItems: 4 + items: + enum: + - tx + - rx + +required: + - compatible + - reg + - interrupts + - clocks + - power-domains + - '#address-cells' + - '#size-cells' + +allOf: + - $ref: /schemas/i2c/i2c-controller.yaml# + + - if: + properties: + compatible: + contains: + enum: + - renesas,iic-r8a7740 + - renesas,iic-sh73a0 + then: + properties: + interrupts: + items: + - description: Arbitration Lost Interrupt (ALI) + - description: Non-acknowledge Detection Interrupt (TACKI) + - description: Wait Interrupt (WAITI) + - description: Data Transmit Enable interrupt (DTEI) + else: + properties: + interrupts: + items: + - description: Single combined interrupt + + - if: + properties: + compatible: + contains: + enum: + - renesas,rcar-gen2-iic + - renesas,rcar-gen3-iic + then: + required: + - resets + +unevaluatedProperties: false + +examples: + - | + #include + #include + #include + + iic0: i2c@e6500000 { + compatible = "renesas,iic-r8a7790", "renesas,rcar-gen2-iic", + "renesas,rmobile-iic"; + reg = <0xe6500000 0x425>; + interrupts = ; + clocks = <&cpg CPG_MOD 318>; + clock-frequency = <400000>; + dmas = <&dmac0 0x61>, <&dmac0 0x62>, <&dmac1 0x61>, <&dmac1 0x62>; + dma-names = "tx", "rx", "tx", "rx"; + power-domains = <&sysc R8A7790_PD_ALWAYS_ON>; + resets = <&cpg 318>; + #address-cells = <1>; + #size-cells = <0>; + }; -- cgit v1.2.3 From 4a7e7408688de048bffa5e0e00d246b5f854bcf7 Mon Sep 17 00:00:00 2001 From: Geert Uytterhoeven Date: Wed, 16 Jun 2021 15:51:43 +0200 Subject: dt-bindings: rtc: ti,bq32k: Convert to json-schema Convert the TI BQ32000 I2C Serial Real-Time Clock Device Tree binding documentation to json-schema. Document missing properties. Signed-off-by: Geert Uytterhoeven Reviewed-by: Rob Herring Signed-off-by: Alexandre Belloni Link: https://lore.kernel.org/r/42d9c71b4ee1f120e0cdcf6b266547d29d1fb9a4.1623851377.git.geert+renesas@glider.be --- .../devicetree/bindings/rtc/ti,bq32000.yaml | 49 ++++++++++++++++++++++ Documentation/devicetree/bindings/rtc/ti,bq32k.txt | 18 -------- 2 files changed, 49 insertions(+), 18 deletions(-) create mode 100644 Documentation/devicetree/bindings/rtc/ti,bq32000.yaml delete mode 100644 Documentation/devicetree/bindings/rtc/ti,bq32k.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/rtc/ti,bq32000.yaml b/Documentation/devicetree/bindings/rtc/ti,bq32000.yaml new file mode 100644 index 000000000000..392bd71bd1be --- /dev/null +++ b/Documentation/devicetree/bindings/rtc/ti,bq32000.yaml @@ -0,0 +1,49 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/rtc/ti,bq32000.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: TI BQ32000 I2C Serial Real-Time Clock + +maintainers: + - Pavel Machek + +allOf: + - $ref: rtc.yaml# + +properties: + compatible: + const: ti,bq32000 + + reg: + const: 0x68 + + interrupts: + maxItems: 1 + + start-year: true + + trickle-resistor-ohms: + enum: [ 1120, 20180 ] + + trickle-diode-disable: true + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + bq32000: rtc@68 { + compatible = "ti,bq32000"; + reg = <0x68>; + trickle-resistor-ohms = <1120>; + }; + }; diff --git a/Documentation/devicetree/bindings/rtc/ti,bq32k.txt b/Documentation/devicetree/bindings/rtc/ti,bq32k.txt deleted file mode 100644 index e204906b9ad3..000000000000 --- a/Documentation/devicetree/bindings/rtc/ti,bq32k.txt +++ /dev/null @@ -1,18 +0,0 @@ -* TI BQ32000 I2C Serial Real-Time Clock - -Required properties: -- compatible: Should contain "ti,bq32000". -- reg: I2C address for chip - -Optional properties: -- trickle-resistor-ohms : Selected resistor for trickle charger - Values usable are 1120 and 20180 - 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: - bq32000: rtc@68 { - compatible = "ti,bq32000"; - trickle-resistor-ohms = <1120>; - reg = <0x68>; - }; -- cgit v1.2.3 From a431a0914f9276aa70b7075cb43b9cdc537eaf29 Mon Sep 17 00:00:00 2001 From: Biju Das Date: Tue, 15 Jun 2021 09:53:59 +0100 Subject: dt-bindings: i2c: renesas,riic: Document RZ/G2L I2C controller Document RZ/G2L I2C controller bindings. Signed-off-by: Biju Das Reviewed-by: Lad Prabhakar Reviewed-by: Geert Uytterhoeven Signed-off-by: Wolfram Sang --- .../devicetree/bindings/i2c/renesas,riic.yaml | 19 +++++++++++++++---- 1 file changed, 15 insertions(+), 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/i2c/renesas,riic.yaml b/Documentation/devicetree/bindings/i2c/renesas,riic.yaml index 2d6378164958..52d92ec7ec0b 100644 --- a/Documentation/devicetree/bindings/i2c/renesas,riic.yaml +++ b/Documentation/devicetree/bindings/i2c/renesas,riic.yaml @@ -4,7 +4,7 @@ $id: http://devicetree.org/schemas/i2c/renesas,riic.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# -title: Renesas RZ/A I2C Bus Interface (RIIC) +title: Renesas RZ/A and RZ/G2L I2C Bus Interface (RIIC) maintainers: - Chris Brandt @@ -17,9 +17,10 @@ properties: compatible: items: - enum: - - renesas,riic-r7s72100 # RZ/A1H - - renesas,riic-r7s9210 # RZ/A2M - - const: renesas,riic-rz # RZ/A + - renesas,riic-r7s72100 # RZ/A1H + - renesas,riic-r7s9210 # RZ/A2M + - renesas,riic-r9a07g044 # RZ/G2{L,LC} + - const: renesas,riic-rz # RZ/A or RZ/G2L reg: maxItems: 1 @@ -56,6 +57,16 @@ required: - '#address-cells' - '#size-cells' +if: + properties: + compatible: + contains: + enum: + - renesas,riic-r9a07g044 +then: + required: + - resets + unevaluatedProperties: false examples: -- cgit v1.2.3 From 4aa908fe4704ef9c09a6b2c19b4b49855a3d6055 Mon Sep 17 00:00:00 2001 From: Geert Uytterhoeven Date: Tue, 1 Jun 2021 17:25:44 +0200 Subject: dt-bindings: i2c: ce4100: Replace "ti,pcf8575" by "nxp,pcf8575" The TI part is equivalent to the NXP part, and its compatible value is not documented in the DT bindings. Signed-off-by: Geert Uytterhoeven Reviewed-by: Rob Herring Signed-off-by: Wolfram Sang --- Documentation/devicetree/bindings/i2c/i2c-pxa-pci-ce4100.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/i2c/i2c-pxa-pci-ce4100.txt b/Documentation/devicetree/bindings/i2c/i2c-pxa-pci-ce4100.txt index 569b16248514..1ff6f8487a2d 100644 --- a/Documentation/devicetree/bindings/i2c/i2c-pxa-pci-ce4100.txt +++ b/Documentation/devicetree/bindings/i2c/i2c-pxa-pci-ce4100.txt @@ -71,7 +71,7 @@ This is an example which is used on FalconFalls: /* This I2C controller has one gpio controller */ gpio@26 { #gpio-cells = <2>; - compatible = "ti,pcf8575"; + compatible = "nxp,pcf8575"; reg = <0x26>; gpio-controller; }; @@ -85,7 +85,7 @@ This is an example which is used on FalconFalls: gpio@26 { #gpio-cells = <2>; - compatible = "ti,pcf8575"; + compatible = "nxp,pcf8575"; reg = <0x26>; gpio-controller; }; -- cgit v1.2.3 From ba66207eb01f4b581ce984756f7cd4fbbf4780c3 Mon Sep 17 00:00:00 2001 From: Heiko Stuebner Date: Thu, 10 Jun 2021 23:29:34 +0200 Subject: dt-bindings: phy: add yaml binding for rockchip-inno-csi-dphy Some Rockchip SoCs like the rk3368, rk3326, px30 use a CSI dphy based on an Innosilicon IP. Add a binding for them. Signed-off-by: Heiko Stuebner Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20210610212935.3520341-2-heiko@sntech.de Signed-off-by: Vinod Koul --- .../bindings/phy/rockchip-inno-csi-dphy.yaml | 79 ++++++++++++++++++++++ 1 file changed, 79 insertions(+) create mode 100644 Documentation/devicetree/bindings/phy/rockchip-inno-csi-dphy.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/phy/rockchip-inno-csi-dphy.yaml b/Documentation/devicetree/bindings/phy/rockchip-inno-csi-dphy.yaml new file mode 100644 index 000000000000..bb4a2e4b8ab0 --- /dev/null +++ b/Documentation/devicetree/bindings/phy/rockchip-inno-csi-dphy.yaml @@ -0,0 +1,79 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/phy/rockchip-inno-csi-dphy.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Rockchip SoC MIPI RX0 D-PHY Device Tree Bindings + +maintainers: + - Heiko Stuebner + +description: | + The Rockchip SoC has a MIPI CSI D-PHY based on an Innosilicon IP wich + connects to the ISP1 (Image Signal Processing unit v1.0) for CSI cameras. + +properties: + compatible: + enum: + - rockchip,px30-csi-dphy + - rockchip,rk1808-csi-dphy + - rockchip,rk3326-csi-dphy + - rockchip,rk3368-csi-dphy + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + + clock-names: + const: pclk + + '#phy-cells': + const: 0 + + power-domains: + description: Video in/out power domain. + maxItems: 1 + + resets: + items: + - description: exclusive PHY reset line + + reset-names: + items: + - const: apb + + rockchip,grf: + $ref: /schemas/types.yaml#/definitions/phandle + description: + Some additional phy settings are access through GRF regs. + +required: + - compatible + - reg + - clocks + - clock-names + - '#phy-cells' + - power-domains + - resets + - reset-names + - rockchip,grf + +additionalProperties: false + +examples: + - | + + csi_dphy: phy@ff2f0000 { + compatible = "rockchip,px30-csi-dphy"; + reg = <0xff2f0000 0x4000>; + clocks = <&cru 1>; + clock-names = "pclk"; + #phy-cells = <0>; + power-domains = <&power 1>; + resets = <&cru 1>; + reset-names = "apb"; + rockchip,grf = <&grf>; + }; -- cgit v1.2.3 From 5f8ebd4766dd072c8152255d45b352d444592a33 Mon Sep 17 00:00:00 2001 From: Wang Qing Date: Sun, 25 Apr 2021 09:52:07 +0800 Subject: doc: mtk-wdt: support pre-timeout when the bark irq is available Add description of pre-timeout in mtk-wdt. Signed-off-by: Wang Qing Acked-by: Rob Herring Link: https://lore.kernel.org/r/1619148020-2236-3-git-send-email-wangqing@vivo.com Signed-off-by: Guenter Roeck Signed-off-by: Wim Van Sebroeck --- Documentation/devicetree/bindings/watchdog/mtk-wdt.txt | 5 +++++ 1 file changed, 5 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/watchdog/mtk-wdt.txt b/Documentation/devicetree/bindings/watchdog/mtk-wdt.txt index e36ba60de829..8e277778f923 100644 --- a/Documentation/devicetree/bindings/watchdog/mtk-wdt.txt +++ b/Documentation/devicetree/bindings/watchdog/mtk-wdt.txt @@ -1,5 +1,8 @@ Mediatek SoCs Watchdog timer +The watchdog supports a pre-timeout interrupt that fires timeout-sec/2 +before the expiry. + Required properties: - compatible should contain: @@ -17,6 +20,7 @@ Required properties: - reg : Specifies base physical address and size of the registers. Optional properties: +- interrupts: Watchdog pre-timeout (bark) interrupt. - timeout-sec: contains the watchdog timeout in seconds. - #reset-cells: Should be 1. @@ -26,6 +30,7 @@ watchdog: watchdog@10007000 { compatible = "mediatek,mt8183-wdt", "mediatek,mt6589-wdt"; reg = <0 0x10007000 0 0x100>; + interrupts = ; timeout-sec = <10>; #reset-cells = <1>; }; -- cgit v1.2.3 From e1138cef88a53eb24c2536cef788a7293824c789 Mon Sep 17 00:00:00 2001 From: Sai Prakash Ranjan Date: Mon, 15 Mar 2021 11:35:01 +0530 Subject: dt-bindings: watchdog: Add compatible for SC7280 SoC Add compatible for watchdog timer on SC7280 SoC. Signed-off-by: Sai Prakash Ranjan Signed-off-by: Rajendra Nayak Reviewed-by: Stephen Boyd Acked-by: Rob Herring Reviewed-by: Guenter Roeck Link: https://lore.kernel.org/r/1615788301-29891-1-git-send-email-rnayak@codeaurora.org Signed-off-by: Guenter Roeck Signed-off-by: Wim Van Sebroeck --- Documentation/devicetree/bindings/watchdog/qcom-wdt.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/watchdog/qcom-wdt.yaml b/Documentation/devicetree/bindings/watchdog/qcom-wdt.yaml index b8e4118945a0..ba60bdf1fecc 100644 --- a/Documentation/devicetree/bindings/watchdog/qcom-wdt.yaml +++ b/Documentation/devicetree/bindings/watchdog/qcom-wdt.yaml @@ -17,6 +17,7 @@ properties: enum: - qcom,apss-wdt-qcs404 - qcom,apss-wdt-sc7180 + - qcom,apss-wdt-sc7280 - qcom,apss-wdt-sdm845 - qcom,apss-wdt-sdx55 - qcom,apss-wdt-sm8150 -- cgit v1.2.3 From e4c721d7167f32331ff436b036fe8fca0b70f094 Mon Sep 17 00:00:00 2001 From: Liang Chen Date: Thu, 29 Apr 2021 16:11:45 +0800 Subject: dt-bindings: watchdog: dw-wdt: add description for rk3568 add "rockchip,rk3568-wdt", "snps,dw-wdt" for watchdog nodes on a rk3568 platform to snps,dw-wdt.yaml. Signed-off-by: Liang Chen Acked-by: Rob Herring Link: https://lore.kernel.org/r/20210429081151.17558-5-cl@rock-chips.com Signed-off-by: Guenter Roeck Signed-off-by: Wim Van Sebroeck --- Documentation/devicetree/bindings/watchdog/snps,dw-wdt.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/watchdog/snps,dw-wdt.yaml b/Documentation/devicetree/bindings/watchdog/snps,dw-wdt.yaml index b58596b1831d..6461eb4f4a27 100644 --- a/Documentation/devicetree/bindings/watchdog/snps,dw-wdt.yaml +++ b/Documentation/devicetree/bindings/watchdog/snps,dw-wdt.yaml @@ -27,6 +27,7 @@ properties: - rockchip,rk3328-wdt - rockchip,rk3368-wdt - rockchip,rk3399-wdt + - rockchip,rk3568-wdt - rockchip,rv1108-wdt - const: snps,dw-wdt -- cgit v1.2.3 From b326f2c85f3d79996a58749d9b17b644d440d68a Mon Sep 17 00:00:00 2001 From: Seiya Wang Date: Tue, 16 Mar 2021 19:14:36 +0800 Subject: dt-bindings: watchdog: Add compatible for Mediatek MT8195 This commit adds dt-binding documentation of watchdog for Mediatek MT8195 SoC Platform. Signed-off-by: Seiya Wang Reviewed-by: Guenter Roeck Acked-by: Rob Herring Link: https://lore.kernel.org/r/20210319023427.16711-5-seiya.wang@mediatek.com Signed-off-by: Guenter Roeck Signed-off-by: Wim Van Sebroeck --- Documentation/devicetree/bindings/watchdog/mtk-wdt.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/watchdog/mtk-wdt.txt b/Documentation/devicetree/bindings/watchdog/mtk-wdt.txt index 8e277778f923..416d716403f6 100644 --- a/Documentation/devicetree/bindings/watchdog/mtk-wdt.txt +++ b/Documentation/devicetree/bindings/watchdog/mtk-wdt.txt @@ -16,6 +16,7 @@ Required properties: "mediatek,mt8183-wdt": for MT8183 "mediatek,mt8516-wdt", "mediatek,mt6589-wdt": for MT8516 "mediatek,mt8192-wdt": for MT8192 + "mediatek,mt8195-wdt", "mediatek,mt6589-wdt": for MT8195 - reg : Specifies base physical address and size of the registers. -- cgit v1.2.3 From 13b191692d917b62d50c3956ed9c6ef3d0fbb001 Mon Sep 17 00:00:00 2001 From: Eugen Hristev Date: Thu, 27 May 2021 13:01:18 +0300 Subject: dt-bindings: watchdog: sama5d4-wdt: convert to yaml Convert the old txt binding to yaml format. Signed-off-by: Eugen Hristev Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20210527100120.266796-1-eugen.hristev@microchip.com Signed-off-by: Guenter Roeck Signed-off-by: Wim Van Sebroeck --- .../bindings/watchdog/atmel,sama5d4-wdt.yaml | 73 ++++++++++++++++++++++ .../bindings/watchdog/atmel-sama5d4-wdt.txt | 34 ---------- 2 files changed, 73 insertions(+), 34 deletions(-) create mode 100644 Documentation/devicetree/bindings/watchdog/atmel,sama5d4-wdt.yaml delete mode 100644 Documentation/devicetree/bindings/watchdog/atmel-sama5d4-wdt.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/watchdog/atmel,sama5d4-wdt.yaml b/Documentation/devicetree/bindings/watchdog/atmel,sama5d4-wdt.yaml new file mode 100644 index 000000000000..0d0ab81da040 --- /dev/null +++ b/Documentation/devicetree/bindings/watchdog/atmel,sama5d4-wdt.yaml @@ -0,0 +1,73 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/watchdog/atmel,sama5d4-wdt.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Atmel SAMA5D4 Watchdog Timer (WDT) Controller + +maintainers: + - Eugen Hristev + +allOf: + - $ref: "watchdog.yaml#" + +properties: + compatible: + enum: + - atmel,sama5d4-wdt + - microchip,sam9x60-wdt + + reg: + maxItems: 1 + + atmel,watchdog-type: + $ref: /schemas/types.yaml#/definitions/string + description: should be hardware or software. + oneOf: + - description: + Enable watchdog fault reset. A watchdog fault triggers + watchdog reset. + const: hardware + - description: + Enable watchdog fault interrupt. A watchdog fault asserts + watchdog interrupt. + const: software + default: hardware + + atmel,idle-halt: + $ref: /schemas/types.yaml#/definitions/flag + description: | + present if you want to stop the watchdog when the CPU is in idle state. + CAUTION: This property should be used with care, it actually makes the + watchdog not counting when the CPU is in idle state, therefore the + watchdog reset time depends on mean CPU usage and will not reset at all + if the CPU stop working while it is in idle state, which is probably + not what you want. + + atmel,dbg-halt: + $ref: /schemas/types.yaml#/definitions/flag + description: | + present if you want to stop the watchdog when the CPU is in debug state. + +required: + - compatible + - reg + +unevaluatedProperties: false + +examples: + - | + #include + + watchdog@fc068640 { + compatible = "atmel,sama5d4-wdt"; + reg = <0xfc068640 0x10>; + interrupts = <4 IRQ_TYPE_LEVEL_HIGH 5>; + timeout-sec = <10>; + atmel,watchdog-type = "hardware"; + atmel,dbg-halt; + atmel,idle-halt; + }; + +... diff --git a/Documentation/devicetree/bindings/watchdog/atmel-sama5d4-wdt.txt b/Documentation/devicetree/bindings/watchdog/atmel-sama5d4-wdt.txt deleted file mode 100644 index 44727fcc2729..000000000000 --- a/Documentation/devicetree/bindings/watchdog/atmel-sama5d4-wdt.txt +++ /dev/null @@ -1,34 +0,0 @@ -* Atmel SAMA5D4 Watchdog Timer (WDT) Controller - -Required properties: -- compatible: "atmel,sama5d4-wdt" or "microchip,sam9x60-wdt" -- reg: base physical address and length of memory mapped region. - -Optional properties: -- timeout-sec: watchdog timeout value (in seconds). -- interrupts: interrupt number to the CPU. -- atmel,watchdog-type: should be "hardware" or "software". - "hardware": enable watchdog fault reset. A watchdog fault triggers - watchdog reset. - "software": enable watchdog fault interrupt. A watchdog fault asserts - watchdog interrupt. -- atmel,idle-halt: present if you want to stop the watchdog when the CPU is - in idle state. - CAUTION: This property should be used with care, it actually makes the - watchdog not counting when the CPU is in idle state, therefore the - watchdog reset time depends on mean CPU usage and will not reset at all - if the CPU stop working while it is in idle state, which is probably - not what you want. -- atmel,dbg-halt: present if you want to stop the watchdog when the CPU is - in debug state. - -Example: - watchdog@fc068640 { - compatible = "atmel,sama5d4-wdt"; - reg = <0xfc068640 0x10>; - interrupts = <4 IRQ_TYPE_LEVEL_HIGH 5>; - timeout-sec = <10>; - atmel,watchdog-type = "hardware"; - atmel,dbg-halt; - atmel,idle-halt; - }; -- cgit v1.2.3 From 12dbbf085fa1a78b6cafb02cf0f40b21160206e7 Mon Sep 17 00:00:00 2001 From: Eugen Hristev Date: Thu, 27 May 2021 13:01:20 +0300 Subject: dt-bindings: watchdog: sama5d4-wdt: add compatible for sama7g5-wdt This driver is also compatible with the watchdog on sama7g5 SoC. Add the corresponding compatible string to the binding. Signed-off-by: Eugen Hristev Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20210527100120.266796-3-eugen.hristev@microchip.com Signed-off-by: Guenter Roeck Signed-off-by: Wim Van Sebroeck --- Documentation/devicetree/bindings/watchdog/atmel,sama5d4-wdt.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/watchdog/atmel,sama5d4-wdt.yaml b/Documentation/devicetree/bindings/watchdog/atmel,sama5d4-wdt.yaml index 0d0ab81da040..9856cd76c28d 100644 --- a/Documentation/devicetree/bindings/watchdog/atmel,sama5d4-wdt.yaml +++ b/Documentation/devicetree/bindings/watchdog/atmel,sama5d4-wdt.yaml @@ -17,6 +17,7 @@ properties: enum: - atmel,sama5d4-wdt - microchip,sam9x60-wdt + - microchip,sama7g5-wdt reg: maxItems: 1 -- cgit v1.2.3 From 5b606ae892e3194c5ef42dece094306a14cf9e94 Mon Sep 17 00:00:00 2001 From: Rob Herring Date: Mon, 7 Jun 2021 14:40:22 -0500 Subject: dt-bindings: watchdog: Convert arm,sbsa-gwdt to DT schema Convert the arm,sbsa-gwdt binding to DT schema format. Cc: Wim Van Sebroeck Cc: Guenter Roeck Cc: Fu Wei Cc: linux-watchdog@vger.kernel.org Signed-off-by: Rob Herring Acked-by: Guenter Roeck Link: https://lore.kernel.org/r/20210607194022.3095736-1-robh@kernel.org Signed-off-by: Guenter Roeck Signed-off-by: Wim Van Sebroeck --- .../bindings/watchdog/arm,sbsa-gwdt.yaml | 51 ++++++++++++++++++++++ .../devicetree/bindings/watchdog/sbsa-gwdt.txt | 31 ------------- 2 files changed, 51 insertions(+), 31 deletions(-) create mode 100644 Documentation/devicetree/bindings/watchdog/arm,sbsa-gwdt.yaml delete mode 100644 Documentation/devicetree/bindings/watchdog/sbsa-gwdt.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/watchdog/arm,sbsa-gwdt.yaml b/Documentation/devicetree/bindings/watchdog/arm,sbsa-gwdt.yaml new file mode 100644 index 000000000000..6bfa46353c4e --- /dev/null +++ b/Documentation/devicetree/bindings/watchdog/arm,sbsa-gwdt.yaml @@ -0,0 +1,51 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/watchdog/arm,sbsa-gwdt.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: SBSA (Server Base System Architecture) Generic Watchdog + +maintainers: + - Fu Wei + +description: | + The SBSA Generic Watchdog Timer is used to force a reset of the system after + two stages of timeout have elapsed. A detailed definition of the watchdog + timer can be found in the ARM document: ARM-DEN-0029 - Server Base System + Architecture (SBSA) + +allOf: + - $ref: watchdog.yaml# + +properties: + compatible: + const: arm,sbsa-gwdt + + reg: + items: + - description: Watchdog control frame + - description: Refresh frame + + interrupts: + description: The Watchdog Signal 0 (WS0) SPI (Shared Peripheral Interrupt) + maxItems: 1 + +required: + - compatible + - reg + - interrupts + +unevaluatedProperties: false + +examples: + - | + + watchdog@2a440000 { + compatible = "arm,sbsa-gwdt"; + reg = <0x2a440000 0x1000>, + <0x2a450000 0x1000>; + interrupts = <0 27 4>; + timeout-sec = <30>; + }; +... diff --git a/Documentation/devicetree/bindings/watchdog/sbsa-gwdt.txt b/Documentation/devicetree/bindings/watchdog/sbsa-gwdt.txt deleted file mode 100644 index 6f2d5f91964d..000000000000 --- a/Documentation/devicetree/bindings/watchdog/sbsa-gwdt.txt +++ /dev/null @@ -1,31 +0,0 @@ -* SBSA (Server Base System Architecture) Generic Watchdog - -The SBSA Generic Watchdog Timer is used to force a reset of the system -after two stages of timeout have elapsed. A detailed definition of the -watchdog timer can be found in the ARM document: ARM-DEN-0029 - Server -Base System Architecture (SBSA) - -Required properties: -- compatible: Should at least contain "arm,sbsa-gwdt". - -- reg: Each entry specifies the base physical address of a register frame - and the length of that frame; currently, two frames must be defined, - in this order: - 1: Watchdog control frame; - 2: Refresh frame. - -- interrupts: Should contain the Watchdog Signal 0 (WS0) SPI (Shared - Peripheral Interrupt) number of SBSA Generic Watchdog. - -Optional properties -- timeout-sec: Watchdog timeout values (in seconds). - -Example for FVP Foundation Model v8: - -watchdog@2a440000 { - compatible = "arm,sbsa-gwdt"; - reg = <0x0 0x2a440000 0 0x1000>, - <0x0 0x2a450000 0 0x1000>; - interrupts = <0 27 4>; - timeout-sec = <30>; -}; -- cgit v1.2.3 From 3e5fcb022addc4f1d32b2ca2676f0541b556512c Mon Sep 17 00:00:00 2001 From: Romain Perier Date: Fri, 11 Jun 2021 22:07:59 +0200 Subject: dt-bindings: watchdog: Add Mstar MSC313e WDT devicetree bindings documentation This adds the documentation for the devicetree bindings of the Mstar MSC313e watchdog driver, found from MSC313e SoCs and newer. Signed-off-by: Romain Perier Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20210611200801.52139-2-romain.perier@gmail.com Signed-off-by: Guenter Roeck Signed-off-by: Wim Van Sebroeck --- .../bindings/watchdog/mstar,msc313e-wdt.yaml | 40 ++++++++++++++++++++++ 1 file changed, 40 insertions(+) create mode 100644 Documentation/devicetree/bindings/watchdog/mstar,msc313e-wdt.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/watchdog/mstar,msc313e-wdt.yaml b/Documentation/devicetree/bindings/watchdog/mstar,msc313e-wdt.yaml new file mode 100644 index 000000000000..e3e8b86dbf63 --- /dev/null +++ b/Documentation/devicetree/bindings/watchdog/mstar,msc313e-wdt.yaml @@ -0,0 +1,40 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/watchdog/mstar,msc313e-wdt.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: MStar Watchdog Device Tree Bindings + +maintainers: + - Daniel Palmer + - Romain Perier + +allOf: + - $ref: watchdog.yaml# + +properties: + compatible: + enum: + - mstar,msc313e-wdt + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + +required: + - compatible + - clocks + - reg + +unevaluatedProperties: false + +examples: + - | + watchdog@6000 { + compatible = "mstar,msc313e-wdt"; + reg = <0x6000 0x1f>; + clocks = <&xtal_div2>; + }; -- cgit v1.2.3 From 577729533cdc4e37a8c230e404a44ad7a3ff4eda Mon Sep 17 00:00:00 2001 From: Tvrtko Ursulin Date: Fri, 18 Jun 2021 16:00:36 +0100 Subject: drm/i915: Document the Virtual Engine uAPI A little bit of documentation covering the topics of engine discovery, context engine maps and virtual engines. It is not very detailed but supposed to be a starting point of giving a brief high level overview of general principles and intended use cases. v2: * Have the text in uapi header and link from there. v4: * Link from driver-uapi.rst. Signed-off-by: Tvrtko Ursulin Cc: Daniel Vetter Acked-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20210618150036.2507653-1-tvrtko.ursulin@linux.intel.com --- Documentation/gpu/driver-uapi.rst | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) (limited to 'Documentation') diff --git a/Documentation/gpu/driver-uapi.rst b/Documentation/gpu/driver-uapi.rst index 4411e6919a3d..27d0fbe33e87 100644 --- a/Documentation/gpu/driver-uapi.rst +++ b/Documentation/gpu/driver-uapi.rst @@ -5,4 +5,25 @@ DRM Driver uAPI drm/i915 uAPI ============= +Engine Discovery uAPI +--------------------- + +.. kernel-doc:: include/uapi/drm/i915_drm.h + :doc: Engine Discovery uAPI + +Context Engine Map uAPI +----------------------- + +.. kernel-doc:: include/uapi/drm/i915_drm.h + :doc: Context Engine Map uAPI + +Virtual Engine uAPI +------------------- + +.. kernel-doc:: include/uapi/drm/i915_drm.h + :doc: Virtual Engine uAPI + +i915_drm.h +---------- .. kernel-doc:: include/uapi/drm/i915_drm.h + :internal: -- cgit v1.2.3 From 59ab522d5b6183b4a19f8f8720e9f4806ceb7069 Mon Sep 17 00:00:00 2001 From: Stephan Gerhold Date: Mon, 31 May 2021 15:34:36 +0200 Subject: dt-bindings: extcon: sm5502: Convert to DT schema Convert the extcon-sm5502 device tree bindings to DT schema. Signed-off-by: Stephan Gerhold Signed-off-by: Chanwoo Choi --- .../devicetree/bindings/extcon/extcon-sm5502.txt | 21 --------- .../bindings/extcon/siliconmitus,sm5502-muic.yaml | 50 ++++++++++++++++++++++ 2 files changed, 50 insertions(+), 21 deletions(-) delete mode 100644 Documentation/devicetree/bindings/extcon/extcon-sm5502.txt create mode 100644 Documentation/devicetree/bindings/extcon/siliconmitus,sm5502-muic.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/extcon/extcon-sm5502.txt b/Documentation/devicetree/bindings/extcon/extcon-sm5502.txt deleted file mode 100644 index fc3888e09549..000000000000 --- a/Documentation/devicetree/bindings/extcon/extcon-sm5502.txt +++ /dev/null @@ -1,21 +0,0 @@ - -* SM5502 MUIC (Micro-USB Interface Controller) device - -The Silicon Mitus SM5502 is a MUIC (Micro-USB Interface Controller) device -which can detect the state of external accessory when external accessory is -attached or detached and button is pressed or released. It is interfaced to -the host controller using an I2C interface. - -Required properties: -- compatible: Should be "siliconmitus,sm5502-muic" -- reg: Specifies the I2C slave address of the MUIC block. It should be 0x25 -- interrupts: Interrupt specifiers for detection interrupt sources. - -Example: - - sm5502@25 { - compatible = "siliconmitus,sm5502-muic"; - interrupt-parent = <&gpx1>; - interrupts = <5 0>; - reg = <0x25>; - }; diff --git a/Documentation/devicetree/bindings/extcon/siliconmitus,sm5502-muic.yaml b/Documentation/devicetree/bindings/extcon/siliconmitus,sm5502-muic.yaml new file mode 100644 index 000000000000..0432b0502e0b --- /dev/null +++ b/Documentation/devicetree/bindings/extcon/siliconmitus,sm5502-muic.yaml @@ -0,0 +1,50 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/extcon/siliconmitus,sm5502-muic.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: SM5502 MUIC (Micro-USB Interface Controller) device + +maintainers: + - Chanwoo Choi + +description: + The Silicon Mitus SM5502 is a MUIC (Micro-USB Interface Controller) device + which can detect the state of external accessory when external accessory is + attached or detached and button is pressed or released. It is interfaced to + the host controller using an I2C interface. + +properties: + compatible: + enum: + - siliconmitus,sm5502-muic + + reg: + maxItems: 1 + description: I2C slave address of the device. Usually 0x25 for SM5502. + + interrupts: + maxItems: 1 + +required: + - compatible + - reg + - interrupts + +additionalProperties: false + +examples: + - | + #include + i2c { + #address-cells = <1>; + #size-cells = <0>; + + extcon@25 { + compatible = "siliconmitus,sm5502-muic"; + reg = <0x25>; + interrupt-parent = <&msmgpio>; + interrupts = <12 IRQ_TYPE_EDGE_FALLING>; + }; + }; -- cgit v1.2.3 From 85b8326ed1513bcd9ab79df2d0d5fae11981be90 Mon Sep 17 00:00:00 2001 From: Stephan Gerhold Date: Fri, 4 Jun 2021 11:01:40 +0900 Subject: dt-bindings: extcon: sm5502: Document siliconmitus,sm5504-muic Document support for SM5504 with the new siliconmitus,sm5504-muic compatible. Acked-by: Rob Herring Signed-off-by: Stephan Gerhold Signed-off-by: Chanwoo Choi --- .../devicetree/bindings/extcon/siliconmitus,sm5502-muic.yaml | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/extcon/siliconmitus,sm5502-muic.yaml b/Documentation/devicetree/bindings/extcon/siliconmitus,sm5502-muic.yaml index 0432b0502e0b..fd2e55088888 100644 --- a/Documentation/devicetree/bindings/extcon/siliconmitus,sm5502-muic.yaml +++ b/Documentation/devicetree/bindings/extcon/siliconmitus,sm5502-muic.yaml @@ -4,7 +4,7 @@ $id: http://devicetree.org/schemas/extcon/siliconmitus,sm5502-muic.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# -title: SM5502 MUIC (Micro-USB Interface Controller) device +title: SM5502/SM5504 MUIC (Micro-USB Interface Controller) device maintainers: - Chanwoo Choi @@ -19,10 +19,12 @@ properties: compatible: enum: - siliconmitus,sm5502-muic + - siliconmitus,sm5504-muic reg: maxItems: 1 - description: I2C slave address of the device. Usually 0x25 for SM5502. + description: I2C slave address of the device. Usually 0x25 for SM5502, + 0x14 for SM5504. interrupts: maxItems: 1 -- cgit v1.2.3 From c830b87a761b942474a7de95acb7f57a366fe73b Mon Sep 17 00:00:00 2001 From: Aswath Govindraju Date: Mon, 24 May 2021 20:49:54 +0530 Subject: dt-bindings: gpio: gpio-davinci: Convert to json-schema Convert gpio-davinci dt-binding documentation from txt to yaml format. Signed-off-by: Aswath Govindraju Reviewed-by: Rob Herring Signed-off-by: Bartosz Golaszewski --- .../devicetree/bindings/gpio/gpio-davinci.txt | 167 ------------------- .../devicetree/bindings/gpio/gpio-davinci.yaml | 185 +++++++++++++++++++++ 2 files changed, 185 insertions(+), 167 deletions(-) delete mode 100644 Documentation/devicetree/bindings/gpio/gpio-davinci.txt create mode 100644 Documentation/devicetree/bindings/gpio/gpio-davinci.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/gpio/gpio-davinci.txt b/Documentation/devicetree/bindings/gpio/gpio-davinci.txt deleted file mode 100644 index 696ea46227d1..000000000000 --- a/Documentation/devicetree/bindings/gpio/gpio-davinci.txt +++ /dev/null @@ -1,167 +0,0 @@ -Davinci/Keystone GPIO controller bindings - -Required Properties: -- compatible: should be "ti,dm6441-gpio": for Davinci da850 SoCs - "ti,keystone-gpio": for Keystone 2 66AK2H/K, 66AK2L, - 66AK2E SoCs - "ti,k2g-gpio", "ti,keystone-gpio": for 66AK2G - "ti,am654-gpio", "ti,keystone-gpio": for TI K3 AM654 - "ti,j721e-gpio", "ti,keystone-gpio": for J721E SoCs - "ti,am64-gpio", "ti,keystone-gpio": for AM64 SoCs - -- reg: Physical base address of the controller and the size of memory mapped - registers. - -- gpio-controller : Marks the device node as a gpio controller. - -- #gpio-cells : Should be two. - - first cell is the pin number - - second cell is used to specify optional parameters (unused) - -- interrupts: Array of GPIO interrupt number. Only banked or unbanked IRQs are - supported at a time. - -- ti,ngpio: The number of GPIO pins supported. - -- ti,davinci-gpio-unbanked: The number of GPIOs that have an individual interrupt - line to processor. - -- clocks: Should contain the device's input clock, and should be defined as per - the appropriate clock bindings consumer usage in, - - Documentation/devicetree/bindings/clock/keystone-gate.txt - for 66AK2HK/66AK2L/66AK2E SoCs or, - - Documentation/devicetree/bindings/clock/ti,sci-clk.txt - for 66AK2G SoCs - -- clock-names: Name should be "gpio"; - -Currently clock-names and clocks are needed for all keystone 2 platforms -Davinci platforms do not have DT clocks as of now. - -The GPIO controller also acts as an interrupt controller. It uses the default -two cells specifier as described in Documentation/devicetree/bindings/ -interrupt-controller/interrupts.txt. - -Example: - -gpio: gpio@1e26000 { - compatible = "ti,dm6441-gpio"; - gpio-controller; - #gpio-cells = <2>; - reg = <0x226000 0x1000>; - interrupt-parent = <&intc>; - interrupts = <42 IRQ_TYPE_EDGE_BOTH 43 IRQ_TYPE_EDGE_BOTH - 44 IRQ_TYPE_EDGE_BOTH 45 IRQ_TYPE_EDGE_BOTH - 46 IRQ_TYPE_EDGE_BOTH 47 IRQ_TYPE_EDGE_BOTH - 48 IRQ_TYPE_EDGE_BOTH 49 IRQ_TYPE_EDGE_BOTH - 50 IRQ_TYPE_EDGE_BOTH>; - ti,ngpio = <144>; - ti,davinci-gpio-unbanked = <0>; - interrupt-controller; - #interrupt-cells = <2>; -}; - -leds { - compatible = "gpio-leds"; - - led1 { - label = "davinci:green:usr1"; - gpios = <&gpio 10 GPIO_ACTIVE_HIGH>; - ... - }; - - led2 { - label = "davinci:red:debug1"; - gpios = <&gpio 11 GPIO_ACTIVE_HIGH>; - ... - }; -}; - -Example for 66AK2G: - -gpio0: gpio@2603000 { - compatible = "ti,k2g-gpio", "ti,keystone-gpio"; - reg = <0x02603000 0x100>; - gpio-controller; - #gpio-cells = <2>; - interrupts = , - , - , - , - , - , - , - , - ; - interrupt-controller; - #interrupt-cells = <2>; - ti,ngpio = <144>; - ti,davinci-gpio-unbanked = <0>; - clocks = <&k2g_clks 0x001b 0x0>; - clock-names = "gpio"; -}; - -Example for 66AK2HK/66AK2L/66AK2E: - -gpio0: gpio@260bf00 { - compatible = "ti,keystone-gpio"; - reg = <0x0260bf00 0x100>; - gpio-controller; - #gpio-cells = <2>; - /* HW Interrupts mapped to GPIO pins */ - interrupts = , - , - , - , - , - , - , - , - , - , - , - , - , - , - , - , - , - , - , - , - , - , - , - , - , - , - , - , - , - , - , - ; - clocks = <&clkgpio>; - clock-names = "gpio"; - ti,ngpio = <32>; - ti,davinci-gpio-unbanked = <32>; -}; - -Example for K3 AM654: - -wkup_gpio0: wkup_gpio0@42110000 { - compatible = "ti,am654-gpio", "ti,keystone-gpio"; - reg = <0x42110000 0x100>; - gpio-controller; - #gpio-cells = <2>; - interrupt-parent = <&intr_wkup_gpio>; - interrupts = <59 128>, <59 129>, <59 130>, <59 131>; - interrupt-controller; - #interrupt-cells = <2>; - ti,ngpio = <56>; - ti,davinci-gpio-unbanked = <0>; - clocks = <&k3_clks 59 0>; - clock-names = "gpio"; -}; diff --git a/Documentation/devicetree/bindings/gpio/gpio-davinci.yaml b/Documentation/devicetree/bindings/gpio/gpio-davinci.yaml new file mode 100644 index 000000000000..f32e09ef937c --- /dev/null +++ b/Documentation/devicetree/bindings/gpio/gpio-davinci.yaml @@ -0,0 +1,185 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/gpio/gpio-davinci.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: GPIO controller for Davinci and keystone devices + +maintainers: + - Keerthy + +properties: + compatible: + oneOf: + - items: + - enum: + - ti,k2g-gpio + - ti,am654-gpio + - ti,j721e-gpio + - ti,am64-gpio + - const: ti,keystone-gpio + + - items: + - enum: + - ti,dm6441-gpio + - ti,keystone-gpio + + reg: + maxItems: 1 + + gpio-controller: true + + gpio-ranges: true + + gpio-line-names: + description: strings describing the names of each gpio line. + minItems: 1 + maxItems: 100 + + "#gpio-cells": + const: 2 + description: + first cell is the pin number and second cell is used to specify optional parameters (unused). + + interrupts: + description: + The interrupts are specified as per the interrupt parent. Only banked + or unbanked IRQs are supported at a time. If the interrupts are + banked then provide list of interrupts corresponding to each bank, else + provide the list of interrupts for each gpio. + minItems: 1 + maxItems: 100 + + ti,ngpio: + $ref: /schemas/types.yaml#/definitions/uint32 + description: The number of GPIO pins supported consecutively. + minimum: 1 + + ti,davinci-gpio-unbanked: + $ref: /schemas/types.yaml#/definitions/uint32 + description: The number of GPIOs that have an individual interrupt line to processor. + minimum: 0 + + clocks: + maxItems: 1 + + clock-names: + const: gpio + + interrupt-controller: true + + power-domains: + maxItems: 1 + + "#interrupt-cells": + const: 2 + +patternProperties: + "^(.+-hog(-[0-9]+)?)$": + type: object + + required: + - gpio-hog + +required: + - compatible + - reg + - gpio-controller + - "#gpio-cells" + - interrupts + - ti,ngpio + - ti,davinci-gpio-unbanked + - clocks + - clock-names + +additionalProperties: false + +examples: + - | + #include + + gpio0: gpio@2603000 { + compatible = "ti,k2g-gpio", "ti,keystone-gpio"; + reg = <0x02603000 0x100>; + gpio-controller; + #gpio-cells = <2>; + interrupts = , + , + , + , + , + , + , + , + ; + interrupt-controller; + #interrupt-cells = <2>; + ti,ngpio = <144>; + ti,davinci-gpio-unbanked = <0>; + clocks = <&k2g_clks 0x001b 0x0>; + clock-names = "gpio"; + }; + + - | + #include + + gpio1: gpio@260bf00 { + compatible = "ti,keystone-gpio"; + reg = <0x0260bf00 0x100>; + gpio-controller; + #gpio-cells = <2>; + /* HW Interrupts mapped to GPIO pins */ + interrupts = , + , + , + , + , + , + , + , + , + , + , + , + , + , + , + , + , + , + , + , + , + , + , + , + , + , + , + , + , + , + , + ; + clocks = <&clkgpio>; + clock-names = "gpio"; + ti,ngpio = <32>; + ti,davinci-gpio-unbanked = <32>; + }; + + - | + wkup_gpio0: gpio0@42110000 { + compatible = "ti,am654-gpio", "ti,keystone-gpio"; + reg = <0x42110000 0x100>; + gpio-controller; + #gpio-cells = <2>; + interrupt-parent = <&intr_wkup_gpio>; + interrupts = <60>, <61>, <62>, <63>; + interrupt-controller; + #interrupt-cells = <2>; + ti,ngpio = <56>; + ti,davinci-gpio-unbanked = <0>; + clocks = <&k3_clks 59 0>; + clock-names = "gpio"; + }; -- cgit v1.2.3 From 45ca16072b700f1e62a908f2de4a12d39edbb49e Mon Sep 17 00:00:00 2001 From: Nobuhiro Iwamatsu Date: Mon, 31 May 2021 21:07:53 +0900 Subject: dt-bindings: gpio: zynq: convert bindings to YAML Convert gpio for Xilinx Zynq SoC bindings documentation to YAML. Signed-off-by: Nobuhiro Iwamatsu Reviewed-by: Linus Walleij Reviewed-by: Rob Herring Signed-off-by: Bartosz Golaszewski --- .../devicetree/bindings/gpio/gpio-zynq.txt | 36 ------------- .../devicetree/bindings/gpio/gpio-zynq.yaml | 59 ++++++++++++++++++++++ 2 files changed, 59 insertions(+), 36 deletions(-) delete mode 100644 Documentation/devicetree/bindings/gpio/gpio-zynq.txt create mode 100644 Documentation/devicetree/bindings/gpio/gpio-zynq.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/gpio/gpio-zynq.txt b/Documentation/devicetree/bindings/gpio/gpio-zynq.txt deleted file mode 100644 index f693e82b4c0f..000000000000 --- a/Documentation/devicetree/bindings/gpio/gpio-zynq.txt +++ /dev/null @@ -1,36 +0,0 @@ -Xilinx Zynq GPIO controller Device Tree Bindings -------------------------------------------- - -Required properties: -- #gpio-cells : Should be two - - First cell is the GPIO line number - - Second cell is used to specify optional - parameters (unused) -- compatible : Should be "xlnx,zynq-gpio-1.0" or - "xlnx,zynqmp-gpio-1.0" or "xlnx,versal-gpio-1.0 - or "xlnx,pmc-gpio-1.0 -- clocks : Clock specifier (see clock bindings for details) -- gpio-controller : Marks the device node as a GPIO controller. -- interrupts : Interrupt specifier (see interrupt bindings for - details) -- interrupt-controller : Marks the device node as an interrupt controller. -- #interrupt-cells : Should be 2. The first cell is the GPIO number. - The second cell bits[3:0] is used to specify trigger type and level flags: - 1 = low-to-high edge triggered. - 2 = high-to-low edge triggered. - 4 = active high level-sensitive. - 8 = active low level-sensitive. -- reg : Address and length of the register set for the device - -Example: - gpio@e000a000 { - #gpio-cells = <2>; - compatible = "xlnx,zynq-gpio-1.0"; - clocks = <&clkc 42>; - gpio-controller; - interrupt-parent = <&intc>; - interrupts = <0 20 4>; - interrupt-controller; - #interrupt-cells = <2>; - reg = <0xe000a000 0x1000>; - }; diff --git a/Documentation/devicetree/bindings/gpio/gpio-zynq.yaml b/Documentation/devicetree/bindings/gpio/gpio-zynq.yaml new file mode 100644 index 000000000000..378da2649e66 --- /dev/null +++ b/Documentation/devicetree/bindings/gpio/gpio-zynq.yaml @@ -0,0 +1,59 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/gpio/gpio-zynq.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Xilinx Zynq GPIO controller Device Tree Bindings + +maintainers: + - Michal Simek + +properties: + compatible: + const: xlnx,zynq-gpio-1.0 + + reg: + maxItems: 1 + + "#gpio-cells": + const: 2 + + interrupts: + maxItems: 1 + + gpio-controller: true + + interrupt-controller: true + + "#interrupt-cells": + const: 2 + + clocks: + maxItems: 1 + +required: + - compatible + - reg + - "#gpio-cells" + - interrupts + - gpio-controller + - interrupt-controller + - "#interrupt-cells" + - clocks + +additionalProperties: false + +examples: + - | + gpio@e000a000 { + #gpio-cells = <2>; + compatible = "xlnx,zynq-gpio-1.0"; + clocks = <&clkc 42>; + gpio-controller; + interrupt-parent = <&intc>; + interrupts = <0 20 4>; + interrupt-controller; + #interrupt-cells = <2>; + reg = <0xe000a000 0x1000>; + }; -- cgit v1.2.3 From 85adaac269c36d8e2e0a5de87a1dc4ec06e984f1 Mon Sep 17 00:00:00 2001 From: Bhupesh Sharma Date: Thu, 17 Jun 2021 10:47:08 +0530 Subject: regulator: qcom,rpmh-regulator: Arrange compatibles alphabetically Arrange the compatibles inside qcom-rpmh regulator device tree bindings alphabetically. Cc: Mark Brown Cc: Bjorn Andersson Signed-off-by: Bhupesh Sharma Reviewed-by: Bjorn Andersson Link: https://lore.kernel.org/r/20210617051712.345372-2-bhupesh.sharma@linaro.org Signed-off-by: Mark Brown --- .../bindings/regulator/qcom,rpmh-regulator.yaml | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.yaml b/Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.yaml index e561a5b941e4..3546c6a966a3 100644 --- a/Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.yaml +++ b/Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.yaml @@ -33,6 +33,9 @@ description: | The names used for regulator nodes must match those supported by a given PMIC. Supported regulator node names are + For PM6150, smps1 - smps5, ldo1 - ldo19 + For PM6150L, smps1 - smps8, ldo1 - ldo11, bob + For PM7325, smps1 - smps8, ldo1 - ldo19 For PM8005, smps1 - smps4 For PM8009, smps1 - smps2, ldo1 - ldo7 For PM8150, smps1 - smps10, ldo1 - ldo18 @@ -41,15 +44,15 @@ description: | For PM8350C, smps1 - smps10, ldo1 - ldo13, bob For PM8998, smps1 - smps13, ldo1 - ldo28, lvs1 - lvs2 For PMI8998, bob - For PM6150, smps1 - smps5, ldo1 - ldo19 - For PM6150L, smps1 - smps8, ldo1 - ldo11, bob - For PMX55, smps1 - smps7, ldo1 - ldo16 - For PM7325, smps1 - smps8, ldo1 - ldo19 For PMR735A, smps1 - smps3, ldo1 - ldo7 + For PMX55, smps1 - smps7, ldo1 - ldo16 properties: compatible: enum: + - qcom,pm6150-rpmh-regulators + - qcom,pm6150l-rpmh-regulators + - qcom,pm7325-rpmh-regulators - qcom,pm8005-rpmh-regulators - qcom,pm8009-rpmh-regulators - qcom,pm8009-1-rpmh-regulators @@ -59,11 +62,8 @@ properties: - qcom,pm8350c-rpmh-regulators - qcom,pm8998-rpmh-regulators - qcom,pmi8998-rpmh-regulators - - qcom,pm6150-rpmh-regulators - - qcom,pm6150l-rpmh-regulators - - qcom,pmx55-rpmh-regulators - - qcom,pm7325-rpmh-regulators - qcom,pmr735a-rpmh-regulators + - qcom,pmx55-rpmh-regulators qcom,pmic-id: description: | -- cgit v1.2.3 From 66376e152303bb60d6a75328b7bc998de86f8c08 Mon Sep 17 00:00:00 2001 From: Bhupesh Sharma Date: Thu, 17 Jun 2021 10:47:09 +0530 Subject: regulator: qcom,rpmh-regulator: Add compatible for SA8155p-adp board pmic Add compatible string for pmm8155au pmic found on the SA8155p-adp board. Cc: Mark Brown Cc: Bjorn Andersson Signed-off-by: Bhupesh Sharma Reviewed-by: Bjorn Andersson Link: https://lore.kernel.org/r/20210617051712.345372-3-bhupesh.sharma@linaro.org Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.yaml b/Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.yaml index 3546c6a966a3..34de38377aa6 100644 --- a/Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.yaml +++ b/Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.yaml @@ -62,6 +62,7 @@ properties: - qcom,pm8350c-rpmh-regulators - qcom,pm8998-rpmh-regulators - qcom,pmi8998-rpmh-regulators + - qcom,pmm8155au-rpmh-regulators - qcom,pmr735a-rpmh-regulators - qcom,pmx55-rpmh-regulators -- cgit v1.2.3 From 01c5741b82969d096ac0870d997b7d2f5a5fe970 Mon Sep 17 00:00:00 2001 From: Sergey Larin Date: Fri, 18 Jun 2021 17:16:07 +0300 Subject: regulator: Add MAX8893 bindings Add Maxim MAX8893 PMIC device tree bindings. The example is also provided. Signed-off-by: Sergey Larin Link: https://lore.kernel.org/r/20210618141607.884-2-cerg2010cerg2010@mail.ru Signed-off-by: Mark Brown --- .../devicetree/bindings/regulator/max8893.yaml | 88 ++++++++++++++++++++++ 1 file changed, 88 insertions(+) create mode 100644 Documentation/devicetree/bindings/regulator/max8893.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/regulator/max8893.yaml b/Documentation/devicetree/bindings/regulator/max8893.yaml new file mode 100644 index 000000000000..2b5e977bf409 --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/max8893.yaml @@ -0,0 +1,88 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/regulator/max8893.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Regulator driver for MAX8893 PMIC from Maxim Integrated. + +maintainers: + - Sergey Larin + +description: | + The device has 5 LDO regulators and a single BUCK regulator. + Programming is done through I2C bus. + +properties: + compatible: + const: maxim,max8893 + + reg: + maxItems: 1 + + regulators: + type: object + + patternProperties: + "^(ldo[1-5]|buck)$": + $ref: "regulator.yaml#" + + additionalProperties: false + +additionalProperties: false + +required: + - compatible + - reg + - regulators + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + pmic@3e { + compatible = "maxim,max8893"; + reg = <0x3e>; + + regulators { + /* Front camera - s5k6aafx, back - m5mo */ + /* Numbers used to indicate the sequence */ + front_1_back_1: buck { + regulator-name = "cam_isp_core_1v2"; + regulator-min-microvolt = <1200000>; + regulator-max-microvolt = <1200000>; + }; + + front_4_back_5: ldo1 { + regulator-name = "vt_io_1v8,cam_isp_1v8"; + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <1800000>; + }; + + front_3_back_4: ldo2 { + regulator-name = "vt_core_1v5"; + regulator-min-microvolt = <1500000>; + regulator-max-microvolt = <1500000>; + }; + + front_5_back_6: ldo3 { + regulator-name = "vt_cam_1v8,vt_sensor_io_1v8"; + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <1800000>; + }; + + ldo4 { + /* not used */ + }; + + back_7: ldo5 { + regulator-name = "cam_sensor_io_1v8"; + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <1800000>; + }; + }; + }; + }; +... -- cgit v1.2.3 From 673e851b7da81256e73fb738c550ec39bac1c9ff Mon Sep 17 00:00:00 2001 From: Matti Vaittinen Date: Thu, 3 Jun 2021 08:40:28 +0300 Subject: regulator: Add protection limit properties Support specifying protection/error/warning limits for regulator over current, over temperature and over/under voltage. Most of the PMICs support only "protection" feature but few setups do also support error/warning level indications. On many ICs most of the protection limits can't actually be set. But for example the ampere limit for over-current protection on ROHM BD9576 can be configured - or feature can be completely disabled. Provide limit setting for all protections/errors for the sake of the completeness and do that using own properties for all so that not all users would need to set all levels when only one or few are supported. Signed-off-by: Matti Vaittinen Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/ae2c6056d5ed1334912d27e736d23c9151065433.1622628333.git.matti.vaittinen@fi.rohmeurope.com Signed-off-by: Mark Brown --- .../devicetree/bindings/regulator/regulator.yaml | 82 ++++++++++++++++++++++ 1 file changed, 82 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/regulator/regulator.yaml b/Documentation/devicetree/bindings/regulator/regulator.yaml index 6d0bc9cd4040..a6ae9ecae5cc 100644 --- a/Documentation/devicetree/bindings/regulator/regulator.yaml +++ b/Documentation/devicetree/bindings/regulator/regulator.yaml @@ -117,6 +117,88 @@ properties: description: Enable over current protection. type: boolean + regulator-oc-protection-microamp: + description: Set over current protection limit. This is a limit where + hardware performs emergency shutdown. Zero can be passed to disable + protection and value '1' indicates that protection should be enabled but + limit setting can be omitted. + + regulator-oc-error-microamp: + description: Set over current error limit. This is a limit where part of + the hardware propably is malfunctional and damage prevention is requested. + Zero can be passed to disable error detection and value '1' indicates + that detection should be enabled but limit setting can be omitted. + + regulator-oc-warn-microamp: + description: Set over current warning limit. This is a limit where hardware + is assumed still to be functional but approaching limit where it gets + damaged. Recovery actions should be initiated. Zero can be passed to + disable detection and value '1' indicates that detection should + be enabled but limit setting can be omitted. + + regulator-ov-protection-microvolt: + description: Set over voltage protection limit. This is a limit where + hardware performs emergency shutdown. Zero can be passed to disable + protection and value '1' indicates that protection should be enabled but + limit setting can be omitted. Limit is given as microvolt offset from + voltage set to regulator. + + regulator-ov-error-microvolt: + description: Set over voltage error limit. This is a limit where part of + the hardware propably is malfunctional and damage prevention is requested + Zero can be passed to disable error detection and value '1' indicates + that detection should be enabled but limit setting can be omitted. Limit + is given as microvolt offset from voltage set to regulator. + + regulator-ov-warn-microvolt: + description: Set over voltage warning limit. This is a limit where hardware + is assumed still to be functional but approaching limit where it gets + damaged. Recovery actions should be initiated. Zero can be passed to + disable detection and value '1' indicates that detection should + be enabled but limit setting can be omitted. Limit is given as microvolt + offset from voltage set to regulator. + + regulator-uv-protection-microvolt: + description: Set over under voltage protection limit. This is a limit where + hardware performs emergency shutdown. Zero can be passed to disable + protection and value '1' indicates that protection should be enabled but + limit setting can be omitted. Limit is given as microvolt offset from + voltage set to regulator. + + regulator-uv-error-microvolt: + description: Set under voltage error limit. This is a limit where part of + the hardware propably is malfunctional and damage prevention is requested + Zero can be passed to disable error detection and value '1' indicates + that detection should be enabled but limit setting can be omitted. Limit + is given as microvolt offset from voltage set to regulator. + + regulator-uv-warn-microvolt: + description: Set over under voltage warning limit. This is a limit where + hardware is assumed still to be functional but approaching limit where + it gets damaged. Recovery actions should be initiated. Zero can be passed + to disable detection and value '1' indicates that detection should + be enabled but limit setting can be omitted. Limit is given as microvolt + offset from voltage set to regulator. + + regulator-temp-protection-kelvin: + description: Set over temperature protection limit. This is a limit where + hardware performs emergency shutdown. Zero can be passed to disable + protection and value '1' indicates that protection should be enabled but + limit setting can be omitted. + + regulator-temp-error-kelvin: + description: Set over temperature error limit. This is a limit where part of + the hardware propably is malfunctional and damage prevention is requested + Zero can be passed to disable error detection and value '1' indicates + that detection should be enabled but limit setting can be omitted. + + regulator-temp-warn-kelvin: + description: Set over temperature warning limit. This is a limit where + hardware is assumed still to be functional but approaching limit where it + gets damaged. Recovery actions should be initiated. Zero can be passed to + disable detection and value '1' indicates that detection should + be enabled but limit setting can be omitted. + regulator-active-discharge: description: | tristate, enable/disable active discharge of regulators. The values are: -- cgit v1.2.3 From db0aeb4f074f7023da26fb65078197c39590346b Mon Sep 17 00:00:00 2001 From: Matti Vaittinen Date: Thu, 3 Jun 2021 08:41:03 +0300 Subject: thermal: Use generic HW-protection shutdown API The hardware shutdown function was exported from kernel/reboot for other subsystems to use. Logic is copied from the thermal_core. The protection mutex is replaced by an atomic_t to allow calls also from an IRQ context. Also the WARN() was replaced by pr_emerg() based on discussions here: https://lore.kernel.org/lkml/YJuPwAZroVZ%2Fw633@alley/ and here: https://lore.kernel.org/linux-iommu/20210331093104.383705-4-geert+renesas@glider.be/ Use the exported API instead of implementing own just for the thermal_core. Signed-off-by: Matti Vaittinen Acked-by: Daniel Lezcano Link: https://lore.kernel.org/r/5531e89d9e710f5d10e7cdce3ee58957335b9e03.1622628333.git.matti.vaittinen@fi.rohmeurope.com Signed-off-by: Mark Brown --- Documentation/driver-api/thermal/sysfs-api.rst | 24 +++++++++--------------- 1 file changed, 9 insertions(+), 15 deletions(-) (limited to 'Documentation') diff --git a/Documentation/driver-api/thermal/sysfs-api.rst b/Documentation/driver-api/thermal/sysfs-api.rst index 4b638c14bc16..c93fa5e961a0 100644 --- a/Documentation/driver-api/thermal/sysfs-api.rst +++ b/Documentation/driver-api/thermal/sysfs-api.rst @@ -740,21 +740,15 @@ possible. 5. thermal_emergency_poweroff ============================= -On an event of critical trip temperature crossing. Thermal framework -allows the system to shutdown gracefully by calling orderly_poweroff(). -In the event of a failure of orderly_poweroff() to shut down the system -we are in danger of keeping the system alive at undesirably high -temperatures. To mitigate this high risk scenario we program a work -queue to fire after a pre-determined number of seconds to start -an emergency shutdown of the device using the kernel_power_off() -function. In case kernel_power_off() fails then finally -emergency_restart() is called in the worst case. +On an event of critical trip temperature crossing the thermal framework +shuts down the system by calling hw_protection_shutdown(). The +hw_protection_shutdown() first attempts to perform an orderly shutdown +but accepts a delay after which it proceeds doing a forced power-off +or as last resort an emergency_restart. The delay should be carefully profiled so as to give adequate time for -orderly_poweroff(). In case of failure of an orderly_poweroff() the -emergency poweroff kicks in after the delay has elapsed and shuts down -the system. +orderly poweroff. -If set to 0 emergency poweroff will not be supported. So a carefully -profiled non-zero positive value is a must for emergency poweroff to be -triggered. +If the delay is set to 0 emergency poweroff will not be supported. So a +carefully profiled non-zero positive value is a must for emergency +poweroff to be triggered. -- cgit v1.2.3 From 627793e4ca4f511837de893545baf0e1b8174dc2 Mon Sep 17 00:00:00 2001 From: Matti Vaittinen Date: Thu, 3 Jun 2021 08:42:30 +0300 Subject: regulator: bd9576 add FET ON-resistance for OCW BD9576MUF provides over-current protection and detection. Current is measured as voltage loss over external FET. Allow specifying FET's on resistance so current monitoring limits can be converted to voltages. Signed-off-by: Matti Vaittinen Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/e5feb160d7e09f33fff5b88f1928c66a15c6680f.1622628334.git.matti.vaittinen@fi.rohmeurope.com Signed-off-by: Mark Brown --- .../devicetree/bindings/regulator/rohm,bd9576-regulator.yaml | 6 ++++++ 1 file changed, 6 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/regulator/rohm,bd9576-regulator.yaml b/Documentation/devicetree/bindings/regulator/rohm,bd9576-regulator.yaml index b6515a0cee62..7cb74cc8c5d9 100644 --- a/Documentation/devicetree/bindings/regulator/rohm,bd9576-regulator.yaml +++ b/Documentation/devicetree/bindings/regulator/rohm,bd9576-regulator.yaml @@ -27,6 +27,12 @@ patternProperties: Properties for single regulator. $ref: "regulator.yaml#" + properties: + rohm,ocw-fet-ron-micro-ohms: + description: | + External FET's ON-resistance. Required if VoutS1 OCP/OCW is + to be set. + required: - regulator-name -- cgit v1.2.3 From 2afd6c8b43c1ee50444d410e953d7d2adf86b5ea Mon Sep 17 00:00:00 2001 From: Alex Elder Date: Mon, 21 Jun 2021 12:56:22 -0500 Subject: dt-bindings: net: qcom,ipa: add support for MSM8998 Add support for "qcom,msm8998-ipa", which uses IPA v3.1. Originally proposed by AngeloGioacchino Del Regno. Link: https://lore.kernel.org/linux-arm-msm/20210211175015.200772-8-angelogioacchino.delregno@somainline.org Signed-off-by: Alex Elder Signed-off-by: David S. Miller --- Documentation/devicetree/bindings/net/qcom,ipa.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/qcom,ipa.yaml b/Documentation/devicetree/bindings/net/qcom,ipa.yaml index 5fe6d3dceb08..ed88ba4b94df 100644 --- a/Documentation/devicetree/bindings/net/qcom,ipa.yaml +++ b/Documentation/devicetree/bindings/net/qcom,ipa.yaml @@ -44,6 +44,7 @@ description: properties: compatible: enum: + - qcom,msm8998-ipa - qcom,sc7180-ipa - qcom,sc7280-ipa - qcom,sdm845-ipa -- cgit v1.2.3 From 89f8a707d00890d302f6d4320d4ecdba12c26bdf Mon Sep 17 00:00:00 2001 From: Sean Anderson Date: Mon, 7 Jun 2021 15:05:46 -0400 Subject: dt-bindings: clk: vc5: Fix example The example properties do not match the binding. Fix them, and prohibit undocumented properties in clock nodes to prevent this from happening in the future. Fixes: 45c940184b50 ("dt-bindings: clk: versaclock5: convert to yaml") Signed-off-by: Sean Anderson Reviewed-by: Luca Ceresoli Link: https://lore.kernel.org/r/20210607190546.2616259-1-sean.anderson@seco.com Signed-off-by: Rob Herring --- Documentation/devicetree/bindings/clock/idt,versaclock5.yaml | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/idt,versaclock5.yaml b/Documentation/devicetree/bindings/clock/idt,versaclock5.yaml index c268debe5b8d..241e1f2554e7 100644 --- a/Documentation/devicetree/bindings/clock/idt,versaclock5.yaml +++ b/Documentation/devicetree/bindings/clock/idt,versaclock5.yaml @@ -86,6 +86,7 @@ patternProperties: description: The Slew rate control for CMOS single-ended. $ref: /schemas/types.yaml#/definitions/uint32 enum: [ 80, 85, 90, 100 ] + additionalProperties: false required: - compatible @@ -141,13 +142,13 @@ examples: clock-names = "xin"; OUT1 { - idt,drive-mode = ; - idt,voltage-microvolts = <1800000>; + idt,mode = ; + idt,voltage-microvolt = <1800000>; idt,slew-percent = <80>; }; OUT4 { - idt,drive-mode = ; + idt,mode = ; }; }; }; -- cgit v1.2.3 From dc4014752eb7489eff43d426bf6b1caeb4092699 Mon Sep 17 00:00:00 2001 From: Rob Herring Date: Tue, 15 Jun 2021 11:20:24 -0600 Subject: dt-bindings: spmi: Correct 'reg' schema 'reg' is defined to be N address entries of M cells each. For SPMI, N is 1 and M is 1 or 2. The schema fails to define the number of entries as it only specifies the inner cell(s). To fix, add an outer items list with 1 entry. Cc: Stephen Boyd Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20210615172024.856360-1-robh@kernel.org --- Documentation/devicetree/bindings/spmi/spmi.yaml | 15 ++++++++------- 1 file changed, 8 insertions(+), 7 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/spmi/spmi.yaml b/Documentation/devicetree/bindings/spmi/spmi.yaml index 173940930719..1d243faef2f8 100644 --- a/Documentation/devicetree/bindings/spmi/spmi.yaml +++ b/Documentation/devicetree/bindings/spmi/spmi.yaml @@ -40,14 +40,15 @@ patternProperties: properties: reg: - minItems: 1 - maxItems: 2 items: - - minimum: 0 - maximum: 0xf - - enum: [ 0 ] - description: | - 0 means user ID address. 1 is reserved for group ID address. + - minItems: 1 + items: + - minimum: 0 + maximum: 0xf + - enum: [ 0 ] + description: + 0 means user ID address. 1 is reserved for group ID + address. required: - reg -- cgit v1.2.3 From 972d6a7dcec3ad3226661034c5d8cb2d30585157 Mon Sep 17 00:00:00 2001 From: Rob Herring Date: Tue, 15 Jun 2021 13:15:43 -0600 Subject: dt-bindings: Drop redundant minItems/maxItems MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit If a property has an 'items' list, then a 'minItems' or 'maxItems' with the same size as the list is redundant and can be dropped. Note that is DT schema specific behavior and not standard json-schema behavior. The tooling will fixup the final schema adding any unspecified minItems/maxItems. This condition is partially checked with the meta-schema already, but only if both 'minItems' and 'maxItems' are equal to the 'items' length. An improved meta-schema is pending. Cc: Jens Axboe Cc: Stephen Boyd Cc: Herbert Xu Cc: "David S. Miller" Cc: David Airlie Cc: Daniel Vetter Cc: Bartosz Golaszewski Cc: Kamal Dasu Cc: Lars-Peter Clausen Cc: Thomas Gleixner Cc: Marc Zyngier Cc: Joerg Roedel Cc: Mauro Carvalho Chehab Cc: Krzysztof Kozlowski Cc: Jakub Kicinski Cc: Wolfgang Grandegger Cc: Andrew Lunn Cc: Vivien Didelot Cc: Vladimir Oltean Cc: Bjorn Helgaas Cc: Kishon Vijay Abraham I Cc: Linus Walleij Cc: "Uwe Kleine-König" Cc: Lee Jones Cc: Ohad Ben-Cohen Cc: Mathieu Poirier Cc: Paul Walmsley Cc: Palmer Dabbelt Cc: Albert Ou Cc: Alessandro Zummo Cc: Alexandre Belloni Cc: Zhang Rui Cc: Daniel Lezcano Cc: Wim Van Sebroeck Cc: Guenter Roeck Signed-off-by: Rob Herring Acked-by: Marc Kleine-Budde Acked-by: Ulf Hansson # for MMC Acked-by: Jassi Brar Acked-By: Vinod Koul Reviewed-by: Greg Kroah-Hartman Reviewed-by: Arnaud Pouliquen Acked-by: Mark Brown Acked-by: Philipp Zabel Acked-by: Wolfram Sang # for I2C Acked-by: Jonathan Cameron Link: https://lore.kernel.org/r/20210615191543.1043414-1-robh@kernel.org --- Documentation/devicetree/bindings/ata/nvidia,tegra-ahci.yaml | 1 - .../devicetree/bindings/clock/allwinner,sun4i-a10-ccu.yaml | 2 -- Documentation/devicetree/bindings/clock/qcom,gcc-apq8064.yaml | 1 - Documentation/devicetree/bindings/clock/qcom,gcc-sdx55.yaml | 2 -- Documentation/devicetree/bindings/clock/qcom,gcc-sm8350.yaml | 2 -- Documentation/devicetree/bindings/clock/sprd,sc9863a-clk.yaml | 1 - Documentation/devicetree/bindings/crypto/allwinner,sun8i-ce.yaml | 2 -- Documentation/devicetree/bindings/crypto/fsl-dcp.yaml | 1 - .../bindings/display/allwinner,sun4i-a10-display-backend.yaml | 6 ------ .../devicetree/bindings/display/allwinner,sun6i-a31-mipi-dsi.yaml | 1 - .../devicetree/bindings/display/allwinner,sun8i-a83t-dw-hdmi.yaml | 4 ---- .../devicetree/bindings/display/allwinner,sun8i-a83t-hdmi-phy.yaml | 2 -- .../devicetree/bindings/display/allwinner,sun8i-r40-tcon-top.yaml | 2 -- Documentation/devicetree/bindings/display/bridge/adi,adv7511.yaml | 1 - Documentation/devicetree/bindings/display/bridge/cdns,mhdp8546.yaml | 2 -- .../devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml | 2 -- Documentation/devicetree/bindings/display/st,stm32-dsi.yaml | 2 -- Documentation/devicetree/bindings/display/st,stm32-ltdc.yaml | 1 - .../devicetree/bindings/display/xlnx/xlnx,zynqmp-dpsub.yaml | 4 ---- Documentation/devicetree/bindings/dma/renesas,rcar-dmac.yaml | 1 - Documentation/devicetree/bindings/edac/amazon,al-mc-edac.yaml | 2 -- Documentation/devicetree/bindings/eeprom/at24.yaml | 1 - Documentation/devicetree/bindings/example-schema.yaml | 2 -- Documentation/devicetree/bindings/gpu/brcm,bcm-v3d.yaml | 1 - Documentation/devicetree/bindings/gpu/vivante,gc.yaml | 1 - Documentation/devicetree/bindings/i2c/aspeed,i2c.yaml | 1 - Documentation/devicetree/bindings/i2c/brcm,brcmstb-i2c.yaml | 1 - Documentation/devicetree/bindings/i2c/marvell,mv64xxx-i2c.yaml | 2 -- Documentation/devicetree/bindings/i2c/mellanox,i2c-mlxbf.yaml | 1 - Documentation/devicetree/bindings/iio/adc/amlogic,meson-saradc.yaml | 1 - Documentation/devicetree/bindings/iio/adc/st,stm32-dfsdm-adc.yaml | 2 -- .../devicetree/bindings/interrupt-controller/fsl,irqsteer.yaml | 1 - .../devicetree/bindings/interrupt-controller/loongson,liointc.yaml | 1 - Documentation/devicetree/bindings/iommu/arm,smmu-v3.yaml | 1 - Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml | 1 - Documentation/devicetree/bindings/mailbox/st,stm32-ipcc.yaml | 2 -- Documentation/devicetree/bindings/media/amlogic,gx-vdec.yaml | 1 - Documentation/devicetree/bindings/media/i2c/adv7604.yaml | 1 - Documentation/devicetree/bindings/media/marvell,mmp2-ccic.yaml | 1 - Documentation/devicetree/bindings/media/qcom,sc7180-venus.yaml | 1 - Documentation/devicetree/bindings/media/qcom,sdm845-venus-v2.yaml | 1 - Documentation/devicetree/bindings/media/qcom,sm8250-venus.yaml | 1 - Documentation/devicetree/bindings/media/renesas,drif.yaml | 2 -- .../devicetree/bindings/memory-controllers/mediatek,smi-common.yaml | 6 ++---- .../devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml | 1 - Documentation/devicetree/bindings/mmc/allwinner,sun4i-a10-mmc.yaml | 2 -- Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml | 1 - Documentation/devicetree/bindings/mmc/mtk-sd.yaml | 2 -- Documentation/devicetree/bindings/mmc/renesas,sdhi.yaml | 2 -- Documentation/devicetree/bindings/mmc/sdhci-am654.yaml | 1 - Documentation/devicetree/bindings/mmc/sdhci-pxa.yaml | 1 - Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml | 2 -- Documentation/devicetree/bindings/net/brcm,bcm4908-enet.yaml | 2 -- Documentation/devicetree/bindings/net/can/bosch,m_can.yaml | 2 -- Documentation/devicetree/bindings/net/dsa/brcm,sf2.yaml | 2 -- Documentation/devicetree/bindings/net/mdio-gpio.yaml | 1 - Documentation/devicetree/bindings/net/snps,dwmac.yaml | 2 -- Documentation/devicetree/bindings/net/stm32-dwmac.yaml | 1 - Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml | 2 -- Documentation/devicetree/bindings/pci/loongson.yaml | 1 - Documentation/devicetree/bindings/pci/mediatek-pcie-gen3.yaml | 1 - Documentation/devicetree/bindings/pci/microchip,pcie-host.yaml | 2 -- Documentation/devicetree/bindings/perf/arm,cmn.yaml | 1 - Documentation/devicetree/bindings/phy/brcm,bcm63xx-usbh-phy.yaml | 1 - Documentation/devicetree/bindings/phy/brcm,brcmstb-usb-phy.yaml | 3 --- Documentation/devicetree/bindings/phy/brcm,sata-phy.yaml | 1 - Documentation/devicetree/bindings/phy/mediatek,tphy.yaml | 2 -- Documentation/devicetree/bindings/phy/phy-cadence-sierra.yaml | 2 -- Documentation/devicetree/bindings/phy/phy-cadence-torrent.yaml | 4 ---- Documentation/devicetree/bindings/phy/qcom,ipq806x-usb-phy-hs.yaml | 1 - Documentation/devicetree/bindings/phy/qcom,ipq806x-usb-phy-ss.yaml | 1 - Documentation/devicetree/bindings/phy/qcom,qmp-phy.yaml | 1 - Documentation/devicetree/bindings/phy/qcom,qusb2-phy.yaml | 2 -- Documentation/devicetree/bindings/phy/renesas,usb2-phy.yaml | 2 -- Documentation/devicetree/bindings/phy/renesas,usb3-phy.yaml | 1 - Documentation/devicetree/bindings/pinctrl/actions,s500-pinctrl.yaml | 1 - Documentation/devicetree/bindings/power/amlogic,meson-ee-pwrc.yaml | 1 - Documentation/devicetree/bindings/pwm/allwinner,sun4i-a10-pwm.yaml | 1 - Documentation/devicetree/bindings/remoteproc/st,stm32-rproc.yaml | 2 -- .../devicetree/bindings/remoteproc/ti,omap-remoteproc.yaml | 1 - Documentation/devicetree/bindings/reset/fsl,imx-src.yaml | 1 - Documentation/devicetree/bindings/riscv/sifive-l2-cache.yaml | 1 - Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml | 1 - Documentation/devicetree/bindings/rtc/imxdi-rtc.yaml | 1 - Documentation/devicetree/bindings/serial/fsl-lpuart.yaml | 2 -- Documentation/devicetree/bindings/serial/samsung_uart.yaml | 1 - Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.yaml | 1 - Documentation/devicetree/bindings/soc/ti/ti,pruss.yaml | 2 -- .../devicetree/bindings/sound/nvidia,tegra-audio-graph-card.yaml | 1 - Documentation/devicetree/bindings/sound/nvidia,tegra210-i2s.yaml | 2 -- Documentation/devicetree/bindings/sound/st,stm32-sai.yaml | 3 --- Documentation/devicetree/bindings/spi/amlogic,meson-gx-spicc.yaml | 1 - Documentation/devicetree/bindings/spi/brcm,spi-bcm-qspi.yaml | 2 -- .../devicetree/bindings/thermal/allwinner,sun8i-a83t-ths.yaml | 2 -- Documentation/devicetree/bindings/thermal/qcom-tsens.yaml | 1 - .../devicetree/bindings/timer/allwinner,sun5i-a13-hstimer.yaml | 1 - Documentation/devicetree/bindings/timer/arm,arch_timer.yaml | 1 - Documentation/devicetree/bindings/timer/arm,arch_timer_mmio.yaml | 2 -- Documentation/devicetree/bindings/timer/intel,ixp4xx-timer.yaml | 1 - Documentation/devicetree/bindings/usb/maxim,max3420-udc.yaml | 2 -- Documentation/devicetree/bindings/usb/nvidia,tegra-xudc.yaml | 4 ---- Documentation/devicetree/bindings/usb/renesas,usbhs.yaml | 3 --- Documentation/devicetree/bindings/watchdog/st,stm32-iwdg.yaml | 1 - 103 files changed, 2 insertions(+), 166 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/ata/nvidia,tegra-ahci.yaml b/Documentation/devicetree/bindings/ata/nvidia,tegra-ahci.yaml index a75e9a8f539a..3c7a2425f3e6 100644 --- a/Documentation/devicetree/bindings/ata/nvidia,tegra-ahci.yaml +++ b/Documentation/devicetree/bindings/ata/nvidia,tegra-ahci.yaml @@ -20,7 +20,6 @@ properties: reg: minItems: 2 - maxItems: 3 items: - description: AHCI registers - description: SATA configuration and IPFS registers diff --git a/Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-ccu.yaml b/Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-ccu.yaml index a27025cd3909..c4b7243ddcf2 100644 --- a/Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-ccu.yaml +++ b/Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-ccu.yaml @@ -51,7 +51,6 @@ properties: clocks: minItems: 2 - maxItems: 4 items: - description: High Frequency Oscillator (usually at 24MHz) - description: Low Frequency Oscillator (usually at 32kHz) @@ -60,7 +59,6 @@ properties: clock-names: minItems: 2 - maxItems: 4 items: - const: hosc - const: losc diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-apq8064.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-apq8064.yaml index eacccc88bbf6..8e2eac6cbfb9 100644 --- a/Documentation/devicetree/bindings/clock/qcom,gcc-apq8064.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,gcc-apq8064.yaml @@ -46,7 +46,6 @@ properties: nvmem-cell-names: minItems: 1 - maxItems: 2 items: - const: calib - const: calib_backup diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-sdx55.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-sdx55.yaml index 1121b3934cb9..b0d1c65aa354 100644 --- a/Documentation/devicetree/bindings/clock/qcom,gcc-sdx55.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,gcc-sdx55.yaml @@ -27,7 +27,6 @@ properties: - description: Sleep clock source - description: PLL test clock source (Optional clock) minItems: 2 - maxItems: 3 clock-names: items: @@ -35,7 +34,6 @@ properties: - const: sleep_clk - const: core_bi_pll_test_se # Optional clock minItems: 2 - maxItems: 3 '#clock-cells': const: 1 diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-sm8350.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-sm8350.yaml index 78f35832aa41..1122700dcc2b 100644 --- a/Documentation/devicetree/bindings/clock/qcom,gcc-sm8350.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,gcc-sm8350.yaml @@ -36,7 +36,6 @@ properties: - description: USB3 phy wrapper pipe clock source (Optional clock) - description: USB3 phy sec pipe clock source (Optional clock) minItems: 2 - maxItems: 13 clock-names: items: @@ -54,7 +53,6 @@ properties: - const: usb3_phy_wrapper_gcc_usb30_pipe_clk # Optional clock - const: usb3_uni_phy_sec_gcc_usb30_pipe_clk # Optional clock minItems: 2 - maxItems: 13 '#clock-cells': const: 1 diff --git a/Documentation/devicetree/bindings/clock/sprd,sc9863a-clk.yaml b/Documentation/devicetree/bindings/clock/sprd,sc9863a-clk.yaml index 4069e09cb62d..47e1ab08c95d 100644 --- a/Documentation/devicetree/bindings/clock/sprd,sc9863a-clk.yaml +++ b/Documentation/devicetree/bindings/clock/sprd,sc9863a-clk.yaml @@ -40,7 +40,6 @@ properties: clock-names: minItems: 1 - maxItems: 4 items: - const: ext-26m - const: ext-32k diff --git a/Documentation/devicetree/bindings/crypto/allwinner,sun8i-ce.yaml b/Documentation/devicetree/bindings/crypto/allwinner,sun8i-ce.yaml index 6ab07eba7778..00648f9d9278 100644 --- a/Documentation/devicetree/bindings/crypto/allwinner,sun8i-ce.yaml +++ b/Documentation/devicetree/bindings/crypto/allwinner,sun8i-ce.yaml @@ -30,7 +30,6 @@ properties: - description: Module clock - description: MBus clock minItems: 2 - maxItems: 3 clock-names: items: @@ -38,7 +37,6 @@ properties: - const: mod - const: ram minItems: 2 - maxItems: 3 resets: maxItems: 1 diff --git a/Documentation/devicetree/bindings/crypto/fsl-dcp.yaml b/Documentation/devicetree/bindings/crypto/fsl-dcp.yaml index a30bf38a4a49..99be01539fcd 100644 --- a/Documentation/devicetree/bindings/crypto/fsl-dcp.yaml +++ b/Documentation/devicetree/bindings/crypto/fsl-dcp.yaml @@ -27,7 +27,6 @@ properties: - description: MXS DCP DCP interrupt - description: MXS DCP secure interrupt minItems: 2 - maxItems: 3 clocks: maxItems: 1 diff --git a/Documentation/devicetree/bindings/display/allwinner,sun4i-a10-display-backend.yaml b/Documentation/devicetree/bindings/display/allwinner,sun4i-a10-display-backend.yaml index 12a7df0e38b2..3d8ea3c2d8dd 100644 --- a/Documentation/devicetree/bindings/display/allwinner,sun4i-a10-display-backend.yaml +++ b/Documentation/devicetree/bindings/display/allwinner,sun4i-a10-display-backend.yaml @@ -26,14 +26,12 @@ properties: reg: minItems: 1 - maxItems: 2 items: - description: Display Backend registers - description: SAT registers reg-names: minItems: 1 - maxItems: 2 items: - const: be - const: sat @@ -43,7 +41,6 @@ properties: clocks: minItems: 3 - maxItems: 4 items: - description: The backend interface clock - description: The backend module clock @@ -52,7 +49,6 @@ properties: clock-names: minItems: 3 - maxItems: 4 items: - const: ahb - const: mod @@ -61,14 +57,12 @@ properties: resets: minItems: 1 - maxItems: 2 items: - description: The Backend reset line - description: The SAT reset line reset-names: minItems: 1 - maxItems: 2 items: - const: be - const: sat diff --git a/Documentation/devicetree/bindings/display/allwinner,sun6i-a31-mipi-dsi.yaml b/Documentation/devicetree/bindings/display/allwinner,sun6i-a31-mipi-dsi.yaml index a738d7c12a97..bf0bdf54e5f9 100644 --- a/Documentation/devicetree/bindings/display/allwinner,sun6i-a31-mipi-dsi.yaml +++ b/Documentation/devicetree/bindings/display/allwinner,sun6i-a31-mipi-dsi.yaml @@ -24,7 +24,6 @@ properties: clocks: minItems: 1 - maxItems: 2 items: - description: Bus Clock - description: Module Clock diff --git a/Documentation/devicetree/bindings/display/allwinner,sun8i-a83t-dw-hdmi.yaml b/Documentation/devicetree/bindings/display/allwinner,sun8i-a83t-dw-hdmi.yaml index 907fb47cc84a..5d42d36608d9 100644 --- a/Documentation/devicetree/bindings/display/allwinner,sun8i-a83t-dw-hdmi.yaml +++ b/Documentation/devicetree/bindings/display/allwinner,sun8i-a83t-dw-hdmi.yaml @@ -46,7 +46,6 @@ properties: clocks: minItems: 3 - maxItems: 6 items: - description: Bus Clock - description: Register Clock @@ -57,7 +56,6 @@ properties: clock-names: minItems: 3 - maxItems: 6 items: - const: iahb - const: isfr @@ -68,14 +66,12 @@ properties: resets: minItems: 1 - maxItems: 2 items: - description: HDMI Controller Reset - description: HDCP Reset reset-names: minItems: 1 - maxItems: 2 items: - const: ctrl - const: hdcp diff --git a/Documentation/devicetree/bindings/display/allwinner,sun8i-a83t-hdmi-phy.yaml b/Documentation/devicetree/bindings/display/allwinner,sun8i-a83t-hdmi-phy.yaml index 501cec16168c..a97366aaf924 100644 --- a/Documentation/devicetree/bindings/display/allwinner,sun8i-a83t-hdmi-phy.yaml +++ b/Documentation/devicetree/bindings/display/allwinner,sun8i-a83t-hdmi-phy.yaml @@ -27,7 +27,6 @@ properties: clocks: minItems: 2 - maxItems: 4 items: - description: Bus Clock - description: Module Clock @@ -36,7 +35,6 @@ properties: clock-names: minItems: 2 - maxItems: 4 items: - const: bus - const: mod diff --git a/Documentation/devicetree/bindings/display/allwinner,sun8i-r40-tcon-top.yaml b/Documentation/devicetree/bindings/display/allwinner,sun8i-r40-tcon-top.yaml index ec21e8bf2767..61ef7b337218 100644 --- a/Documentation/devicetree/bindings/display/allwinner,sun8i-r40-tcon-top.yaml +++ b/Documentation/devicetree/bindings/display/allwinner,sun8i-r40-tcon-top.yaml @@ -48,7 +48,6 @@ properties: clocks: minItems: 2 - maxItems: 6 items: - description: The TCON TOP interface clock - description: The TCON TOP TV0 clock @@ -59,7 +58,6 @@ properties: clock-names: minItems: 2 - maxItems: 6 items: - const: bus - const: tcon-tv0 diff --git a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.yaml b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.yaml index 87f485ee2fb5..d3dd7a79b909 100644 --- a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.yaml +++ b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.yaml @@ -39,7 +39,6 @@ properties: Names of maps with programmable addresses. It can contain any map needing a non-default address. minItems: 1 - maxItems: 4 items: - const: main - const: edid diff --git a/Documentation/devicetree/bindings/display/bridge/cdns,mhdp8546.yaml b/Documentation/devicetree/bindings/display/bridge/cdns,mhdp8546.yaml index 63427878715e..9a3208a15137 100644 --- a/Documentation/devicetree/bindings/display/bridge/cdns,mhdp8546.yaml +++ b/Documentation/devicetree/bindings/display/bridge/cdns,mhdp8546.yaml @@ -18,7 +18,6 @@ properties: reg: minItems: 1 - maxItems: 2 items: - description: Register block of mhdptx apb registers up to PHY mapped area (AUX_CONFIG_P). @@ -29,7 +28,6 @@ properties: reg-names: minItems: 1 - maxItems: 2 items: - const: mhdptx - const: j721e-intg diff --git a/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml b/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml index 75cd9c686e98..da3b889ad8fc 100644 --- a/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml +++ b/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml @@ -29,7 +29,6 @@ properties: clocks: minItems: 2 - maxItems: 5 items: - {} - {} @@ -41,7 +40,6 @@ properties: clock-names: minItems: 2 - maxItems: 5 items: - {} - {} diff --git a/Documentation/devicetree/bindings/display/st,stm32-dsi.yaml b/Documentation/devicetree/bindings/display/st,stm32-dsi.yaml index 679daed4124e..ed310bbe3afe 100644 --- a/Documentation/devicetree/bindings/display/st,stm32-dsi.yaml +++ b/Documentation/devicetree/bindings/display/st,stm32-dsi.yaml @@ -29,7 +29,6 @@ properties: - description: DSI bus clock - description: Pixel clock minItems: 2 - maxItems: 3 clock-names: items: @@ -37,7 +36,6 @@ properties: - const: ref - const: px_clk minItems: 2 - maxItems: 3 resets: maxItems: 1 diff --git a/Documentation/devicetree/bindings/display/st,stm32-ltdc.yaml b/Documentation/devicetree/bindings/display/st,stm32-ltdc.yaml index d54f9ca207af..4ae3d75492d3 100644 --- a/Documentation/devicetree/bindings/display/st,stm32-ltdc.yaml +++ b/Documentation/devicetree/bindings/display/st,stm32-ltdc.yaml @@ -22,7 +22,6 @@ properties: - description: events interrupt line. - description: errors interrupt line. minItems: 1 - maxItems: 2 clocks: maxItems: 1 diff --git a/Documentation/devicetree/bindings/display/xlnx/xlnx,zynqmp-dpsub.yaml b/Documentation/devicetree/bindings/display/xlnx/xlnx,zynqmp-dpsub.yaml index 403d57977ee7..d88bd93f4b80 100644 --- a/Documentation/devicetree/bindings/display/xlnx/xlnx,zynqmp-dpsub.yaml +++ b/Documentation/devicetree/bindings/display/xlnx/xlnx,zynqmp-dpsub.yaml @@ -65,7 +65,6 @@ properties: The APB clock and at least one video clock are mandatory, the audio clock is optional. minItems: 2 - maxItems: 4 items: - description: dp_apb_clk is the APB clock - description: dp_aud_clk is the Audio clock @@ -78,13 +77,11 @@ properties: clock-names: oneOf: - minItems: 2 - maxItems: 3 items: - const: dp_apb_clk - enum: [ dp_vtc_pixel_clk_in, dp_live_video_in_clk ] - enum: [ dp_vtc_pixel_clk_in, dp_live_video_in_clk ] - minItems: 3 - maxItems: 4 items: - const: dp_apb_clk - const: dp_aud_clk @@ -116,7 +113,6 @@ properties: maxItems: 2 phy-names: minItems: 1 - maxItems: 2 items: - const: dp-phy0 - const: dp-phy1 diff --git a/Documentation/devicetree/bindings/dma/renesas,rcar-dmac.yaml b/Documentation/devicetree/bindings/dma/renesas,rcar-dmac.yaml index 7f2a54bc732d..d8142cbd13d3 100644 --- a/Documentation/devicetree/bindings/dma/renesas,rcar-dmac.yaml +++ b/Documentation/devicetree/bindings/dma/renesas,rcar-dmac.yaml @@ -52,7 +52,6 @@ properties: interrupt-names: minItems: 9 - maxItems: 17 items: - const: error - pattern: "^ch([0-9]|1[0-5])$" diff --git a/Documentation/devicetree/bindings/edac/amazon,al-mc-edac.yaml b/Documentation/devicetree/bindings/edac/amazon,al-mc-edac.yaml index 57e5270a0741..4cfc3a187004 100644 --- a/Documentation/devicetree/bindings/edac/amazon,al-mc-edac.yaml +++ b/Documentation/devicetree/bindings/edac/amazon,al-mc-edac.yaml @@ -30,14 +30,12 @@ properties: interrupts: minItems: 1 - maxItems: 2 items: - description: uncorrectable error interrupt - description: correctable error interrupt interrupt-names: minItems: 1 - maxItems: 2 items: - const: ue - const: ce diff --git a/Documentation/devicetree/bindings/eeprom/at24.yaml b/Documentation/devicetree/bindings/eeprom/at24.yaml index 021d8ae42da3..914a423ec449 100644 --- a/Documentation/devicetree/bindings/eeprom/at24.yaml +++ b/Documentation/devicetree/bindings/eeprom/at24.yaml @@ -32,7 +32,6 @@ properties: oneOf: - allOf: - minItems: 1 - maxItems: 2 items: - pattern: "^(atmel|catalyst|microchip|nxp|ramtron|renesas|rohm|st),(24(c|cs|lc|mac)[0-9]+|spd)$" - pattern: "^atmel,(24(c|cs|mac)[0-9]+|spd)$" diff --git a/Documentation/devicetree/bindings/example-schema.yaml b/Documentation/devicetree/bindings/example-schema.yaml index a97f39109f8d..ff6ec65145cf 100644 --- a/Documentation/devicetree/bindings/example-schema.yaml +++ b/Documentation/devicetree/bindings/example-schema.yaml @@ -91,7 +91,6 @@ properties: interrupts: # Either 1 or 2 interrupts can be present minItems: 1 - maxItems: 2 items: - description: tx or combined interrupt - description: rx interrupt @@ -105,7 +104,6 @@ properties: interrupt-names: # minItems must be specified here because the default would be 2 minItems: 1 - maxItems: 2 items: - const: tx irq - const: rx irq diff --git a/Documentation/devicetree/bindings/gpu/brcm,bcm-v3d.yaml b/Documentation/devicetree/bindings/gpu/brcm,bcm-v3d.yaml index 9d72264fa90a..e6485f7b046f 100644 --- a/Documentation/devicetree/bindings/gpu/brcm,bcm-v3d.yaml +++ b/Documentation/devicetree/bindings/gpu/brcm,bcm-v3d.yaml @@ -34,7 +34,6 @@ properties: - enum: [ bridge, gca ] - enum: [ bridge, gca ] minItems: 2 - maxItems: 4 interrupts: items: diff --git a/Documentation/devicetree/bindings/gpu/vivante,gc.yaml b/Documentation/devicetree/bindings/gpu/vivante,gc.yaml index 3ed172629974..93e7244cdc0e 100644 --- a/Documentation/devicetree/bindings/gpu/vivante,gc.yaml +++ b/Documentation/devicetree/bindings/gpu/vivante,gc.yaml @@ -36,7 +36,6 @@ properties: - description: AHB/slave interface clock (only required if GPU can gate slave interface independently) minItems: 1 - maxItems: 4 clock-names: items: diff --git a/Documentation/devicetree/bindings/i2c/aspeed,i2c.yaml b/Documentation/devicetree/bindings/i2c/aspeed,i2c.yaml index 9a40605c3433..ea643e6c3ef5 100644 --- a/Documentation/devicetree/bindings/i2c/aspeed,i2c.yaml +++ b/Documentation/devicetree/bindings/i2c/aspeed,i2c.yaml @@ -21,7 +21,6 @@ properties: reg: minItems: 1 - maxItems: 2 items: - description: address offset and range of bus - description: address offset and range of bus buffer diff --git a/Documentation/devicetree/bindings/i2c/brcm,brcmstb-i2c.yaml b/Documentation/devicetree/bindings/i2c/brcm,brcmstb-i2c.yaml index edbca2476128..7070c04469ed 100644 --- a/Documentation/devicetree/bindings/i2c/brcm,brcmstb-i2c.yaml +++ b/Documentation/devicetree/bindings/i2c/brcm,brcmstb-i2c.yaml @@ -21,7 +21,6 @@ properties: reg: minItems: 1 - maxItems: 2 items: - description: BSC register range - description: Auto-I2C register range diff --git a/Documentation/devicetree/bindings/i2c/marvell,mv64xxx-i2c.yaml b/Documentation/devicetree/bindings/i2c/marvell,mv64xxx-i2c.yaml index eb72dd571def..f771c09aabfc 100644 --- a/Documentation/devicetree/bindings/i2c/marvell,mv64xxx-i2c.yaml +++ b/Documentation/devicetree/bindings/i2c/marvell,mv64xxx-i2c.yaml @@ -43,14 +43,12 @@ properties: clocks: minItems: 1 - maxItems: 2 items: - description: Reference clock for the I2C bus - description: Bus clock (Only for Armada 7K/8K) clock-names: minItems: 1 - maxItems: 2 items: - const: core - const: reg diff --git a/Documentation/devicetree/bindings/i2c/mellanox,i2c-mlxbf.yaml b/Documentation/devicetree/bindings/i2c/mellanox,i2c-mlxbf.yaml index d2b401d062b9..93198d5d43a6 100644 --- a/Documentation/devicetree/bindings/i2c/mellanox,i2c-mlxbf.yaml +++ b/Documentation/devicetree/bindings/i2c/mellanox,i2c-mlxbf.yaml @@ -20,7 +20,6 @@ properties: reg: minItems: 3 - maxItems: 4 items: - description: Smbus block registers - description: Cause master registers diff --git a/Documentation/devicetree/bindings/iio/adc/amlogic,meson-saradc.yaml b/Documentation/devicetree/bindings/iio/adc/amlogic,meson-saradc.yaml index 3be8955587e4..7e8328e9ce13 100644 --- a/Documentation/devicetree/bindings/iio/adc/amlogic,meson-saradc.yaml +++ b/Documentation/devicetree/bindings/iio/adc/amlogic,meson-saradc.yaml @@ -41,7 +41,6 @@ properties: clock-names: minItems: 2 - maxItems: 4 items: - const: clkin - const: core diff --git a/Documentation/devicetree/bindings/iio/adc/st,stm32-dfsdm-adc.yaml b/Documentation/devicetree/bindings/iio/adc/st,stm32-dfsdm-adc.yaml index 6f2398cdc82d..b7b0ab928945 100644 --- a/Documentation/devicetree/bindings/iio/adc/st,stm32-dfsdm-adc.yaml +++ b/Documentation/devicetree/bindings/iio/adc/st,stm32-dfsdm-adc.yaml @@ -38,14 +38,12 @@ properties: dfsdm clock can also feed CLKOUT, when CLKOUT is used. - description: audio clock can be used as an alternate to feed CLKOUT. minItems: 1 - maxItems: 2 clock-names: items: - const: dfsdm - const: audio minItems: 1 - maxItems: 2 "#address-cells": const: 1 diff --git a/Documentation/devicetree/bindings/interrupt-controller/fsl,irqsteer.yaml b/Documentation/devicetree/bindings/interrupt-controller/fsl,irqsteer.yaml index 3b11a1a15398..bcb5e20fa9ca 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/fsl,irqsteer.yaml +++ b/Documentation/devicetree/bindings/interrupt-controller/fsl,irqsteer.yaml @@ -35,7 +35,6 @@ properties: - description: output interrupt 6 - description: output interrupt 7 minItems: 1 - maxItems: 8 clocks: maxItems: 1 diff --git a/Documentation/devicetree/bindings/interrupt-controller/loongson,liointc.yaml b/Documentation/devicetree/bindings/interrupt-controller/loongson,liointc.yaml index 067165c4b836..edf26452dc72 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/loongson,liointc.yaml +++ b/Documentation/devicetree/bindings/interrupt-controller/loongson,liointc.yaml @@ -50,7 +50,6 @@ properties: - const: int2 - const: int3 minItems: 1 - maxItems: 4 '#interrupt-cells': const: 2 diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu-v3.yaml b/Documentation/devicetree/bindings/iommu/arm,smmu-v3.yaml index 5951c6f98c74..e87bfbcc6913 100644 --- a/Documentation/devicetree/bindings/iommu/arm,smmu-v3.yaml +++ b/Documentation/devicetree/bindings/iommu/arm,smmu-v3.yaml @@ -38,7 +38,6 @@ properties: If provided, then the combined interrupt will be used in preference to any others. - minItems: 2 - maxItems: 4 items: - const: eventq # Event Queue not empty - const: gerror # Global Error activated diff --git a/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml b/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml index dda44976acc1..02c69a95c332 100644 --- a/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml +++ b/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml @@ -49,7 +49,6 @@ properties: interrupts: minItems: 1 - maxItems: 2 description: Specifiers for the MMU fault interrupts. Not required for cache IPMMUs. items: diff --git a/Documentation/devicetree/bindings/mailbox/st,stm32-ipcc.yaml b/Documentation/devicetree/bindings/mailbox/st,stm32-ipcc.yaml index 3b7ab61a144f..b15da9ba90b2 100644 --- a/Documentation/devicetree/bindings/mailbox/st,stm32-ipcc.yaml +++ b/Documentation/devicetree/bindings/mailbox/st,stm32-ipcc.yaml @@ -32,7 +32,6 @@ properties: - description: tx channel free - description: wakeup source minItems: 2 - maxItems: 3 interrupt-names: items: @@ -40,7 +39,6 @@ properties: - const: tx - const: wakeup minItems: 2 - maxItems: 3 wakeup-source: true diff --git a/Documentation/devicetree/bindings/media/amlogic,gx-vdec.yaml b/Documentation/devicetree/bindings/media/amlogic,gx-vdec.yaml index b902495d278b..5044c4bb94e0 100644 --- a/Documentation/devicetree/bindings/media/amlogic,gx-vdec.yaml +++ b/Documentation/devicetree/bindings/media/amlogic,gx-vdec.yaml @@ -67,7 +67,6 @@ properties: clock-names: minItems: 4 - maxItems: 5 items: - const: dos_parser - const: dos diff --git a/Documentation/devicetree/bindings/media/i2c/adv7604.yaml b/Documentation/devicetree/bindings/media/i2c/adv7604.yaml index df634b0c1f8c..de15cebe2955 100644 --- a/Documentation/devicetree/bindings/media/i2c/adv7604.yaml +++ b/Documentation/devicetree/bindings/media/i2c/adv7604.yaml @@ -30,7 +30,6 @@ properties: reg-names: minItems: 1 - maxItems: 13 items: - const: main - enum: [ avlink, cec, infoframe, esdp, dpp, afe, rep, edid, hdmi, test, cp, vdp ] diff --git a/Documentation/devicetree/bindings/media/marvell,mmp2-ccic.yaml b/Documentation/devicetree/bindings/media/marvell,mmp2-ccic.yaml index c14c7d827b00..b39b84c5f012 100644 --- a/Documentation/devicetree/bindings/media/marvell,mmp2-ccic.yaml +++ b/Documentation/devicetree/bindings/media/marvell,mmp2-ccic.yaml @@ -43,7 +43,6 @@ properties: clocks: minItems: 1 - maxItems: 3 items: - description: AXI bus interface clock - description: Peripheral clock diff --git a/Documentation/devicetree/bindings/media/qcom,sc7180-venus.yaml b/Documentation/devicetree/bindings/media/qcom,sc7180-venus.yaml index 04013e5dd044..90b4af2c9724 100644 --- a/Documentation/devicetree/bindings/media/qcom,sc7180-venus.yaml +++ b/Documentation/devicetree/bindings/media/qcom,sc7180-venus.yaml @@ -30,7 +30,6 @@ properties: power-domain-names: minItems: 2 - maxItems: 3 items: - const: venus - const: vcodec0 diff --git a/Documentation/devicetree/bindings/media/qcom,sdm845-venus-v2.yaml b/Documentation/devicetree/bindings/media/qcom,sdm845-venus-v2.yaml index 04b9af4db191..177bf81544b1 100644 --- a/Documentation/devicetree/bindings/media/qcom,sdm845-venus-v2.yaml +++ b/Documentation/devicetree/bindings/media/qcom,sdm845-venus-v2.yaml @@ -30,7 +30,6 @@ properties: power-domain-names: minItems: 3 - maxItems: 4 items: - const: venus - const: vcodec0 diff --git a/Documentation/devicetree/bindings/media/qcom,sm8250-venus.yaml b/Documentation/devicetree/bindings/media/qcom,sm8250-venus.yaml index 7b81bd7f2399..ebf8f3d866a5 100644 --- a/Documentation/devicetree/bindings/media/qcom,sm8250-venus.yaml +++ b/Documentation/devicetree/bindings/media/qcom,sm8250-venus.yaml @@ -30,7 +30,6 @@ properties: power-domain-names: minItems: 2 - maxItems: 3 items: - const: venus - const: vcodec0 diff --git a/Documentation/devicetree/bindings/media/renesas,drif.yaml b/Documentation/devicetree/bindings/media/renesas,drif.yaml index f1bdaeab4053..c47dbefd27d8 100644 --- a/Documentation/devicetree/bindings/media/renesas,drif.yaml +++ b/Documentation/devicetree/bindings/media/renesas,drif.yaml @@ -67,7 +67,6 @@ properties: maxItems: 1 clock-names: - maxItems: 1 items: - const: fck @@ -80,7 +79,6 @@ properties: dma-names: minItems: 1 - maxItems: 2 items: - const: rx - const: rx diff --git a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.yaml b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.yaml index a08a32340987..e87e4382807c 100644 --- a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.yaml +++ b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.yaml @@ -53,14 +53,12 @@ properties: apb and smi are mandatory. the async is only for generation 1 smi HW. gals(global async local sync) also is optional, see below. minItems: 2 - maxItems: 4 items: - description: apb is Advanced Peripheral Bus clock, It's the clock for setting the register. - description: smi is the clock for transfer data and command. - - description: async is asynchronous clock, it help transform the smi - clock into the emi clock domain. - - description: gals0 is the path0 clock of gals. + - description: Either asynchronous clock to help transform the smi clock + into the emi clock domain on Gen1 h/w, or the path0 clock of gals. - description: gals1 is the path1 clock of gals. clock-names: diff --git a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml index 7ed7839ff0a7..2353f6cf3c80 100644 --- a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml +++ b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml @@ -37,7 +37,6 @@ properties: description: | apb and smi are mandatory. gals(global async local sync) is optional. minItems: 2 - maxItems: 3 items: - description: apb is Advanced Peripheral Bus clock, It's the clock for setting the register. diff --git a/Documentation/devicetree/bindings/mmc/allwinner,sun4i-a10-mmc.yaml b/Documentation/devicetree/bindings/mmc/allwinner,sun4i-a10-mmc.yaml index e75b3a8ba816..4f62ad6ce50c 100644 --- a/Documentation/devicetree/bindings/mmc/allwinner,sun4i-a10-mmc.yaml +++ b/Documentation/devicetree/bindings/mmc/allwinner,sun4i-a10-mmc.yaml @@ -64,7 +64,6 @@ properties: clocks: minItems: 2 - maxItems: 4 items: - description: Bus Clock - description: Module Clock @@ -73,7 +72,6 @@ properties: clock-names: minItems: 2 - maxItems: 4 items: - const: ahb - const: mmc diff --git a/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml b/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml index 369471814496..b5baf439fbac 100644 --- a/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml +++ b/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml @@ -116,7 +116,6 @@ properties: pinctrl-names: minItems: 1 - maxItems: 4 items: - const: default - const: state_100mhz diff --git a/Documentation/devicetree/bindings/mmc/mtk-sd.yaml b/Documentation/devicetree/bindings/mmc/mtk-sd.yaml index 8648d48dbbfd..4e553fd0349f 100644 --- a/Documentation/devicetree/bindings/mmc/mtk-sd.yaml +++ b/Documentation/devicetree/bindings/mmc/mtk-sd.yaml @@ -38,7 +38,6 @@ properties: description: Should contain phandle for the clock feeding the MMC controller. minItems: 2 - maxItems: 8 items: - description: source clock (required). - description: HCLK which used for host (required). @@ -51,7 +50,6 @@ properties: clock-names: minItems: 2 - maxItems: 8 items: - const: source - const: hclk diff --git a/Documentation/devicetree/bindings/mmc/renesas,sdhi.yaml b/Documentation/devicetree/bindings/mmc/renesas,sdhi.yaml index 1118b6fa93c9..677989bc5924 100644 --- a/Documentation/devicetree/bindings/mmc/renesas,sdhi.yaml +++ b/Documentation/devicetree/bindings/mmc/renesas,sdhi.yaml @@ -75,7 +75,6 @@ properties: clock-names: minItems: 1 - maxItems: 2 items: - const: core - const: cd @@ -107,7 +106,6 @@ properties: pinctrl-names: minItems: 1 - maxItems: 2 items: - const: default - const: state_uhs diff --git a/Documentation/devicetree/bindings/mmc/sdhci-am654.yaml b/Documentation/devicetree/bindings/mmc/sdhci-am654.yaml index 3a79e39253d2..94a96174f99a 100644 --- a/Documentation/devicetree/bindings/mmc/sdhci-am654.yaml +++ b/Documentation/devicetree/bindings/mmc/sdhci-am654.yaml @@ -45,7 +45,6 @@ properties: clock-names: minItems: 1 - maxItems: 2 items: - const: clk_ahb - const: clk_xin diff --git a/Documentation/devicetree/bindings/mmc/sdhci-pxa.yaml b/Documentation/devicetree/bindings/mmc/sdhci-pxa.yaml index aa12480648a5..1c87f4218e18 100644 --- a/Documentation/devicetree/bindings/mmc/sdhci-pxa.yaml +++ b/Documentation/devicetree/bindings/mmc/sdhci-pxa.yaml @@ -57,7 +57,6 @@ properties: clock-names: minItems: 1 - maxItems: 2 items: - const: io - const: core diff --git a/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml b/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml index 0467441d7037..608e1d62bed5 100644 --- a/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml +++ b/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml @@ -43,7 +43,6 @@ allOf: properties: clocks: minItems: 3 - maxItems: 4 items: - description: GMAC main clock - description: First parent clock of the internal mux @@ -52,7 +51,6 @@ allOf: clock-names: minItems: 3 - maxItems: 4 items: - const: stmmaceth - const: clkin0 diff --git a/Documentation/devicetree/bindings/net/brcm,bcm4908-enet.yaml b/Documentation/devicetree/bindings/net/brcm,bcm4908-enet.yaml index 2f46e45dcd60..a93d2f165899 100644 --- a/Documentation/devicetree/bindings/net/brcm,bcm4908-enet.yaml +++ b/Documentation/devicetree/bindings/net/brcm,bcm4908-enet.yaml @@ -23,14 +23,12 @@ properties: interrupts: minItems: 1 - maxItems: 2 items: - description: RX interrupt - description: TX interrupt interrupt-names: minItems: 1 - maxItems: 2 items: - const: rx - const: tx diff --git a/Documentation/devicetree/bindings/net/can/bosch,m_can.yaml b/Documentation/devicetree/bindings/net/can/bosch,m_can.yaml index 798fa5fb7bb2..f84e31348d80 100644 --- a/Documentation/devicetree/bindings/net/can/bosch,m_can.yaml +++ b/Documentation/devicetree/bindings/net/can/bosch,m_can.yaml @@ -30,14 +30,12 @@ properties: - description: interrupt line0 - description: interrupt line1 minItems: 1 - maxItems: 2 interrupt-names: items: - const: int0 - const: int1 minItems: 1 - maxItems: 2 clocks: items: diff --git a/Documentation/devicetree/bindings/net/dsa/brcm,sf2.yaml b/Documentation/devicetree/bindings/net/dsa/brcm,sf2.yaml index d730fe5a4355..d159ac78cec1 100644 --- a/Documentation/devicetree/bindings/net/dsa/brcm,sf2.yaml +++ b/Documentation/devicetree/bindings/net/dsa/brcm,sf2.yaml @@ -48,14 +48,12 @@ properties: clocks: minItems: 1 - maxItems: 2 items: - description: switch's main clock - description: dividing of the switch core clock clock-names: minItems: 1 - maxItems: 2 items: - const: sw_switch - const: sw_switch_mdiv diff --git a/Documentation/devicetree/bindings/net/mdio-gpio.yaml b/Documentation/devicetree/bindings/net/mdio-gpio.yaml index 7c15a508af5b..1d83b8dcce2c 100644 --- a/Documentation/devicetree/bindings/net/mdio-gpio.yaml +++ b/Documentation/devicetree/bindings/net/mdio-gpio.yaml @@ -28,7 +28,6 @@ properties: gpios: minItems: 2 - maxItems: 3 items: - description: MDC - description: MDIO diff --git a/Documentation/devicetree/bindings/net/snps,dwmac.yaml b/Documentation/devicetree/bindings/net/snps,dwmac.yaml index 2edd8bea993e..5d4b028e5620 100644 --- a/Documentation/devicetree/bindings/net/snps,dwmac.yaml +++ b/Documentation/devicetree/bindings/net/snps,dwmac.yaml @@ -82,7 +82,6 @@ properties: interrupts: minItems: 1 - maxItems: 3 items: - description: Combined signal for various interrupt events - description: The interrupt to manage the remote wake-up packet detection @@ -90,7 +89,6 @@ properties: interrupt-names: minItems: 1 - maxItems: 3 items: - const: macirq - const: eth_wake_irq diff --git a/Documentation/devicetree/bindings/net/stm32-dwmac.yaml b/Documentation/devicetree/bindings/net/stm32-dwmac.yaml index 27eb6066793f..19c7bd482a51 100644 --- a/Documentation/devicetree/bindings/net/stm32-dwmac.yaml +++ b/Documentation/devicetree/bindings/net/stm32-dwmac.yaml @@ -46,7 +46,6 @@ properties: clocks: minItems: 3 - maxItems: 5 items: - description: GMAC main clock - description: MAC TX clock diff --git a/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml b/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml index f90557f6deb8..b9589a0daa5c 100644 --- a/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml +++ b/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml @@ -25,14 +25,12 @@ properties: interrupts: minItems: 1 - maxItems: 2 items: - description: PCIe host controller - description: builtin MSI controller interrupt-names: minItems: 1 - maxItems: 2 items: - const: pcie - const: msi diff --git a/Documentation/devicetree/bindings/pci/loongson.yaml b/Documentation/devicetree/bindings/pci/loongson.yaml index 81bae060cbde..82bc6c486ca3 100644 --- a/Documentation/devicetree/bindings/pci/loongson.yaml +++ b/Documentation/devicetree/bindings/pci/loongson.yaml @@ -24,7 +24,6 @@ properties: reg: minItems: 1 - maxItems: 2 items: - description: CFG0 standard config space register - description: CFG1 extended config space register diff --git a/Documentation/devicetree/bindings/pci/mediatek-pcie-gen3.yaml b/Documentation/devicetree/bindings/pci/mediatek-pcie-gen3.yaml index e7b1f9892da4..742206dbd965 100644 --- a/Documentation/devicetree/bindings/pci/mediatek-pcie-gen3.yaml +++ b/Documentation/devicetree/bindings/pci/mediatek-pcie-gen3.yaml @@ -70,7 +70,6 @@ properties: reset-names: minItems: 1 - maxItems: 2 items: - const: phy - const: mac diff --git a/Documentation/devicetree/bindings/pci/microchip,pcie-host.yaml b/Documentation/devicetree/bindings/pci/microchip,pcie-host.yaml index 04251d71f56b..fb95c276a986 100644 --- a/Documentation/devicetree/bindings/pci/microchip,pcie-host.yaml +++ b/Documentation/devicetree/bindings/pci/microchip,pcie-host.yaml @@ -26,14 +26,12 @@ properties: interrupts: minItems: 1 - maxItems: 2 items: - description: PCIe host controller - description: builtin MSI controller interrupt-names: minItems: 1 - maxItems: 2 items: - const: pcie - const: msi diff --git a/Documentation/devicetree/bindings/perf/arm,cmn.yaml b/Documentation/devicetree/bindings/perf/arm,cmn.yaml index e4fcc0de25e2..42424ccbdd0c 100644 --- a/Documentation/devicetree/bindings/perf/arm,cmn.yaml +++ b/Documentation/devicetree/bindings/perf/arm,cmn.yaml @@ -21,7 +21,6 @@ properties: interrupts: minItems: 1 - maxItems: 4 items: - description: Overflow interrupt for DTC0 - description: Overflow interrupt for DTC1 diff --git a/Documentation/devicetree/bindings/phy/brcm,bcm63xx-usbh-phy.yaml b/Documentation/devicetree/bindings/phy/brcm,bcm63xx-usbh-phy.yaml index 9a2e779e6d38..0f0bcde9eb88 100644 --- a/Documentation/devicetree/bindings/phy/brcm,bcm63xx-usbh-phy.yaml +++ b/Documentation/devicetree/bindings/phy/brcm,bcm63xx-usbh-phy.yaml @@ -28,7 +28,6 @@ properties: clock-names: minItems: 1 - maxItems: 2 items: - const: usbh - const: usb_ref diff --git a/Documentation/devicetree/bindings/phy/brcm,brcmstb-usb-phy.yaml b/Documentation/devicetree/bindings/phy/brcm,brcmstb-usb-phy.yaml index 5f9e91bfb5ff..43a4b880534c 100644 --- a/Documentation/devicetree/bindings/phy/brcm,brcmstb-usb-phy.yaml +++ b/Documentation/devicetree/bindings/phy/brcm,brcmstb-usb-phy.yaml @@ -22,7 +22,6 @@ properties: reg: minItems: 1 - maxItems: 6 items: - description: the base CTRL register - description: XHCI EC register @@ -33,7 +32,6 @@ properties: reg-names: minItems: 1 - maxItems: 6 items: - const: ctrl - const: xhci_ec @@ -51,7 +49,6 @@ properties: clock-names: minItems: 1 - maxItems: 2 items: - const: sw_usb - const: sw_usb3 diff --git a/Documentation/devicetree/bindings/phy/brcm,sata-phy.yaml b/Documentation/devicetree/bindings/phy/brcm,sata-phy.yaml index 04edda504ab6..cb1aa325336f 100644 --- a/Documentation/devicetree/bindings/phy/brcm,sata-phy.yaml +++ b/Documentation/devicetree/bindings/phy/brcm,sata-phy.yaml @@ -35,7 +35,6 @@ properties: reg-names: minItems: 1 - maxItems: 2 items: - const: phy - const: phy-ctrl diff --git a/Documentation/devicetree/bindings/phy/mediatek,tphy.yaml b/Documentation/devicetree/bindings/phy/mediatek,tphy.yaml index b8a7651a3d9a..ef9d9d4e6875 100644 --- a/Documentation/devicetree/bindings/phy/mediatek,tphy.yaml +++ b/Documentation/devicetree/bindings/phy/mediatek,tphy.yaml @@ -131,7 +131,6 @@ patternProperties: clocks: minItems: 1 - maxItems: 2 items: - description: Reference clock, (HS is 48Mhz, SS/P is 24~27Mhz) - description: Reference clock of analog phy @@ -141,7 +140,6 @@ patternProperties: clock-names: minItems: 1 - maxItems: 2 items: - const: ref - const: da_ref diff --git a/Documentation/devicetree/bindings/phy/phy-cadence-sierra.yaml b/Documentation/devicetree/bindings/phy/phy-cadence-sierra.yaml index 84383e2e0b34..e71b32c9c0d1 100644 --- a/Documentation/devicetree/bindings/phy/phy-cadence-sierra.yaml +++ b/Documentation/devicetree/bindings/phy/phy-cadence-sierra.yaml @@ -31,14 +31,12 @@ properties: resets: minItems: 1 - maxItems: 2 items: - description: Sierra PHY reset. - description: Sierra APB reset. This is optional. reset-names: minItems: 1 - maxItems: 2 items: - const: sierra_reset - const: sierra_apb diff --git a/Documentation/devicetree/bindings/phy/phy-cadence-torrent.yaml b/Documentation/devicetree/bindings/phy/phy-cadence-torrent.yaml index 01dcd14e7b2a..a28cf544696c 100644 --- a/Documentation/devicetree/bindings/phy/phy-cadence-torrent.yaml +++ b/Documentation/devicetree/bindings/phy/phy-cadence-torrent.yaml @@ -52,28 +52,24 @@ properties: reg: minItems: 1 - maxItems: 2 items: - description: Offset of the Torrent PHY configuration registers. - description: Offset of the DPTX PHY configuration registers. reg-names: minItems: 1 - maxItems: 2 items: - const: torrent_phy - const: dptx_phy resets: minItems: 1 - maxItems: 2 items: - description: Torrent PHY reset. - description: Torrent APB reset. This is optional. reset-names: minItems: 1 - maxItems: 2 items: - const: torrent_reset - const: torrent_apb diff --git a/Documentation/devicetree/bindings/phy/qcom,ipq806x-usb-phy-hs.yaml b/Documentation/devicetree/bindings/phy/qcom,ipq806x-usb-phy-hs.yaml index 17f132ce5516..35296c588e78 100644 --- a/Documentation/devicetree/bindings/phy/qcom,ipq806x-usb-phy-hs.yaml +++ b/Documentation/devicetree/bindings/phy/qcom,ipq806x-usb-phy-hs.yaml @@ -30,7 +30,6 @@ properties: clock-names: minItems: 1 - maxItems: 2 items: - const: ref - const: xo diff --git a/Documentation/devicetree/bindings/phy/qcom,ipq806x-usb-phy-ss.yaml b/Documentation/devicetree/bindings/phy/qcom,ipq806x-usb-phy-ss.yaml index 17fd7f6b83bb..6cf5c6c06072 100644 --- a/Documentation/devicetree/bindings/phy/qcom,ipq806x-usb-phy-ss.yaml +++ b/Documentation/devicetree/bindings/phy/qcom,ipq806x-usb-phy-ss.yaml @@ -30,7 +30,6 @@ properties: clock-names: minItems: 1 - maxItems: 2 items: - const: ref - const: xo diff --git a/Documentation/devicetree/bindings/phy/qcom,qmp-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,qmp-phy.yaml index 7808ec8bc712..a2de5202eb5e 100644 --- a/Documentation/devicetree/bindings/phy/qcom,qmp-phy.yaml +++ b/Documentation/devicetree/bindings/phy/qcom,qmp-phy.yaml @@ -49,7 +49,6 @@ properties: reg: minItems: 1 - maxItems: 2 items: - description: Address and length of PHY's common serdes block. - description: Address and length of PHY's DP_COM control block. diff --git a/Documentation/devicetree/bindings/phy/qcom,qusb2-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,qusb2-phy.yaml index 9f9cf07b7d45..930da598c969 100644 --- a/Documentation/devicetree/bindings/phy/qcom,qusb2-phy.yaml +++ b/Documentation/devicetree/bindings/phy/qcom,qusb2-phy.yaml @@ -36,7 +36,6 @@ properties: clocks: minItems: 2 - maxItems: 3 items: - description: phy config clock - description: 19.2 MHz ref clk @@ -44,7 +43,6 @@ properties: clock-names: minItems: 2 - maxItems: 3 items: - const: cfg_ahb - const: ref diff --git a/Documentation/devicetree/bindings/phy/renesas,usb2-phy.yaml b/Documentation/devicetree/bindings/phy/renesas,usb2-phy.yaml index 0f358d5b84ef..d5dc5a3cdceb 100644 --- a/Documentation/devicetree/bindings/phy/renesas,usb2-phy.yaml +++ b/Documentation/devicetree/bindings/phy/renesas,usb2-phy.yaml @@ -39,7 +39,6 @@ properties: clock-names: minItems: 1 - maxItems: 2 items: - const: fck - const: usb_x1 @@ -61,7 +60,6 @@ properties: resets: minItems: 1 - maxItems: 2 items: - description: reset of USB 2.0 host side - description: reset of USB 2.0 peripheral side diff --git a/Documentation/devicetree/bindings/phy/renesas,usb3-phy.yaml b/Documentation/devicetree/bindings/phy/renesas,usb3-phy.yaml index f3ef738a3ff6..b8483f9edbfc 100644 --- a/Documentation/devicetree/bindings/phy/renesas,usb3-phy.yaml +++ b/Documentation/devicetree/bindings/phy/renesas,usb3-phy.yaml @@ -33,7 +33,6 @@ properties: # If you want to use the ssc, the clock-frequency of usb_extal # must not be 0. minItems: 2 - maxItems: 3 items: - const: usb3-if # The funcional clock - const: usb3s_clk # The usb3's external clock diff --git a/Documentation/devicetree/bindings/pinctrl/actions,s500-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/actions,s500-pinctrl.yaml index ccdd9e3820d7..3f94f6944740 100644 --- a/Documentation/devicetree/bindings/pinctrl/actions,s500-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/actions,s500-pinctrl.yaml @@ -26,7 +26,6 @@ properties: - description: PAD Pull Control + PAD Schmitt Trigger Enable + PAD Control - description: PAD Drive Capacity Select minItems: 1 - maxItems: 4 clocks: maxItems: 1 diff --git a/Documentation/devicetree/bindings/power/amlogic,meson-ee-pwrc.yaml b/Documentation/devicetree/bindings/power/amlogic,meson-ee-pwrc.yaml index d30f85cc395e..f005abac7079 100644 --- a/Documentation/devicetree/bindings/power/amlogic,meson-ee-pwrc.yaml +++ b/Documentation/devicetree/bindings/power/amlogic,meson-ee-pwrc.yaml @@ -37,7 +37,6 @@ properties: clock-names: minItems: 1 - maxItems: 2 items: - const: vpu - const: vapb diff --git a/Documentation/devicetree/bindings/pwm/allwinner,sun4i-a10-pwm.yaml b/Documentation/devicetree/bindings/pwm/allwinner,sun4i-a10-pwm.yaml index 7dcab2bf8128..54a7700df08f 100644 --- a/Documentation/devicetree/bindings/pwm/allwinner,sun4i-a10-pwm.yaml +++ b/Documentation/devicetree/bindings/pwm/allwinner,sun4i-a10-pwm.yaml @@ -37,7 +37,6 @@ properties: clocks: minItems: 1 - maxItems: 2 items: - description: Module Clock - description: Bus Clock diff --git a/Documentation/devicetree/bindings/remoteproc/st,stm32-rproc.yaml b/Documentation/devicetree/bindings/remoteproc/st,stm32-rproc.yaml index 64afdcfb613d..1e6225677e00 100644 --- a/Documentation/devicetree/bindings/remoteproc/st,stm32-rproc.yaml +++ b/Documentation/devicetree/bindings/remoteproc/st,stm32-rproc.yaml @@ -72,7 +72,6 @@ properties: - from local to remote, where ACK from the remote means that communnication as been stopped on the remote side. minItems: 1 - maxItems: 4 mbox-names: items: @@ -81,7 +80,6 @@ properties: - const: shutdown - const: detach minItems: 1 - maxItems: 4 memory-region: description: diff --git a/Documentation/devicetree/bindings/remoteproc/ti,omap-remoteproc.yaml b/Documentation/devicetree/bindings/remoteproc/ti,omap-remoteproc.yaml index 0ef0bc498357..c6c12129d6b7 100644 --- a/Documentation/devicetree/bindings/remoteproc/ti,omap-remoteproc.yaml +++ b/Documentation/devicetree/bindings/remoteproc/ti,omap-remoteproc.yaml @@ -116,7 +116,6 @@ properties: list, in the specified order, each representing the corresponding internal RAM memory region. minItems: 1 - maxItems: 3 items: - const: l2ram - const: l1pram diff --git a/Documentation/devicetree/bindings/reset/fsl,imx-src.yaml b/Documentation/devicetree/bindings/reset/fsl,imx-src.yaml index 27c5e34a3ac6..b11ac533f914 100644 --- a/Documentation/devicetree/bindings/reset/fsl,imx-src.yaml +++ b/Documentation/devicetree/bindings/reset/fsl,imx-src.yaml @@ -59,7 +59,6 @@ properties: - description: SRC interrupt - description: CPU WDOG interrupts out of SRC minItems: 1 - maxItems: 2 '#reset-cells': const: 1 diff --git a/Documentation/devicetree/bindings/riscv/sifive-l2-cache.yaml b/Documentation/devicetree/bindings/riscv/sifive-l2-cache.yaml index 23b227614366..1d38ff76d18f 100644 --- a/Documentation/devicetree/bindings/riscv/sifive-l2-cache.yaml +++ b/Documentation/devicetree/bindings/riscv/sifive-l2-cache.yaml @@ -56,7 +56,6 @@ properties: interrupts: minItems: 3 - maxItems: 4 items: - description: DirError interrupt - description: DataError interrupt diff --git a/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml b/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml index b1b0ee769b71..beeb90e55727 100644 --- a/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml +++ b/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml @@ -32,7 +32,6 @@ properties: interrupts: minItems: 1 - maxItems: 2 items: - description: RTC Alarm 0 - description: RTC Alarm 1 diff --git a/Documentation/devicetree/bindings/rtc/imxdi-rtc.yaml b/Documentation/devicetree/bindings/rtc/imxdi-rtc.yaml index 06bd737821c1..4807c95a663c 100644 --- a/Documentation/devicetree/bindings/rtc/imxdi-rtc.yaml +++ b/Documentation/devicetree/bindings/rtc/imxdi-rtc.yaml @@ -21,7 +21,6 @@ properties: - description: rtc alarm interrupt - description: dryice security violation interrupt minItems: 1 - maxItems: 2 clocks: maxItems: 1 diff --git a/Documentation/devicetree/bindings/serial/fsl-lpuart.yaml b/Documentation/devicetree/bindings/serial/fsl-lpuart.yaml index bd21060d26e0..a90c971b4f1f 100644 --- a/Documentation/devicetree/bindings/serial/fsl-lpuart.yaml +++ b/Documentation/devicetree/bindings/serial/fsl-lpuart.yaml @@ -36,14 +36,12 @@ properties: - description: ipg clock - description: baud clock minItems: 1 - maxItems: 2 clock-names: items: - const: ipg - const: baud minItems: 1 - maxItems: 2 dmas: items: diff --git a/Documentation/devicetree/bindings/serial/samsung_uart.yaml b/Documentation/devicetree/bindings/serial/samsung_uart.yaml index 97ec8a093bf3..3ec3822bd114 100644 --- a/Documentation/devicetree/bindings/serial/samsung_uart.yaml +++ b/Documentation/devicetree/bindings/serial/samsung_uart.yaml @@ -44,7 +44,6 @@ properties: clock-names: description: N = 0 is allowed for SoCs without internal baud clock mux. minItems: 2 - maxItems: 5 items: - const: uart - pattern: '^clk_uart_baud[0-3]$' diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.yaml index 84671950ca0d..4663c2bcad50 100644 --- a/Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.yaml +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.yaml @@ -164,7 +164,6 @@ patternProperties: interrupts: minItems: 1 - maxItems: 2 items: - description: UART core irq - description: Wakeup irq (RX GPIO) diff --git a/Documentation/devicetree/bindings/soc/ti/ti,pruss.yaml b/Documentation/devicetree/bindings/soc/ti/ti,pruss.yaml index dbc62821c60b..9790617af1bc 100644 --- a/Documentation/devicetree/bindings/soc/ti/ti,pruss.yaml +++ b/Documentation/devicetree/bindings/soc/ti/ti,pruss.yaml @@ -100,7 +100,6 @@ patternProperties: properties: reg: minItems: 2 # On AM437x one of two PRUSS units don't contain Shared RAM. - maxItems: 3 items: - description: Address and size of the Data RAM0. - description: Address and size of the Data RAM1. @@ -111,7 +110,6 @@ patternProperties: reg-names: minItems: 2 - maxItems: 3 items: - const: dram0 - const: dram1 diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-graph-card.yaml b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-graph-card.yaml index 249970952202..5bdd30a8a404 100644 --- a/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-graph-card.yaml +++ b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-graph-card.yaml @@ -28,7 +28,6 @@ properties: minItems: 2 clock-names: - minItems: 2 items: - const: pll_a - const: plla_out0 diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra210-i2s.yaml b/Documentation/devicetree/bindings/sound/nvidia,tegra210-i2s.yaml index 38e52e7dbb40..63370709c768 100644 --- a/Documentation/devicetree/bindings/sound/nvidia,tegra210-i2s.yaml +++ b/Documentation/devicetree/bindings/sound/nvidia,tegra210-i2s.yaml @@ -34,7 +34,6 @@ properties: clocks: minItems: 1 - maxItems: 2 items: - description: I2S bit clock - description: @@ -48,7 +47,6 @@ properties: clock-names: minItems: 1 - maxItems: 2 items: - const: i2s - const: sync_input diff --git a/Documentation/devicetree/bindings/sound/st,stm32-sai.yaml b/Documentation/devicetree/bindings/sound/st,stm32-sai.yaml index f2443b651282..06e83461705c 100644 --- a/Documentation/devicetree/bindings/sound/st,stm32-sai.yaml +++ b/Documentation/devicetree/bindings/sound/st,stm32-sai.yaml @@ -26,7 +26,6 @@ properties: - description: Base address and size of SAI common register set. - description: Base address and size of SAI identification register set. minItems: 1 - maxItems: 2 ranges: maxItems: 1 @@ -81,14 +80,12 @@ patternProperties: - description: sai_ck clock feeding the internal clock generator. - description: MCLK clock from a SAI set as master clock provider. minItems: 1 - maxItems: 2 clock-names: items: - const: sai_ck - const: MCLK minItems: 1 - maxItems: 2 dmas: maxItems: 1 diff --git a/Documentation/devicetree/bindings/spi/amlogic,meson-gx-spicc.yaml b/Documentation/devicetree/bindings/spi/amlogic,meson-gx-spicc.yaml index e3fb553d9180..4d46c49ec32b 100644 --- a/Documentation/devicetree/bindings/spi/amlogic,meson-gx-spicc.yaml +++ b/Documentation/devicetree/bindings/spi/amlogic,meson-gx-spicc.yaml @@ -35,7 +35,6 @@ properties: clocks: minItems: 1 - maxItems: 2 items: - description: controller register bus clock - description: baud rate generator and delay control clock diff --git a/Documentation/devicetree/bindings/spi/brcm,spi-bcm-qspi.yaml b/Documentation/devicetree/bindings/spi/brcm,spi-bcm-qspi.yaml index 6ee19d49fd3c..ec5873919170 100644 --- a/Documentation/devicetree/bindings/spi/brcm,spi-bcm-qspi.yaml +++ b/Documentation/devicetree/bindings/spi/brcm,spi-bcm-qspi.yaml @@ -56,7 +56,6 @@ properties: reg-names: minItems: 1 - maxItems: 5 items: - const: mspi - const: bspi @@ -71,7 +70,6 @@ properties: interrupt-names: oneOf: - minItems: 1 - maxItems: 7 items: - const: mspi_done - const: mspi_halted diff --git a/Documentation/devicetree/bindings/thermal/allwinner,sun8i-a83t-ths.yaml b/Documentation/devicetree/bindings/thermal/allwinner,sun8i-a83t-ths.yaml index bf97d1fb33e7..6e0b110153b0 100644 --- a/Documentation/devicetree/bindings/thermal/allwinner,sun8i-a83t-ths.yaml +++ b/Documentation/devicetree/bindings/thermal/allwinner,sun8i-a83t-ths.yaml @@ -23,14 +23,12 @@ properties: clocks: minItems: 1 - maxItems: 2 items: - description: Bus Clock - description: Module Clock clock-names: minItems: 1 - maxItems: 2 items: - const: bus - const: mod diff --git a/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml b/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml index 0242fd91b622..0b3b6af7bd5b 100644 --- a/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml +++ b/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml @@ -77,7 +77,6 @@ properties: nvmem-cell-names: minItems: 1 - maxItems: 2 items: - const: calib - enum: diff --git a/Documentation/devicetree/bindings/timer/allwinner,sun5i-a13-hstimer.yaml b/Documentation/devicetree/bindings/timer/allwinner,sun5i-a13-hstimer.yaml index b6a6d03a08b2..2ecac754e1cd 100644 --- a/Documentation/devicetree/bindings/timer/allwinner,sun5i-a13-hstimer.yaml +++ b/Documentation/devicetree/bindings/timer/allwinner,sun5i-a13-hstimer.yaml @@ -24,7 +24,6 @@ properties: interrupts: minItems: 2 - maxItems: 4 items: - description: Timer 0 Interrupt - description: Timer 1 Interrupt diff --git a/Documentation/devicetree/bindings/timer/arm,arch_timer.yaml b/Documentation/devicetree/bindings/timer/arm,arch_timer.yaml index 7f5e3af58255..df8ce87fd54b 100644 --- a/Documentation/devicetree/bindings/timer/arm,arch_timer.yaml +++ b/Documentation/devicetree/bindings/timer/arm,arch_timer.yaml @@ -35,7 +35,6 @@ properties: interrupts: minItems: 1 - maxItems: 5 items: - description: secure timer irq - description: non-secure timer irq diff --git a/Documentation/devicetree/bindings/timer/arm,arch_timer_mmio.yaml b/Documentation/devicetree/bindings/timer/arm,arch_timer_mmio.yaml index d83a1f97f911..cd2176cad53a 100644 --- a/Documentation/devicetree/bindings/timer/arm,arch_timer_mmio.yaml +++ b/Documentation/devicetree/bindings/timer/arm,arch_timer_mmio.yaml @@ -71,14 +71,12 @@ patternProperties: interrupts: minItems: 1 - maxItems: 2 items: - description: physical timer irq - description: virtual timer irq reg: minItems: 1 - maxItems: 2 items: - description: 1st view base address - description: 2nd optional view base address diff --git a/Documentation/devicetree/bindings/timer/intel,ixp4xx-timer.yaml b/Documentation/devicetree/bindings/timer/intel,ixp4xx-timer.yaml index a8de99b0c0f9..f32575d4b5aa 100644 --- a/Documentation/devicetree/bindings/timer/intel,ixp4xx-timer.yaml +++ b/Documentation/devicetree/bindings/timer/intel,ixp4xx-timer.yaml @@ -22,7 +22,6 @@ properties: interrupts: minItems: 1 - maxItems: 2 items: - description: Timer 1 interrupt - description: Timer 2 interrupt diff --git a/Documentation/devicetree/bindings/usb/maxim,max3420-udc.yaml b/Documentation/devicetree/bindings/usb/maxim,max3420-udc.yaml index 4241d38d5864..1d893d3d3432 100644 --- a/Documentation/devicetree/bindings/usb/maxim,max3420-udc.yaml +++ b/Documentation/devicetree/bindings/usb/maxim,max3420-udc.yaml @@ -30,14 +30,12 @@ properties: - description: usb irq from max3420 - description: vbus detection irq minItems: 1 - maxItems: 2 interrupt-names: items: - const: udc - const: vbus minItems: 1 - maxItems: 2 spi-max-frequency: maximum: 26000000 diff --git a/Documentation/devicetree/bindings/usb/nvidia,tegra-xudc.yaml b/Documentation/devicetree/bindings/usb/nvidia,tegra-xudc.yaml index e60e590dbe12..8428415896ce 100644 --- a/Documentation/devicetree/bindings/usb/nvidia,tegra-xudc.yaml +++ b/Documentation/devicetree/bindings/usb/nvidia,tegra-xudc.yaml @@ -25,7 +25,6 @@ properties: reg: minItems: 2 - maxItems: 3 items: - description: XUSB device controller registers - description: XUSB device PCI Config registers @@ -33,7 +32,6 @@ properties: reg-names: minItems: 2 - maxItems: 3 items: - const: base - const: fpci @@ -45,7 +43,6 @@ properties: clocks: minItems: 4 - maxItems: 5 items: - description: Clock to enable core XUSB dev clock. - description: Clock to enable XUSB super speed clock. @@ -55,7 +52,6 @@ properties: clock-names: minItems: 4 - maxItems: 5 items: - const: dev - const: ss diff --git a/Documentation/devicetree/bindings/usb/renesas,usbhs.yaml b/Documentation/devicetree/bindings/usb/renesas,usbhs.yaml index e67223d90bb7..ad73339ffe1d 100644 --- a/Documentation/devicetree/bindings/usb/renesas,usbhs.yaml +++ b/Documentation/devicetree/bindings/usb/renesas,usbhs.yaml @@ -53,7 +53,6 @@ properties: clocks: minItems: 1 - maxItems: 3 items: - description: USB 2.0 host - description: USB 2.0 peripheral @@ -86,7 +85,6 @@ properties: dma-names: minItems: 2 - maxItems: 4 items: - const: ch0 - const: ch1 @@ -100,7 +98,6 @@ properties: resets: minItems: 1 - maxItems: 2 items: - description: USB 2.0 host - description: USB 2.0 peripheral diff --git a/Documentation/devicetree/bindings/watchdog/st,stm32-iwdg.yaml b/Documentation/devicetree/bindings/watchdog/st,stm32-iwdg.yaml index 3f1ba1d6c6b5..481bf91f988a 100644 --- a/Documentation/devicetree/bindings/watchdog/st,stm32-iwdg.yaml +++ b/Documentation/devicetree/bindings/watchdog/st,stm32-iwdg.yaml @@ -27,7 +27,6 @@ properties: - description: Low speed clock - description: Optional peripheral clock minItems: 1 - maxItems: 2 clock-names: items: -- cgit v1.2.3 From 556910e39249d55e23deaec479f49e7d85bc0d24 Mon Sep 17 00:00:00 2001 From: Bart Van Assche Date: Thu, 17 Jun 2021 17:44:44 -0700 Subject: block: Introduce the ioprio rq-qos policy Introduce an rq-qos policy that assigns an I/O priority to requests based on blk-cgroup configuration settings. This policy has the following advantages over the ioprio_set() system call: - This policy is cgroup based so it has all the advantages of cgroups. - While ioprio_set() does not affect page cache writeback I/O, this rq-qos controller affects page cache writeback I/O for filesystems that support assiociating a cgroup with writeback I/O. See also Documentation/admin-guide/cgroup-v2.rst. Cc: Damien Le Moal Cc: Hannes Reinecke Cc: Christoph Hellwig Cc: Ming Lei Cc: Johannes Thumshirn Cc: Himanshu Madhani Signed-off-by: Bart Van Assche Link: https://lore.kernel.org/r/20210618004456.7280-5-bvanassche@acm.org Signed-off-by: Jens Axboe --- Documentation/admin-guide/cgroup-v2.rst | 55 +++++++++++++++++++++++++++++++++ 1 file changed, 55 insertions(+) (limited to 'Documentation') diff --git a/Documentation/admin-guide/cgroup-v2.rst b/Documentation/admin-guide/cgroup-v2.rst index b1e81aa8598a..4e59925e6583 100644 --- a/Documentation/admin-guide/cgroup-v2.rst +++ b/Documentation/admin-guide/cgroup-v2.rst @@ -56,6 +56,7 @@ v1 is available under :ref:`Documentation/admin-guide/cgroup-v1/index.rst Date: Thu, 17 Jun 2021 16:22:14 +0200 Subject: vfio/mdev: Remove CONFIG_VFIO_MDEV_DEVICE For some reason the vfio_mdev shim mdev_driver has its own module and kconfig. As the next patch requires access to it from mdev.ko merge the two modules together and remove VFIO_MDEV_DEVICE. A later patch deletes this driver entirely. Signed-off-by: Jason Gunthorpe Signed-off-by: Christoph Hellwig Reviewed-by: Cornelia Huck Reviewed-by: Greg Kroah-Hartman Reviewed-by: Kirti Wankhede Link: https://lore.kernel.org/r/20210617142218.1877096-7-hch@lst.de Signed-off-by: Alex Williamson --- Documentation/s390/vfio-ap.rst | 1 - 1 file changed, 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/s390/vfio-ap.rst b/Documentation/s390/vfio-ap.rst index e15436599086..f57ae621f33e 100644 --- a/Documentation/s390/vfio-ap.rst +++ b/Documentation/s390/vfio-ap.rst @@ -514,7 +514,6 @@ These are the steps: * S390_AP_IOMMU * VFIO * VFIO_MDEV - * VFIO_MDEV_DEVICE * KVM If using make menuconfig select the following to build the vfio_ap module:: -- cgit v1.2.3 From 88a21f265ce50a17e6e71e3fb4467625cf234c5a Mon Sep 17 00:00:00 2001 From: Jason Gunthorpe Date: Thu, 17 Jun 2021 16:22:15 +0200 Subject: vfio/mdev: Allow the mdev_parent_ops to specify the device driver to bind This allows a mdev driver to opt out of using vfio_mdev.c, instead the driver will provide a 'struct mdev_driver' and register directly with the driver core. Much of mdev_parent_ops becomes unused in this mode: - create()/remove() are done via the mdev_driver probe()/remove() - mdev_attr_groups becomes mdev_driver driver.dev_groups - Wrapper function callbacks are replaced with the same ones from struct vfio_device_ops Signed-off-by: Jason Gunthorpe Signed-off-by: Christoph Hellwig Reviewed-by: Cornelia Huck Reviewed-by: Greg Kroah-Hartman Reviewed-by: Kirti Wankhede Link: https://lore.kernel.org/r/20210617142218.1877096-8-hch@lst.de Signed-off-by: Alex Williamson --- Documentation/driver-api/vfio-mediated-device.rst | 35 ++++++++--------------- 1 file changed, 12 insertions(+), 23 deletions(-) (limited to 'Documentation') diff --git a/Documentation/driver-api/vfio-mediated-device.rst b/Documentation/driver-api/vfio-mediated-device.rst index 1779b85f014e..9f26079cacae 100644 --- a/Documentation/driver-api/vfio-mediated-device.rst +++ b/Documentation/driver-api/vfio-mediated-device.rst @@ -93,7 +93,7 @@ interfaces: Registration Interface for a Mediated Bus Driver ------------------------------------------------ -The registration interface for a mediated bus driver provides the following +The registration interface for a mediated device driver provides the following structure to represent a mediated device's driver:: /* @@ -136,37 +136,26 @@ The structures in the mdev_parent_ops structure are as follows: * dev_attr_groups: attributes of the parent device * mdev_attr_groups: attributes of the mediated device * supported_config: attributes to define supported configurations +* device_driver: device driver to bind for mediated device instances -The functions in the mdev_parent_ops structure are as follows: +The mdev_parent_ops also still has various functions pointers. Theses exist +for historical reasons only and shall not be used for new drivers. -* create: allocate basic resources in a driver for a mediated device -* remove: free resources in a driver when a mediated device is destroyed - -(Note that mdev-core provides no implicit serialization of create/remove -callbacks per mdev parent device, per mdev type, or any other categorization. -Vendor drivers are expected to be fully asynchronous in this respect or -provide their own internal resource protection.) - -The callbacks in the mdev_parent_ops structure are as follows: - -* open: open callback of mediated device -* close: close callback of mediated device -* ioctl: ioctl callback of mediated device -* read : read emulation callback -* write: write emulation callback -* mmap: mmap emulation callback - -A driver should use the mdev_parent_ops structure in the function call to -register itself with the mdev core driver:: +When a driver wants to add the GUID creation sysfs to an existing device it has +probe'd to then it should call:: extern int mdev_register_device(struct device *dev, const struct mdev_parent_ops *ops); -However, the mdev_parent_ops structure is not required in the function call -that a driver should use to unregister itself with the mdev core driver:: +This will provide the 'mdev_supported_types/XX/create' files which can then be +used to trigger the creation of a mdev_device. The created mdev_device will be +attached to the specified driver. + +When the driver needs to remove itself it calls:: extern void mdev_unregister_device(struct device *dev); +Which will unbind and destroy all the created mdevs and remove the sysfs files. Mediated Device Management Interface Through sysfs ================================================== -- cgit v1.2.3 From 19e068b18e729aecca4fbe5b261b05b59230c80f Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=E5=91=A8=E7=90=B0=E6=9D=B0=20=28Zhou=20Yanjie=29?= Date: Sun, 20 Jun 2021 20:38:49 +0800 Subject: dt-bindings: dwmac: Remove unexpected item. MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Remove the unexpected "snps,dwmac" item in the example. Fixes: 3b8401066e5a ("dt-bindings: dwmac: Add bindings for new Ingenic SoCs.") Signed-off-by: 周琰杰 (Zhou Yanjie) Signed-off-by: David S. Miller --- Documentation/devicetree/bindings/net/ingenic,mac.yaml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/ingenic,mac.yaml b/Documentation/devicetree/bindings/net/ingenic,mac.yaml index 5e93d4f9a080..d08a88125a5c 100644 --- a/Documentation/devicetree/bindings/net/ingenic,mac.yaml +++ b/Documentation/devicetree/bindings/net/ingenic,mac.yaml @@ -61,7 +61,7 @@ examples: #include mac: ethernet@134b0000 { - compatible = "ingenic,x1000-mac", "snps,dwmac"; + compatible = "ingenic,x1000-mac"; reg = <0x134b0000 0x2000>; interrupt-parent = <&intc>; -- cgit v1.2.3 From e880275ccfa120bf6235180ca76f01271b7b97ec Mon Sep 17 00:00:00 2001 From: Andrew Jeffery Date: Tue, 8 Jun 2021 20:17:53 +0930 Subject: dt-bindings: ipmi: Convert ASPEED KCS binding to schema Given the deprecated binding, improve the ability to detect issues in the platform devicetrees. Further, a subsequent patch will introduce a new interrupts property for specifying SerIRQ behaviour, so convert before we do any further additions. Signed-off-by: Andrew Jeffery Reviewed-by: Rob Herring Reviewed-by: Zev Weiss Message-Id: <20210608104757.582199-13-andrew@aj.id.au> Signed-off-by: Corey Minyard --- .../bindings/ipmi/aspeed,ast2400-kcs-bmc.yaml | 92 ++++++++++++++++++++++ .../devicetree/bindings/ipmi/aspeed-kcs-bmc.txt | 33 -------- 2 files changed, 92 insertions(+), 33 deletions(-) create mode 100644 Documentation/devicetree/bindings/ipmi/aspeed,ast2400-kcs-bmc.yaml delete mode 100644 Documentation/devicetree/bindings/ipmi/aspeed-kcs-bmc.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/ipmi/aspeed,ast2400-kcs-bmc.yaml b/Documentation/devicetree/bindings/ipmi/aspeed,ast2400-kcs-bmc.yaml new file mode 100644 index 000000000000..697ca575454f --- /dev/null +++ b/Documentation/devicetree/bindings/ipmi/aspeed,ast2400-kcs-bmc.yaml @@ -0,0 +1,92 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/ipmi/aspeed,ast2400-kcs-bmc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: ASPEED BMC KCS Devices + +maintainers: + - Andrew Jeffery + +description: | + The Aspeed BMC SoCs typically use the Keyboard-Controller-Style (KCS) + interfaces on the LPC bus for in-band IPMI communication with their host. + +properties: + compatible: + oneOf: + - description: Channel ID derived from reg + items: + enum: + - aspeed,ast2400-kcs-bmc-v2 + - aspeed,ast2500-kcs-bmc-v2 + - aspeed,ast2600-kcs-bmc + + - description: Old-style with explicit channel ID, no reg + deprecated: true + items: + enum: + - aspeed,ast2400-kcs-bmc + - aspeed,ast2500-kcs-bmc + + interrupts: + maxItems: 1 + + reg: + # maxItems: 3 + items: + - description: IDR register + - description: ODR register + - description: STR register + + aspeed,lpc-io-reg: + $ref: '/schemas/types.yaml#/definitions/uint32-array' + minItems: 1 + maxItems: 2 + description: | + The host CPU LPC IO data and status addresses for the device. For most + channels the status address is derived from the data address, but the + status address may be optionally provided. + + kcs_chan: + deprecated: true + $ref: '/schemas/types.yaml#/definitions/uint32' + description: The LPC channel number in the controller + + kcs_addr: + deprecated: true + $ref: '/schemas/types.yaml#/definitions/uint32' + description: The host CPU IO map address + +required: + - compatible + - interrupts + +additionalProperties: false + +allOf: + - if: + properties: + compatible: + contains: + enum: + - aspeed,ast2400-kcs-bmc + - aspeed,ast2500-kcs-bmc + then: + required: + - kcs_chan + - kcs_addr + else: + required: + - reg + - aspeed,lpc-io-reg + +examples: + - | + kcs3: kcs@24 { + compatible = "aspeed,ast2600-kcs-bmc"; + reg = <0x24 0x1>, <0x30 0x1>, <0x3c 0x1>; + aspeed,lpc-io-reg = <0xca2>; + interrupts = <8>; + }; diff --git a/Documentation/devicetree/bindings/ipmi/aspeed-kcs-bmc.txt b/Documentation/devicetree/bindings/ipmi/aspeed-kcs-bmc.txt deleted file mode 100644 index 193e71ca96b0..000000000000 --- a/Documentation/devicetree/bindings/ipmi/aspeed-kcs-bmc.txt +++ /dev/null @@ -1,33 +0,0 @@ -# Aspeed KCS (Keyboard Controller Style) IPMI interface - -The Aspeed SOCs (AST2400 and AST2500) are commonly used as BMCs -(Baseboard Management Controllers) and the KCS interface can be -used to perform in-band IPMI communication with their host. - -## v1 -Required properties: -- compatible : should be one of - "aspeed,ast2400-kcs-bmc" - "aspeed,ast2500-kcs-bmc" -- interrupts : interrupt generated by the controller -- kcs_chan : The LPC channel number in the controller -- kcs_addr : The host CPU IO map address - -## v2 -Required properties: -- compatible : should be one of - "aspeed,ast2400-kcs-bmc-v2" - "aspeed,ast2500-kcs-bmc-v2" -- reg : The address and size of the IDR, ODR and STR registers -- interrupts : interrupt generated by the controller -- aspeed,lpc-io-reg : The host CPU LPC IO address for the device - -Example: - - kcs3: kcs@24 { - compatible = "aspeed,ast2500-kcs-bmc-v2"; - reg = <0x24 0x1>, <0x30 0x1>, <0x3c 0x1>; - aspeed,lpc-reg = <0xca2>; - interrupts = <8>; - status = "okay"; - }; -- cgit v1.2.3 From a7fd43d95054fe03cac3878538dcf12caa854889 Mon Sep 17 00:00:00 2001 From: Andrew Jeffery Date: Tue, 8 Jun 2021 20:17:54 +0930 Subject: dt-bindings: ipmi: Add optional SerIRQ property to ASPEED KCS devices Allocating IO and IRQ resources to LPC devices is in-theory an operation for the host, however ASPEED don't appear to expose this capability outside the BMC (e.g. SuperIO). Instead, we are left with BMC-internal registers for managing these resources, so introduce a devicetree property for KCS devices to describe SerIRQ properties. Signed-off-by: Andrew Jeffery Reviewed-by: Rob Herring Message-Id: <20210608104757.582199-14-andrew@aj.id.au> Signed-off-by: Corey Minyard --- .../devicetree/bindings/ipmi/aspeed,ast2400-kcs-bmc.yaml | 14 ++++++++++++++ 1 file changed, 14 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/ipmi/aspeed,ast2400-kcs-bmc.yaml b/Documentation/devicetree/bindings/ipmi/aspeed,ast2400-kcs-bmc.yaml index 697ca575454f..4ff6fabfcb30 100644 --- a/Documentation/devicetree/bindings/ipmi/aspeed,ast2400-kcs-bmc.yaml +++ b/Documentation/devicetree/bindings/ipmi/aspeed,ast2400-kcs-bmc.yaml @@ -49,6 +49,18 @@ properties: channels the status address is derived from the data address, but the status address may be optionally provided. + aspeed,lpc-interrupts: + $ref: "/schemas/types.yaml#/definitions/uint32-array" + minItems: 2 + maxItems: 2 + description: | + A 2-cell property expressing the LPC SerIRQ number and the interrupt + level/sense encoding (specified in the standard fashion). + + Note that the generated interrupt is issued from the BMC to the host, and + thus the target interrupt controller is not captured by the BMC's + devicetree. + kcs_chan: deprecated: true $ref: '/schemas/types.yaml#/definitions/uint32' @@ -84,9 +96,11 @@ allOf: examples: - | + #include kcs3: kcs@24 { compatible = "aspeed,ast2600-kcs-bmc"; reg = <0x24 0x1>, <0x30 0x1>, <0x3c 0x1>; aspeed,lpc-io-reg = <0xca2>; + aspeed,lpc-interrupts = <11 IRQ_TYPE_LEVEL_LOW>; interrupts = <8>; }; -- cgit v1.2.3 From 01610a24cefa182b155a17e38cd0b84f8a3f0529 Mon Sep 17 00:00:00 2001 From: Liang Chen Date: Tue, 22 Jun 2021 10:05:17 +0800 Subject: arm64: dts: rockchip: add basic dts for RK3568 EVB This patch add rk3568-evb1-v10.dts for RK3568 evaluation board. add uart/emmc/i2c/rk809 node for basic function. Signed-off-by: Liang Chen Link: https://lore.kernel.org/r/20210622020517.13100-5-cl@rock-chips.com Signed-off-by: Heiko Stuebner --- Documentation/devicetree/bindings/arm/rockchip.yaml | 5 +++++ 1 file changed, 5 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/rockchip.yaml b/Documentation/devicetree/bindings/arm/rockchip.yaml index 4a6f772c1043..6546b015fc62 100644 --- a/Documentation/devicetree/bindings/arm/rockchip.yaml +++ b/Documentation/devicetree/bindings/arm/rockchip.yaml @@ -600,6 +600,11 @@ properties: - const: zkmagic,a95x-z2 - const: rockchip,rk3318 + - description: Rockchip RK3568 Evaluation board + items: + - const: rockchip,rk3568-evb1-v10 + - const: rockchip,rk3568 + additionalProperties: true ... -- cgit v1.2.3 From d90609a4b72dbfe42da2a55f3078c35e669948e0 Mon Sep 17 00:00:00 2001 From: Sebastian Reichel Date: Mon, 21 Jun 2021 19:53:56 +0200 Subject: spi: dt-bindings: support devices with multiple chipselects Add binding support for devices, that have more than one chip select. A typical example are SPI connected microcontroller, that can also be programmed over SPI like NXP Kinetis or chips with a configuration and a data chip select, such as Microchip's MRF89XA transceiver. Reviewed-by: Rob Herring Signed-off-by: Sebastian Reichel Link: https://lore.kernel.org/r/20210621175359.126729-3-sebastian.reichel@collabora.com Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/spi/spi-controller.yaml | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/spi/spi-controller.yaml b/Documentation/devicetree/bindings/spi/spi-controller.yaml index 0477396e4945..faef4f6f55b8 100644 --- a/Documentation/devicetree/bindings/spi/spi-controller.yaml +++ b/Documentation/devicetree/bindings/spi/spi-controller.yaml @@ -114,8 +114,11 @@ patternProperties: Compatible of the SPI device. reg: - minimum: 0 - maximum: 256 + minItems: 1 + maxItems: 256 + items: + minimum: 0 + maximum: 256 description: Chip select used by the device. -- cgit v1.2.3 From 04c02c201d7e8149ae336ead69fb64e4e6f94bc9 Mon Sep 17 00:00:00 2001 From: Steven Price Date: Mon, 21 Jun 2021 12:17:16 +0100 Subject: KVM: arm64: Document MTE capability and ioctl A new capability (KVM_CAP_ARM_MTE) identifies that the kernel supports granting a guest access to the tags, and provides a mechanism for the VMM to enable it. A new ioctl (KVM_ARM_MTE_COPY_TAGS) provides a simple way for a VMM to access the tags of a guest without having to maintain a PROT_MTE mapping in userspace. The above capability gates access to the ioctl. Reviewed-by: Catalin Marinas Signed-off-by: Steven Price Signed-off-by: Marc Zyngier Link: https://lore.kernel.org/r/20210621111716.37157-7-steven.price@arm.com --- Documentation/virt/kvm/api.rst | 61 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 61 insertions(+) (limited to 'Documentation') diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst index 7fcb2fd38f42..97661a97943f 100644 --- a/Documentation/virt/kvm/api.rst +++ b/Documentation/virt/kvm/api.rst @@ -5034,6 +5034,43 @@ see KVM_XEN_VCPU_SET_ATTR above. The KVM_XEN_VCPU_ATTR_TYPE_RUNSTATE_ADJUST type may not be used with the KVM_XEN_VCPU_GET_ATTR ioctl. +4.130 KVM_ARM_MTE_COPY_TAGS +--------------------------- + +:Capability: KVM_CAP_ARM_MTE +:Architectures: arm64 +:Type: vm ioctl +:Parameters: struct kvm_arm_copy_mte_tags +:Returns: number of bytes copied, < 0 on error (-EINVAL for incorrect + arguments, -EFAULT if memory cannot be accessed). + +:: + + struct kvm_arm_copy_mte_tags { + __u64 guest_ipa; + __u64 length; + void __user *addr; + __u64 flags; + __u64 reserved[2]; + }; + +Copies Memory Tagging Extension (MTE) tags to/from guest tag memory. The +``guest_ipa`` and ``length`` fields must be ``PAGE_SIZE`` aligned. The ``addr`` +field must point to a buffer which the tags will be copied to or from. + +``flags`` specifies the direction of copy, either ``KVM_ARM_TAGS_TO_GUEST`` or +``KVM_ARM_TAGS_FROM_GUEST``. + +The size of the buffer to store the tags is ``(length / 16)`` bytes +(granules in MTE are 16 bytes long). Each byte contains a single tag +value. This matches the format of ``PTRACE_PEEKMTETAGS`` and +``PTRACE_POKEMTETAGS``. + +If an error occurs before any data is copied then a negative error code is +returned. If some tags have been copied before an error occurs then the number +of bytes successfully copied is returned. If the call completes successfully +then ``length`` is returned. + 5. The kvm_run structure ======================== @@ -6362,6 +6399,30 @@ default. See Documentation/x86/sgx/2.Kernel-internals.rst for more details. +7.26 KVM_CAP_ARM_MTE +-------------------- + +:Architectures: arm64 +:Parameters: none + +This capability indicates that KVM (and the hardware) supports exposing the +Memory Tagging Extensions (MTE) to the guest. It must also be enabled by the +VMM before creating any VCPUs to allow the guest access. Note that MTE is only +available to a guest running in AArch64 mode and enabling this capability will +cause attempts to create AArch32 VCPUs to fail. + +When enabled the guest is able to access tags associated with any memory given +to the guest. KVM will ensure that the tags are maintained during swap or +hibernation of the host; however the VMM needs to manually save/restore the +tags as appropriate if the VM is migrated. + +When this capability is enabled all memory in memslots must be mapped as +not-shareable (no MAP_SHARED), attempts to create a memslot with a +MAP_SHARED mmap will result in an -EINVAL return. + +When enabled the VMM may make use of the ``KVM_ARM_MTE_COPY_TAGS`` ioctl to +perform a bulk copy of tags to/from the guest. + 8. Other capabilities. ====================== -- cgit v1.2.3 From b87cc116c7e1bc62a84d8c46acd401db179edb11 Mon Sep 17 00:00:00 2001 From: Bharata B Rao Date: Mon, 21 Jun 2021 14:20:02 +0530 Subject: KVM: PPC: Book3S HV: Add KVM_CAP_PPC_RPT_INVALIDATE capability Now that we have H_RPT_INVALIDATE fully implemented, enable support for the same via KVM_CAP_PPC_RPT_INVALIDATE KVM capability Signed-off-by: Bharata B Rao Reviewed-by: David Gibson Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20210621085003.904767-6-bharata@linux.ibm.com --- Documentation/virt/kvm/api.rst | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) (limited to 'Documentation') diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst index 7fcb2fd38f42..9977e845633f 100644 --- a/Documentation/virt/kvm/api.rst +++ b/Documentation/virt/kvm/api.rst @@ -6362,6 +6362,24 @@ default. See Documentation/x86/sgx/2.Kernel-internals.rst for more details. +7.26 KVM_CAP_PPC_RPT_INVALIDATE +------------------------------- + +:Capability: KVM_CAP_PPC_RPT_INVALIDATE +:Architectures: ppc +:Type: vm + +This capability indicates that the kernel is capable of handling +H_RPT_INVALIDATE hcall. + +In order to enable the use of H_RPT_INVALIDATE in the guest, +user space might have to advertise it for the guest. For example, +IBM pSeries (sPAPR) guest starts using it if "hcall-rpt-invalidate" is +present in the "ibm,hypertas-functions" device-tree property. + +This capability is enabled for hypervisors on platforms like POWER9 +that support radix MMU. + 8. Other capabilities. ====================== -- cgit v1.2.3 From db3a34e17433de2390eb80d436970edcebd0ca3e Mon Sep 17 00:00:00 2001 From: "Paul E. McKenney" Date: Thu, 27 May 2021 12:01:19 -0700 Subject: clocksource: Retry clock read if long delays detected When the clocksource watchdog marks a clock as unstable, this might be due to that clock being unstable or it might be due to delays that happen to occur between the reads of the two clocks. Yes, interrupts are disabled across those two reads, but there are no shortage of things that can delay interrupts-disabled regions of code ranging from SMI handlers to vCPU preemption. It would be good to have some indication as to why the clock was marked unstable. Therefore, re-read the watchdog clock on either side of the read from the clock under test. If the watchdog clock shows an excessive time delta between its pair of reads, the reads are retried. The maximum number of retries is specified by a new kernel boot parameter clocksource.max_cswd_read_retries, which defaults to three, that is, up to four reads, one initial and up to three retries. If more than one retry was required, a message is printed on the console (the occasional single retry is expected behavior, especially in guest OSes). If the maximum number of retries is exceeded, the clock under test will be marked unstable. However, the probability of this happening due to various sorts of delays is quite small. In addition, the reason (clock-read delays) for the unstable marking will be apparent. Reported-by: Chris Mason Signed-off-by: Paul E. McKenney Signed-off-by: Thomas Gleixner Acked-by: Feng Tang Link: https://lore.kernel.org/r/20210527190124.440372-1-paulmck@kernel.org --- 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 cb89dbdedc46..995deccc28bc 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -581,6 +581,12 @@ loops can be debugged more effectively on production systems. + clocksource.max_cswd_read_retries= [KNL] + Number of clocksource_watchdog() retries due to + external delays before the clock will be marked + unstable. Defaults to three retries, that is, + four attempts to read the clock under test. + clearcpuid=BITNUM[,BITNUM...] [X86] Disable CPUID feature X for the kernel. See arch/x86/include/asm/cpufeatures.h for the valid bit -- cgit v1.2.3 From fa218f1cce6ba40069c8daab8821de7e6be1cdd0 Mon Sep 17 00:00:00 2001 From: "Paul E. McKenney" Date: Thu, 27 May 2021 12:01:21 -0700 Subject: clocksource: Limit number of CPUs checked for clock synchronization Currently, if skew is detected on a clock marked CLOCK_SOURCE_VERIFY_PERCPU, that clock is checked on all CPUs. This is thorough, but might not be what you want on a system with a few tens of CPUs, let alone a few hundred of them. Therefore, by default check only up to eight randomly chosen CPUs. Also provide a new clocksource.verify_n_cpus kernel boot parameter. A value of -1 says to check all of the CPUs, and a non-negative value says to randomly select that number of CPUs, without concern about selecting the same CPU multiple times. However, make use of a cpumask so that a given CPU will be checked at most once. Suggested-by: Thomas Gleixner # For verify_n_cpus=1. Signed-off-by: Paul E. McKenney Signed-off-by: Thomas Gleixner Acked-by: Feng Tang Link: https://lore.kernel.org/r/20210527190124.440372-3-paulmck@kernel.org --- Documentation/admin-guide/kernel-parameters.txt | 10 ++++++++++ 1 file changed, 10 insertions(+) (limited to 'Documentation') diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index 995deccc28bc..9ec9ea1a51f2 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -587,6 +587,16 @@ unstable. Defaults to three retries, that is, four attempts to read the clock under test. + clocksource.verify_n_cpus= [KNL] + Limit the number of CPUs checked for clocksources + marked with CLOCK_SOURCE_VERIFY_PERCPU that + are marked unstable due to excessive skew. + A negative value says to check all CPUs, while + zero says not to check any. Values larger than + nr_cpu_ids are silently truncated to nr_cpu_ids. + The actual CPUs are chosen randomly, with + no replacement if the same CPU is chosen twice. + clearcpuid=BITNUM[,BITNUM...] [X86] Disable CPUID feature X for the kernel. See arch/x86/include/asm/cpufeatures.h for the valid bit -- cgit v1.2.3 From 1253b9b87e42ab6a3d5c2cb27af2bdd67d7e50ff Mon Sep 17 00:00:00 2001 From: "Paul E. McKenney" Date: Thu, 27 May 2021 12:01:23 -0700 Subject: clocksource: Provide kernel module to test clocksource watchdog When the clocksource watchdog marks a clock as unstable, this might be due to that clock being unstable or it might be due to delays that happen to occur between the reads of the two clocks. It would be good to have a way of testing the clocksource watchdog's ability to distinguish between these two causes of clock skew and instability. Therefore, provide a new clocksource-wdtest module selected by a new TEST_CLOCKSOURCE_WATCHDOG Kconfig option. This module has a single module parameter named "holdoff" that provides the number of seconds of delay before testing should start, which defaults to zero when built as a module and to 10 seconds when built directly into the kernel. Very large systems that boot slowly may need to increase the value of this module parameter. This module uses hand-crafted clocksource structures to do its testing, thus avoiding messing up timing for the rest of the kernel and for user applications. This module first verifies that the ->uncertainty_margin field of the clocksource structures are set sanely. It then tests the delay-detection capability of the clocksource watchdog, increasing the number of consecutive delays injected, first provoking console messages complaining about the delays and finally forcing a clock-skew event. Unexpected test results cause at least one WARN_ON_ONCE() console splat. If there are no splats, the test has passed. Finally, it fuzzes the value returned from a clocksource to test the clocksource watchdog's ability to detect time skew. This module checks the state of its clocksource after each test, and uses WARN_ON_ONCE() to emit a console splat if there are any failures. This should enable all types of test frameworks to detect any such failures. This facility is intended for diagnostic use only, and should be avoided on production systems. Reported-by: Chris Mason Suggested-by: Thomas Gleixner Signed-off-by: Paul E. McKenney Signed-off-by: Thomas Gleixner Tested-by: Feng Tang Link: https://lore.kernel.org/r/20210527190124.440372-5-paulmck@kernel.org --- 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 9ec9ea1a51f2..591048ed1365 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -597,6 +597,12 @@ The actual CPUs are chosen randomly, with no replacement if the same CPU is chosen twice. + clocksource-wdtest.holdoff= [KNL] + Set the time in seconds that the clocksource + watchdog test waits before commencing its tests. + Defaults to zero when built as a module and to + 10 seconds when built into the kernel. + clearcpuid=BITNUM[,BITNUM...] [X86] Disable CPUID feature X for the kernel. See arch/x86/include/asm/cpufeatures.h for the valid bit -- cgit v1.2.3 From 7c4d7ca8cce3c8167e10f52a5afb553851f2086b Mon Sep 17 00:00:00 2001 From: Marcin Wojtas Date: Mon, 21 Jun 2021 19:30:23 +0200 Subject: Documentation: ACPI: DSD: describe additional MAC configuration Document additional MAC configuration modes which can be processed by the existing fwnode_ phylink helpers: * "managed" standard ACPI _DSD property [1] * "fixed-link" data-only subnode linked in the _DSD package via generic mechanism of the hierarchical data extension [2] [1] https://www.uefi.org/sites/default/files/resources/_DSD-device-properties-UUID.pdf [2] https://github.com/UEFI/DSD-Guide/blob/main/dsd-guide.pdf Signed-off-by: Marcin Wojtas Signed-off-by: David S. Miller --- Documentation/firmware-guide/acpi/dsd/phy.rst | 59 +++++++++++++++++++++++++++ 1 file changed, 59 insertions(+) (limited to 'Documentation') diff --git a/Documentation/firmware-guide/acpi/dsd/phy.rst b/Documentation/firmware-guide/acpi/dsd/phy.rst index 0d49bad2ea9c..680ad179e5f9 100644 --- a/Documentation/firmware-guide/acpi/dsd/phy.rst +++ b/Documentation/firmware-guide/acpi/dsd/phy.rst @@ -50,6 +50,21 @@ phy-mode The "phy-mode" _DSD property is used to describe the connection to the PHY. The valid values for "phy-mode" are defined in [4]. +managed +------- +Optional property, which specifies the PHY management type. +The valid values for "managed" are defined in [4]. + +fixed-link +---------- +The "fixed-link" is described by a data-only subnode of the +MAC port, which is linked in the _DSD package via +hierarchical data extension (UUID dbb8e3e6-5886-4ba6-8795-1319f52a966b +in accordance with [5] "_DSD Implementation Guide" document). +The subnode should comprise a required property ("speed") and +possibly the optional ones - complete list of parameters and +their values are specified in [4]. + The following ASL example illustrates the usage of these properties. DSDT entry for MDIO node @@ -128,6 +143,48 @@ phy-mode and phy-handle are used as explained earlier. }) } +MAC node example where "managed" property is specified. +------------------------------------------------------- + +.. code-block:: none + + Scope(\_SB.PP21.ETH0) + { + Name (_DSD, Package () { + ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), + Package () { + Package () {"phy-mode", "sgmii"}, + Package () {"managed", "in-band-status"} + } + }) + } + +MAC node example with a "fixed-link" subnode. +--------------------------------------------- + +.. code-block:: none + + Scope(\_SB.PP21.ETH1) + { + Name (_DSD, Package () { + ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), + Package () { + Package () {"phy-mode", "sgmii"}, + }, + ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"), + Package () { + Package () {"fixed-link", "LNK0"} + } + }) + Name (LNK0, Package(){ // Data-only subnode of port + ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), + Package () { + Package () {"speed", 1000}, + Package () {"full-duplex", 1} + } + }) + } + References ========== @@ -138,3 +195,5 @@ References [3] Documentation/firmware-guide/acpi/DSD-properties-rules.rst [4] Documentation/devicetree/bindings/net/ethernet-controller.yaml + +[5] https://github.com/UEFI/DSD-Guide/blob/main/dsd-guide.pdf -- cgit v1.2.3 From 78c57f22e3c87ab0a2844d7c9a120eba51ae34f4 Mon Sep 17 00:00:00 2001 From: Ido Schimmel Date: Tue, 22 Jun 2021 09:50:46 +0300 Subject: ethtool: Use correct command name in title The command is called 'ETHTOOL_MSG_MODULE_EEPROM_GET', not 'ETHTOOL_MSG_MODULE_EEPROM'. Signed-off-by: Ido Schimmel Signed-off-by: David S. Miller --- Documentation/networking/ethtool-netlink.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/networking/ethtool-netlink.rst b/Documentation/networking/ethtool-netlink.rst index 25131df3c2bd..c3600f9c8988 100644 --- a/Documentation/networking/ethtool-netlink.rst +++ b/Documentation/networking/ethtool-netlink.rst @@ -1363,8 +1363,8 @@ in an implementation specific way. ``ETHTOOL_A_FEC_AUTO`` requests the driver to choose FEC mode based on SFP module parameters. This does not mean autonegotiation. -MODULE_EEPROM -============= +MODULE_EEPROM_GET +================= Fetch module EEPROM data dump. This interface is designed to allow dumps of at most 1/2 page at once. This -- cgit v1.2.3 From 913d026fbfaf114ff87afcc77fa4e9309f87f114 Mon Sep 17 00:00:00 2001 From: Ido Schimmel Date: Tue, 22 Jun 2021 09:50:47 +0300 Subject: ethtool: Document correct attribute type 'ETHTOOL_A_MODULE_EEPROM_DATA' is a binary attribute, not a nested one. Signed-off-by: Ido Schimmel Signed-off-by: David S. Miller --- Documentation/networking/ethtool-netlink.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/networking/ethtool-netlink.rst b/Documentation/networking/ethtool-netlink.rst index c3600f9c8988..8ae644f800f0 100644 --- a/Documentation/networking/ethtool-netlink.rst +++ b/Documentation/networking/ethtool-netlink.rst @@ -1388,7 +1388,7 @@ Kernel response contents: +---------------------------------------------+--------+---------------------+ | ``ETHTOOL_A_MODULE_EEPROM_HEADER`` | nested | reply header | +---------------------------------------------+--------+---------------------+ - | ``ETHTOOL_A_MODULE_EEPROM_DATA`` | nested | array of bytes from | + | ``ETHTOOL_A_MODULE_EEPROM_DATA`` | binary | array of bytes from | | | | module EEPROM | +---------------------------------------------+--------+---------------------+ -- cgit v1.2.3 From 37a025e83902903df658489665499a548a53423b Mon Sep 17 00:00:00 2001 From: Ido Schimmel Date: Tue, 22 Jun 2021 09:50:49 +0300 Subject: ethtool: Document behavior when module EEPROM bank attribute is omitted The kernel assumes bank 0 when 'ETHTOOL_MSG_MODULE_EEPROM_GET' is sent without 'ETHTOOL_A_MODULE_EEPROM_BANK'. Document it as part of the interface documentation. Signed-off-by: Ido Schimmel Signed-off-by: David S. Miller --- Documentation/networking/ethtool-netlink.rst | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/networking/ethtool-netlink.rst b/Documentation/networking/ethtool-netlink.rst index 8ae644f800f0..6ea91e41593f 100644 --- a/Documentation/networking/ethtool-netlink.rst +++ b/Documentation/networking/ethtool-netlink.rst @@ -1383,6 +1383,8 @@ Request contents: ``ETHTOOL_A_MODULE_EEPROM_I2C_ADDRESS`` u8 page I2C address ======================================= ====== ========================== +If ``ETHTOOL_A_MODULE_EEPROM_BANK`` is not specified, bank 0 is assumed. + Kernel response contents: +---------------------------------------------+--------+---------------------+ -- cgit v1.2.3 From d1e462a7a5f359cbb9a0e8fbfafcfb6657034105 Mon Sep 17 00:00:00 2001 From: Xin Long Date: Tue, 22 Jun 2021 14:04:48 -0400 Subject: sctp: add probe_interval in sysctl and sock/asoc/transport PLPMTUD can be enabled by doing 'sysctl -w net.sctp.probe_interval=n'. 'n' is the interval for PLPMTUD probe timer in milliseconds, and it can't be less than 5000 if it's not 0. All asoc/transport's PLPMTUD in a new socket will be enabled by default. Signed-off-by: Xin Long Acked-by: Marcelo Ricardo Leitner Signed-off-by: David S. Miller --- Documentation/networking/ip-sysctl.rst | 8 ++++++++ 1 file changed, 8 insertions(+) (limited to 'Documentation') diff --git a/Documentation/networking/ip-sysctl.rst b/Documentation/networking/ip-sysctl.rst index b0436d3a4f11..8bff728b3a1e 100644 --- a/Documentation/networking/ip-sysctl.rst +++ b/Documentation/networking/ip-sysctl.rst @@ -2834,6 +2834,14 @@ encap_port - INTEGER Default: 0 +plpmtud_probe_interval - INTEGER + The time interval (in milliseconds) for sending PLPMTUD probe chunks. + These chunks are sent at the specified interval with a variable size + to probe the mtu of a given path between 2 endpoints. PLPMTUD will + be disabled when 0 is set, and other values for it must be >= 5000. + + Default: 0 + ``/proc/sys/net/core/*`` ======================== -- cgit v1.2.3 From 958ae02e8df8b656fa66d6172e8e35e8da2e3a4c Mon Sep 17 00:00:00 2001 From: Lokesh Vutla Date: Fri, 28 May 2021 10:27:42 +0530 Subject: dt-bindings: clock: ehrpwm: Add support for AM64 specific compatible Introduce AM64 specific compatible for epwm time-base sub-module clock. Signed-off-by: Lokesh Vutla Link: https://lore.kernel.org/r/20210528045743.16537-2-lokeshvutla@ti.com Acked-by: Rob Herring Reviewed-by: Tero Kristo Signed-off-by: Stephen Boyd --- Documentation/devicetree/bindings/clock/ti,am654-ehrpwm-tbclk.yaml | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/ti,am654-ehrpwm-tbclk.yaml b/Documentation/devicetree/bindings/clock/ti,am654-ehrpwm-tbclk.yaml index 6b419a9878f3..9b537bc876b5 100644 --- a/Documentation/devicetree/bindings/clock/ti,am654-ehrpwm-tbclk.yaml +++ b/Documentation/devicetree/bindings/clock/ti,am654-ehrpwm-tbclk.yaml @@ -12,7 +12,9 @@ maintainers: properties: compatible: items: - - const: ti,am654-ehrpwm-tbclk + - enum: + - ti,am654-ehrpwm-tbclk + - ti,am64-epwm-tbclk - const: syscon "#clock-cells": -- cgit v1.2.3 From d2f77960e5b03b2d373252b2ee150a4a14010f99 Mon Sep 17 00:00:00 2001 From: Geliang Tang Date: Tue, 22 Jun 2021 12:25:18 -0700 Subject: mptcp: add sysctl allow_join_initial_addr_port This patch added a new sysctl, named allow_join_initial_addr_port, to control whether allow peers to send join requests to the IP address and port number used by the initial subflow. Suggested-by: Florian Westphal Acked-by: Paolo Abeni Signed-off-by: Geliang Tang Signed-off-by: Mat Martineau Signed-off-by: David S. Miller --- Documentation/networking/mptcp-sysctl.rst | 13 +++++++++++++ 1 file changed, 13 insertions(+) (limited to 'Documentation') diff --git a/Documentation/networking/mptcp-sysctl.rst b/Documentation/networking/mptcp-sysctl.rst index ee06fd782465..76d939e688b8 100644 --- a/Documentation/networking/mptcp-sysctl.rst +++ b/Documentation/networking/mptcp-sysctl.rst @@ -32,3 +32,16 @@ checksum_enabled - BOOLEAN per-namespace sysctl. Default: 0 + +allow_join_initial_addr_port - BOOLEAN + Allow peers to send join requests to the IP address and port number used + by the initial subflow if the value is 1. This controls a flag that is + sent to the peer at connection time, and whether such join requests are + accepted or denied. + + Joins to addresses advertised with ADD_ADDR are not affected by this + value. + + This is a per-namespace sysctl. + + Default: 1 -- cgit v1.2.3 From fd7b23be92059f14537cb9cac0f0894c3a9b1284 Mon Sep 17 00:00:00 2001 From: Leah Rumancik Date: Tue, 18 May 2021 15:13:27 +0000 Subject: ext4: update journal documentation Add a section about journal checkpointing, including information about the ioctl EXT4_IOC_CHECKPOINT which can be used to trigger a journal checkpoint from userspace. Also, update the journal allocation information to reflect that up to 10240000 blocks are used for the journal and that the journal is not necessarily contiguous. Signed-off-by: Leah Rumancik Changes in v5: - clarify behavior of DRY_RUN flag Link: https://lore.kernel.org/r/20210518151327.130198-3-leah.rumancik@gmail.com Signed-off-by: Theodore Ts'o --- Documentation/filesystems/ext4/journal.rst | 39 ++++++++++++++++++++++++------ 1 file changed, 31 insertions(+), 8 deletions(-) (limited to 'Documentation') diff --git a/Documentation/filesystems/ext4/journal.rst b/Documentation/filesystems/ext4/journal.rst index cdbfec473167..5fad38860f17 100644 --- a/Documentation/filesystems/ext4/journal.rst +++ b/Documentation/filesystems/ext4/journal.rst @@ -4,14 +4,14 @@ Journal (jbd2) -------------- Introduced in ext3, the ext4 filesystem employs a journal to protect the -filesystem against corruption in the case of a system crash. A small -continuous region of disk (default 128MiB) is reserved inside the -filesystem as a place to land “important” data writes on-disk as quickly -as possible. Once the important data transaction is fully written to the -disk and flushed from the disk write cache, a record of the data being -committed is also written to the journal. At some later point in time, -the journal code writes the transactions to their final locations on -disk (this could involve a lot of seeking or a lot of small +filesystem against metadata inconsistencies in the case of a system crash. Up +to 10,240,000 file system blocks (see man mke2fs(8) for more details on journal +size limits) can be reserved inside the filesystem as a place to land +“important” data writes on-disk as quickly as possible. Once the important +data transaction is fully written to the disk and flushed from the disk write +cache, a record of the data being committed is also written to the journal. At +some later point in time, the journal code writes the transactions to their +final locations on disk (this could involve a lot of seeking or a lot of small read-write-erases) before erasing the commit record. Should the system crash during the second slow write, the journal can be replayed all the way to the latest commit record, guaranteeing the atomicity of whatever @@ -731,3 +731,26 @@ point, the refcount for inode 11 is not reliable, but that gets fixed by the replay of last inode 11 tag. Thus, by converting a non-idempotent procedure into a series of idempotent outcomes, fast commits ensured idempotence during the replay. + +Journal Checkpoint +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Checkpointing the journal ensures all transactions and their associated buffers +are submitted to the disk. In-progress transactions are waited upon and included +in the checkpoint. Checkpointing is used internally during critical updates to +the filesystem including journal recovery, filesystem resizing, and freeing of +the journal_t structure. + +A journal checkpoint can be triggered from userspace via the ioctl +EXT4_IOC_CHECKPOINT. This ioctl takes a single, u64 argument for flags. +Currently, three flags are supported. First, EXT4_IOC_CHECKPOINT_FLAG_DRY_RUN +can be used to verify input to the ioctl. It returns error if there is any +invalid input, otherwise it returns success without performing +any checkpointing. This can be used to check whether the ioctl exists on a +system and to verify there are no issues with arguments or flags. The +other two flags are EXT4_IOC_CHECKPOINT_FLAG_DISCARD and +EXT4_IOC_CHECKPOINT_FLAG_ZEROOUT. These flags cause the journal blocks to be +discarded or zero-filled, respectively, after the journal checkpoint is +complete. EXT4_IOC_CHECKPOINT_FLAG_DISCARD and EXT4_IOC_CHECKPOINT_FLAG_ZEROOUT +cannot both be set. The ioctl may be useful when snapshotting a system or for +complying with content deletion SLOs. -- cgit v1.2.3 From bf3ec9deaa33889630722c47f7bb86ba58872ea7 Mon Sep 17 00:00:00 2001 From: Thierry Reding Date: Mon, 21 Jun 2021 16:00:36 +0200 Subject: dt-bindings: arm-smmu: Fix json-schema syntax Commit 4287861dca9d ("dt-bindings: arm-smmu: Add Tegra186 compatible string") introduced a jsonschema syntax error as a result of a rebase gone wrong. Fix it. Fixes: 4287861dca9d ("dt-bindings: arm-smmu: Add Tegra186 compatible string") Reported-by: Rob Herring Signed-off-by: Thierry Reding Acked-by: Rob Herring Link: https://lore.kernel.org/r/20210621140036.2879563-1-thierry.reding@gmail.com Signed-off-by: Krzysztof Kozlowski --- Documentation/devicetree/bindings/iommu/arm,smmu.yaml | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml index 1181b590db71..03f2b2d4db30 100644 --- a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml +++ b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml @@ -52,16 +52,14 @@ properties: items: - const: marvell,ap806-smmu-500 - const: arm,mmu-500 - - description: NVIDIA SoCs that program two ARM MMU-500s identically - items: - description: NVIDIA SoCs that require memory controller interaction and may program multiple ARM MMU-500s identically with the memory controller interleaving translations between multiple instances for improved performance. items: - enum: - - const: nvidia,tegra194-smmu - - const: nvidia,tegra186-smmu + - nvidia,tegra194-smmu + - nvidia,tegra186-smmu - const: nvidia,smmu-500 - items: - const: arm,mmu-500 -- cgit v1.2.3 From 4b9718b5a201eddcd00d9db6c36b18840125c7ee Mon Sep 17 00:00:00 2001 From: Ilya Maximets Date: Tue, 22 Jun 2021 20:56:47 +0200 Subject: docs, af_xdp: Consistent indentation in examples Examples in this document use all kinds of indentation from 3 to 5 spaces and even mixed with tabs. Making them all even and equal to 4 spaces. Signed-off-by: Ilya Maximets Signed-off-by: Daniel Borkmann Acked-by: Magnus Karlsson Link: https://lore.kernel.org/bpf/20210622185647.3705104-1-i.maximets@ovn.org --- Documentation/networking/af_xdp.rst | 32 ++++++++++++++++---------------- 1 file changed, 16 insertions(+), 16 deletions(-) (limited to 'Documentation') diff --git a/Documentation/networking/af_xdp.rst b/Documentation/networking/af_xdp.rst index 2ccc5644cc98..42576880aa4a 100644 --- a/Documentation/networking/af_xdp.rst +++ b/Documentation/networking/af_xdp.rst @@ -290,19 +290,19 @@ round-robin example of distributing packets is shown below: #define MAX_SOCKS 16 struct { - __uint(type, BPF_MAP_TYPE_XSKMAP); - __uint(max_entries, MAX_SOCKS); - __uint(key_size, sizeof(int)); - __uint(value_size, sizeof(int)); + __uint(type, BPF_MAP_TYPE_XSKMAP); + __uint(max_entries, MAX_SOCKS); + __uint(key_size, sizeof(int)); + __uint(value_size, sizeof(int)); } xsks_map SEC(".maps"); static unsigned int rr; SEC("xdp_sock") int xdp_sock_prog(struct xdp_md *ctx) { - rr = (rr + 1) & (MAX_SOCKS - 1); + rr = (rr + 1) & (MAX_SOCKS - 1); - return bpf_redirect_map(&xsks_map, rr, XDP_DROP); + return bpf_redirect_map(&xsks_map, rr, XDP_DROP); } Note, that since there is only a single set of FILL and COMPLETION @@ -379,7 +379,7 @@ would look like this for the TX path: .. code-block:: c if (xsk_ring_prod__needs_wakeup(&my_tx_ring)) - sendto(xsk_socket__fd(xsk_handle), NULL, 0, MSG_DONTWAIT, NULL, 0); + sendto(xsk_socket__fd(xsk_handle), NULL, 0, MSG_DONTWAIT, NULL, 0); I.e., only use the syscall if the flag is set. @@ -442,9 +442,9 @@ purposes. The supported statistics are shown below: .. code-block:: c struct xdp_statistics { - __u64 rx_dropped; /* Dropped for reasons other than invalid desc */ - __u64 rx_invalid_descs; /* Dropped due to invalid descriptor */ - __u64 tx_invalid_descs; /* Dropped due to invalid descriptor */ + __u64 rx_dropped; /* Dropped for reasons other than invalid desc */ + __u64 rx_invalid_descs; /* Dropped due to invalid descriptor */ + __u64 tx_invalid_descs; /* Dropped due to invalid descriptor */ }; XDP_OPTIONS getsockopt @@ -483,15 +483,15 @@ like this: .. code-block:: c // struct xdp_rxtx_ring { - // __u32 *producer; - // __u32 *consumer; - // struct xdp_desc *desc; + // __u32 *producer; + // __u32 *consumer; + // struct xdp_desc *desc; // }; // struct xdp_umem_ring { - // __u32 *producer; - // __u32 *consumer; - // __u64 *desc; + // __u32 *producer; + // __u32 *consumer; + // __u64 *desc; // }; // typedef struct xdp_rxtx_ring RING; -- cgit v1.2.3 From 4c89b53d05f1f5d25e9aec09c00351994101cc97 Mon Sep 17 00:00:00 2001 From: Jaegeuk Kim Date: Thu, 3 Jun 2021 12:31:08 -0700 Subject: f2fs: clean up /sys/fs/f2fs//features Let's create /sys/fs/f2fs//feature_list/ to meet sysfs rule. Note that there are three feature list entries: 1) /sys/fs/f2fs/features : shows runtime features supported by in-kernel f2fs along with Kconfig. - ref. F2FS_FEATURE_RO_ATTR() 2) /sys/fs/f2fs/$s_id/features : shows on-disk features enabled by mkfs.f2fs, used for old kernels. This won't add new feature anymore, and thus, users should check entries in 3) instead of this 2). 3) /sys/fs/f2fs/$s_id/feature_list : shows on-disk features enabled by mkfs.f2fs per instance, which follows sysfs entry rule where each entry should expose single value. This list covers old feature list provided by 2) and beyond. Therefore, please add new on-disk feature in this list only. - ref. F2FS_SB_FEATURE_RO_ATTR() Reviewed-by: Chao Yu Reviewed-by: Eric Biggers Signed-off-by: Jaegeuk Kim --- Documentation/ABI/testing/sysfs-fs-f2fs | 29 ++++++++++++++++++++++++++++- 1 file changed, 28 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-fs-f2fs b/Documentation/ABI/testing/sysfs-fs-f2fs index 5088281e312e..95155e4ec7fe 100644 --- a/Documentation/ABI/testing/sysfs-fs-f2fs +++ b/Documentation/ABI/testing/sysfs-fs-f2fs @@ -203,7 +203,34 @@ Description: Shows total written kbytes issued to disk. What: /sys/fs/f2fs//features Date: July 2017 Contact: "Jaegeuk Kim" -Description: Shows all enabled features in current device. +Description: /feature_list/ + Shows all enabled features in current device. + Supported features: + encryption, blkzoned, extra_attr, projquota, inode_checksum, + flexible_inline_xattr, quota_ino, inode_crtime, lost_found, + verity, sb_checksum, casefold, readonly, compression, pin_file. + +What: /sys/fs/f2fs//feature_list/ +Date: June 2021 +Contact: "Jaegeuk Kim" +Description: Expand /sys/fs/f2fs//features to meet sysfs rule. + Supported on-disk features: + encryption, block_zoned (aka blkzoned), extra_attr, + project_quota (aka projquota), inode_checksum, + flexible_inline_xattr, quota_ino, inode_crtime, lost_found, + verity, sb_checksum, casefold, readonly, compression. + Note that, pin_file is moved into /sys/fs/f2fs/features/. + +What: /sys/fs/f2fs/features/ +Date: July 2017 +Contact: "Jaegeuk Kim" +Description: Shows all enabled kernel features. + Supported features: + encryption, block_zoned, extra_attr, project_quota, + inode_checksum, flexible_inline_xattr, quota_ino, + inode_crtime, lost_found, verity, sb_checksum, + casefold, readonly, compression, test_dummy_encryption_v2, + atomic_write, pin_file, encrypted_casefold. What: /sys/fs/f2fs//inject_rate Date: May 2016 -- cgit v1.2.3 From 6ce19aff0b8cd386860855185c6cd79337fc4d2b Mon Sep 17 00:00:00 2001 From: Chao Yu Date: Thu, 20 May 2021 19:51:50 +0800 Subject: f2fs: compress: add compress_inode to cache compressed blocks Support to use address space of inner inode to cache compressed block, in order to improve cache hit ratio of random read. Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim --- Documentation/filesystems/f2fs.rst | 3 +++ 1 file changed, 3 insertions(+) (limited to 'Documentation') diff --git a/Documentation/filesystems/f2fs.rst b/Documentation/filesystems/f2fs.rst index 992bf91eeec8..809c4d0a696f 100644 --- a/Documentation/filesystems/f2fs.rst +++ b/Documentation/filesystems/f2fs.rst @@ -289,6 +289,9 @@ compress_mode=%s Control file compression mode. This supports "fs" and "user" choosing the target file and the timing. The user can do manual compression/decompression on the compression enabled files using ioctls. +compress_cache Support to use address space of a filesystem managed inode to + cache compressed block, in order to improve cache hit ratio of + random read. inlinecrypt When possible, encrypt/decrypt the contents of encrypted files using the blk-crypto framework rather than filesystem-layer encryption. This allows the use of -- cgit v1.2.3 From 3c16dc40aab84bab9cf54c2b61a458bb86b180c3 Mon Sep 17 00:00:00 2001 From: Chao Yu Date: Tue, 8 Jun 2021 07:31:22 +0800 Subject: f2fs: fix to avoid adding tab before doc section Otherwise whole section after tab will be invisible in compiled html format document. Cc: Mauro Carvalho Chehab Fixes: 89272ca1102e ("docs: filesystems: convert f2fs.txt to ReST") Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim --- Documentation/filesystems/f2fs.rst | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) (limited to 'Documentation') diff --git a/Documentation/filesystems/f2fs.rst b/Documentation/filesystems/f2fs.rst index 809c4d0a696f..b91e5a8444d5 100644 --- a/Documentation/filesystems/f2fs.rst +++ b/Documentation/filesystems/f2fs.rst @@ -720,10 +720,10 @@ users. ===================== ======================== =================== User F2FS Block ===================== ======================== =================== - META WRITE_LIFE_NOT_SET - HOT_NODE " - WARM_NODE " - COLD_NODE " +N/A META WRITE_LIFE_NOT_SET +N/A HOT_NODE " +N/A WARM_NODE " +N/A COLD_NODE " ioctl(COLD) COLD_DATA WRITE_LIFE_EXTREME extension list " " @@ -749,10 +749,10 @@ WRITE_LIFE_LONG " WRITE_LIFE_LONG ===================== ======================== =================== User F2FS Block ===================== ======================== =================== - META WRITE_LIFE_MEDIUM; - HOT_NODE WRITE_LIFE_NOT_SET - WARM_NODE " - COLD_NODE WRITE_LIFE_NONE +N/A META WRITE_LIFE_MEDIUM; +N/A HOT_NODE WRITE_LIFE_NOT_SET +N/A WARM_NODE " +N/A COLD_NODE WRITE_LIFE_NONE ioctl(COLD) COLD_DATA WRITE_LIFE_EXTREME extension list " " -- cgit v1.2.3 From 8e0eb2fb5c0732a6fa53f2df7079754152857c24 Mon Sep 17 00:00:00 2001 From: Claudius Heine Date: Thu, 17 Jun 2021 10:52:30 +0200 Subject: ASoC: tlv320aic32x4: dt-bindings: add TAS2505 to compatible This adds 'ti,tas2505' for TAS2505 to the list of allowed compatible strings. Signed-off-by: Claudius Heine Link: https://lore.kernel.org/r/20210617085230.1851503-4-ch@denx.de Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/sound/tlv320aic32x4.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/tlv320aic32x4.txt b/Documentation/devicetree/bindings/sound/tlv320aic32x4.txt index ca75890f0d07..f59125bc79d1 100644 --- a/Documentation/devicetree/bindings/sound/tlv320aic32x4.txt +++ b/Documentation/devicetree/bindings/sound/tlv320aic32x4.txt @@ -6,6 +6,7 @@ Required properties: - compatible - "string" - One of: "ti,tlv320aic32x4" TLV320AIC3204 "ti,tlv320aic32x6" TLV320AIC3206, TLV320AIC3256 + "ti,tas2505" TAS2505, TAS2521 - reg: I2C slave address - supply-*: Required supply regulators are: "iov" - digital IO power supply -- cgit v1.2.3 From c58c7e9bf55ced301fdd9c8c1841361cc5fc8458 Mon Sep 17 00:00:00 2001 From: Jon Lin Date: Mon, 21 Jun 2021 18:47:55 +0800 Subject: spi: spi-rockchip: add description for rv1126 The description below will be used for rv1126.dtsi or compatible one in the future Signed-off-by: Jon Lin Link: https://lore.kernel.org/r/20210621104800.19088-2-jon.lin@rock-chips.com Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/spi/spi-rockchip.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/spi/spi-rockchip.yaml b/Documentation/devicetree/bindings/spi/spi-rockchip.yaml index 1e6cf29e6388..7f987e79337c 100644 --- a/Documentation/devicetree/bindings/spi/spi-rockchip.yaml +++ b/Documentation/devicetree/bindings/spi/spi-rockchip.yaml @@ -33,6 +33,7 @@ properties: - rockchip,rk3328-spi - rockchip,rk3368-spi - rockchip,rk3399-spi + - rockchip,rv1126-spi - const: rockchip,rk3066-spi reg: -- cgit v1.2.3 From bfc245129caa84dd384caf002921ededf5917951 Mon Sep 17 00:00:00 2001 From: Suman Anna Date: Wed, 23 Jun 2021 12:32:41 -0500 Subject: dt-bindings: remoteproc: pru: Update bindings for K3 AM64x SoCs The K3 AM64x SoCs have an ICSSG IP that is similar to the IP revisions used on K3 AM65x SR2.0 and J721E SoCs. The ICSSG IP on K3 AM64x SoCs have the same set of two PRU cores, two RTU cores and two auxiliary PRU cores called Transmit PRUs (Tx_PRUs). There are some minor differences surrounding the PRU cores like different Broadside RAM (BSRAM) sizes w.r.t AM65x SR1.0 SoCs. Update the PRU remoteproc bindings for these PRU cores on AM64x SoCs. Reviewed-by: Grygorii Strashko Signed-off-by: Suman Anna Link: https://lore.kernel.org/r/20210623173243.7862-2-s-anna@ti.com Signed-off-by: Bjorn Andersson --- Documentation/devicetree/bindings/remoteproc/ti,pru-rproc.yaml | 5 +++++ 1 file changed, 5 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/remoteproc/ti,pru-rproc.yaml b/Documentation/devicetree/bindings/remoteproc/ti,pru-rproc.yaml index 63071eef1632..d7c3a78e37e6 100644 --- a/Documentation/devicetree/bindings/remoteproc/ti,pru-rproc.yaml +++ b/Documentation/devicetree/bindings/remoteproc/ti,pru-rproc.yaml @@ -36,6 +36,9 @@ properties: enum: - ti,am3356-pru # for AM335x SoC family (AM3356+ SoCs only) - ti,am4376-pru # for AM437x SoC family (AM4376+ SoCs only) + - ti,am642-pru # for PRUs in K3 AM64x SoC family + - ti,am642-rtu # for RTUs in K3 AM64x SoC family + - ti,am642-tx-pru # for Tx_PRUs in K3 AM64x SoC family - ti,am5728-pru # for AM57xx SoC family - ti,k2g-pru # for 66AK2G SoC family - ti,am654-pru # for PRUs in K3 AM65x SoC family @@ -68,6 +71,7 @@ if: enum: - ti,am654-rtu - ti,j721e-rtu + - ti,am642-rtu then: properties: $nodename: @@ -79,6 +83,7 @@ else: enum: - ti,am654-tx-pru - ti,j721e-tx-pru + - ti,am642-tx-pru then: properties: $nodename: -- cgit v1.2.3 From 5f5fb97491b9a934a1ae0196d073e7fe603d8c91 Mon Sep 17 00:00:00 2001 From: Peng Fan Date: Tue, 22 Jun 2021 14:01:47 +0800 Subject: dt-bindings: remoteproc: imx_rproc: support i.MX8ULP Add i.MX8ULP remote processor(Cortex-M33) compatible string Signed-off-by: Peng Fan Link: https://lore.kernel.org/r/20210622060148.18411-2-peng.fan@oss.nxp.com Signed-off-by: Bjorn Andersson --- Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml b/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml index 1dc34cf5a4ea..fc16d903353e 100644 --- a/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml +++ b/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml @@ -19,6 +19,7 @@ properties: - fsl,imx8mm-cm4 - fsl,imx8mn-cm7 - fsl,imx8mp-cm7 + - fsl,imx8ulp-cm33 - fsl,imx7d-cm4 - fsl,imx7ulp-cm4 - fsl,imx6sx-cm4 -- cgit v1.2.3 From 2ec73ece4efd818536519f1c5908017122d2e7b5 Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Wed, 16 Jun 2021 08:27:17 +0200 Subject: docs: dev-tools: kunit: don't use a table for docs name We'll be replacing :doc:`foo` references to Documentation/foo.rst. Yet, here it happens inside a table. Doing a search-and-replace would break it. Yet, as there's no good reason to use a table there, let's just convert it into a list. Reviewed-by: David Gow Acked-by: Brendan Higgins Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Shuah Khan --- Documentation/dev-tools/kunit/api/index.rst | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/dev-tools/kunit/api/index.rst b/Documentation/dev-tools/kunit/api/index.rst index 9b9bffe5d41a..b33ad72bcf0b 100644 --- a/Documentation/dev-tools/kunit/api/index.rst +++ b/Documentation/dev-tools/kunit/api/index.rst @@ -10,7 +10,7 @@ API Reference This section documents the KUnit kernel testing API. It is divided into the following sections: -================================= ============================================== -:doc:`test` documents all of the standard testing API - excluding mocking or mocking related features. -================================= ============================================== +Documentation/dev-tools/kunit/api/test.rst + + - documents all of the standard testing API excluding mocking + or mocking related features. -- cgit v1.2.3 From 99a8e899fab95be3e6b66edf7b303a58f6997be4 Mon Sep 17 00:00:00 2001 From: David Gow Date: Thu, 13 May 2021 12:31:57 -0700 Subject: Documentation: kunit: Clean up some string casts in examples As the type checking is no longer excessively strict, get rid of the unsightly (char*) casts -- and comment discussing them -- from the KUnit usage page. Signed-off-by: David Gow Reviewed-by: Daniel Latypov Acked-by: Brendan Higgins Signed-off-by: Shuah Khan --- Documentation/dev-tools/kunit/usage.rst | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/dev-tools/kunit/usage.rst b/Documentation/dev-tools/kunit/usage.rst index 888c341701da..97c9a31919a6 100644 --- a/Documentation/dev-tools/kunit/usage.rst +++ b/Documentation/dev-tools/kunit/usage.rst @@ -465,10 +465,9 @@ fictitious example for ``sha1sum(1)`` .. code-block:: c - /* Note: the cast is to satisfy overly strict type-checking. */ #define TEST_SHA1(in, want) \ sha1sum(in, out); \ - KUNIT_EXPECT_STREQ_MSG(test, (char *)out, want, "sha1sum(%s)", in); + KUNIT_EXPECT_STREQ_MSG(test, out, want, "sha1sum(%s)", in); char out[40]; TEST_SHA1("hello world", "2aae6c35c94fcfb415dbe95f408b9ce91ee846ed"); @@ -507,7 +506,7 @@ In some cases, it can be helpful to write a *table-driven test* instead, e.g. }; for (i = 0; i < ARRAY_SIZE(cases); ++i) { sha1sum(cases[i].str, out); - KUNIT_EXPECT_STREQ_MSG(test, (char *)out, cases[i].sha1, + KUNIT_EXPECT_STREQ_MSG(test, out, cases[i].sha1, "sha1sum(%s)", cases[i].str); } @@ -568,7 +567,7 @@ Reusing the same ``cases`` array from above, we can write the test as a struct sha1_test_case *test_param = (struct sha1_test_case *)(test->param_value); sha1sum(test_param->str, out); - KUNIT_EXPECT_STREQ_MSG(test, (char *)out, test_param->sha1, + KUNIT_EXPECT_STREQ_MSG(test, out, test_param->sha1, "sha1sum(%s)", test_param->str); } -- cgit v1.2.3 From d9d6b8225e7319fde69b1aa59c3bb66d501f3845 Mon Sep 17 00:00:00 2001 From: David Gow Date: Fri, 21 May 2021 21:42:40 -0700 Subject: kunit: Move default config from arch/um -> tools/testing/kunit The default .kunitconfig file is currently kept in arch/um/configs/kunit_defconfig, but -- with the impending QEMU patch -- will no-longer be exclusively used for UML-based kernels. Move it alongside the other KUnit configs in tools/testing/kunit/configs, and give it a name which matches the existing all_tests.config and broken_on_uml.config files. Also update the Getting Started documentation to point to the new file. Signed-off-by: David Gow Reviewed-by: Brendan Higgins Signed-off-by: Shuah Khan --- Documentation/dev-tools/kunit/start.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/dev-tools/kunit/start.rst b/Documentation/dev-tools/kunit/start.rst index aa56d7ca6bfb..62d8462db4df 100644 --- a/Documentation/dev-tools/kunit/start.rst +++ b/Documentation/dev-tools/kunit/start.rst @@ -36,7 +36,7 @@ A good starting point for a ``.kunitconfig`` is the KUnit defconfig: .. code-block:: bash cd $PATH_TO_LINUX_REPO - cp arch/um/configs/kunit_defconfig .kunitconfig + cp tools/testing/kunit/configs/default.config .kunitconfig You can then add any other Kconfig options you wish, e.g.: -- cgit v1.2.3 From adf3c31e18b765ea24eba7b0c1efc076b8ee3d55 Mon Sep 17 00:00:00 2001 From: Beata Michalska Date: Thu, 3 Jun 2021 15:06:27 +0100 Subject: sched/doc: Update the CPU capacity asymmetry bits Update the documentation bits referring to capacity aware scheduling with regards to newly introduced SD_ASYM_CPUCAPACITY_FULL sched_domain flag. Signed-off-by: Beata Michalska Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Valentin Schneider Reviewed-by: Dietmar Eggemann Link: https://lore.kernel.org/r/20210603140627.8409-4-beata.michalska@arm.com --- Documentation/scheduler/sched-capacity.rst | 6 ++++-- Documentation/scheduler/sched-energy.rst | 2 +- 2 files changed, 5 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/scheduler/sched-capacity.rst b/Documentation/scheduler/sched-capacity.rst index 9b7cbe43b2d1..805f85f330b5 100644 --- a/Documentation/scheduler/sched-capacity.rst +++ b/Documentation/scheduler/sched-capacity.rst @@ -284,8 +284,10 @@ whether the system exhibits asymmetric CPU capacities. Should that be the case: - The sched_asym_cpucapacity static key will be enabled. -- The SD_ASYM_CPUCAPACITY flag will be set at the lowest sched_domain level that - spans all unique CPU capacity values. +- The SD_ASYM_CPUCAPACITY_FULL flag will be set at the lowest sched_domain + level that spans all unique CPU capacity values. +- The SD_ASYM_CPUCAPACITY flag will be set for any sched_domain that spans + CPUs with any range of asymmetry. The sched_asym_cpucapacity static key is intended to guard sections of code that cater to asymmetric CPU capacity systems. Do note however that said key is diff --git a/Documentation/scheduler/sched-energy.rst b/Documentation/scheduler/sched-energy.rst index afe02d394402..8fbce5e767d9 100644 --- a/Documentation/scheduler/sched-energy.rst +++ b/Documentation/scheduler/sched-energy.rst @@ -328,7 +328,7 @@ section lists these dependencies and provides hints as to how they can be met. As mentioned in the introduction, EAS is only supported on platforms with asymmetric CPU topologies for now. This requirement is checked at run-time by -looking for the presence of the SD_ASYM_CPUCAPACITY flag when the scheduling +looking for the presence of the SD_ASYM_CPUCAPACITY_FULL flag when the scheduling domains are built. See Documentation/scheduler/sched-capacity.rst for requirements to be met for this -- cgit v1.2.3 From 0715786771f24190b3f2dcdcaf2af263c1ef46eb Mon Sep 17 00:00:00 2001 From: Laurent Pinchart Date: Thu, 24 Jun 2021 03:02:59 +0300 Subject: dt-bindings: drm/bridge: ti-sn65dsi8: Make enable GPIO optional The SN65DSI86 EN pin can be hardwired to a high level, or connected to a global reset signal, not controllable by the kernel. Make it optional in those cases. Signed-off-by: Laurent Pinchart Reviewed-by: Jagan Teki Reviewed-by: Stephen Boyd Reviewed-by: Douglas Anderson Acked-by: Rob Herring Signed-off-by: Robert Foss Link: https://patchwork.freedesktop.org/patch/msgid/20210624000304.16281-2-laurent.pinchart+renesas@ideasonboard.com --- Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml | 1 - 1 file changed, 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml index 12b876a20574..1c2daf7c24cc 100644 --- a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml +++ b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml @@ -153,7 +153,6 @@ properties: required: - compatible - reg - - enable-gpios - vccio-supply - vpll-supply - vcca-supply -- cgit v1.2.3 From 2f0b20fb0568f770524e1e6515d217a95d0f418c Mon Sep 17 00:00:00 2001 From: Iskren Chernev Date: Tue, 22 Jun 2021 23:32:38 +0300 Subject: dt-bindings: usb: qcom,dwc3: Add bindings for sm6115/4250 Add the compatible string for SM6115/4250 SoC from Qualcomm. Reviewed-by: Bjorn Andersson Signed-off-by: Iskren Chernev Link: https://lore.kernel.org/r/20210622203240.559979-2-iskren.chernev@gmail.com Signed-off-by: Greg Kroah-Hartman --- Documentation/devicetree/bindings/usb/qcom,dwc3.yaml | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml b/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml index 413299b5fe2b..4e6451789806 100644 --- a/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml +++ b/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml @@ -19,6 +19,8 @@ properties: - qcom,sc7280-dwc3 - qcom,sdm845-dwc3 - qcom,sdx55-dwc3 + - qcom,sm4250-dwc3 + - qcom,sm6115-dwc3 - qcom,sm8150-dwc3 - qcom,sm8250-dwc3 - qcom,sm8350-dwc3 -- cgit v1.2.3 From bbaabe0d26742e914eccc26d818128a84ec40458 Mon Sep 17 00:00:00 2001 From: Iskren Chernev Date: Tue, 22 Jun 2021 23:32:39 +0300 Subject: dt-bindings: phy: qcom,qusb2: document sm4250/6115 compatible This compatible string is for the HS USB PHY on sm4250 and sm6115 platforms. Reviewed-by: Bjorn Andersson Signed-off-by: Iskren Chernev Link: https://lore.kernel.org/r/20210622203240.559979-3-iskren.chernev@gmail.com Signed-off-by: Greg Kroah-Hartman --- Documentation/devicetree/bindings/phy/qcom,qusb2-phy.yaml | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/phy/qcom,qusb2-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,qusb2-phy.yaml index 9f9cf07b7d45..70258540676a 100644 --- a/Documentation/devicetree/bindings/phy/qcom,qusb2-phy.yaml +++ b/Documentation/devicetree/bindings/phy/qcom,qusb2-phy.yaml @@ -23,6 +23,8 @@ properties: - qcom,msm8998-qusb2-phy - qcom,sdm660-qusb2-phy - qcom,ipq6018-qusb2-phy + - qcom,sm4250-qusb2-phy + - qcom,sm6115-qusb2-phy - items: - enum: - qcom,sc7180-qusb2-phy -- cgit v1.2.3 From 3b1f941536af17537da09a7552c8e74804dd6823 Mon Sep 17 00:00:00 2001 From: Jianpeng Ma Date: Wed, 23 Jun 2021 10:31:26 +0800 Subject: docs: ABI: testing: sysfs-firmware-memmap: add some memmap types. Compare with arch/x86/kernel/e820.c, types of memmap omitted some. So add. Signed-off-by: Jianpeng Ma Link: https://lore.kernel.org/r/20210623023126.104380-1-jianpeng.ma@intel.com Signed-off-by: Greg Kroah-Hartman --- Documentation/ABI/testing/sysfs-firmware-memmap | 4 ++++ 1 file changed, 4 insertions(+) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-firmware-memmap b/Documentation/ABI/testing/sysfs-firmware-memmap index 1f6f4d3a32c0..9205122fa4b1 100644 --- a/Documentation/ABI/testing/sysfs-firmware-memmap +++ b/Documentation/ABI/testing/sysfs-firmware-memmap @@ -56,6 +56,10 @@ Description: - System RAM - ACPI Tables - ACPI Non-volatile Storage + - Unusable memory + - Persistent Memory (legacy) + - Persistent Memory + - Soft Reserved - reserved Following shell snippet can be used to display that memory -- cgit v1.2.3 From 9a145c04a293933002ec288a4d6b4f370b59e4d1 Mon Sep 17 00:00:00 2001 From: "Paul E. McKenney" Date: Thu, 24 Jun 2021 18:05:52 +0200 Subject: doc: Clarify and expand RCU updaters and corresponding readers MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit This commit clarifies which primitives readers can use given that the corresponding updaters have made a specific choice. This commit also adds this information for the various RCU Tasks flavors. While in the area, it removes a paragraph that no longer applies in any straightforward manner. Signed-off-by: Paul E. McKenney Signed-off-by: Toke Høiland-Jørgensen Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20210624160609.292325-3-toke@redhat.com --- Documentation/RCU/checklist.rst | 48 +++++++++++++++++++++++------------------ 1 file changed, 27 insertions(+), 21 deletions(-) (limited to 'Documentation') diff --git a/Documentation/RCU/checklist.rst b/Documentation/RCU/checklist.rst index 1030119294d0..07f6cb8f674d 100644 --- a/Documentation/RCU/checklist.rst +++ b/Documentation/RCU/checklist.rst @@ -211,27 +211,33 @@ over a rather long period of time, but improvements are always welcome! of the system, especially to real-time workloads running on the rest of the system. -7. As of v4.20, a given kernel implements only one RCU flavor, - which is RCU-sched for PREEMPTION=n and RCU-preempt for PREEMPTION=y. - If the updater uses call_rcu() or synchronize_rcu(), - then the corresponding readers may use rcu_read_lock() and - rcu_read_unlock(), rcu_read_lock_bh() and rcu_read_unlock_bh(), - or any pair of primitives that disables and re-enables preemption, - for example, rcu_read_lock_sched() and rcu_read_unlock_sched(). - If the updater uses synchronize_srcu() or call_srcu(), - then the corresponding readers must use srcu_read_lock() and - srcu_read_unlock(), and with the same srcu_struct. The rules for - the expedited primitives are the same as for their non-expedited - counterparts. Mixing things up will result in confusion and - broken kernels, and has even resulted in an exploitable security - issue. - - One exception to this rule: rcu_read_lock() and rcu_read_unlock() - may be substituted for rcu_read_lock_bh() and rcu_read_unlock_bh() - in cases where local bottom halves are already known to be - disabled, for example, in irq or softirq context. Commenting - such cases is a must, of course! And the jury is still out on - whether the increased speed is worth it. +7. As of v4.20, a given kernel implements only one RCU flavor, which + is RCU-sched for PREEMPTION=n and RCU-preempt for PREEMPTION=y. + If the updater uses call_rcu() or synchronize_rcu(), then + the corresponding readers may use: (1) rcu_read_lock() and + rcu_read_unlock(), (2) any pair of primitives that disables + and re-enables softirq, for example, rcu_read_lock_bh() and + rcu_read_unlock_bh(), or (3) any pair of primitives that disables + and re-enables preemption, for example, rcu_read_lock_sched() and + rcu_read_unlock_sched(). If the updater uses synchronize_srcu() + or call_srcu(), then the corresponding readers must use + srcu_read_lock() and srcu_read_unlock(), and with the same + srcu_struct. The rules for the expedited RCU grace-period-wait + primitives are the same as for their non-expedited counterparts. + + If the updater uses call_rcu_tasks() or synchronize_rcu_tasks(), + then the readers must refrain from executing voluntary + context switches, that is, from blocking. If the updater uses + call_rcu_tasks_trace() or synchronize_rcu_tasks_trace(), then + the corresponding readers must use rcu_read_lock_trace() and + rcu_read_unlock_trace(). If an updater uses call_rcu_tasks_rude() + or synchronize_rcu_tasks_rude(), then the corresponding readers + must use anything that disables interrupts. + + Mixing things up will result in confusion and broken kernels, and + has even resulted in an exploitable security issue. Therefore, + when using non-obvious pairs of primitives, commenting is of + course a must. 8. Although synchronize_rcu() is slower than is call_rcu(), it usually results in simpler code. So, unless update performance is -- cgit v1.2.3 From e74c74f9e51deb725e72d129084ba8252d47222d Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Toke=20H=C3=B8iland-J=C3=B8rgensen?= Date: Thu, 24 Jun 2021 18:05:53 +0200 Subject: doc: Give XDP as example of non-obvious RCU reader/updater pairing MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit This commit gives an example of non-obvious RCU reader/updater pairing in the guise of the XDP feature in networking, which calls BPF programs from network-driver NAPI (softirq) context. Signed-off-by: Paul E. McKenney Signed-off-by: Toke Høiland-Jørgensen Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20210624160609.292325-4-toke@redhat.com --- Documentation/RCU/checklist.rst | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/RCU/checklist.rst b/Documentation/RCU/checklist.rst index 07f6cb8f674d..01cc21f17f7b 100644 --- a/Documentation/RCU/checklist.rst +++ b/Documentation/RCU/checklist.rst @@ -236,8 +236,15 @@ over a rather long period of time, but improvements are always welcome! Mixing things up will result in confusion and broken kernels, and has even resulted in an exploitable security issue. Therefore, - when using non-obvious pairs of primitives, commenting is of - course a must. + when using non-obvious pairs of primitives, commenting is + of course a must. One example of non-obvious pairing is + the XDP feature in networking, which calls BPF programs from + network-driver NAPI (softirq) context. BPF relies heavily on RCU + protection for its data structures, but because the BPF program + invocation happens entirely within a single local_bh_disable() + section in a NAPI poll cycle, this usage is safe. The reason + that this usage is safe is that readers can use anything that + disables BH when updaters use call_rcu() or synchronize_rcu(). 8. Although synchronize_rcu() is slower than is call_rcu(), it usually results in simpler code. So, unless update performance is -- cgit v1.2.3 From f8c63088a98bac8926cb40ecf46ebd71dc1232c4 Mon Sep 17 00:00:00 2001 From: Steen Hegelund Date: Thu, 24 Jun 2021 09:07:49 +0200 Subject: dt-bindings: net: sparx5: Add sparx5-switch bindings Document the Sparx5 switch device driver bindings Signed-off-by: Steen Hegelund Signed-off-by: Lars Povlsen Signed-off-by: Bjarni Jonasson Reviewed-by: Rob Herring Signed-off-by: David S. Miller --- .../bindings/net/microchip,sparx5-switch.yaml | 226 +++++++++++++++++++++ 1 file changed, 226 insertions(+) create mode 100644 Documentation/devicetree/bindings/net/microchip,sparx5-switch.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/microchip,sparx5-switch.yaml b/Documentation/devicetree/bindings/net/microchip,sparx5-switch.yaml new file mode 100644 index 000000000000..347b912a46bb --- /dev/null +++ b/Documentation/devicetree/bindings/net/microchip,sparx5-switch.yaml @@ -0,0 +1,226 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/microchip,sparx5-switch.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Microchip Sparx5 Ethernet switch controller + +maintainers: + - Steen Hegelund + - Lars Povlsen + +description: | + The SparX-5 Enterprise Ethernet switch family provides a rich set of + Enterprise switching features such as advanced TCAM-based VLAN and + QoS processing enabling delivery of differentiated services, and + security through TCAM-based frame processing using versatile content + aware processor (VCAP). + + IPv4/IPv6 Layer 3 (L3) unicast and multicast routing is supported + with up to 18K IPv4/9K IPv6 unicast LPM entries and up to 9K IPv4/3K + IPv6 (S,G) multicast groups. + + L3 security features include source guard and reverse path + forwarding (uRPF) tasks. Additional L3 features include VRF-Lite and + IP tunnels (IP over GRE/IP). + + The SparX-5 switch family targets managed Layer 2 and Layer 3 + equipment in SMB, SME, and Enterprise where high port count + 1G/2.5G/5G/10G switching with 10G/25G aggregation links is required. + +properties: + $nodename: + pattern: "^switch@[0-9a-f]+$" + + compatible: + const: microchip,sparx5-switch + + reg: + items: + - description: cpu target + - description: devices target + - description: general control block target + + reg-names: + items: + - const: cpu + - const: devices + - const: gcb + + interrupts: + minItems: 1 + items: + - description: register based extraction + - description: frame dma based extraction + + interrupt-names: + minItems: 1 + items: + - const: xtr + - const: fdma + + resets: + items: + - description: Reset controller used for switch core reset (soft reset) + + reset-names: + items: + - const: switch + + mac-address: true + + ethernet-ports: + type: object + patternProperties: + "^port@[0-9a-f]+$": + type: object + + properties: + '#address-cells': + const: 1 + '#size-cells': + const: 0 + + reg: + description: Switch port number + + phys: + maxItems: 1 + description: + phandle of a Ethernet SerDes PHY. This defines which SerDes + instance will handle the Ethernet traffic. + + phy-mode: + description: + This specifies the interface used by the Ethernet SerDes towards + the PHY or SFP. + + microchip,bandwidth: + description: Specifies bandwidth in Mbit/s allocated to the port. + $ref: "/schemas/types.yaml#/definitions/uint32" + maximum: 25000 + + phy-handle: + description: + phandle of a Ethernet PHY. This is optional and if provided it + points to the cuPHY used by the Ethernet SerDes. + + sfp: + description: + phandle of an SFP. This is optional and used when not specifying + a cuPHY. It points to the SFP node that describes the SFP used by + the Ethernet SerDes. + + managed: true + + microchip,sd-sgpio: + description: + Index of the ports Signal Detect SGPIO in the set of 384 SGPIOs + This is optional, and only needed if the default used index is + is not correct. + $ref: "/schemas/types.yaml#/definitions/uint32" + minimum: 0 + maximum: 383 + + required: + - reg + - phys + - phy-mode + - microchip,bandwidth + + oneOf: + - required: + - phy-handle + - required: + - sfp + - managed + +required: + - compatible + - reg + - reg-names + - interrupts + - interrupt-names + - resets + - reset-names + - ethernet-ports + +additionalProperties: false + +examples: + - | + #include + switch: switch@600000000 { + compatible = "microchip,sparx5-switch"; + reg = <0 0x401000>, + <0x10004000 0x7fc000>, + <0x11010000 0xaf0000>; + reg-names = "cpu", "devices", "gcb"; + interrupts = ; + interrupt-names = "xtr"; + resets = <&reset 0>; + reset-names = "switch"; + ethernet-ports { + #address-cells = <1>; + #size-cells = <0>; + + port0: port@0 { + reg = <0>; + microchip,bandwidth = <1000>; + phys = <&serdes 13>; + phy-handle = <&phy0>; + phy-mode = "qsgmii"; + }; + /* ... */ + /* Then the 25G interfaces */ + port60: port@60 { + reg = <60>; + microchip,bandwidth = <25000>; + phys = <&serdes 29>; + phy-mode = "10gbase-r"; + sfp = <&sfp_eth60>; + managed = "in-band-status"; + microchip,sd-sgpio = <365>; + }; + port61: port@61 { + reg = <61>; + microchip,bandwidth = <25000>; + phys = <&serdes 30>; + phy-mode = "10gbase-r"; + sfp = <&sfp_eth61>; + managed = "in-band-status"; + microchip,sd-sgpio = <369>; + }; + port62: port@62 { + reg = <62>; + microchip,bandwidth = <25000>; + phys = <&serdes 31>; + phy-mode = "10gbase-r"; + sfp = <&sfp_eth62>; + managed = "in-band-status"; + microchip,sd-sgpio = <373>; + }; + port63: port@63 { + reg = <63>; + microchip,bandwidth = <25000>; + phys = <&serdes 32>; + phy-mode = "10gbase-r"; + sfp = <&sfp_eth63>; + managed = "in-band-status"; + microchip,sd-sgpio = <377>; + }; + /* Finally the Management interface */ + port64: port@64 { + reg = <64>; + microchip,bandwidth = <1000>; + phys = <&serdes 0>; + phy-handle = <&phy64>; + phy-mode = "sgmii"; + mac-address = [ 00 00 00 01 02 03 ]; + }; + }; + }; + +... +# vim: set ts=2 sw=2 sts=2 tw=80 et cc=80 ft=yaml : -- cgit v1.2.3 From 8fa826b7344d6752f5cfd72380d9fe7bd8c6b928 Mon Sep 17 00:00:00 2001 From: Daniel Bristot de Oliveira Date: Tue, 22 Jun 2021 16:42:20 +0200 Subject: trace/hwlat: Implement the mode config option Provides the "mode" config to the hardware latency detector. hwlatd has two different operation modes. The default mode is the "round-robin" one, in which a single hwlatd thread runs, migrating among the allowed CPUs in a "round-robin" fashion. This is the current behavior. The "none" sets the allowed cpumask for a single hwlatd thread at the startup, but skips the round-robin, letting the scheduler handle the migration. In preparation to the per-cpu mode. Link: https://lkml.kernel.org/r/f3b1271262aa030c680e26615c1b9b2d71e55e92.1624372313.git.bristot@redhat.com Cc: Phil Auld Cc: Sebastian Andrzej Siewior Cc: Kate Carcia Cc: Jonathan Corbet Cc: Ingo Molnar Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: Alexandre Chartre Cc: Clark Willaims Cc: John Kacur Cc: Juri Lelli Cc: Borislav Petkov Cc: "H. Peter Anvin" Cc: x86@kernel.org Cc: linux-doc@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Daniel Bristot de Oliveira Signed-off-by: Steven Rostedt (VMware) --- Documentation/trace/hwlat_detector.rst | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/trace/hwlat_detector.rst b/Documentation/trace/hwlat_detector.rst index 5739349649c8..4d952df0586a 100644 --- a/Documentation/trace/hwlat_detector.rst +++ b/Documentation/trace/hwlat_detector.rst @@ -76,8 +76,12 @@ in /sys/kernel/tracing: - tracing_cpumask - the CPUs to move the hwlat thread across - hwlat_detector/width - specified amount of time to spin within window (usecs) - hwlat_detector/window - amount of time between (width) runs (usecs) + - hwlat_detector/mode - the thread mode -The hwlat detector's kernel thread will migrate across each CPU specified in -tracing_cpumask between each window. To limit the migration, either modify -tracing_cpumask, or modify the hwlat kernel thread (named [hwlatd]) CPU -affinity directly, and the migration will stop. +By default, the hwlat detector's kernel thread will migrate across each CPU +specified in cpumask at the beginning of a new window, in a round-robin +fashion. This behavior can be changed by changing the thread mode, +the available options are: + + - none: do not force migration + - round-robin: migrate across each CPU specified in cpumask [default] -- cgit v1.2.3 From b7705ba6d0c4aac52688a96884bd6fde91f3b2fb Mon Sep 17 00:00:00 2001 From: Sudeep Holla Date: Thu, 17 Jun 2021 21:53:17 +0100 Subject: dt-bindings: interrupt-controller: Convert ARM VIC to json-schema Convert the ARM VIC binding document to DT schema format using json-schema. Cc: Rob Herring Reviewed-by: Linus Walleij Signed-off-by: Sudeep Holla Link: https://lore.kernel.org/r/20210617205317.3060163-1-sudeep.holla@arm.com Signed-off-by: Rob Herring --- .../bindings/interrupt-controller/arm,vic.txt | 41 ----------- .../bindings/interrupt-controller/arm,vic.yaml | 81 ++++++++++++++++++++++ 2 files changed, 81 insertions(+), 41 deletions(-) delete mode 100644 Documentation/devicetree/bindings/interrupt-controller/arm,vic.txt create mode 100644 Documentation/devicetree/bindings/interrupt-controller/arm,vic.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/interrupt-controller/arm,vic.txt b/Documentation/devicetree/bindings/interrupt-controller/arm,vic.txt deleted file mode 100644 index dd527216c5fb..000000000000 --- a/Documentation/devicetree/bindings/interrupt-controller/arm,vic.txt +++ /dev/null @@ -1,41 +0,0 @@ -* ARM Vectored Interrupt Controller - -One or more Vectored Interrupt Controllers (VIC's) can be connected in an ARM -system for interrupt routing. For multiple controllers they can either be -nested or have the outputs wire-OR'd together. - -Required properties: - -- compatible : should be one of - "arm,pl190-vic" - "arm,pl192-vic" -- interrupt-controller : Identifies the node as an interrupt controller -- #interrupt-cells : The number of cells to define the interrupts. Must be 1 as - the VIC has no configuration options for interrupt sources. The cell is a u32 - and defines the interrupt number. -- reg : The register bank for the VIC. - -Optional properties: - -- interrupts : Interrupt source for parent controllers if the VIC is nested. -- valid-mask : A one cell big bit mask of valid interrupt sources. Each bit - represents single interrupt source, starting from source 0 at LSb and ending - at source 31 at MSb. A bit that is set means that the source is wired and - clear means otherwise. If unspecified, defaults to all valid. -- valid-wakeup-mask : A one cell big bit mask of interrupt sources that can be - configured as wake up source for the system. Order of bits is the same as for - valid-mask property. A set bit means that this interrupt source can be - configured as a wake up source for the system. If unspecied, defaults to all - interrupt sources configurable as wake up sources. - -Example: - - vic0: interrupt-controller@60000 { - compatible = "arm,pl192-vic"; - interrupt-controller; - #interrupt-cells = <1>; - reg = <0x60000 0x1000>; - - valid-mask = <0xffffff7f>; - valid-wakeup-mask = <0x0000ff7f>; - }; diff --git a/Documentation/devicetree/bindings/interrupt-controller/arm,vic.yaml b/Documentation/devicetree/bindings/interrupt-controller/arm,vic.yaml new file mode 100644 index 000000000000..0075e72fe8c1 --- /dev/null +++ b/Documentation/devicetree/bindings/interrupt-controller/arm,vic.yaml @@ -0,0 +1,81 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/interrupt-controller/arm,vic.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: ARM Vectored Interrupt Controller + +maintainers: + - Rob Herring + +description: |+ + One or more Vectored Interrupt Controllers (VIC's) can be connected in an + ARM system for interrupt routing. For multiple controllers they can either + be nested or have the outputs wire-OR'd together. + +allOf: + - $ref: /schemas/interrupt-controller.yaml# + +properties: + compatible: + enum: + - arm,pl190-vic + - arm,pl192-vic + - arm,versatile-vic + + interrupt-controller: true + + "#interrupt-cells": + const: 1 + description: + The number of cells to define the interrupts. It must be 1 as the + VIC has no configuration options for interrupt sources. The single + cell defines the interrupt number. + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + valid-mask: + description: + A one cell big bit mask of valid interrupt sources. Each bit + represents single interrupt source, starting from source 0 at + LSb and ending at source 31 at MSb. A bit that is set means + that the source is wired and clear means otherwise. If unspecified, + defaults to all valid. + $ref: /schemas/types.yaml#/definitions/uint32 + + valid-wakeup-mask: + description: + A one cell big bit mask of interrupt sources that can be configured + as wake up source for the system. Order of bits is the same as for + valid-mask property. A set bit means that this interrupt source + can be configured as a wake up source for the system. If unspecied, + defaults to all interrupt sources configurable as wake up sources. + $ref: /schemas/types.yaml#/definitions/uint32 + +required: + - compatible + - reg + - interrupt-controller + - "#interrupt-cells" + +additionalProperties: false + +examples: + - | + // PL192 VIC + vic0: interrupt-controller@60000 { + compatible = "arm,pl192-vic"; + interrupt-controller; + #interrupt-cells = <1>; + reg = <0x60000 0x1000>; + + valid-mask = <0xffffff7f>; + valid-wakeup-mask = <0x0000ff7f>; + }; + +... -- cgit v1.2.3 From c6a7ed77ee6334f3a85a0f3db74ca80101e25304 Mon Sep 17 00:00:00 2001 From: Bailey Forrest Date: Thu, 24 Jun 2021 11:06:17 -0700 Subject: gve: Update GVE documentation to describe DQO DQO is a new descriptor format for our next generation virtual NIC. Signed-off-by: Bailey Forrest Reviewed-by: Willem de Bruijn Reviewed-by: Catherine Sullivan Signed-off-by: David S. Miller --- .../device_drivers/ethernet/google/gve.rst | 53 ++++++++++++++++++++-- 1 file changed, 48 insertions(+), 5 deletions(-) (limited to 'Documentation') diff --git a/Documentation/networking/device_drivers/ethernet/google/gve.rst b/Documentation/networking/device_drivers/ethernet/google/gve.rst index 793693cef6e3..6d73ee78f3d7 100644 --- a/Documentation/networking/device_drivers/ethernet/google/gve.rst +++ b/Documentation/networking/device_drivers/ethernet/google/gve.rst @@ -47,13 +47,24 @@ The driver interacts with the device in the following ways: - Transmit and Receive Queues - See description below +Descriptor Formats +------------------ +GVE supports two descriptor formats: GQI and DQO. These two formats have +entirely different descriptors, which will be described below. + Registers --------- -All registers are MMIO and big endian. +All registers are MMIO. The registers are used for initializing and configuring the device as well as querying device status in response to management interrupts. +Endianness +---------- +- Admin Queue messages and registers are all Big Endian. +- GQI descriptors and datapath registers are Big Endian. +- DQO descriptors and datapath registers are Little Endian. + Admin Queue (AQ) ---------------- The Admin Queue is a PAGE_SIZE memory block, treated as an array of AQ @@ -97,10 +108,10 @@ the queues associated with that interrupt. The handler for these irqs schedule the napi for that block to run and poll the queues. -Traffic Queues --------------- -gVNIC's queues are composed of a descriptor ring and a buffer and are -assigned to a notification block. +GQI Traffic Queues +------------------ +GQI queues are composed of a descriptor ring and a buffer and are assigned to a +notification block. The descriptor rings are power-of-two-sized ring buffers consisting of fixed-size descriptors. They advance their head pointer using a __be32 @@ -121,3 +132,35 @@ Receive The buffers for receive rings are put into a data ring that is the same length as the descriptor ring and the head and tail pointers advance over the rings together. + +DQO Traffic Queues +------------------ +- Every TX and RX queue is assigned a notification block. + +- TX and RX buffers queues, which send descriptors to the device, use MMIO + doorbells to notify the device of new descriptors. + +- RX and TX completion queues, which receive descriptors from the device, use a + "generation bit" to know when a descriptor was populated by the device. The + driver initializes all bits with the "current generation". The device will + populate received descriptors with the "next generation" which is inverted + from the current generation. When the ring wraps, the current/next generation + are swapped. + +- It's the driver's responsibility to ensure that the RX and TX completion + queues are not overrun. This can be accomplished by limiting the number of + descriptors posted to HW. + +- TX packets have a 16 bit completion_tag and RX buffers have a 16 bit + buffer_id. These will be returned on the TX completion and RX queues + respectively to let the driver know which packet/buffer was completed. + +Transmit +~~~~~~~~ +A packet's buffers are DMA mapped for the device to access before transmission. +After the packet was successfully transmitted, the buffers are unmapped. + +Receive +~~~~~~~ +The driver posts fixed sized buffers to HW on the RX buffer queue. The packet +received on the associated RX queue may span multiple descriptors. -- cgit v1.2.3 From c9d511dc84610498f370bbfff16e1c194b93c8d8 Mon Sep 17 00:00:00 2001 From: Richard Zhu Date: Fri, 4 Jun 2021 09:47:48 +0800 Subject: dt-bindings: imx6q-pcie: Add "vph-supply" for PHY supply voltage The i.MX8MQ PCIe PHY can use either a 1.8V or a 3.3V power supply. Add a "vph-supply" property to indicate which regulator supplies power for the PHY. Link: https://lore.kernel.org/r/1622771269-13844-2-git-send-email-hongxing.zhu@nxp.com Signed-off-by: Richard Zhu Signed-off-by: Lorenzo Pieralisi Signed-off-by: Bjorn Helgaas Reviewed-by: Lucas Stach Acked-by: Rob Herring --- Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt | 3 +++ 1 file changed, 3 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt index de4b2baf91e8..d8971ab99274 100644 --- a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt +++ b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt @@ -38,6 +38,9 @@ Optional properties: The regulator will be enabled when initializing the PCIe host and disabled either as part of the init process or when shutting down the host. +- vph-supply: Should specify the regulator in charge of VPH one of the three + PCIe PHY powers. This regulator can be supplied by both 1.8v and 3.3v voltage + supplies. Additional required properties for imx6sx-pcie: - clock names: Must include the following additional entries: -- cgit v1.2.3 From 44531076338fc9d9556685d3e7efc2526185760d Mon Sep 17 00:00:00 2001 From: Vladimir Oltean Date: Thu, 24 Jun 2021 17:55:23 +0300 Subject: Documentation: net: dsa: add details about SJA1110 Denote that the new switch generation is supported, detail its pin strapping options (with differences compared to SJA1105) and explain how MDIO access to the internal 100base-T1 and 100base-TX PHYs is performed. Signed-off-by: Vladimir Oltean Signed-off-by: David S. Miller --- Documentation/networking/dsa/sja1105.rst | 61 +++++++++++++++++++++++++++++--- 1 file changed, 57 insertions(+), 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/networking/dsa/sja1105.rst b/Documentation/networking/dsa/sja1105.rst index 7395a33baaf9..da4057ba37f1 100644 --- a/Documentation/networking/dsa/sja1105.rst +++ b/Documentation/networking/dsa/sja1105.rst @@ -5,7 +5,7 @@ NXP SJA1105 switch driver Overview ======== -The NXP SJA1105 is a family of 6 devices: +The NXP SJA1105 is a family of 10 SPI-managed automotive switches: - SJA1105E: First generation, no TTEthernet - SJA1105T: First generation, TTEthernet @@ -13,9 +13,11 @@ The NXP SJA1105 is a family of 6 devices: - SJA1105Q: Second generation, TTEthernet, no SGMII - SJA1105R: Second generation, no TTEthernet, SGMII - SJA1105S: Second generation, TTEthernet, SGMII - -These are SPI-managed automotive switches, with all ports being gigabit -capable, and supporting MII/RMII/RGMII and optionally SGMII on one port. +- SJA1110A: Third generation, TTEthernet, SGMII, integrated 100base-T1 and + 100base-TX PHYs +- SJA1110B: Third generation, TTEthernet, SGMII, 100base-T1, 100base-TX +- SJA1110C: Third generation, TTEthernet, SGMII, 100base-T1, 100base-TX +- SJA1110D: Third generation, TTEthernet, SGMII, 100base-T1 Being automotive parts, their configuration interface is geared towards set-and-forget use, with minimal dynamic interaction at runtime. They @@ -579,3 +581,54 @@ A board would need to hook up the PHYs connected to the switch to any other MDIO bus available to Linux within the system (e.g. to the DSA master's MDIO bus). Link state management then works by the driver manually keeping in sync (over SPI commands) the MAC link speed with the settings negotiated by the PHY. + +By comparison, the SJA1110 supports an MDIO slave access point over which its +internal 100base-T1 PHYs can be accessed from the host. This is, however, not +used by the driver, instead the internal 100base-T1 and 100base-TX PHYs are +accessed through SPI commands, modeled in Linux as virtual MDIO buses. + +The microcontroller attached to the SJA1110 port 0 also has an MDIO controller +operating in master mode, however the driver does not support this either, +since the microcontroller gets disabled when the Linux driver operates. +Discrete PHYs connected to the switch ports should have their MDIO interface +attached to an MDIO controller from the host system and not to the switch, +similar to SJA1105. + +Port compatibility matrix +------------------------- + +The SJA1105 port compatibility matrix is: + +===== ============== ============== ============== +Port SJA1105E/T SJA1105P/Q SJA1105R/S +===== ============== ============== ============== +0 xMII xMII xMII +1 xMII xMII xMII +2 xMII xMII xMII +3 xMII xMII xMII +4 xMII xMII SGMII +===== ============== ============== ============== + + +The SJA1110 port compatibility matrix is: + +===== ============== ============== ============== ============== +Port SJA1110A SJA1110B SJA1110C SJA1110D +===== ============== ============== ============== ============== +0 RevMII (uC) RevMII (uC) RevMII (uC) RevMII (uC) +1 100base-TX 100base-TX 100base-TX + or SGMII SGMII +2 xMII xMII xMII xMII + or SGMII or SGMII +3 xMII xMII xMII + or SGMII or SGMII SGMII + or 2500base-X or 2500base-X or 2500base-X +4 SGMII SGMII SGMII SGMII + or 2500base-X or 2500base-X or 2500base-X or 2500base-X +5 100base-T1 100base-T1 100base-T1 100base-T1 +6 100base-T1 100base-T1 100base-T1 100base-T1 +7 100base-T1 100base-T1 100base-T1 100base-T1 +8 100base-T1 100base-T1 n/a n/a +9 100base-T1 100base-T1 n/a n/a +10 100base-T1 n/a n/a n/a +===== ============== ============== ============== ============== -- cgit v1.2.3 From fea1d5b17f821b78abbdadb9cb6f28fe433b635e Mon Sep 17 00:00:00 2001 From: Xin Long Date: Thu, 24 Jun 2021 11:48:09 -0400 Subject: sctp: send the next probe immediately once the last one is acked These is no need to wait for 'interval' period for the next probe if the last probe is already acked in search state. The 'interval' period waiting should be only for probe failure timeout and the current pmtu check when it's in search complete state. This change will shorten the probe time a lot in search state, and also fix the document accordingly. Signed-off-by: Xin Long Signed-off-by: David S. Miller --- Documentation/networking/ip-sysctl.rst | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/networking/ip-sysctl.rst b/Documentation/networking/ip-sysctl.rst index 8bff728b3a1e..b3fa522e4cd9 100644 --- a/Documentation/networking/ip-sysctl.rst +++ b/Documentation/networking/ip-sysctl.rst @@ -2835,10 +2835,14 @@ encap_port - INTEGER Default: 0 plpmtud_probe_interval - INTEGER - The time interval (in milliseconds) for sending PLPMTUD probe chunks. - These chunks are sent at the specified interval with a variable size - to probe the mtu of a given path between 2 endpoints. PLPMTUD will - be disabled when 0 is set, and other values for it must be >= 5000. + The time interval (in milliseconds) for the PLPMTUD probe timer, + which is configured to expire after this period to receive an + acknowledgment to a probe packet. This is also the time interval + between the probes for the current pmtu when the probe search + is done. + + PLPMTUD will be disabled when 0 is set, and other values for it + must be >= 5000. Default: 0 -- cgit v1.2.3 From b05c8922c98de489f52e5d327837857e35d25422 Mon Sep 17 00:00:00 2001 From: "Kewei.Xu" Date: Tue, 8 Jun 2021 11:16:38 +0800 Subject: dt-bindings: i2c: update bindings for MT8195 SoC Add a DT binding documentation for the MT8195 soc. Signed-off-by: Kewei.Xu Reviewed-by: Matthias Brugger Acked-by: Rob Herring Signed-off-by: Wolfram Sang --- Documentation/devicetree/bindings/i2c/i2c-mt65xx.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/i2c/i2c-mt65xx.txt b/Documentation/devicetree/bindings/i2c/i2c-mt65xx.txt index 2c45647e9f0b..5ea216ae7084 100644 --- a/Documentation/devicetree/bindings/i2c/i2c-mt65xx.txt +++ b/Documentation/devicetree/bindings/i2c/i2c-mt65xx.txt @@ -15,6 +15,7 @@ Required properties: "mediatek,mt8173-i2c": for MediaTek MT8173 "mediatek,mt8183-i2c": for MediaTek MT8183 "mediatek,mt8192-i2c": for MediaTek MT8192 + "mediatek,mt8195-i2c", "mediatek,mt8192-i2c": for MediaTek MT8195 "mediatek,mt8516-i2c", "mediatek,mt2712-i2c": for MediaTek MT8516 - reg: physical base address of the controller and dma base, length of memory mapped region. -- cgit v1.2.3 From b14e889c31b5beaab74954efb3672dac3049995e Mon Sep 17 00:00:00 2001 From: Nobuhiro Iwamatsu Date: Mon, 14 Jun 2021 05:50:22 +0900 Subject: dt-bindings: rtc: zynqmp: convert bindings to YAML Convert Real Time Clock for Xilinx Zynq MPSoC SoC bindings documentation to YAML schemas. And this renamed the file to compatible string of DT. Signed-off-by: Nobuhiro Iwamatsu Link: https://lore.kernel.org/r/20210613205022.292575-1-iwamatsu@nigauri.org Signed-off-by: Rob Herring --- .../devicetree/bindings/rtc/xlnx,zynqmp-rtc.yaml | 65 ++++++++++++++++++++++ Documentation/devicetree/bindings/rtc/xlnx-rtc.txt | 25 --------- 2 files changed, 65 insertions(+), 25 deletions(-) create mode 100644 Documentation/devicetree/bindings/rtc/xlnx,zynqmp-rtc.yaml delete mode 100644 Documentation/devicetree/bindings/rtc/xlnx-rtc.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/rtc/xlnx,zynqmp-rtc.yaml b/Documentation/devicetree/bindings/rtc/xlnx,zynqmp-rtc.yaml new file mode 100644 index 000000000000..bdb72d3ddf2a --- /dev/null +++ b/Documentation/devicetree/bindings/rtc/xlnx,zynqmp-rtc.yaml @@ -0,0 +1,65 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/rtc/xlnx,zynqmp-rtc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Xilinx Zynq Ultrascale+ MPSoC Real Time Clock + +description: + RTC controller for the Xilinx Zynq MPSoC Real Time Clock. + The RTC controller has separate IRQ lines for seconds and alarm. + +maintainers: + - Michal Simek + +allOf: + - $ref: rtc.yaml# + +properties: + compatible: + const: xlnx,zynqmp-rtc + + reg: + maxItems: 1 + + interrupts: + minItems: 2 + + interrupt-names: + items: + - const: alarm + - const: sec + + calibration: + description: | + calibration value for 1 sec period which will + be programmed directly to calibration register. + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0x1 + maximum: 0x1FFFFF + default: 0x198233 + +required: + - compatible + - reg + - interrupts + - interrupt-names + +additionalProperties: false + +examples: + - | + soc { + #address-cells = <2>; + #size-cells = <2>; + + rtc: rtc@ffa60000 { + compatible = "xlnx,zynqmp-rtc"; + reg = <0x0 0xffa60000 0x0 0x100>; + interrupt-parent = <&gic>; + interrupts = <0 26 4>, <0 27 4>; + interrupt-names = "alarm", "sec"; + calibration = <0x198233>; + }; + }; diff --git a/Documentation/devicetree/bindings/rtc/xlnx-rtc.txt b/Documentation/devicetree/bindings/rtc/xlnx-rtc.txt deleted file mode 100644 index 0df6f016b1b7..000000000000 --- a/Documentation/devicetree/bindings/rtc/xlnx-rtc.txt +++ /dev/null @@ -1,25 +0,0 @@ -* Xilinx Zynq Ultrascale+ MPSoC Real Time Clock - -RTC controller for the Xilinx Zynq MPSoC Real Time Clock -Separate IRQ lines for seconds and alarm - -Required properties: -- compatible: Should be "xlnx,zynqmp-rtc" -- reg: Physical base address of the controller and length - of memory mapped region. -- interrupts: IRQ lines for the RTC. -- interrupt-names: interrupt line names eg. "sec" "alarm" - -Optional: -- calibration: calibration value for 1 sec period which will - be programmed directly to calibration register - -Example: -rtc: rtc@ffa60000 { - compatible = "xlnx,zynqmp-rtc"; - reg = <0x0 0xffa60000 0x100>; - interrupt-parent = <&gic>; - interrupts = <0 26 4>, <0 27 4>; - interrupt-names = "alarm", "sec"; - calibration = <0x198233>; -}; -- cgit v1.2.3 From 1e32084cb535024ffcd5f1846677cf7f630036ab Mon Sep 17 00:00:00 2001 From: Nobuhiro Iwamatsu Date: Mon, 14 Jun 2021 06:28:56 +0900 Subject: dt-bindings: fpga: zynq: convert bindings to YAML Convert FPGA for Xilinx Zynq SoC bindings documentation to YAML. Signed-off-by: Nobuhiro Iwamatsu Link: https://lore.kernel.org/r/20210613212856.296153-1-iwamatsu@nigauri.org Signed-off-by: Rob Herring --- .../bindings/fpga/xilinx-zynq-fpga-mgr.txt | 19 -------- .../bindings/fpga/xilinx-zynq-fpga-mgr.yaml | 52 ++++++++++++++++++++++ 2 files changed, 52 insertions(+), 19 deletions(-) delete mode 100644 Documentation/devicetree/bindings/fpga/xilinx-zynq-fpga-mgr.txt create mode 100644 Documentation/devicetree/bindings/fpga/xilinx-zynq-fpga-mgr.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/fpga/xilinx-zynq-fpga-mgr.txt b/Documentation/devicetree/bindings/fpga/xilinx-zynq-fpga-mgr.txt deleted file mode 100644 index 7018aa896835..000000000000 --- a/Documentation/devicetree/bindings/fpga/xilinx-zynq-fpga-mgr.txt +++ /dev/null @@ -1,19 +0,0 @@ -Xilinx Zynq FPGA Manager - -Required properties: -- compatible: should contain "xlnx,zynq-devcfg-1.0" -- reg: base address and size for memory mapped io -- interrupts: interrupt for the FPGA manager device -- clocks: phandle for clocks required operation -- clock-names: name for the clock, should be "ref_clk" -- syscon: phandle for access to SLCR registers - -Example: - devcfg: devcfg@f8007000 { - compatible = "xlnx,zynq-devcfg-1.0"; - reg = <0xf8007000 0x100>; - interrupts = <0 8 4>; - clocks = <&clkc 12>; - clock-names = "ref_clk"; - syscon = <&slcr>; - }; diff --git a/Documentation/devicetree/bindings/fpga/xilinx-zynq-fpga-mgr.yaml b/Documentation/devicetree/bindings/fpga/xilinx-zynq-fpga-mgr.yaml new file mode 100644 index 000000000000..29daca4be47f --- /dev/null +++ b/Documentation/devicetree/bindings/fpga/xilinx-zynq-fpga-mgr.yaml @@ -0,0 +1,52 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/fpga/xilinx-zynq-fpga-mgr.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Xilinx Zynq FPGA Manager Device Tree Bindings + +maintainers: + - Michal Simek + +properties: + compatible: + const: xlnx,zynq-devcfg-1.0 + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + + clock-names: + items: + - const: ref_clk + + syscon: + $ref: /schemas/types.yaml#/definitions/phandle + description: + Phandle to syscon block which provide access to SLCR registers + +required: + - compatible + - reg + - clocks + - clock-names + - syscon + +additionalProperties: false + +examples: + - | + devcfg: devcfg@f8007000 { + compatible = "xlnx,zynq-devcfg-1.0"; + reg = <0xf8007000 0x100>; + interrupts = <0 8 4>; + clocks = <&clkc 12>; + clock-names = "ref_clk"; + syscon = <&slcr>; + }; -- cgit v1.2.3 From 180208cedfec5e6aea53a06e954feffc846c34ab Mon Sep 17 00:00:00 2001 From: Geert Uytterhoeven Date: Fri, 11 Jun 2021 14:20:17 +0200 Subject: dt-bindings: crypto: ccree: Convert to json-schema Convert the Arm TrustZone CryptoCell cryptographic engine Device Tree binding documentation to json-schema. Document missing properties. Update the example to match reality. Signed-off-by: Geert Uytterhoeven Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/ab361a862755e281f5fef67b3f678d66ae201781.1623413974.git.geert+renesas@glider.be --- .../devicetree/bindings/crypto/arm,cryptocell.yaml | 53 ++++++++++++++++++++++ .../devicetree/bindings/crypto/arm-cryptocell.txt | 25 ---------- 2 files changed, 53 insertions(+), 25 deletions(-) create mode 100644 Documentation/devicetree/bindings/crypto/arm,cryptocell.yaml delete mode 100644 Documentation/devicetree/bindings/crypto/arm-cryptocell.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/crypto/arm,cryptocell.yaml b/Documentation/devicetree/bindings/crypto/arm,cryptocell.yaml new file mode 100644 index 000000000000..9c97874a6dbd --- /dev/null +++ b/Documentation/devicetree/bindings/crypto/arm,cryptocell.yaml @@ -0,0 +1,53 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/crypto/arm,cryptocell.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Arm TrustZone CryptoCell cryptographic engine + +maintainers: + - Gilad Ben-Yossef + +properties: + compatible: + enum: + - arm,cryptocell-713-ree + - arm,cryptocell-703-ree + - arm,cryptocell-712-ree + - arm,cryptocell-710-ree + - arm,cryptocell-630p-ree + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + + power-domains: + maxItems: 1 + + resets: + maxItems: 1 + + dma-coherent: true + +required: + - compatible + - reg + - interrupts + +additionalProperties: false + +examples: + - | + #include + + arm_cc712: crypto@80000000 { + compatible = "arm,cryptocell-712-ree"; + reg = <0x80000000 0x10000>; + interrupts = ; + }; diff --git a/Documentation/devicetree/bindings/crypto/arm-cryptocell.txt b/Documentation/devicetree/bindings/crypto/arm-cryptocell.txt deleted file mode 100644 index 6130e6eb4af8..000000000000 --- a/Documentation/devicetree/bindings/crypto/arm-cryptocell.txt +++ /dev/null @@ -1,25 +0,0 @@ -Arm TrustZone CryptoCell cryptographic engine - -Required properties: -- compatible: Should be one of - - "arm,cryptocell-713-ree" - "arm,cryptocell-703-ree" - "arm,cryptocell-712-ree" - "arm,cryptocell-710-ree" - "arm,cryptocell-630p-ree" -- reg: Base physical address of the engine and length of memory mapped region. -- interrupts: Interrupt number for the device. - -Optional properties: -- clocks: Reference to the crypto engine clock. -- dma-coherent: Present if dma operations are coherent. - -Examples: - - arm_cc712: crypto@80000000 { - compatible = "arm,cryptocell-712-ree"; - interrupt-parent = <&intc>; - interrupts = < 0 30 4 >; - reg = < 0x80000000 0x10000 >; - - }; -- cgit v1.2.3 From fdc09ddd40645b0e3f245e4512fd4b4c34cde5e5 Mon Sep 17 00:00:00 2001 From: Jing Zhang Date: Fri, 18 Jun 2021 22:27:07 +0000 Subject: KVM: stats: Add documentation for binary statistics interface This new API provides a file descriptor for every VM and VCPU to read KVM statistics data in binary format. It is meant to provide a lightweight, flexible, scalable and efficient lock-free solution for user space telemetry applications to pull the statistics data periodically for large scale systems. The pulling frequency could be as high as a few times per second. The statistics descriptors are defined by KVM in kernel and can be by userspace to discover VM/VCPU statistics during the one-time setup stage. The statistics data itself could be read out by userspace telemetry periodically without any extra parsing or setup effort. There are a few existed interface protocols and definitions, but no one can fulfil all the requirements this interface implemented as below: 1. During high frequency periodic stats reading, there should be no extra efforts except the stats data read itself. 2. Support stats annotation, like type (cumulative, instantaneous, peak, histogram, etc) and unit (counter, time, size, cycles, etc). 3. The stats data reading should be free of lock/synchronization. We don't care about the consistency between all the stats data. All stats data can not be read out at exactly the same time. We really care about the change or trend of the stats data. The lock-free solution is not just for efficiency and scalability, also for the stats data accuracy and usability. For example, in the situation that all the stats data readings are protected by a global lock, if one VCPU died somehow with that lock held, then all stats data reading would be blocked, then we have no way from stats data that which VCPU has died. 4. The stats data reading workload can be handed over to other unprivileged process. Reviewed-by: David Matlack Reviewed-by: Ricardo Koller Reviewed-by: Krish Sadhukhan Reviewed-by: Fuad Tabba Signed-off-by: Jing Zhang Message-Id: <20210618222709.1858088-6-jingzhangos@google.com> Signed-off-by: Paolo Bonzini --- Documentation/virt/kvm/api.rst | 170 +++++++++++++++++++++++++++++++++++++++++ 1 file changed, 170 insertions(+) (limited to 'Documentation') diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst index dd3fe231e435..b87fa32835f2 100644 --- a/Documentation/virt/kvm/api.rst +++ b/Documentation/virt/kvm/api.rst @@ -5081,6 +5081,176 @@ Writes special registers into the vcpu. See KVM_GET_SREGS2 for the data structures. This ioctl (when supported) replaces the KVM_SET_SREGS. +4.133 KVM_GET_STATS_FD +---------------------- + +:Capability: KVM_CAP_STATS_BINARY_FD +:Architectures: all +:Type: vm ioctl, vcpu ioctl +:Parameters: none +:Returns: statistics file descriptor on success, < 0 on error + +Errors: + + ====== ====================================================== + ENOMEM if the fd could not be created due to lack of memory + EMFILE if the number of opened files exceeds the limit + ====== ====================================================== + +The returned file descriptor can be used to read VM/vCPU statistics data in +binary format. The data in the file descriptor consists of four blocks +organized as follows: + ++-------------+ +| Header | ++-------------+ +| id string | ++-------------+ +| Descriptors | ++-------------+ +| Stats Data | ++-------------+ + +Apart from the header starting at offset 0, please be aware that it is +not guaranteed that the four blocks are adjacent or in the above order; +the offsets of the id, descriptors and data blocks are found in the +header. However, all four blocks are aligned to 64 bit offsets in the +file and they do not overlap. + +All blocks except the data block are immutable. Userspace can read them +only one time after retrieving the file descriptor, and then use ``pread`` or +``lseek`` to read the statistics repeatedly. + +All data is in system endianness. + +The format of the header is as follows:: + + struct kvm_stats_header { + __u32 flags; + __u32 name_size; + __u32 num_desc; + __u32 id_offset; + __u32 desc_offset; + __u32 data_offset; + }; + +The ``flags`` field is not used at the moment. It is always read as 0. + +The ``name_size`` field is the size (in byte) of the statistics name string +(including trailing '\0') which is contained in the "id string" block and +appended at the end of every descriptor. + +The ``num_desc`` field is the number of descriptors that are included in the +descriptor block. (The actual number of values in the data block may be +larger, since each descriptor may comprise more than one value). + +The ``id_offset`` field is the offset of the id string from the start of the +file indicated by the file descriptor. It is a multiple of 8. + +The ``desc_offset`` field is the offset of the Descriptors block from the start +of the file indicated by the file descriptor. It is a multiple of 8. + +The ``data_offset`` field is the offset of the Stats Data block from the start +of the file indicated by the file descriptor. It is a multiple of 8. + +The id string block contains a string which identifies the file descriptor on +which KVM_GET_STATS_FD was invoked. The size of the block, including the +trailing ``'\0'``, is indicated by the ``name_size`` field in the header. + +The descriptors block is only needed to be read once for the lifetime of the +file descriptor contains a sequence of ``struct kvm_stats_desc``, each followed +by a string of size ``name_size``. + + #define KVM_STATS_TYPE_SHIFT 0 + #define KVM_STATS_TYPE_MASK (0xF << KVM_STATS_TYPE_SHIFT) + #define KVM_STATS_TYPE_CUMULATIVE (0x0 << KVM_STATS_TYPE_SHIFT) + #define KVM_STATS_TYPE_INSTANT (0x1 << KVM_STATS_TYPE_SHIFT) + #define KVM_STATS_TYPE_PEAK (0x2 << KVM_STATS_TYPE_SHIFT) + + #define KVM_STATS_UNIT_SHIFT 4 + #define KVM_STATS_UNIT_MASK (0xF << KVM_STATS_UNIT_SHIFT) + #define KVM_STATS_UNIT_NONE (0x0 << KVM_STATS_UNIT_SHIFT) + #define KVM_STATS_UNIT_BYTES (0x1 << KVM_STATS_UNIT_SHIFT) + #define KVM_STATS_UNIT_SECONDS (0x2 << KVM_STATS_UNIT_SHIFT) + #define KVM_STATS_UNIT_CYCLES (0x3 << KVM_STATS_UNIT_SHIFT) + + #define KVM_STATS_BASE_SHIFT 8 + #define KVM_STATS_BASE_MASK (0xF << KVM_STATS_BASE_SHIFT) + #define KVM_STATS_BASE_POW10 (0x0 << KVM_STATS_BASE_SHIFT) + #define KVM_STATS_BASE_POW2 (0x1 << KVM_STATS_BASE_SHIFT) + + struct kvm_stats_desc { + __u32 flags; + __s16 exponent; + __u16 size; + __u32 offset; + __u32 unused; + char name[]; + }; + +The ``flags`` field contains the type and unit of the statistics data described +by this descriptor. Its endianness is CPU native. +The following flags are supported: + +Bits 0-3 of ``flags`` encode the type: + * ``KVM_STATS_TYPE_CUMULATIVE`` + The statistics data is cumulative. The value of data can only be increased. + Most of the counters used in KVM are of this type. + The corresponding ``size`` field for this type is always 1. + All cumulative statistics data are read/write. + * ``KVM_STATS_TYPE_INSTANT`` + The statistics data is instantaneous. Its value can be increased or + decreased. This type is usually used as a measurement of some resources, + like the number of dirty pages, the number of large pages, etc. + All instant statistics are read only. + The corresponding ``size`` field for this type is always 1. + * ``KVM_STATS_TYPE_PEAK`` + The statistics data is peak. The value of data can only be increased, and + represents a peak value for a measurement, for example the maximum number + of items in a hash table bucket, the longest time waited and so on. + The corresponding ``size`` field for this type is always 1. + +Bits 4-7 of ``flags`` encode the unit: + * ``KVM_STATS_UNIT_NONE`` + There is no unit for the value of statistics data. This usually means that + the value is a simple counter of an event. + * ``KVM_STATS_UNIT_BYTES`` + It indicates that the statistics data is used to measure memory size, in the + unit of Byte, KiByte, MiByte, GiByte, etc. The unit of the data is + determined by the ``exponent`` field in the descriptor. + * ``KVM_STATS_UNIT_SECONDS`` + It indicates that the statistics data is used to measure time or latency. + * ``KVM_STATS_UNIT_CYCLES`` + It indicates that the statistics data is used to measure CPU clock cycles. + +Bits 8-11 of ``flags``, together with ``exponent``, encode the scale of the +unit: + * ``KVM_STATS_BASE_POW10`` + The scale is based on power of 10. It is used for measurement of time and + CPU clock cycles. For example, an exponent of -9 can be used with + ``KVM_STATS_UNIT_SECONDS`` to express that the unit is nanoseconds. + * ``KVM_STATS_BASE_POW2`` + The scale is based on power of 2. It is used for measurement of memory size. + For example, an exponent of 20 can be used with ``KVM_STATS_UNIT_BYTES`` to + express that the unit is MiB. + +The ``size`` field is the number of values of this statistics data. Its +value is usually 1 for most of simple statistics. 1 means it contains an +unsigned 64bit data. + +The ``offset`` field is the offset from the start of Data Block to the start of +the corresponding statistics data. + +The ``unused`` field is reserved for future support for other types of +statistics data, like log/linear histogram. Its value is always 0 for the types +defined above. + +The ``name`` field is the name string of the statistics data. The name string +starts at the end of ``struct kvm_stats_desc``. The maximum length including +the trailing ``'\0'``, is indicated by ``name_size`` in the header. + +The Stats Data block contains an array of 64-bit values in the same order +as the descriptors in Descriptors block. 5. The kvm_run structure ======================== -- cgit v1.2.3 From 63f5a1909f9e465eb446274969f65471794deafb Mon Sep 17 00:00:00 2001 From: Sean Christopherson Date: Tue, 22 Jun 2021 10:56:52 -0700 Subject: KVM: x86: Alert userspace that KVM_SET_CPUID{,2} after KVM_RUN is broken Warn userspace that KVM_SET_CPUID{,2} after KVM_RUN "may" cause guest instability. Initialize last_vmentry_cpu to -1 and use it to detect if the vCPU has been run at least once when its CPUID model is changed. KVM does not correctly handle changes to paging related settings in the guest's vCPU model after KVM_RUN, e.g. MAXPHYADDR, GBPAGES, etc... KVM could theoretically zap all shadow pages, but actually making that happen is a mess due to lock inversion (vcpu->mutex is held). And even then, updating paging settings on the fly would only work if all vCPUs are stopped, updated in concert with identical settings, then restarted. To support running vCPUs with different vCPU models (that affect paging), KVM would need to track all relevant information in kvm_mmu_page_role. Note, that's the _page_ role, not the full mmu_role. Updating mmu_role isn't sufficient as a vCPU can reuse a shadow page translation that was created by a vCPU with different settings and thus completely skip the reserved bit checks (that are tied to CPUID). Tracking CPUID state in kvm_mmu_page_role is _extremely_ undesirable as it would require doubling gfn_track from a u16 to a u32, i.e. would increase KVM's memory footprint by 2 bytes for every 4kb of guest memory. E.g. MAXPHYADDR (6 bits), GBPAGES, AMD vs. INTEL = 1 bit, and SEV C-BIT would all need to be tracked. In practice, there is no remotely sane use case for changing any paging related CPUID entries on the fly, so just sweep it under the rug (after yelling at userspace). Signed-off-by: Sean Christopherson Message-Id: <20210622175739.3610207-8-seanjc@google.com> Signed-off-by: Paolo Bonzini --- Documentation/virt/kvm/api.rst | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst index b87fa32835f2..5d8db4922df6 100644 --- a/Documentation/virt/kvm/api.rst +++ b/Documentation/virt/kvm/api.rst @@ -688,9 +688,14 @@ MSRs that have been set successfully. Defines the vcpu responses to the cpuid instruction. Applications should use the KVM_SET_CPUID2 ioctl if available. -Note, when this IOCTL fails, KVM gives no guarantees that previous valid CPUID -configuration (if there is) is not corrupted. Userspace can get a copy of the -resulting CPUID configuration through KVM_GET_CPUID2 in case. +Caveat emptor: + - If this IOCTL fails, KVM gives no guarantees that previous valid CPUID + configuration (if there is) is not corrupted. Userspace can get a copy + of the resulting CPUID configuration through KVM_GET_CPUID2 in case. + - Using KVM_SET_CPUID{,2} after KVM_RUN, i.e. changing the guest vCPU model + after running the guest, may cause guest instability. + - Using heterogeneous CPUID configurations, modulo APIC IDs, topology, etc... + may cause guest instability. :: -- cgit v1.2.3 From 00a669780ffa8c4b5f3e37346b5bf45508dd15bb Mon Sep 17 00:00:00 2001 From: Sean Christopherson Date: Tue, 22 Jun 2021 10:56:55 -0700 Subject: KVM: x86/mmu: Use MMU role to check for matching guest page sizes Originally, __kvm_sync_page used to check the cr4_pae bit in the role to avoid zapping 4-byte kvm_mmu_pages when guest page size are 8-byte or the other way round. However, in commit 47c42e6b4192 ("KVM: x86: fix handling of role.cr4_pae and rename it to 'gpte_size'", 2019-03-28) it was observed that this did not work for nested EPT, where the page table size would be 8 bytes even if CR4.PAE=0. (Note that the check still has to be done for nested *NPT*, so it is not possible to use tdp_enabled or similar). Therefore, a hack was introduced to identify nested EPT shadow pages and unconditionally call __kvm_sync_page() on them. However, it is possible to do without the hack to identify nested EPT shadow pages: if EPT is active, there will be no shadow pages in non-EPT format, and all of them will have gpte_is_8_bytes set to true; we can just check the MMU role directly, and the test will always be true. Even for non-EPT shadow MMUs, this test should really always be true now that __kvm_sync_page() is called if and only if the role is an exact match (kvm_mmu_get_page()) or is part of the current MMU context (kvm_mmu_sync_roots()). A future commit will convert the likely-pointless check into a meaningful WARN to enforce that the mmu_roles of the current context and the shadow page are compatible. Cc: Vitaly Kuznetsov Signed-off-by: Sean Christopherson Message-Id: <20210622175739.3610207-11-seanjc@google.com> Signed-off-by: Paolo Bonzini --- Documentation/virt/kvm/mmu.rst | 3 --- 1 file changed, 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/virt/kvm/mmu.rst b/Documentation/virt/kvm/mmu.rst index 20d85daed395..ddbb23998742 100644 --- a/Documentation/virt/kvm/mmu.rst +++ b/Documentation/virt/kvm/mmu.rst @@ -192,9 +192,6 @@ Shadow pages contain the following information: Contains the value of cr4.smap && !cr0.wp for which the page is valid (pages for which this is true are different from other pages; see the treatment of cr0.wp=0 below). - role.ept_sp: - This is a virtual flag to denote a shadowed nested EPT page. ept_sp - is true if "cr0_wp && smap_andnot_wp", an otherwise invalid combination. role.smm: Is 1 if the page is valid in system management mode. This field determines which of the kvm_memslots array was used to build this -- cgit v1.2.3 From 167f8a5cae99fb2050d3d674ca84457a526e23dd Mon Sep 17 00:00:00 2001 From: Sean Christopherson Date: Tue, 22 Jun 2021 10:57:09 -0700 Subject: KVM: x86/mmu: Rename "nxe" role bit to "efer_nx" for macro shenanigans Rename "nxe" to "efer_nx" so that future macro magic can use the pattern _ for all CR0, CR4, and EFER bits that included in the role. Using "efer_nx" also makes it clear that the role bit reflects EFER.NX, not the NX bit in the corresponding PTE. Signed-off-by: Sean Christopherson Message-Id: <20210622175739.3610207-25-seanjc@google.com> Signed-off-by: Paolo Bonzini --- Documentation/virt/kvm/mmu.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/virt/kvm/mmu.rst b/Documentation/virt/kvm/mmu.rst index ddbb23998742..f60f5488e121 100644 --- a/Documentation/virt/kvm/mmu.rst +++ b/Documentation/virt/kvm/mmu.rst @@ -180,8 +180,8 @@ Shadow pages contain the following information: role.gpte_is_8_bytes: Reflects the size of the guest PTE for which the page is valid, i.e. '1' if 64-bit gptes are in use, '0' if 32-bit gptes are in use. - role.nxe: - Contains the value of efer.nxe for which the page is valid. + role.efer_nx: + Contains the value of efer.nx for which the page is valid. role.cr0_wp: Contains the value of cr0.wp for which the page is valid. role.smep_andnot_wp: -- cgit v1.2.3 From 19238e75bd8ed8ffe784bf5b37586e77b2093742 Mon Sep 17 00:00:00 2001 From: Aaron Lewis Date: Mon, 10 May 2021 07:48:33 -0700 Subject: kvm: x86: Allow userspace to handle emulation errors Add a fallback mechanism to the in-kernel instruction emulator that allows userspace the opportunity to process an instruction the emulator was unable to. When the in-kernel instruction emulator fails to process an instruction it will either inject a #UD into the guest or exit to userspace with exit reason KVM_INTERNAL_ERROR. This is because it does not know how to proceed in an appropriate manner. This feature lets userspace get involved to see if it can figure out a better path forward. Signed-off-by: Aaron Lewis Reviewed-by: David Edmondson Message-Id: <20210510144834.658457-2-aaronlewis@google.com> Reviewed-by: Jim Mattson Signed-off-by: Paolo Bonzini --- Documentation/virt/kvm/api.rst | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) (limited to 'Documentation') diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst index 5d8db4922df6..3b6e3b1628b4 100644 --- a/Documentation/virt/kvm/api.rst +++ b/Documentation/virt/kvm/api.rst @@ -6546,6 +6546,7 @@ KVM_RUN_BUS_LOCK flag is used to distinguish between them. This capability can be used to check / enable 2nd DAWR feature provided by POWER10 processor. + 7.24 KVM_CAP_VM_COPY_ENC_CONTEXT_FROM ------------------------------------- @@ -6603,6 +6604,25 @@ present in the "ibm,hypertas-functions" device-tree property. This capability is enabled for hypervisors on platforms like POWER9 that support radix MMU. +7.27 KVM_CAP_EXIT_ON_EMULATION_FAILURE +-------------------------------------- + +:Architectures: x86 +:Parameters: args[0] whether the feature should be enabled or not + +When this capability is enabled, an emulation failure will result in an exit +to userspace with KVM_INTERNAL_ERROR (except when the emulator was invoked +to handle a VMware backdoor instruction). Furthermore, KVM will now provide up +to 15 instruction bytes for any exit to userspace resulting from an emulation +failure. When these exits to userspace occur use the emulation_failure struct +instead of the internal struct. They both have the same layout, but the +emulation_failure struct matches the content better. It also explicitly +defines the 'flags' field which is used to describe the fields in the struct +that are valid (ie: if KVM_INTERNAL_ERROR_EMULATION_FLAG_INSTRUCTION_BYTES is +set in the 'flags' field then both 'insn_size' and 'insn_bytes' have valid data +in them.) + + 8. Other capabilities. ====================== -- cgit v1.2.3 From ed78f56e1271f108e8af61baeba383dcd77adbec Mon Sep 17 00:00:00 2001 From: Vaibhav Jain Date: Thu, 13 May 2021 14:53:49 +0530 Subject: powerpc/papr_scm: Make 'perf_stats' invisible if perf-stats unavailable In case performance stats for an nvdimm are not available, reading the 'perf_stats' sysfs file returns an -ENOENT error. A better approach is to make the 'perf_stats' file entirely invisible to indicate that performance stats for an nvdimm are unavailable. So this patch updates 'papr_nd_attribute_group' to add a 'is_visible' callback implemented as newly introduced 'papr_nd_attribute_visible()' that returns an appropriate mode in case performance stats aren't supported in a given nvdimm. Also the initialization of 'papr_scm_priv.stat_buffer_len' is moved from papr_scm_nvdimm_init() to papr_scm_probe() so that it value is available when 'papr_nd_attribute_visible()' is called during nvdimm initialization. Even though 'perf_stats' attribute is available since v5.9, there are no known user-space tools/scripts that are dependent on presence of its sysfs file. Hence I dont expect any user-space breakage with this patch. Fixes: 2d02bf835e57 ("powerpc/papr_scm: Fetch nvdimm performance stats from PHYP") Signed-off-by: Vaibhav Jain Reviewed-by: Dan Williams Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20210513092349.285021-1-vaibhav@linux.ibm.com --- Documentation/ABI/testing/sysfs-bus-papr-pmem | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-bus-papr-pmem b/Documentation/ABI/testing/sysfs-bus-papr-pmem index 92e2db0e2d3d..95254cec92bf 100644 --- a/Documentation/ABI/testing/sysfs-bus-papr-pmem +++ b/Documentation/ABI/testing/sysfs-bus-papr-pmem @@ -39,9 +39,11 @@ KernelVersion: v5.9 Contact: linuxppc-dev , nvdimm@lists.linux.dev, Description: (RO) Report various performance stats related to papr-scm NVDIMM - device. Each stat is reported on a new line with each line - composed of a stat-identifier followed by it value. Below are - currently known dimm performance stats which are reported: + device. This attribute is only available for NVDIMM devices + that support reporting NVDIMM performance stats. Each stat is + reported on a new line with each line composed of a + stat-identifier followed by it value. Below are currently known + dimm performance stats which are reported: * "CtlResCt" : Controller Reset Count * "CtlResTm" : Controller Reset Elapsed Time -- cgit v1.2.3 From 8de6b7edd493af5587e479afa85706d6fe9c5725 Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Fri, 25 Jun 2021 09:45:53 +0200 Subject: phy: phy-hi3670-usb3: move driver from staging into phy The phy USB3 driver for Hisilicon 970 (hi3670) is ready for mainstream. Mode it from staging into the main driver's phy/ directory. Acked-by: Rob Herring Acked-By: Vinod Koul Signed-off-by: Mauro Carvalho Chehab Link: https://lore.kernel.org/r/dcf66a01aaeaab93cda52f9a283ecbdf9fa71bb8.1624606660.git.mchehab+huawei@kernel.org Signed-off-by: Greg Kroah-Hartman --- .../bindings/phy/hisilicon,hi3670-usb3.yaml | 73 ++++++++++++++++++++++ 1 file changed, 73 insertions(+) create mode 100644 Documentation/devicetree/bindings/phy/hisilicon,hi3670-usb3.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/phy/hisilicon,hi3670-usb3.yaml b/Documentation/devicetree/bindings/phy/hisilicon,hi3670-usb3.yaml new file mode 100644 index 000000000000..ebd78acfe2de --- /dev/null +++ b/Documentation/devicetree/bindings/phy/hisilicon,hi3670-usb3.yaml @@ -0,0 +1,73 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/phy/hisilicon,hi3670-usb3.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Hisilicon Kirin970 USB PHY + +maintainers: + - Mauro Carvalho Chehab + +description: |+ + Bindings for USB3 PHY on HiSilicon Kirin 970. + +properties: + compatible: + const: hisilicon,hi3670-usb-phy + + "#phy-cells": + const: 0 + + hisilicon,pericrg-syscon: + $ref: '/schemas/types.yaml#/definitions/phandle' + description: phandle of syscon used to control iso refclk. + + hisilicon,pctrl-syscon: + $ref: '/schemas/types.yaml#/definitions/phandle' + description: phandle of syscon used to control usb tcxo. + + hisilicon,sctrl-syscon: + $ref: '/schemas/types.yaml#/definitions/phandle' + description: phandle of syscon used to control phy deep sleep. + + hisilicon,eye-diagram-param: + $ref: /schemas/types.yaml#/definitions/uint32 + description: Eye diagram for phy. + + hisilicon,tx-vboost-lvl: + $ref: /schemas/types.yaml#/definitions/uint32 + description: TX level vboost for phy. + +required: + - compatible + - hisilicon,pericrg-syscon + - hisilicon,pctrl-syscon + - hisilicon,sctrl-syscon + - hisilicon,eye-diagram-param + - hisilicon,tx-vboost-lvl + - "#phy-cells" + +additionalProperties: false + +examples: + - | + bus { + #address-cells = <2>; + #size-cells = <2>; + + usb3_otg_bc: usb3_otg_bc@ff200000 { + compatible = "syscon", "simple-mfd"; + reg = <0x0 0xff200000 0x0 0x1000>; + + usb_phy { + compatible = "hisilicon,hi3670-usb-phy"; + #phy-cells = <0>; + hisilicon,pericrg-syscon = <&crg_ctrl>; + hisilicon,pctrl-syscon = <&pctrl>; + hisilicon,sctrl-syscon = <&sctrl>; + hisilicon,eye-diagram-param = <0xfdfee4>; + hisilicon,tx-vboost-lvl = <0x5>; + }; + }; + }; -- cgit v1.2.3 From e562cf3aea3e1ea46566907f7627e5512840a2b4 Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Fri, 25 Jun 2021 09:45:54 +0200 Subject: spmi: hisi-spmi-controller: move driver from staging The Hisilicon 6421v600 SPMI driver is ready for mainstream. So, move it from staging. Acked-by: Stephen Boyd Signed-off-by: Mauro Carvalho Chehab Link: https://lore.kernel.org/r/35b9f9169889c1f4d51eff8bf2035450c9e02576.1624606660.git.mchehab+huawei@kernel.org Signed-off-by: Greg Kroah-Hartman --- .../spmi/hisilicon,hisi-spmi-controller.yaml | 73 ++++++++++++++++++++++ 1 file changed, 73 insertions(+) create mode 100644 Documentation/devicetree/bindings/spmi/hisilicon,hisi-spmi-controller.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/spmi/hisilicon,hisi-spmi-controller.yaml b/Documentation/devicetree/bindings/spmi/hisilicon,hisi-spmi-controller.yaml new file mode 100644 index 000000000000..f882903769f9 --- /dev/null +++ b/Documentation/devicetree/bindings/spmi/hisilicon,hisi-spmi-controller.yaml @@ -0,0 +1,73 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/spmi/hisilicon,hisi-spmi-controller.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: HiSilicon SPMI controller + +maintainers: + - Mauro Carvalho Chehab + +description: | + The HiSilicon SPMI BUS controller is found on some Kirin-based designs. + It is a MIPI System Power Management (SPMI) controller. + + The PMIC part is provided by + ./Documentation/devicetree/bindings/mfd/hisilicon,hi6421-spmi-pmic.yaml. + +allOf: + - $ref: spmi.yaml# + +properties: + + $nodename: + pattern: "spmi@[0-9a-f]" + + compatible: + const: hisilicon,kirin970-spmi-controller + + reg: + maxItems: 1 + + hisilicon,spmi-channel: + $ref: /schemas/types.yaml#/definitions/uint32 + description: | + number of the Kirin 970 SPMI channel where the SPMI devices are connected. + +required: + - compatible + - reg + - hisilicon,spmi-channel + +patternProperties: + "@[0-9a-f]$": + type: object + + description: | + PMIC properties, which are specific to the used SPMI PMIC device(s). + When used in combination with HiSilicon 6421v600, the properties + are documented at + drivers/staging/hikey9xx/hisilicon,hi6421-spmi-pmic.yaml. + +unevaluatedProperties: false + +examples: + - | + bus { + #address-cells = <2>; + #size-cells = <2>; + + spmi: spmi@fff24000 { + compatible = "hisilicon,kirin970-spmi-controller"; + #address-cells = <2>; + #size-cells = <0>; + reg = <0x0 0xfff24000 0x0 0x1000>; + hisilicon,spmi-channel = <2>; + + pmic@0 { + reg = <0 0>; + /* pmic properties */ + }; + }; + }; -- cgit v1.2.3 From eda627f6be8aede0e4a80fd0274a2ba944d40f2c Mon Sep 17 00:00:00 2001 From: Aleksander Jan Bajkowski Date: Thu, 3 Jun 2021 15:59:45 +0200 Subject: dt-bindings: gpio: stp: convert to json-schema Convert the Lantiq STP Device Tree binding documentation to json-schema. Add the missing pinctrl property to the example. Add missing lantiq,phy3 and lantiq,phy4 bindings for xRX300 and xRX330 SoCs. Signed-off-by: Aleksander Jan Bajkowski Acked-by: Linus Walleij Reviewed-by: Rob Herring Signed-off-by: Bartosz Golaszewski --- .../devicetree/bindings/gpio/gpio-stp-xway.txt | 42 --------- .../devicetree/bindings/gpio/gpio-stp-xway.yaml | 99 ++++++++++++++++++++++ 2 files changed, 99 insertions(+), 42 deletions(-) delete mode 100644 Documentation/devicetree/bindings/gpio/gpio-stp-xway.txt create mode 100644 Documentation/devicetree/bindings/gpio/gpio-stp-xway.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/gpio/gpio-stp-xway.txt b/Documentation/devicetree/bindings/gpio/gpio-stp-xway.txt deleted file mode 100644 index 78458adbf4b7..000000000000 --- a/Documentation/devicetree/bindings/gpio/gpio-stp-xway.txt +++ /dev/null @@ -1,42 +0,0 @@ -Lantiq SoC Serial To Parallel (STP) GPIO controller - -The Serial To Parallel (STP) is found on MIPS based Lantiq socs. It is a -peripheral controller used to drive external shift register cascades. At most -3 groups of 8 bits can be driven. The hardware is able to allow the DSL modem -to drive the 2 LSBs of the cascade automatically. - - -Required properties: -- compatible : Should be "lantiq,gpio-stp-xway" -- reg : Address and length of the register set for the device -- #gpio-cells : Should be two. The first cell is the pin number and - the second cell is used to specify optional parameters (currently - unused). -- gpio-controller : Marks the device node as a gpio controller. - -Optional properties: -- lantiq,shadow : The default value that we shall assume as already set on the - shift register cascade. -- lantiq,groups : Set the 3 bit mask to select which of the 3 groups are enabled - in the shift register cascade. -- lantiq,dsl : The dsl core can control the 2 LSBs of the gpio cascade. This 2 bit - property can enable this feature. -- lantiq,phy1 : The gphy1 core can control 3 bits of the gpio cascade. -- lantiq,phy2 : The gphy2 core can control 3 bits of the gpio cascade. -- lantiq,rising : use rising instead of falling edge for the shift register - -Example: - -gpio1: stp@e100bb0 { - compatible = "lantiq,gpio-stp-xway"; - reg = <0xE100BB0 0x40>; - #gpio-cells = <2>; - gpio-controller; - - lantiq,shadow = <0xffff>; - lantiq,groups = <0x7>; - lantiq,dsl = <0x3>; - lantiq,phy1 = <0x7>; - lantiq,phy2 = <0x7>; - /* lantiq,rising; */ -}; diff --git a/Documentation/devicetree/bindings/gpio/gpio-stp-xway.yaml b/Documentation/devicetree/bindings/gpio/gpio-stp-xway.yaml new file mode 100644 index 000000000000..d565c4b63dbf --- /dev/null +++ b/Documentation/devicetree/bindings/gpio/gpio-stp-xway.yaml @@ -0,0 +1,99 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/gpio/gpio-stp-xway.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Lantiq SoC Serial To Parallel (STP) GPIO controller + +description: | + The Serial To Parallel (STP) is found on MIPS based Lantiq socs. It is a + peripheral controller used to drive external shift register cascades. At most + 3 groups of 8 bits can be driven. The hardware is able to allow the DSL modem + and Ethernet PHYs to drive some bytes of the cascade automatically. + +maintainers: + - John Crispin + +properties: + $nodename: + pattern: "^gpio@[0-9a-f]+$" + + compatible: + const: lantiq,gpio-stp-xway + + reg: + maxItems: 1 + + gpio-controller: true + + "#gpio-cells": + description: + The first cell is the pin number and the second cell is used to specify + consumer flags. + const: 2 + + lantiq,shadow: + description: + The default value that we shall assume as already set on the + shift register cascade. + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0x000000 + maximum: 0xffffff + + lantiq,groups: + description: + Set the 3 bit mask to select which of the 3 groups are enabled + in the shift register cascade. + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0x0 + maximum: 0x7 + + lantiq,dsl: + description: + The dsl core can control the 2 LSBs of the gpio cascade. This 2 bit + property can enable this feature. + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0x0 + maximum: 0x3 + + lantiq,rising: + description: + Use rising instead of falling edge for the shift register. + type: boolean + +patternProperties: + "^lantiq,phy[1-4]$": + description: + The gphy core can control 3 bits of the gpio cascade. In the xRX200 family + phy[1-2] are available, in xRX330 phy[1-3] and in XRX330 phy[1-4]. + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0x0 + maximum: 0x7 + +required: + - compatible + - reg + - gpio-controller + - "#gpio-cells" + +additionalProperties: false + +examples: + - | + gpio@e100bb0 { + compatible = "lantiq,gpio-stp-xway"; + reg = <0xE100BB0 0x40>; + #gpio-cells = <2>; + gpio-controller; + + pinctrl-0 = <&stp_pins>; + pinctrl-names = "default"; + + lantiq,shadow = <0xffffff>; + lantiq,groups = <0x7>; + lantiq,dsl = <0x3>; + lantiq,phy1 = <0x7>; + lantiq,phy2 = <0x7>; + }; +... -- cgit v1.2.3 From d766dfee58e19d5781f6f9acb5092376742e7888 Mon Sep 17 00:00:00 2001 From: Geert Uytterhoeven Date: Tue, 1 Jun 2021 17:25:47 +0200 Subject: dt-bindings: gpio: pcf857x: Convert to json-schema Convert the PCF857x-compatible I/O expanders Device Tree binding documentation to json-schema. Document missing compatible values, properties, and gpio hogs. Signed-off-by: Geert Uytterhoeven Reviewed-by: Rob Herring Reviewed-by: Linus Walleij Signed-off-by: Bartosz Golaszewski --- .../devicetree/bindings/gpio/gpio-pcf857x.txt | 69 -------------- .../devicetree/bindings/gpio/nxp,pcf8575.yaml | 103 +++++++++++++++++++++ 2 files changed, 103 insertions(+), 69 deletions(-) delete mode 100644 Documentation/devicetree/bindings/gpio/gpio-pcf857x.txt create mode 100644 Documentation/devicetree/bindings/gpio/nxp,pcf8575.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/gpio/gpio-pcf857x.txt b/Documentation/devicetree/bindings/gpio/gpio-pcf857x.txt deleted file mode 100644 index a482455a205b..000000000000 --- a/Documentation/devicetree/bindings/gpio/gpio-pcf857x.txt +++ /dev/null @@ -1,69 +0,0 @@ -* PCF857x-compatible I/O expanders - -The PCF857x-compatible chips have "quasi-bidirectional" I/O lines that can be -driven high by a pull-up current source or driven low to ground. This combines -the direction and output level into a single bit per line, which can't be read -back. We can't actually know at initialization time whether a line is configured -(a) as output and driving the signal low/high, or (b) as input and reporting a -low/high value, without knowing the last value written since the chip came out -of reset (if any). The only reliable solution for setting up line direction is -thus to do it explicitly. - -Required Properties: - - - compatible: should be one of the following. - - "maxim,max7328": For the Maxim MAX7378 - - "maxim,max7329": For the Maxim MAX7329 - - "nxp,pca8574": For the NXP PCA8574 - - "nxp,pca8575": For the NXP PCA8575 - - "nxp,pca9670": For the NXP PCA9670 - - "nxp,pca9671": For the NXP PCA9671 - - "nxp,pca9672": For the NXP PCA9672 - - "nxp,pca9673": For the NXP PCA9673 - - "nxp,pca9674": For the NXP PCA9674 - - "nxp,pca9675": For the NXP PCA9675 - - "nxp,pcf8574": For the NXP PCF8574 - - "nxp,pcf8574a": For the NXP PCF8574A - - "nxp,pcf8575": For the NXP PCF8575 - - - reg: I2C slave address. - - - gpio-controller: Marks the device node as a gpio controller. - - #gpio-cells: Should be 2. The first cell is the GPIO number and the second - cell specifies GPIO flags, as defined in . Only the - GPIO_ACTIVE_HIGH and GPIO_ACTIVE_LOW flags are supported. - -Optional Properties: - - - lines-initial-states: Bitmask that specifies the initial state of each - line. When a bit is set to zero, the corresponding line will be initialized to - the input (pulled-up) state. When the bit is set to one, the line will be - initialized the low-level output state. If the property is not specified - all lines will be initialized to the input state. - - The I/O expander can detect input state changes, and thus optionally act as - an interrupt controller. When the expander interrupt line is connected all the - following properties must be set. For more information please see the - interrupt controller device tree bindings documentation available at - Documentation/devicetree/bindings/interrupt-controller/interrupts.txt. - - - interrupt-controller: Identifies the node as an interrupt controller. - - #interrupt-cells: Number of cells to encode an interrupt source, shall be 2. - - interrupts: Interrupt specifier for the controllers interrupt. - - -Please refer to gpio.txt in this directory for details of the common GPIO -bindings used by client devices. - -Example: PCF8575 I/O expander node - - pcf8575: gpio@20 { - compatible = "nxp,pcf8575"; - reg = <0x20>; - interrupt-parent = <&irqpin2>; - interrupts = <3 0>; - gpio-controller; - #gpio-cells = <2>; - interrupt-controller; - #interrupt-cells = <2>; - }; diff --git a/Documentation/devicetree/bindings/gpio/nxp,pcf8575.yaml b/Documentation/devicetree/bindings/gpio/nxp,pcf8575.yaml new file mode 100644 index 000000000000..f0ff66c4c74e --- /dev/null +++ b/Documentation/devicetree/bindings/gpio/nxp,pcf8575.yaml @@ -0,0 +1,103 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/gpio/nxp,pcf8575.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: PCF857x-compatible I/O expanders + +maintainers: + - Laurent Pinchart + +description: + The PCF857x-compatible chips have "quasi-bidirectional" I/O lines that can be + driven high by a pull-up current source or driven low to ground. This + combines the direction and output level into a single bit per line, which + can't be read back. We can't actually know at initialization time whether a + line is configured (a) as output and driving the signal low/high, or (b) as + input and reporting a low/high value, without knowing the last value written + since the chip came out of reset (if any). The only reliable solution for + setting up line direction is thus to do it explicitly. + +properties: + compatible: + enum: + - maxim,max7328 + - maxim,max7329 + - nxp,pca8574 + - nxp,pca8575 + - nxp,pca9670 + - nxp,pca9671 + - nxp,pca9672 + - nxp,pca9673 + - nxp,pca9674 + - nxp,pca9675 + - nxp,pcf8574 + - nxp,pcf8574a + - nxp,pcf8575 + + reg: + maxItems: 1 + + gpio-controller: true + + '#gpio-cells': + const: 2 + description: + The first cell is the GPIO number and the second cell specifies GPIO + flags, as defined in . Only the GPIO_ACTIVE_HIGH + and GPIO_ACTIVE_LOW flags are supported. + + lines-initial-states: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + Bitmask that specifies the initial state of each line. + When a bit is set to zero, the corresponding line will be initialized to + the input (pulled-up) state. + When the bit is set to one, the line will be initialized to the + low-level output state. + If the property is not specified all lines will be initialized to the + input state. + + interrupts: + maxItems: 1 + + interrupt-controller: true + + '#interrupt-cells': + const: 2 + + wakeup-source: true + +patternProperties: + "^(.+-hog(-[0-9]+)?)$": + type: object + + required: + - gpio-hog + +required: + - compatible + - reg + - gpio-controller + - '#gpio-cells' + +additionalProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + pcf8575: gpio@20 { + compatible = "nxp,pcf8575"; + reg = <0x20>; + interrupt-parent = <&irqpin2>; + interrupts = <3 0>; + gpio-controller; + #gpio-cells = <2>; + interrupt-controller; + #interrupt-cells = <2>; + }; + }; -- cgit v1.2.3 From c34c1228fc1cfe83aed909995f5b82e0ab7cb977 Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Wed, 16 Jun 2021 08:27:29 +0200 Subject: docs: driver-api: gpio: using-gpio.rst: avoid using ReST :doc:`foo` markup The :doc:`foo` tag is auto-generated via automarkup.py. So, use the filename at the sources, instead of :doc:`foo`. Reviewed-by: Linus Walleij Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Bartosz Golaszewski --- Documentation/driver-api/gpio/using-gpio.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/driver-api/gpio/using-gpio.rst b/Documentation/driver-api/gpio/using-gpio.rst index dda069444032..64c8d3f76c3a 100644 --- a/Documentation/driver-api/gpio/using-gpio.rst +++ b/Documentation/driver-api/gpio/using-gpio.rst @@ -9,13 +9,13 @@ with them. For examples of already existing generic drivers that will also be good examples for any other kernel drivers you want to author, refer to -:doc:`drivers-on-gpio` +Documentation/driver-api/gpio/drivers-on-gpio.rst For any kind of mass produced system you want to support, such as servers, laptops, phones, tablets, routers, and any consumer or office or business goods using appropriate kernel drivers is paramount. Submit your code for inclusion in the upstream Linux kernel when you feel it is mature enough and you will get -help to refine it, see :doc:`../../process/submitting-patches`. +help to refine it, see Documentation/process/submitting-patches.rst. In Linux GPIO lines also have a userspace ABI. -- cgit v1.2.3 From c58db2abb19fd2bf23fb25bb3630a9f540df6042 Mon Sep 17 00:00:00 2001 From: Nobuhiro Iwamatsu Date: Mon, 14 Jun 2021 06:43:17 +0900 Subject: spi: convert Xilinx Zynq UltraScale+ MPSoC GQSPI bindings to YAML Convert spi for Xilinx Zynq UltraScale+ MPSoC GQSPI bindings documentation to YAML. Signed-off-by: Nobuhiro Iwamatsu Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20210613214317.296667-1-iwamatsu@nigauri.org Signed-off-by: Mark Brown --- .../devicetree/bindings/spi/spi-zynqmp-qspi.txt | 25 ----------- .../devicetree/bindings/spi/spi-zynqmp-qspi.yaml | 51 ++++++++++++++++++++++ 2 files changed, 51 insertions(+), 25 deletions(-) delete mode 100644 Documentation/devicetree/bindings/spi/spi-zynqmp-qspi.txt create mode 100644 Documentation/devicetree/bindings/spi/spi-zynqmp-qspi.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/spi/spi-zynqmp-qspi.txt b/Documentation/devicetree/bindings/spi/spi-zynqmp-qspi.txt deleted file mode 100644 index 0f6d37ff541c..000000000000 --- a/Documentation/devicetree/bindings/spi/spi-zynqmp-qspi.txt +++ /dev/null @@ -1,25 +0,0 @@ -Xilinx Zynq UltraScale+ MPSoC GQSPI controller Device Tree Bindings -------------------------------------------------------------------- - -Required properties: -- compatible : Should be "xlnx,zynqmp-qspi-1.0". -- reg : Physical base address and size of GQSPI registers map. -- interrupts : Property with a value describing the interrupt - number. -- clock-names : List of input clock names - "ref_clk", "pclk" - (See clock bindings for details). -- clocks : Clock phandles (see clock bindings for details). - -Optional properties: -- num-cs : Number of chip selects used. - -Example: - qspi: spi@ff0f0000 { - compatible = "xlnx,zynqmp-qspi-1.0"; - clock-names = "ref_clk", "pclk"; - clocks = <&misc_clk &misc_clk>; - interrupts = <0 15 4>; - interrupt-parent = <&gic>; - num-cs = <1>; - reg = <0x0 0xff0f0000 0x1000>,<0x0 0xc0000000 0x8000000>; - }; diff --git a/Documentation/devicetree/bindings/spi/spi-zynqmp-qspi.yaml b/Documentation/devicetree/bindings/spi/spi-zynqmp-qspi.yaml new file mode 100644 index 000000000000..ea72c8001256 --- /dev/null +++ b/Documentation/devicetree/bindings/spi/spi-zynqmp-qspi.yaml @@ -0,0 +1,51 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/spi/spi-zynqmp-qspi.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Xilinx Zynq UltraScale+ MPSoC GQSPI controller Device Tree Bindings + +maintainers: + - Michal Simek + +allOf: + - $ref: "spi-controller.yaml#" + +properties: + compatible: + const: xlnx,zynqmp-qspi-1.0 + + reg: + maxItems: 2 + + interrupts: + maxItems: 1 + + clock-names: + items: + - const: ref_clk + - const: pclk + + clocks: + maxItems: 2 + +unevaluatedProperties: false + +examples: + - | + #include + soc { + #address-cells = <2>; + #size-cells = <2>; + + qspi: spi@ff0f0000 { + compatible = "xlnx,zynqmp-qspi-1.0"; + clocks = <&zynqmp_clk QSPI_REF>, <&zynqmp_clk LPD_LSBUS>; + clock-names = "ref_clk", "pclk"; + interrupts = <0 15 4>; + interrupt-parent = <&gic>; + reg = <0x0 0xff0f0000 0x0 0x1000>, + <0x0 0xc0000000 0x0 0x8000000>; + }; + }; -- cgit v1.2.3 From 56b3276954f0e3b32760997a904fcbaec25bc005 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Pali=20Roh=C3=A1r?= Date: Fri, 25 Jun 2021 00:49:03 +0200 Subject: dt-bindings: mvebu-uart: fix documentation MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Both UARTs support higher baudrates and are not limited to baudrate 230400. Only current kernel driver implementation has limitation for both UARTs in maximal baudrate 230400. This limitation will be removed in next patches. So remove incorrect information about (hardware) limitation from bindings. UART1 (standard variant with DT node name 'uart0') has register space 0x12000-0x12018 and not whole size 0x200. So fix also this in example. Signed-off-by: Pali Rohár Fixes: d160c3413478 ("dt-bindings: mvebu-uart: update documentation with extended UART") Link: https://lore.kernel.org/r/20210624224909.6350-5-pali@kernel.org Signed-off-by: Greg Kroah-Hartman --- Documentation/devicetree/bindings/serial/mvebu-uart.txt | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/serial/mvebu-uart.txt b/Documentation/devicetree/bindings/serial/mvebu-uart.txt index b7e0e32b9ac6..2d0dbdf32d1d 100644 --- a/Documentation/devicetree/bindings/serial/mvebu-uart.txt +++ b/Documentation/devicetree/bindings/serial/mvebu-uart.txt @@ -5,10 +5,10 @@ Required properties: - compatible: - "marvell,armada-3700-uart" for the standard variant of the UART (32 bytes FIFO, no DMA, level interrupts, 8-bit access to the - FIFO, baudrate limited to 230400). + FIFO), called also UART1. - "marvell,armada-3700-uart-ext" for the extended variant of the UART (128 bytes FIFO, DMA, front interrupts, 8-bit or 32-bit - accesses to the FIFO, baudrate unlimited by the dividers). + accesses to the FIFO), called also UART2. - reg: offset and length of the register set for the device. - clocks: UART reference clock used to derive the baudrate. If no clock is provided (possible only with the "marvell,armada-3700-uart" @@ -33,7 +33,7 @@ Required properties: Example: uart0: serial@12000 { compatible = "marvell,armada-3700-uart"; - reg = <0x12000 0x200>; + reg = <0x12000 0x18>; clocks = <&xtalclk>; interrupts = , -- cgit v1.2.3 From 31df7195b100f7e7b7ac07675d93b3b504400fe9 Mon Sep 17 00:00:00 2001 From: Alex Qiu Date: Mon, 17 May 2021 16:56:05 -0700 Subject: Documentation: i2c: Add doc for I2C sysfs This doc helps Linux users navigate through I2C sysfs and learn the system I2C topology. Signed-off-by: Alex Qiu Reviewed-by: Guenter Roeck Signed-off-by: Wolfram Sang --- Documentation/i2c/i2c-sysfs.rst | 395 ++++++++++++++++++++++++++++++++++++++++ 1 file changed, 395 insertions(+) create mode 100644 Documentation/i2c/i2c-sysfs.rst (limited to 'Documentation') diff --git a/Documentation/i2c/i2c-sysfs.rst b/Documentation/i2c/i2c-sysfs.rst new file mode 100644 index 000000000000..6b68b95cd427 --- /dev/null +++ b/Documentation/i2c/i2c-sysfs.rst @@ -0,0 +1,395 @@ +.. SPDX-License-Identifier: GPL-2.0 + +=============== +Linux I2C Sysfs +=============== + +Overview +======== + +I2C topology can be complex because of the existence of I2C MUX +(I2C Multiplexer). The Linux +kernel abstracts the MUX channels into logical I2C bus numbers. However, there +is a gap of knowledge to map from the I2C bus physical number and MUX topology +to logical I2C bus number. This doc is aimed to fill in this gap, so the +audience (hardware engineers and new software developers for example) can learn +the concept of logical I2C buses in the kernel, by knowing the physical I2C +topology and navigating through the I2C sysfs in Linux shell. This knowledge is +useful and essential to use ``i2c-tools`` for the purpose of development and +debugging. + +Target audience +--------------- + +People who need to use Linux shell to interact with I2C subsystem on a system +which the Linux is running on. + +Prerequisites +------------- + +1. Knowledge of general Linux shell file system commands and operations. + +2. General knowledge of I2C, I2C MUX and I2C topology. + +Location of I2C Sysfs +===================== + +Typically, the Linux Sysfs filesystem is mounted at the ``/sys`` directory, +so you can find the I2C Sysfs under ``/sys/bus/i2c/devices`` +where you can directly ``cd`` to it. +There is a list of symbolic links under that directory. The links that +start with ``i2c-`` are I2C buses, which may be either physical or logical. The +other links that begin with numbers and end with numbers are I2C devices, where +the first number is I2C bus number, and the second number is I2C address. + +Google Pixel 3 phone for example:: + + blueline:/sys/bus/i2c/devices $ ls + 0-0008 0-0061 1-0028 3-0043 4-0036 4-0041 i2c-1 i2c-3 + 0-000c 0-0066 2-0049 4-000b 4-0040 i2c-0 i2c-2 i2c-4 + +``i2c-2`` is an I2C bus whose number is 2, and ``2-0049`` is an I2C device +on bus 2 address 0x49 bound with a kernel driver. + +Terminologies +============= + +First, let us define a couple of terminologies to avoid confusions in the later +sections. + +(Physical) I2C Bus Controller +----------------------------- + +The hardware system that the Linux kernel is running on may have multiple +physical I2C bus controllers. The controllers are hardware and physical, and the +system may define multiple registers in the memory space to manipulate the +controllers. Linux kernel has I2C bus drivers under source directory +``drivers/i2c/busses`` to translate kernel I2C API into register +operations for different systems. This terminology is not limited to Linux +kernel only. + +I2C Bus Physical Number +----------------------- + +For each physical I2C bus controller, the system vendor may assign a physical +number to each controller. For example, the first I2C bus controller which has +the lowest register addresses may be called ``I2C-0``. + +Logical I2C Bus +--------------- + +Every I2C bus number you see in Linux I2C Sysfs is a logical I2C bus with a +number assigned. This is similar to the fact that software code is usually +written upon virtual memory space, instead of physical memory space. + +Each logical I2C bus may be an abstraction of a physical I2C bus controller, or +an abstraction of a channel behind an I2C MUX. In case it is an abstraction of a +MUX channel, whenever we access an I2C device via a such logical bus, the kernel +will switch the I2C MUX for you to the proper channel as part of the +abstraction. + +Physical I2C Bus +---------------- + +If the logical I2C bus is a direct abstraction of a physical I2C bus controller, +let us call it a physical I2C bus. + +Caveat +------ + +This may be a confusing part for people who only know about the physical I2C +design of a board. It is actually possible to rename the I2C bus physical number +to a different number in logical I2C bus level in Device Tree Source (DTS) under +section ``aliases``. See +`arch/arm/boot/dts/nuvoton-npcm730-gsj.dts +<../../arch/arm/boot/dts/nuvoton-npcm730-gsj.dts>`_ +for an example of DTS file. + +Best Practice: **(To kernel software developers)** It is better to keep the I2C +bus physical number the same as their corresponding logical I2C bus number, +instead of renaming or mapping them, so that it may be less confusing to other +users. These physical I2C buses can be served as good starting points for I2C +MUX fanouts. For the following examples, we will assume that the physical I2C +bus has a number same as their I2C bus physical number. + +Walk through Logical I2C Bus +============================ + +For the following content, we will use a more complex I2C topology as an +example. Here is a brief graph for the I2C topology. If you do not understand +this graph at the first glance, do not be afraid to continue reading this doc +and review it when you finish reading. + +:: + + i2c-7 (physical I2C bus controller 7) + `-- 7-0071 (4-channel I2C MUX at 0x71) + |-- i2c-60 (channel-0) + |-- i2c-73 (channel-1) + | |-- 73-0040 (I2C sensor device with hwmon directory) + | |-- 73-0070 (I2C MUX at 0x70, exists in DTS, but failed to probe) + | `-- 73-0072 (8-channel I2C MUX at 0x72) + | |-- i2c-78 (channel-0) + | |-- ... (channel-1...6, i2c-79...i2c-84) + | `-- i2c-85 (channel-7) + |-- i2c-86 (channel-2) + `-- i2c-203 (channel-3) + +Distinguish Physical and Logical I2C Bus +---------------------------------------- + +One simple way to distinguish between a physical I2C bus and a logical I2C bus, +is to read the symbolic link ``device`` under the I2C bus directory by using +command ``ls -l`` or ``readlink``. + +An alternative symbolic link to check is ``mux_device``. This link only exists +in logical I2C bus directory which is fanned out from another I2C bus. +Reading this link will also tell you which I2C MUX device created +this logical I2C bus. + +If the symbolic link points to a directory ending with ``.i2c``, it should be a +physical I2C bus, directly abstracting a physical I2C bus controller. For +example:: + + $ readlink /sys/bus/i2c/devices/i2c-7/device + ../../f0087000.i2c + $ ls /sys/bus/i2c/devices/i2c-7/mux_device + ls: /sys/bus/i2c/devices/i2c-7/mux_device: No such file or directory + +In this case, ``i2c-7`` is a physical I2C bus, so it does not have the symbolic +link ``mux_device`` under its directory. And if the kernel software developer +follows the common practice by not renaming physical I2C buses, this should also +mean the physical I2C bus controller 7 of the system. + +On the other hand, if the symbolic link points to another I2C bus, the I2C bus +presented by the current directory has to be a logical bus. The I2C bus pointed +by the link is the parent bus which may be either a physical I2C bus or a +logical one. In this case, the I2C bus presented by the current directory +abstracts an I2C MUX channel under the parent bus. + +For example:: + + $ readlink /sys/bus/i2c/devices/i2c-73/device + ../../i2c-7 + $ readlink /sys/bus/i2c/devices/i2c-73/mux_device + ../7-0071 + +``i2c-73`` is a logical bus fanout by an I2C MUX under ``i2c-7`` +whose I2C address is 0x71. +Whenever we access an I2C device with bus 73, the kernel will always +switch the I2C MUX addressed 0x71 to the proper channel for you as part of the +abstraction. + +Finding out Logical I2C Bus Number +---------------------------------- + +In this section, we will describe how to find out the logical I2C bus number +representing certain I2C MUX channels based on the knowledge of physical +hardware I2C topology. + +In this example, we have a system which has a physical I2C bus 7 and not renamed +in DTS. There is a 4-channel MUX at address 0x71 on that bus. There is another +8-channel MUX at address 0x72 behind the channel 1 of the 0x71 MUX. Let us +navigate through Sysfs and find out the logical I2C bus number of the channel 3 +of the 0x72 MUX. + +First of all, let us go to the directory of ``i2c-7``:: + + ~$ cd /sys/bus/i2c/devices/i2c-7 + /sys/bus/i2c/devices/i2c-7$ ls + 7-0071 i2c-60 name subsystem + delete_device i2c-73 new_device uevent + device i2c-86 of_node + i2c-203 i2c-dev power + +There, we see the 0x71 MUX as ``7-0071``. Go inside it:: + + /sys/bus/i2c/devices/i2c-7$ cd 7-0071/ + /sys/bus/i2c/devices/i2c-7/7-0071$ ls -l + channel-0 channel-3 modalias power + channel-1 driver name subsystem + channel-2 idle_state of_node uevent + +Read the link ``channel-1`` using ``readlink`` or ``ls -l``:: + + /sys/bus/i2c/devices/i2c-7/7-0071$ readlink channel-1 + ../i2c-73 + +We find out that the channel 1 of 0x71 MUX on ``i2c-7`` is assigned +with a logical I2C bus number of 73. +Let us continue the journey to directory ``i2c-73`` in either ways:: + + # cd to i2c-73 under I2C Sysfs root + /sys/bus/i2c/devices/i2c-7/7-0071$ cd /sys/bus/i2c/devices/i2c-73 + /sys/bus/i2c/devices/i2c-73$ + + # cd the channel symbolic link + /sys/bus/i2c/devices/i2c-7/7-0071$ cd channel-1 + /sys/bus/i2c/devices/i2c-7/7-0071/channel-1$ + + # cd the link content + /sys/bus/i2c/devices/i2c-7/7-0071$ cd ../i2c-73 + /sys/bus/i2c/devices/i2c-7/i2c-73$ + +Either ways, you will end up in the directory of ``i2c-73``. Similar to above, +we can now find the 0x72 MUX and what logical I2C bus numbers +that its channels are assigned:: + + /sys/bus/i2c/devices/i2c-73$ ls + 73-0040 device i2c-83 new_device + 73-004e i2c-78 i2c-84 of_node + 73-0050 i2c-79 i2c-85 power + 73-0070 i2c-80 i2c-dev subsystem + 73-0072 i2c-81 mux_device uevent + delete_device i2c-82 name + /sys/bus/i2c/devices/i2c-73$ cd 73-0072 + /sys/bus/i2c/devices/i2c-73/73-0072$ ls + channel-0 channel-4 driver of_node + channel-1 channel-5 idle_state power + channel-2 channel-6 modalias subsystem + channel-3 channel-7 name uevent + /sys/bus/i2c/devices/i2c-73/73-0072$ readlink channel-3 + ../i2c-81 + +There, we find out the logical I2C bus number of the channel 3 of the 0x72 MUX +is 81. We can later use this number to switch to its own I2C Sysfs directory or +issue ``i2c-tools`` commands. + +Tip: Once you understand the I2C topology with MUX, command +`i2cdetect -l +`_ +in +`I2C Tools +`_ +can give you +an overview of the I2C topology easily, if it is available on your system. For +example:: + + $ i2cdetect -l | grep -e '\-73' -e _7 | sort -V + i2c-7 i2c npcm_i2c_7 I2C adapter + i2c-73 i2c i2c-7-mux (chan_id 1) I2C adapter + i2c-78 i2c i2c-73-mux (chan_id 0) I2C adapter + i2c-79 i2c i2c-73-mux (chan_id 1) I2C adapter + i2c-80 i2c i2c-73-mux (chan_id 2) I2C adapter + i2c-81 i2c i2c-73-mux (chan_id 3) I2C adapter + i2c-82 i2c i2c-73-mux (chan_id 4) I2C adapter + i2c-83 i2c i2c-73-mux (chan_id 5) I2C adapter + i2c-84 i2c i2c-73-mux (chan_id 6) I2C adapter + i2c-85 i2c i2c-73-mux (chan_id 7) I2C adapter + +Pinned Logical I2C Bus Number +----------------------------- + +If not specified in DTS, when an I2C MUX driver is applied and the MUX device is +successfully probed, the kernel will assign the MUX channels with a logical bus +number based on the current biggest logical bus number incrementally. For +example, if the system has ``i2c-15`` as the highest logical bus number, and a +4-channel MUX is applied successfully, we will have ``i2c-16`` for the +MUX channel 0, and all the way to ``i2c-19`` for the MUX channel 3. + +The kernel software developer is able to pin the fanout MUX channels to a static +logical I2C bus number in the DTS. This doc will not go through the details on +how to implement this in DTS, but we can see an example in: +`arch/arm/boot/dts/aspeed-bmc-facebook-wedge400.dts +<../../arch/arm/boot/dts/aspeed-bmc-facebook-wedge400.dts>`_ + +In the above example, there is an 8-channel I2C MUX at address 0x70 on physical +I2C bus 2. The channel 2 of the MUX is defined as ``imux18`` in DTS, +and pinned to logical I2C bus number 18 with the line of ``i2c18 = &imux18;`` +in section ``aliases``. + +Take it further, it is possible to design a logical I2C bus number schema that +can be easily remembered by humans or calculated arithmetically. For example, we +can pin the fanout channels of a MUX on bus 3 to start at 30. So 30 will be the +logical bus number of the channel 0 of the MUX on bus 3, and 37 will be the +logical bus number of the channel 7 of the MUX on bus 3. + +I2C Devices +=========== + +In previous sections, we mostly covered the I2C bus. In this section, let us see +what we can learn from the I2C device directory whose link name is in the format +of ``${bus}-${addr}``. The ``${bus}`` part in the name is a logical I2C bus +decimal number, while the ``${addr}`` part is a hex number of the I2C address +of each device. + +I2C Device Directory Content +---------------------------- + +Inside each I2C device directory, there is a file named ``name``. +This file tells what device name it was used for the kernel driver to +probe this device. Use command ``cat`` to read its content. For example:: + + /sys/bus/i2c/devices/i2c-73$ cat 73-0040/name + ina230 + /sys/bus/i2c/devices/i2c-73$ cat 73-0070/name + pca9546 + /sys/bus/i2c/devices/i2c-73$ cat 73-0072/name + pca9547 + +There is a symbolic link named ``driver`` to tell what Linux kernel driver was +used to probe this device:: + + /sys/bus/i2c/devices/i2c-73$ readlink -f 73-0040/driver + /sys/bus/i2c/drivers/ina2xx + /sys/bus/i2c/devices/i2c-73$ readlink -f 73-0072/driver + /sys/bus/i2c/drivers/pca954x + +But if the link ``driver`` does not exist at the first place, +it may mean that the kernel driver failed to probe this device due to +some errors. The error may be found in ``dmesg``:: + + /sys/bus/i2c/devices/i2c-73$ ls 73-0070/driver + ls: 73-0070/driver: No such file or directory + /sys/bus/i2c/devices/i2c-73$ dmesg | grep 73-0070 + pca954x 73-0070: probe failed + pca954x 73-0070: probe failed + +Depending on what the I2C device is and what kernel driver was used to probe the +device, we may have different content in the device directory. + +I2C MUX Device +-------------- + +While you may be already aware of this in previous sections, an I2C MUX device +will have symbolic link ``channel-*`` inside its device directory. +These symbolic links point to their logical I2C bus directories:: + + /sys/bus/i2c/devices/i2c-73$ ls -l 73-0072/channel-* + lrwxrwxrwx ... 73-0072/channel-0 -> ../i2c-78 + lrwxrwxrwx ... 73-0072/channel-1 -> ../i2c-79 + lrwxrwxrwx ... 73-0072/channel-2 -> ../i2c-80 + lrwxrwxrwx ... 73-0072/channel-3 -> ../i2c-81 + lrwxrwxrwx ... 73-0072/channel-4 -> ../i2c-82 + lrwxrwxrwx ... 73-0072/channel-5 -> ../i2c-83 + lrwxrwxrwx ... 73-0072/channel-6 -> ../i2c-84 + lrwxrwxrwx ... 73-0072/channel-7 -> ../i2c-85 + +I2C Sensor Device / Hwmon +------------------------- + +I2C sensor device is also common to see. If they are bound by a kernel hwmon +(Hardware Monitoring) driver successfully, you will see a ``hwmon`` directory +inside the I2C device directory. Keep digging into it, you will find the Hwmon +Sysfs for the I2C sensor device:: + + /sys/bus/i2c/devices/i2c-73/73-0040/hwmon/hwmon17$ ls + curr1_input in0_lcrit_alarm name subsystem + device in1_crit power uevent + in0_crit in1_crit_alarm power1_crit update_interval + in0_crit_alarm in1_input power1_crit_alarm + in0_input in1_lcrit power1_input + in0_lcrit in1_lcrit_alarm shunt_resistor + +For more info on the Hwmon Sysfs, refer to the doc: + +`Naming and data format standards for sysfs files +<../hwmon/sysfs-interface.rst>`_ + +Instantiate I2C Devices in I2C Sysfs +------------------------------------ + +Refer to the doc: + +`How to instantiate I2C devices, Method 4: Instantiate from user-space +`_ -- cgit v1.2.3 From cd039afa0ad86e1f01921cc5abf7f80d2449543a Mon Sep 17 00:00:00 2001 From: Mike Snitzer Date: Fri, 25 Jun 2021 15:18:59 -0400 Subject: dm writecache: add "cleaner" and "max_age" to Documentation Backfill missing Documentation. Fixes: 93de44eb3fc8 ("dm writecache: implement the "cleaner" policy") Fixes: 3923d4854e18 ("dm writecache: implement gradual cleanup") Signed-off-by: Mike Snitzer --- Documentation/admin-guide/device-mapper/writecache.rst | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) (limited to 'Documentation') diff --git a/Documentation/admin-guide/device-mapper/writecache.rst b/Documentation/admin-guide/device-mapper/writecache.rst index dce0184e07ca..c181f26af769 100644 --- a/Documentation/admin-guide/device-mapper/writecache.rst +++ b/Documentation/admin-guide/device-mapper/writecache.rst @@ -53,6 +53,21 @@ Constructor parameters: - some underlying devices perform better with fua, some with nofua. The user should test it + cleaner + when this option is activated (either in the constructor + arguments or by a message), the cache will not promote + new writes (however, writes to already cached blocks are + promoted, to avoid data corruption due to misordered + writes) and it will gradually writeback any cached + data. The userspace can then monitor the cleaning + process with "dmsetup status". When the number of cached + blocks drops to zero, userspace can unload the + dm-writecache target and replace it with dm-linear or + other targets. + max_age n + specifies the maximum age of a block in milliseconds. If + a block is stored in the cache for too long, it will be + written to the underlying device and cleaned up. Status: 1. error indicator - 0 if there was no error, otherwise error number @@ -77,3 +92,5 @@ Messages: 5. resume the device, so that it will use the linear target 6. the cache device is now inactive and it can be deleted + cleaner + See above "cleaner" constructor documentation. -- cgit v1.2.3 From 611c3e168b1c5b6cf81e6deb8f6b4eb83f6b53fd Mon Sep 17 00:00:00 2001 From: Mikulas Patocka Date: Mon, 21 Jun 2021 05:22:21 -0400 Subject: dm writecache: add optional "metadata_only" parameter Add a "metadata_only" parameter that when present: only metadata is promoted to the cache. This option improves performance for heavier REQ_META workloads (e.g. device-mapper-test-suite's "git clone and checkout" benchmark improves from 341s to 312s). Signed-off-by: Mikulas Patocka Signed-off-by: Mike Snitzer --- Documentation/admin-guide/device-mapper/writecache.rst | 3 +++ 1 file changed, 3 insertions(+) (limited to 'Documentation') diff --git a/Documentation/admin-guide/device-mapper/writecache.rst b/Documentation/admin-guide/device-mapper/writecache.rst index c181f26af769..977f82b5a811 100644 --- a/Documentation/admin-guide/device-mapper/writecache.rst +++ b/Documentation/admin-guide/device-mapper/writecache.rst @@ -68,6 +68,9 @@ Constructor parameters: specifies the maximum age of a block in milliseconds. If a block is stored in the cache for too long, it will be written to the underlying device and cleaned up. + metadata_only + only metadata is promoted to the cache. This option + improves performance for heavier REQ_META workloads. Status: 1. error indicator - 0 if there was no error, otherwise error number -- cgit v1.2.3 From f46b16520a087e892a189db9c23ccf7e9bb5fa69 Mon Sep 17 00:00:00 2001 From: Daniel Bristot de Oliveira Date: Tue, 22 Jun 2021 16:42:22 +0200 Subject: trace/hwlat: Implement the per-cpu mode Implements the per-cpu mode in which a sampling thread is created for each cpu in the "cpus" (and tracing_mask). The per-cpu mode has the potention to speed up the hwlat detection by running on multiple CPUs at the same time, at the cost of higher cpu usage with irqs disabled. Use with care. [ Changed get_cpu_data() to static. Reported-by: kernel test robot ] Link: https://lkml.kernel.org/r/ec06d0ab340e8460d293772faba19ad8a5c371aa.1624372313.git.bristot@redhat.com Cc: Phil Auld Cc: Sebastian Andrzej Siewior Cc: Kate Carcia Cc: Jonathan Corbet Cc: Ingo Molnar Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: Alexandre Chartre Cc: Clark Willaims Cc: John Kacur Cc: Juri Lelli Cc: Borislav Petkov Cc: "H. Peter Anvin" Cc: x86@kernel.org Cc: linux-doc@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Daniel Bristot de Oliveira Signed-off-by: Steven Rostedt (VMware) --- Documentation/trace/hwlat_detector.rst | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/trace/hwlat_detector.rst b/Documentation/trace/hwlat_detector.rst index 4d952df0586a..de94b499b0bc 100644 --- a/Documentation/trace/hwlat_detector.rst +++ b/Documentation/trace/hwlat_detector.rst @@ -78,10 +78,11 @@ in /sys/kernel/tracing: - hwlat_detector/window - amount of time between (width) runs (usecs) - hwlat_detector/mode - the thread mode -By default, the hwlat detector's kernel thread will migrate across each CPU +By default, one hwlat detector's kernel thread will migrate across each CPU specified in cpumask at the beginning of a new window, in a round-robin fashion. This behavior can be changed by changing the thread mode, the available options are: - none: do not force migration - round-robin: migrate across each CPU specified in cpumask [default] + - per-cpu: create one thread for each cpu in tracing_cpumask -- cgit v1.2.3 From feb29cc744c1d4d503138708964f21840c23b3ea Mon Sep 17 00:00:00 2001 From: Geert Uytterhoeven Date: Fri, 11 Jun 2021 14:30:47 +0200 Subject: dt-bindings: clock: gpio-mux-clock: Convert to json-schema Convert the simple GPIO clock multiplexer Device Tree binding documentation to json-schema. Signed-off-by: Geert Uytterhoeven Link: https://lore.kernel.org/r/14cb3b4da446f26a4780e0bd1b58788eb6085d05.1623414619.git.geert+renesas@glider.be Reviewed-by: Rob Herring Signed-off-by: Stephen Boyd --- .../devicetree/bindings/clock/gpio-mux-clock.txt | 19 --------- .../devicetree/bindings/clock/gpio-mux-clock.yaml | 45 ++++++++++++++++++++++ 2 files changed, 45 insertions(+), 19 deletions(-) delete mode 100644 Documentation/devicetree/bindings/clock/gpio-mux-clock.txt create mode 100644 Documentation/devicetree/bindings/clock/gpio-mux-clock.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/gpio-mux-clock.txt b/Documentation/devicetree/bindings/clock/gpio-mux-clock.txt deleted file mode 100644 index 2be1e038ca62..000000000000 --- a/Documentation/devicetree/bindings/clock/gpio-mux-clock.txt +++ /dev/null @@ -1,19 +0,0 @@ -Binding for simple gpio clock multiplexer. - -This binding uses the common clock binding[1]. - -[1] Documentation/devicetree/bindings/clock/clock-bindings.txt - -Required properties: -- compatible : shall be "gpio-mux-clock". -- clocks: list of two references to parent clocks. -- #clock-cells : from common clock binding; shall be set to 0. -- select-gpios : GPIO reference for selecting the parent clock. - -Example: - clock { - compatible = "gpio-mux-clock"; - clocks = <&parentclk1>, <&parentclk2>; - #clock-cells = <0>; - select-gpios = <&gpio 1 GPIO_ACTIVE_HIGH>; - }; diff --git a/Documentation/devicetree/bindings/clock/gpio-mux-clock.yaml b/Documentation/devicetree/bindings/clock/gpio-mux-clock.yaml new file mode 100644 index 000000000000..1e21f8b3a4ff --- /dev/null +++ b/Documentation/devicetree/bindings/clock/gpio-mux-clock.yaml @@ -0,0 +1,45 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/gpio-mux-clock.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Simple GPIO clock multiplexer + +maintainers: + - Sergej Sawazki + +properties: + compatible: + const: gpio-mux-clock + + clocks: + items: + - description: First parent clock + - description: Second parent clock + + '#clock-cells': + const: 0 + + select-gpios: + description: GPIO reference for selecting the parent clock. + maxItems: 1 + +required: + - compatible + - clocks + - '#clock-cells' + - select-gpios + +additionalProperties: false + +examples: + - | + #include + + clock { + compatible = "gpio-mux-clock"; + clocks = <&parentclk1>, <&parentclk2>; + #clock-cells = <0>; + select-gpios = <&gpio 1 GPIO_ACTIVE_HIGH>; + }; -- cgit v1.2.3 From 4865ed13604538991c247db7756f3046102cce6d Mon Sep 17 00:00:00 2001 From: Bjorn Andersson Date: Tue, 8 Jun 2021 10:49:43 -0700 Subject: dt-bindings: remoteproc: qcom: pas: Add SC8180X adsp, cdsp and mpss Add compatibles for the Audio DSP, Compute DSP and Modem subsystem found in the Qualcomm SC8180x to the Peripheral Authentication Service remoteproc binding. Acked-by: Rob Herring Link: https://lore.kernel.org/r/20210608174944.2045215-1-bjorn.andersson@linaro.org Signed-off-by: Bjorn Andersson --- Documentation/devicetree/bindings/remoteproc/qcom,adsp.yaml | 11 +++++++++++ 1 file changed, 11 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,adsp.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,adsp.yaml index 9ea05e608bc1..c597ccced623 100644 --- a/Documentation/devicetree/bindings/remoteproc/qcom,adsp.yaml +++ b/Documentation/devicetree/bindings/remoteproc/qcom,adsp.yaml @@ -25,6 +25,9 @@ properties: - qcom,qcs404-cdsp-pas - qcom,qcs404-wcss-pas - qcom,sc7180-mpss-pas + - qcom,sc8180x-adsp-pas + - qcom,sc8180x-cdsp-pas + - qcom,sc8180x-mpss-pas - qcom,sdm845-adsp-pas - qcom,sdm845-cdsp-pas - qcom,sdx55-mpss-pas @@ -143,6 +146,9 @@ allOf: - qcom,msm8998-adsp-pas - qcom,qcs404-adsp-pas - qcom,qcs404-wcss-pas + - qcom,sc8180x-adsp-pas + - qcom,sc8180x-cdsp-pas + - qcom,sc8180x-mpss-pas - qcom,sdm845-adsp-pas - qcom,sdm845-cdsp-pas - qcom,sm8150-adsp-pas @@ -249,6 +255,8 @@ allOf: - qcom,qcs404-adsp-pas - qcom,qcs404-cdsp-pas - qcom,qcs404-wcss-pas + - qcom,sc8180x-adsp-pas + - qcom,sc8180x-cdsp-pas - qcom,sdm845-adsp-pas - qcom,sdm845-cdsp-pas - qcom,sm8150-adsp-pas @@ -283,6 +291,7 @@ allOf: contains: enum: - qcom,sc7180-mpss-pas + - qcom,sc8180x-mpss-pas - qcom,sdx55-mpss-pas - qcom,sm8150-mpss-pas - qcom,sm8350-mpss-pas @@ -430,6 +439,8 @@ allOf: compatible: contains: enum: + - qcom,sc8180x-adsp-pas + - qcom,sc8180x-cdsp-pas - qcom,sm8150-slpi-pas - qcom,sm8250-adsp-pas - qcom,sm8250-slpi-pas -- cgit v1.2.3 From bce29ac9ce0bb0b0b146b687ab978378c21e9078 Mon Sep 17 00:00:00 2001 From: Daniel Bristot de Oliveira Date: Tue, 22 Jun 2021 16:42:27 +0200 Subject: trace: Add osnoise tracer In the context of high-performance computing (HPC), the Operating System Noise (*osnoise*) refers to the interference experienced by an application due to activities inside the operating system. In the context of Linux, NMIs, IRQs, SoftIRQs, and any other system thread can cause noise to the system. Moreover, hardware-related jobs can also cause noise, for example, via SMIs. The osnoise tracer leverages the hwlat_detector by running a similar loop with preemption, SoftIRQs and IRQs enabled, thus allowing all the sources of *osnoise* during its execution. Using the same approach of hwlat, osnoise takes note of the entry and exit point of any source of interferences, increasing a per-cpu interference counter. The osnoise tracer also saves an interference counter for each source of interference. The interference counter for NMI, IRQs, SoftIRQs, and threads is increased anytime the tool observes these interferences' entry events. When a noise happens without any interference from the operating system level, the hardware noise counter increases, pointing to a hardware-related noise. In this way, osnoise can account for any source of interference. At the end of the period, the osnoise tracer prints the sum of all noise, the max single noise, the percentage of CPU available for the thread, and the counters for the noise sources. Usage Write the ASCII text "osnoise" into the current_tracer file of the tracing system (generally mounted at /sys/kernel/tracing). For example:: [root@f32 ~]# cd /sys/kernel/tracing/ [root@f32 tracing]# echo osnoise > current_tracer It is possible to follow the trace by reading the trace trace file:: [root@f32 tracing]# cat trace # tracer: osnoise # # _-----=> irqs-off # / _----=> need-resched # | / _---=> hardirq/softirq # || / _--=> preempt-depth MAX # || / SINGLE Interference counters: # |||| RUNTIME NOISE % OF CPU NOISE +-----------------------------+ # TASK-PID CPU# |||| TIMESTAMP IN US IN US AVAILABLE IN US HW NMI IRQ SIRQ THREAD # | | | |||| | | | | | | | | | | <...>-859 [000] .... 81.637220: 1000000 190 99.98100 9 18 0 1007 18 1 <...>-860 [001] .... 81.638154: 1000000 656 99.93440 74 23 0 1006 16 3 <...>-861 [002] .... 81.638193: 1000000 5675 99.43250 202 6 0 1013 25 21 <...>-862 [003] .... 81.638242: 1000000 125 99.98750 45 1 0 1011 23 0 <...>-863 [004] .... 81.638260: 1000000 1721 99.82790 168 7 0 1002 49 41 <...>-864 [005] .... 81.638286: 1000000 263 99.97370 57 6 0 1006 26 2 <...>-865 [006] .... 81.638302: 1000000 109 99.98910 21 3 0 1006 18 1 <...>-866 [007] .... 81.638326: 1000000 7816 99.21840 107 8 0 1016 39 19 In addition to the regular trace fields (from TASK-PID to TIMESTAMP), the tracer prints a message at the end of each period for each CPU that is running an osnoise/CPU thread. The osnoise specific fields report: - The RUNTIME IN USE reports the amount of time in microseconds that the osnoise thread kept looping reading the time. - The NOISE IN US reports the sum of noise in microseconds observed by the osnoise tracer during the associated runtime. - The % OF CPU AVAILABLE reports the percentage of CPU available for the osnoise thread during the runtime window. - The MAX SINGLE NOISE IN US reports the maximum single noise observed during the runtime window. - The Interference counters display how many each of the respective interference happened during the runtime window. Note that the example above shows a high number of HW noise samples. The reason being is that this sample was taken on a virtual machine, and the host interference is detected as a hardware interference. Tracer options The tracer has a set of options inside the osnoise directory, they are: - osnoise/cpus: CPUs at which a osnoise thread will execute. - osnoise/period_us: the period of the osnoise thread. - osnoise/runtime_us: how long an osnoise thread will look for noise. - osnoise/stop_tracing_us: stop the system tracing if a single noise higher than the configured value happens. Writing 0 disables this option. - osnoise/stop_tracing_total_us: stop the system tracing if total noise higher than the configured value happens. Writing 0 disables this option. - tracing_threshold: the minimum delta between two time() reads to be considered as noise, in us. When set to 0, the default value will be used, which is currently 5 us. Additional Tracing In addition to the tracer, a set of tracepoints were added to facilitate the identification of the osnoise source. - osnoise:sample_threshold: printed anytime a noise is higher than the configurable tolerance_ns. - osnoise:nmi_noise: noise from NMI, including the duration. - osnoise:irq_noise: noise from an IRQ, including the duration. - osnoise:softirq_noise: noise from a SoftIRQ, including the duration. - osnoise:thread_noise: noise from a thread, including the duration. Note that all the values are *net values*. For example, if while osnoise is running, another thread preempts the osnoise thread, it will start a thread_noise duration at the start. Then, an IRQ takes place, preempting the thread_noise, starting a irq_noise. When the IRQ ends its execution, it will compute its duration, and this duration will be subtracted from the thread_noise, in such a way as to avoid the double accounting of the IRQ execution. This logic is valid for all sources of noise. Here is one example of the usage of these tracepoints:: osnoise/8-961 [008] d.h. 5789.857532: irq_noise: local_timer:236 start 5789.857529929 duration 1845 ns osnoise/8-961 [008] dNh. 5789.858408: irq_noise: local_timer:236 start 5789.858404871 duration 2848 ns migration/8-54 [008] d... 5789.858413: thread_noise: migration/8:54 start 5789.858409300 duration 3068 ns osnoise/8-961 [008] .... 5789.858413: sample_threshold: start 5789.858404555 duration 8723 ns interferences 2 In this example, a noise sample of 8 microseconds was reported in the last line, pointing to two interferences. Looking backward in the trace, the two previous entries were about the migration thread running after a timer IRQ execution. The first event is not part of the noise because it took place one millisecond before. It is worth noticing that the sum of the duration reported in the tracepoints is smaller than eight us reported in the sample_threshold. The reason roots in the overhead of the entry and exit code that happens before and after any interference execution. This justifies the dual approach: measuring thread and tracing. Link: https://lkml.kernel.org/r/e649467042d60e7b62714c9c6751a56299d15119.1624372313.git.bristot@redhat.com Cc: Phil Auld Cc: Sebastian Andrzej Siewior Cc: Kate Carcia Cc: Jonathan Corbet Cc: Ingo Molnar Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: Alexandre Chartre Cc: Clark Willaims Cc: John Kacur Cc: Juri Lelli Cc: Borislav Petkov Cc: "H. Peter Anvin" Cc: x86@kernel.org Cc: linux-doc@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Daniel Bristot de Oliveira [ Made the following functions static: trace_irqentry_callback() trace_irqexit_callback() trace_intel_irqentry_callback() trace_intel_irqexit_callback() Added to include/trace.h: osnoise_arch_register() osnoise_arch_unregister() Fixed define logic for LATENCY_FS_NOTIFY Reported-by: kernel test robot ] Signed-off-by: Steven Rostedt (VMware) --- Documentation/trace/index.rst | 1 + Documentation/trace/osnoise-tracer.rst | 152 +++++++++++++++++++++++++++++++++ 2 files changed, 153 insertions(+) create mode 100644 Documentation/trace/osnoise-tracer.rst (limited to 'Documentation') diff --git a/Documentation/trace/index.rst b/Documentation/trace/index.rst index f634b36fd3aa..608107b27cc0 100644 --- a/Documentation/trace/index.rst +++ b/Documentation/trace/index.rst @@ -23,6 +23,7 @@ Linux Tracing Technologies histogram-design boottime-trace hwlat_detector + osnoise-tracer intel_th ring-buffer-design stm diff --git a/Documentation/trace/osnoise-tracer.rst b/Documentation/trace/osnoise-tracer.rst new file mode 100644 index 000000000000..37a3c10fb216 --- /dev/null +++ b/Documentation/trace/osnoise-tracer.rst @@ -0,0 +1,152 @@ +============== +OSNOISE Tracer +============== + +In the context of high-performance computing (HPC), the Operating System +Noise (*osnoise*) refers to the interference experienced by an application +due to activities inside the operating system. In the context of Linux, +NMIs, IRQs, SoftIRQs, and any other system thread can cause noise to the +system. Moreover, hardware-related jobs can also cause noise, for example, +via SMIs. + +hwlat_detector is one of the tools used to identify the most complex +source of noise: *hardware noise*. + +In a nutshell, the hwlat_detector creates a thread that runs +periodically for a given period. At the beginning of a period, the thread +disables interrupt and starts sampling. While running, the hwlatd +thread reads the time in a loop. As interrupts are disabled, threads, +IRQs, and SoftIRQs cannot interfere with the hwlatd thread. Hence, the +cause of any gap between two different reads of the time roots either on +NMI or in the hardware itself. At the end of the period, hwlatd enables +interrupts and reports the max observed gap between the reads. It also +prints a NMI occurrence counter. If the output does not report NMI +executions, the user can conclude that the hardware is the culprit for +the latency. The hwlat detects the NMI execution by observing +the entry and exit of a NMI. + +The osnoise tracer leverages the hwlat_detector by running a +similar loop with preemption, SoftIRQs and IRQs enabled, thus allowing +all the sources of *osnoise* during its execution. Using the same approach +of hwlat, osnoise takes note of the entry and exit point of any +source of interferences, increasing a per-cpu interference counter. The +osnoise tracer also saves an interference counter for each source of +interference. The interference counter for NMI, IRQs, SoftIRQs, and +threads is increased anytime the tool observes these interferences' entry +events. When a noise happens without any interference from the operating +system level, the hardware noise counter increases, pointing to a +hardware-related noise. In this way, osnoise can account for any +source of interference. At the end of the period, the osnoise tracer +prints the sum of all noise, the max single noise, the percentage of CPU +available for the thread, and the counters for the noise sources. + +Usage +----- + +Write the ASCII text "osnoise" into the current_tracer file of the +tracing system (generally mounted at /sys/kernel/tracing). + +For example:: + + [root@f32 ~]# cd /sys/kernel/tracing/ + [root@f32 tracing]# echo osnoise > current_tracer + +It is possible to follow the trace by reading the trace trace file:: + + [root@f32 tracing]# cat trace + # tracer: osnoise + # + # _-----=> irqs-off + # / _----=> need-resched + # | / _---=> hardirq/softirq + # || / _--=> preempt-depth MAX + # || / SINGLE Interference counters: + # |||| RUNTIME NOISE % OF CPU NOISE +-----------------------------+ + # TASK-PID CPU# |||| TIMESTAMP IN US IN US AVAILABLE IN US HW NMI IRQ SIRQ THREAD + # | | | |||| | | | | | | | | | | + <...>-859 [000] .... 81.637220: 1000000 190 99.98100 9 18 0 1007 18 1 + <...>-860 [001] .... 81.638154: 1000000 656 99.93440 74 23 0 1006 16 3 + <...>-861 [002] .... 81.638193: 1000000 5675 99.43250 202 6 0 1013 25 21 + <...>-862 [003] .... 81.638242: 1000000 125 99.98750 45 1 0 1011 23 0 + <...>-863 [004] .... 81.638260: 1000000 1721 99.82790 168 7 0 1002 49 41 + <...>-864 [005] .... 81.638286: 1000000 263 99.97370 57 6 0 1006 26 2 + <...>-865 [006] .... 81.638302: 1000000 109 99.98910 21 3 0 1006 18 1 + <...>-866 [007] .... 81.638326: 1000000 7816 99.21840 107 8 0 1016 39 19 + +In addition to the regular trace fields (from TASK-PID to TIMESTAMP), the +tracer prints a message at the end of each period for each CPU that is +running an osnoise/ thread. The osnoise specific fields report: + + - The RUNTIME IN USE reports the amount of time in microseconds that + the osnoise thread kept looping reading the time. + - The NOISE IN US reports the sum of noise in microseconds observed + by the osnoise tracer during the associated runtime. + - The % OF CPU AVAILABLE reports the percentage of CPU available for + the osnoise thread during the runtime window. + - The MAX SINGLE NOISE IN US reports the maximum single noise observed + during the runtime window. + - The Interference counters display how many each of the respective + interference happened during the runtime window. + +Note that the example above shows a high number of HW noise samples. +The reason being is that this sample was taken on a virtual machine, +and the host interference is detected as a hardware interference. + +Tracer options +--------------------- + +The tracer has a set of options inside the osnoise directory, they are: + + - osnoise/cpus: CPUs at which a osnoise thread will execute. + - osnoise/period_us: the period of the osnoise thread. + - osnoise/runtime_us: how long an osnoise thread will look for noise. + - osnoise/stop_tracing_us: stop the system tracing if a single noise + higher than the configured value happens. Writing 0 disables this + option. + - osnoise/stop_tracing_total_us: stop the system tracing if total noise + higher than the configured value happens. Writing 0 disables this + option. + - tracing_threshold: the minimum delta between two time() reads to be + considered as noise, in us. When set to 0, the default value will + will be used, which is currently 5 us. + +Additional Tracing +------------------ + +In addition to the tracer, a set of tracepoints were added to +facilitate the identification of the osnoise source. + + - osnoise:sample_threshold: printed anytime a noise is higher than + the configurable tolerance_ns. + - osnoise:nmi_noise: noise from NMI, including the duration. + - osnoise:irq_noise: noise from an IRQ, including the duration. + - osnoise:softirq_noise: noise from a SoftIRQ, including the + duration. + - osnoise:thread_noise: noise from a thread, including the duration. + +Note that all the values are *net values*. For example, if while osnoise +is running, another thread preempts the osnoise thread, it will start a +thread_noise duration at the start. Then, an IRQ takes place, preempting +the thread_noise, starting a irq_noise. When the IRQ ends its execution, +it will compute its duration, and this duration will be subtracted from +the thread_noise, in such a way as to avoid the double accounting of the +IRQ execution. This logic is valid for all sources of noise. + +Here is one example of the usage of these tracepoints:: + + osnoise/8-961 [008] d.h. 5789.857532: irq_noise: local_timer:236 start 5789.857529929 duration 1845 ns + osnoise/8-961 [008] dNh. 5789.858408: irq_noise: local_timer:236 start 5789.858404871 duration 2848 ns + migration/8-54 [008] d... 5789.858413: thread_noise: migration/8:54 start 5789.858409300 duration 3068 ns + osnoise/8-961 [008] .... 5789.858413: sample_threshold: start 5789.858404555 duration 8812 ns interferences 2 + +In this example, a noise sample of 8 microseconds was reported in the last +line, pointing to two interferences. Looking backward in the trace, the +two previous entries were about the migration thread running after a +timer IRQ execution. The first event is not part of the noise because +it took place one millisecond before. + +It is worth noticing that the sum of the duration reported in the +tracepoints is smaller than eight us reported in the sample_threshold. +The reason roots in the overhead of the entry and exit code that happens +before and after any interference execution. This justifies the dual +approach: measuring thread and tracing. -- cgit v1.2.3 From a955d7eac1779b437ceb24fc352026a2cbcec140 Mon Sep 17 00:00:00 2001 From: Daniel Bristot de Oliveira Date: Tue, 22 Jun 2021 16:42:28 +0200 Subject: trace: Add timerlat tracer The timerlat tracer aims to help the preemptive kernel developers to found souces of wakeup latencies of real-time threads. Like cyclictest, the tracer sets a periodic timer that wakes up a thread. The thread then computes a *wakeup latency* value as the difference between the *current time* and the *absolute time* that the timer was set to expire. The main goal of timerlat is tracing in such a way to help kernel developers. Usage Write the ASCII text "timerlat" into the current_tracer file of the tracing system (generally mounted at /sys/kernel/tracing). For example: [root@f32 ~]# cd /sys/kernel/tracing/ [root@f32 tracing]# echo timerlat > current_tracer It is possible to follow the trace by reading the trace trace file: [root@f32 tracing]# cat trace # tracer: timerlat # # _-----=> irqs-off # / _----=> need-resched # | / _---=> hardirq/softirq # || / _--=> preempt-depth # || / # |||| ACTIVATION # TASK-PID CPU# |||| TIMESTAMP ID CONTEXT LATENCY # | | | |||| | | | | -0 [000] d.h1 54.029328: #1 context irq timer_latency 932 ns <...>-867 [000] .... 54.029339: #1 context thread timer_latency 11700 ns -0 [001] dNh1 54.029346: #1 context irq timer_latency 2833 ns <...>-868 [001] .... 54.029353: #1 context thread timer_latency 9820 ns -0 [000] d.h1 54.030328: #2 context irq timer_latency 769 ns <...>-867 [000] .... 54.030330: #2 context thread timer_latency 3070 ns -0 [001] d.h1 54.030344: #2 context irq timer_latency 935 ns <...>-868 [001] .... 54.030347: #2 context thread timer_latency 4351 ns The tracer creates a per-cpu kernel thread with real-time priority that prints two lines at every activation. The first is the *timer latency* observed at the *hardirq* context before the activation of the thread. The second is the *timer latency* observed by the thread, which is the same level that cyclictest reports. The ACTIVATION ID field serves to relate the *irq* execution to its respective *thread* execution. The irq/thread splitting is important to clarify at which context the unexpected high value is coming from. The *irq* context can be delayed by hardware related actions, such as SMIs, NMIs, IRQs or by a thread masking interrupts. Once the timer happens, the delay can also be influenced by blocking caused by threads. For example, by postponing the scheduler execution via preempt_disable(), by the scheduler execution, or by masking interrupts. Threads can also be delayed by the interference from other threads and IRQs. The timerlat can also take advantage of the osnoise: traceevents. For example: [root@f32 ~]# cd /sys/kernel/tracing/ [root@f32 tracing]# echo timerlat > current_tracer [root@f32 tracing]# echo osnoise > set_event [root@f32 tracing]# echo 25 > osnoise/stop_tracing_total_us [root@f32 tracing]# tail -10 trace cc1-87882 [005] d..h... 548.771078: #402268 context irq timer_latency 1585 ns cc1-87882 [005] dNLh1.. 548.771082: irq_noise: local_timer:236 start 548.771077442 duration 4597 ns cc1-87882 [005] dNLh2.. 548.771083: irq_noise: reschedule:253 start 548.771083017 duration 56 ns cc1-87882 [005] dNLh2.. 548.771086: irq_noise: call_function_single:251 start 548.771083811 duration 2048 ns cc1-87882 [005] dNLh2.. 548.771088: irq_noise: call_function_single:251 start 548.771086814 duration 1495 ns cc1-87882 [005] dNLh2.. 548.771091: irq_noise: call_function_single:251 start 548.771089194 duration 1558 ns cc1-87882 [005] dNLh2.. 548.771094: irq_noise: call_function_single:251 start 548.771091719 duration 1932 ns cc1-87882 [005] dNLh2.. 548.771096: irq_noise: call_function_single:251 start 548.771094696 duration 1050 ns cc1-87882 [005] d...3.. 548.771101: thread_noise: cc1:87882 start 548.771078243 duration 10909 ns timerlat/5-1035 [005] ....... 548.771103: #402268 context thread timer_latency 25960 ns For further information see: Documentation/trace/timerlat-tracer.rst Link: https://lkml.kernel.org/r/71f18efc013e1194bcaea1e54db957de2b19ba62.1624372313.git.bristot@redhat.com Cc: Phil Auld Cc: Sebastian Andrzej Siewior Cc: Kate Carcia Cc: Jonathan Corbet Cc: Ingo Molnar Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: Alexandre Chartre Cc: Clark Willaims Cc: John Kacur Cc: Juri Lelli Cc: Borislav Petkov Cc: "H. Peter Anvin" Cc: x86@kernel.org Cc: linux-doc@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Daniel Bristot de Oliveira Signed-off-by: Steven Rostedt (VMware) --- Documentation/trace/index.rst | 1 + Documentation/trace/timerlat-tracer.rst | 181 ++++++++++++++++++++++++++++++++ 2 files changed, 182 insertions(+) create mode 100644 Documentation/trace/timerlat-tracer.rst (limited to 'Documentation') diff --git a/Documentation/trace/index.rst b/Documentation/trace/index.rst index 608107b27cc0..3769b9b7aed8 100644 --- a/Documentation/trace/index.rst +++ b/Documentation/trace/index.rst @@ -24,6 +24,7 @@ Linux Tracing Technologies boottime-trace hwlat_detector osnoise-tracer + timerlat-tracer intel_th ring-buffer-design stm diff --git a/Documentation/trace/timerlat-tracer.rst b/Documentation/trace/timerlat-tracer.rst new file mode 100644 index 000000000000..c7cbb557aee7 --- /dev/null +++ b/Documentation/trace/timerlat-tracer.rst @@ -0,0 +1,181 @@ +############### +Timerlat tracer +############### + +The timerlat tracer aims to help the preemptive kernel developers to +find souces of wakeup latencies of real-time threads. Like cyclictest, +the tracer sets a periodic timer that wakes up a thread. The thread then +computes a *wakeup latency* value as the difference between the *current +time* and the *absolute time* that the timer was set to expire. The main +goal of timerlat is tracing in such a way to help kernel developers. + +Usage +----- + +Write the ASCII text "timerlat" into the current_tracer file of the +tracing system (generally mounted at /sys/kernel/tracing). + +For example:: + + [root@f32 ~]# cd /sys/kernel/tracing/ + [root@f32 tracing]# echo timerlat > current_tracer + +It is possible to follow the trace by reading the trace trace file:: + + [root@f32 tracing]# cat trace + # tracer: timerlat + # + # _-----=> irqs-off + # / _----=> need-resched + # | / _---=> hardirq/softirq + # || / _--=> preempt-depth + # || / + # |||| ACTIVATION + # TASK-PID CPU# |||| TIMESTAMP ID CONTEXT LATENCY + # | | | |||| | | | | + -0 [000] d.h1 54.029328: #1 context irq timer_latency 932 ns + <...>-867 [000] .... 54.029339: #1 context thread timer_latency 11700 ns + -0 [001] dNh1 54.029346: #1 context irq timer_latency 2833 ns + <...>-868 [001] .... 54.029353: #1 context thread timer_latency 9820 ns + -0 [000] d.h1 54.030328: #2 context irq timer_latency 769 ns + <...>-867 [000] .... 54.030330: #2 context thread timer_latency 3070 ns + -0 [001] d.h1 54.030344: #2 context irq timer_latency 935 ns + <...>-868 [001] .... 54.030347: #2 context thread timer_latency 4351 ns + + +The tracer creates a per-cpu kernel thread with real-time priority that +prints two lines at every activation. The first is the *timer latency* +observed at the *hardirq* context before the activation of the thread. +The second is the *timer latency* observed by the thread. The ACTIVATION +ID field serves to relate the *irq* execution to its respective *thread* +execution. + +The *irq*/*thread* splitting is important to clarify at which context +the unexpected high value is coming from. The *irq* context can be +delayed by hardware related actions, such as SMIs, NMIs, IRQs +or by a thread masking interrupts. Once the timer happens, the delay +can also be influenced by blocking caused by threads. For example, by +postponing the scheduler execution via preempt_disable(), by the +scheduler execution, or by masking interrupts. Threads can +also be delayed by the interference from other threads and IRQs. + +Tracer options +--------------------- + +The timerlat tracer is built on top of osnoise tracer. +So its configuration is also done in the osnoise/ config +directory. The timerlat configs are: + + - cpus: CPUs at which a timerlat thread will execute. + - timerlat_period_us: the period of the timerlat thread. + - osnoise/stop_tracing_us: stop the system tracing if a + timer latency at the *irq* context higher than the configured + value happens. Writing 0 disables this option. + - stop_tracing_total_us: stop the system tracing if a + timer latency at the *thread* context higher than the configured + value happens. Writing 0 disables this option. + - print_stack: save the stack of the IRQ ocurrence, and print + it afte the *thread context* event". + +timerlat and osnoise +---------------------------- + +The timerlat can also take advantage of the osnoise: traceevents. +For example:: + + [root@f32 ~]# cd /sys/kernel/tracing/ + [root@f32 tracing]# echo timerlat > current_tracer + [root@f32 tracing]# echo 1 > events/osnoise/enable + [root@f32 tracing]# echo 25 > osnoise/stop_tracing_total_us + [root@f32 tracing]# tail -10 trace + cc1-87882 [005] d..h... 548.771078: #402268 context irq timer_latency 13585 ns + cc1-87882 [005] dNLh1.. 548.771082: irq_noise: local_timer:236 start 548.771077442 duration 7597 ns + cc1-87882 [005] dNLh2.. 548.771099: irq_noise: qxl:21 start 548.771085017 duration 7139 ns + cc1-87882 [005] d...3.. 548.771102: thread_noise: cc1:87882 start 548.771078243 duration 9909 ns + timerlat/5-1035 [005] ....... 548.771104: #402268 context thread timer_latency 39960 ns + +In this case, the root cause of the timer latency does not point to a +single cause, but to multiple ones. Firstly, the timer IRQ was delayed +for 13 us, which may point to a long IRQ disabled section (see IRQ +stacktrace section). Then the timer interrupt that wakes up the timerlat +thread took 7597 ns, and the qxl:21 device IRQ took 7139 ns. Finally, +the cc1 thread noise took 9909 ns of time before the context switch. +Such pieces of evidence are useful for the developer to use other +tracing methods to figure out how to debug and optimize the system. + +It is worth mentioning that the *duration* values reported +by the osnoise: events are *net* values. For example, the +thread_noise does not include the duration of the overhead caused +by the IRQ execution (which indeed accounted for 12736 ns). But +the values reported by the timerlat tracer (timerlat_latency) +are *gross* values. + +The art below illustrates a CPU timeline and how the timerlat tracer +observes it at the top and the osnoise: events at the bottom. Each "-" +in the timelines means circa 1 us, and the time moves ==>:: + + External timer irq thread + clock latency latency + event 13585 ns 39960 ns + | ^ ^ + v | | + |-------------| | + |-------------+-------------------------| + ^ ^ + ======================================================================== + [tmr irq] [dev irq] + [another thread...^ v..^ v.......][timerlat/ thread] <-- CPU timeline + ========================================================================= + |-------| |-------| + |--^ v-------| + | | | + | | + thread_noise: 9909 ns + | +-> irq_noise: 6139 ns + +-> irq_noise: 7597 ns + +IRQ stacktrace +--------------------------- + +The osnoise/print_stack option is helpful for the cases in which a thread +noise causes the major factor for the timer latency, because of preempt or +irq disabled. For example:: + + [root@f32 tracing]# echo 500 > osnoise/stop_tracing_total_us + [root@f32 tracing]# echo 500 > osnoise/print_stack + [root@f32 tracing]# echo timerlat > current_tracer + [root@f32 tracing]# tail -21 per_cpu/cpu7/trace + insmod-1026 [007] dN.h1.. 200.201948: irq_noise: local_timer:236 start 200.201939376 duration 7872 ns + insmod-1026 [007] d..h1.. 200.202587: #29800 context irq timer_latency 1616 ns + insmod-1026 [007] dN.h2.. 200.202598: irq_noise: local_timer:236 start 200.202586162 duration 11855 ns + insmod-1026 [007] dN.h3.. 200.202947: irq_noise: local_timer:236 start 200.202939174 duration 7318 ns + insmod-1026 [007] d...3.. 200.203444: thread_noise: insmod:1026 start 200.202586933 duration 838681 ns + timerlat/7-1001 [007] ....... 200.203445: #29800 context thread timer_latency 859978 ns + timerlat/7-1001 [007] ....1.. 200.203446: + => timerlat_irq + => __hrtimer_run_queues + => hrtimer_interrupt + => __sysvec_apic_timer_interrupt + => asm_call_irq_on_stack + => sysvec_apic_timer_interrupt + => asm_sysvec_apic_timer_interrupt + => delay_tsc + => dummy_load_1ms_pd_init + => do_one_initcall + => do_init_module + => __do_sys_finit_module + => do_syscall_64 + => entry_SYSCALL_64_after_hwframe + +In this case, it is possible to see that the thread added the highest +contribution to the *timer latency* and the stack trace, saved during +the timerlat IRQ handler, points to a function named +dummy_load_1ms_pd_init, which had the following code (on purpose):: + + static int __init dummy_load_1ms_pd_init(void) + { + preempt_disable(); + mdelay(1); + preempt_enable(); + return 0; + + } -- cgit v1.2.3 From d88c6de4f8b6e6f1b6c3e3a85d39106c83553bc9 Mon Sep 17 00:00:00 2001 From: Venkata Lakshmi Narayana Gubba Date: Tue, 18 May 2021 22:04:45 +0530 Subject: dt-bindings: net: bluetooth: Convert Qualcomm BT binding to DT schema Converted Qualcomm Bluetooth binidings to DT schema. Signed-off-by: Venkata Lakshmi Narayana Gubba Reviewed-by: Rob Herring Signed-off-by: Marcel Holtmann --- .../devicetree/bindings/net/qualcomm-bluetooth.txt | 69 ------------- .../bindings/net/qualcomm-bluetooth.yaml | 112 +++++++++++++++++++++ 2 files changed, 112 insertions(+), 69 deletions(-) delete mode 100644 Documentation/devicetree/bindings/net/qualcomm-bluetooth.txt create mode 100644 Documentation/devicetree/bindings/net/qualcomm-bluetooth.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/qualcomm-bluetooth.txt b/Documentation/devicetree/bindings/net/qualcomm-bluetooth.txt deleted file mode 100644 index 709ca6d51650..000000000000 --- a/Documentation/devicetree/bindings/net/qualcomm-bluetooth.txt +++ /dev/null @@ -1,69 +0,0 @@ -Qualcomm Bluetooth Chips ---------------------- - -This documents the binding structure and common properties for serial -attached Qualcomm devices. - -Serial attached Qualcomm devices shall be a child node of the host UART -device the slave device is attached to. - -Required properties: - - compatible: should contain one of the following: - * "qcom,qca6174-bt" - * "qcom,qca9377-bt" - * "qcom,wcn3990-bt" - * "qcom,wcn3991-bt" - * "qcom,wcn3998-bt" - * "qcom,qca6390-bt" - -Optional properties for compatible string qcom,qca6174-bt: - - - enable-gpios: gpio specifier used to enable chip - - clocks: clock provided to the controller (SUSCLK_32KHZ) - - firmware-name: specify the name of nvm firmware to load - -Optional properties for compatible string qcom,qca9377-bt: - - - max-speed: see Documentation/devicetree/bindings/serial/serial.yaml - -Required properties for compatible string qcom,wcn399x-bt: - - - vddio-supply: VDD_IO supply regulator handle. - - vddxo-supply: VDD_XO supply regulator handle. - - vddrf-supply: VDD_RF supply regulator handle. - - vddch0-supply: VDD_CH0 supply regulator handle. - -Optional properties for compatible string qcom,wcn399x-bt: - - - max-speed: see Documentation/devicetree/bindings/serial/serial.yaml - - firmware-name: specify the name of nvm firmware to load - - clocks: clock provided to the controller - -Examples: - -serial@7570000 { - label = "BT-UART"; - status = "okay"; - - bluetooth { - compatible = "qcom,qca6174-bt"; - - enable-gpios = <&pm8994_gpios 19 GPIO_ACTIVE_HIGH>; - clocks = <&divclk4>; - firmware-name = "nvm_00440302.bin"; - }; -}; - -serial@898000 { - bluetooth { - compatible = "qcom,wcn3990-bt"; - - vddio-supply = <&vreg_s4a_1p8>; - vddxo-supply = <&vreg_l7a_1p8>; - vddrf-supply = <&vreg_l17a_1p3>; - vddch0-supply = <&vreg_l25a_3p3>; - max-speed = <3200000>; - firmware-name = "crnv21.bin"; - clocks = <&rpmhcc RPMH_RF_CLK2>; - }; -}; diff --git a/Documentation/devicetree/bindings/net/qualcomm-bluetooth.yaml b/Documentation/devicetree/bindings/net/qualcomm-bluetooth.yaml new file mode 100644 index 000000000000..772689bf50c1 --- /dev/null +++ b/Documentation/devicetree/bindings/net/qualcomm-bluetooth.yaml @@ -0,0 +1,112 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/qualcomm-bluetooth.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Bluetooth Chips + +maintainers: + - Balakrishna Godavarthi + - Rocky Liao + +description: + This binding describes Qualcomm UART-attached bluetooth chips. + +properties: + compatible: + enum: + - qcom,qca6174-bt + - qcom,qca9377-bt + - qcom,wcn3990-bt + - qcom,wcn3991-bt + - qcom,wcn3998-bt + - qcom,qca6390-bt + + enable-gpios: + maxItems: 1 + description: gpio specifier used to enable chip + + clocks: + maxItems: 1 + description: clock provided to the controller (SUSCLK_32KHZ) + + vddio-supply: + description: VDD_IO supply regulator handle + + vddxo-supply: + description: VDD_XO supply regulator handle + + vddrf-supply: + description: VDD_RF supply regulator handle + + vddch0-supply: + description: VDD_CH0 supply regulator handle + + max-speed: + description: see Documentation/devicetree/bindings/serial/serial.yaml + + firmware-name: + description: specify the name of nvm firmware to load + + local-bd-address: + description: see Documentation/devicetree/bindings/net/bluetooth.txt + + +required: + - compatible + +additionalProperties: false + +allOf: + - if: + properties: + compatible: + contains: + enum: + - qcom,qca6174-bt + then: + required: + - enable-gpios + - clocks + + - if: + properties: + compatible: + contains: + enum: + - qcom,wcn3990-bt + - qcom,wcn3991-bt + - qcom,wcn3998-bt + then: + required: + - vddio-supply + - vddxo-supply + - vddrf-supply + - vddch0-supply + +examples: + - | + #include + serial { + + bluetooth { + compatible = "qcom,qca6174-bt"; + enable-gpios = <&pm8994_gpios 19 GPIO_ACTIVE_HIGH>; + clocks = <&divclk4>; + firmware-name = "nvm_00440302.bin"; + }; + }; + - | + serial { + + bluetooth { + compatible = "qcom,wcn3990-bt"; + vddio-supply = <&vreg_s4a_1p8>; + vddxo-supply = <&vreg_l7a_1p8>; + vddrf-supply = <&vreg_l17a_1p3>; + vddch0-supply = <&vreg_l25a_3p3>; + max-speed = <3200000>; + firmware-name = "crnv21.bin"; + }; + }; -- cgit v1.2.3 From 7a4cb1635a4b879f8d118ec7c6586aef913819f3 Mon Sep 17 00:00:00 2001 From: Venkata Lakshmi Narayana Gubba Date: Tue, 18 May 2021 22:04:46 +0530 Subject: dt-bindings: net: bluetooth: Add device tree bindings for QTI chip wcn6750 This patch enables regulators and gpios for the Qualcomm Bluetooth wcn6750 controller. Signed-off-by: Venkata Lakshmi Narayana Gubba Reviewed-by: Rob Herring Signed-off-by: Marcel Holtmann --- .../bindings/net/qualcomm-bluetooth.yaml | 71 ++++++++++++++++++++++ 1 file changed, 71 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/qualcomm-bluetooth.yaml b/Documentation/devicetree/bindings/net/qualcomm-bluetooth.yaml index 772689bf50c1..f93c6e7a1b59 100644 --- a/Documentation/devicetree/bindings/net/qualcomm-bluetooth.yaml +++ b/Documentation/devicetree/bindings/net/qualcomm-bluetooth.yaml @@ -22,11 +22,17 @@ properties: - qcom,wcn3991-bt - qcom,wcn3998-bt - qcom,qca6390-bt + - qcom,wcn6750-bt enable-gpios: maxItems: 1 description: gpio specifier used to enable chip + swctrl-gpios: + maxItems: 1 + description: gpio specifier is used to find status + of clock supply to SoC + clocks: maxItems: 1 description: clock provided to the controller (SUSCLK_32KHZ) @@ -43,6 +49,30 @@ properties: vddch0-supply: description: VDD_CH0 supply regulator handle + vddaon-supply: + description: VDD_AON supply regulator handle + + vddbtcxmx-supply: + description: VDD_BT_CXMX supply regulator handle + + vddrfacmn-supply: + description: VDD_RFA_CMN supply regulator handle + + vddrfa0p8-supply: + description: VDD_RFA_0P8 suppply regulator handle + + vddrfa1p7-supply: + description: VDD_RFA_1P7 supply regulator handle + + vddrfa1p2-supply: + description: VDD_RFA_1P2 supply regulator handle + + vddrfa2p2-supply: + description: VDD_RFA_2P2 supply regulator handle + + vddasd-supply: + description: VDD_ASD supply regulator handle + max-speed: description: see Documentation/devicetree/bindings/serial/serial.yaml @@ -85,6 +115,25 @@ allOf: - vddrf-supply - vddch0-supply + - if: + properties: + compatible: + contains: + enum: + - qcom,wcn6750-bt + then: + required: + - enable-gpios + - swctrl-gpios + - vddio-supply + - vddaon-supply + - vddbtcxmx-supply + - vddrfacmn-supply + - vddrfa0p8-supply + - vddrfa1p7-supply + - vddrfa1p2-supply + - vddasd-supply + examples: - | #include @@ -110,3 +159,25 @@ examples: firmware-name = "crnv21.bin"; }; }; + - | + serial { + + bluetooth { + compatible = "qcom,wcn6750-bt"; + pinctrl-names = "default"; + pinctrl-0 = <&bt_en_default>; + enable-gpios = <&tlmm 85 GPIO_ACTIVE_HIGH>; + swctrl-gpios = <&tlmm 86 GPIO_ACTIVE_HIGH>; + vddio-supply = <&vreg_l19b_1p8>; + vddaon-supply = <&vreg_s7b_0p9>; + vddbtcxmx-supply = <&vreg_s7b_0p9>; + vddrfacmn-supply = <&vreg_s7b_0p9>; + vddrfa0p8-supply = <&vreg_s7b_0p9>; + vddrfa1p7-supply = <&vreg_s1b_1p8>; + vddrfa1p2-supply = <&vreg_s8b_1p2>; + vddrfa2p2-supply = <&vreg_s1c_2p2>; + vddasd-supply = <&vreg_l11c_2p8>; + max-speed = <3200000>; + firmware-name = "msnv11.bin"; + }; + }; -- cgit v1.2.3 From 8339642c930500140fe27621d783630b002a6342 Mon Sep 17 00:00:00 2001 From: Peng Fan Date: Fri, 28 May 2021 18:06:00 +0800 Subject: dt-bindings: mailbox: imx-mu: add i.MX8ULP MU support The register layout and bits definition of i.MX8ULP MU is different compared with others, let's add the compatible for the new MU. Acked-by: Rob Herring Signed-off-by: Peng Fan Signed-off-by: Jassi Brar --- Documentation/devicetree/bindings/mailbox/fsl,mu.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mailbox/fsl,mu.yaml b/Documentation/devicetree/bindings/mailbox/fsl,mu.yaml index 1a3dff277e2b..675ad9de15bb 100644 --- a/Documentation/devicetree/bindings/mailbox/fsl,mu.yaml +++ b/Documentation/devicetree/bindings/mailbox/fsl,mu.yaml @@ -26,6 +26,7 @@ properties: oneOf: - const: fsl,imx6sx-mu - const: fsl,imx7ulp-mu + - const: fsl,imx8ulp-mu - const: fsl,imx8-mu-scu - items: - enum: -- cgit v1.2.3 From 4649d722c37bec95fd818b6e46179d31c8b9807b Mon Sep 17 00:00:00 2001 From: Martin Botka Date: Sat, 12 Jun 2021 11:46:29 +0200 Subject: dt-bindings: mailbox: Add binding for sm6125 This patch adds the binding for sm6125 Signed-off-by: Martin Botka Acked-by: Rob Herring Signed-off-by: Jassi Brar --- Documentation/devicetree/bindings/mailbox/qcom,apcs-kpss-global.yaml | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mailbox/qcom,apcs-kpss-global.yaml b/Documentation/devicetree/bindings/mailbox/qcom,apcs-kpss-global.yaml index 5dc1173d03fd..9f4fbc6a141c 100644 --- a/Documentation/devicetree/bindings/mailbox/qcom,apcs-kpss-global.yaml +++ b/Documentation/devicetree/bindings/mailbox/qcom,apcs-kpss-global.yaml @@ -27,6 +27,7 @@ properties: - qcom,sc8180x-apss-shared - qcom,sdm660-apcs-hmss-global - qcom,sdm845-apss-shared + - qcom,sm6125-apcs-hmss-global - qcom,sm8150-apss-shared reg: @@ -75,6 +76,7 @@ allOf: - qcom,sc7180-apss-shared - qcom,sdm660-apcs-hmss-global - qcom,sdm845-apss-shared + - qcom,sm6125-apcs-hmss-global - qcom,sm8150-apss-shared then: properties: -- cgit v1.2.3 From 2ef6123182face5df85e585dfddff1e013659ee9 Mon Sep 17 00:00:00 2001 From: Shawn Guo Date: Tue, 22 Jun 2021 08:39:17 +0800 Subject: dt-bindings: mailbox: qcom: Add MSM8939 APCS compatible Add compatible for the Qualcomm MSM8939 APCS block to the Qualcomm APCS bindings. Signed-off-by: Shawn Guo Acked-by: Rob Herring Signed-off-by: Jassi Brar --- Documentation/devicetree/bindings/mailbox/qcom,apcs-kpss-global.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mailbox/qcom,apcs-kpss-global.yaml b/Documentation/devicetree/bindings/mailbox/qcom,apcs-kpss-global.yaml index 9f4fbc6a141c..8878ec00820e 100644 --- a/Documentation/devicetree/bindings/mailbox/qcom,apcs-kpss-global.yaml +++ b/Documentation/devicetree/bindings/mailbox/qcom,apcs-kpss-global.yaml @@ -19,6 +19,7 @@ properties: - qcom,ipq6018-apcs-apps-global - qcom,ipq8074-apcs-apps-global - qcom,msm8916-apcs-kpss-global + - qcom,msm8939-apcs-kpss-global - qcom,msm8994-apcs-kpss-global - qcom,msm8996-apcs-hmss-global - qcom,msm8998-apcs-hmss-global -- cgit v1.2.3 From ed9543d6f2c444457b1936026f67cb8d3bf70bc7 Mon Sep 17 00:00:00 2001 From: Conor Dooley Date: Thu, 24 Jun 2021 16:00:48 +0100 Subject: dt-bindings: add bindings for polarfire soc mailbox Add device tree bindings for the MSS system controller mailbox on the Microchip PolarFire SoC. Signed-off-by: Conor Dooley Reviewed-by: Rob Herring Signed-off-by: Jassi Brar --- .../mailbox/microchip,polarfire-soc-mailbox.yaml | 47 ++++++++++++++++++++++ 1 file changed, 47 insertions(+) create mode 100644 Documentation/devicetree/bindings/mailbox/microchip,polarfire-soc-mailbox.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mailbox/microchip,polarfire-soc-mailbox.yaml b/Documentation/devicetree/bindings/mailbox/microchip,polarfire-soc-mailbox.yaml new file mode 100644 index 000000000000..bbb173ea483c --- /dev/null +++ b/Documentation/devicetree/bindings/mailbox/microchip,polarfire-soc-mailbox.yaml @@ -0,0 +1,47 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/mailbox/microchip,polarfire-soc-mailbox.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: Microchip PolarFire SoC (MPFS) MSS (microprocessor subsystem) mailbox controller + +maintainers: + - Conor Dooley + +properties: + compatible: + const: microchip,polarfire-soc-mailbox + + reg: + items: + - description: mailbox data registers + - description: mailbox interrupt registers + + interrupts: + maxItems: 1 + + "#mbox-cells": + const: 1 + +required: + - compatible + - reg + - interrupts + - "#mbox-cells" + +additionalProperties: false + +examples: + - | + soc { + #address-cells = <2>; + #size-cells = <2>; + mbox: mailbox@37020000 { + compatible = "microchip,polarfire-soc-mailbox"; + reg = <0x0 0x37020000 0x0 0x1000>, <0x0 0x2000318c 0x0 0x40>; + interrupt-parent = <&L1>; + interrupts = <96>; + #mbox-cells = <1>; + }; + }; -- cgit v1.2.3 From c317ae30afc26112e64e832253dc780e32c7b734 Mon Sep 17 00:00:00 2001 From: Conor Dooley Date: Thu, 24 Jun 2021 16:01:39 +0100 Subject: dt-bindings: add bindings for polarfire soc system controller Add device tree bindings for the MSS system controller on the Microchip PolarFire SoC. Signed-off-by: Conor Dooley Reviewed-by: Rob Herring Signed-off-by: Jassi Brar --- .../microchip,polarfire-soc-sys-controller.yaml | 35 ++++++++++++++++++++++ 1 file changed, 35 insertions(+) create mode 100644 Documentation/devicetree/bindings/soc/microchip/microchip,polarfire-soc-sys-controller.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/soc/microchip/microchip,polarfire-soc-sys-controller.yaml b/Documentation/devicetree/bindings/soc/microchip/microchip,polarfire-soc-sys-controller.yaml new file mode 100644 index 000000000000..2cd3bc6bd8d6 --- /dev/null +++ b/Documentation/devicetree/bindings/soc/microchip/microchip,polarfire-soc-sys-controller.yaml @@ -0,0 +1,35 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/soc/microchip/microchip,polarfire-soc-sys-controller.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: Microchip PolarFire SoC (MPFS) MSS (microprocessor subsystem) system controller + +maintainers: + - Conor Dooley + +description: | + The PolarFire SoC system controller is communicated with via a mailbox. + This document describes the bindings for the client portion of that mailbox. + + +properties: + mboxes: + maxItems: 1 + + compatible: + const: microchip,polarfire-soc-sys-controller + +required: + - compatible + - mboxes + +additionalProperties: false + +examples: + - | + syscontroller: syscontroller { + compatible = "microchip,polarfire-soc-sys-controller"; + mboxes = <&mbox 0>; + }; -- cgit v1.2.3 From 11fa5f8392eede198bc1218b97b03c063ee9d080 Mon Sep 17 00:00:00 2001 From: Martin Botka Date: Sat, 5 Jun 2021 14:10:37 +0200 Subject: dt-bindings: clk: qcom: gcc-sm6125: Document SM6125 GCC driver Document the newly added SM6125 GCC driver. Signed-off-by: Martin Botka Link: https://lore.kernel.org/r/20210605121040.282053-1-martin.botka@somainline.org Reviewed-by: Rob Herring Reviewed-by: Bjorn Andersson Signed-off-by: Stephen Boyd --- .../devicetree/bindings/clock/qcom,gcc-sm6125.yaml | 72 ++++++++++++++++++++++ 1 file changed, 72 insertions(+) create mode 100644 Documentation/devicetree/bindings/clock/qcom,gcc-sm6125.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-sm6125.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-sm6125.yaml new file mode 100644 index 000000000000..ab12b391effc --- /dev/null +++ b/Documentation/devicetree/bindings/clock/qcom,gcc-sm6125.yaml @@ -0,0 +1,72 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/qcom,gcc-sm6125.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Global Clock & Reset Controller Binding for SM6125 + +maintainers: + - Konrad Dybcio + +description: | + Qualcomm global clock control module which supports the clocks, resets and + power domains on SM6125. + + See also: + - dt-bindings/clock/qcom,gcc-sm6125.h + +properties: + compatible: + const: qcom,gcc-sm6125 + + clocks: + items: + - description: Board XO source + - description: Sleep clock source + + clock-names: + items: + - const: bi_tcxo + - const: sleep_clk + + '#clock-cells': + const: 1 + + '#reset-cells': + const: 1 + + '#power-domain-cells': + const: 1 + + reg: + maxItems: 1 + + protected-clocks: + description: + Protected clock specifier list as per common clock binding. + +required: + - compatible + - clocks + - clock-names + - reg + - '#clock-cells' + - '#reset-cells' + - '#power-domain-cells' + +additionalProperties: false + +examples: + - | + #include + clock-controller@1400000 { + compatible = "qcom,gcc-sm6125"; + reg = <0x01400000 0x1f0000>; + #clock-cells = <1>; + #reset-cells = <1>; + #power-domain-cells = <1>; + clock-names = "bi_tcxo", "sleep_clk"; + clocks = <&rpmcc RPM_SMD_XO_CLK_SRC>, <&sleep_clk>; + }; +... -- cgit v1.2.3 From e184d788af5c10d00c7430dcb1f8c7cf086567a2 Mon Sep 17 00:00:00 2001 From: Bartosz Dudziak Date: Sun, 18 Apr 2021 14:29:05 +0200 Subject: dt-bindings: clock: qcom: Add MSM8226 GCC clock bindings Add compatible device strings and the include files for the MSM8226 GCC. Signed-off-by: Bartosz Dudziak Link: https://lore.kernel.org/r/20210418122909.71434-2-bartosz.dudziak@snejp.pl Acked-by: Rob Herring Signed-off-by: Stephen Boyd --- Documentation/devicetree/bindings/clock/qcom,gcc.yaml | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc.yaml index 3599702cd428..8453eeddf30e 100644 --- a/Documentation/devicetree/bindings/clock/qcom,gcc.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,gcc.yaml @@ -26,8 +26,8 @@ description: | - dt-bindings/reset/qcom,gcc-msm8939.h - dt-bindings/clock/qcom,gcc-msm8660.h - dt-bindings/reset/qcom,gcc-msm8660.h - - dt-bindings/clock/qcom,gcc-msm8974.h - - dt-bindings/reset/qcom,gcc-msm8974.h + - dt-bindings/clock/qcom,gcc-msm8974.h (qcom,gcc-msm8226 and qcom,gcc-msm8974) + - dt-bindings/reset/qcom,gcc-msm8974.h (qcom,gcc-msm8226 and qcom,gcc-msm8974) - dt-bindings/clock/qcom,gcc-msm8994.h - dt-bindings/clock/qcom,gcc-mdm9607.h - dt-bindings/clock/qcom,gcc-mdm9615.h @@ -42,6 +42,7 @@ properties: - qcom,gcc-ipq6018 - qcom,gcc-ipq8064 - qcom,gcc-mdm9607 + - qcom,gcc-msm8226 - qcom,gcc-msm8660 - qcom,gcc-msm8916 - qcom,gcc-msm8939 -- cgit v1.2.3 From a3b82fa77b861364b5abac3bf310124276e8f65d Mon Sep 17 00:00:00 2001 From: Jonathan Marek Date: Tue, 8 Jun 2021 22:20:47 -0400 Subject: dt-bindings: clock: add QCOM SM8250 camera clock bindings Add device tree bindings for camera clock controller for Qualcomm Technology Inc's SM8250 SoC. Signed-off-by: Jonathan Marek Link: https://lore.kernel.org/r/20210609022051.2171-3-jonathan@marek.ca Reviewed-by: Rob Herring Signed-off-by: Stephen Boyd --- .../bindings/clock/qcom,camcc-sm8250.yaml | 68 ++++++++++++++++++++++ 1 file changed, 68 insertions(+) create mode 100644 Documentation/devicetree/bindings/clock/qcom,camcc-sm8250.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/qcom,camcc-sm8250.yaml b/Documentation/devicetree/bindings/clock/qcom,camcc-sm8250.yaml new file mode 100644 index 000000000000..9f239c3960d1 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/qcom,camcc-sm8250.yaml @@ -0,0 +1,68 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/qcom,camcc-sm8250.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Camera Clock & Reset Controller Binding for SM8250 + +maintainers: + - Jonathan Marek + +description: | + Qualcomm camera clock control module which supports the clocks, resets and + power domains on SM8250. + + See also dt-bindings/clock/qcom,camcc-sm8250.h + +properties: + compatible: + const: qcom,sm8250-camcc + + clocks: + items: + - description: Board XO source + - description: Sleep clock source + + clock-names: + items: + - const: bi_tcxo + - const: sleep_clk + + '#clock-cells': + const: 1 + + '#reset-cells': + const: 1 + + '#power-domain-cells': + const: 1 + + reg: + maxItems: 1 + +required: + - compatible + - reg + - clocks + - clock-names + - '#clock-cells' + - '#reset-cells' + - '#power-domain-cells' + +additionalProperties: false + +examples: + - | + #include + clock-controller@ad00000 { + compatible = "qcom,sm8250-camcc"; + reg = <0x0ad00000 0x10000>; + clocks = <&rpmhcc RPMH_CXO_CLK>, + <&sleep_clk>; + clock-names = "bi_tcxo", "sleep_clk"; + #clock-cells = <1>; + #reset-cells = <1>; + #power-domain-cells = <1>; + }; +... -- cgit v1.2.3 From 199ead4008b2078772c4efc3851a31af75eb4013 Mon Sep 17 00:00:00 2001 From: Liam Beguin Date: Thu, 22 Apr 2021 20:40:57 -0400 Subject: dt-bindings: clock: add ti,lmk04832 bindings Document devicetree bindings for Texas Instruments' LMK04832. The LMK04208 is a high performance clock conditioner with superior clock jitter cleaning, generation, and distribution with JEDEC JESD204B support. Signed-off-by: Liam Beguin Link: https://lore.kernel.org/r/20210423004057.283926-4-liambeguin@gmail.com Reviewed-by: Rob Herring Signed-off-by: Stephen Boyd --- .../devicetree/bindings/clock/ti,lmk04832.yaml | 209 +++++++++++++++++++++ 1 file changed, 209 insertions(+) create mode 100644 Documentation/devicetree/bindings/clock/ti,lmk04832.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/ti,lmk04832.yaml b/Documentation/devicetree/bindings/clock/ti,lmk04832.yaml new file mode 100644 index 000000000000..bd8173848253 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/ti,lmk04832.yaml @@ -0,0 +1,209 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/ti,lmk04832.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Clock bindings for the Texas Instruments LMK04832 + +maintainers: + - Liam Beguin + +description: | + Devicetree binding for the LMK04832, a clock conditioner with JEDEC JESD204B + support. The LMK04832 is pin compatible with the LMK0482x family. + + Link to datasheet, https://www.ti.com/lit/ds/symlink/lmk04832.pdf + +properties: + compatible: + enum: + - ti,lmk04832 + + reg: + maxItems: 1 + + '#address-cells': + const: 1 + + '#size-cells': + const: 0 + + '#clock-cells': + const: 1 + + spi-max-frequency: + maximum: 5000000 + + clocks: + items: + - description: PLL2 reference clock. + + clock-names: + items: + - const: oscin + + reset-gpios: + maxItems: 1 + + ti,spi-4wire-rdbk: + description: | + Select SPI 4wire readback pin configuration. + Available readback pins are, + CLKin_SEL0 0 + CLKin_SEL1 1 + RESET 2 + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1, 2] + default: 1 + + ti,vco-hz: + description: Optional to set VCO frequency of the PLL in Hertz. + + ti,sysref-ddly: + description: SYSREF digital delay value. + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 8 + maximum: 8191 + default: 8 + + ti,sysref-mux: + description: | + SYSREF Mux configuration. + Available options are, + Normal SYNC 0 + Re-clocked 1 + SYSREF Pulser 2 + SYSREF Continuous 3 + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1, 2, 3] + default: 3 + + ti,sync-mode: + description: SYNC pin configuration. + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1, 2] + default: 1 + + ti,sysref-pulse-count: + description: + Number of SYSREF pulses to send when SYSREF is not in continuous mode. + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [1, 2, 4, 8] + default: 4 + +patternProperties: + "@[0-9a-d]+$": + type: object + description: + Child nodes used to configure output clocks. + + properties: + reg: + description: + clock output identifier. + minimum: 0 + maximum: 13 + + ti,clkout-fmt: + description: + Clock output format. + Available options are, + Powerdown 0x00 + LVDS 0x01 + HSDS 6 mA 0x02 + HSDS 8 mA 0x03 + LVPECL 1600 mV 0x04 + LVPECL 2000 mV 0x05 + LCPECL 0x06 + CML 16 mA 0x07 + CML 24 mA 0x08 + CML 32 mA 0x09 + CMOS (Off/Inverted) 0x0a + CMOS (Normal/Off) 0x0b + CMOS (Inverted/Inverted) 0x0c + CMOS (Inverted/Normal) 0x0d + CMOS (Normal/Inverted) 0x0e + CMOS (Normal/Normal) 0x0f + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 15 + + ti,clkout-sysref: + description: + Select SYSREF clock path for output clock. + type: boolean + + required: + - reg + + additionalProperties: false + +required: + - compatible + - reg + - '#clock-cells' + - clocks + - clock-names + +additionalProperties: false + +examples: + - | + clocks { + lmk04832_oscin: oscin { + compatible = "fixed-clock"; + + #clock-cells = <0>; + clock-frequency = <122880000>; + clock-output-names = "lmk04832-oscin"; + }; + }; + + spi0 { + #address-cells = <1>; + #size-cells = <0>; + + lmk04832: clock-controller@0 { + #address-cells = <1>; + #size-cells = <0>; + + reg = <0>; + + compatible = "ti,lmk04832"; + spi-max-frequency = <781250>; + + reset-gpios = <&gpio_lmk 0 0 0>; + + #clock-cells = <1>; + clocks = <&lmk04832_oscin>; + clock-names = "oscin"; + + ti,spi-4wire-rdbk = <0>; + ti,vco-hz = <2457600000>; + + assigned-clocks = + <&lmk04832 0>, <&lmk04832 1>, + <&lmk04832 2>, <&lmk04832 3>, + <&lmk04832 4>, + <&lmk04832 6>, <&lmk04832 7>, + <&lmk04832 10>, <&lmk04832 11>; + assigned-clock-rates = + <122880000>, <384000>, + <122880000>, <384000>, + <122880000>, + <153600000>, <384000>, + <614400000>, <384000>; + + clkout0@0 { + reg = <0>; + ti,clkout-fmt = <0x01>; // LVDS + }; + + clkout1@1 { + reg = <1>; + ti,clkout-fmt = <0x01>; // LVDS + ti,clkout-sysref; + }; + }; + }; -- cgit v1.2.3 From 2e1ae04f7fe049bb012c273e5281a3c145924ea1 Mon Sep 17 00:00:00 2001 From: Paul Cercueil Date: Sun, 30 May 2021 17:49:18 +0100 Subject: dt-bindings: clock: ingenic: Add ingenic,jz4760{,b}-cgu compatibles Add ingenic,jz4760-cgu and ingenic,jz4760b-cgu compatible strings for the JZ4760 and JZ4760B SoCs respectively. Signed-off-by: Paul Cercueil Acked-by: Rob Herring Link: https://lore.kernel.org/r/20210530164923.18134-2-paul@crapouillou.net Signed-off-by: Stephen Boyd --- Documentation/devicetree/bindings/clock/ingenic,cgu.yaml | 4 ++++ 1 file changed, 4 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/ingenic,cgu.yaml b/Documentation/devicetree/bindings/clock/ingenic,cgu.yaml index c65b9458c0b6..6d6236e02c22 100644 --- a/Documentation/devicetree/bindings/clock/ingenic,cgu.yaml +++ b/Documentation/devicetree/bindings/clock/ingenic,cgu.yaml @@ -22,6 +22,8 @@ select: enum: - ingenic,jz4740-cgu - ingenic,jz4725b-cgu + - ingenic,jz4760-cgu + - ingenic,jz4760b-cgu - ingenic,jz4770-cgu - ingenic,jz4780-cgu - ingenic,x1000-cgu @@ -49,6 +51,8 @@ properties: - enum: - ingenic,jz4740-cgu - ingenic,jz4725b-cgu + - ingenic,jz4760-cgu + - ingenic,jz4760b-cgu - ingenic,jz4770-cgu - ingenic,jz4780-cgu - ingenic,x1000-cgu -- cgit v1.2.3 From fa745c71b8e75e85ce129dd9097a00ac7a9df47f Mon Sep 17 00:00:00 2001 From: Alain Volmat Date: Wed, 31 Mar 2021 22:16:28 +0200 Subject: dt-bindings: clock: st: flexgen: add new introduced compatible New compatible are added, supporting various kind of flexgen in STiH407, STiH410 and STiH418 Signed-off-by: Alain Volmat Acked-by: Rob Herring Link: https://lore.kernel.org/r/20210331201632.24530-4-avolmat@me.com Signed-off-by: Stephen Boyd --- Documentation/devicetree/bindings/clock/st/st,flexgen.txt | 10 ++++++++++ 1 file changed, 10 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/st/st,flexgen.txt b/Documentation/devicetree/bindings/clock/st/st,flexgen.txt index 7ff77fc57dff..55a18939bddd 100644 --- a/Documentation/devicetree/bindings/clock/st/st,flexgen.txt +++ b/Documentation/devicetree/bindings/clock/st/st,flexgen.txt @@ -64,6 +64,16 @@ Required properties: audio use case) "st,flexgen-video", "st,flexgen" (enable clock propagation on parent and activate synchronous mode) + "st,flexgen-stih407-a0" + "st,flexgen-stih410-a0" + "st,flexgen-stih407-c0" + "st,flexgen-stih410-c0" + "st,flexgen-stih418-c0" + "st,flexgen-stih407-d0" + "st,flexgen-stih410-d0" + "st,flexgen-stih407-d2" + "st,flexgen-stih418-d2" + "st,flexgen-stih407-d3" - #clock-cells : from common clock binding; shall be set to 1 (multiple clock outputs). -- cgit v1.2.3 From 8df309e9c5e173eea83909d5575eab89965541af Mon Sep 17 00:00:00 2001 From: Alain Volmat Date: Wed, 31 Mar 2021 22:16:30 +0200 Subject: dt-bindings: clock: st: clkgen-pll: add new introduced compatible New compatible are added, supporting various kind of clkgen-pll used for STiH407, STiH410 and STiH418 Signed-off-by: Alain Volmat Acked-by: Rob Herring Link: https://lore.kernel.org/r/20210331201632.24530-6-avolmat@me.com Signed-off-by: Stephen Boyd --- Documentation/devicetree/bindings/clock/st/st,clkgen-pll.txt | 3 +++ 1 file changed, 3 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/st/st,clkgen-pll.txt b/Documentation/devicetree/bindings/clock/st/st,clkgen-pll.txt index f207053e0550..d0fa1e02d06d 100644 --- a/Documentation/devicetree/bindings/clock/st/st,clkgen-pll.txt +++ b/Documentation/devicetree/bindings/clock/st/st,clkgen-pll.txt @@ -10,7 +10,10 @@ Required properties: - compatible : shall be: "st,clkgen-pll0" + "st,clkgen-pll0-a0" + "st,clkgen-pll0-c0" "st,clkgen-pll1" + "st,clkgen-pll1-c0" "st,stih407-clkgen-plla9" "st,stih418-clkgen-plla9" -- cgit v1.2.3 From 301035c32e6754c2293d3aba77e6de3e3dded7fe Mon Sep 17 00:00:00 2001 From: Alain Volmat Date: Wed, 31 Mar 2021 22:16:32 +0200 Subject: dt-bindings: clock: st: clkgen-fsyn: add new introduced compatible New compatible are added, supporting various kind of clkgen-fsyn used for STiH407, STiH410 and STiH418 Signed-off-by: Alain Volmat Link: https://lore.kernel.org/r/20210331201632.24530-8-avolmat@me.com Acked-by: Rob Herring Signed-off-by: Stephen Boyd --- Documentation/devicetree/bindings/clock/st/st,quadfs.txt | 3 +++ 1 file changed, 3 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/st/st,quadfs.txt b/Documentation/devicetree/bindings/clock/st/st,quadfs.txt index d93d49342e60..c4ba2adb0b4f 100644 --- a/Documentation/devicetree/bindings/clock/st/st,quadfs.txt +++ b/Documentation/devicetree/bindings/clock/st/st,quadfs.txt @@ -12,6 +12,9 @@ This binding uses the common clock binding[1]. Required properties: - compatible : shall be: "st,quadfs" + "st,quadfs-d0" + "st,quadfs-d2" + "st,quadfs-d3" "st,quadfs-pll" -- cgit v1.2.3 From c832bb98d3706f843a207fff44ddf8a6422289a1 Mon Sep 17 00:00:00 2001 From: Robert Hancock Date: Thu, 25 Mar 2021 13:26:35 -0600 Subject: dt-bindings: clock: clk-si5341: Add new attributes Add new silabs,xaxb-ext-clk and silabs,iovdd-33 properties. Changed vdd-supply on top-level node to optional since it is not actually used by the driver. Removed vdd-supply from output sub-nodes, as it was not supported by the driver and it is not easily possible to support this in that location with the kernel regulator infrastructure. Changed to have vddoX-supply attributes for each output on the top-level device node. Signed-off-by: Robert Hancock Link: https://lore.kernel.org/r/20210325192643.2190069-2-robert.hancock@calian.com Reviewed-by: Rob Herring Signed-off-by: Stephen Boyd --- .../devicetree/bindings/clock/silabs,si5341.txt | 16 ++++++++++------ 1 file changed, 10 insertions(+), 6 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/silabs,si5341.txt b/Documentation/devicetree/bindings/clock/silabs,si5341.txt index 504cce3abe46..ce55aba0ce22 100644 --- a/Documentation/devicetree/bindings/clock/silabs,si5341.txt +++ b/Documentation/devicetree/bindings/clock/silabs,si5341.txt @@ -24,9 +24,8 @@ it. The device type, speed grade and revision are determined runtime by probing. -The driver currently only supports XTAL input mode, and does not support any -fancy input configurations. They can still be programmed into the chip and -the driver will leave them "as is". +The driver currently does not support any fancy input configurations. They can +still be programmed into the chip and the driver will leave them "as is". ==I2C device node== @@ -45,9 +44,9 @@ Required properties: corresponding to inputs. Use a fixed clock for the "xtal" input. At least one must be present. - clock-names: One of: "xtal", "in0", "in1", "in2" -- vdd-supply: Regulator node for VDD Optional properties: +- vdd-supply: Regulator node for VDD - vdda-supply: Regulator node for VDDA - vdds-supply: Regulator node for VDDS - silabs,pll-m-num, silabs,pll-m-den: Numerator and denominator for PLL @@ -60,7 +59,14 @@ Optional properties: be initialized, and always performs the soft-reset routine. Since this will temporarily stop all output clocks, don't do this if the chip is generating the CPU clock for example. +- silabs,xaxb-ext-clk: When present, indicates that the XA/XB pins are used + in EXTCLK (external reference clock) rather than XTAL (crystal) mode. - interrupts: Interrupt for INTRb pin. +- silabs,iovdd-33: When present, indicates that the I2C lines are using 3.3V + rather than 1.8V thresholds. +- vddoX-supply (where X is an output index): Regulator node for VDDO for the + specified output. The driver selects the output VDD_SEL setting based on this + voltage. - #address-cells: shall be set to 1. - #size-cells: shall be set to 0. @@ -77,8 +83,6 @@ Required child node properties: - reg: number of clock output. Optional child node properties: -- vdd-supply: Regulator node for VDD for this output. The driver selects default - values for common-mode and amplitude based on the voltage. - silabs,format: Output format, one of: 1 = differential (defaults to LVDS levels) 2 = low-power (defaults to HCSL levels) -- cgit v1.2.3 From b87111da42f328c0e658e36e6782bb341ee742ea Mon Sep 17 00:00:00 2001 From: Dongjiu Geng Date: Tue, 23 Mar 2021 19:29:32 +0800 Subject: dt-bindings: Document the hi3559a clock bindings Add DT bindings documentation for hi3559a SoC clock. Signed-off-by: Dongjiu Geng Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/1616498973-47067-2-git-send-email-gengdongjiu1@gmail.com Signed-off-by: Stephen Boyd --- .../clock/hisilicon,hi3559av100-clock.yaml | 59 ++++++++++++++++++++++ 1 file changed, 59 insertions(+) create mode 100644 Documentation/devicetree/bindings/clock/hisilicon,hi3559av100-clock.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/hisilicon,hi3559av100-clock.yaml b/Documentation/devicetree/bindings/clock/hisilicon,hi3559av100-clock.yaml new file mode 100644 index 000000000000..3ceb29cec704 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/hisilicon,hi3559av100-clock.yaml @@ -0,0 +1,59 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/hisilicon,hi3559av100-clock.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Hisilicon SOC Clock for HI3559AV100 + +maintainers: + - Dongjiu Geng + +description: | + Hisilicon SOC clock control module which supports the clocks, resets and + power domains on HI3559AV100. + + See also: + dt-bindings/clock/hi3559av100-clock.h + +properties: + compatible: + enum: + - hisilicon,hi3559av100-clock + - hisilicon,hi3559av100-shub-clock + + reg: + minItems: 1 + maxItems: 2 + + '#clock-cells': + const: 1 + + '#reset-cells': + const: 2 + description: | + First cell is reset request register offset. + Second cell is bit offset in reset request register. + +required: + - compatible + - reg + - '#clock-cells' + - '#reset-cells' + +additionalProperties: false + +examples: + - | + soc { + #address-cells = <2>; + #size-cells = <2>; + + clock-controller@12010000 { + compatible = "hisilicon,hi3559av100-clock"; + #clock-cells = <1>; + #reset-cells = <2>; + reg = <0x0 0x12010000 0x0 0x10000>; + }; + }; +... -- cgit v1.2.3 From 1a93084b9a89818aec0ac7b59a5a51f2112bf203 Mon Sep 17 00:00:00 2001 From: Namjae Jeon Date: Thu, 24 Jun 2021 10:34:11 +0900 Subject: ksmbd: move fs/cifsd to fs/ksmbd Move fs/cifsd to fs/ksmbd and rename the remaining cifsd name to ksmbd. Reviewed-by: Christoph Hellwig Signed-off-by: Namjae Jeon Signed-off-by: Steve French --- Documentation/filesystems/cifs/cifsd.rst | 164 ------------------------------- Documentation/filesystems/cifs/index.rst | 2 +- Documentation/filesystems/cifs/ksmbd.rst | 164 +++++++++++++++++++++++++++++++ 3 files changed, 165 insertions(+), 165 deletions(-) delete mode 100644 Documentation/filesystems/cifs/cifsd.rst create mode 100644 Documentation/filesystems/cifs/ksmbd.rst (limited to 'Documentation') diff --git a/Documentation/filesystems/cifs/cifsd.rst b/Documentation/filesystems/cifs/cifsd.rst deleted file mode 100644 index 01a0be272ce6..000000000000 --- a/Documentation/filesystems/cifs/cifsd.rst +++ /dev/null @@ -1,164 +0,0 @@ -.. SPDX-License-Identifier: GPL-2.0 - -========================== -CIFSD - SMB3 Kernel Server -========================== - -CIFSD is a linux kernel server which implements SMB3 protocol in kernel space -for sharing files over network. - -CIFSD architecture -================== - -The subset of performance related operations belong in kernelspace and -the other subset which belong to operations which are not really related with -performance in userspace. So, DCE/RPC management that has historically resulted -into number of buffer overflow issues and dangerous security bugs and user -account management are implemented in user space as ksmbd.mountd. -File operations that are related with performance (open/read/write/close etc.) -in kernel space (ksmbd). This also allows for easier integration with VFS -interface for all file operations. - -ksmbd (kernel daemon) ---------------------- - -When the server daemon is started, It starts up a forker thread -(ksmbd/interface name) at initialization time and open a dedicated port 445 -for listening to SMB requests. Whenever new clients make request, Forker -thread will accept the client connection and fork a new thread for dedicated -communication channel between the client and the server. It allows for parallel -processing of SMB requests(commands) from clients as well as allowing for new -clients to make new connections. Each instance is named ksmbd/1~n(port number) -to indicate connected clients. Depending on the SMB request types, each new -thread can decide to pass through the commands to the user space (ksmbd.mountd), -currently DCE/RPC commands are identified to be handled through the user space. -To further utilize the linux kernel, it has been chosen to process the commands -as workitems and to be executed in the handlers of the ksmbd-io kworker threads. -It allows for multiplexing of the handlers as the kernel take care of initiating -extra worker threads if the load is increased and vice versa, if the load is -decreased it destroys the extra worker threads. So, after connection is -established with client. Dedicated ksmbd/1..n(port number) takes complete -ownership of receiving/parsing of SMB commands. Each received command is worked -in parallel i.e., There can be multiple clients commands which are worked in -parallel. After receiving each command a separated kernel workitem is prepared -for each command which is further queued to be handled by ksmbd-io kworkers. -So, each SMB workitem is queued to the kworkers. This allows the benefit of load -sharing to be managed optimally by the default kernel and optimizing client -performance by handling client commands in parallel. - -ksmbd.mountd (user space daemon) --------------------------------- - -ksmbd.mountd is userspace process to, transfer user account and password that -are registered using ksmbd.adduser(part of utils for user space). Further it -allows sharing information parameters that parsed from smb.conf to ksmbd in -kernel. For the execution part it has a daemon which is continuously running -and connected to the kernel interface using netlink socket, it waits for the -requests(dcerpc and share/user info). It handles RPC calls (at a minimum few -dozen) that are most important for file server from NetShareEnum and -NetServerGetInfo. Complete DCE/RPC response is prepared from the user space -and passed over to the associated kernel thread for the client. - - -CIFSD Feature Status -==================== - -============================== ================================================= -Feature name Status -============================== ================================================= -Dialects Supported. SMB2.1 SMB3.0, SMB3.1.1 dialects - (intentionally excludes security vulnerable SMB1 - dialect). -Auto Negotiation Supported. -Compound Request Supported. -Oplock Cache Mechanism Supported. -SMB2 leases(v1 lease) Supported. -Directory leases(v2 lease) Planned for future. -Multi-credits Supported. -NTLM/NTLMv2 Supported. -HMAC-SHA256 Signing Supported. -Secure negotiate Supported. -Signing Update Supported. -Pre-authentication integrity Supported. -SMB3 encryption(CCM, GCM) Supported. (CCM and GCM128 supported, GCM256 in - progress) -SMB direct(RDMA) Partially Supported. SMB3 Multi-channel is - required to connect to Windows client. -SMB3 Multi-channel In Progress. -SMB3.1.1 POSIX extension Supported. -ACLs Partially Supported. only DACLs available, SACLs - (auditing) is planned for the future. For - ownership (SIDs) ksmbd generates random subauth - values(then store it to disk) and use uid/gid - get from inode as RID for local domain SID. - The current acl implementation is limited to - standalone server, not a domain member. - Integration with Samba tools is being worked on - to allow future support for running as a domain - member. -Kerberos Supported. -Durable handle v1,v2 Planned for future. -Persistent handle Planned for future. -SMB2 notify Planned for future. -Sparse file support Supported. -DCE/RPC support Partially Supported. a few calls(NetShareEnumAll, - NetServerGetInfo, SAMR, LSARPC) that are needed - for file server handled via netlink interface - from ksmbd.mountd. Additional integration with - Samba tools and libraries via upcall is being - investigated to allow support for additional - DCE/RPC management calls (and future support - for Witness protocol e.g.) -ksmbd/nfsd interoperability Planned for future. The features that ksmbd - support are Leases, Notify, ACLs and Share modes. -============================== ================================================= - - -How to run -========== - -1. Download ksmbd-tools and compile them. - - https://github.com/cifsd-team/ksmbd-tools - -2. Create user/password for SMB share. - - # mkdir /etc/ksmbd/ - # ksmbd.adduser -a - -3. Create /etc/ksmbd/smb.conf file, add SMB share in smb.conf file - - Refer smb.conf.example and - https://github.com/cifsd-team/ksmbd-tools/blob/master/Documentation/configuration.txt - -4. Insert ksmbd.ko module - - # insmod ksmbd.ko - -5. Start ksmbd user space daemon - # ksmbd.mountd - -6. Access share from Windows or Linux using CIFS - -Shutdown CIFSD -============== - -1. kill user and kernel space daemon - # sudo ksmbd.control -s - -How to turn debug print on -========================== - -Each layer -/sys/class/ksmbd-control/debug - -1. Enable all component prints - # sudo ksmbd.control -d "all" - -2. Enable one of components(smb, auth, vfs, oplock, ipc, conn, rdma) - # sudo ksmbd.control -d "smb" - -3. Show what prints are enable. - # cat/sys/class/ksmbd-control/debug - [smb] auth vfs oplock ipc conn [rdma] - -4. Disable prints: - If you try the selected component once more, It is disabled without brackets. diff --git a/Documentation/filesystems/cifs/index.rst b/Documentation/filesystems/cifs/index.rst index e762586b5dc7..1c8597a679ab 100644 --- a/Documentation/filesystems/cifs/index.rst +++ b/Documentation/filesystems/cifs/index.rst @@ -6,5 +6,5 @@ CIFS .. toctree:: :maxdepth: 1 - cifsd + ksmbd cifsroot diff --git a/Documentation/filesystems/cifs/ksmbd.rst b/Documentation/filesystems/cifs/ksmbd.rst new file mode 100644 index 000000000000..1e111efecd45 --- /dev/null +++ b/Documentation/filesystems/cifs/ksmbd.rst @@ -0,0 +1,164 @@ +.. SPDX-License-Identifier: GPL-2.0 + +========================== +KSMBD - SMB3 Kernel Server +========================== + +KSMBD is a linux kernel server which implements SMB3 protocol in kernel space +for sharing files over network. + +KSMBD architecture +================== + +The subset of performance related operations belong in kernelspace and +the other subset which belong to operations which are not really related with +performance in userspace. So, DCE/RPC management that has historically resulted +into number of buffer overflow issues and dangerous security bugs and user +account management are implemented in user space as ksmbd.mountd. +File operations that are related with performance (open/read/write/close etc.) +in kernel space (ksmbd). This also allows for easier integration with VFS +interface for all file operations. + +ksmbd (kernel daemon) +--------------------- + +When the server daemon is started, It starts up a forker thread +(ksmbd/interface name) at initialization time and open a dedicated port 445 +for listening to SMB requests. Whenever new clients make request, Forker +thread will accept the client connection and fork a new thread for dedicated +communication channel between the client and the server. It allows for parallel +processing of SMB requests(commands) from clients as well as allowing for new +clients to make new connections. Each instance is named ksmbd/1~n(port number) +to indicate connected clients. Depending on the SMB request types, each new +thread can decide to pass through the commands to the user space (ksmbd.mountd), +currently DCE/RPC commands are identified to be handled through the user space. +To further utilize the linux kernel, it has been chosen to process the commands +as workitems and to be executed in the handlers of the ksmbd-io kworker threads. +It allows for multiplexing of the handlers as the kernel take care of initiating +extra worker threads if the load is increased and vice versa, if the load is +decreased it destroys the extra worker threads. So, after connection is +established with client. Dedicated ksmbd/1..n(port number) takes complete +ownership of receiving/parsing of SMB commands. Each received command is worked +in parallel i.e., There can be multiple clients commands which are worked in +parallel. After receiving each command a separated kernel workitem is prepared +for each command which is further queued to be handled by ksmbd-io kworkers. +So, each SMB workitem is queued to the kworkers. This allows the benefit of load +sharing to be managed optimally by the default kernel and optimizing client +performance by handling client commands in parallel. + +ksmbd.mountd (user space daemon) +-------------------------------- + +ksmbd.mountd is userspace process to, transfer user account and password that +are registered using ksmbd.adduser(part of utils for user space). Further it +allows sharing information parameters that parsed from smb.conf to ksmbd in +kernel. For the execution part it has a daemon which is continuously running +and connected to the kernel interface using netlink socket, it waits for the +requests(dcerpc and share/user info). It handles RPC calls (at a minimum few +dozen) that are most important for file server from NetShareEnum and +NetServerGetInfo. Complete DCE/RPC response is prepared from the user space +and passed over to the associated kernel thread for the client. + + +KSMBD Feature Status +==================== + +============================== ================================================= +Feature name Status +============================== ================================================= +Dialects Supported. SMB2.1 SMB3.0, SMB3.1.1 dialects + (intentionally excludes security vulnerable SMB1 + dialect). +Auto Negotiation Supported. +Compound Request Supported. +Oplock Cache Mechanism Supported. +SMB2 leases(v1 lease) Supported. +Directory leases(v2 lease) Planned for future. +Multi-credits Supported. +NTLM/NTLMv2 Supported. +HMAC-SHA256 Signing Supported. +Secure negotiate Supported. +Signing Update Supported. +Pre-authentication integrity Supported. +SMB3 encryption(CCM, GCM) Supported. (CCM and GCM128 supported, GCM256 in + progress) +SMB direct(RDMA) Partially Supported. SMB3 Multi-channel is + required to connect to Windows client. +SMB3 Multi-channel In Progress. +SMB3.1.1 POSIX extension Supported. +ACLs Partially Supported. only DACLs available, SACLs + (auditing) is planned for the future. For + ownership (SIDs) ksmbd generates random subauth + values(then store it to disk) and use uid/gid + get from inode as RID for local domain SID. + The current acl implementation is limited to + standalone server, not a domain member. + Integration with Samba tools is being worked on + to allow future support for running as a domain + member. +Kerberos Supported. +Durable handle v1,v2 Planned for future. +Persistent handle Planned for future. +SMB2 notify Planned for future. +Sparse file support Supported. +DCE/RPC support Partially Supported. a few calls(NetShareEnumAll, + NetServerGetInfo, SAMR, LSARPC) that are needed + for file server handled via netlink interface + from ksmbd.mountd. Additional integration with + Samba tools and libraries via upcall is being + investigated to allow support for additional + DCE/RPC management calls (and future support + for Witness protocol e.g.) +ksmbd/nfsd interoperability Planned for future. The features that ksmbd + support are Leases, Notify, ACLs and Share modes. +============================== ================================================= + + +How to run +========== + +1. Download ksmbd-tools and compile them. + - https://github.com/cifsd-team/ksmbd-tools + +2. Create user/password for SMB share. + + # mkdir /etc/ksmbd/ + # ksmbd.adduser -a + +3. Create /etc/ksmbd/smb.conf file, add SMB share in smb.conf file + - Refer smb.conf.example and + https://github.com/cifsd-team/ksmbd-tools/blob/master/Documentation/configuration.txt + +4. Insert ksmbd.ko module + + # insmod ksmbd.ko + +5. Start ksmbd user space daemon + # ksmbd.mountd + +6. Access share from Windows or Linux using CIFS + +Shutdown KSMBD +============== + +1. kill user and kernel space daemon + # sudo ksmbd.control -s + +How to turn debug print on +========================== + +Each layer +/sys/class/ksmbd-control/debug + +1. Enable all component prints + # sudo ksmbd.control -d "all" + +2. Enable one of components(smb, auth, vfs, oplock, ipc, conn, rdma) + # sudo ksmbd.control -d "smb" + +3. Show what prints are enable. + # cat/sys/class/ksmbd-control/debug + [smb] auth vfs oplock ipc conn [rdma] + +4. Disable prints: + If you try the selected component once more, It is disabled without brackets. -- cgit v1.2.3 From bd09c0556eca17f55fb09a26b6ed27bedd1b42ef Mon Sep 17 00:00:00 2001 From: Daniel Bristot de Oliveira Date: Mon, 28 Jun 2021 11:45:50 +0200 Subject: Documentation: Fix a typo on trace/osnoise-tracer s/RUNTIME IN USE/RUNTIME IN US/ Link: https://lkml.kernel.org/r/43e5160422a967218aa651c47f523e8d32d6a59e.1624872608.git.bristot@redhat.com Fixes: bce29ac9ce0b ("trace: Add osnoise tracer") Signed-off-by: Daniel Bristot de Oliveira Signed-off-by: Steven Rostedt (VMware) --- Documentation/trace/osnoise-tracer.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/trace/osnoise-tracer.rst b/Documentation/trace/osnoise-tracer.rst index 37a3c10fb216..b648cb9bf1f0 100644 --- a/Documentation/trace/osnoise-tracer.rst +++ b/Documentation/trace/osnoise-tracer.rst @@ -77,7 +77,7 @@ In addition to the regular trace fields (from TASK-PID to TIMESTAMP), the tracer prints a message at the end of each period for each CPU that is running an osnoise/ thread. The osnoise specific fields report: - - The RUNTIME IN USE reports the amount of time in microseconds that + - The RUNTIME IN US reports the amount of time in microseconds that the osnoise thread kept looping reading the time. - The NOISE IN US reports the sum of noise in microseconds observed by the osnoise tracer during the associated runtime. -- cgit v1.2.3 From 0ae71c7720e3ae3aabd2e8a072d27f7bd173d25c Mon Sep 17 00:00:00 2001 From: Rodrigo Campos Date: Mon, 17 May 2021 12:39:07 -0700 Subject: seccomp: Support atomic "addfd + send reply" Alban Crequy reported a race condition userspace faces when we want to add some fds and make the syscall return them[1] using seccomp notify. The problem is that currently two different ioctl() calls are needed by the process handling the syscalls (agent) for another userspace process (target): SECCOMP_IOCTL_NOTIF_ADDFD to allocate the fd and SECCOMP_IOCTL_NOTIF_SEND to return that value. Therefore, it is possible for the agent to do the first ioctl to add a file descriptor but the target is interrupted (EINTR) before the agent does the second ioctl() call. This patch adds a flag to the ADDFD ioctl() so it adds the fd and returns that value atomically to the target program, as suggested by Kees Cook[2]. This is done by simply allowing seccomp_do_user_notification() to add the fd and return it in this case. Therefore, in this case the target wakes up from the wait in seccomp_do_user_notification() either to interrupt the syscall or to add the fd and return it. This "allocate an fd and return" functionality is useful for syscalls that return a file descriptor only, like connect(2). Other syscalls that return a file descriptor but not as return value (or return more than one fd), like socketpair(), pipe(), recvmsg with SCM_RIGHTs, will not work with this flag. This effectively combines SECCOMP_IOCTL_NOTIF_ADDFD and SECCOMP_IOCTL_NOTIF_SEND into an atomic opteration. The notification's return value, nor error can be set by the user. Upon successful invocation of the SECCOMP_IOCTL_NOTIF_ADDFD ioctl with the SECCOMP_ADDFD_FLAG_SEND flag, the notifying process's errno will be 0, and the return value will be the file descriptor number that was installed. [1]: https://lore.kernel.org/lkml/CADZs7q4sw71iNHmV8EOOXhUKJMORPzF7thraxZYddTZsxta-KQ@mail.gmail.com/ [2]: https://lore.kernel.org/lkml/202012011322.26DCBC64F2@keescook/ Signed-off-by: Rodrigo Campos Signed-off-by: Sargun Dhillon Acked-by: Tycho Andersen Acked-by: Christian Brauner Signed-off-by: Kees Cook Link: https://lore.kernel.org/r/20210517193908.3113-4-sargun@sargun.me --- Documentation/userspace-api/seccomp_filter.rst | 12 ++++++++++++ 1 file changed, 12 insertions(+) (limited to 'Documentation') diff --git a/Documentation/userspace-api/seccomp_filter.rst b/Documentation/userspace-api/seccomp_filter.rst index 6efb41cc8072..d61219889e49 100644 --- a/Documentation/userspace-api/seccomp_filter.rst +++ b/Documentation/userspace-api/seccomp_filter.rst @@ -259,6 +259,18 @@ and ``ioctl(SECCOMP_IOCTL_NOTIF_SEND)`` a response, indicating what should be returned to userspace. The ``id`` member of ``struct seccomp_notif_resp`` should be the same ``id`` as in ``struct seccomp_notif``. +Userspace can also add file descriptors to the notifying process via +``ioctl(SECCOMP_IOCTL_NOTIF_ADDFD)``. The ``id`` member of +``struct seccomp_notif_addfd`` should be the same ``id`` as in +``struct seccomp_notif``. The ``newfd_flags`` flag may be used to set flags +like O_EXEC on the file descriptor in the notifying process. If the supervisor +wants to inject the file descriptor with a specific number, the +``SECCOMP_ADDFD_FLAG_SETFD`` flag can be used, and set the ``newfd`` member to +the specific number to use. If that file descriptor is already open in the +notifying process it will be replaced. The supervisor can also add an FD, and +respond atomically by using the ``SECCOMP_ADDFD_FLAG_SEND`` flag and the return +value will be the injected file descriptor number. + It is worth noting that ``struct seccomp_data`` contains the values of register arguments to the syscall, but does not contain pointers to memory. The task's memory is accessible to suitably privileged traces via ``ptrace()`` or -- cgit v1.2.3 From 5c0de3d72f8c05678ed769bea24e98128f7ab570 Mon Sep 17 00:00:00 2001 From: Mikulas Patocka Date: Mon, 28 Jun 2021 09:59:37 -0400 Subject: dm writecache: make writeback pause configurable Commit 95b88f4d71cb953e02206be3c757083601391a0f ("dm writecache: pause writeback if cache full and origin being written directly") introduced a code that pauses cache flushing if we are issuing writes directly to the origin. Improve that initial commit by making the timeout code configurable (via the option "pause_writeback"). Also change the default from 1s to 3s because it performed better. Signed-off-by: Mikulas Patocka Signed-off-by: Mike Snitzer --- Documentation/admin-guide/device-mapper/writecache.rst | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/admin-guide/device-mapper/writecache.rst b/Documentation/admin-guide/device-mapper/writecache.rst index 977f82b5a811..65427d8dfca6 100644 --- a/Documentation/admin-guide/device-mapper/writecache.rst +++ b/Documentation/admin-guide/device-mapper/writecache.rst @@ -12,7 +12,6 @@ first sector should contain valid superblock from previous invocation. Constructor parameters: 1. type of the cache device - "p" or "s" - - p - persistent memory - s - SSD 2. the underlying device that will be cached @@ -21,7 +20,6 @@ Constructor parameters: size) 5. the number of optional parameters (the parameters with an argument count as two) - start_sector n (default: 0) offset from the start of cache device in 512-byte sectors high_watermark n (default: 50) @@ -71,6 +69,9 @@ Constructor parameters: metadata_only only metadata is promoted to the cache. This option improves performance for heavier REQ_META workloads. + pause_writeback n (default: 3000) + pause writeback if there was some write I/O redirected to + the origin volume in the last n milliseconds Status: 1. error indicator - 0 if there was no error, otherwise error number -- cgit v1.2.3 From 94b7888b67c4e301635bbfdea1403ed0693242fd Mon Sep 17 00:00:00 2001 From: Gabriel Fernandez Date: Thu, 17 Jun 2021 07:18:13 +0200 Subject: dt-bindings: clock: stm32mp1 new compatible for secure rcc Introduce new compatible string "st,stm32mp1-rcc-secure" for stm32mp1 clock driver when the device is configured with RCC security support hardened. Signed-off-by: Etienne Carriere Signed-off-by: Gabriel Fernandez Acked-by: Rob Herring Link: https://lore.kernel.org/r/20210617051814.12018-11-gabriel.fernandez@foss.st.com Signed-off-by: Stephen Boyd --- Documentation/devicetree/bindings/clock/st,stm32mp1-rcc.yaml | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/st,stm32mp1-rcc.yaml b/Documentation/devicetree/bindings/clock/st,stm32mp1-rcc.yaml index 4e385508f516..8b1ecb2ecdd5 100644 --- a/Documentation/devicetree/bindings/clock/st,stm32mp1-rcc.yaml +++ b/Documentation/devicetree/bindings/clock/st,stm32mp1-rcc.yaml @@ -54,7 +54,9 @@ properties: compatible: items: - - const: st,stm32mp1-rcc + - enum: + - st,stm32mp1-rcc-secure + - st,stm32mp1-rcc - const: syscon reg: @@ -71,7 +73,7 @@ additionalProperties: false examples: - | rcc: rcc@50000000 { - compatible = "st,stm32mp1-rcc", "syscon"; + compatible = "st,stm32mp1-rcc-secure", "syscon"; reg = <0x50000000 0x1000>; #clock-cells = <1>; #reset-cells = <1>; -- cgit v1.2.3 From 2fee14ac97dc74f6a8525e69640c6972a4f36899 Mon Sep 17 00:00:00 2001 From: Wenbin Mei Date: Tue, 15 Jun 2021 11:00:33 +0800 Subject: dt-bindings: mmc: change compatiable string for MT8195 mmc host IP MT8195 mmc host IP is compatible with MT8183, and currently it shows: properties: compatible: oneOf: ... - items: - const: mediatek,mt8192-mmc - const: mediatek,mt8195-mmc - const: mediatek,mt8183-mmc which means the compatible string in the device tree would be: compatible = "mediatek,mt8192-mmc", "mediatek,mt8195-mmc", "mediatek,mt8183-mmc"; The bindings is wrong and that isn't the result we want. instead we want: properties: compatible: oneOf: ... - items: - const: mediatek,mt8192-mmc - const: mediatek,mt8183-mmc - items: - const: mediatek,mt8195-mmc - const: mediatek,mt8183-mmc which would give us: compatible = "mediatek,mt8192-mmc", "mediatek,mt8183-mmc"; and compatible = "mediatek,mt8195-mmc", "mediatek,mt8183-mmc"; Fixes: eb9cb7227e5c (dt-bindings: mmc: Add compatible for Mediatek MT8195) Signed-off-by: Wenbin Mei Acked-by: Rob Herring Link: https://lore.kernel.org/r/1623726033-16073-2-git-send-email-wenbin.mei@mediatek.com Signed-off-by: Ulf Hansson --- Documentation/devicetree/bindings/mmc/mtk-sd.yaml | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mmc/mtk-sd.yaml b/Documentation/devicetree/bindings/mmc/mtk-sd.yaml index 8648d48dbbfd..adaba903858a 100644 --- a/Documentation/devicetree/bindings/mmc/mtk-sd.yaml +++ b/Documentation/devicetree/bindings/mmc/mtk-sd.yaml @@ -31,6 +31,8 @@ properties: - const: mediatek,mt2701-mmc - items: - const: mediatek,mt8192-mmc + - const: mediatek,mt8183-mmc + - items: - const: mediatek,mt8195-mmc - const: mediatek,mt8183-mmc -- cgit v1.2.3 From b117e1e8a86d363fc1ad53df8d2c47884d2c0048 Mon Sep 17 00:00:00 2001 From: Vladimir Oltean Date: Tue, 29 Jun 2021 17:06:47 +0300 Subject: net: dsa: delete dsa_legacy_fdb_add and dsa_legacy_fdb_del We want to add reference counting for FDB entries in cross-chip topologies, and in order for that to have any chance of working and not be unbalanced (leading to entries which are never deleted), we need to ensure that higher layers are sane, because if they aren't, it's garbage in, garbage out. For example, if we add a bridge FDB entry twice, the bridge properly errors out: $ bridge fdb add dev swp0 00:01:02:03:04:07 master static $ bridge fdb add dev swp0 00:01:02:03:04:07 master static RTNETLINK answers: File exists However, the same thing cannot be said about the bridge bypass operations: $ bridge fdb add dev swp0 00:01:02:03:04:07 $ bridge fdb add dev swp0 00:01:02:03:04:07 $ bridge fdb add dev swp0 00:01:02:03:04:07 $ bridge fdb add dev swp0 00:01:02:03:04:07 $ echo $? 0 But one 'bridge fdb del' is enough to remove the entry, no matter how many times it was added. The bridge bypass operations are impossible to maintain in these circumstances and lack of support for reference counting the cross-chip notifiers is holding us back from making further progress, so just drop support for them. The only way left for users to install static bridge FDB entries is the proper one, using the "master static" flags. With this change, rtnl_fdb_add() falls back to calling ndo_dflt_fdb_add() which uses the duplicate-exclusive variant of dev_uc_add(): dev_uc_add_excl(). Because DSA does not (yet) declare IFF_UNICAST_FLT, this results in us going to promiscuous mode: $ bridge fdb add dev swp0 00:01:02:03:04:05 [ 28.206743] device swp0 entered promiscuous mode $ bridge fdb add dev swp0 00:01:02:03:04:05 RTNETLINK answers: File exists So even if it does not completely fail, there is at least some indication that it is behaving differently from before, and closer to user space expectations, I would argue (the lack of a "local|static" specifier defaults to "local", or "host-only", so dev_uc_add() is a reasonable default implementation). If the generic implementation of .ndo_fdb_add provided by Vlad Yasevich is a proof of anything, it only proves that the implementation provided by DSA was always wrong, by not looking at "ndm->ndm_state & NUD_NOARP" (the "static" flag which means that the FDB entry points outwards) and "ndm->ndm_state & NUD_PERMANENT" (the "local" flag which means that the FDB entry points towards the host). It all used to mean the same thing to DSA. Update the documentation so that the users are not confused about what's going on. Signed-off-by: Vladimir Oltean Signed-off-by: David S. Miller --- Documentation/networking/dsa/configuration.rst | 68 ++++++++++++++++++++++++++ 1 file changed, 68 insertions(+) (limited to 'Documentation') diff --git a/Documentation/networking/dsa/configuration.rst b/Documentation/networking/dsa/configuration.rst index 774f0e76c746..2b08f1a772d3 100644 --- a/Documentation/networking/dsa/configuration.rst +++ b/Documentation/networking/dsa/configuration.rst @@ -292,3 +292,71 @@ configuration. # bring up the bridge devices ip link set br0 up + +Forwarding database (FDB) management +------------------------------------ + +The existing DSA switches do not have the necessary hardware support to keep +the software FDB of the bridge in sync with the hardware tables, so the two +tables are managed separately (``bridge fdb show`` queries both, and depending +on whether the ``self`` or ``master`` flags are being used, a ``bridge fdb +add`` or ``bridge fdb del`` command acts upon entries from one or both tables). + +Up until kernel v4.14, DSA only supported user space management of bridge FDB +entries using the bridge bypass operations (which do not update the software +FDB, just the hardware one) using the ``self`` flag (which is optional and can +be omitted). + + .. code-block:: sh + + bridge fdb add dev swp0 00:01:02:03:04:05 self static + # or shorthand + bridge fdb add dev swp0 00:01:02:03:04:05 static + +Due to a bug, the bridge bypass FDB implementation provided by DSA did not +distinguish between ``static`` and ``local`` FDB entries (``static`` are meant +to be forwarded, while ``local`` are meant to be locally terminated, i.e. sent +to the host port). Instead, all FDB entries with the ``self`` flag (implicit or +explicit) are treated by DSA as ``static`` even if they are ``local``. + + .. code-block:: sh + + # This command: + bridge fdb add dev swp0 00:01:02:03:04:05 static + # behaves the same for DSA as this command: + bridge fdb add dev swp0 00:01:02:03:04:05 local + # or shorthand, because the 'local' flag is implicit if 'static' is not + # specified, it also behaves the same as: + bridge fdb add dev swp0 00:01:02:03:04:05 + +The last command is an incorrect way of adding a static bridge FDB entry to a +DSA switch using the bridge bypass operations, and works by mistake. Other +drivers will treat an FDB entry added by the same command as ``local`` and as +such, will not forward it, as opposed to DSA. + +Between kernel v4.14 and v5.14, DSA has supported in parallel two modes of +adding a bridge FDB entry to the switch: the bridge bypass discussed above, as +well as a new mode using the ``master`` flag which installs FDB entries in the +software bridge too. + + .. code-block:: sh + + bridge fdb add dev swp0 00:01:02:03:04:05 master static + +Since kernel v5.14, DSA has gained stronger integration with the bridge's +software FDB, and the support for its bridge bypass FDB implementation (using +the ``self`` flag) has been removed. This results in the following changes: + + .. code-block:: sh + + # This is the only valid way of adding an FDB entry that is supported, + # compatible with v4.14 kernels and later: + bridge fdb add dev swp0 00:01:02:03:04:05 master static + # This command is no longer buggy and the entry is properly treated as + # 'local' instead of being forwarded: + bridge fdb add dev swp0 00:01:02:03:04:05 + # This command no longer installs a static FDB entry to hardware: + bridge fdb add dev swp0 00:01:02:03:04:05 static + +Script writers are therefore encouraged to use the ``master static`` set of +flags when working with bridge FDB entries on DSA switch interfaces. -- cgit v1.2.3 From e55fda8cdcba2cb3d5d46ae5fcd5f243f8b70d6e Mon Sep 17 00:00:00 2001 From: Wang Qing Date: Mon, 28 Jun 2021 19:34:20 -0700 Subject: doc: watchdog: modify the explanation related to watchdog thread "watchdog/%u" threads has be replaced by cpu_stop_work. The current description is extremely misleading. Link: https://lkml.kernel.org/r/1619687073-24686-4-git-send-email-wangqing@vivo.com Signed-off-by: Wang Qing Reviewed-by: Petr Mladek Cc: "Guilherme G. Piccoli" Cc: Joe Perches Cc: Jonathan Corbet Cc: Kees Cook Cc: Mauro Carvalho Chehab Cc: Qais Yousef Cc: Randy Dunlap Cc: Santosh Sivaraj Cc: Stephen Kitt Cc: Vlastimil Babka Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/admin-guide/lockup-watchdogs.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/admin-guide/lockup-watchdogs.rst b/Documentation/admin-guide/lockup-watchdogs.rst index 290840c160af..3e09284a8b9b 100644 --- a/Documentation/admin-guide/lockup-watchdogs.rst +++ b/Documentation/admin-guide/lockup-watchdogs.rst @@ -39,7 +39,7 @@ in principle, they should work in any architecture where these subsystems are present. A periodic hrtimer runs to generate interrupts and kick the watchdog -task. An NMI perf event is generated every "watchdog_thresh" +job. An NMI perf event is generated every "watchdog_thresh" (compile-time initialized to 10 and configurable through sysctl of the same name) seconds to check for hardlockups. If any CPU in the system does not receive any hrtimer interrupt during that time the @@ -47,7 +47,7 @@ does not receive any hrtimer interrupt during that time the generate a kernel warning or call panic, depending on the configuration. -The watchdog task is a high priority kernel thread that updates a +The watchdog job runs in a stop scheduling thread that updates a timestamp every time it is scheduled. If that timestamp is not updated for 2*watchdog_thresh seconds (the softlockup threshold) the 'softlockup detector' (coded inside the hrtimer callback function) -- cgit v1.2.3 From 256f7a6791e8f19bafa1d702f69a6a6ba16250e3 Mon Sep 17 00:00:00 2001 From: Wang Qing Date: Mon, 28 Jun 2021 19:34:24 -0700 Subject: doc: watchdog: modify the doc related to "watchdog/%u" "watchdog/%u" threads has be replaced by cpu_stop_work. The current description is extremely misleading. Link: https://lkml.kernel.org/r/1619687073-24686-5-git-send-email-wangqing@vivo.com Signed-off-by: Wang Qing Reviewed-by: Petr Mladek Cc: "Guilherme G. Piccoli" Cc: Joe Perches Cc: Jonathan Corbet Cc: Kees Cook Cc: Mauro Carvalho Chehab Cc: Qais Yousef Cc: Randy Dunlap Cc: Santosh Sivaraj Cc: Stephen Kitt Cc: Vlastimil Babka Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/admin-guide/sysctl/kernel.rst | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) (limited to 'Documentation') diff --git a/Documentation/admin-guide/sysctl/kernel.rst b/Documentation/admin-guide/sysctl/kernel.rst index 68b21395a743..04c79017814b 100644 --- a/Documentation/admin-guide/sysctl/kernel.rst +++ b/Documentation/admin-guide/sysctl/kernel.rst @@ -1283,11 +1283,11 @@ This parameter can be used to control the soft lockup detector. = ================================= The soft lockup detector monitors CPUs for threads that are hogging the CPUs -without rescheduling voluntarily, and thus prevent the 'watchdog/N' threads -from running. The mechanism depends on the CPUs ability to respond to timer -interrupts which are needed for the 'watchdog/N' threads to be woken up by -the watchdog timer function, otherwise the NMI watchdog — if enabled — can -detect a hard lockup condition. +without rescheduling voluntarily, and thus prevent the 'migration/N' threads +from running, causing the watchdog work fail to execute. The mechanism depends +on the CPUs ability to respond to timer interrupts which are needed for the +watchdog work to be queued by the watchdog timer function, otherwise the NMI +watchdog — if enabled — can detect a hard lockup condition. stack_erasing -- cgit v1.2.3 From f58780a8e3851edae5bafb7d3af19425308a37f5 Mon Sep 17 00:00:00 2001 From: Gavin Shan Date: Mon, 28 Jun 2021 19:35:19 -0700 Subject: mm/page_reporting: export reporting order as module parameter The macro PAGE_REPORTING_MIN_ORDER is defined as the page reporting threshold. It can't be adjusted at runtime. This introduces a variable (@page_reporting_order) to replace the marcro (PAGE_REPORTING_MIN_ORDER). MAX_ORDER is assigned to it initially, meaning the page reporting is disabled. It will be specified by driver if valid one is provided. Otherwise, it will fall back to @pageblock_order. It's also exported so that the page reporting order can be adjusted at runtime. Link: https://lkml.kernel.org/r/20210625014710.42954-3-gshan@redhat.com Signed-off-by: Gavin Shan Suggested-by: David Hildenbrand Reviewed-by: Alexander Duyck Cc: Anshuman Khandual Cc: Catalin Marinas Cc: "Michael S. Tsirkin" Cc: Will Deacon Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- 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 cb89dbdedc46..566c4b9af3cd 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -3566,6 +3566,12 @@ off: turn off poisoning (default) on: turn on poisoning + page_reporting.page_reporting_order= + [KNL] Minimal page reporting order + Format: + Adjust the minimal page reporting order. The page + reporting is disabled when it exceeds (MAX_ORDER-1). + panic= [KNL] Kernel behaviour on panic: delay timeout > 0: seconds before rebooting timeout = 0: wait forever -- cgit v1.2.3 From 3ff16d30f593d80a958104ee06a94562a12c5879 Mon Sep 17 00:00:00 2001 From: David Gow Date: Mon, 28 Jun 2021 19:40:36 -0700 Subject: kasan: test: improve failure message in KUNIT_EXPECT_KASAN_FAIL() The KUNIT_EXPECT_KASAN_FAIL() macro currently uses KUNIT_EXPECT_EQ() to compare fail_data.report_expected and fail_data.report_found. This always gave a somewhat useless error message on failure, but the addition of extra compile-time checking with READ_ONCE() has caused it to get much longer, and be truncated before anything useful is displayed. Instead, just check fail_data.report_found by hand (we've just set report_expected to 'true'), and print a better failure message with KUNIT_FAIL(). Because of this, report_expected is no longer used anywhere, and can be removed. Beforehand, a failure in: KUNIT_EXPECT_KASAN_FAIL(test, ((volatile char *)area)[3100]); would have looked like: [22:00:34] [FAILED] vmalloc_oob [22:00:34] # vmalloc_oob: EXPECTATION FAILED at lib/test_kasan.c:991 [22:00:34] Expected ({ do { extern void __compiletime_assert_705(void) __attribute__((__error__("Unsupported access size for {READ,WRITE}_ONCE()."))); if (!((sizeof(fail_data.report_expected) == sizeof(char) || sizeof(fail_data.repp [22:00:34] not ok 45 - vmalloc_oob With this change, it instead looks like: [22:04:04] [FAILED] vmalloc_oob [22:04:04] # vmalloc_oob: EXPECTATION FAILED at lib/test_kasan.c:993 [22:04:04] KASAN failure expected in "((volatile char *)area)[3100]", but none occurred [22:04:04] not ok 45 - vmalloc_oob Also update the example failure in the documentation to reflect this. Link: https://lkml.kernel.org/r/20210606005531.165954-1-davidgow@google.com Signed-off-by: David Gow Reviewed-by: Andrey Konovalov Reviewed-by: Marco Elver Acked-by: Brendan Higgins Cc: Andrey Ryabinin Cc: Dmitry Vyukov Cc: Daniel Axtens Cc: David Gow Cc: Jonathan Corbet Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/dev-tools/kasan.rst | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) (limited to 'Documentation') diff --git a/Documentation/dev-tools/kasan.rst b/Documentation/dev-tools/kasan.rst index d3f335ffc751..83ec4a556c19 100644 --- a/Documentation/dev-tools/kasan.rst +++ b/Documentation/dev-tools/kasan.rst @@ -447,11 +447,10 @@ When a test fails due to a failed ``kmalloc``:: When a test fails due to a missing KASAN report:: - # kmalloc_double_kzfree: EXPECTATION FAILED at lib/test_kasan.c:629 - Expected kasan_data->report_expected == kasan_data->report_found, but - kasan_data->report_expected == 1 - kasan_data->report_found == 0 - not ok 28 - kmalloc_double_kzfree + # kmalloc_double_kzfree: EXPECTATION FAILED at lib/test_kasan.c:974 + KASAN failure expected in "kfree_sensitive(ptr)", but none occurred + not ok 44 - kmalloc_double_kzfree + At the end the cumulative status of all KASAN tests is printed. On success:: -- cgit v1.2.3 From bbbecb35a41cb5c63ef78e14cc8b95fa9130bc1a Mon Sep 17 00:00:00 2001 From: Mel Gorman Date: Mon, 28 Jun 2021 19:42:09 -0700 Subject: mm/page_alloc: delete vm.percpu_pagelist_fraction Patch series "Calculate pcp->high based on zone sizes and active CPUs", v2. The per-cpu page allocator (PCP) is meant to reduce contention on the zone lock but the sizing of batch and high is archaic and neither takes the zone size into account or the number of CPUs local to a zone. With larger zones and more CPUs per node, the contention is getting worse. Furthermore, the fact that vm.percpu_pagelist_fraction adjusts both batch and high values means that the sysctl can reduce zone lock contention but also increase allocation latencies. This series disassociates pcp->high from pcp->batch and then scales pcp->high based on the size of the local zone with limited impact to reclaim and accounting for active CPUs but leaves pcp->batch static. It also adapts the number of pages that can be on the pcp list based on recent freeing patterns. The motivation is partially to adjust to larger memory sizes but is also driven by the fact that large batches of page freeing via release_pages() often shows zone contention as a major part of the problem. Another is a bug report based on an older kernel where a multi-terabyte process can takes several minutes to exit. A workaround was to use vm.percpu_pagelist_fraction to increase the pcp->high value but testing indicated that a production workload could not use the same values because of an increase in allocation latencies. Unfortunately, I cannot reproduce this test case myself as the multi-terabyte machines are in active use but it should alleviate the problem. The series aims to address both and partially acts as a pre-requisite. pcp only works with order-0 which is useless for SLUB (when using high orders) and THP (unconditionally). To store high-order pages on PCP, the pcp->high values need to be increased first. This patch (of 6): The vm.percpu_pagelist_fraction is used to increase the batch and high limits for the per-cpu page allocator (PCP). The intent behind the sysctl is to reduce zone lock acquisition when allocating/freeing pages but it has a problem. While it can decrease contention, it can also increase latency on the allocation side due to unreasonably large batch sizes. This leads to games where an administrator adjusts percpu_pagelist_fraction on the fly to work around contention and allocation latency problems. This series aims to alleviate the problems with zone lock contention while avoiding the allocation-side latency problems. For the purposes of review, it's easier to remove this sysctl now and reintroduce a similar sysctl later in the series that deals only with pcp->high. Link: https://lkml.kernel.org/r/20210525080119.5455-1-mgorman@techsingularity.net Link: https://lkml.kernel.org/r/20210525080119.5455-2-mgorman@techsingularity.net Signed-off-by: Mel Gorman Acked-by: Dave Hansen Acked-by: Vlastimil Babka Cc: Hillf Danton Cc: Michal Hocko Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/admin-guide/sysctl/vm.rst | 19 ------------------- 1 file changed, 19 deletions(-) (limited to 'Documentation') diff --git a/Documentation/admin-guide/sysctl/vm.rst b/Documentation/admin-guide/sysctl/vm.rst index 586cd4b86428..2fcafccb53a8 100644 --- a/Documentation/admin-guide/sysctl/vm.rst +++ b/Documentation/admin-guide/sysctl/vm.rst @@ -64,7 +64,6 @@ Currently, these files are in /proc/sys/vm: - overcommit_ratio - page-cluster - panic_on_oom -- percpu_pagelist_fraction - stat_interval - stat_refresh - numa_stat @@ -790,24 +789,6 @@ panic_on_oom=2+kdump gives you very strong tool to investigate why oom happens. You can get snapshot. -percpu_pagelist_fraction -======================== - -This is the fraction of pages at most (high mark pcp->high) in each zone that -are allocated for each per cpu page list. The min value for this is 8. It -means that we don't allow more than 1/8th of pages in each zone to be -allocated in any single per_cpu_pagelist. This entry only changes the value -of hot per cpu pagelists. User can specify a number like 100 to allocate -1/100th of each zone to each per cpu page list. - -The batch value of each per cpu pagelist is also updated as a result. It is -set to pcp->high/4. The upper limit of batch is (PAGE_SHIFT * 8) - -The initial value is zero. Kernel does not use this value at boot time to set -the high water marks for each per cpu page list. If the user writes '0' to this -sysctl, it will revert to this default behavior. - - stat_interval ============= -- cgit v1.2.3 From 74f44822097c665041010994502b5971d6cd9f04 Mon Sep 17 00:00:00 2001 From: Mel Gorman Date: Mon, 28 Jun 2021 19:42:24 -0700 Subject: mm/page_alloc: introduce vm.percpu_pagelist_high_fraction This introduces a new sysctl vm.percpu_pagelist_high_fraction. It is similar to the old vm.percpu_pagelist_fraction. The old sysctl increased both pcp->batch and pcp->high with the higher pcp->high potentially reducing zone->lock contention. However, the higher pcp->batch value also potentially increased allocation latency while the PCP was refilled. This sysctl only adjusts pcp->high so that zone->lock contention is potentially reduced but allocation latency during a PCP refill remains the same. # grep -E "high:|batch" /proc/zoneinfo | tail -2 high: 649 batch: 63 # sysctl vm.percpu_pagelist_high_fraction=8 # grep -E "high:|batch" /proc/zoneinfo | tail -2 high: 35071 batch: 63 # sysctl vm.percpu_pagelist_high_fraction=64 high: 4383 batch: 63 # sysctl vm.percpu_pagelist_high_fraction=0 high: 649 batch: 63 [mgorman@techsingularity.net: fix documentation] Link: https://lkml.kernel.org/r/20210528151010.GQ30378@techsingularity.net Link: https://lkml.kernel.org/r/20210525080119.5455-7-mgorman@techsingularity.net Signed-off-by: Mel Gorman Acked-by: Dave Hansen Acked-by: Vlastimil Babka Cc: Hillf Danton Cc: Michal Hocko Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/admin-guide/sysctl/vm.rst | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) (limited to 'Documentation') diff --git a/Documentation/admin-guide/sysctl/vm.rst b/Documentation/admin-guide/sysctl/vm.rst index 2fcafccb53a8..2da25735a629 100644 --- a/Documentation/admin-guide/sysctl/vm.rst +++ b/Documentation/admin-guide/sysctl/vm.rst @@ -64,6 +64,7 @@ Currently, these files are in /proc/sys/vm: - overcommit_ratio - page-cluster - panic_on_oom +- percpu_pagelist_high_fraction - stat_interval - stat_refresh - numa_stat @@ -789,6 +790,26 @@ panic_on_oom=2+kdump gives you very strong tool to investigate why oom happens. You can get snapshot. +percpu_pagelist_high_fraction +============================= + +This is the fraction of pages in each zone that are can be stored to +per-cpu page lists. It is an upper boundary that is divided depending +on the number of online CPUs. The min value for this is 8 which means +that we do not allow more than 1/8th of pages in each zone to be stored +on per-cpu page lists. This entry only changes the value of hot per-cpu +page lists. A user can specify a number like 100 to allocate 1/100th of +each zone between per-cpu lists. + +The batch value of each per-cpu page list remains the same regardless of +the value of the high fraction so allocation latencies are unaffected. + +The initial value is zero. Kernel uses this value to set the high pcp->high +mark based on the low watermark for the zone and the number of local +online CPUs. If the user writes '0' to this sysctl, it will revert to +this default behavior. + + stat_interval ============= -- cgit v1.2.3 From 48d9f3355a8eaa79b00472929b517df497fc6d5f Mon Sep 17 00:00:00 2001 From: Mike Rapoport Date: Mon, 28 Jun 2021 19:42:58 -0700 Subject: docs: remove description of DISCONTIGMEM Remove description of DISCONTIGMEM from the "Memory Models" document and update VM sysctl description so that it won't mention DISCONIGMEM. Link: https://lkml.kernel.org/r/20210608091316.3622-8-rppt@kernel.org Signed-off-by: Mike Rapoport Acked-by: Arnd Bergmann Reviewed-by: David Hildenbrand Cc: Geert Uytterhoeven Cc: Ivan Kokshaysky Cc: Jonathan Corbet Cc: Matt Turner Cc: Richard Henderson Cc: Vineet Gupta Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/admin-guide/sysctl/vm.rst | 12 ++++----- Documentation/vm/memory-model.rst | 45 ++------------------------------- 2 files changed, 8 insertions(+), 49 deletions(-) (limited to 'Documentation') diff --git a/Documentation/admin-guide/sysctl/vm.rst b/Documentation/admin-guide/sysctl/vm.rst index 2da25735a629..8387ad0b0b83 100644 --- a/Documentation/admin-guide/sysctl/vm.rst +++ b/Documentation/admin-guide/sysctl/vm.rst @@ -938,12 +938,12 @@ allocations, THP and hugetlbfs pages. To make it sensible with respect to the watermark_scale_factor parameter, the unit is in fractions of 10,000. The default value of -15,000 on !DISCONTIGMEM configurations means that up to 150% of the high -watermark will be reclaimed in the event of a pageblock being mixed due -to fragmentation. The level of reclaim is determined by the number of -fragmentation events that occurred in the recent past. If this value is -smaller than a pageblock then a pageblocks worth of pages will be reclaimed -(e.g. 2MB on 64-bit x86). A boost factor of 0 will disable the feature. +15,000 means that up to 150% of the high watermark will be reclaimed in the +event of a pageblock being mixed due to fragmentation. The level of reclaim +is determined by the number of fragmentation events that occurred in the +recent past. If this value is smaller than a pageblock then a pageblocks +worth of pages will be reclaimed (e.g. 2MB on 64-bit x86). A boost factor +of 0 will disable the feature. watermark_scale_factor diff --git a/Documentation/vm/memory-model.rst b/Documentation/vm/memory-model.rst index ce398a7dc6cd..30e8fbed6914 100644 --- a/Documentation/vm/memory-model.rst +++ b/Documentation/vm/memory-model.rst @@ -14,15 +14,11 @@ for the CPU. Then there could be several contiguous ranges at completely distinct addresses. And, don't forget about NUMA, where different memory banks are attached to different CPUs. -Linux abstracts this diversity using one of the three memory models: -FLATMEM, DISCONTIGMEM and SPARSEMEM. Each architecture defines what +Linux abstracts this diversity using one of the two memory models: +FLATMEM and SPARSEMEM. Each architecture defines what memory models it supports, what the default memory model is and whether it is possible to manually override that default. -.. note:: - At time of this writing, DISCONTIGMEM is considered deprecated, - although it is still in use by several architectures. - All the memory models track the status of physical page frames using struct page arranged in one or more arrays. @@ -63,43 +59,6 @@ straightforward: `PFN - ARCH_PFN_OFFSET` is an index to the The `ARCH_PFN_OFFSET` defines the first page frame number for systems with physical memory starting at address different from 0. -DISCONTIGMEM -============ - -The DISCONTIGMEM model treats the physical memory as a collection of -`nodes` similarly to how Linux NUMA support does. For each node Linux -constructs an independent memory management subsystem represented by -`struct pglist_data` (or `pg_data_t` for short). Among other -things, `pg_data_t` holds the `node_mem_map` array that maps -physical pages belonging to that node. The `node_start_pfn` field of -`pg_data_t` is the number of the first page frame belonging to that -node. - -The architecture setup code should call :c:func:`free_area_init_node` for -each node in the system to initialize the `pg_data_t` object and its -`node_mem_map`. - -Every `node_mem_map` behaves exactly as FLATMEM's `mem_map` - -every physical page frame in a node has a `struct page` entry in the -`node_mem_map` array. When DISCONTIGMEM is enabled, a portion of the -`flags` field of the `struct page` encodes the node number of the -node hosting that page. - -The conversion between a PFN and the `struct page` in the -DISCONTIGMEM model became slightly more complex as it has to determine -which node hosts the physical page and which `pg_data_t` object -holds the `struct page`. - -Architectures that support DISCONTIGMEM provide :c:func:`pfn_to_nid` -to convert PFN to the node number. The opposite conversion helper -:c:func:`page_to_nid` is generic as it uses the node number encoded in -page->flags. - -Once the node number is known, the PFN can be used to index -appropriate `node_mem_map` array to access the `struct page` and -the offset of the `struct page` from the `node_mem_map` plus -`node_start_pfn` is the PFN of that page. - SPARSEMEM ========= -- cgit v1.2.3 From f587623b78ff538f5d9ef1241e58b91ea70a4daf Mon Sep 17 00:00:00 2001 From: Matthew Brost Date: Tue, 29 Jun 2021 12:35:10 -0700 Subject: drm/doc/rfc: i915 GuC submission / DRM scheduler MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Add entry for i915 GuC submission / DRM scheduler integration plan. Follow up patch with details of new parallel submission uAPI to come. v2: (Daniel Vetter) - Expand explaination of why bonding isn't supported for GuC submission - CC some of the DRM scheduler maintainers - Add priority inheritance / boosting use case - Add reasoning for removing in order assumptions (Daniel Stone) - Add links to priority spec v4: (Tvrtko) - Add TODOs section (Daniel Vetter) - Pull in 1 line from following patch v5: (Checkpatch) - Fix typos Cc: Christian König Cc: Luben Tuikov Cc: Alex Deucher Cc: Steven Price Cc: Jon Bloomfield Cc: Dave Airlie Cc: Daniel Vetter Cc: Jason Ekstrand Cc: dri-devel@lists.freedesktop.org Signed-off-by: Matthew Brost Reviewed-by: Daniel Vetter Acked-by: Dave Airlie Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20210629193511.124099-2-matthew.brost@intel.com --- Documentation/gpu/rfc/i915_scheduler.rst | 91 ++++++++++++++++++++++++++++++++ Documentation/gpu/rfc/index.rst | 4 ++ 2 files changed, 95 insertions(+) create mode 100644 Documentation/gpu/rfc/i915_scheduler.rst (limited to 'Documentation') diff --git a/Documentation/gpu/rfc/i915_scheduler.rst b/Documentation/gpu/rfc/i915_scheduler.rst new file mode 100644 index 000000000000..7acd386a6b49 --- /dev/null +++ b/Documentation/gpu/rfc/i915_scheduler.rst @@ -0,0 +1,91 @@ +========================================= +I915 GuC Submission/DRM Scheduler Section +========================================= + +Upstream plan +============= +For upstream the overall plan for landing GuC submission and integrating the +i915 with the DRM scheduler is: + +* Merge basic GuC submission + * Basic submission support for all gen11+ platforms + * Not enabled by default on any current platforms but can be enabled via + modparam enable_guc + * Lots of rework will need to be done to integrate with DRM scheduler so + no need to nit pick everything in the code, it just should be + functional, no major coding style / layering errors, and not regress + execlists + * Update IGTs / selftests as needed to work with GuC submission + * Enable CI on supported platforms for a baseline + * Rework / get CI heathly for GuC submission in place as needed +* Merge new parallel submission uAPI + * Bonding uAPI completely incompatible with GuC submission, plus it has + severe design issues in general, which is why we want to retire it no + matter what + * New uAPI adds I915_CONTEXT_ENGINES_EXT_PARALLEL context setup step + which configures a slot with N contexts + * After I915_CONTEXT_ENGINES_EXT_PARALLEL a user can submit N batches to + a slot in a single execbuf IOCTL and the batches run on the GPU in + paralllel + * Initially only for GuC submission but execlists can be supported if + needed +* Convert the i915 to use the DRM scheduler + * GuC submission backend fully integrated with DRM scheduler + * All request queues removed from backend (e.g. all backpressure + handled in DRM scheduler) + * Resets / cancels hook in DRM scheduler + * Watchdog hooks into DRM scheduler + * Lots of complexity of the GuC backend can be pulled out once + integrated with DRM scheduler (e.g. state machine gets + simplier, locking gets simplier, etc...) + * Execlists backend will minimum required to hook in the DRM scheduler + * Legacy interface + * Features like timeslicing / preemption / virtual engines would + be difficult to integrate with the DRM scheduler and these + features are not required for GuC submission as the GuC does + these things for us + * ROI low on fully integrating into DRM scheduler + * Fully integrating would add lots of complexity to DRM + scheduler + * Port i915 priority inheritance / boosting feature in DRM scheduler + * Used for i915 page flip, may be useful to other DRM drivers as + well + * Will be an optional feature in the DRM scheduler + * Remove in-order completion assumptions from DRM scheduler + * Even when using the DRM scheduler the backends will handle + preemption, timeslicing, etc... so it is possible for jobs to + finish out of order + * Pull out i915 priority levels and use DRM priority levels + * Optimize DRM scheduler as needed + +TODOs for GuC submission upstream +================================= + +* Need an update to GuC firmware / i915 to enable error state capture +* Open source tool to decode GuC logs +* Public GuC spec + +New uAPI for basic GuC submission +================================= +No major changes are required to the uAPI for basic GuC submission. The only +change is a new scheduler attribute: I915_SCHEDULER_CAP_STATIC_PRIORITY_MAP. +This attribute indicates the 2k i915 user priority levels are statically mapped +into 3 levels as follows: + +* -1k to -1 Low priority +* 0 Medium priority +* 1 to 1k High priority + +This is needed because the GuC only has 4 priority bands. The highest priority +band is reserved with the kernel. This aligns with the DRM scheduler priority +levels too. + +Spec references: +---------------- +* https://www.khronos.org/registry/EGL/extensions/IMG/EGL_IMG_context_priority.txt +* https://www.khronos.org/registry/vulkan/specs/1.2-extensions/html/chap5.html#devsandqueues-priority +* https://spec.oneapi.com/level-zero/latest/core/api.html#ze-command-queue-priority-t + +New parallel submission uAPI +============================ +Details to come in a following patch. diff --git a/Documentation/gpu/rfc/index.rst b/Documentation/gpu/rfc/index.rst index 05670442ca1b..91e93a705230 100644 --- a/Documentation/gpu/rfc/index.rst +++ b/Documentation/gpu/rfc/index.rst @@ -19,3 +19,7 @@ host such documentation: .. toctree:: i915_gem_lmem.rst + +.. toctree:: + + i915_scheduler.rst -- cgit v1.2.3 From 0454a490bdebea78e93e325a020f9f80908b9ed6 Mon Sep 17 00:00:00 2001 From: Matthew Brost Date: Tue, 29 Jun 2021 12:35:11 -0700 Subject: drm/doc/rfc: i915 new parallel submission uAPI plan MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Add entry for i915 new parallel submission uAPI plan. v2: (Daniel Vetter): - Expand logical order explaination - Add dummy header - Only allow N BBs in execbuf IOCTL - Configure parallel submission per slot not per gem context v3: (Marcin Ślusarz): - Lot's of typos / bad english fixed (Tvrtko Ursulin): - Consistent pseudo code, clean up wording in descriptions v4: (Daniel Vetter) - Drop flags - Add kernel doc - Reword a few things / fix typos (Tvrtko) - Reword a few things / fix typos v5: (Checkpatch) - Fix typos (Docs) - Fix warning Cc: Tvrtko Ursulin Cc: Tony Ye CC: Carl Zhang Cc: Daniel Vetter Cc: Jason Ekstrand Signed-off-by: Matthew Brost Acked-by: Daniel Vetter Acked-by: Tony Ye Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20210629193511.124099-3-matthew.brost@intel.com --- Documentation/gpu/rfc/i915_parallel_execbuf.h | 122 ++++++++++++++++++++++++++ Documentation/gpu/rfc/i915_scheduler.rst | 59 ++++++++++++- 2 files changed, 180 insertions(+), 1 deletion(-) create mode 100644 Documentation/gpu/rfc/i915_parallel_execbuf.h (limited to 'Documentation') diff --git a/Documentation/gpu/rfc/i915_parallel_execbuf.h b/Documentation/gpu/rfc/i915_parallel_execbuf.h new file mode 100644 index 000000000000..8cbe2c4e0172 --- /dev/null +++ b/Documentation/gpu/rfc/i915_parallel_execbuf.h @@ -0,0 +1,122 @@ +/* SPDX-License-Identifier: MIT */ +/* + * Copyright © 2021 Intel Corporation + */ + +#define I915_CONTEXT_ENGINES_EXT_PARALLEL_SUBMIT 2 /* see i915_context_engines_parallel_submit */ + +/** + * struct drm_i915_context_engines_parallel_submit - Configure engine for + * parallel submission. + * + * Setup a slot in the context engine map to allow multiple BBs to be submitted + * in a single execbuf IOCTL. Those BBs will then be scheduled to run on the GPU + * in parallel. Multiple hardware contexts are created internally in the i915 + * run these BBs. Once a slot is configured for N BBs only N BBs can be + * submitted in each execbuf IOCTL and this is implicit behavior e.g. The user + * doesn't tell the execbuf IOCTL there are N BBs, the execbuf IOCTL knows how + * many BBs there are based on the slot's configuration. The N BBs are the last + * N buffer objects or first N if I915_EXEC_BATCH_FIRST is set. + * + * The default placement behavior is to create implicit bonds between each + * context if each context maps to more than 1 physical engine (e.g. context is + * a virtual engine). Also we only allow contexts of same engine class and these + * contexts must be in logically contiguous order. Examples of the placement + * behavior described below. Lastly, the default is to not allow BBs to + * preempted mid BB rather insert coordinated preemption on all hardware + * contexts between each set of BBs. Flags may be added in the future to change + * both of these default behaviors. + * + * Returns -EINVAL if hardware context placement configuration is invalid or if + * the placement configuration isn't supported on the platform / submission + * interface. + * Returns -ENODEV if extension isn't supported on the platform / submission + * interface. + * + * .. code-block:: none + * + * Example 1 pseudo code: + * CS[X] = generic engine of same class, logical instance X + * INVALID = I915_ENGINE_CLASS_INVALID, I915_ENGINE_CLASS_INVALID_NONE + * set_engines(INVALID) + * set_parallel(engine_index=0, width=2, num_siblings=1, + * engines=CS[0],CS[1]) + * + * Results in the following valid placement: + * CS[0], CS[1] + * + * Example 2 pseudo code: + * CS[X] = generic engine of same class, logical instance X + * INVALID = I915_ENGINE_CLASS_INVALID, I915_ENGINE_CLASS_INVALID_NONE + * set_engines(INVALID) + * set_parallel(engine_index=0, width=2, num_siblings=2, + * engines=CS[0],CS[2],CS[1],CS[3]) + * + * Results in the following valid placements: + * CS[0], CS[1] + * CS[2], CS[3] + * + * This can also be thought of as 2 virtual engines described by 2-D array + * in the engines the field with bonds placed between each index of the + * virtual engines. e.g. CS[0] is bonded to CS[1], CS[2] is bonded to + * CS[3]. + * VE[0] = CS[0], CS[2] + * VE[1] = CS[1], CS[3] + * + * Example 3 pseudo code: + * CS[X] = generic engine of same class, logical instance X + * INVALID = I915_ENGINE_CLASS_INVALID, I915_ENGINE_CLASS_INVALID_NONE + * set_engines(INVALID) + * set_parallel(engine_index=0, width=2, num_siblings=2, + * engines=CS[0],CS[1],CS[1],CS[3]) + * + * Results in the following valid and invalid placements: + * CS[0], CS[1] + * CS[1], CS[3] - Not logical contiguous, return -EINVAL + */ +struct drm_i915_context_engines_parallel_submit { + /** + * @base: base user extension. + */ + struct i915_user_extension base; + + /** + * @engine_index: slot for parallel engine + */ + __u16 engine_index; + + /** + * @width: number of contexts per parallel engine + */ + __u16 width; + + /** + * @num_siblings: number of siblings per context + */ + __u16 num_siblings; + + /** + * @mbz16: reserved for future use; must be zero + */ + __u16 mbz16; + + /** + * @flags: all undefined flags must be zero, currently not defined flags + */ + __u64 flags; + + /** + * @mbz64: reserved for future use; must be zero + */ + __u64 mbz64[3]; + + /** + * @engines: 2-d array of engine instances to configure parallel engine + * + * length = width (i) * num_siblings (j) + * index = j + i * num_siblings + */ + struct i915_engine_class_instance engines[0]; + +} __packed; + diff --git a/Documentation/gpu/rfc/i915_scheduler.rst b/Documentation/gpu/rfc/i915_scheduler.rst index 7acd386a6b49..cbda75065dad 100644 --- a/Documentation/gpu/rfc/i915_scheduler.rst +++ b/Documentation/gpu/rfc/i915_scheduler.rst @@ -88,4 +88,61 @@ Spec references: New parallel submission uAPI ============================ -Details to come in a following patch. +The existing bonding uAPI is completely broken with GuC submission because +whether a submission is a single context submit or parallel submit isn't known +until execbuf time activated via the I915_SUBMIT_FENCE. To submit multiple +contexts in parallel with the GuC the context must be explicitly registered with +N contexts and all N contexts must be submitted in a single command to the GuC. +The GuC interfaces do not support dynamically changing between N contexts as the +bonding uAPI does. Hence the need for a new parallel submission interface. Also +the legacy bonding uAPI is quite confusing and not intuitive at all. Furthermore +I915_SUBMIT_FENCE is by design a future fence, so not really something we should +continue to support. + +The new parallel submission uAPI consists of 3 parts: + +* Export engines logical mapping +* A 'set_parallel' extension to configure contexts for parallel + submission +* Extend execbuf2 IOCTL to support submitting N BBs in a single IOCTL + +Export engines logical mapping +------------------------------ +Certain use cases require BBs to be placed on engine instances in logical order +(e.g. split-frame on gen11+). The logical mapping of engine instances can change +based on fusing. Rather than making UMDs be aware of fusing, simply expose the +logical mapping with the existing query engine info IOCTL. Also the GuC +submission interface currently only supports submitting multiple contexts to +engines in logical order which is a new requirement compared to execlists. +Lastly, all current platforms have at most 2 engine instances and the logical +order is the same as uAPI order. This will change on platforms with more than 2 +engine instances. + +A single bit will be added to drm_i915_engine_info.flags indicating that the +logical instance has been returned and a new field, +drm_i915_engine_info.logical_instance, returns the logical instance. + +A 'set_parallel' extension to configure contexts for parallel submission +------------------------------------------------------------------------ +The 'set_parallel' extension configures a slot for parallel submission of N BBs. +It is a setup step that must be called before using any of the contexts. See +I915_CONTEXT_ENGINES_EXT_LOAD_BALANCE or I915_CONTEXT_ENGINES_EXT_BOND for +similar existing examples. Once a slot is configured for parallel submission the +execbuf2 IOCTL can be called submitting N BBs in a single IOCTL. Initially only +supports GuC submission. Execlists supports can be added later if needed. + +Add I915_CONTEXT_ENGINES_EXT_PARALLEL_SUBMIT and +drm_i915_context_engines_parallel_submit to the uAPI to implement this +extension. + +.. kernel-doc:: Documentation/gpu/rfc/i915_parallel_execbuf.h + :functions: drm_i915_context_engines_parallel_submit + +Extend execbuf2 IOCTL to support submitting N BBs in a single IOCTL +------------------------------------------------------------------- +Contexts that have been configured with the 'set_parallel' extension can only +submit N BBs in a single execbuf2 IOCTL. The BBs are either the last N objects +in the drm_i915_gem_exec_object2 list or the first N if I915_EXEC_BATCH_FIRST is +set. The number of BBs is implicit based on the slot submitted and how it has +been configured by 'set_parallel' or other extensions. No uAPI changes are +required to the execbuf2 IOCTL. -- cgit v1.2.3 From 2bc434b12d1283f16e388b0fd682303aa9c16db6 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=E5=91=A8=E7=90=B0=E6=9D=B0=20=28Zhou=20Yanjie=29?= Date: Sat, 26 Jun 2021 14:18:38 +0800 Subject: dt-bindings: clock: Add documentation for MAC PHY control bindings. MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Update the CGU binding documentation, add mac-phy-ctrl as a pattern property. Signed-off-by: 周琰杰 (Zhou Yanjie) Acked-by: Paul Cercueil Acked-by: Stephen Boyd Signed-off-by: Thomas Bogendoerfer --- Documentation/devicetree/bindings/clock/ingenic,cgu.yaml | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/ingenic,cgu.yaml b/Documentation/devicetree/bindings/clock/ingenic,cgu.yaml index c65b9458c0b6..ee9b5fbf8e91 100644 --- a/Documentation/devicetree/bindings/clock/ingenic,cgu.yaml +++ b/Documentation/devicetree/bindings/clock/ingenic,cgu.yaml @@ -93,6 +93,8 @@ required: patternProperties: "^usb-phy@[a-f0-9]+$": allOf: [ $ref: "../phy/ingenic,phy-usb.yaml#" ] + "^mac-phy-ctrl@[a-f0-9]+$": + allOf: [ $ref: "../net/ingenic,mac.yaml#" ] additionalProperties: false -- cgit v1.2.3 From 3e0f897fd92662f0ff21ca1759d724a9ad574858 Mon Sep 17 00:00:00 2001 From: Viresh Kumar Date: Wed, 23 Jun 2021 09:54:42 +0530 Subject: cpufreq: Remove the ->stop_cpu() driver callback Now that all users of ->stop_cpu() have been migrated to using other callbacks, drop it from the core. Signed-off-by: Viresh Kumar [ rjw: Minor edits in the subject and changelog ] Signed-off-by: Rafael J. Wysocki --- Documentation/cpu-freq/cpu-drivers.rst | 3 --- Documentation/translations/zh_CN/cpu-freq/cpu-drivers.rst | 3 --- 2 files changed, 6 deletions(-) (limited to 'Documentation') diff --git a/Documentation/cpu-freq/cpu-drivers.rst b/Documentation/cpu-freq/cpu-drivers.rst index a697278ce190..74fac797c396 100644 --- a/Documentation/cpu-freq/cpu-drivers.rst +++ b/Documentation/cpu-freq/cpu-drivers.rst @@ -71,9 +71,6 @@ And optionally .exit - A pointer to a per-policy cleanup function called during CPU_POST_DEAD phase of cpu hotplug process. - .stop_cpu - A pointer to a per-policy stop function called during - CPU_DOWN_PREPARE phase of cpu hotplug process. - .suspend - A pointer to a per-policy suspend function which is called with interrupts disabled and _after_ the governor is stopped for the policy. diff --git a/Documentation/translations/zh_CN/cpu-freq/cpu-drivers.rst b/Documentation/translations/zh_CN/cpu-freq/cpu-drivers.rst index 0ca2cb646666..9570e9c9e939 100644 --- a/Documentation/translations/zh_CN/cpu-freq/cpu-drivers.rst +++ b/Documentation/translations/zh_CN/cpu-freq/cpu-drivers.rst @@ -76,9 +76,6 @@ CPUfreq核心层注册一个cpufreq_driver结构体。 .exit - 一个指向per-policy清理函数的指针，该函数在cpu热插拔过程的CPU_POST_DEAD 阶段被调用。 - .stop_cpu - 一个指向per-policy停止函数的指针，该函数在cpu热插拔过程的CPU_DOWN_PREPARE - 阶段被调用。 - .suspend - 一个指向per-policy暂停函数的指针，该函数在关中断且在该策略的调节器停止 后被调用。 -- cgit v1.2.3 From b0b8d558efb5b607fc35fbccb9edb5230c41c0ba Mon Sep 17 00:00:00 2001 From: Lokesh Vutla Date: Tue, 1 Jun 2021 15:58:03 +0530 Subject: dt-bindings: pwm: pwm-tiecap: Convert to json schema Convert the tiecap binding to DT schema format using json-schema. Along with this conversion the following changes are included: - 'clock' and 'clock-names' properties are marked required as driver fails to probe without these properties - Dropped ti,am33xx-ecap as it is no longer applicable. - 'power-domains' property is introduced and marked as optional. Signed-off-by: Lokesh Vutla Reviewed-by: Rob Herring Signed-off-by: Thierry Reding --- .../devicetree/bindings/pwm/pwm-tiecap.txt | 51 ------------------ .../devicetree/bindings/pwm/pwm-tiecap.yaml | 63 ++++++++++++++++++++++ 2 files changed, 63 insertions(+), 51 deletions(-) delete mode 100644 Documentation/devicetree/bindings/pwm/pwm-tiecap.txt create mode 100644 Documentation/devicetree/bindings/pwm/pwm-tiecap.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pwm/pwm-tiecap.txt b/Documentation/devicetree/bindings/pwm/pwm-tiecap.txt deleted file mode 100644 index c7c4347a769a..000000000000 --- a/Documentation/devicetree/bindings/pwm/pwm-tiecap.txt +++ /dev/null @@ -1,51 +0,0 @@ -TI SOC ECAP based APWM controller - -Required properties: -- compatible: Must be "ti,-ecap". - for am33xx - compatible = "ti,am3352-ecap", "ti,am33xx-ecap"; - for am4372 - compatible = "ti,am4372-ecap", "ti,am3352-ecap", "ti,am33xx-ecap"; - for da850 - compatible = "ti,da850-ecap", "ti,am3352-ecap", "ti,am33xx-ecap"; - for dra746 - compatible = "ti,dra746-ecap", "ti,am3352-ecap"; - for 66ak2g - compatible = "ti,k2g-ecap", "ti,am3352-ecap"; - for am654 - compatible = "ti,am654-ecap", "ti,am3352-ecap"; -- #pwm-cells: should be 3. See pwm.yaml in this directory for a description of - the cells format. The PWM channel index ranges from 0 to 4. The only third - cell flag supported by this binding is PWM_POLARITY_INVERTED. -- reg: physical base address and size of the registers map. - -Optional properties: -- clocks: Handle to the ECAP's functional clock. -- clock-names: Must be set to "fck". - -Example: - -ecap0: ecap@48300100 { /* ECAP on am33xx */ - compatible = "ti,am3352-ecap", "ti,am33xx-ecap"; - #pwm-cells = <3>; - reg = <0x48300100 0x80>; - clocks = <&l4ls_gclk>; - clock-names = "fck"; -}; - -ecap0: ecap@48300100 { /* ECAP on am4372 */ - compatible = "ti,am4372-ecap", "ti,am3352-ecap", "ti,am33xx-ecap"; - #pwm-cells = <3>; - reg = <0x48300100 0x80>; - ti,hwmods = "ecap0"; - clocks = <&l4ls_gclk>; - clock-names = "fck"; -}; - -ecap0: ecap@1f06000 { /* ECAP on da850 */ - compatible = "ti,da850-ecap", "ti,am3352-ecap", "ti,am33xx-ecap"; - #pwm-cells = <3>; - reg = <0x1f06000 0x80>; -}; - -ecap0: ecap@4843e100 { - compatible = "ti,dra746-ecap", "ti,am3352-ecap"; - #pwm-cells = <3>; - reg = <0x4843e100 0x80>; - clocks = <&l4_root_clk_div>; - clock-names = "fck"; -}; diff --git a/Documentation/devicetree/bindings/pwm/pwm-tiecap.yaml b/Documentation/devicetree/bindings/pwm/pwm-tiecap.yaml new file mode 100644 index 000000000000..8717166dd05f --- /dev/null +++ b/Documentation/devicetree/bindings/pwm/pwm-tiecap.yaml @@ -0,0 +1,63 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pwm/pwm-tiecap.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: TI SOC ECAP based APWM controller + +maintainers: + - Vignesh R + +allOf: + - $ref: pwm.yaml# + +properties: + compatible: + oneOf: + - const: ti,am3352-ecap + - items: + - enum: + - ti,da850-ecap + - ti,am4372-ecap + - ti,dra746-ecap + - ti,k2g-ecap + - ti,am654-ecap + - const: ti,am3352-ecap + + reg: + maxItems: 1 + + "#pwm-cells": + const: 3 + description: | + See pwm.yaml in this directory for a description of the cells format. + The only third cell flag supported by this binding is PWM_POLARITY_INVERTED. + + clock-names: + const: fck + + clocks: + maxItems: 1 + + power-domains: + maxItems: 1 + +required: + - compatible + - reg + - "#pwm-cells" + - clocks + - clock-names + +additionalProperties: false + +examples: + - | + ecap0: pwm@48300100 { /* ECAP on am33xx */ + compatible = "ti,am3352-ecap"; + #pwm-cells = <3>; + reg = <0x48300100 0x80>; + clocks = <&l4ls_gclk>; + clock-names = "fck"; + }; -- cgit v1.2.3 From 9939648a53c4c795bdac0d54df22423f81ccf5f0 Mon Sep 17 00:00:00 2001 From: Lokesh Vutla Date: Tue, 1 Jun 2021 15:58:04 +0530 Subject: dt-bindings: pwm: pwm-tiecap: Add compatible string for AM64 SoC Add compatible string for AM64 SoC in device tree binding. IP is compatible with ti,am3352-ecap, so adding the AM64 compatible under enum of one of the compatible list entry. Signed-off-by: Lokesh Vutla Reviewed-by: Rob Herring Signed-off-by: Thierry Reding --- Documentation/devicetree/bindings/pwm/pwm-tiecap.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pwm/pwm-tiecap.yaml b/Documentation/devicetree/bindings/pwm/pwm-tiecap.yaml index 8717166dd05f..ed35b6cc48d5 100644 --- a/Documentation/devicetree/bindings/pwm/pwm-tiecap.yaml +++ b/Documentation/devicetree/bindings/pwm/pwm-tiecap.yaml @@ -23,6 +23,7 @@ properties: - ti,dra746-ecap - ti,k2g-ecap - ti,am654-ecap + - ti,am64-ecap - const: ti,am3352-ecap reg: -- cgit v1.2.3 From ef3d13b867637f9a791b524100362ba7e2b69810 Mon Sep 17 00:00:00 2001 From: Andy Shevchenko Date: Mon, 7 Jun 2021 15:24:53 +0300 Subject: docs: firmware-guide: ACPI: Add a PWM example When PWM support for ACPI has been added into the kernel, it missed the documentation update. Hence update documentation here. Fixes: 4a6ef8e37c4d ("pwm: Add support referencing PWMs from ACPI") Signed-off-by: Andy Shevchenko Acked-by: Rafael J. Wysocki Signed-off-by: Thierry Reding --- Documentation/firmware-guide/acpi/enumeration.rst | 32 +++++++++++++++++++++++ 1 file changed, 32 insertions(+) (limited to 'Documentation') diff --git a/Documentation/firmware-guide/acpi/enumeration.rst b/Documentation/firmware-guide/acpi/enumeration.rst index 9f0d5c854fa4..f588663ba906 100644 --- a/Documentation/firmware-guide/acpi/enumeration.rst +++ b/Documentation/firmware-guide/acpi/enumeration.rst @@ -258,6 +258,38 @@ input driver:: .id_table = mpu3050_ids, }; +Reference to PWM device +======================= + +Sometimes a device can be a consumer of PWM channel. Obviously OS would like +to know which one. To provide this mapping the special property has been +introduced, i.e.:: + + Device (DEV) + { + Name (_DSD, Package () + { + ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), + Package () { + Package () { "compatible", Package () { "pwm-leds" } }, + Package () { "label", "alarm-led" }, + Package () { "pwms", + Package () { + "\\_SB.PCI0.PWM", // + 0, // + 600000000, // + 0, // + } + } + } + + }) + ... + +In the above example the PWM-based LED driver references to the PWM channel 0 +of \_SB.PCI0.PWM device with initial period setting equal to 600 ms (note that +value is given in nanoseconds). + GPIO support ============ -- cgit v1.2.3 From c333b936c1530e76eba4e81091874d1217046131 Mon Sep 17 00:00:00 2001 From: Andy Shevchenko Date: Mon, 7 Jun 2021 15:24:57 +0300 Subject: pwm: core: Remove unused devm_pwm_put() MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit There are no users and seems no will come of the devm_pwm_put(). Remove the function. While at it, slightly update documentation. Signed-off-by: Andy Shevchenko Reviewed-by: Uwe Kleine-König Signed-off-by: Thierry Reding --- Documentation/driver-api/driver-model/devres.rst | 3 ++- Documentation/driver-api/pwm.rst | 3 ++- 2 files changed, 4 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/driver-api/driver-model/devres.rst b/Documentation/driver-api/driver-model/devres.rst index e0814d214048..772216f7c6ff 100644 --- a/Documentation/driver-api/driver-model/devres.rst +++ b/Documentation/driver-api/driver-model/devres.rst @@ -401,7 +401,8 @@ POWER PWM devm_pwm_get() - devm_pwm_put() + devm_of_pwm_get() + devm_fwnode_pwm_get() REGULATOR devm_regulator_bulk_get() diff --git a/Documentation/driver-api/pwm.rst b/Documentation/driver-api/pwm.rst index 750734a7f874..ccb06e485756 100644 --- a/Documentation/driver-api/pwm.rst +++ b/Documentation/driver-api/pwm.rst @@ -40,7 +40,8 @@ after usage with pwm_free(). New users should use the pwm_get() function and pass to it the consumer device or a consumer name. pwm_put() is used to free the PWM device. Managed -variants of these functions, devm_pwm_get() and devm_pwm_put(), also exist. +variants of the getter, devm_pwm_get(), devm_of_pwm_get(), +devm_fwnode_pwm_get(), also exist. After being requested, a PWM has to be configured using:: -- cgit v1.2.3 From b3beca76181681fce9cf72f37d19c3030e3353c0 Mon Sep 17 00:00:00 2001 From: Viresh Kumar Date: Tue, 29 Jun 2021 11:57:08 +0530 Subject: cpufreq: Remove ->resolve_freq() Commit e3c062360870 ("cpufreq: add cpufreq_driver_resolve_freq()") introduced this callback, back in 2016, for drivers that provide the ->target() callback. The kernel hasn't seen a single user of it in the past 5 years and it is not likely to be used any time soon. Remove it for now. Signed-off-by: Viresh Kumar [ rjw: Changelog edits ] Signed-off-by: Rafael J. Wysocki --- Documentation/cpu-freq/cpu-drivers.rst | 3 --- Documentation/translations/zh_CN/cpu-freq/cpu-drivers.rst | 2 -- 2 files changed, 5 deletions(-) (limited to 'Documentation') diff --git a/Documentation/cpu-freq/cpu-drivers.rst b/Documentation/cpu-freq/cpu-drivers.rst index 74fac797c396..d84ededb66f9 100644 --- a/Documentation/cpu-freq/cpu-drivers.rst +++ b/Documentation/cpu-freq/cpu-drivers.rst @@ -58,9 +58,6 @@ And optionally .driver_data - cpufreq driver specific data. - .resolve_freq - Returns the most appropriate frequency for a target - frequency. Doesn't change the frequency though. - .get_intermediate and target_intermediate - Used to switch to stable frequency while changing CPU frequency. diff --git a/Documentation/translations/zh_CN/cpu-freq/cpu-drivers.rst b/Documentation/translations/zh_CN/cpu-freq/cpu-drivers.rst index 9570e9c9e939..5ae9cfa2ec55 100644 --- a/Documentation/translations/zh_CN/cpu-freq/cpu-drivers.rst +++ b/Documentation/translations/zh_CN/cpu-freq/cpu-drivers.rst @@ -64,8 +64,6 @@ CPUfreq核心层注册一个cpufreq_driver结构体。 .driver_data - cpufreq驱动程序的特定数据。 - .resolve_freq - 返回最适合目标频率的频率。不过并不能改变频率。 - .get_intermediate 和 target_intermediate - 用于在改变CPU频率时切换到稳定 的频率。 -- cgit v1.2.3 From ad2fa3717b74994a22519dbe045757135db00dbb Mon Sep 17 00:00:00 2001 From: Muchun Song Date: Wed, 30 Jun 2021 18:47:21 -0700 Subject: mm: hugetlb: alloc the vmemmap pages associated with each HugeTLB page When we free a HugeTLB page to the buddy allocator, we need to allocate the vmemmap pages associated with it. However, we may not be able to allocate the vmemmap pages when the system is under memory pressure. In this case, we just refuse to free the HugeTLB page. This changes behavior in some corner cases as listed below: 1) Failing to free a huge page triggered by the user (decrease nr_pages). User needs to try again later. 2) Failing to free a surplus huge page when freed by the application. Try again later when freeing a huge page next time. 3) Failing to dissolve a free huge page on ZONE_MOVABLE via offline_pages(). This can happen when we have plenty of ZONE_MOVABLE memory, but not enough kernel memory to allocate vmemmmap pages. We may even be able to migrate huge page contents, but will not be able to dissolve the source huge page. This will prevent an offline operation and is unfortunate as memory offlining is expected to succeed on movable zones. Users that depend on memory hotplug to succeed for movable zones should carefully consider whether the memory savings gained from this feature are worth the risk of possibly not being able to offline memory in certain situations. 4) Failing to dissolve a huge page on CMA/ZONE_MOVABLE via alloc_contig_range() - once we have that handling in place. Mainly affects CMA and virtio-mem. Similar to 3). virito-mem will handle migration errors gracefully. CMA might be able to fallback on other free areas within the CMA region. Vmemmap pages are allocated from the page freeing context. In order for those allocations to be not disruptive (e.g. trigger oom killer) __GFP_NORETRY is used. hugetlb_lock is dropped for the allocation because a non sleeping allocation would be too fragile and it could fail too easily under memory pressure. GFP_ATOMIC or other modes to access memory reserves is not used because we want to prevent consuming reserves under heavy hugetlb freeing. [mike.kravetz@oracle.com: fix dissolve_free_huge_page use of tail/head page] Link: https://lkml.kernel.org/r/20210527231225.226987-1-mike.kravetz@oracle.com [willy@infradead.org: fix alloc_vmemmap_page_list documentation warning] Link: https://lkml.kernel.org/r/20210615200242.1716568-6-willy@infradead.org Link: https://lkml.kernel.org/r/20210510030027.56044-7-songmuchun@bytedance.com Signed-off-by: Muchun Song Signed-off-by: Mike Kravetz Signed-off-by: Matthew Wilcox (Oracle) Reviewed-by: Mike Kravetz Reviewed-by: Oscar Salvador Cc: Alexander Viro Cc: Andy Lutomirski Cc: Anshuman Khandual Cc: Balbir Singh Cc: Barry Song Cc: Bodeddula Balasubramaniam Cc: Borislav Petkov Cc: Chen Huang Cc: Dave Hansen Cc: David Hildenbrand Cc: David Rientjes Cc: HORIGUCHI NAOYA Cc: "H. Peter Anvin" Cc: Ingo Molnar Cc: Joao Martins Cc: Joerg Roedel Cc: Jonathan Corbet Cc: Matthew Wilcox Cc: Miaohe Lin Cc: Michal Hocko Cc: Mina Almasry Cc: Oliver Neukum Cc: Paul E. McKenney Cc: Pawan Gupta Cc: Peter Zijlstra Cc: Randy Dunlap Cc: Thomas Gleixner Cc: Xiongchun Duan Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/admin-guide/mm/hugetlbpage.rst | 8 ++++++++ Documentation/admin-guide/mm/memory-hotplug.rst | 13 +++++++++++++ 2 files changed, 21 insertions(+) (limited to 'Documentation') diff --git a/Documentation/admin-guide/mm/hugetlbpage.rst b/Documentation/admin-guide/mm/hugetlbpage.rst index f7b1c7462991..6988895d09a8 100644 --- a/Documentation/admin-guide/mm/hugetlbpage.rst +++ b/Documentation/admin-guide/mm/hugetlbpage.rst @@ -60,6 +60,10 @@ HugePages_Surp the pool above the value in ``/proc/sys/vm/nr_hugepages``. The maximum number of surplus huge pages is controlled by ``/proc/sys/vm/nr_overcommit_hugepages``. + Note: When the feature of freeing unused vmemmap pages associated + with each hugetlb page is enabled, the number of surplus huge pages + may be temporarily larger than the maximum number of surplus huge + pages when the system is under memory pressure. Hugepagesize is the default hugepage size (in Kb). Hugetlb @@ -80,6 +84,10 @@ returned to the huge page pool when freed by a task. A user with root privileges can dynamically allocate more or free some persistent huge pages by increasing or decreasing the value of ``nr_hugepages``. +Note: When the feature of freeing unused vmemmap pages associated with each +hugetlb page is enabled, we can fail to free the huge pages triggered by +the user when ths system is under memory pressure. Please try again later. + Pages that are used as huge pages are reserved inside the kernel and cannot be used for other purposes. Huge pages cannot be swapped out under memory pressure. diff --git a/Documentation/admin-guide/mm/memory-hotplug.rst b/Documentation/admin-guide/mm/memory-hotplug.rst index 05d51d2d8beb..c6bae2d77160 100644 --- a/Documentation/admin-guide/mm/memory-hotplug.rst +++ b/Documentation/admin-guide/mm/memory-hotplug.rst @@ -357,6 +357,19 @@ creates ZONE_MOVABLE as following. Unfortunately, there is no information to show which memory block belongs to ZONE_MOVABLE. This is TBD. + Memory offlining can fail when dissolving a free huge page on ZONE_MOVABLE + and the feature of freeing unused vmemmap pages associated with each hugetlb + page is enabled. + + This can happen when we have plenty of ZONE_MOVABLE memory, but not enough + kernel memory to allocate vmemmmap pages. We may even be able to migrate + huge page contents, but will not be able to dissolve the source huge page. + This will prevent an offline operation and is unfortunate as memory offlining + is expected to succeed on movable zones. Users that depend on memory hotplug + to succeed for movable zones should carefully consider whether the memory + savings gained from this feature are worth the risk of possibly not being + able to offline memory in certain situations. + .. note:: Techniques that rely on long-term pinnings of memory (especially, RDMA and vfio) are fundamentally problematic with ZONE_MOVABLE and, therefore, memory -- cgit v1.2.3 From e9fdff87e893ec5b7c32836675db80cf691b2a8b Mon Sep 17 00:00:00 2001 From: Muchun Song Date: Wed, 30 Jun 2021 18:47:25 -0700 Subject: mm: hugetlb: add a kernel parameter hugetlb_free_vmemmap Add a kernel parameter hugetlb_free_vmemmap to enable the feature of freeing unused vmemmap pages associated with each hugetlb page on boot. We disable PMD mapping of vmemmap pages for x86-64 arch when this feature is enabled. Because vmemmap_remap_free() depends on vmemmap being base page mapped. Link: https://lkml.kernel.org/r/20210510030027.56044-8-songmuchun@bytedance.com Signed-off-by: Muchun Song Reviewed-by: Oscar Salvador Reviewed-by: Barry Song Reviewed-by: Miaohe Lin Tested-by: Chen Huang Tested-by: Bodeddula Balasubramaniam Reviewed-by: Mike Kravetz Cc: Alexander Viro Cc: Andy Lutomirski Cc: Anshuman Khandual Cc: Balbir Singh Cc: Borislav Petkov Cc: Dave Hansen Cc: David Hildenbrand Cc: David Rientjes Cc: HORIGUCHI NAOYA Cc: "H. Peter Anvin" Cc: Ingo Molnar Cc: Joao Martins Cc: Joerg Roedel Cc: Jonathan Corbet Cc: Matthew Wilcox Cc: Michal Hocko Cc: Mina Almasry Cc: Oliver Neukum Cc: Paul E. McKenney Cc: Pawan Gupta Cc: Peter Zijlstra Cc: Randy Dunlap Cc: Thomas Gleixner Cc: Xiongchun Duan Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/admin-guide/kernel-parameters.txt | 17 +++++++++++++++++ Documentation/admin-guide/mm/hugetlbpage.rst | 3 +++ 2 files changed, 20 insertions(+) (limited to 'Documentation') diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index 566c4b9af3cd..b787a9953f2e 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -1567,6 +1567,23 @@ Documentation/admin-guide/mm/hugetlbpage.rst. Format: size[KMG] + hugetlb_free_vmemmap= + [KNL] Reguires CONFIG_HUGETLB_PAGE_FREE_VMEMMAP + enabled. + Allows heavy hugetlb users to free up some more + memory (6 * PAGE_SIZE for each 2MB hugetlb page). + This feauture is not free though. Large page + tables are not used to back vmemmap pages which + can lead to a performance degradation for some + workloads. Also there will be memory allocation + required when hugetlb pages are freed from the + pool which can lead to corner cases under heavy + memory pressure. + Format: { on | off (default) } + + on: enable the feature + off: disable the feature + hung_task_panic= [KNL] Should the hung task detector generate panics. Format: 0 | 1 diff --git a/Documentation/admin-guide/mm/hugetlbpage.rst b/Documentation/admin-guide/mm/hugetlbpage.rst index 6988895d09a8..8abaeb144e44 100644 --- a/Documentation/admin-guide/mm/hugetlbpage.rst +++ b/Documentation/admin-guide/mm/hugetlbpage.rst @@ -153,6 +153,9 @@ default_hugepagesz will all result in 256 2M huge pages being allocated. Valid default huge page size is architecture dependent. +hugetlb_free_vmemmap + When CONFIG_HUGETLB_PAGE_FREE_VMEMMAP is set, this enables freeing + unused vmemmap pages associated with each HugeTLB page. When multiple huge page sizes are supported, ``/proc/sys/vm/nr_hugepages`` indicates the current number of pre-allocated huge pages of the default size. -- cgit v1.2.3 From 4bab4964a59f277915285787c828b810151de7a1 Mon Sep 17 00:00:00 2001 From: Muchun Song Date: Wed, 30 Jun 2021 18:47:29 -0700 Subject: mm: memory_hotplug: disable memmap_on_memory when hugetlb_free_vmemmap enabled The parameter of memory_hotplug.memmap_on_memory is not compatible with hugetlb_free_vmemmap. So disable it when hugetlb_free_vmemmap is enabled. [akpm@linux-foundation.org: remove unneeded include, per Oscar] Link: https://lkml.kernel.org/r/20210510030027.56044-9-songmuchun@bytedance.com Signed-off-by: Muchun Song Acked-by: Mike Kravetz Cc: Alexander Viro Cc: Andy Lutomirski Cc: Anshuman Khandual Cc: Balbir Singh Cc: Barry Song Cc: Bodeddula Balasubramaniam Cc: Borislav Petkov Cc: Chen Huang Cc: Dave Hansen Cc: David Hildenbrand Cc: David Rientjes Cc: HORIGUCHI NAOYA Cc: "H. Peter Anvin" Cc: Ingo Molnar Cc: Joao Martins Cc: Joerg Roedel Cc: Jonathan Corbet Cc: Matthew Wilcox Cc: Miaohe Lin Cc: Michal Hocko Cc: Mina Almasry Cc: Oliver Neukum Cc: Oscar Salvador Cc: Paul E. McKenney Cc: Pawan Gupta Cc: Peter Zijlstra Cc: Randy Dunlap Cc: Thomas Gleixner Cc: Xiongchun Duan Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/admin-guide/kernel-parameters.txt | 8 ++++++++ 1 file changed, 8 insertions(+) (limited to 'Documentation') diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index b787a9953f2e..597572ceb8ba 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -1584,6 +1584,10 @@ on: enable the feature off: disable the feature + This is not compatible with memory_hotplug.memmap_on_memory. + If both parameters are enabled, hugetlb_free_vmemmap takes + precedence over memory_hotplug.memmap_on_memory. + hung_task_panic= [KNL] Should the hung task detector generate panics. Format: 0 | 1 @@ -2850,6 +2854,10 @@ Note that even when enabled, there are a few cases where the feature is not effective. + This is not compatible with hugetlb_free_vmemmap. If + both parameters are enabled, hugetlb_free_vmemmap takes + precedence over memory_hotplug.memmap_on_memory. + memtest= [KNL,X86,ARM,PPC,RISCV] Enable memtest Format: default : 0 -- cgit v1.2.3 From 2d7a21715f25122779e2bed17db8c57aa01e922f Mon Sep 17 00:00:00 2001 From: Muchun Song Date: Wed, 30 Jun 2021 18:48:25 -0700 Subject: mm: sparsemem: use huge PMD mapping for vmemmap pages The preparation of splitting huge PMD mapping of vmemmap pages is ready, so switch the mapping from PTE to PMD. Link: https://lkml.kernel.org/r/20210616094915.34432-3-songmuchun@bytedance.com Signed-off-by: Muchun Song Reviewed-by: Mike Kravetz Cc: Chen Huang Cc: David Hildenbrand Cc: Jonathan Corbet Cc: Michal Hocko Cc: Oscar Salvador Cc: Xiongchun Duan Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/admin-guide/kernel-parameters.txt | 7 ------- 1 file changed, 7 deletions(-) (limited to 'Documentation') diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index 597572ceb8ba..7a7da02b3bc6 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -1572,13 +1572,6 @@ enabled. Allows heavy hugetlb users to free up some more memory (6 * PAGE_SIZE for each 2MB hugetlb page). - This feauture is not free though. Large page - tables are not used to back vmemmap pages which - can lead to a performance degradation for some - workloads. Also there will be memory allocation - required when hugetlb pages are freed from the - pool which can lead to corner cases under heavy - memory pressure. Format: { on | off (default) } on: enable the feature -- cgit v1.2.3 From e6d41f12df0efcaa6e30b575d40f2529024cfce9 Mon Sep 17 00:00:00 2001 From: Muchun Song Date: Wed, 30 Jun 2021 18:48:28 -0700 Subject: mm: hugetlb: introduce CONFIG_HUGETLB_PAGE_FREE_VMEMMAP_DEFAULT_ON When using HUGETLB_PAGE_FREE_VMEMMAP, the freeing unused vmemmap pages associated with each HugeTLB page is default off. Now the vmemmap is PMD mapped. So there is no side effect when this feature is enabled with no HugeTLB pages in the system. Someone may want to enable this feature in the compiler time instead of using boot command line. So add a config to make it default on when someone do not want to enable it via command line. Link: https://lkml.kernel.org/r/20210616094915.34432-4-songmuchun@bytedance.com Signed-off-by: Muchun Song Cc: Chen Huang Cc: David Hildenbrand Cc: Jonathan Corbet Cc: Michal Hocko Cc: Mike Kravetz Cc: Oscar Salvador Cc: Xiongchun Duan Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- 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 7a7da02b3bc6..c4e34420a485 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -1577,6 +1577,9 @@ on: enable the feature off: disable the feature + Built with CONFIG_HUGETLB_PAGE_FREE_VMEMMAP_DEFAULT_ON=y, + the default is on. + This is not compatible with memory_hotplug.memmap_on_memory. If both parameters are enabled, hugetlb_free_vmemmap takes precedence over memory_hotplug.memmap_on_memory. -- cgit v1.2.3 From fb8e37f35a2fe1f983ac21850e856e2c7498d469 Mon Sep 17 00:00:00 2001 From: Peter Xu Date: Wed, 30 Jun 2021 18:49:09 -0700 Subject: mm/pagemap: export uffd-wp protection information Export the PTE/PMD status of uffd-wp to pagemap too. Link: https://lkml.kernel.org/r/20210428225030.9708-6-peterx@redhat.com Signed-off-by: Peter Xu Cc: Alexander Viro Cc: Andrea Arcangeli Cc: Axel Rasmussen Cc: Brian Geffon Cc: "Dr . David Alan Gilbert" Cc: Hugh Dickins Cc: Jerome Glisse Cc: Joe Perches Cc: Kirill A. Shutemov Cc: Lokesh Gidra Cc: Mike Kravetz Cc: Mike Rapoport Cc: Mina Almasry Cc: Oliver Upton Cc: Shaohua Li Cc: Shuah Khan Cc: Stephen Rothwell Cc: Wang Qing Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/admin-guide/mm/pagemap.rst | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/admin-guide/mm/pagemap.rst b/Documentation/admin-guide/mm/pagemap.rst index 340a5aee9b80..fb578fbbb76c 100644 --- a/Documentation/admin-guide/mm/pagemap.rst +++ b/Documentation/admin-guide/mm/pagemap.rst @@ -21,6 +21,8 @@ There are four components to pagemap: * Bit 55 pte is soft-dirty (see :ref:`Documentation/admin-guide/mm/soft-dirty.rst `) * Bit 56 page exclusively mapped (since 4.2) + * Bit 57 pte is uffd-wp write-protected (since 5.13) (see + :ref:`Documentation/admin-guide/mm/userfaultfd.rst `) * Bits 57-60 zero * Bit 61 page is file-page or shared-anon (since 3.5) * Bit 62 page swapped -- cgit v1.2.3 From 964ab0040ff9598783bf37776b5e31b27b50e293 Mon Sep 17 00:00:00 2001 From: Axel Rasmussen Date: Wed, 30 Jun 2021 18:49:27 -0700 Subject: userfaultfd/shmem: advertise shmem minor fault support Now that the feature is fully implemented (the faulting path hooks exist so userspace is notified, and the ioctl to resolve such faults is available), advertise this as a supported feature. Link: https://lkml.kernel.org/r/20210503180737.2487560-6-axelrasmussen@google.com Signed-off-by: Axel Rasmussen Acked-by: Hugh Dickins Acked-by: Peter Xu Cc: Alexander Viro Cc: Andrea Arcangeli Cc: Brian Geffon Cc: "Dr . David Alan Gilbert" Cc: Jerome Glisse Cc: Joe Perches Cc: Kirill A. Shutemov Cc: Lokesh Gidra Cc: Mike Kravetz Cc: Mike Rapoport Cc: Mina Almasry Cc: Oliver Upton Cc: Shaohua Li Cc: Shuah Khan Cc: Stephen Rothwell Cc: Wang Qing Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/admin-guide/mm/userfaultfd.rst | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/admin-guide/mm/userfaultfd.rst b/Documentation/admin-guide/mm/userfaultfd.rst index 3aa38e8b8361..6528036093e1 100644 --- a/Documentation/admin-guide/mm/userfaultfd.rst +++ b/Documentation/admin-guide/mm/userfaultfd.rst @@ -77,7 +77,8 @@ events, except page fault notifications, may be generated: - ``UFFD_FEATURE_MINOR_HUGETLBFS`` indicates that the kernel supports ``UFFDIO_REGISTER_MODE_MINOR`` registration for hugetlbfs virtual memory - areas. + areas. ``UFFD_FEATURE_MINOR_SHMEM`` is the analogous feature indicating + support for shmem virtual memory areas. The userland application should set the feature flags it intends to use when invoking the ``UFFDIO_API`` ioctl, to request that those features be -- cgit v1.2.3 From 8d719afcb34434ebfa7911338d8c777eca8452b0 Mon Sep 17 00:00:00 2001 From: Mike Rapoport Date: Wed, 30 Jun 2021 18:50:00 -0700 Subject: docs: proc.rst: meminfo: briefly describe gaps in memory accounting Add a paragraph that explains that it may happen that the counters in /proc/meminfo do not add up to the overall memory usage. Link: https://lkml.kernel.org/r/20210421061127.1182723-1-rppt@kernel.org Signed-off-by: Mike Rapoport Acked-by: Michal Hocko Reviewed-by: Matthew Wilcox (Oracle) Acked-by: Vlastimil Babka Cc: Jonathan Corbet Cc: Alexey Dobriyan Cc: Eric Dumazet Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/filesystems/proc.rst | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/filesystems/proc.rst b/Documentation/filesystems/proc.rst index 81bfe3c800cc..dd4e3e18c22b 100644 --- a/Documentation/filesystems/proc.rst +++ b/Documentation/filesystems/proc.rst @@ -933,8 +933,15 @@ meminfo ~~~~~~~ Provides information about distribution and utilization of memory. This -varies by architecture and compile options. The following is from a -16GB PIII, which has highmem enabled. You may not have all of these fields. +varies by architecture and compile options. Some of the counters reported +here overlap. The memory reported by the non overlapping counters may not +add up to the overall memory usage and the difference for some workloads +can be substantial. In many cases there are other means to find out +additional memory using subsystem specific interfaces, for instance +/proc/net/sockstat for TCP memory allocations. + +The following is from a 16GB PIII, which has highmem enabled. +You may not have all of these fields. :: -- cgit v1.2.3 From 0118915b447d370fde51ae5418bcaf108600b6b8 Mon Sep 17 00:00:00 2001 From: Rob Herring Date: Wed, 23 Jun 2021 10:42:56 -0600 Subject: dt-bindings: media: adv7180: Add missing video-interfaces.yaml reference The adv7180 binding is using 'bus-width' property, but doesn't document it. Add a reference to the video-interfaces.yaml schema to properly document it. Fixes: 066a94e28a23 ("media: dt-bindings: media: Use graph and video-interfaces schemas") Cc: Lars-Peter Clausen Cc: Mauro Carvalho Chehab Cc: linux-media@vger.kernel.org Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20210623164256.2569839-1-robh@kernel.org --- Documentation/devicetree/bindings/media/i2c/adv7180.yaml | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/media/i2c/adv7180.yaml b/Documentation/devicetree/bindings/media/i2c/adv7180.yaml index bcfd93739b4f..3ce4af143a3a 100644 --- a/Documentation/devicetree/bindings/media/i2c/adv7180.yaml +++ b/Documentation/devicetree/bindings/media/i2c/adv7180.yaml @@ -36,7 +36,13 @@ properties: maxItems: 1 port: - $ref: /schemas/graph.yaml#/properties/port + $ref: /schemas/graph.yaml#/$defs/port-base + unevaluatedProperties: false + + properties: + endpoint: + $ref: /schemas/media/video-interfaces.yaml# + unevaluatedProperties: false ports: true -- cgit v1.2.3 From bae4cbe1922bc71c73b86f8ebe3d2d53c7e38d3d Mon Sep 17 00:00:00 2001 From: Rob Herring Date: Wed, 23 Jun 2021 10:43:08 -0600 Subject: dt-bindings: display: renesas,du: Fix 'ports' reference Fix the renesas,du binding 'ports' schema which is referencing the 'port' schema instead of the 'ports' schema. Fixes: 99d66127fad2 ("dt-bindings: display: renesas,du: Convert binding to YAML") Cc: Laurent Pinchart Cc: Kieran Bingham Cc: dri-devel@lists.freedesktop.org Cc: linux-renesas-soc@vger.kernel.org Signed-off-by: Rob Herring Reviewed-by: Laurent Pinchart Reviewed-by: Kieran Bingham Link: https://lore.kernel.org/r/20210623164308.2570164-1-robh@kernel.org --- Documentation/devicetree/bindings/display/renesas,du.yaml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/renesas,du.yaml b/Documentation/devicetree/bindings/display/renesas,du.yaml index 121596f106da..5f4345d43020 100644 --- a/Documentation/devicetree/bindings/display/renesas,du.yaml +++ b/Documentation/devicetree/bindings/display/renesas,du.yaml @@ -55,7 +55,7 @@ properties: maxItems: 1 ports: - $ref: /schemas/graph.yaml#/properties/port + $ref: /schemas/graph.yaml#/properties/ports description: | The connections to the DU output video ports are modeled using the OF graph bindings specified in Documentation/devicetree/bindings/graph.txt. -- cgit v1.2.3 From 6a9a930dc4415b2e8c0bf2085b2b0b2b291053d5 Mon Sep 17 00:00:00 2001 From: Rob Herring Date: Wed, 23 Jun 2021 10:43:44 -0600 Subject: dt-bindings: Fix 'unevaluatedProperties' errors in DT graph users MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit In testing out under development json-schema 2020-12 support, there's a few issues with 'unevaluatedProperties' and the graph schema. If 'graph.yaml#/properties/port' is used, then neither the port nor the endpoint(s) can have additional properties. 'graph.yaml#/$defs/port-base' needs to be used instead. Cc: Sakari Ailus Cc: Mauro Carvalho Chehab Cc: "Paul J. Murphy" Cc: Daniele Alessandrelli Cc: "Niklas Söderlund" Cc: Krzysztof Kozlowski Cc: Paul Kocialkowski Cc: dri-devel@lists.freedesktop.org Cc: linux-media@vger.kernel.org Cc: linux-renesas-soc@vger.kernel.org Signed-off-by: Rob Herring Reviewed-by: Niklas Söderlund Acked-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20210623164344.2571043-1-robh@kernel.org --- Documentation/devicetree/bindings/display/bridge/lontium,lt8912b.yaml | 3 ++- Documentation/devicetree/bindings/media/i2c/imx258.yaml | 2 +- Documentation/devicetree/bindings/media/i2c/ovti,ov5648.yaml | 2 +- Documentation/devicetree/bindings/media/i2c/ovti,ov8865.yaml | 2 +- Documentation/devicetree/bindings/media/i2c/sony,imx334.yaml | 2 +- Documentation/devicetree/bindings/media/renesas,vin.yaml | 3 ++- 6 files changed, 8 insertions(+), 6 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/bridge/lontium,lt8912b.yaml b/Documentation/devicetree/bindings/display/bridge/lontium,lt8912b.yaml index 735d0233a7d6..674891ee2f8e 100644 --- a/Documentation/devicetree/bindings/display/bridge/lontium,lt8912b.yaml +++ b/Documentation/devicetree/bindings/display/bridge/lontium,lt8912b.yaml @@ -29,7 +29,8 @@ properties: properties: port@0: - $ref: /schemas/graph.yaml#/properties/port + $ref: /schemas/graph.yaml#/$defs/port-base + unevaluatedProperties: false description: Primary MIPI port for MIPI input diff --git a/Documentation/devicetree/bindings/media/i2c/imx258.yaml b/Documentation/devicetree/bindings/media/i2c/imx258.yaml index 515317eff41a..cde0f7383b2a 100644 --- a/Documentation/devicetree/bindings/media/i2c/imx258.yaml +++ b/Documentation/devicetree/bindings/media/i2c/imx258.yaml @@ -49,7 +49,7 @@ properties: # See ../video-interfaces.txt for more details port: - $ref: /schemas/graph.yaml#/properties/port + $ref: /schemas/graph.yaml#/$defs/port-base additionalProperties: false properties: diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov5648.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov5648.yaml index 9149f5685688..246dc5fec716 100644 --- a/Documentation/devicetree/bindings/media/i2c/ovti,ov5648.yaml +++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov5648.yaml @@ -45,7 +45,7 @@ properties: port: description: MIPI CSI-2 transmitter port - $ref: /schemas/graph.yaml#/properties/port + $ref: /schemas/graph.yaml#/$defs/port-base additionalProperties: false properties: diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov8865.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov8865.yaml index 0699c7e4fdeb..b962863e4f65 100644 --- a/Documentation/devicetree/bindings/media/i2c/ovti,ov8865.yaml +++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov8865.yaml @@ -45,7 +45,7 @@ properties: port: description: MIPI CSI-2 transmitter port - $ref: /schemas/graph.yaml#/properties/port + $ref: /schemas/graph.yaml#/$defs/port-base additionalProperties: false properties: diff --git a/Documentation/devicetree/bindings/media/i2c/sony,imx334.yaml b/Documentation/devicetree/bindings/media/i2c/sony,imx334.yaml index 27cc5b7ff613..f5055b9db693 100644 --- a/Documentation/devicetree/bindings/media/i2c/sony,imx334.yaml +++ b/Documentation/devicetree/bindings/media/i2c/sony,imx334.yaml @@ -37,7 +37,7 @@ properties: port: additionalProperties: false - $ref: /schemas/graph.yaml#/properties/port + $ref: /schemas/graph.yaml#/$defs/port-base properties: endpoint: diff --git a/Documentation/devicetree/bindings/media/renesas,vin.yaml b/Documentation/devicetree/bindings/media/renesas,vin.yaml index dd1a5ce5896c..4945a2f0eca6 100644 --- a/Documentation/devicetree/bindings/media/renesas,vin.yaml +++ b/Documentation/devicetree/bindings/media/renesas,vin.yaml @@ -118,7 +118,8 @@ properties: properties: port@0: - $ref: /schemas/graph.yaml#/properties/port + $ref: /schemas/graph.yaml#/$defs/port-base + unevaluatedProperties: false description: Input port node, single endpoint describing a parallel input source. -- cgit v1.2.3 From cd62734ca60dbb2ab5bb19c8d837dd9990955310 Mon Sep 17 00:00:00 2001 From: Alistair Popple Date: Wed, 30 Jun 2021 18:54:12 -0700 Subject: mm/rmap: split try_to_munlock from try_to_unmap The behaviour of try_to_unmap_one() is difficult to follow because it performs different operations based on a fairly large set of flags used in different combinations. TTU_MUNLOCK is one such flag. However it is exclusively used by try_to_munlock() which specifies no other flags. Therefore rather than overload try_to_unmap_one() with unrelated behaviour split this out into it's own function and remove the flag. Link: https://lkml.kernel.org/r/20210616105937.23201-4-apopple@nvidia.com Signed-off-by: Alistair Popple Reviewed-by: Ralph Campbell Reviewed-by: Christoph Hellwig Cc: Ben Skeggs Cc: Hugh Dickins Cc: Jason Gunthorpe Cc: John Hubbard Cc: "Matthew Wilcox (Oracle)" Cc: Peter Xu Cc: Shakeel Butt Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/vm/unevictable-lru.rst | 33 +++++++++++++-------------------- 1 file changed, 13 insertions(+), 20 deletions(-) (limited to 'Documentation') diff --git a/Documentation/vm/unevictable-lru.rst b/Documentation/vm/unevictable-lru.rst index 0e1490524f53..eae3af17f2d9 100644 --- a/Documentation/vm/unevictable-lru.rst +++ b/Documentation/vm/unevictable-lru.rst @@ -389,14 +389,14 @@ mlocked, munlock_vma_page() updates that zone statistics for the number of mlocked pages. Note, however, that at this point we haven't checked whether the page is mapped by other VM_LOCKED VMAs. -We can't call try_to_munlock(), the function that walks the reverse map to +We can't call page_mlock(), the function that walks the reverse map to check for other VM_LOCKED VMAs, without first isolating the page from the LRU. -try_to_munlock() is a variant of try_to_unmap() and thus requires that the page +page_mlock() is a variant of try_to_unmap() and thus requires that the page not be on an LRU list [more on these below]. However, the call to -isolate_lru_page() could fail, in which case we couldn't try_to_munlock(). So, +isolate_lru_page() could fail, in which case we can't call page_mlock(). So, we go ahead and clear PG_mlocked up front, as this might be the only chance we -have. If we can successfully isolate the page, we go ahead and -try_to_munlock(), which will restore the PG_mlocked flag and update the zone +have. If we can successfully isolate the page, we go ahead and call +page_mlock(), which will restore the PG_mlocked flag and update the zone page statistics if it finds another VMA holding the page mlocked. If we fail to isolate the page, we'll have left a potentially mlocked page on the LRU. This is fine, because we'll catch it later if and if vmscan tries to reclaim @@ -545,31 +545,24 @@ munlock or munmap system calls, mm teardown (munlock_vma_pages_all), reclaim, holepunching, and truncation of file pages and their anonymous COWed pages. -try_to_munlock() Reverse Map Scan +page_mlock() Reverse Map Scan --------------------------------- -.. warning:: - [!] TODO/FIXME: a better name might be page_mlocked() - analogous to the - page_referenced() reverse map walker. - When munlock_vma_page() [see section :ref:`munlock()/munlockall() System Call Handling ` above] tries to munlock a page, it needs to determine whether or not the page is mapped by any VM_LOCKED VMA without actually attempting to unmap all PTEs from the page. For this purpose, the unevictable/mlock infrastructure -introduced a variant of try_to_unmap() called try_to_munlock(). +introduced a variant of try_to_unmap() called page_mlock(). -try_to_munlock() calls the same functions as try_to_unmap() for anonymous and -mapped file and KSM pages with a flag argument specifying unlock versus unmap -processing. Again, these functions walk the respective reverse maps looking -for VM_LOCKED VMAs. When such a VMA is found, as in the try_to_unmap() case, -the functions mlock the page via mlock_vma_page() and return SWAP_MLOCK. This -undoes the pre-clearing of the page's PG_mlocked done by munlock_vma_page. +page_mlock() walks the respective reverse maps looking for VM_LOCKED VMAs. When +such a VMA is found the page is mlocked via mlock_vma_page(). This undoes the +pre-clearing of the page's PG_mlocked done by munlock_vma_page. -Note that try_to_munlock()'s reverse map walk must visit every VMA in a page's +Note that page_mlock()'s reverse map walk must visit every VMA in a page's reverse map to determine that a page is NOT mapped into any VM_LOCKED VMA. However, the scan can terminate when it encounters a VM_LOCKED VMA. -Although try_to_munlock() might be called a great many times when munlocking a +Although page_mlock() might be called a great many times when munlocking a large region or tearing down a large address space that has been mlocked via mlockall(), overall this is a fairly rare event. @@ -602,7 +595,7 @@ inactive lists to the appropriate node's unevictable list. shrink_inactive_list() should only see SHM_LOCK'd pages that became SHM_LOCK'd after shrink_active_list() had moved them to the inactive list, or pages mapped into VM_LOCKED VMAs that munlock_vma_page() couldn't isolate from the LRU to -recheck via try_to_munlock(). shrink_inactive_list() won't notice the latter, +recheck via page_mlock(). shrink_inactive_list() won't notice the latter, but will pass on to shrink_page_list(). shrink_page_list() again culls obviously unevictable pages that it could -- cgit v1.2.3 From 6b49bf6ddbb0d7992c816846acfa5fd1cf751c36 Mon Sep 17 00:00:00 2001 From: Alistair Popple Date: Wed, 30 Jun 2021 18:54:19 -0700 Subject: mm: rename migrate_pgmap_owner MMU notifier ranges have a migrate_pgmap_owner field which is used by drivers to store a pointer. This is subsequently used by the driver callback to filter MMU_NOTIFY_MIGRATE events. Other notifier event types can also benefit from this filtering, so rename the 'migrate_pgmap_owner' field to 'owner' and create a new notifier initialisation function to initialise this field. Link: https://lkml.kernel.org/r/20210616105937.23201-6-apopple@nvidia.com Signed-off-by: Alistair Popple Suggested-by: Peter Xu Reviewed-by: Peter Xu Cc: Ben Skeggs Cc: Christoph Hellwig Cc: Hugh Dickins Cc: Jason Gunthorpe Cc: John Hubbard Cc: "Matthew Wilcox (Oracle)" Cc: Ralph Campbell Cc: Shakeel Butt Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/vm/hmm.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/vm/hmm.rst b/Documentation/vm/hmm.rst index 09e28507f5b2..3df79307a797 100644 --- a/Documentation/vm/hmm.rst +++ b/Documentation/vm/hmm.rst @@ -332,7 +332,7 @@ between device driver specific code and shared common code: walks to fill in the ``args->src`` array with PFNs to be migrated. The ``invalidate_range_start()`` callback is passed a ``struct mmu_notifier_range`` with the ``event`` field set to - ``MMU_NOTIFY_MIGRATE`` and the ``migrate_pgmap_owner`` field set to + ``MMU_NOTIFY_MIGRATE`` and the ``owner`` field set to the ``args->pgmap_owner`` field passed to migrate_vma_setup(). This is allows the device driver to skip the invalidation callback and only invalidate device private MMU mappings that are actually migrating. -- cgit v1.2.3 From b756a3b5e7ead8f6f4b03cea8ac22478ce04c8a8 Mon Sep 17 00:00:00 2001 From: Alistair Popple Date: Wed, 30 Jun 2021 18:54:25 -0700 Subject: mm: device exclusive memory access Some devices require exclusive write access to shared virtual memory (SVM) ranges to perform atomic operations on that memory. This requires CPU page tables to be updated to deny access whilst atomic operations are occurring. In order to do this introduce a new swap entry type (SWP_DEVICE_EXCLUSIVE). When a SVM range needs to be marked for exclusive access by a device all page table mappings for the particular range are replaced with device exclusive swap entries. This causes any CPU access to the page to result in a fault. Faults are resovled by replacing the faulting entry with the original mapping. This results in MMU notifiers being called which a driver uses to update access permissions such as revoking atomic access. After notifiers have been called the device will no longer have exclusive access to the region. Walking of the page tables to find the target pages is handled by get_user_pages() rather than a direct page table walk. A direct page table walk similar to what migrate_vma_collect()/unmap() does could also have been utilised. However this resulted in more code similar in functionality to what get_user_pages() provides as page faulting is required to make the PTEs present and to break COW. [dan.carpenter@oracle.com: fix signedness bug in make_device_exclusive_range()] Link: https://lkml.kernel.org/r/YNIz5NVnZ5GiZ3u1@mwanda Link: https://lkml.kernel.org/r/20210616105937.23201-8-apopple@nvidia.com Signed-off-by: Alistair Popple Signed-off-by: Dan Carpenter Reviewed-by: Christoph Hellwig Cc: Ben Skeggs Cc: Hugh Dickins Cc: Jason Gunthorpe Cc: John Hubbard Cc: "Matthew Wilcox (Oracle)" Cc: Peter Xu Cc: Ralph Campbell Cc: Shakeel Butt Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/vm/hmm.rst | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) (limited to 'Documentation') diff --git a/Documentation/vm/hmm.rst b/Documentation/vm/hmm.rst index 3df79307a797..a14c2938e7af 100644 --- a/Documentation/vm/hmm.rst +++ b/Documentation/vm/hmm.rst @@ -405,6 +405,23 @@ between device driver specific code and shared common code: The lock can now be released. +Exclusive access memory +======================= + +Some devices have features such as atomic PTE bits that can be used to implement +atomic access to system memory. To support atomic operations to a shared virtual +memory page such a device needs access to that page which is exclusive of any +userspace access from the CPU. The ``make_device_exclusive_range()`` function +can be used to make a memory range inaccessible from userspace. + +This replaces all mappings for pages in the given range with special swap +entries. Any attempt to access the swap entry results in a fault which is +resovled by replacing the entry with the original mapping. A driver gets +notified that the mapping has been changed by MMU notifiers, after which point +it will no longer have exclusive access to the page. Exclusive access is +guranteed to last until the driver drops the page lock and page reference, at +which point any CPU faults on the page may proceed as described. + Memory cgroup (memcg) and rss accounting ======================================== -- cgit v1.2.3 From 3845f256a8b527127bfbd4ced21e93d9e89aa6d7 Mon Sep 17 00:00:00 2001 From: Kalesh Singh Date: Wed, 30 Jun 2021 18:54:49 -0700 Subject: procfs/dmabuf: add inode number to /proc/*/fdinfo MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit And 'ino' field to /proc//fdinfo/ and /proc//task//fdinfo/. The inode numbers can be used to uniquely identify DMA buffers in user space and avoids a dependency on /proc//fd/* when accounting per-process DMA buffer sizes. Link: https://lkml.kernel.org/r/20210308170651.919148-2-kaleshsingh@google.com Signed-off-by: Kalesh Singh Acked-by: Randy Dunlap Acked-by: Christian König Cc: Jann Horn Cc: Jeff Vander Stoep Cc: Kees Cook Cc: Suren Baghdasaryan Cc: Minchan Kim Cc: Hridya Valsaraju Cc: Matthew Wilcox Cc: Alexander Viro Cc: Kalesh Singh Cc: Alexey Dobriyan Cc: Jonathan Corbet Cc: Mauro Carvalho Chehab Cc: Michal Hocko Cc: Alexey Gladkov Cc: Szabolcs Nagy Cc: Eric W. Biederman Cc: Christian Brauner Cc: Michel Lespinasse Cc: Bernd Edlinger Cc: Andrei Vagin Cc: Helge Deller Cc: James Morris Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/filesystems/proc.rst | 37 +++++++++++++++++++++++++++++++------ 1 file changed, 31 insertions(+), 6 deletions(-) (limited to 'Documentation') diff --git a/Documentation/filesystems/proc.rst b/Documentation/filesystems/proc.rst index dd4e3e18c22b..042c418f4090 100644 --- a/Documentation/filesystems/proc.rst +++ b/Documentation/filesystems/proc.rst @@ -1920,18 +1920,20 @@ if precise results are needed. 3.8 /proc//fdinfo/ - Information about opened file --------------------------------------------------------------- This file provides information associated with an opened file. The regular -files have at least three fields -- 'pos', 'flags' and 'mnt_id'. The 'pos' -represents the current offset of the opened file in decimal form [see lseek(2) -for details], 'flags' denotes the octal O_xxx mask the file has been -created with [see open(2) for details] and 'mnt_id' represents mount ID of -the file system containing the opened file [see 3.5 /proc//mountinfo -for details]. +files have at least four fields -- 'pos', 'flags', 'mnt_id' and 'ino'. +The 'pos' represents the current offset of the opened file in decimal +form [see lseek(2) for details], 'flags' denotes the octal O_xxx mask the +file has been created with [see open(2) for details] and 'mnt_id' represents +mount ID of the file system containing the opened file [see 3.5 +/proc//mountinfo for details]. 'ino' represents the inode number of +the file. A typical output is:: pos: 0 flags: 0100002 mnt_id: 19 + ino: 63107 All locks associated with a file descriptor are shown in its fdinfo too:: @@ -1948,6 +1950,7 @@ Eventfd files pos: 0 flags: 04002 mnt_id: 9 + ino: 63107 eventfd-count: 5a where 'eventfd-count' is hex value of a counter. @@ -1960,6 +1963,7 @@ Signalfd files pos: 0 flags: 04002 mnt_id: 9 + ino: 63107 sigmask: 0000000000000200 where 'sigmask' is hex value of the signal mask associated @@ -1973,6 +1977,7 @@ Epoll files pos: 0 flags: 02 mnt_id: 9 + ino: 63107 tfd: 5 events: 1d data: ffffffffffffffff pos:0 ino:61af sdev:7 where 'tfd' is a target file descriptor number in decimal form, @@ -1989,6 +1994,8 @@ For inotify files the format is the following:: pos: 0 flags: 02000000 + mnt_id: 9 + ino: 63107 inotify wd:3 ino:9e7e sdev:800013 mask:800afce ignored_mask:0 fhandle-bytes:8 fhandle-type:1 f_handle:7e9e0000640d1b6d where 'wd' is a watch descriptor in decimal form, i.e. a target file @@ -2011,6 +2018,7 @@ For fanotify files the format is:: pos: 0 flags: 02 mnt_id: 9 + ino: 63107 fanotify flags:10 event-flags:0 fanotify mnt_id:12 mflags:40 mask:38 ignored_mask:40000003 fanotify ino:4f969 sdev:800013 mflags:0 mask:3b ignored_mask:40000000 fhandle-bytes:8 fhandle-type:1 f_handle:69f90400c275b5b4 @@ -2035,6 +2043,7 @@ Timerfd files pos: 0 flags: 02 mnt_id: 9 + ino: 63107 clockid: 0 ticks: 0 settime flags: 01 @@ -2049,6 +2058,22 @@ details]. 'it_value' is remaining time until the timer expiration. with TIMER_ABSTIME option which will be shown in 'settime flags', but 'it_value' still exhibits timer's remaining time. +DMA Buffer files +~~~~~~~~~~~~~~~~ + +:: + + pos: 0 + flags: 04002 + mnt_id: 9 + ino: 63107 + size: 32768 + count: 2 + exp_name: system-heap + +where 'size' is the size of the DMA buffer in bytes. 'count' is the file count of +the DMA buffer file. 'exp_name' is the name of the DMA buffer exporter. + 3.9 /proc//map_files - Information about memory mapped files --------------------------------------------------------------------- This directory contains symbolic links which represent memory mapped files -- cgit v1.2.3 From 4c52729377eab025b238caeed48994a39c3b73f2 Mon Sep 17 00:00:00 2001 From: Andy Shevchenko Date: Wed, 30 Jun 2021 18:56:10 -0700 Subject: kernel.h: split out kstrtox() and simple_strtox() to a separate header kernel.h is being used as a dump for all kinds of stuff for a long time. Here is the attempt to start cleaning it up by splitting out kstrtox() and simple_strtox() helpers. At the same time convert users in header and lib folders to use new header. Though for time being include new header back to kernel.h to avoid twisted indirected includes for existing users. [andy.shevchenko@gmail.com: fix documentation references] Link: https://lkml.kernel.org/r/20210615220003.377901-1-andy.shevchenko@gmail.com Link: https://lkml.kernel.org/r/20210611185815.44103-1-andriy.shevchenko@linux.intel.com Signed-off-by: Andy Shevchenko Acked-by: Jonathan Cameron Cc: Francis Laniel Cc: Randy Dunlap Cc: Kars Mulder Cc: Trond Myklebust Cc: Anna Schumaker Cc: "J. Bruce Fields" Cc: Chuck Lever Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/core-api/kernel-api.rst | 7 ++----- 1 file changed, 2 insertions(+), 5 deletions(-) (limited to 'Documentation') diff --git a/Documentation/core-api/kernel-api.rst b/Documentation/core-api/kernel-api.rst index 741aa37dc181..2a7444e3a4c2 100644 --- a/Documentation/core-api/kernel-api.rst +++ b/Documentation/core-api/kernel-api.rst @@ -24,11 +24,8 @@ String Conversions .. kernel-doc:: lib/vsprintf.c :export: -.. kernel-doc:: include/linux/kernel.h - :functions: kstrtol - -.. kernel-doc:: include/linux/kernel.h - :functions: kstrtoul +.. kernel-doc:: include/linux/kstrtox.h + :functions: kstrtol kstrtoul .. kernel-doc:: lib/kstrtox.c :export: -- cgit v1.2.3 From 73f37068d540eba5f93ba3a0019bf479d35ebd76 Mon Sep 17 00:00:00 2001 From: Yangbo Lu Date: Wed, 30 Jun 2021 16:11:53 +0800 Subject: ptp: support ptp physical/virtual clocks conversion Support ptp physical/virtual clocks conversion via sysfs. There will be a new attribute n_vclocks under ptp physical clock sysfs. - In default, the value is 0 meaning only ptp physical clock is in use. - Setting the value can create corresponding number of ptp virtual clocks to use. But current physical clock is guaranteed to stay free running. - Setting the value back to 0 can delete virtual clocks and back use physical clock again. Another new attribute max_vclocks control the maximum number of ptp vclocks. Signed-off-by: Yangbo Lu Signed-off-by: David S. Miller --- Documentation/ABI/testing/sysfs-ptp | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-ptp b/Documentation/ABI/testing/sysfs-ptp index 2363ad810ddb..d378f57c1b73 100644 --- a/Documentation/ABI/testing/sysfs-ptp +++ b/Documentation/ABI/testing/sysfs-ptp @@ -33,6 +33,13 @@ Description: frequency adjustment value (a positive integer) in parts per billion. +What: /sys/class/ptp/ptpN/max_vclocks +Date: May 2021 +Contact: Yangbo Lu +Description: + This file contains the maximum number of ptp vclocks. + Write integer to re-configure it. + What: /sys/class/ptp/ptpN/n_alarms Date: September 2010 Contact: Richard Cochran @@ -61,6 +68,19 @@ Description: This file contains the number of programmable pins offered by the PTP hardware clock. +What: /sys/class/ptp/ptpN/n_vclocks +Date: May 2021 +Contact: Yangbo Lu +Description: + This file contains the number of virtual PTP clocks in + use. By default, the value is 0 meaning that only the + physical clock is in use. Setting the value creates + the corresponding number of virtual clocks and causes + the physical clock to become free running. Setting the + value back to 0 deletes the virtual clocks and + switches the physical clock back to normal, adjustable + operation. + What: /sys/class/ptp/ptpN/pins Date: March 2014 Contact: Richard Cochran -- cgit v1.2.3 From c156174a67070042d51d2c866146d3c934d5468c Mon Sep 17 00:00:00 2001 From: Yangbo Lu Date: Wed, 30 Jun 2021 16:11:56 +0800 Subject: ethtool: add a new command for getting PHC virtual clocks Add an interface for getting PHC (PTP Hardware Clock) virtual clocks, which are based on PHC physical clock providing hardware timestamp to network packets. Signed-off-by: Yangbo Lu Signed-off-by: David S. Miller --- Documentation/networking/ethtool-netlink.rst | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+) (limited to 'Documentation') diff --git a/Documentation/networking/ethtool-netlink.rst b/Documentation/networking/ethtool-netlink.rst index 6ea91e41593f..c86628e6a235 100644 --- a/Documentation/networking/ethtool-netlink.rst +++ b/Documentation/networking/ethtool-netlink.rst @@ -212,6 +212,7 @@ Userspace to kernel: ``ETHTOOL_MSG_FEC_SET`` set FEC settings ``ETHTOOL_MSG_MODULE_EEPROM_GET`` read SFP module EEPROM ``ETHTOOL_MSG_STATS_GET`` get standard statistics + ``ETHTOOL_MSG_PHC_VCLOCKS_GET`` get PHC virtual clocks info ===================================== ================================ Kernel to userspace: @@ -250,6 +251,7 @@ Kernel to userspace: ``ETHTOOL_MSG_FEC_NTF`` FEC settings ``ETHTOOL_MSG_MODULE_EEPROM_GET_REPLY`` read SFP module EEPROM ``ETHTOOL_MSG_STATS_GET_REPLY`` standard statistics + ``ETHTOOL_MSG_PHC_VCLOCKS_GET_REPLY`` PHC virtual clocks info ======================================== ================================= ``GET`` requests are sent by userspace applications to retrieve device @@ -1477,6 +1479,25 @@ Low and high bounds are inclusive, for example: etherStatsPkts512to1023Octets 512 1023 ============================= ==== ==== +PHC_VCLOCKS_GET +=============== + +Query device PHC virtual clocks information. + +Request contents: + + ==================================== ====== ========================== + ``ETHTOOL_A_PHC_VCLOCKS_HEADER`` nested request header + ==================================== ====== ========================== + +Kernel response contents: + + ==================================== ====== ========================== + ``ETHTOOL_A_PHC_VCLOCKS_HEADER`` nested reply header + ``ETHTOOL_A_PHC_VCLOCKS_NUM`` u32 PHC virtual clocks number + ``ETHTOOL_A_PHC_VCLOCKS_INDEX`` s32 PHC index array + ==================================== ====== ========================== + Request translation =================== @@ -1575,4 +1596,5 @@ are netlink only. n/a ``ETHTOOL_MSG_CABLE_TEST_ACT`` n/a ``ETHTOOL_MSG_CABLE_TEST_TDR_ACT`` n/a ``ETHTOOL_MSG_TUNNEL_INFO_GET`` + n/a ``ETHTOOL_MSG_PHC_VCLOCKS_GET`` =================================== ===================================== -- cgit v1.2.3 From 09ef17863f37235fe4e65a7d991e487b9ff6e553 Mon Sep 17 00:00:00 2001 From: Xin Long Date: Wed, 30 Jun 2021 20:18:20 -0400 Subject: Documentation: add more details in tipc.rst kernel-doc for TIPC is too simple, we need to add more information for it. This patch is to extend the abstract, and add the Features and Links items. Signed-off-by: Xin Long Acked-by: Jon Maloy Signed-off-by: David S. Miller --- Documentation/networking/tipc.rst | 121 +++++++++++++++++++++++++++++++++++++- 1 file changed, 118 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/networking/tipc.rst b/Documentation/networking/tipc.rst index 76775f24cdc8..ab63d298cca2 100644 --- a/Documentation/networking/tipc.rst +++ b/Documentation/networking/tipc.rst @@ -4,10 +4,125 @@ Linux Kernel TIPC ================= -TIPC (Transparent Inter Process Communication) is a protocol that is -specially designed for intra-cluster communication. +Introduction +============ -For more information about TIPC, see http://tipc.sourceforge.net. +TIPC (Transparent Inter Process Communication) is a protocol that is specially +designed for intra-cluster communication. It can be configured to transmit +messages either on UDP or directly across Ethernet. Message delivery is +sequence guaranteed, loss free and flow controlled. Latency times are shorter +than with any other known protocol, while maximal throughput is comparable to +that of TCP. + +TIPC Features +------------- + +- Cluster wide IPC service + + Have you ever wished you had the convenience of Unix Domain Sockets even when + transmitting data between cluster nodes? Where you yourself determine the + addresses you want to bind to and use? Where you don't have to perform DNS + lookups and worry about IP addresses? Where you don't have to start timers + to monitor the continuous existence of peer sockets? And yet without the + downsides of that socket type, such as the risk of lingering inodes? + + Welcome to the Transparent Inter Process Communication service, TIPC in short, + which gives you all of this, and a lot more. + +- Service Addressing + + A fundamental concept in TIPC is that of Service Addressing which makes it + possible for a programmer to chose his own address, bind it to a server + socket and let client programs use only that address for sending messages. + +- Service Tracking + + A client wanting to wait for the availability of a server, uses the Service + Tracking mechanism to subscribe for binding and unbinding/close events for + sockets with the associated service address. + + The service tracking mechanism can also be used for Cluster Topology Tracking, + i.e., subscribing for availability/non-availability of cluster nodes. + + Likewise, the service tracking mechanism can be used for Cluster Connectivity + Tracking, i.e., subscribing for up/down events for individual links between + cluster nodes. + +- Transmission Modes + + Using a service address, a client can send datagram messages to a server socket. + + Using the same address type, it can establish a connection towards an accepting + server socket. + + It can also use a service address to create and join a Communication Group, + which is the TIPC manifestation of a brokerless message bus. + + Multicast with very good performance and scalability is available both in + datagram mode and in communication group mode. + +- Inter Node Links + + Communication between any two nodes in a cluster is maintained by one or two + Inter Node Links, which both guarantee data traffic integrity and monitor + the peer node's availability. + +- Cluster Scalability + + By applying the Overlapping Ring Monitoring algorithm on the inter node links + it is possible to scale TIPC clusters up to 1000 nodes with a maintained + neighbor failure discovery time of 1-2 seconds. For smaller clusters this + time can be made much shorter. + +- Neighbor Discovery + + Neighbor Node Discovery in the cluster is done by Ethernet broadcast or UDP + multicast, when any of those services are available. If not, configured peer + IP addresses can be used. + +- Configuration + + When running TIPC in single node mode no configuration whatsoever is needed. + When running in cluster mode TIPC must as a minimum be given a node address + (before Linux 4.17) and told which interface to attach to. The "tipc" + configuration tool makes is possible to add and maintain many more + configuration parameters. + +- Performance + + TIPC message transfer latency times are better than in any other known protocol. + Maximal byte throughput for inter-node connections is still somewhat lower than + for TCP, while they are superior for intra-node and inter-container throughput + on the same host. + +- Language Support + + The TIPC user API has support for C, Python, Perl, Ruby, D and Go. + +More Information +---------------- + +- How to set up TIPC: + + http://tipc.io/getting_started.html + +- How to program with TIPC: + + http://tipc.io/programming.html + +- How to contribute to TIPC: + +- http://tipc.io/contacts.html + +- More details about TIPC specification: + + http://tipc.io/protocol.html + + +Implementation +============== + +TIPC is implemented as a kernel module in net/tipc/ directory. TIPC Base Types --------------- -- cgit v1.2.3 From 19373d0233d04ede649eee4269922e20dd133cf2 Mon Sep 17 00:00:00 2001 From: Geert Uytterhoeven Date: Thu, 1 Jul 2021 14:02:21 +0200 Subject: dt-bindings: net: sms911x: Convert to json-schema Convert the Smart Mixed-Signal Connectivity (SMSC) LAN911x/912x Controller Device Tree binding documentation to json-schema. Document missing properties. Make "phy-mode" not required, as many DTS files do not have it, and the Linux drivers falls back to PHY_INTERFACE_MODE_NA. Correct nodename in example. Signed-off-by: Geert Uytterhoeven Signed-off-by: David S. Miller --- Documentation/devicetree/bindings/net/gpmc-eth.txt | 2 +- .../devicetree/bindings/net/smsc,lan9115.yaml | 110 +++++++++++++++++++++ Documentation/devicetree/bindings/net/smsc911x.txt | 43 -------- 3 files changed, 111 insertions(+), 44 deletions(-) create mode 100644 Documentation/devicetree/bindings/net/smsc,lan9115.yaml delete mode 100644 Documentation/devicetree/bindings/net/smsc911x.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/gpmc-eth.txt b/Documentation/devicetree/bindings/net/gpmc-eth.txt index f7da3d73ca1b..32821066a85b 100644 --- a/Documentation/devicetree/bindings/net/gpmc-eth.txt +++ b/Documentation/devicetree/bindings/net/gpmc-eth.txt @@ -13,7 +13,7 @@ Documentation/devicetree/bindings/memory-controllers/omap-gpmc.txt For the properties relevant to the ethernet controller connected to the GPMC refer to the binding documentation of the device. For example, the documentation -for the SMSC 911x is Documentation/devicetree/bindings/net/smsc911x.txt +for the SMSC 911x is Documentation/devicetree/bindings/net/smsc,lan9115.yaml Child nodes need to specify the GPMC bus address width using the "bank-width" property but is possible that an ethernet controller also has a property to diff --git a/Documentation/devicetree/bindings/net/smsc,lan9115.yaml b/Documentation/devicetree/bindings/net/smsc,lan9115.yaml new file mode 100644 index 000000000000..f86667cbcca8 --- /dev/null +++ b/Documentation/devicetree/bindings/net/smsc,lan9115.yaml @@ -0,0 +1,110 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/smsc,lan9115.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Smart Mixed-Signal Connectivity (SMSC) LAN911x/912x Controller + +maintainers: + - Shawn Guo + +allOf: + - $ref: ethernet-controller.yaml# + +properties: + compatible: + oneOf: + - const: smsc,lan9115 + - items: + - enum: + - smsc,lan89218 + - smsc,lan9117 + - smsc,lan9118 + - smsc,lan9220 + - smsc,lan9221 + - const: smsc,lan9115 + + reg: + maxItems: 1 + + reg-shift: true + + reg-io-width: + enum: [ 2, 4 ] + default: 2 + + interrupts: + minItems: 1 + items: + - description: + LAN interrupt line + - description: + Optional PME (power management event) interrupt that is able to wake + up the host system with a 50ms pulse on network activity + + clocks: + maxItems: 1 + + phy-mode: true + + smsc,irq-active-high: + type: boolean + description: Indicates the IRQ polarity is active-high + + smsc,irq-push-pull: + type: boolean + description: Indicates the IRQ type is push-pull + + smsc,force-internal-phy: + type: boolean + description: Forces SMSC LAN controller to use internal PHY + + smsc,force-external-phy: + type: boolean + description: Forces SMSC LAN controller to use external PHY + + smsc,save-mac-address: + type: boolean + description: + Indicates that MAC address needs to be saved before resetting the + controller + + reset-gpios: + maxItems: 1 + description: + A GPIO line connected to the RESET (active low) signal of the device. + On many systems this is wired high so the device goes out of reset at + power-on, but if it is under program control, this optional GPIO can + wake up in response to it. + + vdd33a-supply: + description: 3.3V analog power supply + + vddvario-supply: + description: IO logic power supply + +required: + - compatible + - reg + - interrupts + +# There are lots of bus-specific properties ("qcom,*", "samsung,*", "fsl,*", +# "gpmc,*", ...) to be found, that actually depend on the compatible value of +# the parent node. +additionalProperties: true + +examples: + - | + #include + + ethernet@f4000000 { + compatible = "smsc,lan9220", "smsc,lan9115"; + reg = <0xf4000000 0x2000000>; + phy-mode = "mii"; + interrupt-parent = <&gpio1>; + interrupts = <31>, <32>; + reset-gpios = <&gpio1 30 GPIO_ACTIVE_LOW>; + reg-io-width = <4>; + smsc,irq-push-pull; + }; diff --git a/Documentation/devicetree/bindings/net/smsc911x.txt b/Documentation/devicetree/bindings/net/smsc911x.txt deleted file mode 100644 index acfafc8e143c..000000000000 --- a/Documentation/devicetree/bindings/net/smsc911x.txt +++ /dev/null @@ -1,43 +0,0 @@ -* Smart Mixed-Signal Connectivity (SMSC) LAN911x/912x Controller - -Required properties: -- compatible : Should be "smsc,lan", "smsc,lan9115" -- reg : Address and length of the io space for SMSC LAN -- interrupts : one or two interrupt specifiers - - The first interrupt is the SMSC LAN interrupt line - - The second interrupt (if present) is the PME (power - management event) interrupt that is able to wake up the host - system with a 50ms pulse on network activity -- phy-mode : See ethernet.txt file in the same directory - -Optional properties: -- reg-shift : Specify the quantity to shift the register offsets by -- reg-io-width : Specify the size (in bytes) of the IO accesses that - should be performed on the device. Valid value for SMSC LAN is - 2 or 4. If it's omitted or invalid, the size would be 2. -- smsc,irq-active-high : Indicates the IRQ polarity is active-high -- smsc,irq-push-pull : Indicates the IRQ type is push-pull -- smsc,force-internal-phy : Forces SMSC LAN controller to use - internal PHY -- smsc,force-external-phy : Forces SMSC LAN controller to use - external PHY -- smsc,save-mac-address : Indicates that mac address needs to be saved - before resetting the controller -- reset-gpios : a GPIO line connected to the RESET (active low) signal - of the device. On many systems this is wired high so the device goes - out of reset at power-on, but if it is under program control, this - optional GPIO can wake up in response to it. -- vdd33a-supply, vddvario-supply : 3.3V analog and IO logic power supplies - -Examples: - -lan9220@f4000000 { - compatible = "smsc,lan9220", "smsc,lan9115"; - reg = <0xf4000000 0x2000000>; - phy-mode = "mii"; - interrupt-parent = <&gpio1>; - interrupts = <31>, <32>; - reset-gpios = <&gpio1 30 GPIO_ACTIVE_LOW>; - reg-io-width = <4>; - smsc,irq-push-pull; -}; -- cgit v1.2.3 From fb786a48ac0dd63e702c05c35426f2e024f5749f Mon Sep 17 00:00:00 2001 From: Melissa Wen Date: Sat, 26 Jun 2021 10:26:55 +0100 Subject: drm/vkms: update the current status of todo list Update: - debugging issues on igt testcases - plane composition features: add primary plane improvements - suggestions of good tasks to start working on vkms Drop: - syzkaller bug report: what triggered the warning was replaced by shmem functions at https://patchwork.freedesktop.org/patch/394614/ - overlay plane: this feature was added by https://patchwork.freedesktop.org/patch/430941/ Signed-off-by: Melissa Wen Reviewed-by: Rodrigo Siqueira Link: https://patchwork.freedesktop.org/patch/msgid/20210626092655.ghmmt2yux5klrne7@smtp.gmail.com --- Documentation/gpu/vkms.rst | 38 ++++++++++++++++++++++++++------------ 1 file changed, 26 insertions(+), 12 deletions(-) (limited to 'Documentation') diff --git a/Documentation/gpu/vkms.rst b/Documentation/gpu/vkms.rst index 2c9b376da5ca..941f0e7e5eef 100644 --- a/Documentation/gpu/vkms.rst +++ b/Documentation/gpu/vkms.rst @@ -98,9 +98,17 @@ with VKMS maintainers. IGT better support ------------------ -- Investigate: (1) test cases on kms_plane that are failing due to timeout on - capturing CRC; (2) when running kms_flip test cases in sequence, some - successful individual test cases are failing randomly. +Debugging: + +- kms_plane: some test cases are failing due to timeout on capturing CRC; + +- kms_flip: when running test cases in sequence, some successful individual + test cases are failing randomly; when individually, some successful test + cases display in the log the following error:: + + [drm:vkms_prepare_fb [vkms]] ERROR vmap failed: -4 + +Virtual hardware (vblank-less) mode: - VKMS already has support for vblanks simulated via hrtimers, which can be tested with kms_flip test; in some way, we can say that VKMS already mimics @@ -116,7 +124,17 @@ Add Plane Features There's lots of plane features we could add support for: -- Real overlay planes, not just cursor. +- Multiple overlay planes. [Good to get started] + +- Clearing primary plane: clear primary plane before plane composition (at the + start) for correctness of pixel blend ops. It also guarantees alpha channel + is cleared in the target buffer for stable crc. [Good to get started] + +- ARGB format on primary plane: blend the primary plane into background with + translucent alpha. + +- Support when the primary plane isn't exactly matching the output size: blend + the primary plane into the black background. - Full alpha blending on all planes. @@ -129,13 +147,8 @@ There's lots of plane features we could add support for: cursor api). For all of these, we also want to review the igt test coverage and make sure -all relevant igt testcases work on vkms. - -Prime Buffer Sharing --------------------- - -- Syzbot report - WARNING in vkms_gem_free_object: - https://syzkaller.appspot.com/bug?extid=e7ad70d406e74d8fc9d0 +all relevant igt testcases work on vkms. They are good options for internship +project. Runtime Configuration --------------------- @@ -153,7 +166,7 @@ module. Use/Test-cases: the refresh rate. The currently proposed solution is to expose vkms configuration through -configfs. All existing module options should be supported through configfs +configfs. All existing module options should be supported through configfs too. Writeback support @@ -162,6 +175,7 @@ Writeback support - The writeback and CRC capture operations share the use of composer_enabled boolean to ensure vblanks. Probably, when these operations work together, composer_enabled needs to refcounting the composer state to proper work. + [Good to get started] - Add support for cloned writeback outputs and related test cases using a cloned output in the IGT kms_writeback. -- cgit v1.2.3 From 151b1982be5d9f4ca641687ee1a4bb4fba5d26cf Mon Sep 17 00:00:00 2001 From: Fengnan Chang Date: Tue, 8 Jun 2021 19:15:08 +0800 Subject: f2fs: compress: add nocompress extensions support When we create a directory with enable compression, all file write into directory will try to compress.But sometimes we may know, new file cannot meet compression ratio requirements. We need a nocompress extension to skip those files to avoid unnecessary compress page test. After add nocompress_extension, the priority should be: dir_flag < comp_extention,nocompress_extension < comp_file_flag, no_comp_file_flag. Priority in between FS_COMPR_FL, FS_NOCOMP_FS, extensions: * compress_extension=so; nocompress_extension=zip; chattr +c dir; touch dir/foo.so; touch dir/bar.zip; touch dir/baz.txt; then foo.so and baz.txt should be compresse, bar.zip should be non-compressed. chattr +c dir/bar.zip can enable compress on bar.zip. * compress_extension=so; nocompress_extension=zip; chattr -c dir; touch dir/foo.so; touch dir/bar.zip; touch dir/baz.txt; then foo.so should be compresse, bar.zip and baz.txt should be non-compressed. chattr+c dir/bar.zip; chattr+c dir/baz.txt; can enable compress on bar.zip and baz.txt. Signed-off-by: Fengnan Chang Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim --- Documentation/filesystems/f2fs.rst | 31 ++++++++++++++++++++++++++++++- 1 file changed, 30 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/filesystems/f2fs.rst b/Documentation/filesystems/f2fs.rst index b91e5a8444d5..ff9e7cc97c65 100644 --- a/Documentation/filesystems/f2fs.rst +++ b/Documentation/filesystems/f2fs.rst @@ -281,6 +281,18 @@ compress_extension=%s Support adding specified extension, so that f2fs can enab For other files, we can still enable compression via ioctl. Note that, there is one reserved special extension '*', it can be set to enable compression for all files. +nocompress_extension=%s Support adding specified extension, so that f2fs can disable + compression on those corresponding files, just contrary to compression extension. + If you know exactly which files cannot be compressed, you can use this. + The same extension name can't appear in both compress and nocompress + extension at the same time. + If the compress extension specifies all files, the types specified by the + nocompress extension will be treated as special cases and will not be compressed. + Don't allow use '*' to specifie all file in nocompress extension. + After add nocompress_extension, the priority should be: + dir_flag < comp_extention,nocompress_extension < comp_file_flag,no_comp_file_flag. + See more in compression sections. + compress_chksum Support verifying chksum of raw data in compressed cluster. compress_mode=%s Control file compression mode. This supports "fs" and "user" modes. In "fs" mode (default), f2fs does automatic compression @@ -817,13 +829,30 @@ Compression implementation all logical blocks in cluster contain valid data and compress ratio of cluster data is lower than specified threshold. -- To enable compression on regular inode, there are three ways: +- To enable compression on regular inode, there are four ways: * chattr +c file * chattr +c dir; touch dir/file * mount w/ -o compress_extension=ext; touch file.ext * mount w/ -o compress_extension=*; touch any_file +- To disable compression on regular inode, there are two ways: + + * chattr -c file + * mount w/ -o nocompress_extension=ext; touch file.ext + +- Priority in between FS_COMPR_FL, FS_NOCOMP_FS, extensions: + + * compress_extension=so; nocompress_extension=zip; chattr +c dir; touch + dir/foo.so; touch dir/bar.zip; touch dir/baz.txt; then foo.so and baz.txt + should be compresse, bar.zip should be non-compressed. chattr +c dir/bar.zip + can enable compress on bar.zip. + * compress_extension=so; nocompress_extension=zip; chattr -c dir; touch + dir/foo.so; touch dir/bar.zip; touch dir/baz.txt; then foo.so should be + compresse, bar.zip and baz.txt should be non-compressed. + chattr+c dir/bar.zip; chattr+c dir/baz.txt; can enable compress on bar.zip + and baz.txt. + - At this point, compression feature doesn't expose compressed space to user directly in order to guarantee potential data updates later to the space. Instead, the main goal is to reduce data writes to flash disk as much as -- cgit v1.2.3 From 8053f2d752e2936f494ede62766a6c9e9fb674f2 Mon Sep 17 00:00:00 2001 From: Kan Liang Date: Wed, 30 Jun 2021 14:08:36 -0700 Subject: perf/x86/intel/uncore: Add alias PMU name A perf PMU may have two PMU names. For example, Intel Sapphire Rapids server supports the discovery mechanism. Without the platform-specific support, an uncore PMU is named by a type ID plus a box ID, e.g., uncore_type_0_0, because the real name of the uncore PMU cannot be retrieved from the discovery table. With the platform-specific support later, perf has the mapping information from a type ID to a specific uncore unit. Just like the previous platforms, the uncore PMU is named by the real PMU name, e.g., uncore_cha_0. The user scripts which work well with the old numeric name may not work anymore. Add a new attribute "alias" to indicate the old numeric name. The following userspace perf tool patch will handle both names. The user scripts should work properly with the updated perf tool. Signed-off-by: Kan Liang Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Andi Kleen Link: https://lore.kernel.org/r/1625087320-194204-13-git-send-email-kan.liang@linux.intel.com --- .../ABI/testing/sysfs-bus-event_source-devices-uncore | 13 +++++++++++++ 1 file changed, 13 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-bus-event_source-devices-uncore (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-bus-event_source-devices-uncore b/Documentation/ABI/testing/sysfs-bus-event_source-devices-uncore new file mode 100644 index 000000000000..b56e8f019fd4 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-bus-event_source-devices-uncore @@ -0,0 +1,13 @@ +What: /sys/bus/event_source/devices/uncore_*/alias +Date: June 2021 +KernelVersion: 5.15 +Contact: Linux kernel mailing list +Description: Read-only. An attribute to describe the alias name of + the uncore PMU if an alias exists on some platforms. + The 'perf(1)' tool should treat both names the same. + They both can be used to access the uncore PMU. + + Example: + + $ cat /sys/devices/uncore_cha_2/alias + uncore_type_0_2 -- cgit v1.2.3 From 19d67694745c5c9ed085d0d8332fa02d835a07d0 Mon Sep 17 00:00:00 2001 From: Rodrigo Campos Date: Fri, 2 Jul 2021 17:19:27 +0200 Subject: Documentation: seccomp: Fix typo in user notification The close on exec flag is O_CLOEXEC, not O_EXEC. This patch just fixes the typo. Suggested-by: Christian Brauner Signed-off-by: Rodrigo Campos Acked-by: Christian Brauner Signed-off-by: Kees Cook Fixes: 0ae71c7720e3 ("seccomp: Support atomic "addfd + send reply"") Link: https://lore.kernel.org/r/20210702151927.263402-1-rodrigo@kinvolk.io --- Documentation/userspace-api/seccomp_filter.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/userspace-api/seccomp_filter.rst b/Documentation/userspace-api/seccomp_filter.rst index d61219889e49..539e9d4a4860 100644 --- a/Documentation/userspace-api/seccomp_filter.rst +++ b/Documentation/userspace-api/seccomp_filter.rst @@ -263,7 +263,7 @@ Userspace can also add file descriptors to the notifying process via ``ioctl(SECCOMP_IOCTL_NOTIF_ADDFD)``. The ``id`` member of ``struct seccomp_notif_addfd`` should be the same ``id`` as in ``struct seccomp_notif``. The ``newfd_flags`` flag may be used to set flags -like O_EXEC on the file descriptor in the notifying process. If the supervisor +like O_CLOEXEC on the file descriptor in the notifying process. If the supervisor wants to inject the file descriptor with a specific number, the ``SECCOMP_ADDFD_FLAG_SETFD`` flag can be used, and set the ``newfd`` member to the specific number to use. If that file descriptor is already open in the -- cgit v1.2.3 From 1aab6b81af3c96e3181911140d2528e112335bef Mon Sep 17 00:00:00 2001 From: Dmitry Osipenko Date: Wed, 16 Jun 2021 22:04:12 +0300 Subject: dt-bindings: thermal: Add binding for Tegra30 thermal sensor All NVIDIA Tegra30 SoCs have on-chip sensors which monitor temperature and voltage of the SoC. Sensors also controls CPU x2 freq throttle and emits emergency shutdown signal. TSENSOR has has two separate channels for each sensor placed in a different parts of the SoC. Add binding for the sensor hardware. Reviewed-by: Rob Herring Signed-off-by: Dmitry Osipenko Signed-off-by: Daniel Lezcano Link: https://lore.kernel.org/r/20210616190417.32214-2-digetx@gmail.com --- .../bindings/thermal/nvidia,tegra30-tsensor.yaml | 73 ++++++++++++++++++++++ 1 file changed, 73 insertions(+) create mode 100644 Documentation/devicetree/bindings/thermal/nvidia,tegra30-tsensor.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/thermal/nvidia,tegra30-tsensor.yaml b/Documentation/devicetree/bindings/thermal/nvidia,tegra30-tsensor.yaml new file mode 100644 index 000000000000..a35da257b070 --- /dev/null +++ b/Documentation/devicetree/bindings/thermal/nvidia,tegra30-tsensor.yaml @@ -0,0 +1,73 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/thermal/nvidia,tegra30-tsensor.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NVIDIA Tegra30 Thermal Sensor + +maintainers: + - Dmitry Osipenko + - Jon Hunter + - Thierry Reding + +description: | + TSENSOR provides thermal and voltage sensors which monitor temperature + and voltage of the chip. Sensors are placed across the die to gauge the + temperature of the whole chip. The TSENSOR module: + + Generates an interrupt to SW to lower temperature via DVFS on reaching + a certain thermal/voltage threshold. + + Generates a signal to the CAR to reduce CPU frequency by half on reaching + a certain thermal/voltage threshold. + + Generates a signal to the PMC when the temperature reaches dangerously high + levels to reset the chip and sets a flag in the PMC. + + TSENSOR has two channels which monitor two different spots of the SoC. + +properties: + compatible: + const: nvidia,tegra30-tsensor + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + + resets: + maxItems: 1 + + interrupts: + maxItems: 1 + + "#thermal-sensor-cells": + const: 1 + + assigned-clock-parents: true + assigned-clock-rates: true + assigned-clocks: true + +required: + - compatible + - reg + - clocks + - resets + - interrupts + - "#thermal-sensor-cells" + +additionalProperties: false + +examples: + - | + thermal-sensor@70014000 { + compatible = "nvidia,tegra30-tsensor"; + reg = <0x70014000 0x500>; + interrupts = <0 102 4>; + clocks = <&clk 100>; + resets = <&rst 100>; + + #thermal-sensor-cells = <1>; + }; -- cgit v1.2.3 From 7d70aa141ed2dcd36c93e070ba62d96613ccc06b Mon Sep 17 00:00:00 2001 From: Ezequiel Garcia Date: Thu, 6 May 2021 14:55:12 -0300 Subject: dt-bindings: thermal: convert rockchip-thermal to json-schema Convert Rockchip Thermal sensor dt-bindings to YAML. Signed-off-by: Ezequiel Garcia Reviewed-by: Rob Herring Signed-off-by: Daniel Lezcano Link: https://lore.kernel.org/r/20210506175514.168365-3-ezequiel@collabora.com --- .../bindings/thermal/rockchip-thermal.txt | 85 ------------------- .../bindings/thermal/rockchip-thermal.yaml | 95 ++++++++++++++++++++++ 2 files changed, 95 insertions(+), 85 deletions(-) delete mode 100644 Documentation/devicetree/bindings/thermal/rockchip-thermal.txt create mode 100644 Documentation/devicetree/bindings/thermal/rockchip-thermal.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/thermal/rockchip-thermal.txt b/Documentation/devicetree/bindings/thermal/rockchip-thermal.txt deleted file mode 100644 index 7f94669e9ebe..000000000000 --- a/Documentation/devicetree/bindings/thermal/rockchip-thermal.txt +++ /dev/null @@ -1,85 +0,0 @@ -* Temperature Sensor ADC (TSADC) on rockchip SoCs - -Required properties: -- compatible : should be "rockchip,-tsadc" - "rockchip,px30-tsadc": found on PX30 SoCs - "rockchip,rv1108-tsadc": found on RV1108 SoCs - "rockchip,rk3228-tsadc": found on RK3228 SoCs - "rockchip,rk3288-tsadc": found on RK3288 SoCs - "rockchip,rk3328-tsadc": found on RK3328 SoCs - "rockchip,rk3368-tsadc": found on RK3368 SoCs - "rockchip,rk3399-tsadc": found on RK3399 SoCs -- reg : physical base address of the controller and length of memory mapped - region. -- interrupts : The interrupt number to the cpu. The interrupt specifier format - depends on the interrupt controller. -- clocks : Must contain an entry for each entry in clock-names. -- clock-names : Shall be "tsadc" for the converter-clock, and "apb_pclk" for - the peripheral clock. -- resets : Must contain an entry for each entry in reset-names. - See ../reset/reset.txt for details. -- reset-names : Must include the name "tsadc-apb". -- pinctrl-names : The pin control state names; -- pinctrl-0 : The "init" pinctrl state, it will be set before device probe. -- pinctrl-1 : The "default" pinctrl state, it will be set after reset the - TSADC controller. -- pinctrl-2 : The "sleep" pinctrl state, it will be in for suspend. -- #thermal-sensor-cells : Should be 1. See Documentation/devicetree/bindings/thermal/thermal-sensor.yaml for a description. - -Optional properties: -- rockchip,hw-tshut-temp : The hardware-controlled shutdown temperature value. -- rockchip,hw-tshut-mode : The hardware-controlled shutdown mode 0:CRU 1:GPIO. -- rockchip,hw-tshut-polarity : The hardware-controlled active polarity 0:LOW - 1:HIGH. -- rockchip,grf : The phandle of the syscon node for the general register file. - -Exiample: -tsadc: tsadc@ff280000 { - compatible = "rockchip,rk3288-tsadc"; - reg = <0xff280000 0x100>; - interrupts = ; - clocks = <&cru SCLK_TSADC>, <&cru PCLK_TSADC>; - clock-names = "tsadc", "apb_pclk"; - resets = <&cru SRST_TSADC>; - reset-names = "tsadc-apb"; - pinctrl-names = "init", "default", "sleep"; - pinctrl-0 = <&otp_gpio>; - pinctrl-1 = <&otp_out>; - pinctrl-2 = <&otp_gpio>; - #thermal-sensor-cells = <1>; - rockchip,hw-tshut-temp = <95000>; - rockchip,hw-tshut-mode = <0>; - rockchip,hw-tshut-polarity = <0>; -}; - -Example: referring to thermal sensors: -thermal-zones { - cpu_thermal: cpu_thermal { - polling-delay-passive = <1000>; /* milliseconds */ - polling-delay = <5000>; /* milliseconds */ - - /* sensor ID */ - thermal-sensors = <&tsadc 1>; - - trips { - cpu_alert0: cpu_alert { - temperature = <70000>; /* millicelsius */ - hysteresis = <2000>; /* millicelsius */ - type = "passive"; - }; - cpu_crit: cpu_crit { - temperature = <90000>; /* millicelsius */ - hysteresis = <2000>; /* millicelsius */ - type = "critical"; - }; - }; - - cooling-maps { - map0 { - trip = <&cpu_alert0>; - cooling-device = - <&cpu0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>; - }; - }; - }; -}; diff --git a/Documentation/devicetree/bindings/thermal/rockchip-thermal.yaml b/Documentation/devicetree/bindings/thermal/rockchip-thermal.yaml new file mode 100644 index 000000000000..8385e8ac03e8 --- /dev/null +++ b/Documentation/devicetree/bindings/thermal/rockchip-thermal.yaml @@ -0,0 +1,95 @@ +# SPDX-License-Identifier: GPL-2.0-only +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/thermal/rockchip-thermal.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Temperature Sensor ADC (TSADC) on Rockchip SoCs + +maintainers: + - Heiko Stuebner + +properties: + compatible: + enum: + - rockchip,px30-tsadc # PX30 SoCs + - rockchip,rv1108-tsadc # RV1108 SoCs + - rockchip,rk3228-tsadc # RK3228 SoCs + - rockchip,rk3288-tsadc # RK3288 SoCs + - rockchip,rk3328-tsadc # RK3328 SoCs + - rockchip,rk3368-tsadc # RK3368 SoCs + - rockchip,rk3399-tsadc # RK3399 SoCs + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + minItems: 2 + maxItems: 2 + + clock-names: + items: + - const: tsadc + - const: apb_pclk + + resets: + maxItems: 1 + + reset-names: + items: + - const: tsadc-apb + + "#thermal-sensor-cells": + const: 1 + + rockchip,grf: + description: The phandle of the syscon node for the general register file. + $ref: /schemas/types.yaml#/definitions/phandle + + rockchip,hw-tshut-temp: + description: The hardware-controlled shutdown temperature value. + $ref: /schemas/types.yaml#/definitions/uint32 + + rockchip,hw-tshut-mode: + description: The hardware-controlled shutdown mode 0:CRU 1:GPIO. + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1] + + rockchip,hw-tshut-polarity: + description: The hardware-controlled active polarity 0:LOW 1:HIGH. + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1] + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + - resets + - reset-names + - "#thermal-sensor-cells" + +additionalProperties: false + +examples: + - | + #include + #include + + tsadc: tsadc@ff280000 { + compatible = "rockchip,rk3288-tsadc"; + reg = <0xff280000 0x100>; + interrupts = ; + clocks = <&cru SCLK_TSADC>, <&cru PCLK_TSADC>; + clock-names = "tsadc", "apb_pclk"; + resets = <&cru SRST_TSADC>; + reset-names = "tsadc-apb"; + #thermal-sensor-cells = <1>; + rockchip,hw-tshut-temp = <95000>; + rockchip,hw-tshut-mode = <0>; + rockchip,hw-tshut-polarity = <0>; + }; -- cgit v1.2.3 From 4b14c055a6f644cbeb1156ba24647e92fe51ec69 Mon Sep 17 00:00:00 2001 From: Ezequiel Garcia Date: Thu, 6 May 2021 14:55:13 -0300 Subject: dt-bindings: rockchip-thermal: Support the RK3568 SoC compatible Add a new compatible for the thermal sensor device on RK3568 SoCs. Signed-off-by: Ezequiel Garcia Acked-by: Rob Herring Signed-off-by: Daniel Lezcano Link: https://lore.kernel.org/r/20210506175514.168365-4-ezequiel@collabora.com --- Documentation/devicetree/bindings/thermal/rockchip-thermal.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/thermal/rockchip-thermal.yaml b/Documentation/devicetree/bindings/thermal/rockchip-thermal.yaml index 8385e8ac03e8..b96ea277b558 100644 --- a/Documentation/devicetree/bindings/thermal/rockchip-thermal.yaml +++ b/Documentation/devicetree/bindings/thermal/rockchip-thermal.yaml @@ -19,6 +19,7 @@ properties: - rockchip,rk3328-tsadc # RK3328 SoCs - rockchip,rk3368-tsadc # RK3368 SoCs - rockchip,rk3399-tsadc # RK3399 SoCs + - rockchip,rk3568-tsadc # RK3568 SoCs reg: maxItems: 1 -- cgit v1.2.3 From 481bd297291b59480b87f88f88fbcff59455dcc3 Mon Sep 17 00:00:00 2001 From: Bjorn Andersson Date: Tue, 8 Jun 2021 13:16:38 -0700 Subject: dt-bindings: thermal: tsens: Add sc8180x compatible The Qualcomm sc8180x platform has the usual tsens blocks, add compatible for this. Signed-off-by: Bjorn Andersson Acked-by: Thara Gopinath Acked-by: Rob Herring Signed-off-by: Daniel Lezcano Link: https://lore.kernel.org/r/20210608201638.2136344-1-bjorn.andersson@linaro.org --- Documentation/devicetree/bindings/thermal/qcom-tsens.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml b/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml index 0d4cfe04648f..ccf70dd06d5b 100644 --- a/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml +++ b/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml @@ -47,6 +47,7 @@ properties: - qcom,msm8998-tsens - qcom,sc7180-tsens - qcom,sc7280-tsens + - qcom,sc8180x-tsens - qcom,sdm845-tsens - qcom,sm8150-tsens - qcom,sm8250-tsens -- cgit v1.2.3 From 1da4cd82dd180224503e745ccf3220e3490d8897 Mon Sep 17 00:00:00 2001 From: Ali Abdallah Date: Thu, 27 May 2021 09:19:06 +0200 Subject: netfilter: conntrack: add new sysctl to disable RST check This patch adds a new sysctl tcp_ignore_invalid_rst to disable marking out of segments RSTs as INVALID. Signed-off-by: Ali Abdallah Acked-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso --- Documentation/networking/nf_conntrack-sysctl.rst | 6 ++++++ 1 file changed, 6 insertions(+) (limited to 'Documentation') diff --git a/Documentation/networking/nf_conntrack-sysctl.rst b/Documentation/networking/nf_conntrack-sysctl.rst index 0467b30e4abe..d31ed6c1cb0d 100644 --- a/Documentation/networking/nf_conntrack-sysctl.rst +++ b/Documentation/networking/nf_conntrack-sysctl.rst @@ -110,6 +110,12 @@ nf_conntrack_tcp_be_liberal - BOOLEAN Be conservative in what you do, be liberal in what you accept from others. If it's non-zero, we mark only out of window RST segments as INVALID. +nf_conntrack_tcp_ignore_invalid_rst - BOOLEAN + - 0 - disabled (default) + - 1 - enabled + + If it's 1, we don't mark out of window RST segments as INVALID. + nf_conntrack_tcp_loose - BOOLEAN - 0 - disabled - not 0 - enabled (default) -- cgit v1.2.3 From c9cd752d8f3a6b13afc5332a60bea3e68f141738 Mon Sep 17 00:00:00 2001 From: Ulf Hansson Date: Mon, 5 Jul 2021 15:34:41 +0200 Subject: regulator: fixed: Mark regulator-fixed-domain as deprecated A power domain should not be modelled as a regulator, not even for the simplest case as recent discussions have concluded around the existing regulator-fixed-domain DT binding. Fortunately, there is only one user of the binding that was recently added. Therefore, let's mark the binding as deprecated to prevent it from being further used. Signed-off-by: Ulf Hansson Link: https://lore.kernel.org/r/20210705133441.11344-1-ulf.hansson@linaro.org Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/regulator/fixed-regulator.yaml | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/regulator/fixed-regulator.yaml b/Documentation/devicetree/bindings/regulator/fixed-regulator.yaml index 8850c01bd470..9b131c6facbc 100644 --- a/Documentation/devicetree/bindings/regulator/fixed-regulator.yaml +++ b/Documentation/devicetree/bindings/regulator/fixed-regulator.yaml @@ -57,12 +57,14 @@ properties: maxItems: 1 power-domains: + deprecated: true description: Power domain to use for enable control. This binding is only available if the compatible is chosen to regulator-fixed-domain. maxItems: 1 required-opps: + deprecated: true description: Performance state to use for enable control. This binding is only available if the compatible is chosen to regulator-fixed-domain. The -- cgit v1.2.3 From d1bbfd0c7c9f985e57795a7e0cefc209ebf689c0 Mon Sep 17 00:00:00 2001 From: Peter Zijlstra Date: Mon, 5 Jul 2021 17:00:24 +0200 Subject: Documentation/atomic_t: Document cmpxchg() vs try_cmpxchg() There seems to be a significant amount of confusion around the new try_cmpxchg(), despite this being more like the C11 atomic_compare_exchange_*() family. Add a few words of clarification on how cmpxchg() and try_cmpxchg() relate to one another. Signed-off-by: Peter Zijlstra (Intel) Acked-by: Will Deacon Link: https://lkml.kernel.org/r/YOMgPeMOmmiK3tXO@hirez.programming.kicks-ass.net --- Documentation/atomic_t.txt | 41 +++++++++++++++++++++++++++++++++++++++++ 1 file changed, 41 insertions(+) (limited to 'Documentation') diff --git a/Documentation/atomic_t.txt b/Documentation/atomic_t.txt index 0f1fdedf36bb..a9c1e2b39b15 100644 --- a/Documentation/atomic_t.txt +++ b/Documentation/atomic_t.txt @@ -271,3 +271,44 @@ WRITE_ONCE. Thus: SC *y, t; is allowed. + + +CMPXCHG vs TRY_CMPXCHG +---------------------- + + int atomic_cmpxchg(atomic_t *ptr, int old, int new); + bool atomic_try_cmpxchg(atomic_t *ptr, int *oldp, int new); + +Both provide the same functionality, but try_cmpxchg() can lead to more +compact code. The functions relate like: + + bool atomic_try_cmpxchg(atomic_t *ptr, int *oldp, int new) + { + int ret, old = *oldp; + ret = atomic_cmpxchg(ptr, old, new); + if (ret != old) + *oldp = ret; + return ret == old; + } + +and: + + int atomic_cmpxchg(atomic_t *ptr, int old, int new) + { + (void)atomic_try_cmpxchg(ptr, &old, new); + return old; + } + +Usage: + + old = atomic_read(&v); old = atomic_read(&v); + for (;;) { do { + new = func(old); new = func(old); + tmp = atomic_cmpxchg(&v, old, new); } while (!atomic_try_cmpxchg(&v, &old, new)); + if (tmp == old) + break; + old = tmp; + } + +NB. try_cmpxchg() also generates better code on some platforms (notably x86) +where the function more closely matches the hardware instruction. -- cgit v1.2.3 From f8a9a5c2e9058bcfc3a3d5b444d10fd8f20cb29e Mon Sep 17 00:00:00 2001 From: Jason Ekstrand Date: Thu, 8 Jul 2021 10:48:20 -0500 Subject: drm/i915: Add gem/i915_gem_context.h to the docs In order to prevent kernel doc warnings, also fill out docs for any missing fields and fix those that forgot the "@". Signed-off-by: Jason Ekstrand Reviewed-by: Daniel Vetter Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20210708154835.528166-16-jason@jlekstrand.net --- Documentation/gpu/i915.rst | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst index e6fd9608e9c6..204ebdaadb45 100644 --- a/Documentation/gpu/i915.rst +++ b/Documentation/gpu/i915.rst @@ -422,6 +422,8 @@ Batchbuffer Parsing User Batchbuffer Execution -------------------------- +.. kernel-doc:: drivers/gpu/drm/i915/gem/i915_gem_context_types.h + .. kernel-doc:: drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c :doc: User command execution -- cgit v1.2.3 From 9294523e3768030ae8afb84110bcecc66425a647 Mon Sep 17 00:00:00 2001 From: Stephen Boyd Date: Wed, 7 Jul 2021 18:09:20 -0700 Subject: module: add printk formats to add module build ID to stacktraces Let's make kernel stacktraces easier to identify by including the build ID[1] of a module if the stacktrace is printing a symbol from a module. This makes it simpler for developers to locate a kernel module's full debuginfo for a particular stacktrace. Combined with scripts/decode_stracktrace.sh, a developer can download the matching debuginfo from a debuginfod[2] server and find the exact file and line number for the functions plus offsets in a stacktrace that match the module. This is especially useful for pstore crash debugging where the kernel crashes are recorded in something like console-ramoops and the recovery kernel/modules are different or the debuginfo doesn't exist on the device due to space concerns (the debuginfo can be too large for space limited devices). Originally, I put this on the %pS format, but that was quickly rejected given that %pS is used in other places such as ftrace where build IDs aren't meaningful. There was some discussions on the list to put every module build ID into the "Modules linked in:" section of the stacktrace message but that quickly becomes very hard to read once you have more than three or four modules linked in. It also provides too much information when we don't expect each module to be traversed in a stacktrace. Having the build ID for modules that aren't important just makes things messy. Splitting it to multiple lines for each module quickly explodes the number of lines printed in an oops too, possibly wrapping the warning off the console. And finally, trying to stash away each module used in a callstack to provide the ID of each symbol printed is cumbersome and would require changes to each architecture to stash away modules and return their build IDs once unwinding has completed. Instead, we opt for the simpler approach of introducing new printk formats '%pS[R]b' for "pointer symbolic backtrace with module build ID" and '%pBb' for "pointer backtrace with module build ID" and then updating the few places in the architecture layer where the stacktrace is printed to use this new format. Before: Call trace: lkdtm_WARNING+0x28/0x30 [lkdtm] direct_entry+0x16c/0x1b4 [lkdtm] full_proxy_write+0x74/0xa4 vfs_write+0xec/0x2e8 After: Call trace: lkdtm_WARNING+0x28/0x30 [lkdtm 6c2215028606bda50de823490723dc4bc5bf46f9] direct_entry+0x16c/0x1b4 [lkdtm 6c2215028606bda50de823490723dc4bc5bf46f9] full_proxy_write+0x74/0xa4 vfs_write+0xec/0x2e8 [akpm@linux-foundation.org: fix build with CONFIG_MODULES=n, tweak code layout] [rdunlap@infradead.org: fix build when CONFIG_MODULES is not set] Link: https://lkml.kernel.org/r/20210513171510.20328-1-rdunlap@infradead.org [akpm@linux-foundation.org: make kallsyms_lookup_buildid() static] [cuibixuan@huawei.com: fix build error when CONFIG_SYSFS is disabled] Link: https://lkml.kernel.org/r/20210525105049.34804-1-cuibixuan@huawei.com Link: https://lkml.kernel.org/r/20210511003845.2429846-6-swboyd@chromium.org Link: https://fedoraproject.org/wiki/Releases/FeatureBuildId [1] Link: https://sourceware.org/elfutils/Debuginfod.html [2] Signed-off-by: Stephen Boyd Signed-off-by: Bixuan Cui Signed-off-by: Randy Dunlap Cc: Jiri Olsa Cc: Alexei Starovoitov Cc: Jessica Yu Cc: Evan Green Cc: Hsin-Yi Wang Cc: Petr Mladek Cc: Steven Rostedt Cc: Sergey Senozhatsky Cc: Andy Shevchenko Cc: Rasmus Villemoes Cc: Matthew Wilcox Cc: Baoquan He Cc: Borislav Petkov Cc: Catalin Marinas Cc: Dave Young Cc: Ingo Molnar Cc: Konstantin Khlebnikov Cc: Sasha Levin Cc: Thomas Gleixner Cc: Vivek Goyal Cc: Will Deacon Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/core-api/printk-formats.rst | 11 +++++++++++ 1 file changed, 11 insertions(+) (limited to 'Documentation') diff --git a/Documentation/core-api/printk-formats.rst b/Documentation/core-api/printk-formats.rst index 4346ae17a72c..d941717a191b 100644 --- a/Documentation/core-api/printk-formats.rst +++ b/Documentation/core-api/printk-formats.rst @@ -125,6 +125,17 @@ used when printing stack backtraces. The specifier takes into consideration the effect of compiler optimisations which may occur when tail-calls are used and marked with the noreturn GCC attribute. +If the pointer is within a module, the module name and optionally build ID is +printed after the symbol name with an extra ``b`` appended to the end of the +specifier. + +:: + %pS versatile_init+0x0/0x110 [module_name] + %pSb versatile_init+0x0/0x110 [module_name ed5019fdf5e53be37cb1ba7899292d7e143b259e] + %pSRb versatile_init+0x9/0x110 [module_name ed5019fdf5e53be37cb1ba7899292d7e143b259e] + (with __builtin_extract_return_addr() translation) + %pBb prev_fn_of_versatile_init+0x88/0x88 [module_name ed5019fdf5e53be37cb1ba7899292d7e143b259e] + Probed Pointers from BPF / tracing ---------------------------------- -- cgit v1.2.3 From c20dec19358449050785ba42c702f68a86060564 Mon Sep 17 00:00:00 2001 From: Rajeev Nandan Date: Sat, 26 Jun 2021 22:21:07 +0530 Subject: dt-bindings: display: simple: Add Samsung ATNA33XC20 Add Samsung 13.3" FHD eDP AMOLED panel. Signed-off-by: Rajeev Nandan Reviewed-by: Douglas Anderson Acked-by: Rob Herring Signed-off-by: Douglas Anderson Link: https://patchwork.freedesktop.org/patch/msgid/1624726268-14869-6-git-send-email-rajeevny@codeaurora.org --- Documentation/devicetree/bindings/display/panel/panel-simple.yaml | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml index 4a0a5e1ee252..f5acfd64f2a5 100644 --- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml +++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml @@ -242,6 +242,8 @@ properties: - rocktech,rk101ii01d-ct # Rocktech Display Ltd. RK070ER9427 800(RGB)x480 TFT LCD panel - rocktech,rk070er9427 + # Samsung 13.3" FHD (1920x1080 pixels) eDP AMOLED panel + - samsung,atna33xc20 # Samsung 12.2" (2560x1600 pixels) TFT LCD panel - samsung,lsn122dl01-c01 # Samsung Electronics 10.1" WSVGA TFT LCD panel -- cgit v1.2.3 From 710fa9aa16321f2ffdd8383f6f780c9cc1e5a197 Mon Sep 17 00:00:00 2001 From: Linus Walleij Date: Thu, 1 Jul 2021 23:36:18 +0200 Subject: drm/panel: Fix up DT bindings for Samsung lms397kf04 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Improve the bindings and make them more usable: - Pick in spi-cpha and spi-cpol from the SPI node parent, this will specify that we are "type 3" in the device tree rather than hardcoding it in the operating system. - Drop the u32 ref from the SPI frequency: comes in from the SPI host bindings. - Make spi-cpha, spi-cpol and port compulsory. - Update the example with a real-world SPI controller, spi-gpio. Cc: Noralf Trønnes Cc: devicetree@vger.kernel.org Signed-off-by: Linus Walleij Reviewed-by: Sam Ravnborg Reviewed-by: Douglas Anderson Link: https://patchwork.freedesktop.org/patch/msgid/20210701213618.3818821-1-linus.walleij@linaro.org --- .../bindings/display/panel/samsung,lms397kf04.yaml | 18 ++++++++++++++++-- 1 file changed, 16 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/panel/samsung,lms397kf04.yaml b/Documentation/devicetree/bindings/display/panel/samsung,lms397kf04.yaml index 4cb75a5f2e3a..cd62968426fb 100644 --- a/Documentation/devicetree/bindings/display/panel/samsung,lms397kf04.yaml +++ b/Documentation/devicetree/bindings/display/panel/samsung,lms397kf04.yaml @@ -33,8 +33,11 @@ properties: backlight: true + spi-cpha: true + + spi-cpol: true + spi-max-frequency: - $ref: /schemas/types.yaml#/definitions/uint32 description: inherited as a SPI client node, the datasheet specifies maximum 300 ns minimum cycle which gives around 3 MHz max frequency maximum: 3000000 @@ -44,6 +47,9 @@ properties: required: - compatible - reg + - spi-cpha + - spi-cpol + - port additionalProperties: false @@ -52,15 +58,23 @@ examples: #include spi { + compatible = "spi-gpio"; + sck-gpios = <&gpio 0 GPIO_ACTIVE_HIGH>; + miso-gpios = <&gpio 1 GPIO_ACTIVE_HIGH>; + mosi-gpios = <&gpio 2 GPIO_ACTIVE_HIGH>; + cs-gpios = <&gpio 3 GPIO_ACTIVE_HIGH>; + num-chipselects = <1>; #address-cells = <1>; #size-cells = <0>; panel@0 { compatible = "samsung,lms397kf04"; spi-max-frequency = <3000000>; + spi-cpha; + spi-cpol; reg = <0>; vci-supply = <&lcd_3v0_reg>; vccio-supply = <&lcd_1v8_reg>; - reset-gpios = <&gpio 1 GPIO_ACTIVE_LOW>; + reset-gpios = <&gpio 4 GPIO_ACTIVE_LOW>; backlight = <&ktd259>; port { -- cgit v1.2.3 From a60d6b4164636a9195aed032f780f6fa5c1f966b Mon Sep 17 00:00:00 2001 From: Yunus Bas Date: Fri, 9 Jul 2021 22:09:12 +0200 Subject: dt-bindings: display: simple: Add EDT ETMV570G2DHU The Emerging Display Technology ETMV570G2DHU is a 5.7" VGA TFT panel. Add it to the list of compatibles. Signed-off-by: Yunus Bas Signed-off-by: Sam Ravnborg Link: https://patchwork.freedesktop.org/patch/msgid/20210709200913.2666570-1-y.bas@phytec.de --- Documentation/devicetree/bindings/display/panel/panel-simple.yaml | 3 +++ 1 file changed, 3 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml index f5acfd64f2a5..2d154fc4a004 100644 --- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml +++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml @@ -128,6 +128,9 @@ properties: # Emerging Display Technology Corp. WVGA TFT Display with capacitive touch - edt,etm0700g0dh6 - edt,etm0700g0edh6 + # Emerging Display Technology Corp. 5.7" VGA TFT LCD panel with + # capacitive touch + - edt,etmv570g2dhu # Evervision Electronics Co. Ltd. VGG804821 5.0" WVGA TFT LCD Panel - evervision,vgg804821 # Foxlink Group 5" WVGA TFT LCD panel -- cgit v1.2.3 From f3ba46debcafd7f6c8440e38caeb0247d1336336 Mon Sep 17 00:00:00 2001 From: Yunus Bas Date: Fri, 9 Jul 2021 22:09:13 +0200 Subject: dt-bindings: display: simple: Add EDT ETM0350G0DH6 The Emerging Display Technology ETM0350G0DH6 is a 3.5" WVGA TFT panel with capacitive multitouch. Add it to the list of compatibles. Signed-off-by: Yunus Bas Signed-off-by: Sam Ravnborg Link: https://patchwork.freedesktop.org/patch/msgid/20210709200913.2666570-2-y.bas@phytec.de --- Documentation/devicetree/bindings/display/panel/panel-simple.yaml | 3 +++ 1 file changed, 3 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml index 2d154fc4a004..3624363938dd 100644 --- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml +++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml @@ -110,6 +110,9 @@ properties: # Emerging Display Technology Corp. 5.7" VGA TFT LCD panel - edt,et057090dhu - edt,et070080dh6 + # Emerging Display Technology Corp. 3.5" WVGA TFT LCD panel with + # capacitive multitouch + - edt,etm0350g0dh6 # Emerging Display Technology Corp. 480x272 TFT Display with capacitive touch - edt,etm043080dh6gp # Emerging Display Technology Corp. 480x272 TFT Display -- cgit v1.2.3 From 08eeafbba566ad0413b2e118e72658bee0550efb Mon Sep 17 00:00:00 2001 From: Alexandre Belloni Date: Mon, 21 Jun 2021 00:40:29 +0200 Subject: dt-bindings: rtc: ti,bq32k: take maintainership Take maintainership of the binding as PAvel said he doesn't have the hardware anymore. Signed-off-by: Alexandre Belloni Acked-by: Pavel Machek Link: https://lore.kernel.org/r/20210620224030.1115356-1-alexandre.belloni@bootlin.com --- Documentation/devicetree/bindings/rtc/ti,bq32000.yaml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/rtc/ti,bq32000.yaml b/Documentation/devicetree/bindings/rtc/ti,bq32000.yaml index 392bd71bd1be..bf9c1c4ddb7e 100644 --- a/Documentation/devicetree/bindings/rtc/ti,bq32000.yaml +++ b/Documentation/devicetree/bindings/rtc/ti,bq32000.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: TI BQ32000 I2C Serial Real-Time Clock maintainers: - - Pavel Machek + - Alexandre Belloni allOf: - $ref: rtc.yaml# -- cgit v1.2.3 From 5dcd276e1525e0c7ae7aa1f0426b6343ebf994e0 Mon Sep 17 00:00:00 2001 From: Peter Ujfalusi Date: Mon, 5 Jul 2021 22:42:46 +0300 Subject: ASoC: dt-bindings: davinci-mcasp: Add compatible string for OMAP4 OMAP4 has one McASP instance with single serializer and supporting only DIT mode. According to the TRM the DAT port needs to be accessed as specific offset compared to other devices where access to any part of the DAT region is valid. To handle this constraint we need to introduce a new compatiple string for OMAP4. Signed-off-by: Peter Ujfalusi Link: https://lore.kernel.org/r/20210705194249.2385-3-peter.ujfalusi@gmail.com Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/sound/davinci-mcasp-audio.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/davinci-mcasp-audio.txt b/Documentation/devicetree/bindings/sound/davinci-mcasp-audio.txt index c483dcec01f8..bd863bd69501 100644 --- a/Documentation/devicetree/bindings/sound/davinci-mcasp-audio.txt +++ b/Documentation/devicetree/bindings/sound/davinci-mcasp-audio.txt @@ -6,6 +6,7 @@ Required properties: "ti,da830-mcasp-audio" : for both DA830 & DA850 platforms "ti,am33xx-mcasp-audio" : for AM33xx platforms (AM33xx, AM43xx, TI81xx) "ti,dra7-mcasp-audio" : for DRA7xx platforms + "ti,omap4-mcasp-audio" : for OMAP4 - reg : Should contain reg specifiers for the entries in the reg-names property. - reg-names : Should contain: -- cgit v1.2.3 From 526e99cf43fe3884014f9e9f2ca5d04d56007287 Mon Sep 17 00:00:00 2001 From: ChiYuan Huang Date: Fri, 9 Jul 2021 23:40:35 +0800 Subject: regulator: rtq6752: Add binding document for Richtek RTQ6752 Add binding document for Richtek RTQ6752. Signed-off-by: ChiYuan Huang Link: https://lore.kernel.org/r/1625845236-30285-1-git-send-email-u0084500@gmail.com Signed-off-by: Mark Brown --- .../regulator/richtek,rtq6752-regulator.yaml | 78 ++++++++++++++++++++++ 1 file changed, 78 insertions(+) create mode 100644 Documentation/devicetree/bindings/regulator/richtek,rtq6752-regulator.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/regulator/richtek,rtq6752-regulator.yaml b/Documentation/devicetree/bindings/regulator/richtek,rtq6752-regulator.yaml new file mode 100644 index 000000000000..641840ea7c16 --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/richtek,rtq6752-regulator.yaml @@ -0,0 +1,78 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/regulator/richtek,rtq6752-regulator.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Richtek RTQ6752 TFT LCD Voltage Regulator + +maintainers: + - ChiYuan Huang + +description: | + The RTQ6752 is an I2C interface pgorammable power management IC. It includes + two synchronous boost converter for PAVDD, and one synchronous NAVDD + buck-boost. The device is suitable for automotive TFT-LCD panel. + +properties: + compatible: + enum: + - richtek,rtq6752 + + reg: + maxItems: 1 + + enable-gpios: + description: | + A connection of the chip 'enable' gpio line. If not provided, treat it as + external pull up. + maxItems: 1 + + regulators: + type: object + $ref: regulator.yaml# + + patternProperties: + "^(p|n)avdd$": + type: object + $ref: regulator.yaml# + description: | + regulator description for pavdd and navdd. + + additionalProperties: false + +required: + - compatible + - reg + - regulators + +additionalProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + rtq6752@6b { + compatible = "richtek,rtq6752"; + status = "okay"; + reg = <0x6b>; + enable-gpios = <&gpio26 2 0>; + + regulators { + pavdd { + regulator-name = "rtq6752-pavdd"; + regulator-min-microvolt = <5000000>; + regulator-max-microvolt = <7300000>; + regulator-boot-on; + }; + navdd { + regulator-name = "rtq6752-navdd"; + regulator-min-microvolt = <5000000>; + regulator-max-microvolt = <7300000>; + regulator-boot-on; + }; + }; + }; + }; -- cgit v1.2.3 From 3522d9aa19285bbff14da20cb3481e36ef4835fd Mon Sep 17 00:00:00 2001 From: Mason Zhang Date: Tue, 29 Jun 2021 18:13:11 +0800 Subject: spi: mediatek: update spi master bingdings for MT6893 SOC this patch update spi master bingdings for MT6893 SOC. Signed-off-by: Mason Zhang Link: https://lore.kernel.org/r/20210629101310.21045-1-mason.zhang@mediatek.com Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/spi/spi-mt65xx.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/spi/spi-mt65xx.txt b/Documentation/devicetree/bindings/spi/spi-mt65xx.txt index 4d0e4c15c4ea..2a24969159cc 100644 --- a/Documentation/devicetree/bindings/spi/spi-mt65xx.txt +++ b/Documentation/devicetree/bindings/spi/spi-mt65xx.txt @@ -11,6 +11,7 @@ Required properties: - mediatek,mt8135-spi: for mt8135 platforms - mediatek,mt8173-spi: for mt8173 platforms - mediatek,mt8183-spi: for mt8183 platforms + - mediatek,mt6893-spi: for mt6893 platforms - "mediatek,mt8192-spi", "mediatek,mt6765-spi": for mt8192 platforms - "mediatek,mt8195-spi", "mediatek,mt6765-spi": for mt8195 platforms - "mediatek,mt8516-spi", "mediatek,mt2712-spi": for mt8516 platforms -- cgit v1.2.3 From caa7302b3a346d9a9ec85568cff52d2cee5f32c4 Mon Sep 17 00:00:00 2001 From: Hans Verkuil Date: Fri, 18 Jun 2021 16:21:36 +0200 Subject: media: include/uapi/linux/cec.h: typo: SATERDAY -> SATURDAY Fix typo in a define: CEC_OP_REC_SEQ_SATERDAY -> CEC_OP_REC_SEQ_SATURDAY This isn't used yet in actual applications to the best of my knowledge, and it certainly doesn't break the ABI since the value doesn't change. Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab --- Documentation/userspace-api/media/cec.h.rst.exceptions | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/userspace-api/media/cec.h.rst.exceptions b/Documentation/userspace-api/media/cec.h.rst.exceptions index d83790ccac8e..13de01d9555e 100644 --- a/Documentation/userspace-api/media/cec.h.rst.exceptions +++ b/Documentation/userspace-api/media/cec.h.rst.exceptions @@ -140,7 +140,7 @@ ignore define CEC_OP_REC_SEQ_TUESDAY ignore define CEC_OP_REC_SEQ_WEDNESDAY ignore define CEC_OP_REC_SEQ_THURSDAY ignore define CEC_OP_REC_SEQ_FRIDAY -ignore define CEC_OP_REC_SEQ_SATERDAY +ignore define CEC_OP_REC_SEQ_SATURDAY ignore define CEC_OP_REC_SEQ_ONCE_ONLY ignore define CEC_MSG_CLEAR_DIGITAL_TIMER -- cgit v1.2.3 From 229e5bdcd39ed3ca0a71dc8500ba4ea90d4415db Mon Sep 17 00:00:00 2001 From: Jernej Skrabec Date: Sun, 6 Jun 2021 10:23:13 +0200 Subject: media: hevc: Add segment address field If HEVC frame consists of multiple slices, segment address has to be known in order to properly decode it. Add segment address field to slice parameters. Signed-off-by: Jernej Skrabec Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab --- Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst | 3 +++ 1 file changed, 3 insertions(+) (limited to 'Documentation') diff --git a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst index 8c6e2a11ed95..dc096a5562cd 100644 --- a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst +++ b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst @@ -3000,6 +3000,9 @@ enum v4l2_mpeg_video_hevc_size_of_length_field - * - __u8 - ``pic_struct`` - + * - __u32 + - ``slice_segment_addr`` + - * - __u8 - ``ref_idx_l0[V4L2_HEVC_DPB_ENTRIES_NUM_MAX]`` - The list of L0 reference elements as indices in the DPB. -- cgit v1.2.3 From 97db1b081e1286bdd9dcd4d25b88d6770ff4a65b Mon Sep 17 00:00:00 2001 From: Wesley Cheng Date: Sat, 10 Jul 2021 02:13:15 -0700 Subject: dt-bindings: usb: dwc3: Update dwc3 TX fifo properties Update the tx-fifo-resize property with a better description, while adding the tx-fifo-max-num, which is a new parameter allowing adjustments for the maximum number of packets the txfifo resizing logic can account for while resizing the endpoints. Reviewed-by: Rob Herring Signed-off-by: Wesley Cheng Link: https://lore.kernel.org/r/1625908395-5498-7-git-send-email-wcheng@codeaurora.org Signed-off-by: Greg Kroah-Hartman --- Documentation/devicetree/bindings/usb/snps,dwc3.yaml | 15 +++++++++++++-- 1 file changed, 13 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/usb/snps,dwc3.yaml b/Documentation/devicetree/bindings/usb/snps,dwc3.yaml index 41416fbd92aa..078fb7889593 100644 --- a/Documentation/devicetree/bindings/usb/snps,dwc3.yaml +++ b/Documentation/devicetree/bindings/usb/snps,dwc3.yaml @@ -289,10 +289,21 @@ properties: maximum: 16 tx-fifo-resize: - description: Determines if the FIFO *has* to be reallocated - deprecated: true + description: Determines if the TX fifos can be dynamically resized depending + on the number of IN endpoints used and if bursting is supported. This + may help improve bandwidth on platforms with higher system latencies, as + increased fifo space allows for the controller to prefetch data into its + internal memory. type: boolean + tx-fifo-max-num: + description: Specifies the max number of packets the txfifo resizing logic + can account for when higher endpoint bursting is used. (bMaxBurst > 6) The + higher the number, the more fifo space the txfifo resizing logic will + allocate for that endpoint. + $ref: /schemas/types.yaml#/definitions/uint8 + minimum: 3 + snps,incr-burst-type-adjustment: description: Value for INCR burst type of GSBUSCFG0 register, undefined length INCR -- cgit v1.2.3 From f35e0cc25280cb0063b0e4481f99268fbd872ff3 Mon Sep 17 00:00:00 2001 From: Baruch Siach Date: Tue, 6 Jul 2021 08:44:00 +0300 Subject: doc, af_xdp: Fix bind flags option typo Fix XDP_ZERO_COPY flag typo since it is actually named XDP_ZEROCOPY instead as per if_xdp.h uapi header. Signed-off-by: Baruch Siach Signed-off-by: Daniel Borkmann Acked-by: Magnus Karlsson Link: https://lore.kernel.org/bpf/1656fdf94704e9e735df0f8b97667d8f26dd098b.1625550240.git.baruch@tkos.co.il --- Documentation/networking/af_xdp.rst | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/networking/af_xdp.rst b/Documentation/networking/af_xdp.rst index 42576880aa4a..60b217b436be 100644 --- a/Documentation/networking/af_xdp.rst +++ b/Documentation/networking/af_xdp.rst @@ -243,8 +243,8 @@ Configuration Flags and Socket Options These are the various configuration flags that can be used to control and monitor the behavior of AF_XDP sockets. -XDP_COPY and XDP_ZERO_COPY bind flags -------------------------------------- +XDP_COPY and XDP_ZEROCOPY bind flags +------------------------------------ When you bind to a socket, the kernel will first try to use zero-copy copy. If zero-copy is not supported, it will fall back on using copy @@ -252,7 +252,7 @@ mode, i.e. copying all packets out to user space. But if you would like to force a certain mode, you can use the following flags. If you pass the XDP_COPY flag to the bind call, the kernel will force the socket into copy mode. If it cannot use copy mode, the bind call will -fail with an error. Conversely, the XDP_ZERO_COPY flag will force the +fail with an error. Conversely, the XDP_ZEROCOPY flag will force the socket into zero-copy mode or fail. XDP_SHARED_UMEM bind flag -- cgit v1.2.3 From a72fa6304342a3ad749955fd9007695f761e12d6 Mon Sep 17 00:00:00 2001 From: Daniel Latypov Date: Wed, 23 Jun 2021 13:17:21 -0700 Subject: Documentation: kunit: drop obsolete note about uml_abort for coverage Commit b6d5799b0b58 ("kunit: Add 'kunit_shutdown' option") changes KUnit to call kernel_halt() by default when done testing. This fixes the issue with not having .gcda files due to not calling atexit() handlers, and therefore we can stop recommending people manually tweak UML code. The need to use older versions of GCC (<=6) remains however, due to linktime issues, same as before. Note: There also might still be issues with .gcda files as well in newer versions. Signed-off-by: Daniel Latypov Reviewed-by: David Gow Reviewed-by: Brendan Higgins Signed-off-by: Shuah Khan --- Documentation/dev-tools/kunit/running_tips.rst | 14 +------------- 1 file changed, 1 insertion(+), 13 deletions(-) (limited to 'Documentation') diff --git a/Documentation/dev-tools/kunit/running_tips.rst b/Documentation/dev-tools/kunit/running_tips.rst index 7d99386cf94a..d1626d548fa5 100644 --- a/Documentation/dev-tools/kunit/running_tips.rst +++ b/Documentation/dev-tools/kunit/running_tips.rst @@ -86,19 +86,7 @@ Generating code coverage reports under UML .. note:: TODO(brendanhiggins@google.com): There are various issues with UML and versions of gcc 7 and up. You're likely to run into missing ``.gcda`` - files or compile errors. We know one `faulty GCC commit - `_ - but not how we'd go about getting this fixed. The compile errors still - need some investigation. - -.. note:: - TODO(brendanhiggins@google.com): for recent versions of Linux - (5.10-5.12, maybe earlier), there's a bug with gcov counters not being - flushed in UML. This translates to very low (<1%) reported coverage. This is - related to the above issue and can be worked around by replacing the - one call to ``uml_abort()`` (it's in ``os_dump_core()``) with a plain - ``exit()``. - + files or compile errors. This is different from the "normal" way of getting coverage information that is documented in Documentation/dev-tools/gcov.rst. -- cgit v1.2.3 From c625b4cc57d078b03fd8aa4d86c99d584a1782be Mon Sep 17 00:00:00 2001 From: Jan Kara Date: Mon, 10 May 2021 19:13:53 +0200 Subject: documentation: Sync file_operations members with reality Sync listing of struct file_operations members with the real one in fs.h. Reviewed-by: Darrick J. Wong Reviewed-by: Christoph Hellwig Signed-off-by: Jan Kara --- Documentation/filesystems/locking.rst | 15 +++++++++------ 1 file changed, 9 insertions(+), 6 deletions(-) (limited to 'Documentation') diff --git a/Documentation/filesystems/locking.rst b/Documentation/filesystems/locking.rst index 2183fd8cc350..cdf15492c699 100644 --- a/Documentation/filesystems/locking.rst +++ b/Documentation/filesystems/locking.rst @@ -506,6 +506,7 @@ prototypes:: ssize_t (*write) (struct file *, const char __user *, size_t, loff_t *); ssize_t (*read_iter) (struct kiocb *, struct iov_iter *); ssize_t (*write_iter) (struct kiocb *, struct iov_iter *); + int (*iopoll) (struct kiocb *kiocb, bool spin); int (*iterate) (struct file *, struct dir_context *); int (*iterate_shared) (struct file *, struct dir_context *); __poll_t (*poll) (struct file *, struct poll_table_struct *); @@ -518,12 +519,6 @@ prototypes:: int (*fsync) (struct file *, loff_t start, loff_t end, int datasync); int (*fasync) (int, struct file *, int); int (*lock) (struct file *, int, struct file_lock *); - ssize_t (*readv) (struct file *, const struct iovec *, unsigned long, - loff_t *); - ssize_t (*writev) (struct file *, const struct iovec *, unsigned long, - loff_t *); - ssize_t (*sendfile) (struct file *, loff_t *, size_t, read_actor_t, - void __user *); ssize_t (*sendpage) (struct file *, struct page *, int, size_t, loff_t *, int); unsigned long (*get_unmapped_area)(struct file *, unsigned long, @@ -536,6 +531,14 @@ prototypes:: size_t, unsigned int); int (*setlease)(struct file *, long, struct file_lock **, void **); long (*fallocate)(struct file *, int, loff_t, loff_t); + void (*show_fdinfo)(struct seq_file *m, struct file *f); + unsigned (*mmap_capabilities)(struct file *); + ssize_t (*copy_file_range)(struct file *, loff_t, struct file *, + loff_t, size_t, unsigned int); + loff_t (*remap_file_range)(struct file *file_in, loff_t pos_in, + struct file *file_out, loff_t pos_out, + loff_t len, unsigned int remap_flags); + int (*fadvise)(struct file *, loff_t, loff_t, int); locking rules: All may block. -- cgit v1.2.3 From 730633f0b7f951726e87f912a6323641f674ae34 Mon Sep 17 00:00:00 2001 From: Jan Kara Date: Thu, 28 Jan 2021 19:19:45 +0100 Subject: mm: Protect operations adding pages to page cache with invalidate_lock Currently, serializing operations such as page fault, read, or readahead against hole punching is rather difficult. The basic race scheme is like: fallocate(FALLOC_FL_PUNCH_HOLE) read / fault / .. truncate_inode_pages_range() Now the problem is in this way read / page fault / readahead can instantiate pages in page cache with potentially stale data (if blocks get quickly reused). Avoiding this race is not simple - page locks do not work because we want to make sure there are *no* pages in given range. inode->i_rwsem does not work because page fault happens under mmap_sem which ranks below inode->i_rwsem. Also using it for reads makes the performance for mixed read-write workloads suffer. So create a new rw_semaphore in the address_space - invalidate_lock - that protects adding of pages to page cache for page faults / reads / readahead. Reviewed-by: Darrick J. Wong Reviewed-by: Christoph Hellwig Signed-off-by: Jan Kara --- Documentation/filesystems/locking.rst | 62 ++++++++++++++++++++++++----------- 1 file changed, 43 insertions(+), 19 deletions(-) (limited to 'Documentation') diff --git a/Documentation/filesystems/locking.rst b/Documentation/filesystems/locking.rst index cdf15492c699..38a3097b6f1c 100644 --- a/Documentation/filesystems/locking.rst +++ b/Documentation/filesystems/locking.rst @@ -271,19 +271,19 @@ prototypes:: locking rules: All except set_page_dirty and freepage may block -====================== ======================== ========= -ops PageLocked(page) i_rwsem -====================== ======================== ========= +====================== ======================== ========= =============== +ops PageLocked(page) i_rwsem invalidate_lock +====================== ======================== ========= =============== writepage: yes, unlocks (see below) -readpage: yes, unlocks +readpage: yes, unlocks shared writepages: set_page_dirty no -readahead: yes, unlocks -readpages: no +readahead: yes, unlocks shared +readpages: no shared write_begin: locks the page exclusive write_end: yes, unlocks exclusive bmap: -invalidatepage: yes +invalidatepage: yes exclusive releasepage: yes freepage: yes direct_IO: @@ -378,7 +378,10 @@ keep it that way and don't breed new callers. ->invalidatepage() is called when the filesystem must attempt to drop some or all of the buffers from the page when it is being truncated. It returns zero on success. If ->invalidatepage is zero, the kernel uses -block_invalidatepage() instead. +block_invalidatepage() instead. The filesystem must exclusively acquire +invalidate_lock before invalidating page cache in truncate / hole punch path +(and thus calling into ->invalidatepage) to block races between page cache +invalidation and page cache filling functions (fault, read, ...). ->releasepage() is called when the kernel is about to try to drop the buffers from the page in preparation for freeing it. It returns zero to @@ -573,6 +576,25 @@ in sys_read() and friends. the lease within the individual filesystem to record the result of the operation +->fallocate implementation must be really careful to maintain page cache +consistency when punching holes or performing other operations that invalidate +page cache contents. Usually the filesystem needs to call +truncate_inode_pages_range() to invalidate relevant range of the page cache. +However the filesystem usually also needs to update its internal (and on disk) +view of file offset -> disk block mapping. Until this update is finished, the +filesystem needs to block page faults and reads from reloading now-stale page +cache contents from the disk. Since VFS acquires mapping->invalidate_lock in +shared mode when loading pages from disk (filemap_fault(), filemap_read(), +readahead paths), the fallocate implementation must take the invalidate_lock to +prevent reloading. + +->copy_file_range and ->remap_file_range implementations need to serialize +against modifications of file data while the operation is running. For +blocking changes through write(2) and similar operations inode->i_rwsem can be +used. To block changes to file contents via a memory mapping during the +operation, the filesystem must take mapping->invalidate_lock to coordinate +with ->page_mkwrite. + dquot_operations ================ @@ -630,11 +652,11 @@ pfn_mkwrite: yes access: yes ============= ========= =========================== -->fault() is called when a previously not present pte is about -to be faulted in. The filesystem must find and return the page associated -with the passed in "pgoff" in the vm_fault structure. If it is possible that -the page may be truncated and/or invalidated, then the filesystem must lock -the page, then ensure it is not already truncated (the page lock will block +->fault() is called when a previously not present pte is about to be faulted +in. The filesystem must find and return the page associated with the passed in +"pgoff" in the vm_fault structure. If it is possible that the page may be +truncated and/or invalidated, then the filesystem must lock invalidate_lock, +then ensure the page is not already truncated (invalidate_lock will block subsequent truncate), and then return with VM_FAULT_LOCKED, and the page locked. The VM will unlock the page. @@ -647,12 +669,14 @@ page table entry. Pointer to entry associated with the page is passed in "pte" field in vm_fault structure. Pointers to entries for other offsets should be calculated relative to "pte". -->page_mkwrite() is called when a previously read-only pte is -about to become writeable. The filesystem again must ensure that there are -no truncate/invalidate races, and then return with the page locked. If -the page has been truncated, the filesystem should not look up a new page -like the ->fault() handler, but simply return with VM_FAULT_NOPAGE, which -will cause the VM to retry the fault. +->page_mkwrite() is called when a previously read-only pte is about to become +writeable. The filesystem again must ensure that there are no +truncate/invalidate races or races with operations such as ->remap_file_range +or ->copy_file_range, and then return with the page locked. Usually +mapping->invalidate_lock is suitable for proper serialization. If the page has +been truncated, the filesystem should not look up a new page like the ->fault() +handler, but simply return with VM_FAULT_NOPAGE, which will cause the VM to +retry the fault. ->pfn_mkwrite() is the same as page_mkwrite but when the pte is VM_PFNMAP or VM_MIXEDMAP with a page-less entry. Expected return is -- cgit v1.2.3 From 8480a727ae7b8bee7c11ea4a515e37c93ea677ef Mon Sep 17 00:00:00 2001 From: Marek Vasut Date: Sun, 20 Jun 2021 23:07:41 +0200 Subject: dt-bindings: net: ks8851: Convert to YAML schema Convert the Micrel KSZ8851 DT bindings to YAML schema. Signed-off-by: Marek Vasut Cc: Andrew Lunn Cc: David S. Miller Cc: Lukas Wunner Cc: Petr Stetiar Cc: Rob Herring Cc: linux@dh-electronics.com Cc: netdev@vger.kernel.org To: devicetree@vger.kernel.org Link: https://lore.kernel.org/r/20210620210741.100206-1-marex@denx.de Signed-off-by: Rob Herring --- .../devicetree/bindings/net/micrel,ks8851.yaml | 96 ++++++++++++++++++++++ .../devicetree/bindings/net/micrel-ks8851.txt | 18 ---- 2 files changed, 96 insertions(+), 18 deletions(-) create mode 100644 Documentation/devicetree/bindings/net/micrel,ks8851.yaml delete mode 100644 Documentation/devicetree/bindings/net/micrel-ks8851.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/micrel,ks8851.yaml b/Documentation/devicetree/bindings/net/micrel,ks8851.yaml new file mode 100644 index 000000000000..5aa7cf2eacb1 --- /dev/null +++ b/Documentation/devicetree/bindings/net/micrel,ks8851.yaml @@ -0,0 +1,96 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/micrel,ks8851.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Micrel KS8851 Ethernet MAC (SPI and Parallel bus options) + +maintainers: + - Marek Vasut + +properties: + compatible: + enum: + - micrel,ks8851 # SPI bus option + - micrel,ks8851-mll # Parallel bus option + + interrupts: + maxItems: 1 + + reg: + minItems: 1 + items: + - description: SPI or Parallel bus hardware address + - description: Parallel bus command mode address + + reset-gpios: + maxItems: 1 + description: + The reset_n input pin + + vdd-supply: + description: | + Analog 3.3V supply for Ethernet MAC + + vdd-io-supply: + description: | + Digital 1.8V IO supply for Ethernet MAC + +required: + - compatible + - reg + - interrupts + +allOf: + - $ref: ethernet-controller.yaml# + - if: + properties: + compatible: + contains: + const: micrel,ks8851 + then: + properties: + reg: + maxItems: 1 + - if: + properties: + compatible: + contains: + const: micrel,ks8851-mll + then: + properties: + reg: + minItems: 2 + +unevaluatedProperties: false + +examples: + - | + /* SPI bus option */ + spi { + #address-cells = <1>; + #size-cells = <0>; + ethernet@0 { + compatible = "micrel,ks8851"; + reg = <0>; + interrupt-parent = <&msmgpio>; + interrupts = <90 8>; + vdd-supply = <&ext_l2>; + vdd-io-supply = <&pm8921_lvs6>; + reset-gpios = <&msmgpio 89 0>; + }; + }; + - | + #include + /* Parallel bus option */ + memory-controller { + #address-cells = <2>; + #size-cells = <1>; + ethernet@1,0 { + compatible = "micrel,ks8851-mll"; + reg = <1 0x0 0x2>, <1 0x2 0x20000>; + interrupt-parent = <&gpioc>; + interrupts = <3 IRQ_TYPE_LEVEL_LOW>; + }; + }; diff --git a/Documentation/devicetree/bindings/net/micrel-ks8851.txt b/Documentation/devicetree/bindings/net/micrel-ks8851.txt deleted file mode 100644 index bbdf9a7359a2..000000000000 --- a/Documentation/devicetree/bindings/net/micrel-ks8851.txt +++ /dev/null @@ -1,18 +0,0 @@ -Micrel KS8851 Ethernet mac (MLL) - -Required properties: -- compatible = "micrel,ks8851-mll" of parallel interface -- reg : 2 physical address and size of registers for data and command -- interrupts : interrupt connection - -Micrel KS8851 Ethernet mac (SPI) - -Required properties: -- compatible = "micrel,ks8851" or the deprecated "ks8851" -- reg : chip select number -- interrupts : interrupt connection - -Optional properties: -- vdd-supply: analog 3.3V supply for Ethernet mac -- vdd-io-supply: digital 1.8V IO supply for Ethernet mac -- reset-gpios: reset_n input pin -- cgit v1.2.3 From fac4e24dcc56b59cfc5f0cbd559a89adc0fc63bf Mon Sep 17 00:00:00 2001 From: Marek Vasut Date: Mon, 21 Jun 2021 00:50:28 +0200 Subject: dt-bindings: mxsfb: Add compatible for i.MX8MN NXP's i.MX8MN has an LCDIF as well. Signed-off-by: Marek Vasut Cc: Fabio Estevam Cc: Lucas Stach Cc: NXP Linux Team Cc: Rob Herring Cc: Shawn Guo Reviewed-by: Lucas Stach Link: https://lore.kernel.org/r/20210620225028.189637-1-marex@denx.de Signed-off-by: Rob Herring --- Documentation/devicetree/bindings/display/fsl,lcdif.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/fsl,lcdif.yaml b/Documentation/devicetree/bindings/display/fsl,lcdif.yaml index a4c3064c778c..900a56cae80e 100644 --- a/Documentation/devicetree/bindings/display/fsl,lcdif.yaml +++ b/Documentation/devicetree/bindings/display/fsl,lcdif.yaml @@ -27,6 +27,7 @@ properties: - fsl,imx6ul-lcdif - fsl,imx7d-lcdif - fsl,imx8mm-lcdif + - fsl,imx8mn-lcdif - fsl,imx8mq-lcdif - const: fsl,imx6sx-lcdif -- cgit v1.2.3 From 07c6b5933ebf58b6132aea9f3e72a62486882bfb Mon Sep 17 00:00:00 2001 From: Daeho Jeong Date: Fri, 9 Jul 2021 22:53:57 -0700 Subject: f2fs: add sysfs nodes to get GC info for each GC mode Added gc_reclaimed_segments and gc_segment_mode sysfs nodes. 1) "gc_reclaimed_segments" shows how many segments have been reclaimed by GC during a specific GC mode. 2) "gc_segment_mode" is used to control for which gc mode the "gc_reclaimed_segments" node shows. Signed-off-by: Daeho Jeong Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim --- Documentation/ABI/testing/sysfs-fs-f2fs | 14 ++++++++++++++ 1 file changed, 14 insertions(+) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-fs-f2fs b/Documentation/ABI/testing/sysfs-fs-f2fs index ef4b9218ae1e..845c4be535b0 100644 --- a/Documentation/ABI/testing/sysfs-fs-f2fs +++ b/Documentation/ABI/testing/sysfs-fs-f2fs @@ -493,3 +493,17 @@ Contact: "Chao Yu" Description: When ATGC is on, it controls age threshold to bypass GCing young candidates whose age is not beyond the threshold, by default it was initialized as 604800 seconds (equals to 7 days). + +What: /sys/fs/f2fs//gc_reclaimed_segments +Date: July 2021 +Contact: "Daeho Jeong" +Description: Show how many segments have been reclaimed by GC during a specific + GC mode (0: GC normal, 1: GC idle CB, 2: GC idle greedy, + 3: GC idle AT, 4: GC urgent high, 5: GC urgent low) + You can re-initialize this value to "0". + +What: /sys/fs/f2fs//gc_segment_mode +Date: July 2021 +Contact: "Daeho Jeong" +Description: You can control for which gc mode the "gc_reclaimed_segments" node shows. + Refer to the description of the modes in "gc_reclaimed_segments". -- cgit v1.2.3 From b12fe999545cf3fd89e1a178ee4e541a9331da82 Mon Sep 17 00:00:00 2001 From: Claire Chang Date: Sat, 19 Jun 2021 11:40:42 +0800 Subject: dt-bindings: of: Add restricted DMA pool Introduce the new compatible string, restricted-dma-pool, for restricted DMA. One can specify the address and length of the restricted DMA memory region by restricted-dma-pool in the reserved-memory node. Signed-off-by: Claire Chang Tested-by: Stefano Stabellini Tested-by: Will Deacon Signed-off-by: Konrad Rzeszutek Wilk --- .../bindings/reserved-memory/reserved-memory.txt | 36 ++++++++++++++++++++-- 1 file changed, 33 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt b/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt index e8d3096d922c..39b5f4c5a511 100644 --- a/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt +++ b/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt @@ -51,6 +51,23 @@ compatible (optional) - standard definition used as a shared pool of DMA buffers for a set of devices. It can be used by an operating system to instantiate the necessary pool management subsystem if necessary. + - restricted-dma-pool: This indicates a region of memory meant to be + used as a pool of restricted DMA buffers for a set of devices. The + memory region would be the only region accessible to those devices. + When using this, the no-map and reusable properties must not be set, + so the operating system can create a virtual mapping that will be used + for synchronization. The main purpose for restricted DMA is to + mitigate the lack of DMA access control on systems without an IOMMU, + which could result in the DMA accessing the system memory at + unexpected times and/or unexpected addresses, possibly leading to data + leakage or corruption. The feature on its own provides a basic level + of protection against the DMA overwriting buffer contents at + unexpected times. However, to protect against general data leakage and + system memory corruption, the system needs to provide way to lock down + the memory access, e.g., MPU. Note that since coherent allocation + needs remapping, one must set up another device coherent pool by + shared-dma-pool and use dma_alloc_from_dev_coherent instead for atomic + coherent allocation. - vendor specific string in the form ,[-] no-map (optional) - empty property - Indicates the operating system must not create a virtual mapping @@ -85,10 +102,11 @@ memory-region-names (optional) - a list of names, one for each corresponding Example ------- -This example defines 3 contiguous regions are defined for Linux kernel: +This example defines 4 contiguous regions for Linux kernel: one default of all device drivers (named linux,cma@72000000 and 64MiB in size), -one dedicated to the framebuffer device (named framebuffer@78000000, 8MiB), and -one for multimedia processing (named multimedia-memory@77000000, 64MiB). +one dedicated to the framebuffer device (named framebuffer@78000000, 8MiB), +one for multimedia processing (named multimedia-memory@77000000, 64MiB), and +one for restricted dma pool (named restricted_dma_reserved@0x50000000, 64MiB). / { #address-cells = <1>; @@ -120,6 +138,11 @@ one for multimedia processing (named multimedia-memory@77000000, 64MiB). compatible = "acme,multimedia-memory"; reg = <0x77000000 0x4000000>; }; + + restricted_dma_reserved: restricted_dma_reserved { + compatible = "restricted-dma-pool"; + reg = <0x50000000 0x4000000>; + }; }; /* ... */ @@ -138,4 +161,11 @@ one for multimedia processing (named multimedia-memory@77000000, 64MiB). memory-region = <&multimedia_reserved>; /* ... */ }; + + pcie_device: pcie_device@0,0 { + reg = <0x83010000 0x0 0x00000000 0x0 0x00100000 + 0x83010000 0x0 0x00100000 0x0 0x00100000>; + memory-region = <&restricted_dma_reserved>; + /* ... */ + }; }; -- cgit v1.2.3 From 204d1a747636403fb0d9859eb4fdae2117f0545a Mon Sep 17 00:00:00 2001 From: Lucas Stach Date: Mon, 14 Jun 2021 19:06:29 +0200 Subject: dt-bindings: arm: fsl: add Nitrogen8 SoM Add compatible for the BoundaryDevices Nitrogen8 system on module. Signed-off-by: Lucas Stach Acked-by: Rob Herring Signed-off-by: Shawn Guo --- Documentation/devicetree/bindings/arm/fsl.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml index 1c827c1954dc..6179484c2489 100644 --- a/Documentation/devicetree/bindings/arm/fsl.yaml +++ b/Documentation/devicetree/bindings/arm/fsl.yaml @@ -752,6 +752,7 @@ properties: items: - enum: - boundary,imx8mq-nitrogen8m # i.MX8MQ NITROGEN Board + - boundary,imx8mq-nitrogen8m-som # i.MX8MQ NITROGEN SoM - einfochips,imx8mq-thor96 # i.MX8MQ Thor96 Board - fsl,imx8mq-evk # i.MX8MQ EVK Board - google,imx8mq-phanbell # Google Coral Edge TPU -- cgit v1.2.3 From 26d816652c92edc8d7dfc881e43a693db81bab37 Mon Sep 17 00:00:00 2001 From: Lucas Stach Date: Mon, 14 Jun 2021 19:06:31 +0200 Subject: dt-bindings: vendor-prefixes: add mntre MNT Research GmbH develops open source hardware, software and textiles in Berlin, Germany. Signed-off-by: Lucas Stach Acked-by: Rob Herring Signed-off-by: Shawn Guo --- Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index 07fb0d25fc15..62cb1d9341f5 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -735,6 +735,8 @@ patternProperties: description: MiraMEMS Sensing Technology Co., Ltd. "^mitsubishi,.*": description: Mitsubishi Electric Corporation + "^mntre,.*": + description: MNT Research GmbH "^modtronix,.*": description: Modtronix Engineering "^mosaixtech,.*": -- cgit v1.2.3 From ec1e7fc7721806250731b8168f8abc247c065e4d Mon Sep 17 00:00:00 2001 From: Lucas Stach Date: Wed, 14 Jul 2021 12:11:14 +0800 Subject: dt-bindings: arm: fsl: add MNT Reform2 board Add compatible for the MNT Reform2 laptop board. Signed-off-by: Lucas Stach Acked-by: Rob Herring Signed-off-by: Shawn Guo --- Documentation/devicetree/bindings/arm/fsl.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml index 6179484c2489..97f56ede2a3f 100644 --- a/Documentation/devicetree/bindings/arm/fsl.yaml +++ b/Documentation/devicetree/bindings/arm/fsl.yaml @@ -757,6 +757,7 @@ properties: - fsl,imx8mq-evk # i.MX8MQ EVK Board - google,imx8mq-phanbell # Google Coral Edge TPU - kontron,pitx-imx8m # Kontron pITX-imx8m Board + - mntre,reform2 # MNT Reform2 Laptop - purism,librem5-devkit # Purism Librem5 devkit - solidrun,hummingboard-pulse # SolidRun Hummingboard Pulse - technexion,pico-pi-imx8m # TechNexion PICO-PI-8M evk -- cgit v1.2.3 From e753a64bee753136087dfd70b37fdd199e942ea9 Mon Sep 17 00:00:00 2001 From: Dave Jiang Date: Thu, 3 Jun 2021 14:57:35 -0700 Subject: dmaengine: idxd: Add wq occupancy information to sysfs attribute Add occupancy information to wq sysfs attribute. Attribute will show wq occupancy data if "WQ Occupancy Support" field in WQCAP is 1. It displays the number of entries currently in this WQ. This is provided as an estimate and should not be relied on to determine whether there is space in the WQ. The data is to provide information to user apps for flow control. Signed-off-by: Dave Jiang Link: https://lore.kernel.org/r/162275745546.1857062.8765615879420582018.stgit@djiang5-desk3.ch.intel.com Signed-off-by: Vinod Koul --- Documentation/ABI/stable/sysfs-driver-dma-idxd | 7 +++++++ 1 file changed, 7 insertions(+) (limited to 'Documentation') diff --git a/Documentation/ABI/stable/sysfs-driver-dma-idxd b/Documentation/ABI/stable/sysfs-driver-dma-idxd index d431e2d00472..adb0c93e8dfc 100644 --- a/Documentation/ABI/stable/sysfs-driver-dma-idxd +++ b/Documentation/ABI/stable/sysfs-driver-dma-idxd @@ -211,6 +211,13 @@ Contact: dmaengine@vger.kernel.org Description: Indicate whether ATS disable is turned on for the workqueue. 0 indicates ATS is on, and 1 indicates ATS is off for the workqueue. +What: /sys/bus/dsa/devices/wq./occupancy +Date May 25, 2021 +KernelVersion: 5.14.0 +Contact: dmaengine@vger.kernel.org +Description: Show the current number of entries in this WQ if WQ Occupancy + Support bit WQ capabilities is 1. + What: /sys/bus/dsa/devices/engine./group_id Date: Oct 25, 2019 KernelVersion: 5.6.0 -- cgit v1.2.3 From 718226469d2300b5c6252fdc72a1415b17568d5f Mon Sep 17 00:00:00 2001 From: Mirela Rabulea Date: Sat, 19 Jun 2021 17:36:10 +0300 Subject: dt-bindings: media: imx-jpeg: Add compatible for i.MX8QM JPEG codec Add two more compatibles: "nxp,imx8qm-jpgdec" and " nxp,imx8qm-jpgenc". Also update the compatible property to ensure mutually exclusive usage of encoder and decoder compatibles. Update examples. Signed-off-by: Mirela Rabulea Reviewed-by: Dong Aisheng Reviewed-by: Rob Herring Signed-off-by: Shawn Guo --- .../devicetree/bindings/media/nxp,imx8-jpeg.yaml | 19 ++++++++++++------- 1 file changed, 12 insertions(+), 7 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/media/nxp,imx8-jpeg.yaml b/Documentation/devicetree/bindings/media/nxp,imx8-jpeg.yaml index 5d13cbb5251b..3cc6f42aeb76 100644 --- a/Documentation/devicetree/bindings/media/nxp,imx8-jpeg.yaml +++ b/Documentation/devicetree/bindings/media/nxp,imx8-jpeg.yaml @@ -16,12 +16,17 @@ description: |- properties: compatible: - items: - - enum: - # JPEG decoder - - nxp,imx8qxp-jpgdec - # JPEG encoder - - nxp,imx8qxp-jpgenc + oneOf: + - items: + enum: + - nxp,imx8qxp-jpgdec + - nxp,imx8qxp-jpgenc + - items: + - const: nxp,imx8qm-jpgdec + - const: nxp,imx8qxp-jpgdec + - items: + - const: nxp,imx8qm-jpgenc + - const: nxp,imx8qxp-jpgenc reg: maxItems: 1 @@ -69,7 +74,7 @@ examples: }; jpegenc: jpegenc@58450000 { - compatible = "nxp,imx8qxp-jpgenc"; + compatible = "nxp,imx8qm-jpgenc", "nxp,imx8qxp-jpgenc"; reg = <0x58450000 0x00050000 >; interrupts = , , -- cgit v1.2.3 From d7114b57685997668c4fb7a4d3829f4d6d707cc0 Mon Sep 17 00:00:00 2001 From: "Russell King (Oracle)" Date: Sat, 19 Jun 2021 16:55:26 +0100 Subject: dt-bindings: arm: fsl: add SolidSense boards Add SolidRun SolidSense boards. Signed-off-by: Russell King (Oracle) Acked-by: Rob Herring Signed-off-by: Shawn Guo --- Documentation/devicetree/bindings/arm/fsl.yaml | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml index 97f56ede2a3f..2793d161b24e 100644 --- a/Documentation/devicetree/bindings/arm/fsl.yaml +++ b/Documentation/devicetree/bindings/arm/fsl.yaml @@ -224,6 +224,7 @@ properties: - solidrun,cubox-i/q # SolidRun Cubox-i Dual/Quad - solidrun,hummingboard/q - solidrun,hummingboard2/q + - solidrun,solidsense/q # SolidRun SolidSense Dual/Quad - tbs,imx6q-tbs2910 # TBS2910 Matrix ARM mini PC - technexion,imx6q-pico-dwarf # TechNexion i.MX6Q Pico-Dwarf - technexion,imx6q-pico-hobbit # TechNexion i.MX6Q Pico-Hobbit @@ -380,6 +381,7 @@ properties: - solidrun,cubox-i/dl # SolidRun Cubox-i Solo/DualLite - solidrun,hummingboard/dl - solidrun,hummingboard2/dl # SolidRun HummingBoard2 Solo/DualLite + - solidrun,solidsense/dl # SolidRun SolidSense Solo/DualLite - technexion,imx6dl-pico-dwarf # TechNexion i.MX6DL Pico-Dwarf - technexion,imx6dl-pico-hobbit # TechNexion i.MX6DL Pico-Hobbit - technexion,imx6dl-pico-nymph # TechNexion i.MX6DL Pico-Nymph -- cgit v1.2.3 From e98fb032170bfa2e671a01e356a7ee86a2038312 Mon Sep 17 00:00:00 2001 From: ChiYuan Huang Date: Wed, 14 Jul 2021 10:25:32 +0800 Subject: regulator: rtq6752: Refine binding document Drop regulators property reference and remove the status in example dts. Signed-off-by: ChiYuan Huang Link: https://lore.kernel.org/r/1626229532-13037-1-git-send-email-u0084500@gmail.com Signed-off-by: Mark Brown --- .../devicetree/bindings/regulator/richtek,rtq6752-regulator.yaml | 2 -- 1 file changed, 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/regulator/richtek,rtq6752-regulator.yaml b/Documentation/devicetree/bindings/regulator/richtek,rtq6752-regulator.yaml index 641840ea7c16..e6e5a9a7d940 100644 --- a/Documentation/devicetree/bindings/regulator/richtek,rtq6752-regulator.yaml +++ b/Documentation/devicetree/bindings/regulator/richtek,rtq6752-regulator.yaml @@ -30,7 +30,6 @@ properties: regulators: type: object - $ref: regulator.yaml# patternProperties: "^(p|n)avdd$": @@ -56,7 +55,6 @@ examples: rtq6752@6b { compatible = "richtek,rtq6752"; - status = "okay"; reg = <0x6b>; enable-gpios = <&gpio26 2 0>; -- cgit v1.2.3 From 014861c2fb3d7b38b8de32baa953082bb9dabaf4 Mon Sep 17 00:00:00 2001 From: Aswath Govindraju Date: Mon, 21 Jun 2021 14:58:58 +0530 Subject: spi: omap-spi: Convert to json-schema Convert omap-spi dt-binding documentation from txt to yaml format. Signed-off-by: Aswath Govindraju Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20210621092900.951-1-a-govindraju@ti.com Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/spi/omap-spi.txt | 48 --------- .../devicetree/bindings/spi/omap-spi.yaml | 117 +++++++++++++++++++++ 2 files changed, 117 insertions(+), 48 deletions(-) delete mode 100644 Documentation/devicetree/bindings/spi/omap-spi.txt create mode 100644 Documentation/devicetree/bindings/spi/omap-spi.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/spi/omap-spi.txt b/Documentation/devicetree/bindings/spi/omap-spi.txt deleted file mode 100644 index 487208c256c0..000000000000 --- a/Documentation/devicetree/bindings/spi/omap-spi.txt +++ /dev/null @@ -1,48 +0,0 @@ -OMAP2+ McSPI device - -Required properties: -- compatible : - - "ti,am654-mcspi" for AM654. - - "ti,omap2-mcspi" for OMAP2 & OMAP3. - - "ti,omap4-mcspi" for OMAP4+. -- ti,spi-num-cs : Number of chipselect supported by the instance. -- ti,hwmods: Name of the hwmod associated to the McSPI -- ti,pindir-d0-out-d1-in: Select the D0 pin as output and D1 as - input. The default is D0 as input and - D1 as output. - -Optional properties: -- dmas: List of DMA specifiers with the controller specific format - as described in the generic DMA client binding. A tx and rx - specifier is required for each chip select. -- dma-names: List of DMA request names. These strings correspond - 1:1 with the DMA specifiers listed in dmas. The string naming - is to be "rxN" and "txN" for RX and TX requests, - respectively, where N equals the chip select number. - -Examples: - -[hwmod populated DMA resources] - -mcspi1: mcspi@1 { - #address-cells = <1>; - #size-cells = <0>; - compatible = "ti,omap4-mcspi"; - ti,hwmods = "mcspi1"; - ti,spi-num-cs = <4>; -}; - -[generic DMA request binding] - -mcspi1: mcspi@1 { - #address-cells = <1>; - #size-cells = <0>; - compatible = "ti,omap4-mcspi"; - ti,hwmods = "mcspi1"; - ti,spi-num-cs = <2>; - dmas = <&edma 42 - &edma 43 - &edma 44 - &edma 45>; - dma-names = "tx0", "rx0", "tx1", "rx1"; -}; diff --git a/Documentation/devicetree/bindings/spi/omap-spi.yaml b/Documentation/devicetree/bindings/spi/omap-spi.yaml new file mode 100644 index 000000000000..e55538186cf6 --- /dev/null +++ b/Documentation/devicetree/bindings/spi/omap-spi.yaml @@ -0,0 +1,117 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/spi/omap-spi.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: SPI controller bindings for OMAP and K3 SoCs + +maintainers: + - Aswath Govindraju + +allOf: + - $ref: spi-controller.yaml# + +properties: + compatible: + oneOf: + - items: + - enum: + - ti,am654-mcspi + - ti,am4372-mcspi + - const: ti,omap4-mcspi + - items: + - enum: + - ti,omap2-mcspi + - ti,omap4-mcspi + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + + power-domains: + maxItems: 1 + + ti,spi-num-cs: + $ref: /schemas/types.yaml#/definitions/uint32 + description: Number of chipselect supported by the instance. + minimum: 1 + maximum: 4 + + ti,hwmods: + $ref: /schemas/types.yaml#/definitions/string + description: + Must be "mcspi", n being the instance number (1-based). + This property is applicable only on legacy platforms mainly omap2/3 + and ti81xx and should not be used on other platforms. + deprecated: true + + ti,pindir-d0-out-d1-in: + description: + Select the D0 pin as output and D1 as input. The default is D0 + as input and D1 as output. + type: boolean + + dmas: + description: + List of DMA specifiers with the controller specific format as + described in the generic DMA client binding. A tx and rx + specifier is required for each chip select. + minItems: 1 + maxItems: 8 + + dma-names: + description: + List of DMA request names. These strings correspond 1:1 with + the DMA sepecifiers listed in dmas. The string names is to be + "rxN" and "txN" for RX and TX requests, respectively. Where N + is the chip select number. + minItems: 1 + maxItems: 8 + +required: + - compatible + - reg + - interrupts + +unevaluatedProperties: false + +if: + properties: + compatible: + oneOf: + - const: ti,omap2-mcspi + - const: ti,omap4-mcspi + +then: + properties: + ti,hwmods: + items: + - pattern: "^mcspi([1-9])$" + +else: + properties: + ti,hwmods: false + +examples: + - | + #include + #include + #include + + spi@2100000 { + compatible = "ti,am654-mcspi","ti,omap4-mcspi"; + reg = <0x2100000 0x400>; + interrupts = ; + clocks = <&k3_clks 137 1>; + power-domains = <&k3_pds 137 TI_SCI_PD_EXCLUSIVE>; + #address-cells = <1>; + #size-cells = <0>; + dmas = <&main_udmap 0xc500>, <&main_udmap 0x4500>; + dma-names = "tx0", "rx0"; + }; -- cgit v1.2.3 From 1333adfcc3cbfabb68f6cf6f2baffd89ad012330 Mon Sep 17 00:00:00 2001 From: Paul Cercueil Date: Fri, 25 Jun 2021 13:10:44 +0100 Subject: dt-bindings: display/panel: Add Innolux EJ030NA Add binding for the Innolux EJ030NA panel, which is a 320x480 3.0" 4:3 24-bit TFT LCD panel with non-square pixels and a delta-RGB 8-bit interface. Signed-off-by: Paul Cercueil Reviewed-by: Sam Ravnborg Reviewed-by: Rob Herring Link: https://patchwork.freedesktop.org/patch/msgid/20210625121045.81711-1-paul@crapouillou.net --- .../bindings/display/panel/innolux,ej030na.yaml | 62 ++++++++++++++++++++++ 1 file changed, 62 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/panel/innolux,ej030na.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/panel/innolux,ej030na.yaml b/Documentation/devicetree/bindings/display/panel/innolux,ej030na.yaml new file mode 100644 index 000000000000..cda36c04e85c --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/innolux,ej030na.yaml @@ -0,0 +1,62 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/panel/innolux,ej030na.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Innolux EJ030NA 3.0" (320x480 pixels) 24-bit TFT LCD panel + +description: | + The panel must obey the rules for a SPI slave device as specified in + spi/spi-controller.yaml + +maintainers: + - Paul Cercueil + +allOf: + - $ref: panel-common.yaml# + +properties: + compatible: + const: innolux,ej030na + + backlight: true + port: true + power-supply: true + reg: true + reset-gpios: true + +required: + - compatible + - reg + - power-supply + - reset-gpios + +unevaluatedProperties: false + +examples: + - | + #include + + spi { + #address-cells = <1>; + #size-cells = <0>; + + panel@0 { + compatible = "innolux,ej030na"; + reg = <0>; + + spi-max-frequency = <10000000>; + + reset-gpios = <&gpe 4 GPIO_ACTIVE_LOW>; + power-supply = <&lcd_power>; + + backlight = <&backlight>; + + port { + panel_input: endpoint { + remote-endpoint = <&panel_output>; + }; + }; + }; + }; -- cgit v1.2.3 From 05f3485cad759b2d63c5625caef334de4c2cb57d Mon Sep 17 00:00:00 2001 From: Alex Bee Date: Thu, 27 May 2021 17:44:44 +0200 Subject: dt-bindings: mfd: syscon: add Rockchip RK3036/RK3228 qos compatibles Document Rockchip RK3036/RK3228 qos compatibles Signed-off-by: Alex Bee Reviewed-by: Heiko Stuebner Acked-by: Rob Herring Signed-off-by: Lee Jones --- Documentation/devicetree/bindings/mfd/syscon.yaml | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mfd/syscon.yaml b/Documentation/devicetree/bindings/mfd/syscon.yaml index f14ae6da0068..ad1121620e15 100644 --- a/Documentation/devicetree/bindings/mfd/syscon.yaml +++ b/Documentation/devicetree/bindings/mfd/syscon.yaml @@ -45,7 +45,9 @@ properties: - microchip,sparx5-cpu-syscon - mstar,msc313-pmsleep - rockchip,px30-qos + - rockchip,rk3036-qos - rockchip,rk3066-qos + - rockchip,rk3228-qos - rockchip,rk3288-qos - rockchip,rk3399-qos - samsung,exynos3-sysreg -- cgit v1.2.3 From f861d1d77a17e66b90be11c2575f6631879cebb1 Mon Sep 17 00:00:00 2001 From: Liang Chen Date: Thu, 24 Jun 2021 19:47:18 +0800 Subject: dt-bindings: mfd: syscon: Add rk3568 QoS register compatible Document rk3568 compatible for QoS registers. Signed-off-by: Liang Chen Acked-by: Rob Herring Acked-by: Heiko Stuebner Signed-off-by: Lee Jones --- Documentation/devicetree/bindings/mfd/syscon.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mfd/syscon.yaml b/Documentation/devicetree/bindings/mfd/syscon.yaml index ad1121620e15..abe3fd817e0b 100644 --- a/Documentation/devicetree/bindings/mfd/syscon.yaml +++ b/Documentation/devicetree/bindings/mfd/syscon.yaml @@ -50,6 +50,7 @@ properties: - rockchip,rk3228-qos - rockchip,rk3288-qos - rockchip,rk3399-qos + - rockchip,rk3568-qos - samsung,exynos3-sysreg - samsung,exynos4-sysreg - samsung,exynos5-sysreg -- cgit v1.2.3 From 442a9d105e61591b36b653ba1ee0c02b0482b639 Mon Sep 17 00:00:00 2001 From: Kunihiko Hayashi Date: Wed, 23 Jun 2021 10:52:17 +0900 Subject: regulator: Convert UniPhier regulator to json-schema Convert the UniPhier regulator binding to DT schema format. Signed-off-by: Kunihiko Hayashi Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/1624413137-17453-1-git-send-email-hayashi.kunihiko@socionext.com Signed-off-by: Mark Brown --- .../regulator/socionext,uniphier-regulator.yaml | 85 ++++++++++++++++++++++ .../bindings/regulator/uniphier-regulator.txt | 58 --------------- 2 files changed, 85 insertions(+), 58 deletions(-) create mode 100644 Documentation/devicetree/bindings/regulator/socionext,uniphier-regulator.yaml delete mode 100644 Documentation/devicetree/bindings/regulator/uniphier-regulator.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/regulator/socionext,uniphier-regulator.yaml b/Documentation/devicetree/bindings/regulator/socionext,uniphier-regulator.yaml new file mode 100644 index 000000000000..861d5f3c79e8 --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/socionext,uniphier-regulator.yaml @@ -0,0 +1,85 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/regulator/socionext,uniphier-regulator.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Socionext UniPhier regulator controller + +description: | + This regulator controls VBUS and belongs to USB3 glue layer. Before using + the regulator, it is necessary to control the clocks and resets to enable + this layer. These clocks and resets should be described in each property. + +maintainers: + - Kunihiko Hayashi + +allOf: + - $ref: "regulator.yaml#" + +# USB3 Controller + +properties: + compatible: + enum: + - socionext,uniphier-pro4-usb3-regulator + - socionext,uniphier-pro5-usb3-regulator + - socionext,uniphier-pxs2-usb3-regulator + - socionext,uniphier-ld20-usb3-regulator + - socionext,uniphier-pxs3-usb3-regulator + + reg: + maxItems: 1 + + clocks: + minItems: 1 + maxItems: 2 + + clock-names: + oneOf: + - items: # for Pro4, Pro5 + - const: gio + - const: link + - items: # for others + - const: link + + resets: + minItems: 1 + maxItems: 2 + + reset-names: + oneOf: + - items: # for Pro4, Pro5 + - const: gio + - const: link + - items: + - const: link + +additionalProperties: false + +required: + - compatible + - reg + - clocks + - clock-names + - resets + - reset-names + +examples: + - | + usb-glue@65b00000 { + compatible = "simple-mfd"; + #address-cells = <1>; + #size-cells = <1>; + ranges = <0 0x65b00000 0x400>; + + usb_vbus0: regulators@100 { + compatible = "socionext,uniphier-ld20-usb3-regulator"; + reg = <0x100 0x10>; + clock-names = "link"; + clocks = <&sys_clk 14>; + reset-names = "link"; + resets = <&sys_rst 14>; + }; + }; + diff --git a/Documentation/devicetree/bindings/regulator/uniphier-regulator.txt b/Documentation/devicetree/bindings/regulator/uniphier-regulator.txt deleted file mode 100644 index 94fd38b0d163..000000000000 --- a/Documentation/devicetree/bindings/regulator/uniphier-regulator.txt +++ /dev/null @@ -1,58 +0,0 @@ -Socionext UniPhier Regulator Controller - -This describes the devicetree bindings for regulator controller implemented -on Socionext UniPhier SoCs. - -USB3 Controller ---------------- - -This regulator controls VBUS and belongs to USB3 glue layer. Before using -the regulator, it is necessary to control the clocks and resets to enable -this layer. These clocks and resets should be described in each property. - -Required properties: -- compatible: Should be - "socionext,uniphier-pro4-usb3-regulator" - for Pro4 SoC - "socionext,uniphier-pro5-usb3-regulator" - for Pro5 SoC - "socionext,uniphier-pxs2-usb3-regulator" - for PXs2 SoC - "socionext,uniphier-ld20-usb3-regulator" - for LD20 SoC - "socionext,uniphier-pxs3-usb3-regulator" - for PXs3 SoC -- reg: Specifies offset and length of the register set for the device. -- clocks: A list of phandles to the clock gate for USB3 glue layer. - According to the clock-names, appropriate clocks are required. -- clock-names: Should contain - "gio", "link" - for Pro4 and Pro5 SoCs - "link" - for others -- resets: A list of phandles to the reset control for USB3 glue layer. - According to the reset-names, appropriate resets are required. -- reset-names: Should contain - "gio", "link" - for Pro4 and Pro5 SoCs - "link" - for others - -See Documentation/devicetree/bindings/regulator/regulator.txt -for more details about the regulator properties. - -Example: - - usb-glue@65b00000 { - compatible = "socionext,uniphier-ld20-dwc3-glue", - "simple-mfd"; - #address-cells = <1>; - #size-cells = <1>; - ranges = <0 0x65b00000 0x400>; - - usb_vbus0: regulators@100 { - compatible = "socionext,uniphier-ld20-usb3-regulator"; - reg = <0x100 0x10>; - clock-names = "link"; - clocks = <&sys_clk 14>; - reset-names = "link"; - resets = <&sys_rst 14>; - }; - - phy { - ... - phy-supply = <&usb_vbus0>; - }; - ... - }; -- cgit v1.2.3 From e6c65d354fae36e5a3ccd9dca6cec05ea2e4473a Mon Sep 17 00:00:00 2001 From: Hu Haowen Date: Sun, 20 Jun 2021 13:28:43 +0800 Subject: docs/zh_CN: create new translations for zh_CN/dev-tools/testing-overview Create new translations for dev-tools/testing-overview.rst and link it to dev-tools/index.rst with TODOList modifications. Signed-off-by: Hu Haowen Reviewed-by: Wu XiangCheng Reviewed-by: Yanteng Si Signed-off-by: Wu XiangCheng Link: https://lore.kernel.org/r/20210620052841.GA22083@bobwxc.top Signed-off-by: Jonathan Corbet --- .../translations/zh_CN/dev-tools/index.rst | 5 + .../zh_CN/dev-tools/testing-overview.rst | 108 +++++++++++++++++++++ 2 files changed, 113 insertions(+) create mode 100644 Documentation/translations/zh_CN/dev-tools/testing-overview.rst (limited to 'Documentation') diff --git a/Documentation/translations/zh_CN/dev-tools/index.rst b/Documentation/translations/zh_CN/dev-tools/index.rst index e6c99f2f543f..0f770b8664e9 100644 --- a/Documentation/translations/zh_CN/dev-tools/index.rst +++ b/Documentation/translations/zh_CN/dev-tools/index.rst @@ -11,6 +11,9 @@ 目前这些文档已经整理在一起，不需要再花费额外的精力。 欢迎任何补丁。 +有关测试专用工具的简要概述，参见 +Documentation/translations/zh_CN/dev-tools/testing-overview.rst + .. class:: toc-title 目录 @@ -18,6 +21,7 @@ .. toctree:: :maxdepth: 2 + testing-overview gcov kasan @@ -29,6 +33,7 @@ Todolist: - ubsan - kmemleak - kcsan + - kfence - gdb-kernel-debugging - kgdb - kselftest diff --git a/Documentation/translations/zh_CN/dev-tools/testing-overview.rst b/Documentation/translations/zh_CN/dev-tools/testing-overview.rst new file mode 100644 index 000000000000..8206d5b477e2 --- /dev/null +++ b/Documentation/translations/zh_CN/dev-tools/testing-overview.rst @@ -0,0 +1,108 @@ +.. SPDX-License-Identifier: GPL-2.0 + +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/dev-tools/testing-overview.rst +:Translator: 胡皓文 Hu Haowen + +============ +内核测试指南 +============ + +有许多不同的工具可以用于测试Linux内核，因此了解什么时候使用它们可能 +很困难。本文档粗略概述了它们之间的区别，并阐释了它们是怎样糅合在一起 +的。 + +编写和运行测试 +============== + +大多数内核测试都是用kselftest或KUnit框架之一编写的。它们都让运行测试 +更加简化，并为编写新测试提供帮助。 + +如果你想验证内核的行为——尤其是内核的特定部分——那你就要使用kUnit或 +kselftest。 + +KUnit和kselftest的区别 +---------------------- + +.. note:: + 由于本文段中部分术语尚无较好的对应中文释义，可能导致与原文含义 + 存在些许差异，因此建议读者结合原文 + （Documentation/dev-tools/testing-overview.rst）辅助阅读。 + 如对部分翻译有异议或有更好的翻译意见，欢迎联系译者进行修订。 + +KUnit（Documentation/dev-tools/kunit/index.rst）是用于“白箱”测 +试的一个完整的内核内部系统：因为测试代码是内核的一部分，所以它能够访 +问用户空间不能访问到的内部结构和功能。 + +因此，KUnit测试最好针对内核中较小的、自包含的部分，以便能够独立地测 +试。“单元”测试的概念亦是如此。 + +比如，一个KUnit测试可能测试一个单独的内核功能（甚至通过一个函数测试 +一个单一的代码路径，例如一个错误处理案例），而不是整个地测试一个特性。 + +这也使得KUnit测试构建和运行非常地快，从而能够作为开发流程的一部分被 +频繁地运行。 + +有关更详细的介绍，请参阅KUnit测试代码风格指南 +Documentation/dev-tools/kunit/style.rst + +kselftest（Documentation/dev-tools/kselftest.rst），相对来说，大量用 +于用户空间，并且通常测试用户空间的脚本或程序。 + +这使得编写复杂的测试，或者需要操作更多全局系统状态的测试更加容易（诸 +如生成进程之类）。然而，从kselftest直接调用内核函数是不行的。这也就 +意味着只有通过某种方式（如系统调用、驱动设备、文件系统等）导出到了用 +户空间的内核功能才能使用kselftest来测试。为此，有些测试包含了一个伴 +生的内核模块用于导出更多的信息和功能。不过，对于基本上或者完全在内核 +中运行的测试，KUnit可能是更佳工具。 + +kselftest也因此非常适合于全部功能的测试，因为这些功能会将接口暴露到 +用户空间，从而能够被测试，而不是展现实现细节。“system”测试和 +“end-to-end”测试亦是如此。 + +比如，一个新的系统调用应该伴随有新的kselftest测试。 + +代码覆盖率工具 +============== + +支持两种不同代码之间的覆盖率测量工具。它们可以用来验证一项测试执行的 +确切函数或代码行。这有助于决定内核被测试了多少，或用来查找合适的测试 +中没有覆盖到的极端情况。 + +Documentation/translations/zh_CN/dev-tools/gcov.rst 是GCC的覆盖率测试工具，能用于获取内核的全局或每个模块的 +覆盖率。与KCOV不同的是，这个工具不记录每个任务的覆盖率。覆盖率数据可 +以通过debugfs读取，并通过常规的gcov工具进行解释。 + +Documentation/dev-tools/kcov.rst 是能够构建在内核之中，用于在每个任务的层面捕捉覆盖率的一 +个功能。因此，它对于模糊测试和关于代码执行期间信息的其它情况非常有用， +比如在一个单一系统调用里使用它就很有用。 + +动态分析工具 +============ + +内核也支持许多动态分析工具，用以检测正在运行的内核中出现的多种类型的 +问题。这些工具通常每个去寻找一类不同的缺陷，比如非法内存访问，数据竞 +争等并发问题，或整型溢出等其他未定义行为。 + +如下所示： + +* kmemleak检测可能的内存泄漏。参阅 + Documentation/dev-tools/kmemleak.rst +* KASAN检测非法内存访问，如数组越界和释放后重用（UAF）。参阅 + Documentation/dev-tools/kasan.rst +* UBSAN检测C标准中未定义的行为，如整型溢出。参阅 + Documentation/dev-tools/ubsan.rst +* KCSAN检测数据竞争。参阅 Documentation/dev-tools/kcsan.rst +* KFENCE是一个低开销的内存问题检测器，比KASAN更快且能被用于批量构建。 + 参阅 Documentation/dev-tools/kfence.rst +* lockdep是一个锁定正确性检测器。参阅 + Documentation/locking/lockdep-design.rst +* 除此以外，在内核中还有一些其它的调试工具，大多数能在 + lib/Kconfig.debug 中找到。 + +这些工具倾向于对内核进行整体测试，并且不像kselftest和KUnit一样“传递”。 +它们可以通过在启用这些工具时运行内核测试以与kselftest或KUnit结合起来： +之后你就能确保这些错误在测试过程中都不会发生了。 + +一些工具与KUnit和kselftest集成，并且在检测到问题时会自动打断测试。 -- cgit v1.2.3 From c767ef4519b3716d74a78e0bafad250b0c6e1783 Mon Sep 17 00:00:00 2001 From: Yanteng Si Date: Fri, 9 Jul 2021 11:01:43 +0800 Subject: docs/zh_CN: add core api genericirq translation translate Documentation/core-api/genericirq.rst into Chinese. Signed-off-by: Yanteng Si Reviewed-by: Wu XiangCheng Link: https://lore.kernel.org/r/20210709030143.548940-1-siyanteng@loongson.cn Signed-off-by: Jonathan Corbet --- .../translations/zh_CN/core-api/genericirq.rst | 409 +++++++++++++++++++++ .../translations/zh_CN/core-api/index.rst | 2 +- 2 files changed, 410 insertions(+), 1 deletion(-) create mode 100644 Documentation/translations/zh_CN/core-api/genericirq.rst (limited to 'Documentation') diff --git a/Documentation/translations/zh_CN/core-api/genericirq.rst b/Documentation/translations/zh_CN/core-api/genericirq.rst new file mode 100644 index 000000000000..05ccb954c18d --- /dev/null +++ b/Documentation/translations/zh_CN/core-api/genericirq.rst @@ -0,0 +1,409 @@ +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/core-api/genericirq.rst + +:翻译: + + 司延腾 Yanteng Si + +:校译: + + 吴想成 Wu XiangCheng + +.. include:: + +.. _cn_core-api_genericirq: + +================ +Linux通用IRQ处理 +================ + +:版权: |copy| 2005-2010: Thomas Gleixner +:版权: |copy| 2005-2006: Ingo Molnar + +简介 +==== + +通用中断处理层是为了给设备驱动程序提供一个完整的中断处理抽象（层）。它能够处 +理所有不同类型的中断控制器硬件。设备驱动程序使用通用API函数来请求、启用、禁 +用和释放中断。驱动程序不需要知道任何关于硬件处理中断的细节，所以它们可以在不同的 +平台上使用而不需要修改代码。 + +本文档提供给那些希望在通用IRQ处理层的帮助下实现基于其架构的中断子系统的开发 +者。 + +理论依据 +======== + +Linux中中断处理的原始实现使用__do_IRQ()超级处理程序，它能够处理每种类型的 +中断逻辑。 + +最初，Russell King确定了不同类型的处理程序，以便为Linux 2.5/2.6中的ARM中 +断处理程序实现建立一个相当通用的集合。他区分了以下几种类型: + +- 电平触发型 + +- 边沿触发型 + +- 简单型 + +在实现过程中，我们发现了另一种类型: + +- 响应EOI（end of interrupt）型 + +在SMP的__do_IRQ()超级处理程序中，还需定义一种类型： + +-  每cpu型（针对CPU SMP） + +这种高层IRQ处理程序的拆分实现使我们能够为每个特定的中断类型优化中断处理的流 +程。这减少了该特定代码路径的复杂性，并允许对特定类型进行优化处理。 + +最初的通用IRQ实现使用hw_interrupt_type结构体及其 ``->ack`` ``->end`` 等回 +调来区分超级处理程序中的流控制。这导致了流逻辑和低级硬件逻辑的混合，也导致了 +不必要的代码重复：例如i386中的 ``ioapic_level_irq`` 和 ``ioapic_edge_irq`` ， +这两个IRQ类型共享许多低级的细节，但有不同的流处理。 + +一个更自然的抽象是“irq流”和“芯片细节”的干净分离。 + +分析一些架构的IRQ子系统的实现可以发现，他们中的大多数可以使用一套通用的“irq +流”方法，只需要添加芯片级的特定代码。这种分离对于那些需要IRQ流本身而不需要芯 +片细节的特定（子）架构也很有价值——以提供了一个更透明的IRQ子系统设计。 + +每个中断描述符都被分配给它自己的高层流程处理程序，这通常是一个通用的实现。(这 +种高层次的流程处理程序的实现也使得提供解复用处理程序变得简单，这可以在各种架 +构的嵌入式平台上找到。) + +这种分离使得通用中断处理层更加灵活和可扩展。例如，一个（子）架构可以使用通用 +的IRQ流实现“电平触发型”中断，并添加一个（子）架构特定的“边沿型”实现。 + +为了使向新模型的过渡更容易，并防止破坏现有实现，__do_IRQ()超级处理程序仍然 +可用。这导致了一种暂时的双重性。随着时间的推移，新的模型应该在越来越多的架构中 +被使用，因为它能使IRQ子系统更小更干净。它已经被废弃三年了，即将被删除。 + +已知的缺陷和假设 +================ + +没有（但愿如此）。 + +抽象层 +====== + +中断代码中主要有三个抽象层次: + +1. 高级别的驱动API + +2. 高级别的IRQ流处理器 + +3. 芯片级的硬件封装 + +中断控制流 +---------- + +每个中断都由一个中断描述符结构体irq_desc来描述。中断是由一个“无符号整型”的数值来 +引用的，它在描述符结构体数组中选择相应的中断描述符结构体。描述符结构体包含状态 +信息和指向中断流方法和中断芯片结构的指针，这些都是分配给这个中断的。 + +每当中断触发时，低级架构代码通过调用desc->handle_irq()调用到通用中断代码中。 +这个高层IRQ处理函数只使用由分配的芯片描述符结构体引用的desc->irq_data.chip +基元。 + +高级驱动程序API +--------------- + +高层驱动API由以下函数组成: + +- request_irq() + +- request_threaded_irq() + +- free_irq() + +- disable_irq() + +- enable_irq() + +- disable_irq_nosync() (SMP only) + +- synchronize_irq() (SMP only) + +- irq_set_irq_type() + +- irq_set_irq_wake() + +- irq_set_handler_data() + +- irq_set_chip() + +- irq_set_chip_data() + +详见自动生成的函数文档。 + +.. note:: + + 由于文档构建流程所限，中文文档中并没有引入自动生成的函数文档，所以请读者直接 + 阅读源码注释。 + +电平触发型IRQ流处理程序 +----------------------- + +通用层提供了一套预定义的irq-flow方法: + +- handle_level_irq() + +- handle_edge_irq() + +- handle_fasteoi_irq() + +- handle_simple_irq() + +- handle_percpu_irq() + +- handle_edge_eoi_irq() + +- handle_bad_irq() + +中断流处理程序（无论是预定义的还是架构特定的）由架构在启动期间或设备初始化期间分配给 +特定中断。 + +默认流实现 +~~~~~~~~~~ + +辅助函数 +^^^^^^^^ + +辅助函数调用芯片基元，并被默认流实现所使用。以下是实现的辅助函数（简化摘录）:: + + default_enable(struct irq_data *data) + { + desc->irq_data.chip->irq_unmask(data); + } + + default_disable(struct irq_data *data) + { + if (!delay_disable(data)) + desc->irq_data.chip->irq_mask(data); + } + + default_ack(struct irq_data *data) + { + chip->irq_ack(data); + } + + default_mask_ack(struct irq_data *data) + { + if (chip->irq_mask_ack) { + chip->irq_mask_ack(data); + } else { + chip->irq_mask(data); + chip->irq_ack(data); + } + } + + noop(struct irq_data *data)) + { + } + + + +默认流处理程序的实现 +~~~~~~~~~~~~~~~~~~~~ + +电平触发型IRQ流处理器 +^^^^^^^^^^^^^^^^^^^^^ + +handle_level_irq为电平触发型的中断提供了一个通用实现。 + +实现的控制流如下（简化摘录）:: + + desc->irq_data.chip->irq_mask_ack(); + handle_irq_event(desc->action); + desc->irq_data.chip->irq_unmask(); + + +默认的需回应IRQ流处理器 +^^^^^^^^^^^^^^^^^^^^^^^ + +handle_fasteoi_irq为中断提供了一个通用的实现，它只需要在处理程序的末端有一个EOI。 + +实现的控制流如下（简化摘录）:: + + handle_irq_event(desc->action); + desc->irq_data.chip->irq_eoi(); + + +默认的边沿触发型IRQ流处理器 +^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +handle_edge_irq为边沿触发型的中断提供了一个通用的实现。 + +实现的控制流如下（简化摘录）:: + + if (desc->status & running) { + desc->irq_data.chip->irq_mask_ack(); + desc->status |= pending | masked; + return; + } + desc->irq_data.chip->irq_ack(); + desc->status |= running; + do { + if (desc->status & masked) + desc->irq_data.chip->irq_unmask(); + desc->status &= ~pending; + handle_irq_event(desc->action); + } while (status & pending); + desc->status &= ~running; + + +默认的简单型IRQ流处理器 +^^^^^^^^^^^^^^^^^^^^^^^ + +handle_simple_irq提供了一个简单型中断的通用实现。 + +.. note:: + + 简单型的流处理程序不调用任何处理程序/芯片基元。 + +实现的控制流程如下（简化摘录）:: + + handle_irq_event(desc->action); + + +默认的每CPU型流处理程序 +^^^^^^^^^^^^^^^^^^^^^^^ + +handle_percpu_irq为每CPU型中断提供一个通用的实现。 + +每个CPU中断只在SMP上可用，该处理程序提供了一个没有锁的简化版本。 + +以下是控制流的实现（简化摘录）:: + + if (desc->irq_data.chip->irq_ack) + desc->irq_data.chip->irq_ack(); + handle_irq_event(desc->action); + if (desc->irq_data.chip->irq_eoi) + desc->irq_data.chip->irq_eoi(); + + +EOI边沿型IRQ流处理器 +^^^^^^^^^^^^^^^^^^^^ + +handle_edge_eoi_irq提供了一个异常的边沿触发型处理程序，它只用于拯救powerpc/cell +上的一个严重失控的irq控制器。 + +坏的IRQ流处理器 +^^^^^^^^^^^^^^^ + +handle_bad_irq用于处理没有真正分配处理程序的假中断。 + +特殊性和优化 +~~~~~~~~~~~~ + +通用函数是为“干净”的架构和芯片设计的，它们没有平台特定的IRQ处理特殊性。如果一 +个架构需要在“流”的层面上实现特殊性，那么它可以通过覆盖高层的IRQ-流处理程序来实 +现。 + +延迟中断禁用 +~~~~~~~~~~~~ + +每个中断可选择的功能是由Russell King在ARM中断实现中引入的，当调用disable_irq() +时，不会在硬件层面上屏蔽中断。中断保持启用状态，而在中断事件发生时在流处理器中被 +屏蔽。这可以防止在硬件上丢失边沿中断，因为硬件上不存储边沿中断事件，而中断在硬件 +级被禁用。当一个中断在IRQ_DISABLED标志被设置时到达，那么该中断在硬件层面被屏蔽， +IRQ_PENDING位被设置。当中断被enable_irq()重新启用时，将检查挂起位，如果它被设置， +中断将通过硬件或软件重发机制重新发送。(当你想使用延迟中断禁用功能，而你的硬件又不 +能重新触发中断时，有必要启用CONFIG_HARDIRQS_SW_RESEND。) 延迟中断禁止功能是不可 +配置的。 + +芯片级硬件封装 +-------------- + +芯片级硬件描述符结构体 :c:type:`irq_chip` 包含了所有与芯片直接相关的功能，这些功 +能可以被irq流实现所利用。 + +- ``irq_ack`` + +- ``irq_mask_ack`` - 可选的，建议使用的性能 + +- ``irq_mask`` + +- ``irq_unmask`` + +- ``irq_eoi`` - 可选的，EOI流处理程序需要 + +- ``irq_retrigger`` - 可选的 + +- ``irq_set_type`` - 可选的 + +- ``irq_set_wake`` - 可选的 + +这些基元的意思是严格意义上的：ack是指ACK，masking是指对IRQ线的屏蔽，等等。这取决 +于流处理器如何使用这些基本的低级功能单元。 + +__do_IRQ入口点 +============== + +最初的实现__do_IRQ()是所有类型中断的替代入口点。它已经不存在了。 + +这个处理程序被证明不适合所有的中断硬件，因此被重新实现了边沿/级别/简单/超高速中断 +的拆分功能。这不仅是一个功能优化。它也缩短了中断的代码路径。 + +在SMP上的锁 +=========== + +芯片寄存器的锁定是由定义芯片基元的架构决定的。每个寄存器的结构通过desc->lock，由 +通用层保护。 + +通用中断芯片 +============ + +为了避免复制相同的IRQ芯片实现，核心提供了一个可配置的通用中断芯片实现。开发者在自 +己实现相同的功能之前，应该仔细检查通用芯片是否符合他们的需求，并以稍微不同的方式实 +现相同的功能。 + +该API在以下内核代码中: + +kernel/irq/generic-chip.c + +结构体 +====== + +本章包含自动生成的结构体文档，这些结构体在通用IRQ层中使用。 + +该API在以下内核代码中: + +include/linux/irq.h + +include/linux/interrupt.h + +提供的通用函数 +============== + +这一章包含了自动生成的内核API函数的文档，这些函数被导出。 + +该API在以下内核代码中: + +kernel/irq/manage.c + +kernel/irq/chip.c + +提供的内部函数 +============== + +本章包含自动生成的内部函数的文档。 + +该API在以下内核代码中: + +kernel/irq/irqdesc.c + +kernel/irq/handle.c + +kernel/irq/chip.c + +鸣谢 +==== + +感谢以下人士对本文档作出的贡献： + +1. Thomas Gleixner tglx@linutronix.de + +2. Ingo Molnar mingo@elte.hu diff --git a/Documentation/translations/zh_CN/core-api/index.rst b/Documentation/translations/zh_CN/core-api/index.rst index b4bde9396339..71a212a2a9db 100644 --- a/Documentation/translations/zh_CN/core-api/index.rst +++ b/Documentation/translations/zh_CN/core-api/index.rst @@ -80,13 +80,13 @@ Todolist: :maxdepth: 1 cachetlb + genericirq Todolist: cpu_hotplug memory-hotplug - genericirq protection-keys -- cgit v1.2.3 From 153c43a84c7f092b21d9624ffd819552cd5c915b Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Pali=20Roh=C3=A1r?= Date: Fri, 25 Jun 2021 23:54:37 +0200 Subject: Documentation: arm: marvell: Add few missing models and documentation files MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Signed-off-by: Pali Rohár Link: https://lore.kernel.org/r/20210625215437.2156-1-pali@kernel.org Signed-off-by: Jonathan Corbet --- Documentation/arm/marvell.rst | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) (limited to 'Documentation') diff --git a/Documentation/arm/marvell.rst b/Documentation/arm/marvell.rst index db2246493d18..85169bc3f538 100644 --- a/Documentation/arm/marvell.rst +++ b/Documentation/arm/marvell.rst @@ -58,11 +58,19 @@ Kirkwood family - Product Brief : https://web.archive.org/web/20120616201621/http://www.marvell.com/embedded-processors/kirkwood/assets/88F6180-003_ver1.pdf - Hardware Spec : https://web.archive.org/web/20130730091654/http://www.marvell.com/embedded-processors/kirkwood/assets/HW_88F6180_OpenSource.pdf - Functional Spec: https://web.archive.org/web/20130730091033/http://www.marvell.com/embedded-processors/kirkwood/assets/FS_88F6180_9x_6281_OpenSource.pdf + - 88F6280 + + - Product Brief : https://web.archive.org/web/20130730091058/http://www.marvell.com/embedded-processors/kirkwood/assets/88F6280_SoC_PB-001.pdf - 88F6281 - Product Brief : https://web.archive.org/web/20120131133709/http://www.marvell.com/embedded-processors/kirkwood/assets/88F6281-004_ver1.pdf - Hardware Spec : https://web.archive.org/web/20120620073511/http://www.marvell.com/embedded-processors/kirkwood/assets/HW_88F6281_OpenSource.pdf - Functional Spec: https://web.archive.org/web/20130730091033/http://www.marvell.com/embedded-processors/kirkwood/assets/FS_88F6180_9x_6281_OpenSource.pdf + - 88F6321 + - 88F6322 + - 88F6323 + + - Product Brief : https://web.archive.org/web/20120616201639/http://www.marvell.com/embedded-processors/kirkwood/assets/88f632x_pb.pdf Homepage: https://web.archive.org/web/20160513194943/http://www.marvell.com/embedded-processors/kirkwood/ Core: @@ -89,6 +97,10 @@ Discovery family - MV76100 + - Product Brief : https://web.archive.org/web/20140722064429/http://www.marvell.com/embedded-processors/discovery-innovation/assets/MV76100-002_WEB.pdf + - Hardware Spec : https://web.archive.org/web/20140722064425/http://www.marvell.com/embedded-processors/discovery-innovation/assets/HW_MV76100_OpenSource.pdf + - Functional Spec: https://web.archive.org/web/20111110081125/http://www.marvell.com/embedded-processors/discovery-innovation/assets/FS_MV76100_78100_78200_OpenSource.pdf + Not supported by the Linux kernel. Core: @@ -124,17 +136,23 @@ EBU Armada family Armada 38x Flavors: - 88F6810 Armada 380 + - 88F6811 Armada 381 + - 88F6821 Armada 382 + - 88F6W21 Armada 383 - 88F6820 Armada 385 - 88F6828 Armada 388 - Product infos: https://web.archive.org/web/20181006144616/http://www.marvell.com/embedded-processors/armada-38x/ - Functional Spec: https://web.archive.org/web/20200420191927/https://www.marvell.com/content/dam/marvell/en/public-collateral/embedded-processors/marvell-embedded-processors-armada-38x-functional-specifications-2015-11.pdf + - Hardware Spec: https://web.archive.org/web/20180713105318/https://www.marvell.com/docs/embedded-processors/assets/marvell-embedded-processors-armada-38x-hardware-specifications-2017-03.pdf + - Design guide: https://web.archive.org/web/20180712231737/https://www.marvell.com/docs/embedded-processors/assets/marvell-embedded-processors-armada-38x-hardware-design-guide-2017-08.pdf Core: ARM Cortex-A9 Armada 39x Flavors: - 88F6920 Armada 390 + - 88F6925 Armada 395 - 88F6928 Armada 398 - Product infos: https://web.archive.org/web/20181020222559/http://www.marvell.com/embedded-processors/armada-39x/ -- cgit v1.2.3 From 842f697776926b06ada93b16658cdd77cc0ef710 Mon Sep 17 00:00:00 2001 From: Ingo Molnar Date: Thu, 1 Jul 2021 13:31:52 +0200 Subject: Documentation/features: Update the ARCH_HAS_TICK_BROADCAST entry Risc-V gained support recently. Signed-off-by: Ingo Molnar Link: https://lore.kernel.org/r/YN2nqOVHgGDt4Iid@gmail.com Signed-off-by: Jonathan Corbet --- Documentation/features/time/arch-tick-broadcast/arch-support.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/features/time/arch-tick-broadcast/arch-support.txt b/Documentation/features/time/arch-tick-broadcast/arch-support.txt index 8639fe8315f5..8dcaab070c7b 100644 --- a/Documentation/features/time/arch-tick-broadcast/arch-support.txt +++ b/Documentation/features/time/arch-tick-broadcast/arch-support.txt @@ -22,7 +22,7 @@ | openrisc: | TODO | | parisc: | TODO | | powerpc: | ok | - | riscv: | TODO | + | riscv: | ok | | s390: | TODO | | sh: | ok | | sparc: | TODO | -- cgit v1.2.3 From f1285c68e12558b147979b96f4efcbc2eb0c48cd Mon Sep 17 00:00:00 2001 From: Cengiz Can Date: Tue, 29 Jun 2021 17:15:09 +0300 Subject: Documentation: sysrq: convert to third person Two parts of the sysrq documentation have sentences written from a first person's point of view. Documentation is generally written from a third person's view in a formal way. Convert those senteces to be less personal and generic. Signed-off-by: Cengiz Can Link: https://lore.kernel.org/r/20210629141508.52229-1-cengiz@kernel.wtf Signed-off-by: Jonathan Corbet --- Documentation/admin-guide/sysrq.rst | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) (limited to 'Documentation') diff --git a/Documentation/admin-guide/sysrq.rst b/Documentation/admin-guide/sysrq.rst index 60ce5f5ebab6..0a178ef0111d 100644 --- a/Documentation/admin-guide/sysrq.rst +++ b/Documentation/admin-guide/sysrq.rst @@ -72,7 +72,7 @@ On PowerPC On other If you know of the key combos for other architectures, please - let me know so I can add them to this section. + submit a patch to be included in this section. On all Write a character to /proc/sysrq-trigger. e.g.:: @@ -205,10 +205,12 @@ frozen (probably root) filesystem via the FIFREEZE ioctl. Sometimes SysRq seems to get 'stuck' after using it, what can I do? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -That happens to me, also. I've found that tapping shift, alt, and control -on both sides of the keyboard, and hitting an invalid sysrq sequence again -will fix the problem. (i.e., something like :kbd:`alt-sysrq-z`). Switching to -another virtual console (:kbd:`ALT+Fn`) and then back again should also help. +When this happens, try tapping shift, alt and control on both sides of the +keyboard, and hitting an invalid sysrq sequence again. (i.e., something like +:kbd:`alt-sysrq-z`). + +Switching to another virtual console (:kbd:`ALT+Fn`) and then back again +should also help. I hit SysRq, but nothing seems to happen, what's wrong? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -- cgit v1.2.3 From d3fb38266afefc6424d7179c14936c5908d5e2f2 Mon Sep 17 00:00:00 2001 From: Ingo Molnar Date: Thu, 1 Jul 2021 13:31:17 +0200 Subject: Documentation/features: Add THREAD_INFO_IN_TASK feature matrix Signed-off-by: Ingo Molnar Link: https://lore.kernel.org/r/YN2nhV5F0hBVNPuX@gmail.com Signed-off-by: Jonathan Corbet --- .../core/thread-info-in-task/arch-support.txt | 32 ++++++++++++++++++++++ 1 file changed, 32 insertions(+) create mode 100644 Documentation/features/core/thread-info-in-task/arch-support.txt (limited to 'Documentation') diff --git a/Documentation/features/core/thread-info-in-task/arch-support.txt b/Documentation/features/core/thread-info-in-task/arch-support.txt new file mode 100644 index 000000000000..9f0259bbd7df --- /dev/null +++ b/Documentation/features/core/thread-info-in-task/arch-support.txt @@ -0,0 +1,32 @@ +# +# Feature name: thread-info-in-task +# Kconfig: THREAD_INFO_IN_TASK +# description: arch makes use of the core kernel facility to embedd thread_info in task_struct +# + ----------------------- + | arch |status| + ----------------------- + | alpha: | TODO | + | arc: | TODO | + | arm: | TODO | + | arm64: | ok | + | csky: | TODO | + | h8300: | TODO | + | hexagon: | TODO | + | ia64: | TODO | + | m68k: | TODO | + | microblaze: | TODO | + | mips: | TODO | + | nds32: | ok | + | nios2: | TODO | + | openrisc: | TODO | + | parisc: | TODO | + | powerpc: | ok | + | riscv: | ok | + | s390: | ok | + | sh: | TODO | + | sparc: | TODO | + | um: | TODO | + | x86: | ok | + | xtensa: | TODO | + ----------------------- -- cgit v1.2.3 From 341968c617ca7726b444fdb23e5b2efb0881c5db Mon Sep 17 00:00:00 2001 From: Hu Jialun Date: Sun, 4 Jul 2021 00:48:34 +0800 Subject: docs/zh_CN: Remove the Microsoft rhetoric Update Chinese translation on par with original English coding-style.rst Related commit b7592e5b82db19b72a34b471f3296ad3f651c8b9 Signed-off-by: Hu Jialun Reviewed-by: Hu Haowen Link: https://lore.kernel.org/r/20210703164834.460447-1-hujialun@comp.nus.edu.sg Signed-off-by: Jonathan Corbet --- Documentation/translations/zh_CN/process/coding-style.rst | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/translations/zh_CN/process/coding-style.rst b/Documentation/translations/zh_CN/process/coding-style.rst index b8c484a84d10..638d714bec83 100644 --- a/Documentation/translations/zh_CN/process/coding-style.rst +++ b/Documentation/translations/zh_CN/process/coding-style.rst @@ -268,8 +268,7 @@ C 程序员不使用类似 ThisVariableIsATemporaryCounter 这样华丽的名字 ``count_active_users()`` 或者类似的名字，你不应该叫它 ``cntuser()`` 。 在函数名中包含函数类型 (所谓的匈牙利命名法) 是脑子出了问题——编译器知道那些类 -型而且能够检查那些类型，这样做只能把程序员弄糊涂了。难怪微软总是制造出有问题 -的程序。 +型而且能够检查那些类型，这样做只能把程序员弄糊涂了。 本地变量名应该简短，而且能够表达相关的含义。如果你有一些随机的整数型的循环计 数器，它应该被称为 ``i`` 。叫它 ``loop_counter`` 并无益处，如果它没有被误解的 -- cgit v1.2.3 From 530c4374e21ae750c5fa5aa67b36a97635ddb379 Mon Sep 17 00:00:00 2001 From: Hu Haowen Date: Sun, 20 Jun 2021 09:04:44 +0800 Subject: docs/zh_CN: add a missing space character "LinusTorvalds" is not pretty. Replace it with "Linus Torvalds". Signed-off-by: Hu Haowen Link: https://lore.kernel.org/r/20210620010444.24813-1-src.res@email.cn Signed-off-by: Jonathan Corbet --- Documentation/translations/zh_CN/process/2.Process.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/translations/zh_CN/process/2.Process.rst b/Documentation/translations/zh_CN/process/2.Process.rst index 229629e305ca..4a6ed0219494 100644 --- a/Documentation/translations/zh_CN/process/2.Process.rst +++ b/Documentation/translations/zh_CN/process/2.Process.rst @@ -47,7 +47,7 @@ （顺便说一句，值得注意的是，合并窗口期间集成的更改并不是凭空产生的；它们是经 提前收集、测试和分级的。稍后将详细描述该过程的工作方式。） -合并窗口持续大约两周。在这段时间结束时，LinusTorvalds将声明窗口已关闭，并 +合并窗口持续大约两周。在这段时间结束时，Linus Torvalds将声明窗口已关闭，并 释放第一个“rc”内核。例如，对于目标为5.6的内核，在合并窗口结束时发生的释放 将被称为5.6-rc1。-rc1 版本是一个信号，表示合并新特性的时间已经过去，稳定下一 个内核的时间已经到来。 @@ -168,7 +168,7 @@ Greg Kroah-Hartman领导。稳定团队将使用5.x.y编号方案不定期地发 补丁如何进入内核 ---------------- -只有一个人可以将补丁合并到主线内核存储库中：LinusTorvalds。但是，在进入 +只有一个人可以将补丁合并到主线内核存储库中：Linus Torvalds。但是，在进入 2.6.38内核的9500多个补丁中，只有112个（大约1.3%）是由Linus自己直接选择的。 内核项目已经发展到一个没有一个开发人员可以在没有支持的情况下检查和选择每个 补丁的规模。内核开发人员处理这种增长的方式是使用围绕信任链构建的助理系统。 -- cgit v1.2.3 From f8c6a07c25ce7ff99f6d7e19352e495af6af1d69 Mon Sep 17 00:00:00 2001 From: Yanteng Si Date: Fri, 9 Jul 2021 11:00:34 +0800 Subject: docs/core-api: Modify document layout Modify the layout of the document and remove unnecessary symbols. Signed-off-by: Yanteng Si Reviewed-by: Wu XiangCheng Link: https://lore.kernel.org/r/f151bbc0d1ff6cf24611a698c76b90181f005f8d.1625798719.git.siyanteng@loongson.cn Signed-off-by: Jonathan Corbet --- Documentation/core-api/cpu_hotplug.rst | 38 +++++++++++++++++++++------------- 1 file changed, 24 insertions(+), 14 deletions(-) (limited to 'Documentation') diff --git a/Documentation/core-api/cpu_hotplug.rst b/Documentation/core-api/cpu_hotplug.rst index a2c96bec5ee8..0c872cbea7d5 100644 --- a/Documentation/core-api/cpu_hotplug.rst +++ b/Documentation/core-api/cpu_hotplug.rst @@ -91,9 +91,10 @@ Never use anything other than ``cpumask_t`` to represent bitmap of CPUs. Using CPU hotplug ================= + The kernel option *CONFIG_HOTPLUG_CPU* needs to be enabled. It is currently available on multiple architectures including ARM, MIPS, PowerPC and X86. The -configuration is done via the sysfs interface: :: +configuration is done via the sysfs interface:: $ ls -lh /sys/devices/system/cpu total 0 @@ -113,14 +114,14 @@ configuration is done via the sysfs interface: :: The files *offline*, *online*, *possible*, *present* represent the CPU masks. Each CPU folder contains an *online* file which controls the logical on (1) and -off (0) state. To logically shutdown CPU4: :: +off (0) state. To logically shutdown CPU4:: $ echo 0 > /sys/devices/system/cpu/cpu4/online smpboot: CPU 4 is now offline Once the CPU is shutdown, it will be removed from */proc/interrupts*, */proc/cpuinfo* and should also not be shown visible by the *top* command. To -bring CPU4 back online: :: +bring CPU4 back online:: $ echo 1 > /sys/devices/system/cpu/cpu4/online smpboot: Booting Node 0 Processor 4 APIC 0x1 @@ -142,6 +143,7 @@ The CPU hotplug coordination The offline case ---------------- + Once a CPU has been logically shutdown the teardown callbacks of registered hotplug states will be invoked, starting with ``CPUHP_ONLINE`` and terminating at state ``CPUHP_OFFLINE``. This includes: @@ -158,9 +160,10 @@ at state ``CPUHP_OFFLINE``. This includes: Using the hotplug API --------------------- + It is possible to receive notifications once a CPU is offline or onlined. This might be important to certain drivers which need to perform some kind of setup -or clean up functions based on the number of available CPUs: :: +or clean up functions based on the number of available CPUs:: #include @@ -186,9 +189,10 @@ During the removal of a hotplug state the teardown callback will be invoked. Multiple instances ~~~~~~~~~~~~~~~~~~ + If a driver has multiple instances and each instance needs to perform the callback independently then it is likely that a ''multi-state'' should be used. -First a multi-state state needs to be registered: :: +First a multi-state state needs to be registered:: ret = cpuhp_setup_state_multi(CPUHP_AP_ONLINE_DYN, "X/Y:online, Y_online, Y_prepare_down); @@ -197,7 +201,7 @@ First a multi-state state needs to be registered: :: The ``cpuhp_setup_state_multi()`` behaves similar to ``cpuhp_setup_state()`` except it prepares the callbacks for a multi state and does not invoke the callbacks. This is a one time setup. -Once a new instance is allocated, you need to register this new instance: :: +Once a new instance is allocated, you need to register this new instance:: ret = cpuhp_state_add_instance(Y_hp_online, &d->node); @@ -206,7 +210,8 @@ This function will add this instance to your previously allocated (*Y_online*) on all online CPUs. The *node* element is a ``struct hlist_node`` member of your per-instance data structure. -On removal of the instance: :: +On removal of the instance:: + cpuhp_state_remove_instance(Y_hp_online, &d->node) should be invoked which will invoke the teardown callback on all online @@ -214,6 +219,7 @@ CPUs. Manual setup ~~~~~~~~~~~~ + Usually it is handy to invoke setup and teardown callbacks on registration or removal of a state because usually the operation needs to performed once a CPU goes online (offline) and during initial setup (shutdown) of the driver. However @@ -226,6 +232,7 @@ hotplug operations. The ordering of the events -------------------------- + The hotplug states are defined in ``include/linux/cpuhotplug.h``: * The states *CPUHP_OFFLINE* … *CPUHP_AP_OFFLINE* are invoked before the @@ -248,13 +255,14 @@ another hotplug event. Testing of hotplug states ========================= + One way to verify whether a custom state is working as expected or not is to shutdown a CPU and then put it online again. It is also possible to put the CPU to certain state (for instance *CPUHP_AP_ONLINE*) and then go back to *CPUHP_ONLINE*. This would simulate an error one state after *CPUHP_AP_ONLINE* which would lead to rollback to the online state. -All registered states are enumerated in ``/sys/devices/system/cpu/hotplug/states``: :: +All registered states are enumerated in ``/sys/devices/system/cpu/hotplug/states`` :: $ tail /sys/devices/system/cpu/hotplug/states 138: mm/vmscan:online @@ -268,7 +276,7 @@ All registered states are enumerated in ``/sys/devices/system/cpu/hotplug/states 168: sched:active 169: online -To rollback CPU4 to ``lib/percpu_cnt:online`` and back online just issue: :: +To rollback CPU4 to ``lib/percpu_cnt:online`` and back online just issue:: $ cat /sys/devices/system/cpu/cpu4/hotplug/state 169 @@ -276,14 +284,14 @@ To rollback CPU4 to ``lib/percpu_cnt:online`` and back online just issue: :: $ cat /sys/devices/system/cpu/cpu4/hotplug/state 140 -It is important to note that the teardown callbac of state 140 have been -invoked. And now get back online: :: +It is important to note that the teardown callback of state 140 have been +invoked. And now get back online:: $ echo 169 > /sys/devices/system/cpu/cpu4/hotplug/target $ cat /sys/devices/system/cpu/cpu4/hotplug/state 169 -With trace events enabled, the individual steps are visible, too: :: +With trace events enabled, the individual steps are visible, too:: # TASK-PID CPU# TIMESTAMP FUNCTION # | | | | | @@ -318,6 +326,7 @@ trace. Architecture's requirements =========================== + The following functions and configurations are required: ``CONFIG_HOTPLUG_CPU`` @@ -339,11 +348,12 @@ The following functions and configurations are required: User Space Notification ======================= -After CPU successfully onlined or offline udev events are sent. A udev rule like: :: + +After CPU successfully onlined or offline udev events are sent. A udev rule like:: SUBSYSTEM=="cpu", DRIVERS=="processor", DEVPATH=="/devices/system/cpu/*", RUN+="the_hotplug_receiver.sh" -will receive all events. A script like: :: +will receive all events. A script like:: #!/bin/sh -- cgit v1.2.3 From d4229805df852d5b6508ea7e186c974446147634 Mon Sep 17 00:00:00 2001 From: Yanteng Si Date: Fri, 9 Jul 2021 11:00:35 +0800 Subject: docs/zh_CN: add core api cpu_hotplug translation Translate Documentation/core-api/cpu_hotplug.rst into Chinese. Signed-off-by: Yanteng Si Reviewed-by: Wu XiangCheng Link: https://lore.kernel.org/r/5c2273563e64ccbbaf1e7ff043d2ab467879c421.1625798719.git.siyanteng@loongson.cn Signed-off-by: Jonathan Corbet --- .../translations/zh_CN/core-api/cpu_hotplug.rst | 348 +++++++++++++++++++++ .../translations/zh_CN/core-api/index.rst | 2 +- 2 files changed, 349 insertions(+), 1 deletion(-) create mode 100644 Documentation/translations/zh_CN/core-api/cpu_hotplug.rst (limited to 'Documentation') diff --git a/Documentation/translations/zh_CN/core-api/cpu_hotplug.rst b/Documentation/translations/zh_CN/core-api/cpu_hotplug.rst new file mode 100644 index 000000000000..85a264287426 --- /dev/null +++ b/Documentation/translations/zh_CN/core-api/cpu_hotplug.rst @@ -0,0 +1,348 @@ +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/core-api/cpu_hotplug.rst +:翻译: + + 司延腾 Yanteng Si + +:校译: + + 吴想成 Wu XiangCheng + +.. _cn_core_api_cpu_hotplug: + +================= +内核中的CPU热拔插 +================= + +:时间: 2016年12月 +:作者: Sebastian Andrzej Siewior , + Rusty Russell , + Srivatsa Vaddagiri , + Ashok Raj , + Joel Schopp + +简介 +==== + +现代系统架构的演进已经在处理器中引入了先进的错误报告和纠正能力。有一些OEM也支 +持可热拔插的NUMA（Non Uniform Memory Access，非统一内存访问）硬件,其中物理 +节点的插入和移除需要支持CPU热插拔。 + +这样的进步要求内核可用的CPU被移除，要么是出于配置的原因，要么是出于RAS的目的， +以保持一个不需要的CPU不在系统执行路径。因此需要在Linux内核中支持CPU热拔插。 + +CPU热拔插支持的一个更新颖的用途是它在SMP的暂停恢复支持中的应用。双核和超线程支 +持使得即使是笔记本电脑也能运行不支持这些方法的SMP内核。 + + +命令行开关 +========== + +``maxcpus=n`` + 限制启动时的CPU为 *n* 个。例如，如果你有四个CPU，使用 ``maxcpus=2`` 将只能启 + 动两个。你可以选择稍后让其他CPU上线。 + +``nr_cpus=n`` + 限制内核将支持的CPU总量。如果这里提供的数量低于实际可用的CPU数量，那么其他CPU + 以后就不能上线了。 + +``additional_cpus=n`` + 使用它来限制可热插拔的CPU。该选项设置 + ``cpu_possible_mask = cpu_present_mask + additional_cpus`` + + 这个选项只限于IA64架构。 + +``possible_cpus=n`` + 这个选项设置 ``cpu_possible_mask`` 中的 ``possible_cpus`` 位。 + + 这个选项只限于X86和S390架构。 + +``cpu0_hotplug`` + 允许关闭CPU0。 + + 这个选项只限于X86架构。 + +CPU位图 +======= + +``cpu_possible_mask`` + 系统中可能可用CPU的位图。这是用来为per_cpu变量分配一些启动时的内存，这些变量 + 不会随着CPU的可用或移除而增加/减少。一旦在启动时的发现阶段被设置，该映射就是静态 + 的，也就是说，任何时候都不会增加或删除任何位。根据你的系统需求提前准确地调整它 + 可以节省一些启动时的内存。 + +``cpu_online_mask`` + 当前在线的所有CPU的位图。在一个CPU可用于内核调度并准备接收设备的中断后，它被 + 设置在 ``__cpu_up()`` 中。当使用 ``__cpu_disable()`` 关闭一个CPU时，它被清 + 空，在此之前，所有的操作系统服务包括中断都被迁移到另一个目标CPU。 + +``cpu_present_mask`` + 系统中当前存在的CPU的位图。它们并非全部在线。当物理热拔插被相关的子系统 + （如ACPI）处理时，可以改变和添加新的位或从位图中删除，这取决于事件是 + hot-add/hot-remove。目前还没有定死规定。典型的用法是在启动时启动拓扑结构，这时 + 热插拔被禁用。 + +你真的不需要操作任何系统的CPU映射。在大多数情况下，它们应该是只读的。当设置每个 +CPU资源时，几乎总是使用 ``cpu_possible_mask`` 或 ``for_each_possible_cpu()`` +来进行迭代。宏 ``for_each_cpu()`` 可以用来迭代一个自定义的CPU掩码。 + +不要使用 ``cpumask_t`` 以外的任何东西来表示CPU的位图。 + + +使用CPU热拔插 +============= + +内核选项 *CONFIG_HOTPLUG_CPU* 需要被启用。它目前可用于多种架构，包括ARM、MIPS、 +PowerPC和X86。配置是通过sysfs接口完成的:: + + $ ls -lh /sys/devices/system/cpu + total 0 + drwxr-xr-x 9 root root 0 Dec 21 16:33 cpu0 + drwxr-xr-x 9 root root 0 Dec 21 16:33 cpu1 + drwxr-xr-x 9 root root 0 Dec 21 16:33 cpu2 + drwxr-xr-x 9 root root 0 Dec 21 16:33 cpu3 + drwxr-xr-x 9 root root 0 Dec 21 16:33 cpu4 + drwxr-xr-x 9 root root 0 Dec 21 16:33 cpu5 + drwxr-xr-x 9 root root 0 Dec 21 16:33 cpu6 + drwxr-xr-x 9 root root 0 Dec 21 16:33 cpu7 + drwxr-xr-x 2 root root 0 Dec 21 16:33 hotplug + -r--r--r-- 1 root root 4.0K Dec 21 16:33 offline + -r--r--r-- 1 root root 4.0K Dec 21 16:33 online + -r--r--r-- 1 root root 4.0K Dec 21 16:33 possible + -r--r--r-- 1 root root 4.0K Dec 21 16:33 present + +文件 *offline* 、 *online* 、*possible* 、*present* 代表CPU掩码。每个CPU文件 +夹包含一个 *online* 文件，控制逻辑上的开（1）和关（0）状态。要在逻辑上关闭CPU4:: + + $ echo 0 > /sys/devices/system/cpu/cpu4/online + smpboot: CPU 4 is now offline + +一旦CPU被关闭，它将从 */proc/interrupts* 、*/proc/cpuinfo* 中被删除，也不应该 +被 *top* 命令显示出来。要让CPU4重新上线:: + + $ echo 1 > /sys/devices/system/cpu/cpu4/online + smpboot: Booting Node 0 Processor 4 APIC 0x1 + +CPU又可以使用了。这应该对所有的CPU都有效。CPU0通常比较特殊，被排除在CPU热拔插之外。 +在X86上，内核选项 *CONFIG_BOOTPARAM_HOTPLUG_CPU0* 必须被启用，以便能够关闭CPU0。 +或者，可以使用内核命令选项 *cpu0_hotplug* 。CPU0的一些已知的依赖性: + +* 从休眠/暂停中恢复。如果CPU0处于离线状态，休眠/暂停将失败。 +* PIC中断。如果检测到PIC中断，CPU0就不能被移除。 + +如果你发现CPU0上有任何依赖性，请告知Fenghua Yu 。 + +CPU的热拔插协作 +=============== + +下线情况 +-------- + +一旦CPU被逻辑关闭，注册的热插拔状态的清除回调将被调用，从 ``CPUHP_ONLINE`` 开始，在 +``CPUHP_OFFLINE`` 状态结束。这包括: + +* 如果任务因暂停操作而被冻结，那么 *cpuhp_tasks_frozen* 将被设置为true。 + +* 所有进程都会从这个将要离线的CPU迁移到新的CPU上。新的CPU是从每个进程的当前cpuset中 + 选择的，它可能是所有在线CPU的一个子集。 + +* 所有针对这个CPU的中断都被迁移到新的CPU上。 + +* 计时器也会被迁移到新的CPU上。 + +* 一旦所有的服务被迁移，内核会调用一个特定的例程 ``__cpu_disable()`` 来进行特定的清 + 理。 + +使用热插拔API +------------- + +一旦一个CPU下线或上线，就有可能收到通知。这对某些需要根据可用CPU数量执行某种设置或清 +理功能的驱动程序来说可能很重要:: + + #include + + ret = cpuhp_setup_state(CPUHP_AP_ONLINE_DYN, "X/Y:online", + Y_online, Y_prepare_down); + +*X* 是子系统， *Y* 是特定的驱动程序。 *Y_online* 回调将在所有在线CPU的注册过程中被调用。 +如果在线回调期间发生错误， *Y_prepare_down* 回调将在所有之前调用过在线回调的CPU上调 +用。注册完成后，一旦有CPU上线， *Y_online* 回调将被调用，当CPU关闭时， *Y_prepare_down* +将被调用。所有之前在 *Y_online* 中分配的资源都应该在 *Y_prepare_down* 中释放。如果在 +注册过程中发生错误，返回值 *ret* 为负值。否则会返回一个正值，其中包含动态分配状态 +（ *CPUHP_AP_ONLINE_DYN* ）的分配热拔插。对于预定义的状态，它将返回0。 + +该回调可以通过调用 ``cpuhp_remove_state()`` 来删除。如果是动态分配的状态 +（ *CPUHP_AP_ONLINE_DYN* ），则使用返回的状态。在移除热插拔状态的过程中，将调用拆解回调。 + +多个实例 +~~~~~~~~ + +如果一个驱动程序有多个实例，并且每个实例都需要独立执行回调，那么很可能应该使用 +``multi-state`` 。首先需要注册一个多状态的状态:: + + ret = cpuhp_setup_state_multi(CPUHP_AP_ONLINE_DYN, "X/Y:online, + Y_online, Y_prepare_down); + Y_hp_online = ret; + +``cpuhp_setup_state_multi()`` 的行为与 ``cpuhp_setup_state()`` 类似，只是它 +为多状态准备了回调，但不调用回调。这是一个一次性的设置。 +一旦分配了一个新的实例，你需要注册这个新实例:: + + ret = cpuhp_state_add_instance(Y_hp_online, &d->node); + +这个函数将把这个实例添加到你先前分配的 ``Y_hp_online`` 状态，并在所有在线的 +CPU上调用先前注册的回调（ ``Y_online`` ）。 *node* 元素是你的每个实例数据结构 +中的一个 ``struct hlist_node`` 成员。 + +在移除该实例时:: + + cpuhp_state_remove_instance(Y_hp_online, &d->node) + +应该被调用，这将在所有在线CPU上调用拆分回调。 + +手动设置 +~~~~~~~~ + +通常情况下，在注册或移除状态时调用setup和teamdown回调是很方便的，因为通常在CPU上线 +（下线）和驱动的初始设置（关闭）时需要执行该操作。然而，每个注册和删除功能也有一个 +_nocalls的后缀，如果不希望调用回调，则不调用所提供的回调。在手动设置（或关闭）期间， +应该使用 ``get_online_cpus()`` 和 ``put_online_cpus()`` 函数来抑制CPU热插拔操作。 + + +事件的顺序 +---------- + +热插拔状态被定义在 ``include/linux/cpuhotplug.h``: + +* ``CPUHP_OFFLINE`` ... ``CPUHP_AP_OFFLINE`` 状态是在CPU启动前调用的。 + +* ``CPUHP_AP_OFFLINE`` ... ``CPUHP_AP_ONLINE`` 状态是在CPU被启动后被调用的。 + 中断是关闭的，调度程序还没有在这个CPU上活动。从 ``CPUHP_AP_OFFLINE`` 开始， + 回调被调用到目标CPU上。 + +* ``CPUHP_AP_ONLINE_DYN`` 和 ``CPUHP_AP_ONLINE_DYN_END`` 之间的状态被保留 + 给动态分配。 + +* 这些状态在CPU关闭时以相反的顺序调用，从 ``CPUHP_ONLINE`` 开始，在 ``CPUHP_OFFLINE`` + 停止。这里的回调是在将被关闭的CPU上调用的，直到 ``CPUHP_AP_OFFLINE`` 。 + +通过 ``CPUHP_AP_ONLINE_DYN`` 动态分配的状态通常已经足够了。然而，如果在启动或关闭 +期间需要更早的调用，那么应该获得一个显式状态。如果热拔插事件需要相对于另一个热拔插事 +件的特定排序，也可能需要一个显式状态。 + +测试热拔插状态 +============== + +验证自定义状态是否按预期工作的一个方法是关闭一个CPU，然后再把它上线。也可以把CPU放到某 +些状态（例如 ``CPUHP_AP_ONLINE`` ），然后再回到 ``CPUHP_ONLINE`` 。这将模拟在 +``CPUHP_AP_ONLINE`` 之后的一个状态出现错误，从而导致回滚到在线状态。 + +所有注册的状态都被列举在 ``/sys/devices/system/cpu/hotplug/states`` :: + + $ tail /sys/devices/system/cpu/hotplug/states + 138: mm/vmscan:online + 139: mm/vmstat:online + 140: lib/percpu_cnt:online + 141: acpi/cpu-drv:online + 142: base/cacheinfo:online + 143: virtio/net:online + 144: x86/mce:online + 145: printk:online + 168: sched:active + 169: online + +要将CPU4回滚到 ``lib/percpu_cnt:online`` ，再回到在线状态，只需发出:: + + $ cat /sys/devices/system/cpu/cpu4/hotplug/state + 169 + $ echo 140 > /sys/devices/system/cpu/cpu4/hotplug/target + $ cat /sys/devices/system/cpu/cpu4/hotplug/state + 140 + +需要注意的是，状态140的清除回调已经被调用。现在重新上线:: + + $ echo 169 > /sys/devices/system/cpu/cpu4/hotplug/target + $ cat /sys/devices/system/cpu/cpu4/hotplug/state + 169 + +启用追踪事件后，单个步骤也是可见的:: + + # TASK-PID CPU# TIMESTAMP FUNCTION + # | | | | | + bash-394 [001] 22.976: cpuhp_enter: cpu: 0004 target: 140 step: 169 (cpuhp_kick_ap_work) + cpuhp/4-31 [004] 22.977: cpuhp_enter: cpu: 0004 target: 140 step: 168 (sched_cpu_deactivate) + cpuhp/4-31 [004] 22.990: cpuhp_exit: cpu: 0004 state: 168 step: 168 ret: 0 + cpuhp/4-31 [004] 22.991: cpuhp_enter: cpu: 0004 target: 140 step: 144 (mce_cpu_pre_down) + cpuhp/4-31 [004] 22.992: cpuhp_exit: cpu: 0004 state: 144 step: 144 ret: 0 + cpuhp/4-31 [004] 22.993: cpuhp_multi_enter: cpu: 0004 target: 140 step: 143 (virtnet_cpu_down_prep) + cpuhp/4-31 [004] 22.994: cpuhp_exit: cpu: 0004 state: 143 step: 143 ret: 0 + cpuhp/4-31 [004] 22.995: cpuhp_enter: cpu: 0004 target: 140 step: 142 (cacheinfo_cpu_pre_down) + cpuhp/4-31 [004] 22.996: cpuhp_exit: cpu: 0004 state: 142 step: 142 ret: 0 + bash-394 [001] 22.997: cpuhp_exit: cpu: 0004 state: 140 step: 169 ret: 0 + bash-394 [005] 95.540: cpuhp_enter: cpu: 0004 target: 169 step: 140 (cpuhp_kick_ap_work) + cpuhp/4-31 [004] 95.541: cpuhp_enter: cpu: 0004 target: 169 step: 141 (acpi_soft_cpu_online) + cpuhp/4-31 [004] 95.542: cpuhp_exit: cpu: 0004 state: 141 step: 141 ret: 0 + cpuhp/4-31 [004] 95.543: cpuhp_enter: cpu: 0004 target: 169 step: 142 (cacheinfo_cpu_online) + cpuhp/4-31 [004] 95.544: cpuhp_exit: cpu: 0004 state: 142 step: 142 ret: 0 + cpuhp/4-31 [004] 95.545: cpuhp_multi_enter: cpu: 0004 target: 169 step: 143 (virtnet_cpu_online) + cpuhp/4-31 [004] 95.546: cpuhp_exit: cpu: 0004 state: 143 step: 143 ret: 0 + cpuhp/4-31 [004] 95.547: cpuhp_enter: cpu: 0004 target: 169 step: 144 (mce_cpu_online) + cpuhp/4-31 [004] 95.548: cpuhp_exit: cpu: 0004 state: 144 step: 144 ret: 0 + cpuhp/4-31 [004] 95.549: cpuhp_enter: cpu: 0004 target: 169 step: 145 (console_cpu_notify) + cpuhp/4-31 [004] 95.550: cpuhp_exit: cpu: 0004 state: 145 step: 145 ret: 0 + cpuhp/4-31 [004] 95.551: cpuhp_enter: cpu: 0004 target: 169 step: 168 (sched_cpu_activate) + cpuhp/4-31 [004] 95.552: cpuhp_exit: cpu: 0004 state: 168 step: 168 ret: 0 + bash-394 [005] 95.553: cpuhp_exit: cpu: 0004 state: 169 step: 140 ret: 0 + +可以看到，CPU4一直下降到时间戳22.996，然后又上升到95.552。所有被调用的回调， +包括它们的返回代码都可以在跟踪中看到。 + +架构的要求 +========== + +需要具备以下功能和配置： + +``CONFIG_HOTPLUG_CPU`` + 这个配置项需要在Kconfig中启用 + +``__cpu_up()`` + 调出一个cpu的架构接口 + +``__cpu_disable()`` + 关闭CPU的架构接口，在此程序返回后，内核不能再处理任何中断。这包括定时器的关闭。 + +``__cpu_die()`` + 这实际上是为了确保CPU的死亡。实际上，看看其他架构中实现CPU热拔插的一些示例代 + 码。对于那个特定的架构，处理器被从 ``idle()`` 循环中拿下来。 ``__cpu_die()`` + 通常会等待一些per_cpu状态的设置，以确保处理器的死亡例程被调用来保持活跃。 + +用户空间通知 +============ + +在CPU成功上线或下线后，udev事件被发送。一个udev规则，比如:: + + SUBSYSTEM=="cpu", DRIVERS=="processor", DEVPATH=="/devices/system/cpu/*", RUN+="the_hotplug_receiver.sh" + +将接收所有事件。一个像这样的脚本:: + + #!/bin/sh + + if [ "${ACTION}" = "offline" ] + then + echo "CPU ${DEVPATH##*/} offline" + + elif [ "${ACTION}" = "online" ] + then + echo "CPU ${DEVPATH##*/} online" + + fi + +可以进一步处理该事件。 + +内核内联文档参考 +================ + +该API在以下内核代码中: + +include/linux/cpuhotplug.h diff --git a/Documentation/translations/zh_CN/core-api/index.rst b/Documentation/translations/zh_CN/core-api/index.rst index 71a212a2a9db..67252125ddee 100644 --- a/Documentation/translations/zh_CN/core-api/index.rst +++ b/Documentation/translations/zh_CN/core-api/index.rst @@ -80,12 +80,12 @@ Todolist: :maxdepth: 1 cachetlb + cpu_hotplug genericirq Todolist: - cpu_hotplug memory-hotplug protection-keys -- cgit v1.2.3 From 620127548a691b00d18442338922434ff7e37467 Mon Sep 17 00:00:00 2001 From: Yanteng Si Date: Fri, 9 Jul 2021 11:02:42 +0800 Subject: docs/zh_CN: add core api memory_hotplug translation Translate Documentation/core-api/memory_hotplug.rst into Chinese. Signed-off-by: Yanteng Si Reviewed-by: Wu XiangCheng Reviewed-by: Alex Shi Link: https://lore.kernel.org/r/55a74c9fe5627edff36fa01940eae943f0861f8e.1625797729.git.siyanteng@loongson.cn Signed-off-by: Jonathan Corbet --- .../translations/zh_CN/core-api/index.rst | 3 + .../translations/zh_CN/core-api/memory-hotplug.rst | 126 +++++++++++++++++++++ 2 files changed, 129 insertions(+) create mode 100644 Documentation/translations/zh_CN/core-api/memory-hotplug.rst (limited to 'Documentation') diff --git a/Documentation/translations/zh_CN/core-api/index.rst b/Documentation/translations/zh_CN/core-api/index.rst index 67252125ddee..cd25d42dfb2c 100644 --- a/Documentation/translations/zh_CN/core-api/index.rst +++ b/Documentation/translations/zh_CN/core-api/index.rst @@ -82,11 +82,14 @@ Todolist: cachetlb cpu_hotplug genericirq + memory-hotplug Todolist: memory-hotplug + cpu_hotplug + genericirq protection-keys diff --git a/Documentation/translations/zh_CN/core-api/memory-hotplug.rst b/Documentation/translations/zh_CN/core-api/memory-hotplug.rst new file mode 100644 index 000000000000..161f4d2c18cc --- /dev/null +++ b/Documentation/translations/zh_CN/core-api/memory-hotplug.rst @@ -0,0 +1,126 @@ +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/core-api/memory_hotplug.rst + +:翻译: + + 司延腾 Yanteng Si + +:校译: + + 吴想成 Wu XiangCheng + +.. _cn_core-api_memory-hotplug: + +========== +内存热插拔 +========== + +内存热拔插事件通知器 +==================== + +热插拔事件被发送到一个通知队列中。 + +在 ``include/linux/memory.h`` 中定义了六种类型的通知： + +MEM_GOING_ONLINE + 在新内存可用之前生成，以便能够为子系统处理内存做准备。页面分配器仍然无法从新 + 的内存中进行分配。 + +MEM_CANCEL_ONLINE + 如果MEM_GOING_ONLINE失败，则生成。 + +MEM_ONLINE + 当内存成功上线时产生。回调可以从新的内存中分配页面。 + +MEM_GOING_OFFLINE + 在开始对内存进行下线处理时生成。从内存中的分配不再可能，但是一些要下线的内存 + 仍然在使用。回调可以用来释放一个子系统在指定内存块中已知的内存。 + +MEM_CANCEL_OFFLINE + 如果MEM_GOING_OFFLINE失败，则生成。来自我们试图离线的内存块中的内存又可以使 + 用了。 + +MEM_OFFLINE + 在内存下线完成后生成。 + +可以通过调用如下函数来注册一个回调程序: + + hotplug_memory_notifier(callback_func, priority) + +优先级数值较高的回调函数在数值较低的回调函数之前被调用。 + +一个回调函数必须有以下原型:: + + int callback_func( + struct notifier_block *self, unsigned long action, void *arg); + +回调函数的第一个参数（self）是指向回调函数本身的通知器链块的一个指针。第二个参 +数（action）是上述的事件类型之一。第三个参数（arg）传递一个指向 +memory_notify结构体的指针:: + + struct memory_notify { + unsigned long start_pfn; + unsigned long nr_pages; + int status_change_nid_normal; + int status_change_nid_high; + int status_change_nid; + } + +- start_pfn是在线/离线内存的start_pfn。 + +- nr_pages是在线/离线内存的页数。 + +- status_change_nid_normal是当nodemask的N_NORMAL_MEMORY被设置/清除时设置节 + 点id，如果是-1，则nodemask状态不改变。 + +- status_change_nid_high是当nodemask的N_HIGH_MEMORY被设置/清除时设置的节点 + id，如果这个值为-1，那么nodemask状态不会改变。 + +- status_change_nid是当nodemask的N_MEMORY被（将）设置/清除时设置的节点id。这 + 意味着一个新的（没上线的）节点通过联机获得新的内存，而一个节点失去了所有的内 + 存。如果这个值为-1，那么nodemask的状态就不会改变。 + + 如果 status_changed_nid* >= 0，回调应该在必要时为节点创建/丢弃结构体。 + +回调程序应返回 ``include/linux/notifier.h`` 中定义的NOTIFY_DONE, NOTIFY_OK, +NOTIFY_BAD, NOTIFY_STOP中的一个值。 + +NOTIFY_DONE和NOTIFY_OK对进一步处理没有影响。 + +NOTIFY_BAD是作为对MEM_GOING_ONLINE、MEM_GOING_OFFLINE、MEM_ONLINE或MEM_OFFLINE +动作的回应，用于取消热插拔。它停止对通知队列的进一步处理。 + +NOTIFY_STOP停止对通知队列的进一步处理。 + +内部锁 +====== + +当添加/删除使用内存块设备（即普通RAM）的内存时，device_hotplug_lock应该被保持 +为: + +- 针对在线/离线请求进行同步（例如，通过sysfs）。这样一来，内存块设备只有在内存 + 被完全添加后才能被用户空间访问（.online/.state属性）。而在删除内存时，我们知 + 道没有人在临界区。 + +- 与CPU热拔插或类似操作同步（例如ACPI和PPC相关操作） + +特别是，在添加内存和用户空间试图以比预期更快的速度上线该内存时，有可能出现锁反转， +使用device_hotplug_lock可以避免此情况: + +- device_online()将首先接受device_lock()，然后是mem_hotplug_lock。 + +- add_memory_resource()将首先使用mem_hotplug_lock，然后是device_lock()（在创 + 建设备时，在bus_add_device()期间）。 + +由于在使用device_lock()之前，设备对用户空间是可见的，这可能导致锁的反转。 + +内存的上线/下线应该通过device_online()/device_offline()完成————确保它与通过 +sysfs进行的操作正确同步。建议持有device_hotplug_lock（例如，保护online_type）。 + +当添加/删除/上线/下线内存或者添加/删除异构或设备内存时，我们应该始终持有写模式的 +mem_hotplug_lock，以序列化内存热插拔（例如访问全局/区域变量）。 + +此外，mem_hotplug_lock（与device_hotplug_lock相反）在读取模式下允许一个相当 +有效的get_online_mems/put_online_mems实现，所以访问内存的代码可以防止该内存 +消失。 -- cgit v1.2.3 From 4b3abe1fde4799ed92c378e545271ca7a7828a41 Mon Sep 17 00:00:00 2001 From: Yanteng Si Date: Fri, 9 Jul 2021 11:02:43 +0800 Subject: docs/zh_CN: add core api protection keys translation Translate Documentation/core-api/protection-keys.rst into Chinese. Signed-off-by: Yanteng Si Reviewed-by: Wu XiangCheng Reviewed-by: Alex Shi Link: https://lore.kernel.org/r/abdcd4f157062a529cfc50754689d2df26070592.1625797729.git.siyanteng@loongson.cn Signed-off-by: Jonathan Corbet --- .../translations/zh_CN/core-api/index.rst | 2 +- .../zh_CN/core-api/protection-keys.rst | 99 ++++++++++++++++++++++ 2 files changed, 100 insertions(+), 1 deletion(-) create mode 100644 Documentation/translations/zh_CN/core-api/protection-keys.rst (limited to 'Documentation') diff --git a/Documentation/translations/zh_CN/core-api/index.rst b/Documentation/translations/zh_CN/core-api/index.rst index cd25d42dfb2c..d5e947d8b6f1 100644 --- a/Documentation/translations/zh_CN/core-api/index.rst +++ b/Documentation/translations/zh_CN/core-api/index.rst @@ -83,6 +83,7 @@ Todolist: cpu_hotplug genericirq memory-hotplug + protection-keys Todolist: @@ -90,7 +91,6 @@ Todolist: memory-hotplug cpu_hotplug genericirq - protection-keys 内存管理 diff --git a/Documentation/translations/zh_CN/core-api/protection-keys.rst b/Documentation/translations/zh_CN/core-api/protection-keys.rst new file mode 100644 index 000000000000..d07830050153 --- /dev/null +++ b/Documentation/translations/zh_CN/core-api/protection-keys.rst @@ -0,0 +1,99 @@ +.. SPDX-License-Identifier: GPL-2.0 +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/core-api/protection-keys.rst + +:翻译: + + 司延腾 Yanteng Si + +:校译: + + 吴想成 Wu XiangCheng + +.. _cn_core-api_protection-keys: + +============ +内存保护密钥 +============ + +用户空间的内存保护密钥（Memory Protection Keys for Userspace，PKU，亦 +即PKEYs）是英特尔Skylake（及以后）“可扩展处理器”服务器CPU上的一项功能。 +它将在未来的非服务器英特尔处理器和未来的AMD处理器中可用。 + +对于任何希望测试或使用该功能的人来说，它在亚马逊的EC2 C5实例中是可用的， +并且已知可以在那里使用Ubuntu 17.04镜像运行。 + +内存保护密钥提供了一种机制来执行基于页面的保护，但在应用程序改变保护域 +时不需要修改页表。它的工作原理是在每个页表项中为“保护密钥”分配4个以 +前被忽略的位，从而提供16个可能的密钥。 + +还有一个新的用户可访问寄存器（PKRU），为每个密钥提供两个单独的位（访 +问禁止和写入禁止）。作为一个CPU寄存器，PKRU在本质上是线程本地的，可能 +会给每个线程提供一套不同于其他线程的保护措施。 + +有两条新指令（RDPKRU/WRPKRU）用于读取和写入新的寄存器。该功能仅在64位 +模式下可用，尽管物理地址扩展页表中理论上有空间。这些权限只在数据访问上 +强制执行，对指令获取没有影响。 + + +系统调用 +======== + +有3个系统调用可以直接与pkeys进行交互:: + + int pkey_alloc(unsigned long flags, unsigned long init_access_rights) + int pkey_free(int pkey); + int pkey_mprotect(unsigned long start, size_t len, + unsigned long prot, int pkey); + +在使用一个pkey之前，必须先用pkey_alloc()分配它。一个应用程序直接调用 +WRPKRU指令，以改变一个密钥覆盖的内存的访问权限。在这个例子中，WRPKRU +被一个叫做pkey_set()的C函数所封装:: + + int real_prot = PROT_READ|PROT_WRITE; + pkey = pkey_alloc(0, PKEY_DISABLE_WRITE); + ptr = mmap(NULL, PAGE_SIZE, PROT_NONE, MAP_ANONYMOUS|MAP_PRIVATE, -1, 0); + ret = pkey_mprotect(ptr, PAGE_SIZE, real_prot, pkey); + ... application runs here + +现在，如果应用程序需要更新'ptr'处的数据，它可以获得访问权，进行更新， +然后取消其写访问权:: + + pkey_set(pkey, 0); // clear PKEY_DISABLE_WRITE + *ptr = foo; // assign something + pkey_set(pkey, PKEY_DISABLE_WRITE); // set PKEY_DISABLE_WRITE again + +现在，当它释放内存时，它也将释放pkey，因为它不再被使用了:: + + munmap(ptr, PAGE_SIZE); + pkey_free(pkey); + +.. note:: pkey_set()是RDPKRU和WRPKRU指令的一个封装器。在tools/testing/selftests/x86/protection_keys.c中可以找到一个实现实例。 + tools/testing/selftests/x86/protection_keys.c. + +行为 +==== + +内核试图使保护密钥与普通的mprotect()的行为一致。例如，如果你这样做:: + + mprotect(ptr, size, PROT_NONE); + something(ptr); + +这样做的时候，你可以期待保护密钥的相同效果:: + + pkey = pkey_alloc(0, PKEY_DISABLE_WRITE | PKEY_DISABLE_READ); + pkey_mprotect(ptr, size, PROT_READ|PROT_WRITE, pkey); + something(ptr); + +无论something()是否是对'ptr'的直接访问，这都应该为真。 +如:: + + *ptr = foo; + +或者当内核代表应用程序进行访问时，比如read():: + + read(fd, ptr, 1); + +在这两种情况下，内核都会发送一个SIGSEGV，但当违反保护密钥时，si_code +将被设置为SEGV_PKERR，而当违反普通的mprotect()权限时，则是SEGV_ACCERR。 -- cgit v1.2.3 From d549c66766ee42175e2f4a47219b4103ddab4ffa Mon Sep 17 00:00:00 2001 From: Thierry Reding Date: Tue, 22 Jun 2021 13:33:27 +0200 Subject: dt-bindings: net: dsa: sja1105: Fix indentation warnings Some of the lines aren't properly indented, causing yamllint to warn about them: .../nxp,sja1105.yaml:70:17: [warning] wrong indentation: expected 18 but found 16 (indentation) Use the proper indentation to fix those warnings. Signed-off-by: Thierry Reding Fixes: 070f5b701d559ae1 ("dt-bindings: net: dsa: sja1105: add SJA1110 bindings") Tested-by: Geert Uytterhoeven Link: https://lore.kernel.org/r/20210622113327.3613595-1-thierry.reding@gmail.com Signed-off-by: Rob Herring --- Documentation/devicetree/bindings/net/dsa/nxp,sja1105.yaml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/dsa/nxp,sja1105.yaml b/Documentation/devicetree/bindings/net/dsa/nxp,sja1105.yaml index 0b8a05dd52e6..f978f8719d8e 100644 --- a/Documentation/devicetree/bindings/net/dsa/nxp,sja1105.yaml +++ b/Documentation/devicetree/bindings/net/dsa/nxp,sja1105.yaml @@ -67,8 +67,8 @@ properties: reg: oneOf: - enum: - - 0 - - 1 + - 0 + - 1 required: - compatible -- cgit v1.2.3 From 977b3167c2bda24c3cd21e94ca7a4c25a386e812 Mon Sep 17 00:00:00 2001 From: Suman Anna Date: Wed, 23 Jun 2021 12:06:30 -0500 Subject: dt-bindings: irqchip: Update pruss-intc binding for K3 AM64x SoCs The K3 AM64x SoCs also have a ICSSG IP that is similar to existing K3 AM65x and J721E SoCs. The ICSSG interrupt controller is identical to that of the INTC on J721E SoCs, and supports 20 host interrupts and 160 input events from various SoC interrupt sources. All the 8 output host interrupts are routed to multiple entities though. Update the PRUSS interrupt controller binding with this information, though the same K3 compatible shall be used for the ICSSG INTC on AM64x SoCs. Signed-off-by: Suman Anna Link: https://lore.kernel.org/r/20210623170630.1430-1-s-anna@ti.com Signed-off-by: Rob Herring --- .../devicetree/bindings/interrupt-controller/ti,pruss-intc.yaml | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/interrupt-controller/ti,pruss-intc.yaml b/Documentation/devicetree/bindings/interrupt-controller/ti,pruss-intc.yaml index 051beb45d998..65523d9459d8 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/ti,pruss-intc.yaml +++ b/Documentation/devicetree/bindings/interrupt-controller/ti,pruss-intc.yaml @@ -46,7 +46,7 @@ properties: AM437x family of SoCs, AM57xx family of SoCs 66AK2G family of SoCs - Use "ti,icssg-intc" for K3 AM65x & J721E family of SoCs + Use "ti,icssg-intc" for K3 AM65x, J721E and AM64x family of SoCs reg: maxItems: 1 @@ -95,6 +95,8 @@ properties: - AM65x and J721E SoCs have "host_intr5", "host_intr6" and "host_intr7" interrupts connected to MPU, and other ICSSG instances. + - AM64x SoCs have all the 8 host interrupts connected to various + other SoC entities required: - compatible -- cgit v1.2.3 From 2720b991337d530b87095f62631e462efa1685cb Mon Sep 17 00:00:00 2001 From: Corentin Labbe Date: Mon, 28 Jun 2021 19:35:08 +0000 Subject: dt-bindings: PCI: ftpci100: convert faraday,ftpci100 to YAML Converts pci/faraday,ftpci100.txt to yaml. Some change are also made: - example has wrong interrupts place Reviewed-by: Linus Walleij Signed-off-by: Corentin Labbe Link: https://lore.kernel.org/r/20210628193508.2826903-1-clabbe@baylibre.com Signed-off-by: Rob Herring --- .../devicetree/bindings/pci/faraday,ftpci100.txt | 135 ---------------- .../devicetree/bindings/pci/faraday,ftpci100.yaml | 176 +++++++++++++++++++++ 2 files changed, 176 insertions(+), 135 deletions(-) delete mode 100644 Documentation/devicetree/bindings/pci/faraday,ftpci100.txt create mode 100644 Documentation/devicetree/bindings/pci/faraday,ftpci100.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pci/faraday,ftpci100.txt b/Documentation/devicetree/bindings/pci/faraday,ftpci100.txt deleted file mode 100644 index 5f8cb4962f8d..000000000000 --- a/Documentation/devicetree/bindings/pci/faraday,ftpci100.txt +++ /dev/null @@ -1,135 +0,0 @@ -Faraday Technology FTPCI100 PCI Host Bridge - -This PCI bridge is found inside that Cortina Systems Gemini SoC platform and -is a generic IP block from Faraday Technology. It exists in two variants: -plain and dual PCI. The plain version embeds a cascading interrupt controller -into the host bridge. The dual version routes the interrupts to the host -chips interrupt controller. - -The host controller appear on the PCI bus with vendor ID 0x159b (Faraday -Technology) and product ID 0x4321. - -Mandatory properties: - -- compatible: ranging from specific to generic, should be one of - "cortina,gemini-pci", "faraday,ftpci100" - "cortina,gemini-pci-dual", "faraday,ftpci100-dual" - "faraday,ftpci100" - "faraday,ftpci100-dual" -- reg: memory base and size for the host bridge -- #address-cells: set to <3> -- #size-cells: set to <2> -- #interrupt-cells: set to <1> -- bus-range: set to <0x00 0xff> -- device_type, set to "pci" -- ranges: see pci.txt -- interrupt-map-mask: see pci.txt -- interrupt-map: see pci.txt -- 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. - -Optional properties: -- clocks: when present, this should contain the peripheral clock (PCLK) and the - PCI clock (PCICLK). If these are not present, they are assumed to be - hard-wired enabled and always on. The PCI clock will be 33 or 66 MHz. -- clock-names: when present, this should contain "PCLK" for the peripheral - clock and "PCICLK" for the PCI-side clock. - -Mandatory subnodes: -- For "faraday,ftpci100" a node representing the interrupt-controller inside the - host bridge is mandatory. It has the following mandatory properties: - - interrupt: see interrupt-controller/interrupts.txt - - interrupt-controller: see interrupt-controller/interrupts.txt - - #address-cells: set to <0> - - #interrupt-cells: set to <1> - -I/O space considerations: - -The plain variant has 128MiB of non-prefetchable memory space, whereas the -"dual" variant has 64MiB. Take this into account when describing the ranges. - -Interrupt map considerations: - -The "dual" variant will get INT A, B, C, D from the system interrupt controller -and should point to respective interrupt in that controller in its -interrupt-map. - -The code which is the only documentation of how the Faraday PCI (the non-dual -variant) interrupts assigns the default interrupt mapping/swizzling has -typically been like this, doing the swizzling on the interrupt controller side -rather than in the interconnect: - -interrupt-map-mask = <0xf800 0 0 7>; -interrupt-map = - <0x4800 0 0 1 &pci_intc 0>, /* Slot 9 */ - <0x4800 0 0 2 &pci_intc 1>, - <0x4800 0 0 3 &pci_intc 2>, - <0x4800 0 0 4 &pci_intc 3>, - <0x5000 0 0 1 &pci_intc 1>, /* Slot 10 */ - <0x5000 0 0 2 &pci_intc 2>, - <0x5000 0 0 3 &pci_intc 3>, - <0x5000 0 0 4 &pci_intc 0>, - <0x5800 0 0 1 &pci_intc 2>, /* Slot 11 */ - <0x5800 0 0 2 &pci_intc 3>, - <0x5800 0 0 3 &pci_intc 0>, - <0x5800 0 0 4 &pci_intc 1>, - <0x6000 0 0 1 &pci_intc 3>, /* Slot 12 */ - <0x6000 0 0 2 &pci_intc 0>, - <0x6000 0 0 3 &pci_intc 1>, - <0x6000 0 0 4 &pci_intc 2>; - -Example: - -pci@50000000 { - compatible = "cortina,gemini-pci", "faraday,ftpci100"; - reg = <0x50000000 0x100>; - interrupts = <8 IRQ_TYPE_LEVEL_HIGH>, /* PCI A */ - <26 IRQ_TYPE_LEVEL_HIGH>, /* PCI B */ - <27 IRQ_TYPE_LEVEL_HIGH>, /* PCI C */ - <28 IRQ_TYPE_LEVEL_HIGH>; /* PCI D */ - #address-cells = <3>; - #size-cells = <2>; - #interrupt-cells = <1>; - - bus-range = <0x00 0xff>; - ranges = /* 1MiB I/O space 0x50000000-0x500fffff */ - <0x01000000 0 0 0x50000000 0 0x00100000>, - /* 128MiB non-prefetchable memory 0x58000000-0x5fffffff */ - <0x02000000 0 0x58000000 0x58000000 0 0x08000000>; - - /* DMA ranges */ - dma-ranges = - /* 128MiB at 0x00000000-0x07ffffff */ - <0x02000000 0 0x00000000 0x00000000 0 0x08000000>, - /* 64MiB at 0x00000000-0x03ffffff */ - <0x02000000 0 0x00000000 0x00000000 0 0x04000000>, - /* 64MiB at 0x00000000-0x03ffffff */ - <0x02000000 0 0x00000000 0x00000000 0 0x04000000>; - - interrupt-map-mask = <0xf800 0 0 7>; - interrupt-map = - <0x4800 0 0 1 &pci_intc 0>, /* Slot 9 */ - <0x4800 0 0 2 &pci_intc 1>, - <0x4800 0 0 3 &pci_intc 2>, - <0x4800 0 0 4 &pci_intc 3>, - <0x5000 0 0 1 &pci_intc 1>, /* Slot 10 */ - <0x5000 0 0 2 &pci_intc 2>, - <0x5000 0 0 3 &pci_intc 3>, - <0x5000 0 0 4 &pci_intc 0>, - <0x5800 0 0 1 &pci_intc 2>, /* Slot 11 */ - <0x5800 0 0 2 &pci_intc 3>, - <0x5800 0 0 3 &pci_intc 0>, - <0x5800 0 0 4 &pci_intc 1>, - <0x6000 0 0 1 &pci_intc 3>, /* Slot 12 */ - <0x6000 0 0 2 &pci_intc 0>, - <0x6000 0 0 3 &pci_intc 0>, - <0x6000 0 0 4 &pci_intc 0>; - pci_intc: interrupt-controller { - interrupt-parent = <&intcon>; - interrupt-controller; - #address-cells = <0>; - #interrupt-cells = <1>; - }; -}; diff --git a/Documentation/devicetree/bindings/pci/faraday,ftpci100.yaml b/Documentation/devicetree/bindings/pci/faraday,ftpci100.yaml new file mode 100644 index 000000000000..fb32f7b55035 --- /dev/null +++ b/Documentation/devicetree/bindings/pci/faraday,ftpci100.yaml @@ -0,0 +1,176 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pci/faraday,ftpci100.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Faraday Technology FTPCI100 PCI Host Bridge + +maintainers: + - Linus Walleij + +description: | + This PCI bridge is found inside that Cortina Systems Gemini SoC platform and + is a generic IP block from Faraday Technology. It exists in two variants: + plain and dual PCI. The plain version embeds a cascading interrupt controller + into the host bridge. The dual version routes the interrupts to the host + chips interrupt controller. + The host controller appear on the PCI bus with vendor ID 0x159b (Faraday + Technology) and product ID 0x4321. + I/O space considerations: + The plain variant has 128MiB of non-prefetchable memory space, whereas the + "dual" variant has 64MiB. Take this into account when describing the ranges. + + Interrupt map considerations: + + The "dual" variant will get INT A, B, C, D from the system interrupt controller + and should point to respective interrupt in that controller in its interrupt-map. + + The code which is the only documentation of how the Faraday PCI (the non-dual + variant) interrupts assigns the default interrupt mapping/swizzling has + typically been like this, doing the swizzling on the interrupt controller side + rather than in the interconnect: + + interrupt-map-mask = <0xf800 0 0 7>; + interrupt-map = + <0x4800 0 0 1 &pci_intc 0>, /* Slot 9 */ + <0x4800 0 0 2 &pci_intc 1>, + <0x4800 0 0 3 &pci_intc 2>, + <0x4800 0 0 4 &pci_intc 3>, + <0x5000 0 0 1 &pci_intc 1>, /* Slot 10 */ + <0x5000 0 0 2 &pci_intc 2>, + <0x5000 0 0 3 &pci_intc 3>, + <0x5000 0 0 4 &pci_intc 0>, + <0x5800 0 0 1 &pci_intc 2>, /* Slot 11 */ + <0x5800 0 0 2 &pci_intc 3>, + <0x5800 0 0 3 &pci_intc 0>, + <0x5800 0 0 4 &pci_intc 1>, + <0x6000 0 0 1 &pci_intc 3>, /* Slot 12 */ + <0x6000 0 0 2 &pci_intc 0>, + <0x6000 0 0 3 &pci_intc 1>, + <0x6000 0 0 4 &pci_intc 2>; + +allOf: + - $ref: /schemas/pci/pci-bus.yaml# + +properties: + compatible: + oneOf: + - items: + - const: cortina,gemini-pci + - const: faraday,ftpci100 + - items: + - const: cortina,gemini-pci-dual + - const: faraday,ftpci100-dual + - const: faraday,ftpci100 + - const: faraday,ftpci100-dual + + reg: + maxItems: 1 + + "#address-cells": + const: 3 + + "#interrupt-cells": + const: 1 + + ranges: + minItems: 2 + + dma-ranges: + minItems: 3 + description: | + 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. + + clocks: + items: + - description: peripheral clock (PCLK) + - description: PCI clock (PCICLK). + description: | + If these are not present, they are assumed to be + hard-wired enabled and always on. The PCI clock will be 33 or 66 MHz. + + clock-names: + items: + - const: PCLK + - const: PCICLK + + interrupt-controller: + type: object + +required: + - reg + - compatible + - "#interrupt-cells" + - interrupt-map-mask + - interrupt-map + - dma-ranges + +if: + properties: + compatible: + contains: + items: + - const: cortina,gemini-pci + - const: faraday,ftpci100 +then: + required: + - interrupt-controller + +unevaluatedProperties: false + +examples: + - | + #include + pci@50000000 { + compatible = "cortina,gemini-pci", "faraday,ftpci100"; + reg = <0x50000000 0x100>; + device_type = "pci"; + #address-cells = <3>; + #size-cells = <2>; + #interrupt-cells = <1>; + + bus-range = <0x00 0xff>; + ranges = /* 1MiB I/O space 0x50000000-0x500fffff */ + <0x01000000 0 0 0x50000000 0 0x00100000>, + /* 128MiB non-prefetchable memory 0x58000000-0x5fffffff */ + <0x02000000 0 0x58000000 0x58000000 0 0x08000000>; + + /* DMA ranges */ + dma-ranges = + /* 128MiB at 0x00000000-0x07ffffff */ + <0x02000000 0 0x00000000 0x00000000 0 0x08000000>, + /* 64MiB at 0x00000000-0x03ffffff */ + <0x02000000 0 0x00000000 0x00000000 0 0x04000000>, + /* 64MiB at 0x00000000-0x03ffffff */ + <0x02000000 0 0x00000000 0x00000000 0 0x04000000>; + + interrupt-map-mask = <0xf800 0 0 7>; + interrupt-map = + <0x4800 0 0 1 &pci_intc 0>, /* Slot 9 */ + <0x4800 0 0 2 &pci_intc 1>, + <0x4800 0 0 3 &pci_intc 2>, + <0x4800 0 0 4 &pci_intc 3>, + <0x5000 0 0 1 &pci_intc 1>, /* Slot 10 */ + <0x5000 0 0 2 &pci_intc 2>, + <0x5000 0 0 3 &pci_intc 3>, + <0x5000 0 0 4 &pci_intc 0>, + <0x5800 0 0 1 &pci_intc 2>, /* Slot 11 */ + <0x5800 0 0 2 &pci_intc 3>, + <0x5800 0 0 3 &pci_intc 0>, + <0x5800 0 0 4 &pci_intc 1>, + <0x6000 0 0 1 &pci_intc 3>, /* Slot 12 */ + <0x6000 0 0 2 &pci_intc 0>, + <0x6000 0 0 3 &pci_intc 0>, + <0x6000 0 0 4 &pci_intc 0>; + pci_intc: interrupt-controller { + interrupt-parent = <&intcon>; + interrupt-controller; + interrupts = <8 IRQ_TYPE_LEVEL_HIGH>; + #address-cells = <0>; + #interrupt-cells = <1>; + }; + }; -- cgit v1.2.3 From e8917266ae0944385d50da5e691c89f64c5975a3 Mon Sep 17 00:00:00 2001 From: Rob Herring Date: Tue, 13 Jul 2021 13:34:53 -0600 Subject: dt-bindings: More dropping redundant minItems/maxItems Another round of removing redundant minItems/maxItems from new schema in the recent merge window. If a property has an 'items' list, then a 'minItems' or 'maxItems' with the same size as the list is redundant and can be dropped. Note that is DT schema specific behavior and not standard json-schema behavior. The tooling will fixup the final schema adding any unspecified minItems/maxItems. This condition is partially checked with the meta-schema already, but only if both 'minItems' and 'maxItems' are equal to the 'items' length. An improved meta-schema is pending. Cc: Stephen Boyd Cc: Joerg Roedel Cc: Will Deacon Cc: Krzysztof Kozlowski Cc: Miquel Raynal Cc: Richard Weinberger Cc: Vignesh Raghavendra Cc: Alessandro Zummo Cc: Alexandre Belloni Cc: Greg Kroah-Hartman Cc: Sureshkumar Relli Cc: Brian Norris Cc: Kamal Dasu Cc: Linus Walleij Cc: Sebastian Siewior Cc: Laurent Pinchart Cc: linux-clk@vger.kernel.org Cc: iommu@lists.linux-foundation.org Cc: linux-mtd@lists.infradead.org Cc: linux-rtc@vger.kernel.org Cc: linux-usb@vger.kernel.org Signed-off-by: Rob Herring Reviewed-by: Greg Kroah-Hartman Acked-by: Alexandre Belloni Reviewed-by: Laurent Pinchart Link: https://lore.kernel.org/r/20210713193453.690290-1-robh@kernel.org --- Documentation/devicetree/bindings/clock/brcm,iproc-clocks.yaml | 1 - Documentation/devicetree/bindings/iommu/rockchip,iommu.yaml | 2 -- .../devicetree/bindings/memory-controllers/arm,pl353-smc.yaml | 1 - Documentation/devicetree/bindings/mtd/brcm,brcmnand.yaml | 8 -------- Documentation/devicetree/bindings/rtc/faraday,ftrtc010.yaml | 1 - Documentation/devicetree/bindings/usb/nxp,isp1760.yaml | 2 -- 6 files changed, 15 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/brcm,iproc-clocks.yaml b/Documentation/devicetree/bindings/clock/brcm,iproc-clocks.yaml index 8dc7b404ee12..1174c9aa9934 100644 --- a/Documentation/devicetree/bindings/clock/brcm,iproc-clocks.yaml +++ b/Documentation/devicetree/bindings/clock/brcm,iproc-clocks.yaml @@ -50,7 +50,6 @@ properties: reg: minItems: 1 - maxItems: 3 items: - description: base register - description: power register diff --git a/Documentation/devicetree/bindings/iommu/rockchip,iommu.yaml b/Documentation/devicetree/bindings/iommu/rockchip,iommu.yaml index d2e28a9e3545..ba9124f721f1 100644 --- a/Documentation/devicetree/bindings/iommu/rockchip,iommu.yaml +++ b/Documentation/devicetree/bindings/iommu/rockchip,iommu.yaml @@ -28,14 +28,12 @@ properties: - description: configuration registers for MMU instance 0 - description: configuration registers for MMU instance 1 minItems: 1 - maxItems: 2 interrupts: items: - description: interruption for MMU instance 0 - description: interruption for MMU instance 1 minItems: 1 - maxItems: 2 clocks: items: diff --git a/Documentation/devicetree/bindings/memory-controllers/arm,pl353-smc.yaml b/Documentation/devicetree/bindings/memory-controllers/arm,pl353-smc.yaml index 7a63c85ef8c5..01c9acf9275d 100644 --- a/Documentation/devicetree/bindings/memory-controllers/arm,pl353-smc.yaml +++ b/Documentation/devicetree/bindings/memory-controllers/arm,pl353-smc.yaml @@ -57,7 +57,6 @@ properties: ranges: minItems: 1 - maxItems: 3 description: | Memory bus areas for interacting with the devices. Reflects the memory layout with four integer values following: diff --git a/Documentation/devicetree/bindings/mtd/brcm,brcmnand.yaml b/Documentation/devicetree/bindings/mtd/brcm,brcmnand.yaml index e5f1a33332a5..dd5a64969e37 100644 --- a/Documentation/devicetree/bindings/mtd/brcm,brcmnand.yaml +++ b/Documentation/devicetree/bindings/mtd/brcm,brcmnand.yaml @@ -84,7 +84,6 @@ properties: interrupts: minItems: 1 - maxItems: 3 items: - description: NAND CTLRDY interrupt - description: FLASH_DMA_DONE if flash DMA is available @@ -92,7 +91,6 @@ properties: interrupt-names: minItems: 1 - maxItems: 3 items: - const: nand_ctlrdy - const: flash_dma_done @@ -148,8 +146,6 @@ allOf: then: properties: reg-names: - minItems: 2 - maxItems: 2 items: - const: nand - const: nand-int-base @@ -161,8 +157,6 @@ allOf: then: properties: reg-names: - minItems: 3 - maxItems: 3 items: - const: nand - const: nand-int-base @@ -175,8 +169,6 @@ allOf: then: properties: reg-names: - minItems: 3 - maxItems: 3 items: - const: nand - const: iproc-idm diff --git a/Documentation/devicetree/bindings/rtc/faraday,ftrtc010.yaml b/Documentation/devicetree/bindings/rtc/faraday,ftrtc010.yaml index 657c13b62b67..056d42daae06 100644 --- a/Documentation/devicetree/bindings/rtc/faraday,ftrtc010.yaml +++ b/Documentation/devicetree/bindings/rtc/faraday,ftrtc010.yaml @@ -30,7 +30,6 @@ properties: maxItems: 1 clocks: - minItems: 2 items: - description: PCLK clocks - description: EXTCLK clocks. Faraday calls it CLK1HZ and says the clock diff --git a/Documentation/devicetree/bindings/usb/nxp,isp1760.yaml b/Documentation/devicetree/bindings/usb/nxp,isp1760.yaml index a88f99adfe8e..f238848ad094 100644 --- a/Documentation/devicetree/bindings/usb/nxp,isp1760.yaml +++ b/Documentation/devicetree/bindings/usb/nxp,isp1760.yaml @@ -25,14 +25,12 @@ properties: interrupts: minItems: 1 - maxItems: 2 items: - description: Host controller interrupt - description: Device controller interrupt in isp1761 interrupt-names: minItems: 1 - maxItems: 2 items: - const: host - const: peripheral -- cgit v1.2.3 From f88321a3bf775649c685379a25fb9f3f79836bfd Mon Sep 17 00:00:00 2001 From: Rob Herring Date: Tue, 13 Jul 2021 13:35:14 -0600 Subject: dt-bindings: Move fixed string 'patternProperties' to 'properties' There's no need for fixed strings to be under 'patternProperties', so move them under 'properties' instead. Cc: Jean Delvare Cc: Guenter Roeck Cc: Kishon Vijay Abraham I Cc: Vinod Koul Cc: Saravanan Sekar Cc: Mark Brown Cc: Jagan Teki Cc: Troy Kisky Cc: linux-hwmon@vger.kernel.org Cc: linux-phy@lists.infradead.org Cc: linux-spi@vger.kernel.org Signed-off-by: Rob Herring Acked-by: Mark Brown Acked-by: Guenter Roeck Link: https://lore.kernel.org/r/20210713193514.690894-1-robh@kernel.org --- .../devicetree/bindings/hwmon/adt7475.yaml | 22 ++++----- .../devicetree/bindings/phy/ti,phy-j721e-wiz.yaml | 56 +++++++++++----------- .../devicetree/bindings/regulator/mps,mpq7920.yaml | 6 +-- .../bindings/regulator/nxp,pf8x00-regulator.yaml | 3 +- .../devicetree/bindings/spi/spi-controller.yaml | 32 ++++++------- 5 files changed, 60 insertions(+), 59 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/hwmon/adt7475.yaml b/Documentation/devicetree/bindings/hwmon/adt7475.yaml index ad0ec9f35bd8..7d9c083632b9 100644 --- a/Documentation/devicetree/bindings/hwmon/adt7475.yaml +++ b/Documentation/devicetree/bindings/hwmon/adt7475.yaml @@ -39,17 +39,7 @@ properties: reg: maxItems: 1 -patternProperties: - "^adi,bypass-attenuator-in[0-4]$": - description: | - Configures bypassing the individual voltage input attenuator. If - set to 1 the attenuator is bypassed if set to 0 the attenuator is - not bypassed. If the property is absent then the attenuator - retains it's configuration from the bios/bootloader. - $ref: /schemas/types.yaml#/definitions/uint32 - enum: [0, 1] - - "^adi,pwm-active-state$": + adi,pwm-active-state: description: | Integer array, represents the active state of the pwm outputs If set to 0 the pwm uses a logic low output for 100% duty cycle. If set to 1 the pwm @@ -61,6 +51,16 @@ patternProperties: enum: [0, 1] default: 1 +patternProperties: + "^adi,bypass-attenuator-in[0-4]$": + description: | + Configures bypassing the individual voltage input attenuator. If + set to 1 the attenuator is bypassed if set to 0 the attenuator is + not bypassed. If the property is absent then the attenuator + retains it's configuration from the bios/bootloader. + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1] + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/phy/ti,phy-j721e-wiz.yaml b/Documentation/devicetree/bindings/phy/ti,phy-j721e-wiz.yaml index 5272b6f284ba..dcd63908aeae 100644 --- a/Documentation/devicetree/bindings/phy/ti,phy-j721e-wiz.yaml +++ b/Documentation/devicetree/bindings/phy/ti,phy-j721e-wiz.yaml @@ -77,6 +77,34 @@ properties: Type-C spec states minimum CC pin debounce of 100 ms and maximum of 200 ms. However, some solutions might need more than 200 ms. + refclk-dig: + type: object + description: | + WIZ node should have subnode for refclk_dig to select the reference + clock source for the reference clock used in the PHY and PMA digital + logic. + properties: + clocks: + minItems: 2 + maxItems: 4 + description: Phandle to two (Torrent) or four (Sierra) clock nodes representing + the inputs to refclk_dig + + "#clock-cells": + const: 0 + + assigned-clocks: + maxItems: 1 + + assigned-clock-parents: + maxItems: 1 + + required: + - clocks + - "#clock-cells" + - assigned-clocks + - assigned-clock-parents + patternProperties: "^pll[0|1]-refclk$": type: object @@ -121,34 +149,6 @@ patternProperties: - clocks - "#clock-cells" - "^refclk-dig$": - type: object - description: | - WIZ node should have subnode for refclk_dig to select the reference - clock source for the reference clock used in the PHY and PMA digital - logic. - properties: - clocks: - minItems: 2 - maxItems: 4 - description: Phandle to two (Torrent) or four (Sierra) clock nodes representing - the inputs to refclk_dig - - "#clock-cells": - const: 0 - - assigned-clocks: - maxItems: 1 - - assigned-clock-parents: - maxItems: 1 - - required: - - clocks - - "#clock-cells" - - assigned-clocks - - assigned-clock-parents - "^serdes@[0-9a-f]+$": type: object description: | diff --git a/Documentation/devicetree/bindings/regulator/mps,mpq7920.yaml b/Documentation/devicetree/bindings/regulator/mps,mpq7920.yaml index 12b8963615c3..c2e8c54e5311 100644 --- a/Documentation/devicetree/bindings/regulator/mps,mpq7920.yaml +++ b/Documentation/devicetree/bindings/regulator/mps,mpq7920.yaml @@ -36,12 +36,12 @@ properties: switching frequency must be one of following corresponding value 1.1MHz, 1.65MHz, 2.2MHz, 2.75MHz - patternProperties: - "^ldo[1-4]$": + ldortc: type: object $ref: regulator.yaml# - "^ldortc$": + patternProperties: + "^ldo[1-4]$": type: object $ref: regulator.yaml# diff --git a/Documentation/devicetree/bindings/regulator/nxp,pf8x00-regulator.yaml b/Documentation/devicetree/bindings/regulator/nxp,pf8x00-regulator.yaml index 8761437ed8ad..aabf50f5b39e 100644 --- a/Documentation/devicetree/bindings/regulator/nxp,pf8x00-regulator.yaml +++ b/Documentation/devicetree/bindings/regulator/nxp,pf8x00-regulator.yaml @@ -83,7 +83,8 @@ properties: unevaluatedProperties: false - "^vsnvs$": + properties: + vsnvs: type: object $ref: regulator.yaml# description: diff --git a/Documentation/devicetree/bindings/spi/spi-controller.yaml b/Documentation/devicetree/bindings/spi/spi-controller.yaml index faef4f6f55b8..8246891602e7 100644 --- a/Documentation/devicetree/bindings/spi/spi-controller.yaml +++ b/Documentation/devicetree/bindings/spi/spi-controller.yaml @@ -79,22 +79,7 @@ properties: description: The SPI controller acts as a slave, instead of a master. -allOf: - - if: - not: - required: - - spi-slave - then: - properties: - "#address-cells": - const: 1 - else: - properties: - "#address-cells": - const: 0 - -patternProperties: - "^slave$": + slave: type: object properties: @@ -105,6 +90,7 @@ patternProperties: required: - compatible +patternProperties: "^.*@[0-9a-f]+$": type: object @@ -180,6 +166,20 @@ patternProperties: - compatible - reg +allOf: + - if: + not: + required: + - spi-slave + then: + properties: + "#address-cells": + const: 1 + else: + properties: + "#address-cells": + const: 0 + additionalProperties: true examples: -- cgit v1.2.3 From 24519fa7f91507d3299018bf4b066dd7b1ccff60 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Rafa=C5=82=20Mi=C5=82ecki?= Date: Tue, 13 Jul 2021 11:31:55 +0200 Subject: dt-bindings: i2c: brcm,iproc-i2c: convert to the json-schema MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit This helps validating DTS files. Introduced changes: 1. Added arm-gic.h include Signed-off-by: Rafał Miłecki Link: https://lore.kernel.org/r/20210713093155.1752-1-zajec5@gmail.com Signed-off-by: Rob Herring --- .../devicetree/bindings/i2c/brcm,iproc-i2c.txt | 46 -------------- .../devicetree/bindings/i2c/brcm,iproc-i2c.yaml | 71 ++++++++++++++++++++++ 2 files changed, 71 insertions(+), 46 deletions(-) delete mode 100644 Documentation/devicetree/bindings/i2c/brcm,iproc-i2c.txt create mode 100644 Documentation/devicetree/bindings/i2c/brcm,iproc-i2c.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/i2c/brcm,iproc-i2c.txt b/Documentation/devicetree/bindings/i2c/brcm,iproc-i2c.txt deleted file mode 100644 index d12cc33cca6c..000000000000 --- a/Documentation/devicetree/bindings/i2c/brcm,iproc-i2c.txt +++ /dev/null @@ -1,46 +0,0 @@ -Broadcom iProc I2C controller - -Required properties: - -- compatible: - Must be "brcm,iproc-i2c" or "brcm,iproc-nic-i2c" - -- reg: - Define the base and range of the I/O address space that contain the iProc - I2C controller registers - -- clock-frequency: - This is the I2C bus clock. Need to be either 100000 or 400000 - -- #address-cells: - Always 1 (for I2C addresses) - -- #size-cells: - Always 0 - -Optional properties: - -- interrupts: - Should contain the I2C interrupt. For certain revisions of the I2C - controller, I2C interrupt is unwired to the interrupt controller. In such - case, this property should be left unspecified, and driver will fall back - to polling mode - -- brcm,ape-hsls-addr-mask: - Required for "brcm,iproc-nic-i2c". Host view of address mask into the - 'APE' co-processor. Value must be unsigned, 32-bit - -Example: - i2c0: i2c@18008000 { - compatible = "brcm,iproc-i2c"; - reg = <0x18008000 0x100>; - #address-cells = <1>; - #size-cells = <0>; - interrupts = ; - clock-frequency = <100000>; - - codec: wm8750@1a { - compatible = "wlf,wm8750"; - reg = <0x1a>; - }; - }; diff --git a/Documentation/devicetree/bindings/i2c/brcm,iproc-i2c.yaml b/Documentation/devicetree/bindings/i2c/brcm,iproc-i2c.yaml new file mode 100644 index 000000000000..2aa75b7add7b --- /dev/null +++ b/Documentation/devicetree/bindings/i2c/brcm,iproc-i2c.yaml @@ -0,0 +1,71 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/i2c/brcm,iproc-i2c.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Broadcom iProc I2C controller + +maintainers: + - Rafał Miłecki + +properties: + compatible: + enum: + - brcm,iproc-i2c + - brcm,iproc-nic-i2c + + reg: + maxItems: 1 + + clock-frequency: + enum: [ 100000, 400000 ] + + interrupts: + description: | + Should contain the I2C interrupt. For certain revisions of the I2C + controller, I2C interrupt is unwired to the interrupt controller. In such + case, this property should be left unspecified, and driver will fall back + to polling mode + maxItems: 1 + + brcm,ape-hsls-addr-mask: + $ref: /schemas/types.yaml#/definitions/uint32 + description: Host view of address mask into the 'APE' co-processor + +allOf: + - $ref: /schemas/i2c/i2c-controller.yaml# + - if: + properties: + compatible: + contains: + const: brcm,iproc-nic-i2c + then: + required: + - brcm,ape-hsls-addr-mask + +unevaluatedProperties: false + +required: + - reg + - clock-frequency + - '#address-cells' + - '#size-cells' + +examples: + - | + #include + + i2c@18008000 { + compatible = "brcm,iproc-i2c"; + reg = <0x18008000 0x100>; + #address-cells = <1>; + #size-cells = <0>; + interrupts = ; + clock-frequency = <100000>; + + wm8750@1a { + compatible = "wlf,wm8750"; + reg = <0x1a>; + }; + }; -- cgit v1.2.3 From 9a3223b0713369e6258fd8656e0c0a5ed794d186 Mon Sep 17 00:00:00 2001 From: Rob Herring Date: Thu, 15 Jul 2021 12:59:52 -0600 Subject: ASoC: dt-bindings: renesas: rsnd: Fix incorrect 'port' regex schema A property regex goes under 'patternProperties', not 'properties' schema. Otherwise, the regex is interpretted as a fixed string. Fixes: 17c2d247ddd2 ("ASoC: dt-bindings: renesas: rsnd: tidyup properties") Cc: Mark Brown Cc: Kuninori Morimoto Cc: alsa-devel@alsa-project.org Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20210715185952.1470138-1-robh@kernel.org Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/sound/renesas,rsnd.yaml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/renesas,rsnd.yaml b/Documentation/devicetree/bindings/sound/renesas,rsnd.yaml index ee936d1aa724..c2930d65728e 100644 --- a/Documentation/devicetree/bindings/sound/renesas,rsnd.yaml +++ b/Documentation/devicetree/bindings/sound/renesas,rsnd.yaml @@ -114,7 +114,7 @@ properties: ports: $ref: /schemas/graph.yaml#/properties/ports - properties: + patternProperties: port(@[0-9a-f]+)?: $ref: audio-graph-port.yaml# unevaluatedProperties: false -- cgit v1.2.3 From 742f62cb06720c12677f0bb05c64c9eeab34c8ec Mon Sep 17 00:00:00 2001 From: Johan Jonker Date: Fri, 25 Jun 2021 13:17:43 +0200 Subject: dt-bindings: power: convert rockchip-io-domain.txt to YAML Current dts files with 'io-domains' nodes are manually verified. In order to automate this process rockchip-io-domain.txt has to be converted to YAML. Changed: Add supply properties for: rockchip,rk3328-io-voltage-domain rockchip,rv1108-io-voltage-domain rockchip,rv1108-pmu-io-voltage-domain Signed-off-by: Johan Jonker Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20210625111746.6269-1-jbx6244@gmail.com Signed-off-by: Heiko Stuebner --- .../bindings/power/rockchip-io-domain.txt | 135 --------- .../bindings/power/rockchip-io-domain.yaml | 330 +++++++++++++++++++++ 2 files changed, 330 insertions(+), 135 deletions(-) delete mode 100644 Documentation/devicetree/bindings/power/rockchip-io-domain.txt create mode 100644 Documentation/devicetree/bindings/power/rockchip-io-domain.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/power/rockchip-io-domain.txt b/Documentation/devicetree/bindings/power/rockchip-io-domain.txt deleted file mode 100644 index e66fd4eab71c..000000000000 --- a/Documentation/devicetree/bindings/power/rockchip-io-domain.txt +++ /dev/null @@ -1,135 +0,0 @@ -Rockchip SRAM for IO Voltage Domains: -------------------------------------- - -IO domain voltages on some Rockchip SoCs are variable but need to be -kept in sync between the regulators and the SoC using a special -register. - -A specific example using rk3288: -- If the regulator hooked up to a pin like SDMMC0_VDD is 3.3V then - bit 7 of GRF_IO_VSEL needs to be 0. If the regulator hooked up to - that same pin is 1.8V then bit 7 of GRF_IO_VSEL needs to be 1. - -Said another way, this driver simply handles keeping bits in the SoC's -general register file (GRF) in sync with the actual value of a voltage -hooked up to the pins. - -Note that this driver specifically doesn't include: -- any logic for deciding what voltage we should set regulators to -- any logic for deciding whether regulators (or internal SoC blocks) - should have power or not have power - -If there were some other software that had the smarts of making -decisions about regulators, it would work in conjunction with this -driver. When that other software adjusted a regulator's voltage then -this driver would handle telling the SoC about it. A good example is -vqmmc for SD. In that case the dw_mmc driver simply is told about a -regulator. It changes the regulator between 3.3V and 1.8V at the -right time. This driver notices the change and makes sure that the -SoC is on the same page. - - -Required properties: -- compatible: should be one of: - - "rockchip,px30-io-voltage-domain" for px30 - - "rockchip,px30-pmu-io-voltage-domain" for px30 pmu-domains - - "rockchip,rk3188-io-voltage-domain" for rk3188 - - "rockchip,rk3228-io-voltage-domain" for rk3228 - - "rockchip,rk3288-io-voltage-domain" for rk3288 - - "rockchip,rk3328-io-voltage-domain" for rk3328 - - "rockchip,rk3368-io-voltage-domain" for rk3368 - - "rockchip,rk3368-pmu-io-voltage-domain" for rk3368 pmu-domains - - "rockchip,rk3399-io-voltage-domain" for rk3399 - - "rockchip,rk3399-pmu-io-voltage-domain" for rk3399 pmu-domains - - "rockchip,rv1108-io-voltage-domain" for rv1108 - - "rockchip,rv1108-pmu-io-voltage-domain" for rv1108 pmu-domains - -Deprecated properties: -- rockchip,grf: phandle to the syscon managing the "general register files" - Systems should move the io-domains to a sub-node of the grf simple-mfd. - -You specify supplies using the standard regulator bindings by including -a phandle the relevant regulator. All specified supplies must be able -to report their voltage. The IO Voltage Domain for any non-specified -supplies will be not be touched. - -Possible supplies for PX30: -- vccio6-supply: The supply connected to VCCIO6. -- vccio1-supply: The supply connected to VCCIO1. -- vccio2-supply: The supply connected to VCCIO2. -- vccio3-supply: The supply connected to VCCIO3. -- vccio4-supply: The supply connected to VCCIO4. -- vccio5-supply: The supply connected to VCCIO5. -- vccio-oscgpi-supply: The supply connected to VCCIO_OSCGPI. - -Possible supplies for PX30 pmu-domains: -- pmuio1-supply: The supply connected to PMUIO1. -- pmuio2-supply: The supply connected to PMUIO2. - -Possible supplies for rk3188: -- ap0-supply: The supply connected to AP0_VCC. -- ap1-supply: The supply connected to AP1_VCC. -- cif-supply: The supply connected to CIF_VCC. -- flash-supply: The supply connected to FLASH_VCC. -- lcdc0-supply: The supply connected to LCD0_VCC. -- lcdc1-supply: The supply connected to LCD1_VCC. -- vccio0-supply: The supply connected to VCCIO0. -- vccio1-supply: The supply connected to VCCIO1. - Sometimes also labeled VCCIO1 and VCCIO2. - -Possible supplies for rk3228: -- vccio1-supply: The supply connected to VCCIO1. -- vccio2-supply: The supply connected to VCCIO2. -- vccio3-supply: The supply connected to VCCIO3. -- vccio4-supply: The supply connected to VCCIO4. - -Possible supplies for rk3288: -- audio-supply: The supply connected to APIO4_VDD. -- bb-supply: The supply connected to APIO5_VDD. -- dvp-supply: The supply connected to DVPIO_VDD. -- flash0-supply: The supply connected to FLASH0_VDD. Typically for eMMC -- flash1-supply: The supply connected to FLASH1_VDD. Also known as SDIO1. -- gpio30-supply: The supply connected to APIO1_VDD. -- gpio1830 The supply connected to APIO2_VDD. -- lcdc-supply: The supply connected to LCDC_VDD. -- sdcard-supply: The supply connected to SDMMC0_VDD. -- wifi-supply: The supply connected to APIO3_VDD. Also known as SDIO0. - -Possible supplies for rk3368: -- audio-supply: The supply connected to APIO3_VDD. -- dvp-supply: The supply connected to DVPIO_VDD. -- flash0-supply: The supply connected to FLASH0_VDD. Typically for eMMC -- gpio30-supply: The supply connected to APIO1_VDD. -- gpio1830 The supply connected to APIO4_VDD. -- sdcard-supply: The supply connected to SDMMC0_VDD. -- wifi-supply: The supply connected to APIO2_VDD. Also known as SDIO0. - -Possible supplies for rk3368 pmu-domains: -- pmu-supply: The supply connected to PMUIO_VDD. -- vop-supply: The supply connected to LCDC_VDD. - -Possible supplies for rk3399: -- bt656-supply: The supply connected to APIO2_VDD. -- audio-supply: The supply connected to APIO5_VDD. -- sdmmc-supply: The supply connected to SDMMC0_VDD. -- gpio1830 The supply connected to APIO4_VDD. - -Possible supplies for rk3399 pmu-domains: -- pmu1830-supply:The supply connected to PMUIO2_VDD. - -Example: - - io-domains { - compatible = "rockchip,rk3288-io-voltage-domain"; - rockchip,grf = <&grf>; - - audio-supply = <&vcc18_codec>; - bb-supply = <&vcc33_io>; - dvp-supply = <&vcc_18>; - flash0-supply = <&vcc18_flashio>; - gpio1830-supply = <&vcc33_io>; - gpio30-supply = <&vcc33_pmuio>; - lcdc-supply = <&vcc33_lcd>; - sdcard-supply = <&vccio_sd>; - wifi-supply = <&vcc18_wl>; - }; diff --git a/Documentation/devicetree/bindings/power/rockchip-io-domain.yaml b/Documentation/devicetree/bindings/power/rockchip-io-domain.yaml new file mode 100644 index 000000000000..121bec56b2b0 --- /dev/null +++ b/Documentation/devicetree/bindings/power/rockchip-io-domain.yaml @@ -0,0 +1,330 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/power/rockchip-io-domain.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Rockchip SRAM for IO Voltage Domains + +maintainers: + - Heiko Stuebner + +description: | + IO domain voltages on some Rockchip SoCs are variable but need to be + kept in sync between the regulators and the SoC using a special + register. + + A specific example using rk3288 + If the regulator hooked up to a pin like SDMMC0_VDD is 3.3V then + bit 7 of GRF_IO_VSEL needs to be 0. If the regulator hooked up to + that same pin is 1.8V then bit 7 of GRF_IO_VSEL needs to be 1. + + Said another way, this driver simply handles keeping bits in the SoCs + General Register File (GRF) in sync with the actual value of a voltage + hooked up to the pins. + + Note that this driver specifically does not include + any logic for deciding what voltage we should set regulators to + any logic for deciding whether regulators (or internal SoC blocks) + should have power or not have power + + If there were some other software that had the smarts of making + decisions about regulators, it would work in conjunction with this + driver. When that other software adjusted a regulators voltage then + this driver would handle telling the SoC about it. A good example is + vqmmc for SD. In that case the dw_mmc driver simply is told about a + regulator. It changes the regulator between 3.3V and 1.8V at the + right time. This driver notices the change and makes sure that the + SoC is on the same page. + + You specify supplies using the standard regulator bindings by including + a phandle the relevant regulator. All specified supplies must be able + to report their voltage. The IO Voltage Domain for any non-specified + supplies will be not be touched. + +properties: + compatible: + enum: + - rockchip,px30-io-voltage-domain + - rockchip,px30-pmu-io-voltage-domain + - rockchip,rk3188-io-voltage-domain + - rockchip,rk3228-io-voltage-domain + - rockchip,rk3288-io-voltage-domain + - rockchip,rk3328-io-voltage-domain + - rockchip,rk3368-io-voltage-domain + - rockchip,rk3368-pmu-io-voltage-domain + - rockchip,rk3399-io-voltage-domain + - rockchip,rk3399-pmu-io-voltage-domain + - rockchip,rv1108-io-voltage-domain + - rockchip,rv1108-pmu-io-voltage-domain + +required: + - compatible + +unevaluatedProperties: false + +allOf: + - $ref: "#/$defs/px30" + - $ref: "#/$defs/px30-pmu" + - $ref: "#/$defs/rk3188" + - $ref: "#/$defs/rk3228" + - $ref: "#/$defs/rk3288" + - $ref: "#/$defs/rk3328" + - $ref: "#/$defs/rk3368" + - $ref: "#/$defs/rk3368-pmu" + - $ref: "#/$defs/rk3399" + - $ref: "#/$defs/rk3399-pmu" + - $ref: "#/$defs/rv1108" + - $ref: "#/$defs/rv1108-pmu" + +$defs: + px30: + if: + properties: + compatible: + contains: + const: rockchip,px30-io-voltage-domain + + then: + properties: + vccio1-supply: + description: The supply connected to VCCIO1. + vccio2-supply: + description: The supply connected to VCCIO2. + vccio3-supply: + description: The supply connected to VCCIO3. + vccio4-supply: + description: The supply connected to VCCIO4. + vccio5-supply: + description: The supply connected to VCCIO5. + vccio6-supply: + description: The supply connected to VCCIO6. + vccio-oscgpi-supply: + description: The supply connected to VCCIO_OSCGPI. + + px30-pmu: + if: + properties: + compatible: + contains: + const: rockchip,px30-pmu-io-voltage-domain + + then: + properties: + pmuio1-supply: + description: The supply connected to PMUIO1. + pmuio2-supply: + description: The supply connected to PMUIO2. + + rk3188: + if: + properties: + compatible: + contains: + const: rockchip,rk3188-io-voltage-domain + + then: + properties: + ap0-supply: + description: The supply connected to AP0_VCC. + ap1-supply: + description: The supply connected to AP1_VCC. + cif-supply: + description: The supply connected to CIF_VCC. + flash-supply: + description: The supply connected to FLASH_VCC. + lcdc0-supply: + description: The supply connected to LCD0_VCC. + lcdc1-supply: + description: The supply connected to LCD1_VCC. + vccio0-supply: + description: The supply connected to VCCIO0. + vccio1-supply: + description: The supply connected to VCCIO1. Also labeled as VCCIO2. + + rk3228: + if: + properties: + compatible: + contains: + const: rockchip,rk3228-io-voltage-domain + + then: + properties: + vccio1-supply: + description: The supply connected to VCCIO1. + vccio2-supply: + description: The supply connected to VCCIO2. + vccio3-supply: + description: The supply connected to VCCIO3. + vccio4-supply: + description: The supply connected to VCCIO4. + + rk3288: + if: + properties: + compatible: + contains: + const: rockchip,rk3288-io-voltage-domain + + then: + properties: + audio-supply: + description: The supply connected to APIO4_VDD. + bb-supply: + description: The supply connected to APIO5_VDD. + dvp-supply: + description: The supply connected to DVPIO_VDD. + flash0-supply: + description: The supply connected to FLASH0_VDD. Typically for eMMC. + flash1-supply: + description: The supply connected to FLASH1_VDD. Also known as SDIO1. + gpio30-supply: + description: The supply connected to APIO1_VDD. + gpio1830-supply: + description: The supply connected to APIO2_VDD. + lcdc-supply: + description: The supply connected to LCDC_VDD. + sdcard-supply: + description: The supply connected to SDMMC0_VDD. + wifi-supply: + description: The supply connected to APIO3_VDD. Also known as SDIO0. + + rk3328: + if: + properties: + compatible: + contains: + const: rockchip,rk3328-io-voltage-domain + + then: + properties: + vccio1-supply: + description: The supply connected to VCCIO1. + vccio2-supply: + description: The supply connected to VCCIO2. + vccio3-supply: + description: The supply connected to VCCIO3. + vccio4-supply: + description: The supply connected to VCCIO4. + vccio5-supply: + description: The supply connected to VCCIO5. + vccio6-supply: + description: The supply connected to VCCIO6. + pmuio-supply: + description: The supply connected to VCCIO_PMU. + + rk3368: + if: + properties: + compatible: + contains: + const: rockchip,rk3368-io-voltage-domain + + then: + properties: + audio-supply: + description: The supply connected to APIO3_VDD. + dvp-supply: + description: The supply connected to DVPIO_VDD. + flash0-supply: + description: The supply connected to FLASH0_VDD. Typically for eMMC. + gpio30-supply: + description: The supply connected to APIO1_VDD. + gpio1830-supply: + description: The supply connected to APIO4_VDD. + sdcard-supply: + description: The supply connected to SDMMC0_VDD. + wifi-supply: + description: The supply connected to APIO2_VDD. Also known as SDIO0. + + rk3368-pmu: + if: + properties: + compatible: + contains: + const: rockchip,rk3368-pmu-io-voltage-domain + + then: + properties: + pmu-supply: + description: The supply connected to PMUIO_VDD. + vop-supply: + description: The supply connected to LCDC_VDD. + + rk3399: + if: + properties: + compatible: + contains: + const: rockchip,rk3399-io-voltage-domain + + then: + properties: + audio-supply: + description: The supply connected to APIO5_VDD. + bt656-supply: + description: The supply connected to APIO2_VDD. + gpio1830-supply: + description: The supply connected to APIO4_VDD. + sdmmc-supply: + description: The supply connected to SDMMC0_VDD. + + rk3399-pmu: + if: + properties: + compatible: + contains: + const: rockchip,rk3399-pmu-io-voltage-domain + + then: + properties: + pmu1830-supply: + description: The supply connected to PMUIO2_VDD. + + rv1108: + if: + properties: + compatible: + contains: + const: rockchip,rv1108-io-voltage-domain + + then: + properties: + vccio1-supply: + description: The supply connected to APIO1_VDD. + vccio2-supply: + description: The supply connected to APIO2_VDD. + vccio3-supply: + description: The supply connected to APIO3_VDD. + vccio5-supply: + description: The supply connected to APIO5_VDD. + vccio6-supply: + description: The supply connected to APIO6_VDD. + + rv1108-pmu: + if: + properties: + compatible: + contains: + const: rockchip,rv1108-pmu-io-voltage-domain + + then: + properties: + pmu-supply: + description: The supply connected to PMUIO_VDD. + +examples: + - | + io-domains { + compatible = "rockchip,rk3288-io-voltage-domain"; + audio-supply = <&vcc18_codec>; + bb-supply = <&vcc33_io>; + dvp-supply = <&vcc_18>; + flash0-supply = <&vcc18_flashio>; + gpio1830-supply = <&vcc33_io>; + gpio30-supply = <&vcc33_pmuio>; + lcdc-supply = <&vcc33_lcd>; + sdcard-supply = <&vccio_sd>; + wifi-supply = <&vcc18_wl>; + }; -- cgit v1.2.3 From 959e131fb5c3a08293178e94a184b5bf28974bb4 Mon Sep 17 00:00:00 2001 From: Johan Jonker Date: Fri, 25 Jun 2021 13:17:44 +0200 Subject: dt-bindings: soc: rockchip: add rockchip-io-domain.yaml object to grf.yaml The rockchip-io-domain.txt file was converted to YAML. IO Voltage Domain nodes are sub nodes of grf and pmugrf nodes. Add rockchip-io-domain.yaml object to the grf.yaml file. Signed-off-by: Johan Jonker Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20210625111746.6269-2-jbx6244@gmail.com Signed-off-by: Heiko Stuebner --- .../devicetree/bindings/soc/rockchip/grf.yaml | 18 ++++++++++++------ 1 file changed, 12 insertions(+), 6 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/soc/rockchip/grf.yaml b/Documentation/devicetree/bindings/soc/rockchip/grf.yaml index 62fa72cfea34..fa010df51a5c 100644 --- a/Documentation/devicetree/bindings/soc/rockchip/grf.yaml +++ b/Documentation/devicetree/bindings/soc/rockchip/grf.yaml @@ -15,7 +15,6 @@ properties: - items: - enum: - rockchip,rk3288-sgrf - - rockchip,rv1108-pmugrf - rockchip,rv1108-usbgrf - const: syscon - items: @@ -41,6 +40,7 @@ properties: - rockchip,rk3568-grf - rockchip,rk3568-pmugrf - rockchip,rv1108-grf + - rockchip,rv1108-pmugrf - const: syscon - const: simple-mfd @@ -198,21 +198,27 @@ allOf: compatible: contains: enum: - - rockchip,px30-pmugrf - rockchip,px30-grf + - rockchip,px30-pmugrf + - rockchip,rk3188-grf - rockchip,rk3228-grf - rockchip,rk3288-grf - rockchip,rk3328-grf - - rockchip,rk3368-pmugrf - rockchip,rk3368-grf - - rockchip,rk3399-pmugrf + - rockchip,rk3368-pmugrf - rockchip,rk3399-grf + - rockchip,rk3399-pmugrf + - rockchip,rv1108-grf + - rockchip,rv1108-pmugrf then: properties: io-domains: - description: - Documentation/devicetree/bindings/power/rockchip-io-domain.txt + type: object + + $ref: "/schemas/power/rockchip-io-domain.yaml#" + + unevaluatedProperties: false examples: - | -- cgit v1.2.3 From ff44b90b325dcd585cdba6ded6c9c52ea8ddead0 Mon Sep 17 00:00:00 2001 From: Corentin Labbe Date: Mon, 28 Jun 2021 19:14:40 +0000 Subject: dt_bindings: mtd: partitions: redboot: convert to YAML Converts mtd/partitions/redboot-fis.txt to YAML. Signed-off-by: Corentin Labbe Reviewed-by: Linus Walleij Reviewed-by: Rob Herring Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20210628191440.2823024-1-clabbe@baylibre.com --- .../bindings/mtd/partitions/redboot-fis.txt | 27 -------------- .../bindings/mtd/partitions/redboot-fis.yaml | 42 ++++++++++++++++++++++ 2 files changed, 42 insertions(+), 27 deletions(-) delete mode 100644 Documentation/devicetree/bindings/mtd/partitions/redboot-fis.txt create mode 100644 Documentation/devicetree/bindings/mtd/partitions/redboot-fis.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mtd/partitions/redboot-fis.txt b/Documentation/devicetree/bindings/mtd/partitions/redboot-fis.txt deleted file mode 100644 index fd0ebe4e3415..000000000000 --- a/Documentation/devicetree/bindings/mtd/partitions/redboot-fis.txt +++ /dev/null @@ -1,27 +0,0 @@ -RedBoot FLASH Image System (FIS) Partitions -=========================================== - -The FLASH Image System (FIS) directory is a flash description -format closely associated with the RedBoot boot loader. - -It uses one single flash eraseblock in the flash to store an index of -all images in the flash. - -This block size will vary depending on flash but is typically -32 KB in size. - -Required properties: -- compatible : (required) must be "redboot-fis" -- fis-index-block : (required) a index to the eraseblock containing - the FIS directory on this device. On a flash memory with 32KB - eraseblocks, 0 means the first eraseblock at 0x00000000, 1 means the - second eraseblock at 0x00008000 and so on. - -Example: - -flash@0 { - partitions { - compatible = "redboot-fis"; - fis-index-block = <0>; - }; -}; diff --git a/Documentation/devicetree/bindings/mtd/partitions/redboot-fis.yaml b/Documentation/devicetree/bindings/mtd/partitions/redboot-fis.yaml new file mode 100644 index 000000000000..fee8d81b5276 --- /dev/null +++ b/Documentation/devicetree/bindings/mtd/partitions/redboot-fis.yaml @@ -0,0 +1,42 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mtd/partitions/redboot-fis.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: RedBoot FLASH Image System (FIS) Partitions + +description: The FLASH Image System (FIS) directory is a flash description + format closely associated with the RedBoot boot loader. + It uses one single flash eraseblock in the flash to store an index of + all images in the flash. + This block size will vary depending on flash but is typically + 32 KB in size. + +maintainers: + - Linus Walleij + +properties: + compatible: + const: redboot-fis + + fis-index-block: + $ref: /schemas/types.yaml#/definitions/uint32 + description: a index to the eraseblock containing the FIS directory on this + device. On a flash memory with 32KB eraseblocks, 0 means the first + eraseblock at 0x00000000, 1 means the second eraseblock at 0x00008000 and so on. + +required: + - compatible + - fis-index-block + +additionalProperties: false + +examples: + - | + flash { + partitions { + compatible = "redboot-fis"; + fis-index-block = <0>; + }; + }; -- cgit v1.2.3 From 778cb8e39f6ec252be50fc3850d66f3dcbd5dd5a Mon Sep 17 00:00:00 2001 From: Miquel Raynal Date: Thu, 10 Jun 2021 16:39:45 +0200 Subject: dt-bindings: mtd: gpmc: Fix the ECC bytes vs. OOB bytes equation "PAGESIZE / 512" is the number of ECC chunks. "ECC_BYTES" is the number of bytes needed to store a single ECC code. "2" is the space reserved by the bad block marker. "2 + (PAGESIZE / 512) * ECC_BYTES" should of course be lower or equal than the total number of OOB bytes, otherwise it won't fit. Fix the equation by substituting s/>=/<=/. Suggested-by: Ryan J. Barnett Signed-off-by: Miquel Raynal Acked-by: Rob Herring Link: https://lore.kernel.org/linux-mtd/20210610143945.3504781-1-miquel.raynal@bootlin.com --- Documentation/devicetree/bindings/mtd/gpmc-nand.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt index 44919d48d241..c459f169a904 100644 --- a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt +++ b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt @@ -122,7 +122,7 @@ on various other factors also like; so the device should have enough free bytes available its OOB/Spare area to accommodate ECC for entire page. In general following expression helps in determining if given device can accommodate ECC syndrome: - "2 + (PAGESIZE / 512) * ECC_BYTES" >= OOBSIZE" + "2 + (PAGESIZE / 512) * ECC_BYTES" <= OOBSIZE" where OOBSIZE number of bytes in OOB/spare area PAGESIZE number of bytes in main-area of device page -- cgit v1.2.3 From 1cbf731ef3a17b3dd4c22ed0c634ac126d1a4876 Mon Sep 17 00:00:00 2001 From: Maarten Lankhorst Date: Fri, 9 Jul 2021 13:38:42 +0200 Subject: drm/i915: Fix missing docbook chapters for i915 uapi. I noticed when grepping for DOC: that those were defined in the header, but not actually used. Fix it by removing all chapters and the internal annotation, so the docbook generated chapters are used. This reverts the changes to driver-uapi.rst by the referenced commit 577729533cdc ("drm/i915: Document the Virtual Engine uAPI") Signed-off-by: Maarten Lankhorst Link: https://patchwork.freedesktop.org/patch/msgid/20210715120842.806605-1-maarten.lankhorst@linux.intel.com Fixes: 577729533cdc ("drm/i915: Document the Virtual Engine uAPI") Cc: Tvrtko Ursulin Reviewed-by: Matthew Auld --- Documentation/gpu/driver-uapi.rst | 21 --------------------- 1 file changed, 21 deletions(-) (limited to 'Documentation') diff --git a/Documentation/gpu/driver-uapi.rst b/Documentation/gpu/driver-uapi.rst index 27d0fbe33e87..4411e6919a3d 100644 --- a/Documentation/gpu/driver-uapi.rst +++ b/Documentation/gpu/driver-uapi.rst @@ -5,25 +5,4 @@ DRM Driver uAPI drm/i915 uAPI ============= -Engine Discovery uAPI ---------------------- - -.. kernel-doc:: include/uapi/drm/i915_drm.h - :doc: Engine Discovery uAPI - -Context Engine Map uAPI ------------------------ - -.. kernel-doc:: include/uapi/drm/i915_drm.h - :doc: Context Engine Map uAPI - -Virtual Engine uAPI -------------------- - -.. kernel-doc:: include/uapi/drm/i915_drm.h - :doc: Virtual Engine uAPI - -i915_drm.h ----------- .. kernel-doc:: include/uapi/drm/i915_drm.h - :internal: -- cgit v1.2.3 From 50d8d7e19c4398da74d028f367754e73547b078b Mon Sep 17 00:00:00 2001 From: Geert Uytterhoeven Date: Wed, 14 Jul 2021 12:19:36 +0200 Subject: dt-bindings: display: renesas,du: Make resets optional on R-Car H1 The "resets" property is not present on R-Car Gen1 SoCs. Supporting it would require migrating from renesas,cpg-clocks to renesas,cpg-mssr. Reflect this in the DT bindings by removing the global "required: resets". All SoCs that do have "resets" properties already have SoC-specific rules making it required. Fixes: 99d66127fad25ebb ("dt-bindings: display: renesas,du: Convert binding to YAML") Signed-off-by: Geert Uytterhoeven Reviewed-by: Laurent Pinchart Link: https://lore.kernel.org/r/98575791b154d80347d5b78132c1d53f5315ee62.1626257936.git.geert+renesas@glider.be Signed-off-by: Rob Herring --- Documentation/devicetree/bindings/display/renesas,du.yaml | 1 - 1 file changed, 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/renesas,du.yaml b/Documentation/devicetree/bindings/display/renesas,du.yaml index 5f4345d43020..e3ca5389c17d 100644 --- a/Documentation/devicetree/bindings/display/renesas,du.yaml +++ b/Documentation/devicetree/bindings/display/renesas,du.yaml @@ -92,7 +92,6 @@ required: - reg - clocks - interrupts - - resets - ports allOf: -- cgit v1.2.3 From 96e4781b3d9399ab75c4d2d8b5833c7e8d60ff6b Mon Sep 17 00:00:00 2001 From: Joakim Zhang Date: Fri, 16 Jul 2021 18:29:09 +0800 Subject: dt-bindings: net: fec: convert fsl,*fec bindings to yaml In order to automate the verification of DT nodes convert fsl-fec.txt to fsl,fec.yaml, and pass binding check with below command. $ make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- dt_binding_check DT_SCHEMA_FILES=Documentation/devicetree/bindings/net/fsl,fec.yaml DTEX Documentation/devicetree/bindings/net/fsl,fec.example.dts DTC Documentation/devicetree/bindings/net/fsl,fec.example.dt.yaml CHECK Documentation/devicetree/bindings/net/fsl,fec.example.dt.yaml Signed-off-by: Joakim Zhang Signed-off-by: David S. Miller --- Documentation/devicetree/bindings/net/fsl,fec.yaml | 213 +++++++++++++++++++++ Documentation/devicetree/bindings/net/fsl-fec.txt | 95 --------- 2 files changed, 213 insertions(+), 95 deletions(-) create mode 100644 Documentation/devicetree/bindings/net/fsl,fec.yaml delete mode 100644 Documentation/devicetree/bindings/net/fsl-fec.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/fsl,fec.yaml b/Documentation/devicetree/bindings/net/fsl,fec.yaml new file mode 100644 index 000000000000..7fa11f6622b1 --- /dev/null +++ b/Documentation/devicetree/bindings/net/fsl,fec.yaml @@ -0,0 +1,213 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/fsl,fec.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Freescale Fast Ethernet Controller (FEC) + +maintainers: + - Joakim Zhang + +allOf: + - $ref: ethernet-controller.yaml# + +properties: + compatible: + oneOf: + - enum: + - fsl,imx25-fec + - fsl,imx27-fec + - fsl,imx28-fec + - fsl,imx6q-fec + - fsl,mvf600-fec + - items: + - enum: + - fsl,imx53-fec + - fsl,imx6sl-fec + - const: fsl,imx25-fec + - items: + - enum: + - fsl,imx35-fec + - fsl,imx51-fec + - const: fsl,imx27-fec + - items: + - enum: + - fsl,imx6ul-fec + - fsl,imx6sx-fec + - const: fsl,imx6q-fec + - items: + - enum: + - fsl,imx7d-fec + - const: fsl,imx6sx-fec + + reg: + maxItems: 1 + + interrupts: + minItems: 1 + maxItems: 4 + + interrupt-names: + description: + 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). + + clocks: + minItems: 2 + maxItems: 5 + description: + The "ipg", for MAC ipg_clk_s, ipg_clk_mac_s that are for register accessing. + The "ahb", for MAC ipg_clk, ipg_clk_mac that are bus clock. + The "ptp"(option), for IEEE1588 timer clock that requires the clock. + The "enet_clk_ref"(option), for MAC transmit/receiver reference clock like + RGMII TXC clock or RMII reference clock. It depends on board design, + the clock is required if RGMII TXC and RMII reference clock source from + SOC internal PLL. + The "enet_out"(option), output clock for external device, like supply clock + for PHY. The clock is required if PHY clock source from SOC. + + clock-names: + minItems: 2 + maxItems: 5 + contains: + enum: + - ipg + - ahb + - ptp + - enet_clk_ref + - enet_out + + phy-mode: true + + phy-handle: true + + fixed-link: true + + local-mac-address: true + + mac-address: true + + phy-supply: + description: + Regulator that powers the Ethernet PHY. + + fsl,num-tx-queues: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + The property is valid for enet-avb IP, which supports hw multi queues. + Should specify the tx queue number, otherwise set tx queue number to 1. + + fsl,num-rx-queues: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + The property is valid for enet-avb IP, which supports hw multi queues. + Should specify the rx queue number, otherwise set rx queue number to 1. + + fsl,magic-packet: + $ref: /schemas/types.yaml#/definitions/flag + description: + If present, indicates that the hardware supports waking up via magic packet. + + fsl,err006687-workaround-present: + $ref: /schemas/types.yaml#/definitions/flag + description: + If present indicates that the system has the hardware workaround for + ERR006687 applied and does not need a software workaround. + + fsl,stop-mode: + $ref: /schemas/types.yaml#/definitions/phandle-array + description: + Register bits of stop mode control, the format is <&gpr req_gpr req_bit>. + gpr is the phandle to general purpose register node. + req_gpr is the gpr register offset for ENET stop request. + req_bit is the gpr bit offset for ENET stop request. + + mdio: + type: object + description: + Specifies the mdio bus in the FEC, used as a container for phy nodes. + + # Deprecated optional properties: + # To avoid these, create a phy node according to ethernet-phy.yaml in the same + # directory, and point the FEC's "phy-handle" property to it. Then use + # the phy's reset binding, again described by ethernet-phy.yaml. + + phy-reset-gpios: + deprecated: true + description: + Should specify the gpio for phy reset. + + phy-reset-duration: + deprecated: true + description: + Reset duration in milliseconds. Should present only if property + "phy-reset-gpios" is available. Missing the property will have the + duration be 1 millisecond. Numbers greater than 1000 are invalid + and 1 millisecond will be used instead. + + phy-reset-active-high: + deprecated: true + description: + If present then the reset sequence using the GPIO specified in the + "phy-reset-gpios" property is reversed (H=reset state, L=operation state). + + phy-reset-post-delay: + deprecated: true + description: + Post reset delay in milliseconds. If present then a delay of phy-reset-post-delay + milliseconds will be observed after the phy-reset-gpios has been toggled. + Can be omitted thus no delay is observed. Delay is in range of 1ms to 1000ms. + Other delays are invalid. + +required: + - compatible + - reg + - interrupts + +# FIXME: We had better set additionalProperties to false to avoid invalid or at +# least undocumented properties. However, PHY may have a deprecated option to +# place PHY OF properties in the MAC node, such as Micrel PHY, and we can find +# these boards which is based on i.MX6QDL. +additionalProperties: true + +examples: + - | + ethernet@83fec000 { + compatible = "fsl,imx51-fec", "fsl,imx27-fec"; + reg = <0x83fec000 0x4000>; + interrupts = <87>; + phy-mode = "mii"; + phy-reset-gpios = <&gpio2 14 0>; + phy-supply = <®_fec_supply>; + }; + + ethernet@83fed000 { + compatible = "fsl,imx51-fec", "fsl,imx27-fec"; + reg = <0x83fed000 0x4000>; + interrupts = <87>; + phy-mode = "mii"; + phy-reset-gpios = <&gpio2 14 0>; + phy-supply = <®_fec_supply>; + phy-handle = <ðphy0>; + + mdio { + #address-cells = <1>; + #size-cells = <0>; + + ethphy0: ethernet-phy@0 { + compatible = "ethernet-phy-ieee802.3-c22"; + reg = <0>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/net/fsl-fec.txt b/Documentation/devicetree/bindings/net/fsl-fec.txt deleted file mode 100644 index 9b543789cd52..000000000000 --- a/Documentation/devicetree/bindings/net/fsl-fec.txt +++ /dev/null @@ -1,95 +0,0 @@ -* Freescale Fast Ethernet Controller (FEC) - -Required properties: -- compatible : Should be "fsl,-fec" -- reg : Address and length of the register set for the device -- interrupts : Should contain fec interrupt -- phy-mode : See ethernet.txt file in the same directory - -Optional properties: -- phy-supply : regulator that powers the Ethernet PHY. -- phy-handle : phandle to the PHY device connected to this device. -- fixed-link : Assume a fixed link. See fixed-link.txt in the same directory. - Use instead of phy-handle. -- fsl,num-tx-queues : The property is valid for enet-avb IP, which supports - hw multi queues. Should specify the tx queue number, otherwise set tx queue - number to 1. -- fsl,num-rx-queues : The property is valid for enet-avb IP, which supports - hw multi queues. Should specify the rx queue number, otherwise set rx queue - number to 1. -- fsl,magic-packet : If present, indicates that the hardware supports waking - up via magic packet. -- fsl,err006687-workaround-present: If present indicates that the system has - the hardware workaround for ERR006687 applied and does not need a software - workaround. -- fsl,stop-mode: register bits of stop mode control, the format is - <&gpr req_gpr req_bit>. - gpr is the phandle to general purpose register node. - req_gpr is the gpr register offset for ENET stop request. - req_bit is the gpr bit offset for ENET stop request. - -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 - according to phy.txt in the same directory - -Deprecated optional properties: - To avoid these, create a phy node according to phy.txt in the same - directory, and point the fec's "phy-handle" property to it. Then use - the phy's reset binding, again described by phy.txt. -- phy-reset-gpios : Should specify the gpio for phy reset -- phy-reset-duration : Reset duration in milliseconds. Should present - only if property "phy-reset-gpios" is available. Missing the property - will have the duration be 1 millisecond. Numbers greater than 1000 are - invalid and 1 millisecond will be used instead. -- phy-reset-active-high : If present then the reset sequence using the GPIO - specified in the "phy-reset-gpios" property is reversed (H=reset state, - L=operation state). -- phy-reset-post-delay : Post reset delay in milliseconds. If present then - a delay of phy-reset-post-delay milliseconds will be observed after the - phy-reset-gpios has been toggled. Can be omitted thus no delay is - observed. Delay is in range of 1ms to 1000ms. Other delays are invalid. - -Example: - -ethernet@83fec000 { - compatible = "fsl,imx51-fec", "fsl,imx27-fec"; - reg = <0x83fec000 0x4000>; - interrupts = <87>; - phy-mode = "mii"; - phy-reset-gpios = <&gpio2 14 GPIO_ACTIVE_LOW>; /* GPIO2_14 */ - local-mac-address = [00 04 9F 01 1B B9]; - phy-supply = <®_fec_supply>; -}; - -Example with phy specified: - -ethernet@83fec000 { - compatible = "fsl,imx51-fec", "fsl,imx27-fec"; - reg = <0x83fec000 0x4000>; - interrupts = <87>; - phy-mode = "mii"; - phy-reset-gpios = <&gpio2 14 GPIO_ACTIVE_LOW>; /* GPIO2_14 */ - local-mac-address = [00 04 9F 01 1B B9]; - phy-supply = <®_fec_supply>; - phy-handle = <ðphy>; - mdio { - clock-frequency = <5000000>; - ethphy: ethernet-phy@6 { - compatible = "ethernet-phy-ieee802.3-c22"; - reg = <6>; - max-speed = <100>; - }; - }; -}; -- cgit v1.2.3 From 8886534747c2e56d9d3b978c99e92dc479cd9426 Mon Sep 17 00:00:00 2001 From: "Roy, UjjaL" Date: Fri, 16 Jul 2021 22:04:41 +0200 Subject: bpf, doc: Add heading and example for extensions in cbpf Add new heading for extensions to make it more readable. Also, add one more example of filtering interface index for better understanding. Signed-off-by: Roy, UjjaL Signed-off-by: Daniel Borkmann Acked-by: Song Liu Acked-by: John Fastabend Link: https://lore.kernel.org/bpf/CAADnVQJ=DoRDcVkaXmY3EmNdLoO7gq1mkJOn5G=00wKH8qUtZQ@mail.gmail.com --- Documentation/networking/filter.rst | 23 ++++++++++++++++------- 1 file changed, 16 insertions(+), 7 deletions(-) (limited to 'Documentation') diff --git a/Documentation/networking/filter.rst b/Documentation/networking/filter.rst index 3e2221f4abe4..5f13905b12e0 100644 --- a/Documentation/networking/filter.rst +++ b/Documentation/networking/filter.rst @@ -320,13 +320,6 @@ Examples for low-level BPF: ret #-1 drop: ret #0 -**(Accelerated) VLAN w/ id 10**:: - - ld vlan_tci - jneq #10, drop - ret #-1 - drop: ret #0 - **icmp random packet sampling, 1 in 4**:: ldh [12] @@ -358,6 +351,22 @@ Examples for low-level BPF: bad: ret #0 /* SECCOMP_RET_KILL_THREAD */ good: ret #0x7fff0000 /* SECCOMP_RET_ALLOW */ +Examples for low-level BPF extension: + +**Packet for interface index 13**:: + + ld ifidx + jneq #13, drop + ret #-1 + drop: ret #0 + +**(Accelerated) VLAN w/ id 10**:: + + ld vlan_tci + jneq #10, drop + ret #-1 + drop: ret #0 + The above example code can be placed into a file (here called "foo"), and then be passed to the bpf_asm tool for generating opcodes, output that xt_bpf and cls_bpf understands and can directly be loaded with. Example with above -- cgit v1.2.3 From f82ff130a5e6a0263cb6161fb44ee79f781fea80 Mon Sep 17 00:00:00 2001 From: Linus Walleij Date: Thu, 15 Jul 2021 00:50:01 +0200 Subject: drm/panel: Add DT bindings for Samsung LMS380KF01 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit This adds device tree bindings for the Samsung Mobile Displays LMS380KF01 RGB DPI display panel. Cc: devicetree@vger.kernel.org Cc: phone-devel@vger.kernel.org Cc: Noralf Trønnes Reviewed-by: Sam Ravnborg Reviewed-by: Douglas Anderson Reviewed-by: Rob Herring Signed-off-by: Linus Walleij Link: https://patchwork.freedesktop.org/patch/msgid/20210714225002.1065107-1-linus.walleij@linaro.org --- .../bindings/display/panel/samsung,lms380kf01.yaml | 99 ++++++++++++++++++++++ 1 file changed, 99 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/panel/samsung,lms380kf01.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/panel/samsung,lms380kf01.yaml b/Documentation/devicetree/bindings/display/panel/samsung,lms380kf01.yaml new file mode 100644 index 000000000000..251f0c7115aa --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/samsung,lms380kf01.yaml @@ -0,0 +1,99 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/panel/samsung,lms380kf01.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Samsung LMS380KF01 display panel + +description: The LMS380KF01 is a 480x800 DPI display panel from Samsung Mobile + Displays (SMD) utilizing the WideChips WS2401 display controller. It can be + used with internal or external backlight control. + The panel must obey the rules for a SPI slave device as specified in + spi/spi-controller.yaml + +maintainers: + - Linus Walleij + +allOf: + - $ref: panel-common.yaml# + +properties: + compatible: + const: samsung,lms380kf01 + + reg: true + + interrupts: + description: provides an optional ESD (electrostatic discharge) + interrupt that signals abnormalities in the display hardware. + This can also be raised for other reasons like erroneous + configuration. + maxItems: 1 + + reset-gpios: true + + vci-supply: + description: regulator that supplies the VCI analog voltage + usually around 3.0 V + + vccio-supply: + description: regulator that supplies the VCCIO voltage usually + around 1.8 V + + backlight: true + + spi-cpha: true + + spi-cpol: true + + spi-max-frequency: + maximum: 1200000 + + port: true + +required: + - compatible + - reg + - spi-cpha + - spi-cpol + - port + +additionalProperties: false + +examples: + - | + #include + #include + + spi { + compatible = "spi-gpio"; + sck-gpios = <&gpio 0 GPIO_ACTIVE_HIGH>; + miso-gpios = <&gpio 1 GPIO_ACTIVE_HIGH>; + mosi-gpios = <&gpio 2 GPIO_ACTIVE_HIGH>; + cs-gpios = <&gpio 3 GPIO_ACTIVE_HIGH>; + num-chipselects = <1>; + #address-cells = <1>; + #size-cells = <0>; + + panel@0 { + compatible = "samsung,lms380kf01"; + spi-max-frequency = <1200000>; + spi-cpha; + spi-cpol; + reg = <0>; + vci-supply = <&lcd_3v0_reg>; + vccio-supply = <&lcd_1v8_reg>; + reset-gpios = <&gpio 4 GPIO_ACTIVE_LOW>; + interrupt-parent = <&gpio>; + interrupts = <5 IRQ_TYPE_EDGE_RISING>; + + port { + panel_in: endpoint { + remote-endpoint = <&display_out>; + }; + }; + }; + }; + +... -- cgit v1.2.3 From edf021d14511e59c4618396ec6f5206c484f89df Mon Sep 17 00:00:00 2001 From: Simon Xue Date: Mon, 12 Jul 2021 09:44:37 +0800 Subject: dt-bindings: iio: adc: rockchip-saradc: add description for rk3568 Add description for rk3568 saradc. Signed-off-by: Simon Xue Reviewed-by: Heiko Stuebner Acked-by: Rob Herring Link: https://lore.kernel.org/r/20210712014437.97427-1-xxm@rock-chips.com Signed-off-by: Jonathan Cameron --- Documentation/devicetree/bindings/iio/adc/rockchip-saradc.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/iio/adc/rockchip-saradc.yaml b/Documentation/devicetree/bindings/iio/adc/rockchip-saradc.yaml index 1bb76197787b..e512a14e41b4 100644 --- a/Documentation/devicetree/bindings/iio/adc/rockchip-saradc.yaml +++ b/Documentation/devicetree/bindings/iio/adc/rockchip-saradc.yaml @@ -20,6 +20,7 @@ properties: - rockchip,px30-saradc - rockchip,rk3308-saradc - rockchip,rk3328-saradc + - rockchip,rk3568-saradc - rockchip,rv1108-saradc - const: rockchip,rk3399-saradc -- cgit v1.2.3 From 4f0964f70fcf077e9f9a95ee5be71ff8be1c2b51 Mon Sep 17 00:00:00 2001 From: Jonathan Cameron Date: Sun, 27 Jun 2021 17:32:30 +0100 Subject: dt-bindings: iio: dac: adi,ad5421: Add missing binding document. MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit This is documented what is currently the case. There are a number of things that could be added, but I don't feel the binding elements are obvious enough to document without a driver implementation to verify they are good choices. These include * Range * Regulators, both input and potentially output (if the loop being driven is ever described). I've listed Lars and myself as maintainers of the binding, but if anyone else wants to be added they would be most welcome! Signed-off-by: Jonathan Cameron Cc: Lars-Peter Clausen Reviewed-by: Rob Herring Acked-by: Nuno Sá Link: https://lore.kernel.org/r/20210627163244.1090296-2-jic23@kernel.org --- .../devicetree/bindings/iio/dac/adi,ad5421.yaml | 51 ++++++++++++++++++++++ 1 file changed, 51 insertions(+) create mode 100644 Documentation/devicetree/bindings/iio/dac/adi,ad5421.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/iio/dac/adi,ad5421.yaml b/Documentation/devicetree/bindings/iio/dac/adi,ad5421.yaml new file mode 100644 index 000000000000..188f656617e3 --- /dev/null +++ b/Documentation/devicetree/bindings/iio/dac/adi,ad5421.yaml @@ -0,0 +1,51 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iio/dac/adi,ad5421.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Analog Devices AD5421 DAC + +maintainers: + - Lars-Peter Clausen + - Jonathan Cameron + +description: | + AD5421 is designed for us in loop-powered, 4 mA to 20 mA smart transmitter + applications. It provides a 16-bit DAC, current amplifier, voltage regulator + to drive the loop and a voltage reference. + +properties: + compatible: + const: adi,ad5421 + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + description: Fault signal. + + spi-max-frequency: true + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + #include + spi { + #address-cells = <1>; + #size-cells = <0>; + + dac@0 { + compatible = "adi,ad5421"; + reg = <0>; + spi-max-frequency = <30000000>; + interrupts = <55 IRQ_TYPE_LEVEL_HIGH>; + }; + }; +... -- cgit v1.2.3 From 613c403a7f978dddfd213e687a3ab6d104e50def Mon Sep 17 00:00:00 2001 From: Jonathan Cameron Date: Sun, 27 Jun 2021 17:32:31 +0100 Subject: dt-bindings: iio: dac: adi,ad5064: Document bindings for many different DACs MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Note this is documenting bindings that have effectively existing ever since this driver was merged. The naming conventions for the ADI parts are inconsistent on the data sheets which has lead to a mixture of -X and -reference voltage part naming. We could attempt to clean this up, but as we are stuck supporting the existing binding it is probably not worthwhile. Signed-off-by: Jonathan Cameron Cc: Lars-Peter Clausen Reviewed-by: Rob Herring Acked-by: Nuno Sá Link: https://lore.kernel.org/r/20210627163244.1090296-3-jic23@kernel.org --- .../devicetree/bindings/iio/dac/adi,ad5064.yaml | 268 +++++++++++++++++++++ 1 file changed, 268 insertions(+) create mode 100644 Documentation/devicetree/bindings/iio/dac/adi,ad5064.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/iio/dac/adi,ad5064.yaml b/Documentation/devicetree/bindings/iio/dac/adi,ad5064.yaml new file mode 100644 index 000000000000..05ed4e0ec364 --- /dev/null +++ b/Documentation/devicetree/bindings/iio/dac/adi,ad5064.yaml @@ -0,0 +1,268 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iio/dac/adi,ad5064.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Analog Devices AD5064 and similar DACs + +maintainers: + - Lars-Peter Clausen + - Jonathan Cameron + +description: | + A range of similar DAC devices with between 1 and 12 channels. Some parts + have internal references, others require a single shared external reference + and the remainder have a separate reference pin for each DAC. + +properties: + compatible: + oneOf: + - description: I2C devics + enum: + - adi,ad5024 + - adi,ad5025 + - adi,ad5044 + - adi,ad5045 + - adi,ad5064 + - adi,ad5064-1 + - adi,ad5065 + - adi,ad5628-1 + - adi,ad5628-2 + - adi,ad5648-1 + - adi,ad5648-2 + - adi,ad5666-1 + - adi,ad5666-2 + - adi,ad5668-1 + - adi,ad5668-2 + - adi,ad5668-3 + - description: SPI devices + enum: + - adi,ad5625 + - adi,ad5625r-1v25 + - adi,ad5625r-2v5 + - adi,ad5627 + - adi,ad5627r-1v25 + - adi,ad5627r-2v5 + - adi,ad5629-1 + - adi,ad5629-2 + - adi,ad5629-3 + - adi,ad5645r-1v25 + - adi,ad5645r-2v5 + - adi,ad5665 + - adi,ad5665r-1v25 + - adi,ad5665r-2v5 + - adi,ad5667 + - adi,ad5667r-1v25 + - adi,ad5667r-2v5 + - adi,ad5669-1 + - adi,ad5669-2 + - adi,ad5669-3 + - lltc,ltc2606 + - lltc,ltc2607 + - lltc,ltc2609 + - lltc,ltc2616 + - lltc,ltc2617 + - lltc,ltc2619 + - lltc,ltc2626 + - lltc,ltc2627 + - lltc,ltc2629 + - lltc,ltc2631-l12 + - lltc,ltc2631-h12 + - lltc,ltc2631-l10 + - lltc,ltc2631-h10 + - lltc,ltc2631-l8 + - lltc,ltc2631-h8 + - lltc,ltc2633-l12 + - lltc,ltc2633-h12 + - lltc,ltc2633-l10 + - lltc,ltc2633-h10 + - lltc,ltc2633-l8 + - lltc,ltc2633-h8 + - lltc,ltc2635-l12 + - lltc,ltc2635-h12 + - lltc,ltc2635-l10 + - lltc,ltc2635-h10 + - lltc,ltc2635-l8 + - lltc,ltc2635-h8 + + reg: + maxItems: 1 + + vrefA-supply: true + vrefB-supply: true + vrefC-supply: true + vrefD-supply: true + vref-supply: true + + spi-max-frequency: true + +additionalProperties: false + +required: + - compatible + - reg + +allOf: + - # Shared external vref, no internal reference + if: + properties: + compatible: + contains: + enum: + - adi,ad5064-1 + - adi,ad5625 + - adi,ad5627 + - adi,ad5665 + - adi,ad5667 + - lltc,ltc2606 + - lltc,ltc2607 + - lltc,ltc2616 + - lltc,ltc2617 + - lltc,ltc2626 + - lltc,ltc2627 + then: + properties: + vref-supply: true + vrefA-supply: false + vrefB-supply: false + vrefC-supply: false + vrefD-supply: false + required: + - vref-supply + - # Shared external vref, internal reference available + if: + properties: + compatible: + contains: + enum: + - adi,ad5625r-1v25 + - adi,ad5625r-2v5 + - adi,ad5627r-1v25 + - adi,ad5627r-2v5 + - adi,ad5628-1 + - adi,ad5628-2 + - adi,ad5629-1 + - adi,ad5629-2 + - adi,ad5629-3 + - adi,ad5645r-1v25 + - adi,ad5645r-2v5 + - adi,ad5647r-1v25 + - adi,ad5647r-2v5 + - adi,ad5648-1 + - adi,ad5648-2 + - adi,ad5665r-1v25 + - adi,ad5665r-2v5 + - adi,ad5666-1 + - adi,ad5666-2 + - adi,ad5667r-1v25 + - adi,ad5667r-2v5 + - adi,ad5668-1 + - adi,ad5668-2 + - adi,ad5668-3 + - adi,ad5669-1 + - adi,ad5669-2 + - adi,ad5669-3 + - lltc,ltc2631-l12 + - lltc,ltc2631-h12 + - lltc,ltc2631-l10 + - lltc,ltc2631-h10 + - lltc,ltc2631-l8 + - lltc,ltc2631-h8 + - lltc,ltc2633-l12 + - lltc,ltc2633-h12 + - lltc,ltc2633-l10 + - lltc,ltc2633-h10 + - lltc,ltc2633-l8 + - lltc,ltc2633-h8 + - lltc,ltc2635-l12 + - lltc,ltc2635-h12 + - lltc,ltc2635-l10 + - lltc,ltc2635-h10 + - lltc,ltc2635-l8 + - lltc,ltc2635-h8 + then: + properties: + vref-supply: true + vrefA-supply: false + vrefB-supply: false + vrefC-supply: false + vrefD-supply: false + - # 4 input devices, separate vrefs, no internal reference + if: + properties: + compatible: + contains: + enum: + - adi,ad5024 + - adi,ad5044 + - adi,ad5064 + - lltc,ltc2609 + - lltc,ltc2619 + - lltc,ltc2629 + then: + properties: + vrefA-supply: true + vrefB-supply: true + vrefC-supply: true + vrefD-supply: true + vref-supply: false + required: + - vrefA-supply + - vrefB-supply + - vrefC-supply + - vrefD-supply + - # 2 input devices, separate vrefs, no internal reference + if: + properties: + compatible: + contains: + enum: + - adi,ad5025 + - adi,ad5045 + - adi,ad5065 + then: + properties: + vrefA-supply: true + vrefB-supply: true + vrefC-supply: false + vrefD-supply: false + vref-supply: false + required: + - vrefA-supply + - vrefB-supply + +examples: + - | + spi { + #address-cells = <1>; + #size-cells = <0>; + dac@0 { + reg = <0>; + compatible = "adi,ad5625"; + vref-supply = <&dac_vref>; + }; + }; + - | + spi { + #address-cells = <1>; + #size-cells = <0>; + dac@0 { + reg = <0>; + compatible = "adi,ad5625r-1v25"; + }; + }; + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + dac@42 { + reg = <0x42>; + compatible = "adi,ad5024"; + vrefA-supply = <&dac_vref>; + vrefB-supply = <&dac_vref>; + vrefC-supply = <&dac_vref2>; + vrefD-supply = <&dac_vref2>; + }; + }; +... -- cgit v1.2.3 From 0688cc60d579e9d122cbf81b7d185d711d0e3989 Mon Sep 17 00:00:00 2001 From: Jonathan Cameron Date: Sun, 27 Jun 2021 17:32:32 +0100 Subject: dt-bindings: iio: dac: adi,ad5360: Add missing binding document MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Bindings for the family of many channel DACs. Fairly straight forward with just a differing number of voltage references (an extra one for the 40 channel ad4371) Signed-off-by: Jonathan Cameron Cc: Lars-Peter Clausen Reviewed-by: Rob Herring Acked-by: Nuno Sá Link: https://lore.kernel.org/r/20210627163244.1090296-4-jic23@kernel.org --- .../devicetree/bindings/iio/dac/adi,ad5360.yaml | 79 ++++++++++++++++++++++ 1 file changed, 79 insertions(+) create mode 100644 Documentation/devicetree/bindings/iio/dac/adi,ad5360.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/iio/dac/adi,ad5360.yaml b/Documentation/devicetree/bindings/iio/dac/adi,ad5360.yaml new file mode 100644 index 000000000000..0d8fb56f4b09 --- /dev/null +++ b/Documentation/devicetree/bindings/iio/dac/adi,ad5360.yaml @@ -0,0 +1,79 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iio/dac/adi,ad5360.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Analog Devices AD5360 and similar DACs + +maintainers: + - Lars-Peter Clausen + - Jonathan Cameron + +properties: + compatible: + enum: + - adi,ad5360 + - adi,ad5361 + - adi,ad5363 + - adi,ad5370 + - adi,ad5371 + - adi,ad5372 + - adi,ad5373 + + reg: + maxItems: 1 + + vref0-supply: true + vref1-supply: true + vref2-supply: true + + spi-max-frequency: true + +additionalProperties: false + +required: + - compatible + - reg + - vref0-supply + - vref1-supply + +allOf: + - if: + properties: + compatible: + contains: + enum: + - adi,ad5360 + - adi,ad5361 + - adi,ad5363 + - adi,ad5370 + - adi,ad5372 + - adi,ad5373 + then: + properties: + vref2-supply: false + - if: + properties: + compatible: + contains: + enum: + - adi,ad5371 + then: + required: + - vref2-supply + +examples: + - | + spi { + #address-cells = <1>; + #size-cells = <0>; + dac@0 { + reg = <0>; + compatible = "adi,ad5371"; + vref0-supply = <&dac_vref0>; + vref1-supply = <&dac_vref1>; + vref2-supply = <&dac_vref2>; + }; + }; +... -- cgit v1.2.3 From 5992d5a6b563bcf4313d8c06b957052b131eba6d Mon Sep 17 00:00:00 2001 From: Jonathan Cameron Date: Sun, 27 Jun 2021 17:32:33 +0100 Subject: dt-bindings: iio: dac: ad5380: Add missing binding document MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit A simple binding for this particular DAC familly. Signed-off-by: Jonathan Cameron Cc: Lars-Peter Clausen Reviewed-by: Rob Herring Acked-by: Nuno Sá Link: https://lore.kernel.org/r/20210627163244.1090296-5-jic23@kernel.org --- .../devicetree/bindings/iio/dac/adi,ad5380.yaml | 70 ++++++++++++++++++++++ 1 file changed, 70 insertions(+) create mode 100644 Documentation/devicetree/bindings/iio/dac/adi,ad5380.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/iio/dac/adi,ad5380.yaml b/Documentation/devicetree/bindings/iio/dac/adi,ad5380.yaml new file mode 100644 index 000000000000..d599b418a020 --- /dev/null +++ b/Documentation/devicetree/bindings/iio/dac/adi,ad5380.yaml @@ -0,0 +1,70 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iio/dac/adi,ad5380.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Analog Devices AD5380 and similar DACs + +maintainers: + - Lars-Peter Clausen + - Jonathan Cameron + +description: | + DAC devices supporting both SPI and I2C interfaces. +properties: + compatible: + enum: + - adi,ad5380-3 + - adi,ad5380-5 + - adi,ad5381-3 + - adi,ad5381-5 + - adi,ad5382-3 + - adi,ad5382-5 + - adi,ad5383-3 + - adi,ad5383-5 + - adi,ad5384-3 + - adi,ad5384-5 + - adi,ad5390-3 + - adi,ad5390-5 + - adi,ad5391-3 + - adi,ad5391-5 + - adi,ad5392-3 + - adi,ad5392-5 + + reg: + maxItems: 1 + + vref-supply: + description: + If not supplied devices will use internal regulators. + + spi-max-frequency: true + +additionalProperties: false + +required: + - compatible + - reg + +examples: + - | + spi { + #address-cells = <1>; + #size-cells = <0>; + dac@0 { + reg = <0>; + compatible = "adi,ad5390-5"; + vref-supply = <&dacvref>; + }; + }; + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + dac@42 { + reg = <0x42>; + compatible = "adi,ad5380-3"; + }; + }; +... -- cgit v1.2.3 From 609bf552b034f62e8775153d943524a1ed4dbc2a Mon Sep 17 00:00:00 2001 From: Jonathan Cameron Date: Sun, 27 Jun 2021 17:32:35 +0100 Subject: dt-bindings: iio: dac: ad5449: Add missing binding document. MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Documenting existing binding, so little flexibility available. 2 channel devices that require separate reference voltages. Signed-off-by: Jonathan Cameron Cc: Lars-Peter Clausen Reviewed-by: Rob Herring Acked-by: Nuno Sá Link: https://lore.kernel.org/r/20210627163244.1090296-7-jic23@kernel.org --- .../devicetree/bindings/iio/dac/adi,ad5449.yaml | 97 ++++++++++++++++++++++ 1 file changed, 97 insertions(+) create mode 100644 Documentation/devicetree/bindings/iio/dac/adi,ad5449.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/iio/dac/adi,ad5449.yaml b/Documentation/devicetree/bindings/iio/dac/adi,ad5449.yaml new file mode 100644 index 000000000000..044332c97743 --- /dev/null +++ b/Documentation/devicetree/bindings/iio/dac/adi,ad5449.yaml @@ -0,0 +1,97 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iio/dac/adi,ad5449.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Analog Devices AD5449 and similar DACs + +maintainers: + - Lars-Peter Clausen + - Jonathan Cameron + +description: + Family of multiplying DACs from Analog Devices + +properties: + compatible: + enum: + - adi,ad5415 + - adi,ad5426 + - adi,ad5429 + - adi,ad5432 + - adi,ad5439 + - adi,ad5443 + - adi,ad5449 + + reg: + maxItems: 1 + + spi-max-frequency: true + + VREF-supply: true + VREFA-supply: true + VREFB-supply: true + +additionalProperties: false + +required: + - compatible + - reg + +allOf: + - if: + properties: + compatible: + contains: + enum: + - adi,ad5415 + - adi,ad5426 + - adi,ad5432 + then: + properties: + VREF-supply: true + VREFA-supply: false + VREFB-supply: false + required: + - VREF-supply + - if: + properties: + compatible: + contains: + enum: + - adi,ad5429 + - adi,ad5439 + - adi,ad5449 + then: + properties: + VREF-supply: false + VREFA-supply: true + VREFB-supply: true + required: + - VREFA-supply + - VREFB-supply + +examples: + - | + spi { + #address-cells = <1>; + #size-cells = <0>; + dac@0 { + reg = <0>; + compatible = "adi,ad5415"; + VREF-supply = <&dac_ref>; + }; + }; + - | + spi { + #address-cells = <1>; + #size-cells = <0>; + dac@0 { + reg = <0>; + compatible = "adi,ad5429"; + VREFA-supply = <&dac_refA>; + VREFB-supply = <&dac_refB>; + }; + }; +... -- cgit v1.2.3 From 790a352b6f125e0d22edc0ae479bb2f2ef930fe3 Mon Sep 17 00:00:00 2001 From: Jonathan Cameron Date: Sun, 27 Jun 2021 17:32:36 +0100 Subject: dt-bindings: iio: dac: ad5504: Add missing binding document MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Binding for this high voltage DAC with temperature event signal. Signed-off-by: Jonathan Cameron Reviewed-by: Rob Herring Acked-by: Nuno Sá Link: https://lore.kernel.org/r/20210627163244.1090296-8-jic23@kernel.org --- .../devicetree/bindings/iio/dac/adi,ad5504.yaml | 50 ++++++++++++++++++++++ 1 file changed, 50 insertions(+) create mode 100644 Documentation/devicetree/bindings/iio/dac/adi,ad5504.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/iio/dac/adi,ad5504.yaml b/Documentation/devicetree/bindings/iio/dac/adi,ad5504.yaml new file mode 100644 index 000000000000..9c2c038683b4 --- /dev/null +++ b/Documentation/devicetree/bindings/iio/dac/adi,ad5504.yaml @@ -0,0 +1,50 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iio/dac/adi,ad5504.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Analog Devices AD5501 and AD5504 DACs + +maintainers: + - Lars-Peter Clausen + - Jonathan Cameron + +description: + High voltage (up to 60V) DACs with temperature sensor alarm function + +properties: + compatible: + enum: + - adi,ad5501 + - adi,ad5504 + + reg: + maxItems: 1 + + interrupts: + description: Used for temperature alarm. + maxItems: 1 + + vcc-supply: true + +additionalProperties: false + +required: + - compatible + - reg + +examples: + - | + #include + spi { + #address-cells = <1>; + #size-cells = <0>; + dac@0 { + reg = <0>; + compatible = "adi,ad5504"; + vcc-supply = <&dac_vcc>; + interrupts = <55 IRQ_TYPE_EDGE_FALLING>; + }; + }; +... -- cgit v1.2.3 From 5e60f363b38fd40e4d8838b5d6f4d4ecee92c777 Mon Sep 17 00:00:00 2001 From: Robert Richter Date: Thu, 15 Jul 2021 11:26:02 +0200 Subject: Documentation: Fix intiramfs script name Documentation was not changed when renaming the script in commit 80e715a06c2d ("initramfs: rename gen_initramfs_list.sh to gen_initramfs.sh"). Fixing this. Basically does: $ sed -i -e s/gen_initramfs_list.sh/gen_initramfs.sh/g $(git grep -l gen_initramfs_list.sh) Fixes: 80e715a06c2d ("initramfs: rename gen_initramfs_list.sh to gen_initramfs.sh") Signed-off-by: Robert Richter Signed-off-by: Masahiro Yamada --- .../driver-api/early-userspace/early_userspace_support.rst | 8 ++++---- Documentation/filesystems/ramfs-rootfs-initramfs.rst | 2 +- 2 files changed, 5 insertions(+), 5 deletions(-) (limited to 'Documentation') diff --git a/Documentation/driver-api/early-userspace/early_userspace_support.rst b/Documentation/driver-api/early-userspace/early_userspace_support.rst index 8a58c61932ff..61bdeac1bae5 100644 --- a/Documentation/driver-api/early-userspace/early_userspace_support.rst +++ b/Documentation/driver-api/early-userspace/early_userspace_support.rst @@ -69,17 +69,17 @@ early userspace image can be built by an unprivileged user. As a technical note, when directories and files are specified, the entire CONFIG_INITRAMFS_SOURCE is passed to -usr/gen_initramfs_list.sh. This means that CONFIG_INITRAMFS_SOURCE +usr/gen_initramfs.sh. This means that CONFIG_INITRAMFS_SOURCE can really be interpreted as any legal argument to -gen_initramfs_list.sh. If a directory is specified as an argument then +gen_initramfs.sh. If a directory is specified as an argument then the contents are scanned, uid/gid translation is performed, and usr/gen_init_cpio file directives are output. If a directory is -specified as an argument to usr/gen_initramfs_list.sh then the +specified as an argument to usr/gen_initramfs.sh then the contents of the file are simply copied to the output. All of the output directives from directory scanning and file contents copying are processed by usr/gen_init_cpio. -See also 'usr/gen_initramfs_list.sh -h'. +See also 'usr/gen_initramfs.sh -h'. Where's this all leading? ========================= diff --git a/Documentation/filesystems/ramfs-rootfs-initramfs.rst b/Documentation/filesystems/ramfs-rootfs-initramfs.rst index 4598b0d90b60..164960631925 100644 --- a/Documentation/filesystems/ramfs-rootfs-initramfs.rst +++ b/Documentation/filesystems/ramfs-rootfs-initramfs.rst @@ -170,7 +170,7 @@ Documentation/driver-api/early-userspace/early_userspace_support.rst for more de The kernel does not depend on external cpio tools. If you specify a directory instead of a configuration file, the kernel's build infrastructure creates a configuration file from that directory (usr/Makefile calls -usr/gen_initramfs_list.sh), and proceeds to package up that directory +usr/gen_initramfs.sh), and proceeds to package up that directory using the config file (by feeding it to usr/gen_init_cpio, which is created from usr/gen_init_cpio.c). The kernel's build-time cpio creation code is entirely self-contained, and the kernel's boot-time extractor is also -- cgit v1.2.3 From b302c57bc9c7d11dbab7b70b9711506a63592617 Mon Sep 17 00:00:00 2001 From: Jonathan Cameron Date: Sun, 27 Jun 2021 17:32:38 +0100 Subject: dt-bindings: iio: dac: ad5624r: Add missing binding document MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Simple binding, with optional vref. Note that the Linux driver does support vcc-supply for historical reasons, but lets not let that get into any bindings that are checked going forwards. Hence I have deliberately not documented it. Signed-off-by: Jonathan Cameron Reviewed-by: Rob Herring Acked-by: Nuno Sá Link: https://lore.kernel.org/r/20210627163244.1090296-10-jic23@kernel.org --- .../devicetree/bindings/iio/dac/adi,ad5624r.yaml | 47 ++++++++++++++++++++++ 1 file changed, 47 insertions(+) create mode 100644 Documentation/devicetree/bindings/iio/dac/adi,ad5624r.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/iio/dac/adi,ad5624r.yaml b/Documentation/devicetree/bindings/iio/dac/adi,ad5624r.yaml new file mode 100644 index 000000000000..330383b85eeb --- /dev/null +++ b/Documentation/devicetree/bindings/iio/dac/adi,ad5624r.yaml @@ -0,0 +1,47 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iio/dac/adi,ad5624r.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Analog Devices AD5624r and similar DACs + +maintainers: + - Jonathan Cameron + +properties: + compatible: + enum: + - adi,ad5624r3 + - adi,ad5644r3 + - adi,ad5664r3 + - adi,ad5624r5 + - adi,ad5644r5 + - adi,ad5664r5 + + reg: + maxItems: 1 + + spi-max-frequency: true + + vref-supply: + description: If not present, internal reference will be used. + +additionalProperties: false + +required: + - compatible + - reg + +examples: + - | + spi { + #address-cells = <1>; + #size-cells = <0>; + dac@0 { + reg = <0>; + compatible = "adi,ad5624r3"; + vref-supply = <&vref>; + }; + }; +... -- cgit v1.2.3 From 2d89b8b2c0bf8a49d9e7b5978afecc806666b5e7 Mon Sep 17 00:00:00 2001 From: Jonathan Cameron Date: Sun, 27 Jun 2021 17:32:39 +0100 Subject: dt-bindings: iio: dac: ad5686 and ad5696: Add missing binding document. MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The use of vcc-supply for the reference voltage is unusual and should probably be deprecated as there is an explicit VREF pin on at least some of these parts. Signed-off-by: Jonathan Cameron Reviewed-by: Rob Herring Acked-by: Nuno Sá Link: https://lore.kernel.org/r/20210627163244.1090296-11-jic23@kernel.org --- .../devicetree/bindings/iio/dac/adi,ad5686.yaml | 75 ++++++++++++++++++++++ 1 file changed, 75 insertions(+) create mode 100644 Documentation/devicetree/bindings/iio/dac/adi,ad5686.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/iio/dac/adi,ad5686.yaml b/Documentation/devicetree/bindings/iio/dac/adi,ad5686.yaml new file mode 100644 index 000000000000..5c26441eae9f --- /dev/null +++ b/Documentation/devicetree/bindings/iio/dac/adi,ad5686.yaml @@ -0,0 +1,75 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iio/dac/adi,ad5686.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Analog Devices AD5360 and similar DACs + +maintainers: + - Michael Hennerich + - Jonathan Cameron + +properties: + compatible: + oneOf: + - description: SPI devices + enum: + - adi,ad5310r + - adi,ad5672r + - adi,ad5674r + - adi,ad5676 + - adi,ad5676r + - adi,ad5679r + - adi,ad5681r + - adi,ad5682r + - adi,ad5683 + - adi,ad5683r + - adi,ad5684 + - adi,ad5684r + - adi,ad5685r + - adi,ad5686 + - adi,ad5686r + - description: I2C devices + enum: + - adi,ad5311r + - adi,ad5338r + - adi,ad5671r + - adi,ad5675r + - adi,ad5691r + - adi,ad5692r + - adi,ad5693 + - adi,ad5693r + - adi,ad5694 + - adi,ad5694r + - adi,ad5695r + - adi,ad5696 + - adi,ad5696r + + + reg: + maxItems: 1 + + vcc-supply: + description: If not supplied the internal reference is used. + + spi-max-frequency: true + +additionalProperties: false + +required: + - compatible + - reg + +examples: + - | + spi { + #address-cells = <1>; + #size-cells = <0>; + dac@0 { + reg = <0>; + compatible = "adi,ad5310r"; + vcc-supply = <&dac_vref0>; + }; + }; +... -- cgit v1.2.3 From db8dc17e1fd820792804fa1e10ab8244b4abdd78 Mon Sep 17 00:00:00 2001 From: Jonathan Cameron Date: Sun, 27 Jun 2021 17:32:40 +0100 Subject: dt-bindings: iio: dac: ad5761: Add missing binding doc. MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Straight forward binding with vref optional for those part with internal regulators, but required for those without. Signed-off-by: Jonathan Cameron Cc: Ricardo Ribalda Reviewed-by: Rob Herring Acked-by: Nuno Sá Link: https://lore.kernel.org/r/20210627163244.1090296-12-jic23@kernel.org --- .../devicetree/bindings/iio/dac/adi,ad5761.yaml | 60 ++++++++++++++++++++++ 1 file changed, 60 insertions(+) create mode 100644 Documentation/devicetree/bindings/iio/dac/adi,ad5761.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/iio/dac/adi,ad5761.yaml b/Documentation/devicetree/bindings/iio/dac/adi,ad5761.yaml new file mode 100644 index 000000000000..7f95a9ed55fe --- /dev/null +++ b/Documentation/devicetree/bindings/iio/dac/adi,ad5761.yaml @@ -0,0 +1,60 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iio/dac/adi,ad5761.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Analog Devices AD5761 and similar DACs + +maintainers: + - Ricardo Ribalda + - Jonathan Cameron + +properties: + + compatible: + enum: + - adi,ad5721 + - adi,ad5721r + - adi,ad5761 + - adi,ad5761r + + reg: + maxItems: 1 + + spi-max-frequency: true + + vref-supply: + description: If not supplied, internal reference will be used. + +additionalProperties: false + +required: + - compatible + - reg + +allOf: + - if: + properties: + compatible: + contains: + enum: + - adi,ad5721 + - adi,ad5761 + then: + required: + - vref-supply + +examples: + - | + spi { + #address-cells = <1>; + #size-cells = <0>; + + dac@0 { + compatible = "adi,ad5721"; + reg = <0>; + vref-supply = <&dac_vref>; + }; + }; +... -- cgit v1.2.3 From 96e137558d5823787a410c3c89d076fdc8b8c720 Mon Sep 17 00:00:00 2001 From: Jonathan Cameron Date: Sun, 27 Jun 2021 17:32:41 +0100 Subject: dt-bindings: iio: dac: adi,ad5764: Add missing binding document MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit This binding covers the ad5744, ad5744r, ad5764 and ad5764r DACs. Note that the driver currently assumes the internal reference is used for the r parts. The binding as defined relaxes this constraint. There is no support in the binding or driver for the two digital IO signals. I do not propose to add that until we have a means to test any such binding. Signed-off-by: Jonathan Cameron Cc: Lars-Peter Clausen Reviewed-by: Rob Herring Acked-by: Nuno Sá Link: https://lore.kernel.org/r/20210627163244.1090296-13-jic23@kernel.org --- .../devicetree/bindings/iio/dac/adi,ad5764.yaml | 62 ++++++++++++++++++++++ 1 file changed, 62 insertions(+) create mode 100644 Documentation/devicetree/bindings/iio/dac/adi,ad5764.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/iio/dac/adi,ad5764.yaml b/Documentation/devicetree/bindings/iio/dac/adi,ad5764.yaml new file mode 100644 index 000000000000..8e893d52bfb1 --- /dev/null +++ b/Documentation/devicetree/bindings/iio/dac/adi,ad5764.yaml @@ -0,0 +1,62 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iio/dac/adi,ad5764.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Analog Devices AD5744 and AD5764 DAC families + +maintainers: + - Lars-Peter Clausen + - Jonathan Cameron + +properties: + + compatible: + enum: + - adi,ad5744 + - adi,ad5744r + - adi,ad5764 + - adi,ad5764r + + reg: + maxItems: 1 + + spi-max-frequency: true + + vrefAB-supply: true + vrefCD-supply: true + +additionalProperties: false + +required: + - compatible + - reg + +allOf: + - if: + properties: + compatible: + contains: + enum: + - adi,ad5744 + - adi,ad5764 + then: + required: + - vrefAB-supply + - vrefCD-supply + +examples: + - | + spi { + #address-cells = <1>; + #size-cells = <0>; + + dac@0 { + compatible = "adi,ad5744"; + reg = <0>; + vrefAB-supply = <&dac_vref>; + vrefCD-supply = <&dac_vref>; + }; + }; +... -- cgit v1.2.3 From a714ee9ea0efe516fd13c1f29f41f6394b408492 Mon Sep 17 00:00:00 2001 From: Jonathan Cameron Date: Sun, 27 Jun 2021 17:32:42 +0100 Subject: dt-bindings: iio: dac: adi,ad5791: Add missing bindings document MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Documenting existing bindings for this device. The Linux driver in theory 'works' without the two supplies that I have listed as required, but without a valid scale. As such I've documented it as required. Signed-off-by: Jonathan Cameron Cc: Michael Hennerich Reviewed-by: Rob Herring Acked-by: Nuno Sá Link: https://lore.kernel.org/r/20210627163244.1090296-14-jic23@kernel.org --- .../devicetree/bindings/iio/dac/adi,ad5791.yaml | 52 ++++++++++++++++++++++ 1 file changed, 52 insertions(+) create mode 100644 Documentation/devicetree/bindings/iio/dac/adi,ad5791.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/iio/dac/adi,ad5791.yaml b/Documentation/devicetree/bindings/iio/dac/adi,ad5791.yaml new file mode 100644 index 000000000000..650d1ebdcec3 --- /dev/null +++ b/Documentation/devicetree/bindings/iio/dac/adi,ad5791.yaml @@ -0,0 +1,52 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iio/dac/adi,ad5791.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Analog Devices AD5791 and similar DACs + +maintainers: + - Michael Hennerich + - Jonathan Cameron + +properties: + + compatible: + enum: + - adi,ad5760 + - adi,ad5780 + - adi,ad5781 + - adi,ad5790 + - adi,ad5791 + + reg: + maxItems: 1 + + spi-max-frequency: true + + vdd-supply: true + vss-supply: true + +additionalProperties: false + +required: + - compatible + - reg + - vdd-supply + - vss-supply + +examples: + - | + spi { + #address-cells = <1>; + #size-cells = <0>; + + dac@0 { + compatible = "adi,ad5791"; + reg = <0>; + vss-supply = <&dac_vss>; + vdd-supply = <&dac_vdd>; + }; + }; +... -- cgit v1.2.3 From 906b00437e71764624f666b75abfe45b087b17c8 Mon Sep 17 00:00:00 2001 From: Jonathan Cameron Date: Sun, 27 Jun 2021 17:32:43 +0100 Subject: dt-bindings: iio: dac: adi,ad8801: Add missing binding document. MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit This device was missing a binding document. Simple binding with the ad8803 requiring two both low and high references whilst the 8801 only has a high reference. Signed-off-by: Jonathan Cameron Cc: Gwenhael Goavec-Merou Reviewed-by: Rob Herring Acked-by: Nuno Sá Link: https://lore.kernel.org/r/20210627163244.1090296-15-jic23@kernel.org --- .../devicetree/bindings/iio/dac/adi,ad8801.yaml | 60 ++++++++++++++++++++++ 1 file changed, 60 insertions(+) create mode 100644 Documentation/devicetree/bindings/iio/dac/adi,ad8801.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/iio/dac/adi,ad8801.yaml b/Documentation/devicetree/bindings/iio/dac/adi,ad8801.yaml new file mode 100644 index 000000000000..6a3990a8d0ad --- /dev/null +++ b/Documentation/devicetree/bindings/iio/dac/adi,ad8801.yaml @@ -0,0 +1,60 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iio/dac/adi,ad8801.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Analog Devices AD8801 and AD8803 DACs + +maintainers: + - Jonathan Cameron + +properties: + + compatible: + enum: + - adi,ad8801 + - adi,ad8803 + + reg: + maxItems: 1 + + spi-max-frequency: true + + vrefh-supply: true + vrefl-supply: true + +additionalProperties: false + +required: + - compatible + - reg + - vrefh-supply + +allOf: + - if: + properties: + compatible: + contains: + const: adi,ad8803 + then: + required: + - vrefl-supply + else: + properties: + vrefl-supply: false + +examples: + - | + spi { + #address-cells = <1>; + #size-cells = <0>; + + dac@0 { + compatible = "adi,ad8803"; + reg = <0>; + vrefl-supply = <&dac_vrefl>; + vrefh-supply = <&dac_vrefh>; + }; + }; +... -- cgit v1.2.3 From f21a5f7215420c513d2bb2d21fdf24c9a550922e Mon Sep 17 00:00:00 2001 From: Jonathan Cameron Date: Sun, 27 Jun 2021 17:32:44 +0100 Subject: dt-bindings: iio: dac: microchip,mcp4922: Add missing binding document MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Simple binding for this family of microchip DACs. Signed-off-by: Jonathan Cameron Cc: Michael Welling Reviewed-by: Rob Herring Acked-by: Nuno Sá Link: https://lore.kernel.org/r/20210627163244.1090296-16-jic23@kernel.org --- .../bindings/iio/dac/microchip,mcp4922.yaml | 46 ++++++++++++++++++++++ 1 file changed, 46 insertions(+) create mode 100644 Documentation/devicetree/bindings/iio/dac/microchip,mcp4922.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/iio/dac/microchip,mcp4922.yaml b/Documentation/devicetree/bindings/iio/dac/microchip,mcp4922.yaml new file mode 100644 index 000000000000..12a14b3f36cb --- /dev/null +++ b/Documentation/devicetree/bindings/iio/dac/microchip,mcp4922.yaml @@ -0,0 +1,46 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iio/dac/microchip,mcp4922.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Microchip MCP4902, MCP4912 and MPC4922 dual output SPI DACs + +maintainers: + - Jonathan Cameron + - Michael Welling + +properties: + compatible: + enum: + - microchip,mcp4902 + - microchip,mcp4912 + - microchip,mcp4922 + + reg: + maxItems: 1 + + spi-max-frequency: true + + vref-supply: true + +additionalProperties: false + +required: + - compatible + - reg + - vref-supply + +examples: + - | + spi { + #address-cells = <1>; + #size-cells = <0>; + + dac@0 { + compatible = "microchip,mcp4912"; + reg = <0>; + vref-supply = <&dac_vref>; + }; + }; +... -- cgit v1.2.3 From c556478f46c2feb36e415c2d3d4566f92a7e41cd Mon Sep 17 00:00:00 2001 From: Eugen Hristev Date: Mon, 28 Jun 2021 15:04:49 +0300 Subject: dt-bindings: ARM: at91: document sama7g5ek board Document the SAMA7G5 Evaluation Kit based on sama7g5 SoC. Acked-by: Rob Herring Signed-off-by: Eugen Hristev Signed-off-by: Nicolas Ferre Link: https://lore.kernel.org/r/20210628120452.74408-1-eugen.hristev@microchip.com --- Documentation/devicetree/bindings/arm/atmel-at91.yaml | 5 +++++ 1 file changed, 5 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/atmel-at91.yaml b/Documentation/devicetree/bindings/arm/atmel-at91.yaml index 6fc5a22ad962..fba071b9af1d 100644 --- a/Documentation/devicetree/bindings/arm/atmel-at91.yaml +++ b/Documentation/devicetree/bindings/arm/atmel-at91.yaml @@ -145,6 +145,11 @@ properties: - const: atmel,sama5d4 - const: atmel,sama5 + - items: + - const: microchip,sama7g5ek # SAMA7G5 Evaluation Kit + - const: microchip,sama7g5 + - const: microchip,sama7 + - items: - enum: - atmel,sams70j19 -- cgit v1.2.3 From b6862714078c5259ba5eb4785c8575d876bc7bf5 Mon Sep 17 00:00:00 2001 From: Claudiu Beznea Date: Thu, 15 Apr 2021 13:50:02 +0300 Subject: dt-bindings: atmel-sysreg: add bindings for sama7g5 Add RAM controller and RAM PHY controller DT bindings. Signed-off-by: Claudiu Beznea Acked-by: Rob Herring Signed-off-by: Nicolas Ferre Link: https://lore.kernel.org/r/20210415105010.569620-17-claudiu.beznea@microchip.com --- Documentation/devicetree/bindings/arm/atmel-sysregs.txt | 14 +++++++++++++- 1 file changed, 13 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/atmel-sysregs.txt b/Documentation/devicetree/bindings/arm/atmel-sysregs.txt index 807264a78edc..16eef600d599 100644 --- a/Documentation/devicetree/bindings/arm/atmel-sysregs.txt +++ b/Documentation/devicetree/bindings/arm/atmel-sysregs.txt @@ -45,7 +45,8 @@ RAMC SDRAM/DDR Controller required properties: "atmel,at91sam9260-sdramc", "atmel,at91sam9g45-ddramc", "atmel,sama5d3-ddramc", - "microchip,sam9x60-ddramc" + "microchip,sam9x60-ddramc", + "microchip,sama7g5-uddrc" - reg: Should contain registers location and length Examples: @@ -55,6 +56,17 @@ Examples: reg = <0xffffe800 0x200>; }; +RAMC PHY Controller required properties: +- compatible: Should be "microchip,sama7g5-ddr3phy", "syscon" +- reg: Should contain registers location and length + +Example: + + ddr3phy: ddr3phy@e3804000 { + compatible = "microchip,sama7g5-ddr3phy", "syscon"; + reg = <0xe3804000 0x1000>; +}; + SHDWC Shutdown Controller required properties: -- cgit v1.2.3 From ac327f1b10bca6cee8f1a427e5ba451e2d69c710 Mon Sep 17 00:00:00 2001 From: Takashi Iwai Date: Thu, 15 Jul 2021 09:58:26 +0200 Subject: ALSA: doc: Add device-managed resource section Give brief explanations about the device-managed resources and the newly introduced snd_devm_card_new() helper. Link: https://lore.kernel.org/r/20210715075941.23332-5-tiwai@suse.de Signed-off-by: Takashi Iwai --- .../sound/kernel-api/writing-an-alsa-driver.rst | 33 ++++++++++++++++++++++ 1 file changed, 33 insertions(+) (limited to 'Documentation') diff --git a/Documentation/sound/kernel-api/writing-an-alsa-driver.rst b/Documentation/sound/kernel-api/writing-an-alsa-driver.rst index 01d59b8aea92..255b7d3bebd6 100644 --- a/Documentation/sound/kernel-api/writing-an-alsa-driver.rst +++ b/Documentation/sound/kernel-api/writing-an-alsa-driver.rst @@ -4172,6 +4172,39 @@ module license as GPL, etc., otherwise the system is shown as “tainted”. MODULE_LICENSE("GPL"); +Device-Managed Resources +======================== + +In the examples above, all resources are allocated and released +manually. But human beings are lazy in nature, especially developers +are lazier. So there are some ways to automate the release part; it's +the (device-)managed resources aka devres or devm family. For +example, an object allocated via :c:func:`devm_kmalloc()` will be +freed automatically at unbinding the device. + +ALSA core provides also the device-managed helper, namely, +:c:func:`snd_devm_card_new()` for creating a card object. +Call this functions instead of the normal :c:func:`snd_card_new()`, +and you can forget the explicit :c:func:`snd_card_free()` call, as +it's called automagically at error and removal paths. + +One caveat is that the call of :c:func:`snd_card_free()` would be put +at the beginning of the call chain only after you call +:c:func:`snd_card_register()`. + +Also, the ``private_free`` callback is always called at the card free, +so be careful to put the hardware clean-up procedure in +``private_free`` callback. It might be called even before you +actually set up at an earlier error path. For avoiding such an +invalid initialization, you can set ``private_free`` callback after +:c:func:`snd_card_register()` call succeeds. + +Another thing to be remarked is that you should use device-managed +helpers for each component as much as possible once when you manage +the card in that way. Mixing up with the normal and the managed +resources may screw up the release order. + + How To Put Your Driver Into ALSA Tree ===================================== -- cgit v1.2.3 From 2b2d4dfca4e7cb6de70985b1579a6c08c027b8c9 Mon Sep 17 00:00:00 2001 From: Eddie James Date: Fri, 16 Jul 2021 08:39:15 -0500 Subject: dt-bindings: fsi: Remove ibm,fsi2spi-restricted compatible Remove this compatible string from the FSI SPI controller documentation, since the security restrictions have been universally applied to the controllers. Signed-off-by: Eddie James Link: https://lore.kernel.org/r/20210716133915.14697-3-eajames@linux.ibm.com Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/fsi/ibm,fsi2spi.yaml | 1 - 1 file changed, 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/fsi/ibm,fsi2spi.yaml b/Documentation/devicetree/bindings/fsi/ibm,fsi2spi.yaml index e425278653f5..e2ca0b000471 100644 --- a/Documentation/devicetree/bindings/fsi/ibm,fsi2spi.yaml +++ b/Documentation/devicetree/bindings/fsi/ibm,fsi2spi.yaml @@ -19,7 +19,6 @@ properties: compatible: enum: - ibm,fsi2spi - - ibm,fsi2spi-restricted reg: items: -- cgit v1.2.3 From bdad810eb97875813a067504424a483aaa309bad Mon Sep 17 00:00:00 2001 From: Joakim Zhang Date: Mon, 19 Jul 2021 15:18:19 +0800 Subject: dt-bindings: net: snps,dwmac: add missing DWMAC IP version Add missing DWMAC IP version in snps,dwmac.yaml which found by below command, as NXP i.MX8 families support SNPS DWMAC 5.10a IP. $ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- dt_binding_check DT_SCHEMA_FILES=Documentation/devicetree/bindings/net/nxp,dwmac-imx.yaml Documentation/devicetree/bindings/net/nxp,dwmac-imx.example.dt.yaml: ethernet@30bf0000: compatible: None of ['nxp,imx8mp-dwmac-eqos', 'snps,dwmac-5.10a'] are valid under the given schema Signed-off-by: Joakim Zhang Signed-off-by: David S. Miller --- Documentation/devicetree/bindings/net/snps,dwmac.yaml | 3 +++ 1 file changed, 3 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/snps,dwmac.yaml b/Documentation/devicetree/bindings/net/snps,dwmac.yaml index d7652596a09b..42689b7d03a2 100644 --- a/Documentation/devicetree/bindings/net/snps,dwmac.yaml +++ b/Documentation/devicetree/bindings/net/snps,dwmac.yaml @@ -28,6 +28,7 @@ select: - snps,dwmac-4.00 - snps,dwmac-4.10a - snps,dwmac-4.20a + - snps,dwmac-5.10a - snps,dwxgmac - snps,dwxgmac-2.10 @@ -82,6 +83,7 @@ properties: - snps,dwmac-4.00 - snps,dwmac-4.10a - snps,dwmac-4.20a + - snps,dwmac-5.10a - snps,dwxgmac - snps,dwxgmac-2.10 @@ -375,6 +377,7 @@ allOf: - snps,dwmac-4.00 - snps,dwmac-4.10a - snps,dwmac-4.20a + - snps,dwmac-5.10a - snps,dwxgmac - snps,dwxgmac-2.10 - st,spear600-gmac -- cgit v1.2.3 From e314a07ef263916f761b736ded7a30894709dfd7 Mon Sep 17 00:00:00 2001 From: Joakim Zhang Date: Mon, 19 Jul 2021 15:18:20 +0800 Subject: dt-bindings: net: imx-dwmac: convert imx-dwmac bindings to yaml In order to automate the verification of DT nodes covert imx-dwmac to nxp,dwmac-imx.yaml, and pass below checking. $ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- dt_binding_check DT_SCHEMA_FILES=Documentation/devicetree/bindings/net/nxp,dwmac-imx.yaml $ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- dtbs_check DT_SCHEMA_FILES=Documentation/devicetree/bindings/net/nxp,dwmac-imx.yaml Signed-off-by: Joakim Zhang Signed-off-by: David S. Miller --- .../devicetree/bindings/net/imx-dwmac.txt | 56 ------------- .../devicetree/bindings/net/nxp,dwmac-imx.yaml | 93 ++++++++++++++++++++++ 2 files changed, 93 insertions(+), 56 deletions(-) delete mode 100644 Documentation/devicetree/bindings/net/imx-dwmac.txt create mode 100644 Documentation/devicetree/bindings/net/nxp,dwmac-imx.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/imx-dwmac.txt b/Documentation/devicetree/bindings/net/imx-dwmac.txt deleted file mode 100644 index 921d522fe8d7..000000000000 --- a/Documentation/devicetree/bindings/net/imx-dwmac.txt +++ /dev/null @@ -1,56 +0,0 @@ -IMX8 glue layer controller, NXP imx8 families support Synopsys MAC 5.10a IP. - -This file documents platform glue layer for IMX. -Please see stmmac.txt for the other unchanged properties. - -The device node has following properties. - -Required properties: -- compatible: Should be "nxp,imx8mp-dwmac-eqos" to select glue layer - and "snps,dwmac-5.10a" to select IP version. -- clocks: Must contain a phandle for each entry in clock-names. -- clock-names: Should be "stmmaceth" for the host clock. - Should be "pclk" for the MAC apb clock. - Should be "ptp_ref" for the MAC timer clock. - Should be "tx" for the MAC RGMII TX clock: - Should be "mem" for EQOS MEM clock. - - "mem" clock is required for imx8dxl platform. - - "mem" clock is not required for imx8mp platform. -- interrupt-names: Should contain a list of interrupt names corresponding to - the interrupts in the interrupts property, if available. - Should be "macirq" for the main MAC IRQ - Should be "eth_wake_irq" for the IT which wake up system -- intf_mode: Should be phandle/offset pair. The phandle to the syscon node which - encompases the GPR register, and the offset of the GPR register. - - required for imx8mp platform. - - is optional for imx8dxl platform. - -Optional properties: -- intf_mode: is optional for imx8dxl platform. -- snps,rmii_refclk_ext: to select RMII reference clock from external. - -Example: - eqos: ethernet@30bf0000 { - compatible = "nxp,imx8mp-dwmac-eqos", "snps,dwmac-5.10a"; - reg = <0x30bf0000 0x10000>; - interrupts = , - ; - interrupt-names = "eth_wake_irq", "macirq"; - clocks = <&clk IMX8MP_CLK_ENET_QOS_ROOT>, - <&clk IMX8MP_CLK_QOS_ENET_ROOT>, - <&clk IMX8MP_CLK_ENET_QOS_TIMER>, - <&clk IMX8MP_CLK_ENET_QOS>; - clock-names = "stmmaceth", "pclk", "ptp_ref", "tx"; - assigned-clocks = <&clk IMX8MP_CLK_ENET_AXI>, - <&clk IMX8MP_CLK_ENET_QOS_TIMER>, - <&clk IMX8MP_CLK_ENET_QOS>; - assigned-clock-parents = <&clk IMX8MP_SYS_PLL1_266M>, - <&clk IMX8MP_SYS_PLL2_100M>, - <&clk IMX8MP_SYS_PLL2_125M>; - assigned-clock-rates = <0>, <100000000>, <125000000>; - nvmem-cells = <ð_mac0>; - nvmem-cell-names = "mac-address"; - nvmem_macaddr_swap; - intf_mode = <&gpr 0x4>; - status = "disabled"; - }; diff --git a/Documentation/devicetree/bindings/net/nxp,dwmac-imx.yaml b/Documentation/devicetree/bindings/net/nxp,dwmac-imx.yaml new file mode 100644 index 000000000000..5629b2e4ccf8 --- /dev/null +++ b/Documentation/devicetree/bindings/net/nxp,dwmac-imx.yaml @@ -0,0 +1,93 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/nxp,dwmac-imx.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NXP i.MX8 DWMAC glue layer Device Tree Bindings + +maintainers: + - Joakim Zhang + +# We need a select here so we don't match all nodes with 'snps,dwmac' +select: + properties: + compatible: + contains: + enum: + - nxp,imx8mp-dwmac-eqos + - nxp,imx8dxl-dwmac-eqos + required: + - compatible + +allOf: + - $ref: "snps,dwmac.yaml#" + +properties: + compatible: + oneOf: + - items: + - enum: + - nxp,imx8mp-dwmac-eqos + - nxp,imx8dxl-dwmac-eqos + - const: snps,dwmac-5.10a + + clocks: + minItems: 3 + maxItems: 5 + items: + - description: MAC host clock + - description: MAC apb clock + - description: MAC timer clock + - description: MAC RGMII TX clock + - description: EQOS MEM clock + + clock-names: + minItems: 3 + maxItems: 5 + contains: + enum: + - stmmaceth + - pclk + - ptp_ref + - tx + - mem + + intf_mode: + $ref: /schemas/types.yaml#/definitions/phandle-array + description: + Should be phandle/offset pair. The phandle to the syscon node which + encompases the GPR register, and the offset of the GPR register. + + snps,rmii_refclk_ext: + $ref: /schemas/types.yaml#/definitions/flag + description: + To select RMII reference clock from external. + +required: + - compatible + - clocks + - clock-names + +unevaluatedProperties: false + +examples: + - | + #include + #include + #include + + eqos: ethernet@30bf0000 { + compatible = "nxp,imx8mp-dwmac-eqos","snps,dwmac-5.10a"; + reg = <0x30bf0000 0x10000>; + interrupts = , + ; + interrupt-names = "macirq", "eth_wake_irq"; + clocks = <&clk IMX8MP_CLK_ENET_QOS_ROOT>, + <&clk IMX8MP_CLK_QOS_ENET_ROOT>, + <&clk IMX8MP_CLK_ENET_QOS_TIMER>, + <&clk IMX8MP_CLK_ENET_QOS>; + clock-names = "stmmaceth", "pclk", "ptp_ref", "tx"; + phy-mode = "rgmii"; + status = "disabled"; + }; -- cgit v1.2.3 From ef537057c298d9abe42dae4da21198ef9f23ade2 Mon Sep 17 00:00:00 2001 From: Bartosz Dudziak Date: Sun, 18 Apr 2021 14:29:08 +0200 Subject: dt-bindings: arm: qcom: Document MSM8226 SoC binding Document the MSM8226 SoC device-tree binding. Signed-off-by: Bartosz Dudziak Acked-by: Rob Herring Link: https://lore.kernel.org/r/20210418122909.71434-5-bartosz.dudziak@snejp.pl Signed-off-by: Bjorn Andersson --- Documentation/devicetree/bindings/arm/qcom.yaml | 6 ++++++ 1 file changed, 6 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml index 9720b00c41d2..7163e5fa33ca 100644 --- a/Documentation/devicetree/bindings/arm/qcom.yaml +++ b/Documentation/devicetree/bindings/arm/qcom.yaml @@ -31,6 +31,7 @@ description: | ipq6018 ipq8074 mdm9615 + msm8226 msm8916 msm8974 msm8992 @@ -114,6 +115,11 @@ properties: - qcom,apq8084-sbc - const: qcom,apq8084 + - items: + - enum: + - samsung,s3ve3g + - const: qcom,msm8226 + - items: - enum: - qcom,msm8960-cdp -- cgit v1.2.3 From e9ad5da25002772436c968309d6dbeaf31c91404 Mon Sep 17 00:00:00 2001 From: Bjorn Andersson Date: Fri, 9 Jul 2021 10:41:40 -0700 Subject: dt-bindings: soc: qcom: aoss: Add SC8180X and generic compatible Add a generic compatible for all versions of the AOSS QMP to the binding, in order to allow a single implementation for them and then add a specific compatible for the Qualcomm SC8180x platform. Acked-by: Rob Herring Link: https://lore.kernel.org/r/20210709174142.1274554-2-bjorn.andersson@linaro.org Signed-off-by: Bjorn Andersson --- Documentation/devicetree/bindings/soc/qcom/qcom,aoss-qmp.txt | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,aoss-qmp.txt b/Documentation/devicetree/bindings/soc/qcom/qcom,aoss-qmp.txt index 783dc81b0f26..3747032311a4 100644 --- a/Documentation/devicetree/bindings/soc/qcom/qcom,aoss-qmp.txt +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,aoss-qmp.txt @@ -18,10 +18,13 @@ power-domains. Definition: must be one of: "qcom,sc7180-aoss-qmp" "qcom,sc7280-aoss-qmp" + "qcom,sc8180x-aoss-qmp" "qcom,sdm845-aoss-qmp" "qcom,sm8150-aoss-qmp" "qcom,sm8250-aoss-qmp" "qcom,sm8350-aoss-qmp" + and: + "qcom,aoss-qmp" - reg: Usage: required @@ -70,7 +73,7 @@ The following example represents the AOSS side-channel message RAM and the mechanism exposing the power-domains, as found in SDM845. aoss_qmp: qmp@c300000 { - compatible = "qcom,sdm845-aoss-qmp"; + compatible = "qcom,sdm845-aoss-qmp", "qcom,aoss-qmp"; reg = <0x0c300000 0x100000>; interrupts = ; mboxes = <&apss_shared 0>; -- cgit v1.2.3 From 44dadfbcd992829515c80ff7d1bbab73cd321a3f Mon Sep 17 00:00:00 2001 From: Bjorn Andersson Date: Fri, 9 Jul 2021 10:41:41 -0700 Subject: dt-bindings: soc: qcom: aoss: Convert to YAML Convert to YAML in order to allow validation. Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20210709174142.1274554-3-bjorn.andersson@linaro.org Signed-off-by: Bjorn Andersson --- .../devicetree/bindings/soc/qcom/qcom,aoss-qmp.txt | 90 ---------------- .../bindings/soc/qcom/qcom,aoss-qmp.yaml | 114 +++++++++++++++++++++ 2 files changed, 114 insertions(+), 90 deletions(-) delete mode 100644 Documentation/devicetree/bindings/soc/qcom/qcom,aoss-qmp.txt create mode 100644 Documentation/devicetree/bindings/soc/qcom/qcom,aoss-qmp.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,aoss-qmp.txt b/Documentation/devicetree/bindings/soc/qcom/qcom,aoss-qmp.txt deleted file mode 100644 index 3747032311a4..000000000000 --- a/Documentation/devicetree/bindings/soc/qcom/qcom,aoss-qmp.txt +++ /dev/null @@ -1,90 +0,0 @@ -Qualcomm Always-On Subsystem side channel binding - -This binding describes the hardware component responsible for side channel -requests to the always-on subsystem (AOSS), used for certain power management -requests that is not handled by the standard RPMh interface. Each client in the -SoC has it's own block of message RAM and IRQ for communication with the AOSS. -The protocol used to communicate in the message RAM is known as Qualcomm -Messaging Protocol (QMP) - -The AOSS side channel exposes control over a set of resources, used to control -a set of debug related clocks and to affect the low power state of resources -related to the secondary subsystems. These resources are exposed as a set of -power-domains. - -- compatible: - Usage: required - Value type: - Definition: must be one of: - "qcom,sc7180-aoss-qmp" - "qcom,sc7280-aoss-qmp" - "qcom,sc8180x-aoss-qmp" - "qcom,sdm845-aoss-qmp" - "qcom,sm8150-aoss-qmp" - "qcom,sm8250-aoss-qmp" - "qcom,sm8350-aoss-qmp" - and: - "qcom,aoss-qmp" - -- reg: - Usage: required - Value type: - Definition: the base address and size of the message RAM for this - client's communication with the AOSS - -- interrupts: - Usage: required - Value type: - Definition: should specify the AOSS message IRQ for this client - -- mboxes: - Usage: required - Value type: - Definition: reference to the mailbox representing the outgoing doorbell - in APCS for this client, as described in mailbox/mailbox.txt - -- #clock-cells: - Usage: optional - Value type: - Definition: must be 0 - The single clock represents the QDSS clock. - -- #power-domain-cells: - Usage: optional - Value type: - Definition: must be 1 - The provided power-domains are: - CDSP state (0), LPASS state (1), modem state (2), SLPI - state (3), SPSS state (4) and Venus state (5). - -= SUBNODES -The AOSS side channel also provides the controls for three cooling devices, -these are expressed as subnodes of the QMP node. The name of the node is used -to identify the resource and must therefor be "cx", "mx" or "ebi". - -- #cooling-cells: - Usage: optional - Value type: - Definition: must be 2 - -= EXAMPLE - -The following example represents the AOSS side-channel message RAM and the -mechanism exposing the power-domains, as found in SDM845. - - aoss_qmp: qmp@c300000 { - compatible = "qcom,sdm845-aoss-qmp", "qcom,aoss-qmp"; - reg = <0x0c300000 0x100000>; - interrupts = ; - mboxes = <&apss_shared 0>; - - #power-domain-cells = <1>; - - cx_cdev: cx { - #cooling-cells = <2>; - }; - - mx_cdev: mx { - #cooling-cells = <2>; - }; - }; diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,aoss-qmp.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,aoss-qmp.yaml new file mode 100644 index 000000000000..93e4b737ee1b --- /dev/null +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,aoss-qmp.yaml @@ -0,0 +1,114 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/soc/qcom/qcom,aoss-qmp.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Always-On Subsystem side channel binding + +maintainers: + - Bjorn Andersson + +description: + This binding describes the hardware component responsible for side channel + requests to the always-on subsystem (AOSS), used for certain power management + requests that is not handled by the standard RPMh interface. Each client in the + SoC has it's own block of message RAM and IRQ for communication with the AOSS. + The protocol used to communicate in the message RAM is known as Qualcomm + Messaging Protocol (QMP) + + The AOSS side channel exposes control over a set of resources, used to control + a set of debug related clocks and to affect the low power state of resources + related to the secondary subsystems. These resources are exposed as a set of + power-domains. + +properties: + compatible: + items: + - enum: + - qcom,sc7180-aoss-qmp + - qcom,sc7280-aoss-qmp + - qcom,sc8180x-aoss-qmp + - qcom,sdm845-aoss-qmp + - qcom,sm8150-aoss-qmp + - qcom,sm8250-aoss-qmp + - qcom,sm8350-aoss-qmp + - const: qcom,aoss-qmp + + reg: + maxItems: 1 + description: + The base address and size of the message RAM for this client's + communication with the AOSS + + interrupts: + maxItems: 1 + description: + Should specify the AOSS message IRQ for this client + + mboxes: + maxItems: 1 + description: + Reference to the mailbox representing the outgoing doorbell in APCS for + this client, as described in mailbox/mailbox.txt + + "#clock-cells": + const: 0 + description: + The single clock represents the QDSS clock. + + "#power-domain-cells": + const: 1 + description: | + The provided power-domains are: + CDSP state (0), LPASS state (1), modem state (2), SLPI + state (3), SPSS state (4) and Venus state (5). + +required: + - compatible + - reg + - interrupts + - mboxes + - "#clock-cells" + +additionalProperties: false + +patternProperties: + "^(cx|mx|ebi)$": + type: object + description: + The AOSS side channel also provides the controls for three cooling devices, + these are expressed as subnodes of the QMP node. The name of the node is + used to identify the resource and must therefor be "cx", "mx" or "ebi". + + properties: + "#cooling-cells": + const: 2 + + required: + - "#cooling-cells" + + additionalProperties: false + +examples: + - | + #include + + aoss_qmp: qmp@c300000 { + compatible = "qcom,sdm845-aoss-qmp", "qcom,aoss-qmp"; + reg = <0x0c300000 0x100000>; + interrupts = ; + mboxes = <&apss_shared 0>; + + #clock-cells = <0>; + #power-domain-cells = <1>; + + cx_cdev: cx { + #cooling-cells = <2>; + }; + + mx_cdev: mx { + #cooling-cells = <2>; + }; + }; +... -- cgit v1.2.3 From d3625d94490e4c2d95febe3eafcc11e606eabb0c Mon Sep 17 00:00:00 2001 From: Iskren Chernev Date: Sun, 27 Jun 2021 21:59:23 +0300 Subject: dt-bindings: soc: qcom: smd-rpm: Add SM6115 compatible Add the dt-binding for the rpm on the Qualcomm SM4250/6115 SoC platform. Signed-off-by: Iskren Chernev Acked-by: Rob Herring Link: https://lore.kernel.org/r/20210627185927.695411-2-iskren.chernev@gmail.com Signed-off-by: Bjorn Andersson --- Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.yaml index d511f01fcac6..cc3fe5ed7421 100644 --- a/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.yaml +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.yaml @@ -39,6 +39,7 @@ properties: - qcom,rpm-msm8996 - qcom,rpm-msm8998 - qcom,rpm-sdm660 + - qcom,rpm-sm6115 - qcom,rpm-sm6125 - qcom,rpm-qcs404 -- cgit v1.2.3 From 42694f9f6407a933ce0880e12c2aaef01073ec28 Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Sun, 18 Jul 2021 13:40:48 +0200 Subject: dt-bindings: PCI: add snps,dw-pcie.yaml Currently, the designware schema is defined on a text file: designware-pcie.txt Convert the pci-bus part into a schema. Signed-off-by: Mauro Carvalho Chehab Link: https://lore.kernel.org/r/53363a7609176ca56c47ef57287466ee84087dc5.1626608375.git.mchehab+huawei@kernel.org Signed-off-by: Rob Herring --- .../devicetree/bindings/pci/snps,dw-pcie.yaml | 101 +++++++++++++++++++++ 1 file changed, 101 insertions(+) create mode 100644 Documentation/devicetree/bindings/pci/snps,dw-pcie.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pci/snps,dw-pcie.yaml b/Documentation/devicetree/bindings/pci/snps,dw-pcie.yaml new file mode 100644 index 000000000000..a8c1db879fb9 --- /dev/null +++ b/Documentation/devicetree/bindings/pci/snps,dw-pcie.yaml @@ -0,0 +1,101 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pci/snps,dw-pcie.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Synopsys DesignWare PCIe interface + +maintainers: + - Jingoo Han + - Gustavo Pimentel + +description: | + Synopsys DesignWare PCIe host controller + +allOf: + - $ref: /schemas/pci/pci-bus.yaml# + +properties: + compatible: + anyOf: + - {} + - const: snps,dw-pcie + + reg: + description: | + It should contain Data Bus Interface (dbi) and config registers for all + versions. + For designware core version >= 4.80, it may contain ATU address space. + minItems: 2 + maxItems: 5 + + reg-names: + minItems: 2 + maxItems: 5 + items: + enum: [dbi, dbi2, config, atu, app, elbi, mgmt, ctrl, parf, cfg, link] + + num-lanes: + description: | + number of lanes to use (this property should be specified unless + the link is brought already up in firmware) + maximum: 16 + + reset-gpio: + description: GPIO pin number of PERST# signal + maxItems: 1 + deprecated: true + + reset-gpios: + description: GPIO controlled connection to PERST# signal + maxItems: 1 + + interrupts: true + + interrupt-names: true + + clocks: true + + snps,enable-cdm-check: + type: boolean + description: | + This is a boolean property and if present enables + automatic checking of CDM (Configuration Dependent Module) registers + for data corruption. CDM registers include standard PCIe configuration + space registers, Port Logic registers, DMA and iATU (internal Address + Translation Unit) registers. + + num-viewport: + description: | + number of view ports configured in hardware. If a platform + does not specify it, the driver autodetects it. + deprecated: true + +unevaluatedProperties: false + +required: + - reg + - reg-names + - compatible + +examples: + - | + bus { + #address-cells = <1>; + #size-cells = <1>; + pcie@dfc00000 { + device_type = "pci"; + compatible = "snps,dw-pcie"; + reg = <0xdfc00000 0x0001000>, /* IP registers */ + <0xd0000000 0x0002000>; /* Configuration space */ + reg-names = "dbi", "config"; + #address-cells = <3>; + #size-cells = <2>; + ranges = <0x81000000 0 0x00000000 0xde000000 0 0x00010000>, + <0x82000000 0 0xd0400000 0xd0400000 0 0x0d000000>; + interrupts = <25>, <24>; + #interrupt-cells = <1>; + num-lanes = <1>; + }; + }; -- cgit v1.2.3 From 0f8b97d8f6021c525bc5fa7e4927401a39086c9f Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Sun, 18 Jul 2021 13:40:49 +0200 Subject: dt-bindings: PCI: add snps,dw-pcie-ep.yaml Currently, the designware schema is defined on a text file: designware-pcie.txt It contains two separate schemas on it: - snps,dw-pcie This one uses the pci-bus.yaml schema; - snps,dw-pcie-ep This one uses the pci-ep.yaml schema. As the: AllOf: - $ref: for the endpoint part is different than the PCI one, place it on a separate yaml file. Signed-off-by: Mauro Carvalho Chehab Link: https://lore.kernel.org/r/26025b256232c2e4bd91954907b9d92db27199a3.1626608375.git.mchehab+huawei@kernel.org Signed-off-by: Rob Herring --- .../devicetree/bindings/pci/snps,dw-pcie-ep.yaml | 90 ++++++++++++++++++++++ 1 file changed, 90 insertions(+) create mode 100644 Documentation/devicetree/bindings/pci/snps,dw-pcie-ep.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pci/snps,dw-pcie-ep.yaml b/Documentation/devicetree/bindings/pci/snps,dw-pcie-ep.yaml new file mode 100644 index 000000000000..b5935b1b153f --- /dev/null +++ b/Documentation/devicetree/bindings/pci/snps,dw-pcie-ep.yaml @@ -0,0 +1,90 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pci/snps,dw-pcie-ep.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Synopsys DesignWare PCIe endpoint interface + +maintainers: + - Jingoo Han + - Gustavo Pimentel + +description: | + Synopsys DesignWare PCIe host controller endpoint + +allOf: + - $ref: /schemas/pci/pci-ep.yaml# + +properties: + compatible: + anyOf: + - {} + - const: snps,dw-pcie-ep + + reg: + description: | + It should contain Data Bus Interface (dbi) and config registers for all + versions. + For designware core version >= 4.80, it may contain ATU address space. + minItems: 2 + maxItems: 4 + + reg-names: + minItems: 2 + maxItems: 4 + items: + enum: [dbi, dbi2, config, atu, addr_space, link, atu_dma, appl] + + reset-gpio: + description: GPIO pin number of PERST# signal + maxItems: 1 + deprecated: true + + reset-gpios: + description: GPIO controlled connection to PERST# signal + maxItems: 1 + + snps,enable-cdm-check: + type: boolean + description: | + This is a boolean property and if present enables + automatic checking of CDM (Configuration Dependent Module) registers + for data corruption. CDM registers include standard PCIe configuration + space registers, Port Logic registers, DMA and iATU (internal Address + Translation Unit) registers. + + num-ib-windows: + description: number of inbound address translation windows + maxItems: 1 + deprecated: true + + num-ob-windows: + description: number of outbound address translation windows + maxItems: 1 + deprecated: true + + max-functions: + $ref: /schemas/types.yaml#/definitions/uint32 + description: maximum number of functions that can be configured + +required: + - reg + - reg-names + - compatible + +unevaluatedProperties: false + +examples: + - | + bus { + #address-cells = <1>; + #size-cells = <1>; + pcie-ep@dfd00000 { + compatible = "snps,dw-pcie-ep"; + reg = <0xdfc00000 0x0001000>, /* IP registers 1 */ + <0xdfc01000 0x0001000>, /* IP registers 2 */ + <0xd0000000 0x2000000>; /* Configuration space */ + reg-names = "dbi", "dbi2", "addr_space"; + }; + }; -- cgit v1.2.3 From 320e10986ef7eda166891493d1f6ff1564dd6275 Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Sun, 18 Jul 2021 13:40:50 +0200 Subject: dt-bindings: PCI: update references to Designware schema Now that its contents were converted to a DT schema, replace the references for the old file on existing properties. Signed-off-by: Mauro Carvalho Chehab Link: https://lore.kernel.org/r/dfff4d94631546c53450d1baeddc694dd26b5c36.1626608375.git.mchehab+huawei@kernel.org Signed-off-by: Rob Herring --- .../devicetree/bindings/pci/amlogic,meson-pcie.txt | 4 ++-- .../devicetree/bindings/pci/axis,artpec6-pcie.txt | 2 +- Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt | 2 +- .../devicetree/bindings/pci/hisilicon-histb-pcie.txt | 2 +- Documentation/devicetree/bindings/pci/kirin-pcie.txt | 2 +- Documentation/devicetree/bindings/pci/layerscape-pci.txt | 2 +- .../devicetree/bindings/pci/nvidia,tegra194-pcie.txt | 5 +++-- Documentation/devicetree/bindings/pci/pci-armada8k.txt | 2 +- Documentation/devicetree/bindings/pci/pcie-al.txt | 2 +- Documentation/devicetree/bindings/pci/qcom,pcie.txt | 14 +++++++------- .../devicetree/bindings/pci/samsung,exynos-pcie.yaml | 4 ++-- .../devicetree/bindings/pci/sifive,fu740-pcie.yaml | 4 ++-- .../bindings/pci/socionext,uniphier-pcie-ep.yaml | 4 ++-- Documentation/devicetree/bindings/pci/ti-pci.txt | 4 ++-- Documentation/devicetree/bindings/pci/uniphier-pcie.txt | 2 +- 15 files changed, 28 insertions(+), 27 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pci/amlogic,meson-pcie.txt b/Documentation/devicetree/bindings/pci/amlogic,meson-pcie.txt index b6acbe694ffb..c3a75ac6e59d 100644 --- a/Documentation/devicetree/bindings/pci/amlogic,meson-pcie.txt +++ b/Documentation/devicetree/bindings/pci/amlogic,meson-pcie.txt @@ -3,7 +3,7 @@ Amlogic Meson AXG DWC PCIE SoC controller Amlogic Meson PCIe host controller is based on the Synopsys DesignWare PCI core. It shares common functions with the PCIe DesignWare core driver and inherits common properties defined in -Documentation/devicetree/bindings/pci/designware-pcie.txt. +Documentation/devicetree/bindings/pci/snps,dw-pcie.yaml. Additional properties are described here: @@ -33,7 +33,7 @@ Required properties: - phy-names: must contain "pcie" - device_type: - should be "pci". As specified in designware-pcie.txt + should be "pci". As specified in snps,dw-pcie.yaml Example configuration: diff --git a/Documentation/devicetree/bindings/pci/axis,artpec6-pcie.txt b/Documentation/devicetree/bindings/pci/axis,artpec6-pcie.txt index 979dc7b6cfe8..cc6dcdb676b9 100644 --- a/Documentation/devicetree/bindings/pci/axis,artpec6-pcie.txt +++ b/Documentation/devicetree/bindings/pci/axis,artpec6-pcie.txt @@ -1,7 +1,7 @@ * Axis ARTPEC-6 PCIe interface This PCIe host controller is based on the Synopsys DesignWare PCIe IP -and thus inherits all the common properties defined in designware-pcie.txt. +and thus inherits all the common properties defined in snps,dw-pcie.yaml. Required properties: - compatible: "axis,artpec6-pcie", "snps,dw-pcie" for ARTPEC-6 in RC mode; diff --git a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt index d8971ab99274..5e6eb44c81b5 100644 --- a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt +++ b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt @@ -1,7 +1,7 @@ * Freescale i.MX6 PCIe interface This PCIe host controller is based on the Synopsys DesignWare PCIe IP -and thus inherits all the common properties defined in designware-pcie.txt. +and thus inherits all the common properties defined in snps,dw-pcie.yaml. Required properties: - compatible: diff --git a/Documentation/devicetree/bindings/pci/hisilicon-histb-pcie.txt b/Documentation/devicetree/bindings/pci/hisilicon-histb-pcie.txt index 760b4d740616..5f0cf6c2fef3 100644 --- a/Documentation/devicetree/bindings/pci/hisilicon-histb-pcie.txt +++ b/Documentation/devicetree/bindings/pci/hisilicon-histb-pcie.txt @@ -3,7 +3,7 @@ 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. +Documentation/devicetree/bindings/pci/snps,dw-pcie.yaml. Additional properties are described here: diff --git a/Documentation/devicetree/bindings/pci/kirin-pcie.txt b/Documentation/devicetree/bindings/pci/kirin-pcie.txt index 6bbe43818ad5..7db30534498f 100644 --- a/Documentation/devicetree/bindings/pci/kirin-pcie.txt +++ b/Documentation/devicetree/bindings/pci/kirin-pcie.txt @@ -3,7 +3,7 @@ HiSilicon Kirin SoCs PCIe host DT description Kirin PCIe host controller is based on the Synopsys DesignWare PCI core. It shares common functions with the PCIe DesignWare core driver and inherits common properties defined in -Documentation/devicetree/bindings/pci/designware-pcie.txt. +Documentation/devicetree/bindings/pci/snps,dw-pcie.yaml. Additional properties are described here: diff --git a/Documentation/devicetree/bindings/pci/layerscape-pci.txt b/Documentation/devicetree/bindings/pci/layerscape-pci.txt index 6d898dd4a8e2..f36efa73a470 100644 --- a/Documentation/devicetree/bindings/pci/layerscape-pci.txt +++ b/Documentation/devicetree/bindings/pci/layerscape-pci.txt @@ -1,7 +1,7 @@ Freescale Layerscape PCIe controller This PCIe host controller is based on the Synopsys DesignWare PCIe IP -and thus inherits all the common properties defined in designware-pcie.txt. +and thus inherits all the common properties defined in snps,dw-pcie.yaml. This controller derives its clocks from the Reset Configuration Word (RCW) which is used to describe the PLL settings at the time of chip-reset. diff --git a/Documentation/devicetree/bindings/pci/nvidia,tegra194-pcie.txt b/Documentation/devicetree/bindings/pci/nvidia,tegra194-pcie.txt index bd43f3c3ece4..6a99d2aa8075 100644 --- a/Documentation/devicetree/bindings/pci/nvidia,tegra194-pcie.txt +++ b/Documentation/devicetree/bindings/pci/nvidia,tegra194-pcie.txt @@ -1,7 +1,8 @@ NVIDIA Tegra PCIe controller (Synopsys DesignWare Core based) This PCIe controller is based on the Synopsis Designware PCIe IP -and thus inherits all the common properties defined in designware-pcie.txt. +and thus inherits all the common properties defined in snps,dw-pcie.yaml and +snps,dw-pcie-ep.yaml. Some of the controller instances are dual mode where in they can work either in root port mode or endpoint mode but one at a time. @@ -22,7 +23,7 @@ Required properties: property. - reg-names: Must include the following entries: "appl": Controller's application logic registers - "config": As per the definition in designware-pcie.txt + "config": As per the definition in snps,dw-pcie.yaml "atu_dma": iATU and DMA registers. This is where the iATU (internal Address Translation Unit) registers of the PCIe core are made available for SW access. diff --git a/Documentation/devicetree/bindings/pci/pci-armada8k.txt b/Documentation/devicetree/bindings/pci/pci-armada8k.txt index 7a813d0e6d63..ff25a134befa 100644 --- a/Documentation/devicetree/bindings/pci/pci-armada8k.txt +++ b/Documentation/devicetree/bindings/pci/pci-armada8k.txt @@ -1,7 +1,7 @@ * Marvell Armada 7K/8K PCIe interface This PCIe host controller is based on the Synopsys DesignWare PCIe IP -and thus inherits all the common properties defined in designware-pcie.txt. +and thus inherits all the common properties defined in snps,dw-pcie.yaml. Required properties: - compatible: "marvell,armada8k-pcie" diff --git a/Documentation/devicetree/bindings/pci/pcie-al.txt b/Documentation/devicetree/bindings/pci/pcie-al.txt index 557a5089229d..2ad1fe466eab 100644 --- a/Documentation/devicetree/bindings/pci/pcie-al.txt +++ b/Documentation/devicetree/bindings/pci/pcie-al.txt @@ -2,7 +2,7 @@ Amazon's Annapurna Labs PCIe Host Controller is based on the Synopsys DesignWare PCI core. It inherits common properties defined in -Documentation/devicetree/bindings/pci/designware-pcie.txt. +Documentation/devicetree/bindings/pci/snps,dw-pcie.yaml. Properties of the host controller node that differ from it are: diff --git a/Documentation/devicetree/bindings/pci/qcom,pcie.txt b/Documentation/devicetree/bindings/pci/qcom,pcie.txt index 25f4def468bf..3f646875f8c2 100644 --- a/Documentation/devicetree/bindings/pci/qcom,pcie.txt +++ b/Documentation/devicetree/bindings/pci/qcom,pcie.txt @@ -34,22 +34,22 @@ - device_type: Usage: required Value type: - Definition: Should be "pci". As specified in designware-pcie.txt + Definition: Should be "pci". As specified in snps,dw-pcie.yaml - #address-cells: Usage: required Value type: - Definition: Should be 3. As specified in designware-pcie.txt + Definition: Should be 3. As specified in snps,dw-pcie.yaml - #size-cells: Usage: required Value type: - Definition: Should be 2. As specified in designware-pcie.txt + Definition: Should be 2. As specified in snps,dw-pcie.yaml - ranges: Usage: required Value type: - Definition: As specified in designware-pcie.txt + Definition: As specified in snps,dw-pcie.yaml - interrupts: Usage: required @@ -64,17 +64,17 @@ - #interrupt-cells: Usage: required Value type: - Definition: Should be 1. As specified in designware-pcie.txt + Definition: Should be 1. As specified in snps,dw-pcie.yaml - interrupt-map-mask: Usage: required Value type: - Definition: As specified in designware-pcie.txt + Definition: As specified in snps,dw-pcie.yaml - interrupt-map: Usage: required Value type: - Definition: As specified in designware-pcie.txt + Definition: As specified in snps,dw-pcie.yaml - clocks: Usage: required diff --git a/Documentation/devicetree/bindings/pci/samsung,exynos-pcie.yaml b/Documentation/devicetree/bindings/pci/samsung,exynos-pcie.yaml index 1810bf722350..445eed94b53f 100644 --- a/Documentation/devicetree/bindings/pci/samsung,exynos-pcie.yaml +++ b/Documentation/devicetree/bindings/pci/samsung,exynos-pcie.yaml @@ -13,10 +13,10 @@ maintainers: description: |+ Exynos5433 SoC PCIe host controller is based on the Synopsys DesignWare PCIe IP and thus inherits all the common properties defined in - designware-pcie.txt. + snps,dw-pcie.yaml. allOf: - - $ref: /schemas/pci/pci-bus.yaml# + - $ref: /schemas/pci/snps,dw-pcie.yaml# properties: compatible: diff --git a/Documentation/devicetree/bindings/pci/sifive,fu740-pcie.yaml b/Documentation/devicetree/bindings/pci/sifive,fu740-pcie.yaml index b03cbb9b6602..2b9d1d6fc661 100644 --- a/Documentation/devicetree/bindings/pci/sifive,fu740-pcie.yaml +++ b/Documentation/devicetree/bindings/pci/sifive,fu740-pcie.yaml @@ -10,14 +10,14 @@ description: |+ SiFive FU740 PCIe host controller is based on the Synopsys DesignWare PCI core. It shares common features with the PCIe DesignWare core and inherits common properties defined in - Documentation/devicetree/bindings/pci/designware-pcie.txt. + Documentation/devicetree/bindings/pci/snps,dw-pcie.yaml. maintainers: - Paul Walmsley - Greentime Hu allOf: - - $ref: /schemas/pci/pci-bus.yaml# + - $ref: /schemas/pci/snps,dw-pcie.yaml# properties: compatible: diff --git a/Documentation/devicetree/bindings/pci/socionext,uniphier-pcie-ep.yaml b/Documentation/devicetree/bindings/pci/socionext,uniphier-pcie-ep.yaml index d6cf8a560ef0..144cbcd60a1c 100644 --- a/Documentation/devicetree/bindings/pci/socionext,uniphier-pcie-ep.yaml +++ b/Documentation/devicetree/bindings/pci/socionext,uniphier-pcie-ep.yaml @@ -10,13 +10,13 @@ description: | UniPhier PCIe endpoint controller is based on the Synopsys DesignWare PCI core. It shares common features with the PCIe DesignWare core and inherits common properties defined in - Documentation/devicetree/bindings/pci/designware-pcie.txt. + Documentation/devicetree/bindings/pci/snps,dw-pcie-ep.yaml. maintainers: - Kunihiko Hayashi allOf: - - $ref: "pci-ep.yaml#" + - $ref: /schemas/pci/snps,dw-pcie-ep.yaml# properties: compatible: diff --git a/Documentation/devicetree/bindings/pci/ti-pci.txt b/Documentation/devicetree/bindings/pci/ti-pci.txt index d5cbfe6b0d89..8147e3e3e29b 100644 --- a/Documentation/devicetree/bindings/pci/ti-pci.txt +++ b/Documentation/devicetree/bindings/pci/ti-pci.txt @@ -12,7 +12,7 @@ PCIe DesignWare Controller number of PHYs as specified in *phys* property. - ti,hwmods : Name of the hwmod associated to the pcie, "pcie", where is the instance number of the pcie from the HW spec. - - num-lanes as specified in ../designware-pcie.txt + - num-lanes as specified in ../snps,dw-pcie.yaml - ti,syscon-lane-sel : phandle/offset pair. Phandle to the system control module and the register offset to specify lane selection. @@ -32,7 +32,7 @@ HOST MODE device_type, ranges, interrupt-map-mask, - interrupt-map : as specified in ../designware-pcie.txt + interrupt-map : as specified in ../snps,dw-pcie.yaml - ti,syscon-unaligned-access: phandle to the syscon DT node. The 1st argument should contain the register offset within syscon and the 2nd argument should contain the bit field diff --git a/Documentation/devicetree/bindings/pci/uniphier-pcie.txt b/Documentation/devicetree/bindings/pci/uniphier-pcie.txt index c4b7381733a0..359585db049f 100644 --- a/Documentation/devicetree/bindings/pci/uniphier-pcie.txt +++ b/Documentation/devicetree/bindings/pci/uniphier-pcie.txt @@ -6,7 +6,7 @@ on Socionext UniPhier SoCs. UniPhier PCIe host controller is based on the Synopsys DesignWare PCI core. It shares common functions with the PCIe DesignWare core driver and inherits common properties defined in -Documentation/devicetree/bindings/pci/designware-pcie.txt. +Documentation/devicetree/bindings/pci/snps,dw-pcie.yaml. Required properties: - compatible: Should be "socionext,uniphier-pcie". -- cgit v1.2.3 From 1c14c1695e78f63a93a1347e15a6e363d7325b43 Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Sun, 18 Jul 2021 13:40:51 +0200 Subject: dt-bindings: PCI: remove designware-pcie.txt Now that the properties defined there were converted to DT schema, and the other dt-bindings are pointing to the new schemas, drop it. Signed-off-by: Mauro Carvalho Chehab Link: https://lore.kernel.org/r/c93261b41f9ffe8d97d8c930f57b41aaf7de5264.1626608375.git.mchehab+huawei@kernel.org Signed-off-by: Rob Herring --- .../devicetree/bindings/pci/designware-pcie.txt | 77 ---------------------- 1 file changed, 77 deletions(-) delete mode 100644 Documentation/devicetree/bindings/pci/designware-pcie.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pci/designware-pcie.txt b/Documentation/devicetree/bindings/pci/designware-pcie.txt deleted file mode 100644 index 78494c4050f7..000000000000 --- a/Documentation/devicetree/bindings/pci/designware-pcie.txt +++ /dev/null @@ -1,77 +0,0 @@ -* Synopsys DesignWare PCIe interface - -Required properties: -- compatible: - "snps,dw-pcie" for RC mode; - "snps,dw-pcie-ep" for EP mode; -- reg: For designware cores version < 4.80 contains the configuration - address space. For designware core version >= 4.80, contains - the configuration and ATU address space -- reg-names: Must be "config" for the PCIe configuration space and "atu" for - the ATU address space. - (The old way of getting the configuration address space from "ranges" - is deprecated and should be avoided.) -RC mode: -- #address-cells: set to <3> -- #size-cells: set to <2> -- device_type: set to "pci" -- ranges: ranges for the PCI memory and I/O regions -- #interrupt-cells: set to <1> -- interrupt-map-mask and interrupt-map: standard PCI - properties to define the mapping of the PCIe interface to interrupt - numbers. -EP mode: -- num-ib-windows: number of inbound address translation windows -- num-ob-windows: number of outbound address translation windows - -Optional properties: -- num-lanes: number of lanes to use (this property should be specified unless - the link is brought already up in BIOS) -- reset-gpio: GPIO pin number of power good signal -- clocks: Must contain an entry for each entry in clock-names. - See ../clocks/clock-bindings.txt for details. -- clock-names: Must include the following entries: - - "pcie" - - "pcie_bus" -- snps,enable-cdm-check: This is a boolean property and if present enables - automatic checking of CDM (Configuration Dependent Module) registers - for data corruption. CDM registers include standard PCIe configuration - space registers, Port Logic registers, DMA and iATU (internal Address - Translation Unit) registers. -RC mode: -- num-viewport: number of view ports configured in hardware. If a platform - does not specify it, the driver assumes 2. -- bus-range: PCI bus numbers covered (it is recommended for new devicetrees - to specify this property, to keep backwards compatibility a range of - 0x00-0xff is assumed if not present) - -EP mode: -- max-functions: maximum number of functions that can be configured - -Example configuration: - - pcie: pcie@dfc00000 { - compatible = "snps,dw-pcie"; - reg = <0xdfc00000 0x0001000>, /* IP registers */ - <0xd0000000 0x0002000>; /* Configuration space */ - reg-names = "dbi", "config"; - #address-cells = <3>; - #size-cells = <2>; - device_type = "pci"; - ranges = <0x81000000 0 0x00000000 0xde000000 0 0x00010000 - 0x82000000 0 0xd0400000 0xd0400000 0 0x0d000000>; - interrupts = <25>, <24>; - #interrupt-cells = <1>; - num-lanes = <1>; - }; -or - pcie: pcie@dfc00000 { - compatible = "snps,dw-pcie-ep"; - reg = <0xdfc00000 0x0001000>, /* IP registers 1 */ - <0xdfc01000 0x0001000>, /* IP registers 2 */ - <0xd0000000 0x2000000>; /* Configuration space */ - reg-names = "dbi", "dbi2", "addr_space"; - num-ib-windows = <6>; - num-ob-windows = <2>; - num-lanes = <1>; - }; -- cgit v1.2.3 From 49a22c4a7136d257d80b9863093a8e66eeb06baa Mon Sep 17 00:00:00 2001 From: Iskren Chernev Date: Sun, 27 Jun 2021 21:59:26 +0300 Subject: dt-bindings: power: rpmpd: Add SM6115 to rpmpd binding Add compatible and constants for the power domains exposed by the RPM in the Qualcomm SM4250/6115 platforms. Signed-off-by: Iskren Chernev Acked-by: Rob Herring Link: https://lore.kernel.org/r/20210627185927.695411-5-iskren.chernev@gmail.com Signed-off-by: Bjorn Andersson --- Documentation/devicetree/bindings/power/qcom,rpmpd.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml b/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml index 4807b560f00d..239f37881cae 100644 --- a/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml +++ b/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml @@ -30,6 +30,7 @@ properties: - qcom,sc8180x-rpmhpd - qcom,sdm845-rpmhpd - qcom,sdx55-rpmhpd + - qcom,sm6115-rpmpd - qcom,sm8150-rpmhpd - qcom,sm8250-rpmhpd - qcom,sm8350-rpmhpd -- cgit v1.2.3 From c715def51591a874a9fcfdc9a05d543e8797e697 Mon Sep 17 00:00:00 2001 From: Hridya Valsaraju Date: Mon, 12 Jul 2021 21:07:38 -0700 Subject: dma-buf: Delete the DMA-BUF attachment sysfs statistics MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The DMA-BUF attachment statistics form a subset of the DMA-BUF sysfs statistics that recently merged to the drm-misc tree. They are not UABI yet since they have not merged to the upstream Linux kernel. Since there has been a reported a performance regression due to the overhead of sysfs directory creation/teardown during dma_buf_attach()/dma_buf_detach(), this patch deletes the DMA-BUF attachment statistics from sysfs. Fixes: bdb8d06dfefd ("dmabuf: Add the capability to expose DMA-BUF stats in sysfs") Signed-off-by: Hridya Valsaraju Reviewed-by: Christian König Reviewed-by: Greg Kroah-Hartman Link: https://patchwork.freedesktop.org/patch/msgid/20210713040742.2680135-1-hridya@google.com Signed-off-by: Christian König --- .../ABI/testing/sysfs-kernel-dmabuf-buffers | 28 ---------------------- 1 file changed, 28 deletions(-) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-kernel-dmabuf-buffers b/Documentation/ABI/testing/sysfs-kernel-dmabuf-buffers index a243984ed420..5d3bc997dc64 100644 --- a/Documentation/ABI/testing/sysfs-kernel-dmabuf-buffers +++ b/Documentation/ABI/testing/sysfs-kernel-dmabuf-buffers @@ -22,31 +22,3 @@ KernelVersion: v5.13 Contact: Hridya Valsaraju Description: This file is read-only and specifies the size of the DMA-BUF in bytes. - -What: /sys/kernel/dmabuf/buffers//attachments -Date: May 2021 -KernelVersion: v5.13 -Contact: Hridya Valsaraju -Description: This directory will contain subdirectories representing every - attachment of the DMA-BUF. - -What: /sys/kernel/dmabuf/buffers//attachments/ -Date: May 2021 -KernelVersion: v5.13 -Contact: Hridya Valsaraju -Description: This directory will contain information on the attached device - and the number of current distinct device mappings. - -What: /sys/kernel/dmabuf/buffers//attachments//device -Date: May 2021 -KernelVersion: v5.13 -Contact: Hridya Valsaraju -Description: This file is read-only and is a symlink to the attached device's - sysfs entry. - -What: /sys/kernel/dmabuf/buffers//attachments//map_counter -Date: May 2021 -KernelVersion: v5.13 -Contact: Hridya Valsaraju -Description: This file is read-only and contains a map_counter indicating the - number of distinct device mappings of the attachment. -- cgit v1.2.3 From 05d58bb65607bde24f867d85d27b48c4954e1442 Mon Sep 17 00:00:00 2001 From: Bjorn Andersson Date: Mon, 28 Jun 2021 17:45:08 -0700 Subject: dt-bindings: phy: qcom,qmp: Add sc8180x PCIe compatible Add a compatible for the sc8180x PCIe PHY. Signed-off-by: Bjorn Andersson Acked-by: Rob Herring Link: https://lore.kernel.org/r/20210629004509.1788286-1-bjorn.andersson@linaro.org Signed-off-by: Vinod Koul --- Documentation/devicetree/bindings/phy/qcom,qmp-phy.yaml | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/phy/qcom,qmp-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,qmp-phy.yaml index f0497b8623ad..242560ff52a4 100644 --- a/Documentation/devicetree/bindings/phy/qcom,qmp-phy.yaml +++ b/Documentation/devicetree/bindings/phy/qcom,qmp-phy.yaml @@ -27,6 +27,7 @@ properties: - qcom,msm8998-qmp-ufs-phy - qcom,msm8998-qmp-usb3-phy - qcom,sc7180-qmp-usb3-phy + - qcom,sc8180x-qmp-pcie-phy - qcom,sc8180x-qmp-ufs-phy - qcom,sc8180x-qmp-usb3-phy - qcom,sdm845-qhp-pcie-phy @@ -326,6 +327,7 @@ allOf: compatible: contains: enum: + - qcom,sc8180x-qmp-pcie-phy - qcom,sdm845-qhp-pcie-phy - qcom,sdm845-qmp-pcie-phy - qcom,sdx55-qmp-pcie-phy -- cgit v1.2.3 From 057d445b9ef22c0c17fad46beb82146c9f0574c0 Mon Sep 17 00:00:00 2001 From: Geert Uytterhoeven Date: Wed, 14 Jul 2021 11:42:13 +0200 Subject: dt-bindings: phy: Rename Intel Keem Bay USB PHY bindings This is the only file not using the "intel,keembay-*" pattern. Fortunately the actual compatible value is already following the standard scheme. Fixes: 4086afa2a1627939 ("dt-bindings: phy: Add Intel Keem Bay USB PHY bindings") Signed-off-by: Geert Uytterhoeven Acked-by: Rob Herring Link: https://lore.kernel.org/r/91235a64185f7446fc58e638d77691078d3114d1.1626255556.git.geert+renesas@glider.be Signed-off-by: Vinod Koul --- .../bindings/phy/intel,keembay-phy-usb.yaml | 44 ++++++++++++++++++++++ .../bindings/phy/intel,phy-keembay-usb.yaml | 44 ---------------------- 2 files changed, 44 insertions(+), 44 deletions(-) create mode 100644 Documentation/devicetree/bindings/phy/intel,keembay-phy-usb.yaml delete mode 100644 Documentation/devicetree/bindings/phy/intel,phy-keembay-usb.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/phy/intel,keembay-phy-usb.yaml b/Documentation/devicetree/bindings/phy/intel,keembay-phy-usb.yaml new file mode 100644 index 000000000000..52815b6c2b88 --- /dev/null +++ b/Documentation/devicetree/bindings/phy/intel,keembay-phy-usb.yaml @@ -0,0 +1,44 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/phy/intel,keembay-phy-usb.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Intel Keem Bay USB PHY bindings + +maintainers: + - Wan Ahmad Zainie + +properties: + compatible: + const: intel,keembay-usb-phy + + reg: + items: + - description: USB APB CPR (clock, power, reset) register + - description: USB APB slave register + + reg-names: + items: + - const: cpr-apb-base + - const: slv-apb-base + + '#phy-cells': + const: 0 + +required: + - compatible + - reg + - '#phy-cells' + +additionalProperties: false + +examples: + - | + usb-phy@20400000 { + compatible = "intel,keembay-usb-phy"; + reg = <0x20400000 0x1c>, + <0x20480000 0xd0>; + reg-names = "cpr-apb-base", "slv-apb-base"; + #phy-cells = <0>; + }; diff --git a/Documentation/devicetree/bindings/phy/intel,phy-keembay-usb.yaml b/Documentation/devicetree/bindings/phy/intel,phy-keembay-usb.yaml deleted file mode 100644 index a217bb8ac5bc..000000000000 --- a/Documentation/devicetree/bindings/phy/intel,phy-keembay-usb.yaml +++ /dev/null @@ -1,44 +0,0 @@ -# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) -%YAML 1.2 ---- -$id: http://devicetree.org/schemas/phy/intel,phy-keembay-usb.yaml# -$schema: http://devicetree.org/meta-schemas/core.yaml# - -title: Intel Keem Bay USB PHY bindings - -maintainers: - - Wan Ahmad Zainie - -properties: - compatible: - const: intel,keembay-usb-phy - - reg: - items: - - description: USB APB CPR (clock, power, reset) register - - description: USB APB slave register - - reg-names: - items: - - const: cpr-apb-base - - const: slv-apb-base - - '#phy-cells': - const: 0 - -required: - - compatible - - reg - - '#phy-cells' - -additionalProperties: false - -examples: - - | - usb-phy@20400000 { - compatible = "intel,keembay-usb-phy"; - reg = <0x20400000 0x1c>, - <0x20480000 0xd0>; - reg-names = "cpr-apb-base", "slv-apb-base"; - #phy-cells = <0>; - }; -- cgit v1.2.3 From d64519249e1d5520e8420936d662ec2cfb155dfc Mon Sep 17 00:00:00 2001 From: Chanho Park Date: Fri, 9 Jul 2021 18:45:24 +0900 Subject: phy: samsung-ufs: support exynosauto ufs phy driver This patch adds to support phy-exynosautov9-ufs driver for ExynosAuto v9 series SoCs. The patch adds "samsung,exynosautov9-ufs-phy" compatible. Unlike previous exynos ufs phy, the chip uses 0x50 offset as PHY_TRSV_REG_CFG_OFFSET. Signed-off-by: Chanho Park Reviewed-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20210709094524.110193-3-chanho61.park@samsung.com Signed-off-by: Vinod Koul --- Documentation/devicetree/bindings/phy/samsung,ufs-phy.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/phy/samsung,ufs-phy.yaml b/Documentation/devicetree/bindings/phy/samsung,ufs-phy.yaml index 636cc501b54f..f6ed1a005e7a 100644 --- a/Documentation/devicetree/bindings/phy/samsung,ufs-phy.yaml +++ b/Documentation/devicetree/bindings/phy/samsung,ufs-phy.yaml @@ -16,6 +16,7 @@ properties: compatible: enum: - samsung,exynos7-ufs-phy + - samsung,exynosautov9-ufs-phy reg: maxItems: 1 -- cgit v1.2.3 From 4c922fd3d6fa4d51e1f5bb845548cbefd5de3d14 Mon Sep 17 00:00:00 2001 From: ChiYuan Huang Date: Fri, 16 Jul 2021 16:03:55 +0800 Subject: regulator: rtq2134: Add binding document for Richtek RTQ2134 SubPMIC Add binding document for Richtek RTQ2134 SubPMIC. Signed-off-by: ChiYuan Huang Link: https://lore.kernel.org/r/1626422636-29458-1-git-send-email-u0084500@gmail.com Signed-off-by: Mark Brown --- .../regulator/richtek,rtq2134-regulator.yaml | 106 +++++++++++++++++++++ 1 file changed, 106 insertions(+) create mode 100644 Documentation/devicetree/bindings/regulator/richtek,rtq2134-regulator.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/regulator/richtek,rtq2134-regulator.yaml b/Documentation/devicetree/bindings/regulator/richtek,rtq2134-regulator.yaml new file mode 100644 index 000000000000..3f47e8e6c4fd --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/richtek,rtq2134-regulator.yaml @@ -0,0 +1,106 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/regulator/richtek,rtq2134-regulator.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Richtek RTQ2134 SubPMIC Regulator + +maintainers: + - ChiYuan Huang + +description: | + The RTQ2134 is a multi-phase, programmable power management IC that + integrates with four high efficient, synchronous step-down converter cores. + + Datasheet is available at + https://www.richtek.com/assets/product_file/RTQ2134-QA/DSQ2134-QA-01.pdf + +properties: + compatible: + enum: + - richtek,rtq2134 + + reg: + maxItems: 1 + + regulators: + type: object + + patternProperties: + "^buck[1-3]$": + type: object + $ref: regulator.yaml# + description: | + regulator description for buck[1-3]. + + properties: + richtek,use-vsel-dvs: + type: boolean + description: | + If specified, buck will listen to 'vsel' pin for dvs config. + Else, use dvs0 voltage by default. + + richtek,uv-shutdown: + type: boolean + description: | + If specified, use shutdown as UV action. Else, hiccup by default. + + unevaluatedProperties: false + + additionalProperties: false + +required: + - compatible + - reg + - regulators + +additionalProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + rtq2134@18 { + compatible = "richtek,rtq2134"; + reg = <0x18>; + + regulators { + buck1 { + regulator-name = "rtq2134-buck1"; + regulator-min-microvolt = <300000>; + regulator-max-microvolt = <1850000>; + regulator-always-on; + richtek,use-vsel-dvs; + regulator-state-mem { + regulator-suspend-min-microvolt = <550000>; + regulator-suspend-max-microvolt = <550000>; + }; + }; + buck2 { + regulator-name = "rtq2134-buck2"; + regulator-min-microvolt = <1120000>; + regulator-max-microvolt = <1120000>; + regulator-always-on; + richtek,use-vsel-dvs; + regulator-state-mem { + regulator-suspend-min-microvolt = <1120000>; + regulator-suspend-max-microvolt = <1120000>; + }; + }; + buck3 { + regulator-name = "rtq2134-buck3"; + regulator-min-microvolt = <600000>; + regulator-max-microvolt = <600000>; + regulator-always-on; + richtek,use-vsel-dvs; + regulator-state-mem { + regulator-suspend-min-microvolt = <600000>; + regulator-suspend-max-microvolt = <600000>; + }; + }; + }; + }; + }; -- cgit v1.2.3 From a38c02ef48a1411ea3fc4403a07e7124ad43d5e6 Mon Sep 17 00:00:00 2001 From: Fabio Estevam Date: Mon, 19 Jul 2021 20:26:39 -0300 Subject: dt-bindings: net: fec: Fix indentation The following warning is observed when running 'make dtbs_check': Documentation/devicetree/bindings/net/fsl,fec.yaml:85:7: [warning] wrong indentation: expected 8 but found 6 (indentation) Fix the indentation accordingly. Signed-off-by: Fabio Estevam Reviewed-by: Joakim Zhang Signed-off-by: David S. Miller --- Documentation/devicetree/bindings/net/fsl,fec.yaml | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/fsl,fec.yaml b/Documentation/devicetree/bindings/net/fsl,fec.yaml index 7fa11f6622b1..0f8ca4e574c6 100644 --- a/Documentation/devicetree/bindings/net/fsl,fec.yaml +++ b/Documentation/devicetree/bindings/net/fsl,fec.yaml @@ -82,11 +82,11 @@ properties: maxItems: 5 contains: enum: - - ipg - - ahb - - ptp - - enet_clk_ref - - enet_out + - ipg + - ahb + - ptp + - enet_clk_ref + - enet_out phy-mode: true -- cgit v1.2.3 From 6a0eb6c9d9341cb076cd803864fff5889aa3fc03 Mon Sep 17 00:00:00 2001 From: Alex Elder Date: Mon, 19 Jul 2021 16:24:54 -0500 Subject: dt-bindings: net: qcom,ipa: make imem interconnect optional On some newer SoCs, the interconnect between IPA and SoC internal memory (imem) is not used. Reflect this in the binding by moving the definition of the "imem" interconnect to the end and defining minItems to be 2 for both the interconnects and interconnect-names properties. Signed-off-by: Alex Elder Signed-off-by: David S. Miller --- Documentation/devicetree/bindings/net/qcom,ipa.yaml | 18 ++++++++++-------- 1 file changed, 10 insertions(+), 8 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/qcom,ipa.yaml b/Documentation/devicetree/bindings/net/qcom,ipa.yaml index ed88ba4b94df..4853ab7017bd 100644 --- a/Documentation/devicetree/bindings/net/qcom,ipa.yaml +++ b/Documentation/devicetree/bindings/net/qcom,ipa.yaml @@ -87,16 +87,18 @@ properties: - const: ipa-setup-ready interconnects: + minItems: 2 items: - - description: Interconnect path between IPA and main memory - - description: Interconnect path between IPA and internal memory - - description: Interconnect path between IPA and the AP subsystem + - description: Path leading to system memory + - description: Path between the AP and IPA config space + - description: Path leading to internal memory interconnect-names: + minItems: 2 items: - const: memory - - const: imem - const: config + - const: imem qcom,smem-states: $ref: /schemas/types.yaml#/definitions/phandle-array @@ -207,11 +209,11 @@ examples: interconnects = <&rsc_hlos MASTER_IPA &rsc_hlos SLAVE_EBI1>, - <&rsc_hlos MASTER_IPA &rsc_hlos SLAVE_IMEM>, - <&rsc_hlos MASTER_APPSS_PROC &rsc_hlos SLAVE_IPA_CFG>; + <&rsc_hlos MASTER_APPSS_PROC &rsc_hlos SLAVE_IPA_CFG>, + <&rsc_hlos MASTER_IPA &rsc_hlos SLAVE_IMEM>; interconnect-names = "memory", - "imem", - "config"; + "config", + "imem"; qcom,smem-states = <&ipa_smp2p_out 0>, <&ipa_smp2p_out 1>; -- cgit v1.2.3 From e3879ecd366a8ccc0ad7e36bf62692c16db360a1 Mon Sep 17 00:00:00 2001 From: Akira Yokosawa Date: Thu, 20 May 2021 13:32:36 +0900 Subject: Documentation/RCU: Fix emphasis markers "-foo-" does not work as emphasis in ReST markdown. Use "*foo*" instead. Signed-off-by: Akira Yokosawa Signed-off-by: Paul E. McKenney --- Documentation/RCU/checklist.rst | 24 ++++++++++++------------ Documentation/RCU/rcu_dereference.rst | 6 +++--- Documentation/RCU/stallwarn.rst | 8 ++++---- 3 files changed, 19 insertions(+), 19 deletions(-) (limited to 'Documentation') diff --git a/Documentation/RCU/checklist.rst b/Documentation/RCU/checklist.rst index 01cc21f17f7b..f4545b7c9a63 100644 --- a/Documentation/RCU/checklist.rst +++ b/Documentation/RCU/checklist.rst @@ -37,7 +37,7 @@ over a rather long period of time, but improvements are always welcome! 1. Does the update code have proper mutual exclusion? - RCU does allow -readers- to run (almost) naked, but -writers- must + RCU does allow *readers* to run (almost) naked, but *writers* must still use some sort of mutual exclusion, such as: a. locking, @@ -73,7 +73,7 @@ over a rather long period of time, but improvements are always welcome! critical section is every bit as bad as letting them leak out from under a lock. Unless, of course, you have arranged some other means of protection, such as a lock or a reference count - -before- letting them out of the RCU read-side critical section. + *before* letting them out of the RCU read-side critical section. 3. Does the update code tolerate concurrent accesses? @@ -101,7 +101,7 @@ over a rather long period of time, but improvements are always welcome! c. Make updates appear atomic to readers. For example, pointer updates to properly aligned fields will appear atomic, as will individual atomic primitives. - Sequences of operations performed under a lock will -not- + Sequences of operations performed under a lock will *not* appear to be atomic to RCU readers, nor will sequences of multiple atomic primitives. @@ -333,7 +333,7 @@ over a rather long period of time, but improvements are always welcome! for example) may be omitted. 10. Conversely, if you are in an RCU read-side critical section, - and you don't hold the appropriate update-side lock, you -must- + and you don't hold the appropriate update-side lock, you *must* use the "_rcu()" variants of the list macros. Failing to do so will break Alpha, cause aggressive compilers to generate bad code, and confuse people trying to read your code. @@ -359,12 +359,12 @@ over a rather long period of time, but improvements are always welcome! callback pending, then that RCU callback will execute on some surviving CPU. (If this was not the case, a self-spawning RCU callback would prevent the victim CPU from ever going offline.) - Furthermore, CPUs designated by rcu_nocbs= might well -always- + Furthermore, CPUs designated by rcu_nocbs= might well *always* have their RCU callbacks executed on some other CPUs, in fact, for some real-time workloads, this is the whole point of using the rcu_nocbs= kernel boot parameter. -13. Unlike other forms of RCU, it -is- permissible to block in an +13. Unlike other forms of RCU, it *is* permissible to block in an SRCU read-side critical section (demarked by srcu_read_lock() and srcu_read_unlock()), hence the "SRCU": "sleepable RCU". Please note that if you don't need to sleep in read-side critical @@ -411,16 +411,16 @@ over a rather long period of time, but improvements are always welcome! 14. The whole point of call_rcu(), synchronize_rcu(), and friends is to wait until all pre-existing readers have finished before carrying out some otherwise-destructive operation. It is - therefore critically important to -first- remove any path + therefore critically important to *first* remove any path that readers can follow that could be affected by the - destructive operation, and -only- -then- invoke call_rcu(), + destructive operation, and *only then* invoke call_rcu(), synchronize_rcu(), or friends. Because these primitives only wait for pre-existing readers, it is the caller's responsibility to guarantee that any subsequent readers will execute safely. -15. The various RCU read-side primitives do -not- necessarily contain +15. The various RCU read-side primitives do *not* necessarily contain memory barriers. You should therefore plan for the CPU and the compiler to freely reorder code into and out of RCU read-side critical sections. It is the responsibility of the @@ -459,8 +459,8 @@ over a rather long period of time, but improvements are always welcome! pass in a function defined within a loadable module, then it in necessary to wait for all pending callbacks to be invoked after the last invocation and before unloading that module. Note that - it is absolutely -not- sufficient to wait for a grace period! - The current (say) synchronize_rcu() implementation is -not- + it is absolutely *not* sufficient to wait for a grace period! + The current (say) synchronize_rcu() implementation is *not* guaranteed to wait for callbacks registered on other CPUs. Or even on the current CPU if that CPU recently went offline and came back online. @@ -470,7 +470,7 @@ over a rather long period of time, but improvements are always welcome! - call_rcu() -> rcu_barrier() - call_srcu() -> srcu_barrier() - However, these barrier functions are absolutely -not- guaranteed + However, these barrier functions are absolutely *not* guaranteed to wait for a grace period. In fact, if there are no call_rcu() callbacks waiting anywhere in the system, rcu_barrier() is within its rights to return immediately. diff --git a/Documentation/RCU/rcu_dereference.rst b/Documentation/RCU/rcu_dereference.rst index f3e587acb4de..0b418a5b243c 100644 --- a/Documentation/RCU/rcu_dereference.rst +++ b/Documentation/RCU/rcu_dereference.rst @@ -43,7 +43,7 @@ Follow these rules to keep your RCU code working properly: - Set bits and clear bits down in the must-be-zero low-order bits of that pointer. This clearly means that the pointer must have alignment constraints, for example, this does - -not- work in general for char* pointers. + *not* work in general for char* pointers. - XOR bits to translate pointers, as is done in some classic buddy-allocator algorithms. @@ -174,7 +174,7 @@ Follow these rules to keep your RCU code working properly: Please see the "CONTROL DEPENDENCIES" section of Documentation/memory-barriers.txt for more details. - - The pointers are not equal -and- the compiler does + - The pointers are not equal *and* the compiler does not have enough information to deduce the value of the pointer. Note that the volatile cast in rcu_dereference() will normally prevent the compiler from knowing too much. @@ -360,7 +360,7 @@ in turn destroying the ordering between this load and the loads of the return values. This can result in "p->b" returning pre-initialization garbage values. -In short, rcu_dereference() is -not- optional when you are going to +In short, rcu_dereference() is *not* optional when you are going to dereference the resulting pointer. diff --git a/Documentation/RCU/stallwarn.rst b/Documentation/RCU/stallwarn.rst index 7148e9be08c3..1cc944aec46f 100644 --- a/Documentation/RCU/stallwarn.rst +++ b/Documentation/RCU/stallwarn.rst @@ -32,7 +32,7 @@ warnings: - Booting Linux using a console connection that is too slow to keep up with the boot-time console-message rate. For example, - a 115Kbaud serial console can be -way- too slow to keep up + a 115Kbaud serial console can be *way* too slow to keep up with boot-time message rates, and will frequently result in RCU CPU stall warning messages. Especially if you have added debug printk()s. @@ -105,7 +105,7 @@ warnings: leading the realization that the CPU had failed. The RCU, RCU-sched, and RCU-tasks implementations have CPU stall warning. -Note that SRCU does -not- have CPU stall warnings. Please note that +Note that SRCU does *not* have CPU stall warnings. Please note that RCU only detects CPU stalls when there is a grace period in progress. No grace period, no CPU stall warnings. @@ -145,7 +145,7 @@ CONFIG_RCU_CPU_STALL_TIMEOUT this parameter is checked only at the beginning of a cycle. So if you are 10 seconds into a 40-second stall, setting this sysfs parameter to (say) five will shorten the timeout for the - -next- stall, or the following warning for the current stall + *next* stall, or the following warning for the current stall (assuming the stall lasts long enough). It will not affect the timing of the next warning for the current stall. @@ -202,7 +202,7 @@ 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 an rcu_state stall to be caused by both CPUs -and- tasks, +possible for an rcu_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. CPU 2's "(3 GPs behind)" indicates that this CPU has not interacted with -- cgit v1.2.3 From 4966090849e96f4db1e115b77d2cfb68c2f73264 Mon Sep 17 00:00:00 2001 From: Akira Yokosawa Date: Fri, 21 May 2021 11:16:04 +0900 Subject: Documentation/RCU: Fix nested inline markup To avoid the ``foo`` markup inside the `bar`__ hyperlink marker, use the "replace" directive [1]. This should restore the intended appearance of the link. Tested with sphinx versions 1.7.9 and 2.4.4. [1]: https://docutils.sourceforge.io/docs/ref/rst/directives.html#replace Signed-off-by: Akira Yokosawa Signed-off-by: Paul E. McKenney --- Documentation/RCU/Design/Requirements/Requirements.rst | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/RCU/Design/Requirements/Requirements.rst b/Documentation/RCU/Design/Requirements/Requirements.rst index 38a39476fc24..45278e2974c0 100644 --- a/Documentation/RCU/Design/Requirements/Requirements.rst +++ b/Documentation/RCU/Design/Requirements/Requirements.rst @@ -362,9 +362,8 @@ do_something_gp() uses rcu_dereference() to fetch from ``gp``: 12 } The rcu_dereference() uses volatile casts and (for DEC Alpha) memory -barriers in the Linux kernel. Should a `high-quality implementation of -C11 ``memory_order_consume`` -[PDF] `__ +barriers in the Linux kernel. Should a |high-quality implementation of +C11 memory_order_consume [PDF]|_ ever appear, then rcu_dereference() could be implemented as a ``memory_order_consume`` load. Regardless of the exact implementation, a pointer fetched by rcu_dereference() may not be used outside of the @@ -374,6 +373,9 @@ element has been passed from RCU to some other synchronization mechanism, most commonly locking or `reference counting `__. +.. |high-quality implementation of C11 memory_order_consume [PDF]| replace:: high-quality implementation of C11 ``memory_order_consume`` [PDF] +.. _high-quality implementation of C11 memory_order_consume [PDF]: http://www.rdrop.com/users/paulmck/RCU/consume.2015.07.13a.pdf + In short, updaters use rcu_assign_pointer() and readers use rcu_dereference(), and these two RCU API elements work together to ensure that readers have a consistent view of newly added data elements. -- cgit v1.2.3 From 9984fd7e5e2f16cf867dba43ab9a4d123b91d3d3 Mon Sep 17 00:00:00 2001 From: Haocheng Xie Date: Tue, 25 May 2021 17:31:52 +0800 Subject: docs: Fix a typo in Documentation/RCU/stallwarn.rst Add the missing ')' in the documentation. Signed-off-by: Haocheng Xie Signed-off-by: Paul E. McKenney --- Documentation/RCU/stallwarn.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/RCU/stallwarn.rst b/Documentation/RCU/stallwarn.rst index 1cc944aec46f..f1c49c626e93 100644 --- a/Documentation/RCU/stallwarn.rst +++ b/Documentation/RCU/stallwarn.rst @@ -224,7 +224,7 @@ is the number that had executed since boot at the time that this CPU last noted the beginning of a grace period, which might be the current (stalled) grace period, or it might be some earlier grace period (for example, if the CPU might have been in dyntick-idle mode for an extended -time period. The number after the "/" is the number that have executed +time period). The number after the "/" is the number that have executed since boot until the current time. If this latter number stays constant across repeated stall-warning messages, it is possible that RCU's softirq handlers are no longer able to execute on this CPU. This can happen if -- cgit v1.2.3 From c28adacc14e70e3260063e97ebb8dd984e6f7a07 Mon Sep 17 00:00:00 2001 From: Frederic Weisbecker Date: Thu, 10 Jun 2021 17:50:29 +0200 Subject: rcu/doc: Add a quick quiz to explain further why we need smp_mb__after_unlock_lock() Add some missing critical pieces of explanation to understand the need for full memory barriers throughout the whole grace period state machine, thanks to Paul's explanations. Signed-off-by: Frederic Weisbecker Cc: Neeraj Upadhyay Cc: Joel Fernandes Cc: Uladzislau Rezki Cc: Boqun Feng [ paulmck: Adjust code block per Akira Yokosawa. ] Signed-off-by: Paul E. McKenney --- .../Memory-Ordering/Tree-RCU-Memory-Ordering.rst | 29 ++++++++++++++++++++++ 1 file changed, 29 insertions(+) (limited to 'Documentation') diff --git a/Documentation/RCU/Design/Memory-Ordering/Tree-RCU-Memory-Ordering.rst b/Documentation/RCU/Design/Memory-Ordering/Tree-RCU-Memory-Ordering.rst index 11cdab037bff..eeb351296df1 100644 --- a/Documentation/RCU/Design/Memory-Ordering/Tree-RCU-Memory-Ordering.rst +++ b/Documentation/RCU/Design/Memory-Ordering/Tree-RCU-Memory-Ordering.rst @@ -112,6 +112,35 @@ on PowerPC. The ``smp_mb__after_unlock_lock()`` invocations prevent this ``WARN_ON()`` from triggering. ++-----------------------------------------------------------------------+ +| **Quick Quiz**: | ++-----------------------------------------------------------------------+ +| But the chain of rcu_node-structure lock acquisitions guarantees | +| that new readers will see all of the updater's pre-grace-period | +| accesses and also guarantees that the updater's post-grace-period | +| accesses will see all of the old reader's accesses. So why do we | +| need all of those calls to smp_mb__after_unlock_lock()? | ++-----------------------------------------------------------------------+ +| **Answer**: | ++-----------------------------------------------------------------------+ +| Because we must provide ordering for RCU's polling grace-period | +| primitives, for example, get_state_synchronize_rcu() and | +| poll_state_synchronize_rcu(). Consider this code:: | +| | +| CPU 0 CPU 1 | +| ---- ---- | +| WRITE_ONCE(X, 1) WRITE_ONCE(Y, 1) | +| g = get_state_synchronize_rcu() smp_mb() | +| while (!poll_state_synchronize_rcu(g)) r1 = READ_ONCE(X) | +| continue; | +| r0 = READ_ONCE(Y) | +| | +| RCU guarantees that the outcome r0 == 0 && r1 == 0 will not | +| happen, even if CPU 1 is in an RCU extended quiescent state | +| (idle or offline) and thus won't interact directly with the RCU | +| core processing at all. | ++-----------------------------------------------------------------------+ + 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 -- cgit v1.2.3 From 99c0974ffeeab111bc709fc77b6900593e2e9078 Mon Sep 17 00:00:00 2001 From: "Paul E. McKenney" Date: Wed, 14 Jul 2021 11:46:55 -0700 Subject: doc: Update stallwarn.rst with recent changes This commit calls out the possibility of self-detected stalls, adds new messages, and calls out the use for stack traces. Reported-by: Jeff Layton Signed-off-by: Paul E. McKenney --- Documentation/RCU/stallwarn.rst | 21 +++++++++++++++------ 1 file changed, 15 insertions(+), 6 deletions(-) (limited to 'Documentation') diff --git a/Documentation/RCU/stallwarn.rst b/Documentation/RCU/stallwarn.rst index f1c49c626e93..5036df24ae61 100644 --- a/Documentation/RCU/stallwarn.rst +++ b/Documentation/RCU/stallwarn.rst @@ -189,8 +189,8 @@ rcupdate.rcu_task_stall_timeout 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:: +For non-RCU-tasks flavors of RCU, when a CPU detects that some other +CPU is stalling, it will print a message similar to the following:: INFO: rcu_sched detected stalls on CPUs/tasks: 2-...: (3 GPs behind) idle=06c/0/0 softirq=1453/1455 fqs=0 @@ -204,6 +204,8 @@ 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 an rcu_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. +In some cases, CPUs will detect themselves stalling, which will result +in a self-detected stall. 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 @@ -283,7 +285,8 @@ If the relevant grace-period kthread has been unable to run prior to the stall warning, as was the case in the "All QSes seen" line above, the following additional line is printed:: - kthread starved for 23807 jiffies! g7075 f0x0 RCU_GP_WAIT_FQS(3) ->state=0x1 ->cpu=5 + rcu_sched kthread starved for 23807 jiffies! g7075 f0x0 RCU_GP_WAIT_FQS(3) ->state=0x1 ->cpu=5 + Unless rcu_sched kthread gets sufficient CPU time, OOM is now expected behavior. 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 @@ -313,15 +316,21 @@ is the current ``TIMER_SOFTIRQ`` count on cpu 4. If this value does not change on successive RCU CPU stall warnings, there is further reason to suspect a timer problem. +These messages are usually followed by stack dumps of the CPUs and tasks +involved in the stall. These stack traces can help you locate the cause +of the stall, keeping in mind that the CPU detecting the stall will have +an interrupt frame that is mainly devoted to detecting the stall. + Multiple Warnings From One Stall ================================ -If a stall lasts long enough, multiple stall-warning messages will be -printed for it. The second and subsequent messages are printed at +If a stall lasts long enough, multiple stall-warning messages will +be printed for it. The second and subsequent messages are printed at longer intervals, so that the time between (say) the first and second message will be about three times the interval between the beginning -of the stall and the first message. +of the stall and the first message. It can be helpful to compare the +stack dumps for the different messages for the same stalled grace period. Stall Warnings for Expedited Grace Periods -- cgit v1.2.3 From ced3aaead0ba4c1b11eec51adc51465fa56aa5da Mon Sep 17 00:00:00 2001 From: Taniya Das Date: Tue, 13 Jul 2021 20:42:18 +0530 Subject: dt-bindings: clock: Add SC7280 DISPCC clock binding Add device tree bindings for display clock controller subsystem for Qualcomm Technology Inc's SC7280 SoCs. Signed-off-by: Taniya Das Link: https://lore.kernel.org/r/1626189143-12957-3-git-send-email-tdas@codeaurora.org Reviewed-by: Rob Herring Signed-off-by: Stephen Boyd --- .../bindings/clock/qcom,sc7280-dispcc.yaml | 94 ++++++++++++++++++++++ 1 file changed, 94 insertions(+) create mode 100644 Documentation/devicetree/bindings/clock/qcom,sc7280-dispcc.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/qcom,sc7280-dispcc.yaml b/Documentation/devicetree/bindings/clock/qcom,sc7280-dispcc.yaml new file mode 100644 index 000000000000..2178666fb697 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/qcom,sc7280-dispcc.yaml @@ -0,0 +1,94 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/qcom,sc7280-dispcc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Display Clock & Reset Controller Binding for SC7280 + +maintainers: + - Taniya Das + +description: | + Qualcomm display clock control module which supports the clocks, resets and + power domains on SC7280. + + See also dt-bindings/clock/qcom,dispcc-sc7280.h. + +properties: + compatible: + const: qcom,sc7280-dispcc + + clocks: + items: + - description: Board XO source + - description: GPLL0 source from GCC + - description: Byte clock from DSI PHY + - description: Pixel clock from DSI PHY + - description: Link clock from DP PHY + - description: VCO DIV clock from DP PHY + - description: Link clock from EDP PHY + - description: VCO DIV clock from EDP PHY + + clock-names: + items: + - const: bi_tcxo + - const: gcc_disp_gpll0_clk + - const: dsi0_phy_pll_out_byteclk + - const: dsi0_phy_pll_out_dsiclk + - const: dp_phy_pll_link_clk + - const: dp_phy_pll_vco_div_clk + - const: edp_phy_pll_link_clk + - const: edp_phy_pll_vco_div_clk + + '#clock-cells': + const: 1 + + '#reset-cells': + const: 1 + + '#power-domain-cells': + const: 1 + + reg: + maxItems: 1 + +required: + - compatible + - reg + - clocks + - clock-names + - '#clock-cells' + - '#reset-cells' + - '#power-domain-cells' + +additionalProperties: false + +examples: + - | + #include + #include + clock-controller@af00000 { + compatible = "qcom,sc7280-dispcc"; + reg = <0x0af00000 0x200000>; + clocks = <&rpmhcc RPMH_CXO_CLK>, + <&gcc GCC_DISP_GPLL0_CLK_SRC>, + <&dsi_phy 0>, + <&dsi_phy 1>, + <&dp_phy 0>, + <&dp_phy 1>, + <&edp_phy 0>, + <&edp_phy 1>; + clock-names = "bi_tcxo", + "gcc_disp_gpll0_clk", + "dsi0_phy_pll_out_byteclk", + "dsi0_phy_pll_out_dsiclk", + "dp_phy_pll_link_clk", + "dp_phy_pll_vco_div_clk", + "edp_phy_pll_link_clk", + "edp_phy_pll_vco_div_clk"; + #clock-cells = <1>; + #reset-cells = <1>; + #power-domain-cells = <1>; + }; +... -- cgit v1.2.3 From 6f1a1ced9ee616fe1e5bdebcfe060d0f03a89336 Mon Sep 17 00:00:00 2001 From: Taniya Das Date: Tue, 13 Jul 2021 20:42:20 +0530 Subject: dt-bindings: clock: Add SC7280 GPUCC clock binding Add device tree bindings for graphics clock subsystem clock controller for Qualcomm Technology Inc's SC7280 SoCs. Signed-off-by: Taniya Das Link: https://lore.kernel.org/r/1626189143-12957-5-git-send-email-tdas@codeaurora.org Reviewed-by: Rob Herring Signed-off-by: Stephen Boyd --- Documentation/devicetree/bindings/clock/qcom,gpucc.yaml | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/qcom,gpucc.yaml b/Documentation/devicetree/bindings/clock/qcom,gpucc.yaml index df943c4c3234..ecfe21284073 100644 --- a/Documentation/devicetree/bindings/clock/qcom,gpucc.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,gpucc.yaml @@ -1,4 +1,4 @@ -# SPDX-License-Identifier: GPL-2.0-only +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2 --- $id: http://devicetree.org/schemas/clock/qcom,gpucc.yaml# @@ -11,11 +11,12 @@ maintainers: description: | Qualcomm graphics clock control module which supports the clocks, resets and - power domains on SDM845/SC7180/SM8150/SM8250. + power domains on Qualcomm SoCs. See also: dt-bindings/clock/qcom,gpucc-sdm845.h dt-bindings/clock/qcom,gpucc-sc7180.h + dt-bindings/clock/qcom,gpucc-sc7280.h dt-bindings/clock/qcom,gpucc-sm8150.h dt-bindings/clock/qcom,gpucc-sm8250.h @@ -24,6 +25,7 @@ properties: enum: - qcom,sdm845-gpucc - qcom,sc7180-gpucc + - qcom,sc7280-gpucc - qcom,sm8150-gpucc - qcom,sm8250-gpucc -- cgit v1.2.3 From f1f5a30385631d528ee2d121a456931f7279139d Mon Sep 17 00:00:00 2001 From: Taniya Das Date: Tue, 13 Jul 2021 20:42:22 +0530 Subject: dt-bindings: clock: Add SC7280 VideoCC clock binding Add device tree bindings for video clock subsystem clock controller for Qualcomm Technology Inc's SC7280 SoCs. Signed-off-by: Taniya Das Link: https://lore.kernel.org/r/1626189143-12957-7-git-send-email-tdas@codeaurora.org Reviewed-by: Rob Herring Signed-off-by: Stephen Boyd --- Documentation/devicetree/bindings/clock/qcom,videocc.yaml | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/qcom,videocc.yaml b/Documentation/devicetree/bindings/clock/qcom,videocc.yaml index 567202942b88..0d224f114b5b 100644 --- a/Documentation/devicetree/bindings/clock/qcom,videocc.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,videocc.yaml @@ -1,4 +1,4 @@ -# SPDX-License-Identifier: GPL-2.0-only +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2 --- $id: http://devicetree.org/schemas/clock/qcom,videocc.yaml# @@ -11,10 +11,11 @@ maintainers: description: | Qualcomm video clock control module which supports the clocks, resets and - power domains on SDM845/SC7180/SM8150/SM8250. + power domains on Qualcomm SoCs. See also: dt-bindings/clock/qcom,videocc-sc7180.h + dt-bindings/clock/qcom,videocc-sc7280.h dt-bindings/clock/qcom,videocc-sdm845.h dt-bindings/clock/qcom,videocc-sm8150.h dt-bindings/clock/qcom,videocc-sm8250.h @@ -23,6 +24,7 @@ properties: compatible: enum: - qcom,sc7180-videocc + - qcom,sc7280-videocc - qcom,sdm845-videocc - qcom,sm8150-videocc - qcom,sm8250-videocc -- cgit v1.2.3 From e675d2533a74acfa95c62e7bb088335866f44fd2 Mon Sep 17 00:00:00 2001 From: Marco Elver Date: Mon, 7 Jun 2021 14:56:49 +0200 Subject: kcsan: Introduce CONFIG_KCSAN_STRICT Add a simpler Kconfig variable to configure KCSAN's "strict" mode. This makes it simpler in documentation or messages to suggest just a single configuration option to select the strictest checking mode (vs. currently having to list several options). Signed-off-by: Marco Elver Acked-by: Mark Rutland Signed-off-by: Paul E. McKenney --- Documentation/dev-tools/kcsan.rst | 4 ++++ 1 file changed, 4 insertions(+) (limited to 'Documentation') diff --git a/Documentation/dev-tools/kcsan.rst b/Documentation/dev-tools/kcsan.rst index 6a600cf8430b..69dc9c502ccc 100644 --- a/Documentation/dev-tools/kcsan.rst +++ b/Documentation/dev-tools/kcsan.rst @@ -127,6 +127,10 @@ Kconfig options: causes KCSAN to not report data races due to conflicts where the only plain accesses are aligned writes up to word size. +To use the strictest possible rules, select ``CONFIG_KCSAN_STRICT=y``, which +configures KCSAN to follow the Linux-kernel memory consistency model (LKMM) as +closely as possible. + DebugFS interface ~~~~~~~~~~~~~~~~~ -- cgit v1.2.3 From 49f72d5358dd3c0d28bcd2232c513000b15480f0 Mon Sep 17 00:00:00 2001 From: Marco Elver Date: Mon, 7 Jun 2021 14:56:51 +0200 Subject: kcsan: Rework atomic.h into permissive.h Rework atomic.h into permissive.h to better reflect its purpose, and introduce kcsan_ignore_address() and kcsan_ignore_data_race(). Introduce CONFIG_KCSAN_PERMISSIVE and update the stub functions in preparation for subsequent changes. As before, developers who choose to use KCSAN in "strict" mode will see all data races and are not affected. Furthermore, by relying on the value-change filter logic for kcsan_ignore_data_race(), even if the permissive rules are enabled, the opt-outs in report.c:skip_report() override them (such as for RCU-related functions by default). The option CONFIG_KCSAN_PERMISSIVE is disabled by default, so that the documented default behaviour of KCSAN does not change. Instead, like CONFIG_KCSAN_IGNORE_ATOMICS, the option needs to be explicitly opted in. Signed-off-by: Marco Elver Acked-by: Mark Rutland Signed-off-by: Paul E. McKenney --- Documentation/dev-tools/kcsan.rst | 8 ++++++++ 1 file changed, 8 insertions(+) (limited to 'Documentation') diff --git a/Documentation/dev-tools/kcsan.rst b/Documentation/dev-tools/kcsan.rst index 69dc9c502ccc..7db43c7c09b8 100644 --- a/Documentation/dev-tools/kcsan.rst +++ b/Documentation/dev-tools/kcsan.rst @@ -127,6 +127,14 @@ Kconfig options: causes KCSAN to not report data races due to conflicts where the only plain accesses are aligned writes up to word size. +* ``CONFIG_KCSAN_PERMISSIVE``: Enable additional permissive rules to ignore + certain classes of common data races. Unlike the above, the rules are more + complex involving value-change patterns, access type, and address. This + option depends on ``CONFIG_KCSAN_REPORT_VALUE_CHANGE_ONLY=y``. For details + please see the ``kernel/kcsan/permissive.h``. Testers and maintainers that + only focus on reports from specific subsystems and not the whole kernel are + recommended to disable this option. + To use the strictest possible rules, select ``CONFIG_KCSAN_STRICT=y``, which configures KCSAN to follow the Linux-kernel memory consistency model (LKMM) as closely as possible. -- cgit v1.2.3 From bc71d3ef59b95cae509a1fc3da3162065be0b256 Mon Sep 17 00:00:00 2001 From: Joakim Zhang Date: Mon, 19 Jul 2021 15:18:19 +0800 Subject: dt-bindings: net: snps,dwmac: add missing DWMAC IP version Add missing DWMAC IP version in snps,dwmac.yaml which found by below command, as NXP i.MX8 families support SNPS DWMAC 5.10a IP. $ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- dt_binding_check DT_SCHEMA_FILES=Documentation/devicetree/bindings/net/nxp,dwmac-imx.yaml Documentation/devicetree/bindings/net/nxp,dwmac-imx.example.dt.yaml: ethernet@30bf0000: compatible: None of ['nxp,imx8mp-dwmac-eqos', 'snps,dwmac-5.10a'] are valid under the given schema Signed-off-by: Joakim Zhang Signed-off-by: David S. Miller --- Documentation/devicetree/bindings/net/snps,dwmac.yaml | 3 +++ 1 file changed, 3 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/snps,dwmac.yaml b/Documentation/devicetree/bindings/net/snps,dwmac.yaml index d7652596a09b..42689b7d03a2 100644 --- a/Documentation/devicetree/bindings/net/snps,dwmac.yaml +++ b/Documentation/devicetree/bindings/net/snps,dwmac.yaml @@ -28,6 +28,7 @@ select: - snps,dwmac-4.00 - snps,dwmac-4.10a - snps,dwmac-4.20a + - snps,dwmac-5.10a - snps,dwxgmac - snps,dwxgmac-2.10 @@ -82,6 +83,7 @@ properties: - snps,dwmac-4.00 - snps,dwmac-4.10a - snps,dwmac-4.20a + - snps,dwmac-5.10a - snps,dwxgmac - snps,dwxgmac-2.10 @@ -375,6 +377,7 @@ allOf: - snps,dwmac-4.00 - snps,dwmac-4.10a - snps,dwmac-4.20a + - snps,dwmac-5.10a - snps,dwxgmac - snps,dwxgmac-2.10 - st,spear600-gmac -- cgit v1.2.3 From 03e85b17030a6516fb76d853d6c74f0181c03180 Mon Sep 17 00:00:00 2001 From: Joakim Zhang Date: Mon, 19 Jul 2021 15:18:20 +0800 Subject: dt-bindings: net: imx-dwmac: convert imx-dwmac bindings to yaml In order to automate the verification of DT nodes covert imx-dwmac to nxp,dwmac-imx.yaml, and pass below checking. $ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- dt_binding_check DT_SCHEMA_FILES=Documentation/devicetree/bindings/net/nxp,dwmac-imx.yaml $ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- dtbs_check DT_SCHEMA_FILES=Documentation/devicetree/bindings/net/nxp,dwmac-imx.yaml Signed-off-by: Joakim Zhang Signed-off-by: David S. Miller --- .../devicetree/bindings/net/imx-dwmac.txt | 56 ------------- .../devicetree/bindings/net/nxp,dwmac-imx.yaml | 93 ++++++++++++++++++++++ 2 files changed, 93 insertions(+), 56 deletions(-) delete mode 100644 Documentation/devicetree/bindings/net/imx-dwmac.txt create mode 100644 Documentation/devicetree/bindings/net/nxp,dwmac-imx.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/imx-dwmac.txt b/Documentation/devicetree/bindings/net/imx-dwmac.txt deleted file mode 100644 index 921d522fe8d7..000000000000 --- a/Documentation/devicetree/bindings/net/imx-dwmac.txt +++ /dev/null @@ -1,56 +0,0 @@ -IMX8 glue layer controller, NXP imx8 families support Synopsys MAC 5.10a IP. - -This file documents platform glue layer for IMX. -Please see stmmac.txt for the other unchanged properties. - -The device node has following properties. - -Required properties: -- compatible: Should be "nxp,imx8mp-dwmac-eqos" to select glue layer - and "snps,dwmac-5.10a" to select IP version. -- clocks: Must contain a phandle for each entry in clock-names. -- clock-names: Should be "stmmaceth" for the host clock. - Should be "pclk" for the MAC apb clock. - Should be "ptp_ref" for the MAC timer clock. - Should be "tx" for the MAC RGMII TX clock: - Should be "mem" for EQOS MEM clock. - - "mem" clock is required for imx8dxl platform. - - "mem" clock is not required for imx8mp platform. -- interrupt-names: Should contain a list of interrupt names corresponding to - the interrupts in the interrupts property, if available. - Should be "macirq" for the main MAC IRQ - Should be "eth_wake_irq" for the IT which wake up system -- intf_mode: Should be phandle/offset pair. The phandle to the syscon node which - encompases the GPR register, and the offset of the GPR register. - - required for imx8mp platform. - - is optional for imx8dxl platform. - -Optional properties: -- intf_mode: is optional for imx8dxl platform. -- snps,rmii_refclk_ext: to select RMII reference clock from external. - -Example: - eqos: ethernet@30bf0000 { - compatible = "nxp,imx8mp-dwmac-eqos", "snps,dwmac-5.10a"; - reg = <0x30bf0000 0x10000>; - interrupts = , - ; - interrupt-names = "eth_wake_irq", "macirq"; - clocks = <&clk IMX8MP_CLK_ENET_QOS_ROOT>, - <&clk IMX8MP_CLK_QOS_ENET_ROOT>, - <&clk IMX8MP_CLK_ENET_QOS_TIMER>, - <&clk IMX8MP_CLK_ENET_QOS>; - clock-names = "stmmaceth", "pclk", "ptp_ref", "tx"; - assigned-clocks = <&clk IMX8MP_CLK_ENET_AXI>, - <&clk IMX8MP_CLK_ENET_QOS_TIMER>, - <&clk IMX8MP_CLK_ENET_QOS>; - assigned-clock-parents = <&clk IMX8MP_SYS_PLL1_266M>, - <&clk IMX8MP_SYS_PLL2_100M>, - <&clk IMX8MP_SYS_PLL2_125M>; - assigned-clock-rates = <0>, <100000000>, <125000000>; - nvmem-cells = <ð_mac0>; - nvmem-cell-names = "mac-address"; - nvmem_macaddr_swap; - intf_mode = <&gpr 0x4>; - status = "disabled"; - }; diff --git a/Documentation/devicetree/bindings/net/nxp,dwmac-imx.yaml b/Documentation/devicetree/bindings/net/nxp,dwmac-imx.yaml new file mode 100644 index 000000000000..5629b2e4ccf8 --- /dev/null +++ b/Documentation/devicetree/bindings/net/nxp,dwmac-imx.yaml @@ -0,0 +1,93 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/nxp,dwmac-imx.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NXP i.MX8 DWMAC glue layer Device Tree Bindings + +maintainers: + - Joakim Zhang + +# We need a select here so we don't match all nodes with 'snps,dwmac' +select: + properties: + compatible: + contains: + enum: + - nxp,imx8mp-dwmac-eqos + - nxp,imx8dxl-dwmac-eqos + required: + - compatible + +allOf: + - $ref: "snps,dwmac.yaml#" + +properties: + compatible: + oneOf: + - items: + - enum: + - nxp,imx8mp-dwmac-eqos + - nxp,imx8dxl-dwmac-eqos + - const: snps,dwmac-5.10a + + clocks: + minItems: 3 + maxItems: 5 + items: + - description: MAC host clock + - description: MAC apb clock + - description: MAC timer clock + - description: MAC RGMII TX clock + - description: EQOS MEM clock + + clock-names: + minItems: 3 + maxItems: 5 + contains: + enum: + - stmmaceth + - pclk + - ptp_ref + - tx + - mem + + intf_mode: + $ref: /schemas/types.yaml#/definitions/phandle-array + description: + Should be phandle/offset pair. The phandle to the syscon node which + encompases the GPR register, and the offset of the GPR register. + + snps,rmii_refclk_ext: + $ref: /schemas/types.yaml#/definitions/flag + description: + To select RMII reference clock from external. + +required: + - compatible + - clocks + - clock-names + +unevaluatedProperties: false + +examples: + - | + #include + #include + #include + + eqos: ethernet@30bf0000 { + compatible = "nxp,imx8mp-dwmac-eqos","snps,dwmac-5.10a"; + reg = <0x30bf0000 0x10000>; + interrupts = , + ; + interrupt-names = "macirq", "eth_wake_irq"; + clocks = <&clk IMX8MP_CLK_ENET_QOS_ROOT>, + <&clk IMX8MP_CLK_QOS_ENET_ROOT>, + <&clk IMX8MP_CLK_ENET_QOS_TIMER>, + <&clk IMX8MP_CLK_ENET_QOS>; + clock-names = "stmmaceth", "pclk", "ptp_ref", "tx"; + phy-mode = "rgmii"; + status = "disabled"; + }; -- cgit v1.2.3 From e516ac5d48fe800b9526e1bb144671f9da9b0a47 Mon Sep 17 00:00:00 2001 From: Sandeep Maheswaram Date: Tue, 6 Jul 2021 18:30:11 +0530 Subject: dt-bindings: phy: qcom,qmp-usb3-dp: Add support for SC7280 Add compatible for SC7280 in QMP USB3 DP PHY bindings. Reviewed-by: Stephen Boyd Acked-by: Rob Herring Signed-off-by: Sandeep Maheswaram Link: https://lore.kernel.org/r/1625576413-12324-2-git-send-email-sanm@codeaurora.org Signed-off-by: Greg Kroah-Hartman --- Documentation/devicetree/bindings/phy/qcom,qmp-usb3-dp-phy.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/phy/qcom,qmp-usb3-dp-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,qmp-usb3-dp-phy.yaml index 217aa6c91893..20199833f144 100644 --- a/Documentation/devicetree/bindings/phy/qcom,qmp-usb3-dp-phy.yaml +++ b/Documentation/devicetree/bindings/phy/qcom,qmp-usb3-dp-phy.yaml @@ -14,6 +14,7 @@ properties: compatible: enum: - qcom,sc7180-qmp-usb3-dp-phy + - qcom,sc7280-qmp-usb3-dp-phy - qcom,sdm845-qmp-usb3-dp-phy - qcom,sm8250-qmp-usb3-dp-phy reg: -- cgit v1.2.3 From 31f21e2a09a150972f9188c3a785998131e843ba Mon Sep 17 00:00:00 2001 From: Biju Das Date: Wed, 30 Jun 2021 08:30:04 +0100 Subject: dt-bindings: usb: generic-ehci: Document dr_mode property Document the optional property dr_mode present on both RZ/G2 and R-Car Gen3 SoCs. It fixes dtbs_check warning, 'dr_mode' does not match any of the regexes: 'pinctrl-[0-9]+' Signed-off-by: Biju Das Reviewed-by: Lad Prabhakar Acked-by: Rob Herring Link: https://lore.kernel.org/r/20210630073013.22415-3-biju.das.jz@bp.renesas.com Signed-off-by: Greg Kroah-Hartman --- Documentation/devicetree/bindings/usb/generic-ehci.yaml | 5 +++++ 1 file changed, 5 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/usb/generic-ehci.yaml b/Documentation/devicetree/bindings/usb/generic-ehci.yaml index 8089dc956ba3..f6e5e4abb85b 100644 --- a/Documentation/devicetree/bindings/usb/generic-ehci.yaml +++ b/Documentation/devicetree/bindings/usb/generic-ehci.yaml @@ -142,6 +142,11 @@ properties: iommus: maxItems: 1 + dr_mode: + enum: + - host + - otg + required: - compatible - reg -- cgit v1.2.3 From 0c29ec921059abf110434addd8b8ed9032e710c7 Mon Sep 17 00:00:00 2001 From: Biju Das Date: Wed, 30 Jun 2021 08:30:03 +0100 Subject: dt-bindings: usb: generic-ohci: Document dr_mode property Document the optional property dr_mode present on both RZ/G2 and R-Car Gen3 SoCs. It fixes the dtbs_check warning, 'dr_mode' does not match any of the regexes: 'pinctrl-[0-9]+' Signed-off-by: Biju Das Reviewed-by: Lad Prabhakar Acked-by: Rob Herring Link: https://lore.kernel.org/r/20210630073013.22415-2-biju.das.jz@bp.renesas.com Signed-off-by: Greg Kroah-Hartman --- Documentation/devicetree/bindings/usb/generic-ohci.yaml | 5 +++++ 1 file changed, 5 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/usb/generic-ohci.yaml b/Documentation/devicetree/bindings/usb/generic-ohci.yaml index 0f5f6ea702d0..569777a76c90 100644 --- a/Documentation/devicetree/bindings/usb/generic-ohci.yaml +++ b/Documentation/devicetree/bindings/usb/generic-ohci.yaml @@ -109,6 +109,11 @@ properties: iommus: maxItems: 1 + dr_mode: + enum: + - host + - otg + required: - compatible - reg -- cgit v1.2.3 From eaf6cbe0992052a46d93047dc122fad5126aa3bd Mon Sep 17 00:00:00 2001 From: Ruslan Bilovol Date: Mon, 12 Jul 2021 14:55:28 +0200 Subject: usb: gadget: f_uac2: add volume and mute support This adds bi-directional (host->device, device->host) volume/mute support to the f_uac2 driver by adding Feature Units and interrupt endpoint. Currently only master channel is supported. Volume and mute are configurable through configfs, by default volume has -100..0 dB range with 1 dB step. Similar to existing flexible endpoints configuration, Feature Unit won't be added to the topology if both mute and volume are not enabled, also interrupt endpoint isn't added to the device if no feature unit is present Signed-off-by: Ruslan Bilovol Signed-off-by: Pavel Hofman Link: https://lore.kernel.org/r/20210712125529.76070-4-pavel.hofman@ivitera.com Signed-off-by: Greg Kroah-Hartman --- Documentation/ABI/testing/configfs-usb-gadget-uac2 | 10 ++++++++++ Documentation/usb/gadget-testing.rst | 12 +++++++++++- 2 files changed, 21 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/configfs-usb-gadget-uac2 b/Documentation/ABI/testing/configfs-usb-gadget-uac2 index 26fb8e9b4e61..cfd160ff8b56 100644 --- a/Documentation/ABI/testing/configfs-usb-gadget-uac2 +++ b/Documentation/ABI/testing/configfs-usb-gadget-uac2 @@ -9,8 +9,18 @@ Description: c_srate capture sampling rate c_ssize capture sample size (bytes) c_sync capture synchronization type (async/adaptive) + c_mute_present capture mute control enable + c_volume_present capture volume control enable + c_volume_min capture volume control min value (in 1/256 dB) + c_volume_max capture volume control max value (in 1/256 dB) + c_volume_res capture volume control resolution (in 1/256 dB) fb_max maximum extra bandwidth in async mode p_chmask playback channel mask p_srate playback sampling rate p_ssize playback sample size (bytes) + p_mute_present playback mute control enable + p_volume_present playback volume control enable + p_volume_min playback volume control min value (in 1/256 dB) + p_volume_max playback volume control max value (in 1/256 dB) + p_volume_res playback volume control resolution (in 1/256 dB) ========= ============================ diff --git a/Documentation/usb/gadget-testing.rst b/Documentation/usb/gadget-testing.rst index 9d6276f82774..272e51f17f54 100644 --- a/Documentation/usb/gadget-testing.rst +++ b/Documentation/usb/gadget-testing.rst @@ -729,10 +729,20 @@ The uac2 function provides these attributes in its function directory: c_srate capture sampling rate c_ssize capture sample size (bytes) c_sync capture synchronization type (async/adaptive) - fb_max maximum extra bandwidth in async mode + c_mute_present capture mute control enable + c_volume_present capture volume control enable + c_volume_min capture volume control min value (in 1/256 dB) + c_volume_max capture volume control max value (in 1/256 dB) + c_volume_res capture volume control resolution (in 1/256 dB) + fb_max maximum extra bandwidth in async mode p_chmask playback channel mask p_srate playback sampling rate p_ssize playback sample size (bytes) + p_mute_present playback mute control enable + p_volume_present playback volume control enable + p_volume_min playback volume control min value (in 1/256 dB) + p_volume_max playback volume control max value (in 1/256 dB) + p_volume_res playback volume control resolution (in 1/256 dB) req_number the number of pre-allocated request for both capture and playback =============== ==================================================== -- cgit v1.2.3 From 0356e6283c7177391d144612f4b12986ed5c4f6e Mon Sep 17 00:00:00 2001 From: Ruslan Bilovol Date: Mon, 12 Jul 2021 14:55:29 +0200 Subject: usb: gadget: f_uac1: add volume and mute support This adds bi-directional (host->device, device->host) volume/mute support to the f_uac1 driver by adding Feature Units and interrupt endpoint. Currently only master channel is supported. Volume and mute are configurable through configfs, by default volume has -100..0 dB range with 1 dB step. Similar to existing flexible endpoints configuration, Feature Unit won't be added to the topology if both mute and volume are not enabled, also interrupt endpoint isn't added to the device if no feature unit is present Signed-off-by: Ruslan Bilovol Signed-off-by: Pavel Hofman Link: https://lore.kernel.org/r/20210712125529.76070-5-pavel.hofman@ivitera.com Signed-off-by: Greg Kroah-Hartman --- Documentation/ABI/testing/configfs-usb-gadget-uac1 | 10 +++++++++ Documentation/usb/gadget-testing.rst | 26 +++++++++++++++------- 2 files changed, 28 insertions(+), 8 deletions(-) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/configfs-usb-gadget-uac1 b/Documentation/ABI/testing/configfs-usb-gadget-uac1 index dc23fd776943..dd647d44d975 100644 --- a/Documentation/ABI/testing/configfs-usb-gadget-uac1 +++ b/Documentation/ABI/testing/configfs-usb-gadget-uac1 @@ -8,9 +8,19 @@ Description: c_chmask capture channel mask c_srate capture sampling rate c_ssize capture sample size (bytes) + c_mute_present capture mute control enable + c_volume_present capture volume control enable + c_volume_min capture volume control min value (in 1/256 dB) + c_volume_max capture volume control max value (in 1/256 dB) + c_volume_res capture volume control resolution (in 1/256 dB) p_chmask playback channel mask p_srate playback sampling rate p_ssize playback sample size (bytes) + p_mute_present playback mute control enable + p_volume_present playback volume control enable + p_volume_min playback volume control min value (in 1/256 dB) + p_volume_max playback volume control max value (in 1/256 dB) + p_volume_res playback volume control resolution (in 1/256 dB) req_number the number of pre-allocated request for both capture and playback ========== =================================== diff --git a/Documentation/usb/gadget-testing.rst b/Documentation/usb/gadget-testing.rst index 272e51f17f54..d6253f1a32a1 100644 --- a/Documentation/usb/gadget-testing.rst +++ b/Documentation/usb/gadget-testing.rst @@ -915,14 +915,24 @@ The function name to use when creating the function directory is "uac1". The uac1 function provides these attributes in its function directory: ========== ==================================================== - c_chmask capture channel mask - c_srate capture sampling rate - c_ssize capture sample size (bytes) - p_chmask playback channel mask - p_srate playback sampling rate - p_ssize playback sample size (bytes) - req_number the number of pre-allocated request for both capture - and playback + c_chmask capture channel mask + c_srate capture sampling rate + c_ssize capture sample size (bytes) + c_mute_present capture mute control enable + c_volume_present capture volume control enable + c_volume_min capture volume control min value (in 1/256 dB) + c_volume_max capture volume control max value (in 1/256 dB) + c_volume_res capture volume control resolution (in 1/256 dB) + p_chmask playback channel mask + p_srate playback sampling rate + p_ssize playback sample size (bytes) + p_mute_present playback mute control enable + p_volume_present playback volume control enable + p_volume_min playback volume control min value (in 1/256 dB) + p_volume_max playback volume control max value (in 1/256 dB) + p_volume_res playback volume control resolution (in 1/256 dB) + req_number the number of pre-allocated request for both capture + and playback ========== ==================================================== The attributes have sane default values. -- cgit v1.2.3 From a30d49ff8a329ede9d5483ea7a27a84b91d5fc3c Mon Sep 17 00:00:00 2001 From: Sibi Sankar Date: Thu, 29 Apr 2021 16:21:02 +0530 Subject: dt-bindings: reset: aoss: Add AOSS reset controller binding Add AOSS reset controller bindings for SC7280 SoCs. Acked-by: Rob Herring Reviewed-by: Stephen Boyd Signed-off-by: Sibi Sankar Link: https://lore.kernel.org/r/1619693465-5724-3-git-send-email-sibis@codeaurora.org Signed-off-by: Philipp Zabel --- Documentation/devicetree/bindings/reset/qcom,aoss-reset.yaml | 5 +++++ 1 file changed, 5 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/reset/qcom,aoss-reset.yaml b/Documentation/devicetree/bindings/reset/qcom,aoss-reset.yaml index e2d85a1e1d63..a054757f4d9f 100644 --- a/Documentation/devicetree/bindings/reset/qcom,aoss-reset.yaml +++ b/Documentation/devicetree/bindings/reset/qcom,aoss-reset.yaml @@ -21,6 +21,11 @@ properties: - const: "qcom,sc7180-aoss-cc" - const: "qcom,sdm845-aoss-cc" + - description: on SC7280 SoCs the following compatibles must be specified + items: + - const: "qcom,sc7280-aoss-cc" + - const: "qcom,sdm845-aoss-cc" + - description: on SDM845 SoCs the following compatibles must be specified items: - const: "qcom,sdm845-aoss-cc" -- cgit v1.2.3 From 9e3b594a923ee1aa0e13701361350b20f4d2597e Mon Sep 17 00:00:00 2001 From: Sibi Sankar Date: Thu, 29 Apr 2021 16:21:03 +0530 Subject: dt-bindings: reset: pdc: Add PDC Global bindings Add PDC Global reset controller bindings for SC7280 SoCs. Acked-by: Rob Herring Signed-off-by: Sibi Sankar Link: https://lore.kernel.org/r/1619693465-5724-4-git-send-email-sibis@codeaurora.org Signed-off-by: Philipp Zabel --- Documentation/devicetree/bindings/reset/qcom,pdc-global.yaml | 4 ++++ 1 file changed, 4 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/reset/qcom,pdc-global.yaml b/Documentation/devicetree/bindings/reset/qcom,pdc-global.yaml index d7d8cec9419f..831ea8d5d83f 100644 --- a/Documentation/devicetree/bindings/reset/qcom,pdc-global.yaml +++ b/Documentation/devicetree/bindings/reset/qcom,pdc-global.yaml @@ -21,6 +21,10 @@ properties: - const: "qcom,sc7180-pdc-global" - const: "qcom,sdm845-pdc-global" + - description: on SC7280 SoCs the following compatibles must be specified + items: + - const: "qcom,sc7280-pdc-global" + - description: on SDM845 SoCs the following compatibles must be specified items: - const: "qcom,sdm845-pdc-global" -- cgit v1.2.3 From 28edf1d77cd5b5f35828dcc3ac2bfa912bf04a3f Mon Sep 17 00:00:00 2001 From: Kunihiko Hayashi Date: Wed, 23 Jun 2021 10:53:28 +0900 Subject: dt-bindings: reset: Convert UniPhier glue reset to json-schema Convert the UniPhier peripheral glue reset binding to DT schema format. Signed-off-by: Kunihiko Hayashi Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/1624413208-17562-1-git-send-email-hayashi.kunihiko@socionext.com Signed-off-by: Philipp Zabel --- .../reset/socionext,uniphier-glue-reset.yaml | 88 ++++++++++++++++++++++ .../devicetree/bindings/reset/uniphier-reset.txt | 61 --------------- 2 files changed, 88 insertions(+), 61 deletions(-) create mode 100644 Documentation/devicetree/bindings/reset/socionext,uniphier-glue-reset.yaml delete mode 100644 Documentation/devicetree/bindings/reset/uniphier-reset.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/reset/socionext,uniphier-glue-reset.yaml b/Documentation/devicetree/bindings/reset/socionext,uniphier-glue-reset.yaml new file mode 100644 index 000000000000..29e4a900cad7 --- /dev/null +++ b/Documentation/devicetree/bindings/reset/socionext,uniphier-glue-reset.yaml @@ -0,0 +1,88 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/reset/socionext,uniphier-glue-reset.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Socionext UniPhier peripheral core reset in glue layer + +description: | + Some peripheral core reset belongs to its own glue layer. Before using + this core reset, it is necessary to control the clocks and resets to + enable this layer. These clocks and resets should be described in each + property. + +maintainers: + - Kunihiko Hayashi + +properties: + compatible: + enum: + - socionext,uniphier-pro4-usb3-reset + - socionext,uniphier-pro5-usb3-reset + - socionext,uniphier-pxs2-usb3-reset + - socionext,uniphier-ld20-usb3-reset + - socionext,uniphier-pxs3-usb3-reset + - socionext,uniphier-pro4-ahci-reset + - socionext,uniphier-pxs2-ahci-reset + - socionext,uniphier-pxs3-ahci-reset + + reg: + maxItems: 1 + + "#reset-cells": + const: 1 + + clocks: + minItems: 1 + maxItems: 2 + + clock-names: + oneOf: + - items: # for Pro4, Pro5 + - const: gio + - const: link + - items: # for others + - const: link + + resets: + minItems: 1 + maxItems: 2 + + reset-names: + oneOf: + - items: # for Pro4, Pro5 + - const: gio + - const: link + - items: # for others + - const: link + +additionalProperties: false + +required: + - compatible + - reg + - "#reset-cells" + - clocks + - clock-names + - resets + - reset-names + +examples: + - | + usb-glue@65b00000 { + compatible = "simple-mfd"; + #address-cells = <1>; + #size-cells = <1>; + ranges = <0 0x65b00000 0x400>; + + usb_rst: reset@0 { + compatible = "socionext,uniphier-ld20-usb3-reset"; + reg = <0x0 0x4>; + #reset-cells = <1>; + clock-names = "link"; + clocks = <&sys_clk 14>; + reset-names = "link"; + resets = <&sys_rst 14>; + }; + }; diff --git a/Documentation/devicetree/bindings/reset/uniphier-reset.txt b/Documentation/devicetree/bindings/reset/uniphier-reset.txt deleted file mode 100644 index 88e06e5e8d23..000000000000 --- a/Documentation/devicetree/bindings/reset/uniphier-reset.txt +++ /dev/null @@ -1,61 +0,0 @@ -UniPhier glue reset controller - - -Peripheral core reset in glue layer ------------------------------------ - -Some peripheral core reset belongs to its own glue layer. Before using -this core reset, it is necessary to control the clocks and resets to enable -this layer. These clocks and resets should be described in each property. - -Required properties: -- compatible: Should be - "socionext,uniphier-pro4-usb3-reset" - for Pro4 SoC USB3 - "socionext,uniphier-pro5-usb3-reset" - for Pro5 SoC USB3 - "socionext,uniphier-pxs2-usb3-reset" - for PXs2 SoC USB3 - "socionext,uniphier-ld20-usb3-reset" - for LD20 SoC USB3 - "socionext,uniphier-pxs3-usb3-reset" - for PXs3 SoC USB3 - "socionext,uniphier-pro4-ahci-reset" - for Pro4 SoC AHCI - "socionext,uniphier-pxs2-ahci-reset" - for PXs2 SoC AHCI - "socionext,uniphier-pxs3-ahci-reset" - for PXs3 SoC AHCI -- #reset-cells: Should be 1. -- reg: Specifies offset and length of the register set for the device. -- clocks: A list of phandles to the clock gate for the glue layer. - According to the clock-names, appropriate clocks are required. -- clock-names: Should contain - "gio", "link" - for Pro4 and Pro5 SoCs - "link" - for others -- resets: A list of phandles to the reset control for the glue layer. - According to the reset-names, appropriate resets are required. -- reset-names: Should contain - "gio", "link" - for Pro4 and Pro5 SoCs - "link" - for others - -Example: - - usb-glue@65b00000 { - compatible = "socionext,uniphier-ld20-dwc3-glue", - "simple-mfd"; - #address-cells = <1>; - #size-cells = <1>; - ranges = <0 0x65b00000 0x400>; - - usb_rst: reset@0 { - compatible = "socionext,uniphier-ld20-usb3-reset"; - reg = <0x0 0x4>; - #reset-cells = <1>; - clock-names = "link"; - clocks = <&sys_clk 14>; - reset-names = "link"; - resets = <&sys_rst 14>; - }; - - regulator { - ... - }; - - phy { - ... - }; - ... - }; -- cgit v1.2.3 From 65a2c14d4f008dcea51391bb7189d95ca7656721 Mon Sep 17 00:00:00 2001 From: Nobuhiro Iwamatsu Date: Thu, 15 Jul 2021 18:22:52 +0900 Subject: dt-bindings: serial: convert Cadence UART bindings to YAML Convert serial for Cadence UART bindings documentation to YAML. Reviewed-by: Rob Herring Signed-off-by: Nobuhiro Iwamatsu Link: https://lore.kernel.org/r/20210715092252.225740-1-iwamatsu@nigauri.org Signed-off-by: Greg Kroah-Hartman --- .../devicetree/bindings/serial/cdns,uart.txt | 27 --------- .../devicetree/bindings/serial/cdns,uart.yaml | 66 ++++++++++++++++++++++ 2 files changed, 66 insertions(+), 27 deletions(-) delete mode 100644 Documentation/devicetree/bindings/serial/cdns,uart.txt create mode 100644 Documentation/devicetree/bindings/serial/cdns,uart.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/serial/cdns,uart.txt b/Documentation/devicetree/bindings/serial/cdns,uart.txt deleted file mode 100644 index 4efc560f90ab..000000000000 --- a/Documentation/devicetree/bindings/serial/cdns,uart.txt +++ /dev/null @@ -1,27 +0,0 @@ -Binding for Cadence UART Controller - -Required properties: -- compatible : - Use "xlnx,xuartps","cdns,uart-r1p8" for Zynq-7xxx SoC. - Use "xlnx,zynqmp-uart","cdns,uart-r1p12" for Zynq Ultrascale+ MPSoC. -- reg: Should contain UART controller registers location and length. -- interrupts: Should contain UART controller interrupts. -- clocks: Must contain phandles to the UART clocks - See ../clocks/clock-bindings.txt for details. -- clock-names: Tuple to identify input clocks, must contain "uart_clk" and "pclk" - See ../clocks/clock-bindings.txt for details. - - -Optional properties: -- cts-override : Override the CTS modem status signal. This signal will - always be reported as active instead of being obtained from the modem status - register. Define this if your serial port does not use this pin - -Example: - uart@e0000000 { - compatible = "cdns,uart-r1p8"; - clocks = <&clkc 23>, <&clkc 40>; - clock-names = "uart_clk", "pclk"; - reg = <0xE0000000 0x1000>; - interrupts = <0 27 4>; - }; diff --git a/Documentation/devicetree/bindings/serial/cdns,uart.yaml b/Documentation/devicetree/bindings/serial/cdns,uart.yaml new file mode 100644 index 000000000000..fcdbe6f87e98 --- /dev/null +++ b/Documentation/devicetree/bindings/serial/cdns,uart.yaml @@ -0,0 +1,66 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/serial/cdns,uart.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Cadence UART Controller Device Tree Bindings + +maintainers: + - Michal Simek + +allOf: + - $ref: /schemas/serial.yaml# + +properties: + compatible: + oneOf: + - description: UART controller for Zynq-7xxx SoC + items: + - const: xlnx,xuartps + - const: cdns,uart-r1p8 + - description: UART controller for Zynq Ultrascale+ MPSoC + items: + - const: xlnx,zynqmp-uart + - const: cdns,uart-r1p12 + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 2 + + clock-names: + items: + - const: uart_clk + - const: pclk + + cts-override: + description: | + Override the CTS modem status signal. This signal will + always be reported as active instead of being obtained + from the modem status register. Define this if your serial + port does not use this pin. + type: boolean + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + +unevaluatedProperties: false + +examples: + - | + uart0: serial@e0000000 { + compatible = "xlnx,xuartps", "cdns,uart-r1p8"; + clocks = <&clkc 23>, <&clkc 40>; + clock-names = "uart_clk", "pclk"; + reg = <0xE0000000 0x1000>; + interrupts = <0 27 4>; + }; -- cgit v1.2.3 From f9ac897e5a4bf7255f2f7613f2a74c2a9a41327c Mon Sep 17 00:00:00 2001 From: Appana Durga Kedareswara rao Date: Sat, 26 Jun 2021 21:22:45 +0530 Subject: dt-bindings: fpga: Add binding doc for versal fpga manager This patch adds binding doc for versal fpga manager driver. Reviewed-by: Rob Herring Signed-off-by: Nava kishore Manne Signed-off-by: Appana Durga Kedareswara rao Link: https://lore.kernel.org/r/20210626155248.5004-3-nava.manne@xilinx.com Signed-off-by: Greg Kroah-Hartman --- .../devicetree/bindings/fpga/xlnx,versal-fpga.yaml | 33 ++++++++++++++++++++++ 1 file changed, 33 insertions(+) create mode 100644 Documentation/devicetree/bindings/fpga/xlnx,versal-fpga.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/fpga/xlnx,versal-fpga.yaml b/Documentation/devicetree/bindings/fpga/xlnx,versal-fpga.yaml new file mode 100644 index 000000000000..ac6a207278d5 --- /dev/null +++ b/Documentation/devicetree/bindings/fpga/xlnx,versal-fpga.yaml @@ -0,0 +1,33 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/fpga/xlnx,versal-fpga.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Xilinx Versal FPGA driver. + +maintainers: + - Nava kishore Manne + +description: | + Device Tree Versal FPGA bindings for the Versal SoC, controlled + using firmware interface. + +properties: + compatible: + items: + - enum: + - xlnx,versal-fpga + +required: + - compatible + +additionalProperties: false + +examples: + - | + versal_fpga: versal_fpga { + compatible = "xlnx,versal-fpga"; + }; + +... -- cgit v1.2.3 From f8cc6d715bfc649e523cc829d2e6d1e58b430a33 Mon Sep 17 00:00:00 2001 From: Nava kishore Manne Date: Sat, 26 Jun 2021 21:22:46 +0530 Subject: dt-bindings: firmware: Add bindings for xilinx firmware Add documentation to describe Xilinx firmware driver bindings. Firmware driver provides an interface to firmware APIs. Interface APIs can be used by any driver to communicate to Platform Management Unit. Reviewed-by: Rob Herring Signed-off-by: Nava kishore Manne Link: https://lore.kernel.org/r/20210626155248.5004-4-nava.manne@xilinx.com Signed-off-by: Greg Kroah-Hartman --- .../firmware/xilinx/xlnx,zynqmp-firmware.yaml | 89 ++++++++++++++++++++++ 1 file changed, 89 insertions(+) create mode 100644 Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.yaml b/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.yaml new file mode 100644 index 000000000000..f14f7b454f07 --- /dev/null +++ b/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.yaml @@ -0,0 +1,89 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/firmware/xilinx/xlnx,zynqmp-firmware.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Xilinx firmware driver + +maintainers: + - Nava kishore Manne + +description: The zynqmp-firmware node describes the interface to platform + firmware. ZynqMP has an interface to communicate with secure firmware. + Firmware driver provides an interface to firmware APIs. Interface APIs + can be used by any driver to communicate to PMUFW(Platform Management Unit). + These requests include clock management, pin control, device control, + power management service, FPGA service and other platform management + services. + +properties: + compatible: + oneOf: + - description: For implementations complying for Zynq Ultrascale+ MPSoC. + const: xlnx,zynqmp-firmware + + - description: For implementations complying for Versal. + const: xlnx,versal-firmware + + method: + description: | + The method of calling the PM-API firmware layer. + Permitted values are. + - "smc" : SMC #0, following the SMCCC + - "hvc" : HVC #0, following the SMCCC + + $ref: /schemas/types.yaml#/definitions/string-array + enum: + - smc + - hvc + + versal_fpga: + $ref: /schemas/fpga/xlnx,versal-fpga.yaml# + description: Compatible of the FPGA device. + type: object + + zynqmp-aes: + $ref: /schemas/crypto/xlnx,zynqmp-aes.yaml# + description: The ZynqMP AES-GCM hardened cryptographic accelerator is + used to encrypt or decrypt the data with provided key and initialization + vector. + type: object + + clock-controller: + $ref: /schemas/clock/xlnx,versal-clk.yaml# + description: The clock controller is a hardware block of Xilinx versal + clock tree. It reads required input clock frequencies from the devicetree + and acts as clock provider for all clock consumers of PS clocks.list of + clock specifiers which are external input clocks to the given clock + controller. + type: object + +required: + - compatible + +additionalProperties: false + +examples: + - | + versal-firmware { + compatible = "xlnx,versal-firmware"; + method = "smc"; + + versal_fpga: versal_fpga { + compatible = "xlnx,versal-fpga"; + }; + + xlnx_aes: zynqmp-aes { + compatible = "xlnx,zynqmp-aes"; + }; + + versal_clk: clock-controller { + #clock-cells = <1>; + compatible = "xlnx,versal-clk"; + clocks = <&ref>, <&alt_ref>, <&pl_alt_ref>; + clock-names = "ref", "alt_ref", "pl_alt_ref"; + }; + }; + +... -- cgit v1.2.3 From 8c9b1301171f6690144d45a3e18ba676acbc34bc Mon Sep 17 00:00:00 2001 From: Nava kishore Manne Date: Sat, 26 Jun 2021 21:22:47 +0530 Subject: dt-bindings: firmware: Remove xlnx,zynqmp-firmware.txt file The funtionality of xlnx,zynqmp-firmware.txt is replaced with xlnx,zynqmp-firmware.yaml bindings so this patch removes the zynqmp-firmware.txt file Reviewed-by: Rob Herring Signed-off-by: Nava kishore Manne Link: https://lore.kernel.org/r/20210626155248.5004-5-nava.manne@xilinx.com Signed-off-by: Greg Kroah-Hartman --- .../firmware/xilinx/xlnx,zynqmp-firmware.txt | 44 ---------------------- 1 file changed, 44 deletions(-) delete mode 100644 Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.txt b/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.txt deleted file mode 100644 index 18c3aea90df2..000000000000 --- a/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.txt +++ /dev/null @@ -1,44 +0,0 @@ ------------------------------------------------------------------ -Device Tree Bindings for the Xilinx Zynq MPSoC Firmware Interface ------------------------------------------------------------------ - -The zynqmp-firmware node describes the interface to platform firmware. -ZynqMP has an interface to communicate with secure firmware. Firmware -driver provides an interface to firmware APIs. Interface APIs can be -used by any driver to communicate to PMUFW(Platform Management Unit). -These requests include clock management, pin control, device control, -power management service, FPGA service and other platform management -services. - -Required properties: - - compatible: Must contain any of below: - "xlnx,zynqmp-firmware" for Zynq Ultrascale+ MPSoC - "xlnx,versal-firmware" for Versal - - method: The method of calling the PM-API firmware layer. - Permitted values are: - - "smc" : SMC #0, following the SMCCC - - "hvc" : HVC #0, following the SMCCC - -------- -Example -------- - -Zynq Ultrascale+ MPSoC ----------------------- -firmware { - zynqmp_firmware: zynqmp-firmware { - compatible = "xlnx,zynqmp-firmware"; - method = "smc"; - ... - }; -}; - -Versal ------- -firmware { - versal_firmware: versal-firmware { - compatible = "xlnx,versal-firmware"; - method = "smc"; - ... - }; -}; -- cgit v1.2.3 From 06e1721d2a265d1247093f5ad5ae2958ef10a604 Mon Sep 17 00:00:00 2001 From: Carlos Llamas Date: Thu, 15 Jul 2021 03:18:04 +0000 Subject: docs: binderfs: add section about feature files Document how binder feature files can be used to determine whether a feature is supported by the binder driver. "oneway_spam_detection" is used as an example as it is the first available feature file. Acked-by: Christian Brauner Signed-off-by: Carlos Llamas Link: https://lore.kernel.org/r/20210715031805.1725878-2-cmllamas@google.com Signed-off-by: Greg Kroah-Hartman --- Documentation/admin-guide/binderfs.rst | 13 +++++++++++++ 1 file changed, 13 insertions(+) (limited to 'Documentation') diff --git a/Documentation/admin-guide/binderfs.rst b/Documentation/admin-guide/binderfs.rst index 199d84314a14..41a4db00df8d 100644 --- a/Documentation/admin-guide/binderfs.rst +++ b/Documentation/admin-guide/binderfs.rst @@ -72,3 +72,16 @@ that the `rm() `_ tool can be used to delete them. Note that the ``binder-control`` device cannot be deleted since this would make the binderfs instance unusable. The ``binder-control`` device will be deleted when the binderfs instance is unmounted and all references to it have been dropped. + +Binder features +--------------- + +Assuming an instance of binderfs has been mounted at ``/dev/binderfs``, the +features supported by the binder driver can be located under +``/dev/binderfs/features/``. The presence of individual files can be tested +to determine whether a particular feature is supported by the driver. + +Example:: + + cat /dev/binderfs/features/oneway_spam_detection + 1 -- cgit v1.2.3 From 17ce60b2e4f87262eedd693021224130d720c00c Mon Sep 17 00:00:00 2001 From: Vincent Pelletier Date: Mon, 5 Jul 2021 00:43:59 +0000 Subject: Documentation: gpio: driver.rst: Remove gpiochip_irqchip_add mention This function was removed in commit f1f37abbe6fc ("gpio: Retire the explicit gpio irqchip code") but this mention was left behind. Also, mention that .set_type() only has to set a line handler if the chip is cascaded, as opposed to hierarchical. Signed-off-by: Vincent Pelletier Signed-off-by: Bartosz Golaszewski --- Documentation/driver-api/gpio/driver.rst | 11 ++++------- 1 file changed, 4 insertions(+), 7 deletions(-) (limited to 'Documentation') diff --git a/Documentation/driver-api/gpio/driver.rst b/Documentation/driver-api/gpio/driver.rst index d6b0d779859b..bbc53920d4dd 100644 --- a/Documentation/driver-api/gpio/driver.rst +++ b/Documentation/driver-api/gpio/driver.rst @@ -547,13 +547,10 @@ To use the helpers please keep the following in mind: the irqchip can initialize. E.g. .dev and .can_sleep shall be set up properly. -- Nominally set all handlers to handle_bad_irq() in the setup call and pass - handle_bad_irq() as flow handler parameter in gpiochip_irqchip_add() if it is - expected for GPIO driver that irqchip .set_type() callback will be called - before using/enabling each GPIO IRQ. Then set the handler to - handle_level_irq() and/or handle_edge_irq() in the irqchip .set_type() - callback depending on what your controller supports and what is requested - by the consumer. +- Nominally set gpio_irq_chip.handler to handle_bad_irq. Then, if your irqchip + is cascaded, set the handler to handle_level_irq() and/or handle_edge_irq() + in the irqchip .set_type() callback depending on what your controller + supports and what is requested by the consumer. Locking IRQ usage -- cgit v1.2.3 From f3f1017a98f91355671feb0e741391999a43b55d Mon Sep 17 00:00:00 2001 From: Hannu Hartikainen Date: Thu, 8 Jul 2021 18:20:54 +0300 Subject: docs: gpio: explain GPIOD_OUT_* values and toggling active low I was confused about the gpiod_flags values and thought that GPIOD_OUT_LOW and GPIOD_OUT_HIGH set the line to be active low / active high. This is not true, but I got the misconception because the flags GPIOD_OUT_*_OPEN_DRAIN do change line configuration and there's a subchapter about *active low* and *open drain* semantics. Add an explicit mention that the initial value is a logical value (and not the line configuration or physical line level). Also add a mention of the function gpiod_toggle_active_low which was previously missing from this document. Signed-off-by: Hannu Hartikainen Signed-off-by: Bartosz Golaszewski --- Documentation/driver-api/gpio/consumer.rst | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/driver-api/gpio/consumer.rst b/Documentation/driver-api/gpio/consumer.rst index 3366a991b4aa..47869ca8ccf0 100644 --- a/Documentation/driver-api/gpio/consumer.rst +++ b/Documentation/driver-api/gpio/consumer.rst @@ -72,6 +72,10 @@ for the GPIO. Values can be: * GPIOD_OUT_HIGH_OPEN_DRAIN same as GPIOD_OUT_HIGH but also enforce the line to be electrically used with open drain. +Note that the initial value is *logical* and the physical line level depends on +whether the line is configured active high or active low (see +:ref:`active_low_semantics`). + The two last flags are used for use cases where open drain is mandatory, such as I2C: if the line is not already configured as open drain in the mappings (see board.txt), then open drain will be enforced anyway and a warning will be @@ -252,6 +256,8 @@ that can't be accessed from hardIRQ handlers, these calls act the same as the spinlock-safe calls. +.. _active_low_semantics: + The active low and open drain semantics --------------------------------------- As a consumer should not have to care about the physical line level, all of the @@ -309,9 +315,11 @@ work on the raw line value:: void gpiod_set_raw_value_cansleep(struct gpio_desc *desc, int value) int gpiod_direction_output_raw(struct gpio_desc *desc, int value) -The active low state of a GPIO can also be queried using the following call:: +The active low state of a GPIO can also be queried and toggled using the +following calls:: int gpiod_is_active_low(const struct gpio_desc *desc) + void gpiod_toggle_active_low(struct gpio_desc *desc) Note that these functions should only be used with great moderation; a driver should not have to care about the physical line level or open drain semantics. -- cgit v1.2.3 From de8e80a54c96d2b75377e0e5319a64d32c88c690 Mon Sep 17 00:00:00 2001 From: Justin Iurman Date: Tue, 20 Jul 2021 21:43:00 +0200 Subject: ipv6: ioam: Documentation for new IOAM sysctls Add documentation for new IOAM sysctls: - ioam6_id and ioam6_id_wide: two per-namespace sysctls - ioam6_enabled, ioam6_id and ioam6_id_wide: three per-interface sysctls Example of IOAM configuration based on the following simple topology: _____ _____ _____ | | eth0 eth0 | | eth1 eth0 | | | A |.----------.| B |.----------.| C | |_____| |_____| |_____| 1) Node and interface IDs can be configured for IOAM: # IOAM ID of A = 1, IOAM ID of A.eth0 = 11 (A) sysctl -w net.ipv6.ioam6_id=1 (A) sysctl -w net.ipv6.conf.eth0.ioam6_id=11 # IOAM ID of B = 2, IOAM ID of B.eth0 = 21, IOAM ID of B.eth1 = 22 (B) sysctl -w net.ipv6.ioam6_id=2 (B) sysctl -w net.ipv6.conf.eth0.ioam6_id=21 (B) sysctl -w net.ipv6.conf.eth1.ioam6_id=22 # IOAM ID of C = 3, IOAM ID of C.eth0 = 31 (C) sysctl -w net.ipv6.ioam6_id=3 (C) sysctl -w net.ipv6.conf.eth0.ioam6_id=31 Note that "_wide" IDs equivalents can be configured the same way. 2) Each node can be configured to form an IOAM domain. For instance, we allow IOAM from A to C only (not the reverse path), i.e. enable IOAM on ingress for B.eth0 and C.eth0: (B) sysctl -w net.ipv6.conf.eth0.ioam6_enabled=1 (C) sysctl -w net.ipv6.conf.eth0.ioam6_enabled=1 3) An IOAM domain (e.g. ID=123) is defined and made known to each node: (A) ip ioam namespace add 123 (B) ip ioam namespace add 123 (C) ip ioam namespace add 123 4) Finally, an IOAM Pre-allocated Trace can be inserted in traffic sent by A when C (e.g. db02::2) is the destination: (A) ip -6 route add db02::2/128 encap ioam6 trace type 0x800000 ns 123 size 12 dev eth0 Signed-off-by: Justin Iurman Signed-off-by: David S. Miller --- Documentation/networking/ioam6-sysctl.rst | 26 ++++++++++++++++++++++++++ Documentation/networking/ip-sysctl.rst | 17 +++++++++++++++++ 2 files changed, 43 insertions(+) create mode 100644 Documentation/networking/ioam6-sysctl.rst (limited to 'Documentation') diff --git a/Documentation/networking/ioam6-sysctl.rst b/Documentation/networking/ioam6-sysctl.rst new file mode 100644 index 000000000000..c18cab2c481a --- /dev/null +++ b/Documentation/networking/ioam6-sysctl.rst @@ -0,0 +1,26 @@ +.. SPDX-License-Identifier: GPL-2.0 + +===================== +IOAM6 Sysfs variables +===================== + + +/proc/sys/net/conf//ioam6_* variables: +============================================= + +ioam6_enabled - BOOL + Accept (= enabled) or ignore (= disabled) IPv6 IOAM options on ingress + for this interface. + + * 0 - disabled (default) + * 1 - enabled + +ioam6_id - SHORT INTEGER + Define the IOAM id of this interface. + + Default is ~0. + +ioam6_id_wide - INTEGER + Define the wide IOAM id of this interface. + + Default is ~0. diff --git a/Documentation/networking/ip-sysctl.rst b/Documentation/networking/ip-sysctl.rst index b3fa522e4cd9..4bb4fa45cc29 100644 --- a/Documentation/networking/ip-sysctl.rst +++ b/Documentation/networking/ip-sysctl.rst @@ -1926,6 +1926,23 @@ fib_notify_on_flag_change - INTEGER - 1 - Emit notifications. - 2 - Emit notifications only for RTM_F_OFFLOAD_FAILED flag change. +ioam6_id - INTEGER + Define the IOAM id of this node. Uses only 24 bits out of 32 in total. + + Min: 0 + Max: 0xFFFFFF + + Default: 0xFFFFFF + +ioam6_id_wide - LONG INTEGER + Define the wide IOAM id of this node. Uses only 56 bits out of 64 in + total. Can be different from ioam6_id. + + Min: 0 + Max: 0xFFFFFFFFFFFFFF + + Default: 0xFFFFFFFFFFFFFF + IPv6 Fragmentation: ip6frag_high_thresh - INTEGER -- cgit v1.2.3 From 649502a337544840f1fbab8660603e08e86e2f41 Mon Sep 17 00:00:00 2001 From: Joakim Zhang Date: Wed, 21 Jul 2021 18:12:19 +0800 Subject: dt-bindings: net: fsl,fec: improve the binding a bit This patch improves the yaml a bit according to Rob Herring comments: 1) normalize interrupt-names property, there is no reason to support random order. 2) validate each string in clock-names property. 3) add constraints for fsl,num-tx-queues/fsl,num-rx-queues property. 4) change additionalProperties to false in order to do strict checking. Signed-off-by: Joakim Zhang Signed-off-by: David S. Miller --- Documentation/devicetree/bindings/net/fsl,fec.yaml | 34 ++++++++++++---------- 1 file changed, 19 insertions(+), 15 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/fsl,fec.yaml b/Documentation/devicetree/bindings/net/fsl,fec.yaml index 0f8ca4e574c6..dbcbec95fc9e 100644 --- a/Documentation/devicetree/bindings/net/fsl,fec.yaml +++ b/Documentation/devicetree/bindings/net/fsl,fec.yaml @@ -49,19 +49,21 @@ properties: maxItems: 4 interrupt-names: - description: - 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). + oneOf: + - items: + - const: int0 + - items: + - const: int0 + - const: pps + - items: + - const: int0 + - const: int1 + - const: int2 + - items: + - const: int0 + - const: int1 + - const: int2 + - const: pps clocks: minItems: 2 @@ -80,7 +82,7 @@ properties: clock-names: minItems: 2 maxItems: 5 - contains: + items: enum: - ipg - ahb @@ -107,12 +109,14 @@ properties: description: The property is valid for enet-avb IP, which supports hw multi queues. Should specify the tx queue number, otherwise set tx queue number to 1. + enum: [1, 2, 3] fsl,num-rx-queues: $ref: /schemas/types.yaml#/definitions/uint32 description: The property is valid for enet-avb IP, which supports hw multi queues. Should specify the rx queue number, otherwise set rx queue number to 1. + enum: [1, 2, 3] fsl,magic-packet: $ref: /schemas/types.yaml#/definitions/flag @@ -179,7 +183,7 @@ required: # least undocumented properties. However, PHY may have a deprecated option to # place PHY OF properties in the MAC node, such as Micrel PHY, and we can find # these boards which is based on i.MX6QDL. -additionalProperties: true +additionalProperties: false examples: - | -- cgit v1.2.3 From 758f74674bcb82e1ed1a0b5a56980f295183b546 Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Mon, 10 May 2021 12:26:25 +0200 Subject: docs: driver-api: fpga: avoid using UTF-8 chars MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit While UTF-8 characters can be used at the Linux documentation, the best is to use them only when ASCII doesn't offer a good replacement. So, replace the occurences of the following UTF-8 characters: - U+2014 ('—'): EM DASH Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Moritz Fischer --- Documentation/driver-api/fpga/fpga-bridge.rst | 10 +++++----- Documentation/driver-api/fpga/fpga-mgr.rst | 12 ++++++------ Documentation/driver-api/fpga/fpga-programming.rst | 8 ++++---- Documentation/driver-api/fpga/fpga-region.rst | 20 ++++++++++---------- 4 files changed, 25 insertions(+), 25 deletions(-) (limited to 'Documentation') diff --git a/Documentation/driver-api/fpga/fpga-bridge.rst b/Documentation/driver-api/fpga/fpga-bridge.rst index 198aadafd3e7..8d650b4e2ce6 100644 --- a/Documentation/driver-api/fpga/fpga-bridge.rst +++ b/Documentation/driver-api/fpga/fpga-bridge.rst @@ -4,11 +4,11 @@ FPGA Bridge API to implement a new FPGA bridge ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -* struct fpga_bridge — The FPGA Bridge structure -* struct fpga_bridge_ops — Low level Bridge driver ops -* devm_fpga_bridge_create() — Allocate and init a bridge struct -* fpga_bridge_register() — Register a bridge -* fpga_bridge_unregister() — Unregister a bridge +* struct fpga_bridge - The FPGA Bridge structure +* struct fpga_bridge_ops - Low level Bridge driver ops +* devm_fpga_bridge_create() - Allocate and init a bridge struct +* fpga_bridge_register() - Register a bridge +* fpga_bridge_unregister() - Unregister a bridge .. kernel-doc:: include/linux/fpga/fpga-bridge.h :functions: fpga_bridge diff --git a/Documentation/driver-api/fpga/fpga-mgr.rst b/Documentation/driver-api/fpga/fpga-mgr.rst index 917ee22db429..4d926b452cb3 100644 --- a/Documentation/driver-api/fpga/fpga-mgr.rst +++ b/Documentation/driver-api/fpga/fpga-mgr.rst @@ -101,12 +101,12 @@ in state. API for implementing a new FPGA Manager driver ---------------------------------------------- -* ``fpga_mgr_states`` — Values for :c:expr:`fpga_manager->state`. -* struct fpga_manager — the FPGA manager struct -* struct fpga_manager_ops — Low level FPGA manager driver ops -* devm_fpga_mgr_create() — Allocate and init a manager struct -* fpga_mgr_register() — Register an FPGA manager -* fpga_mgr_unregister() — Unregister an FPGA manager +* ``fpga_mgr_states`` - Values for :c:expr:`fpga_manager->state`. +* struct fpga_manager - the FPGA manager struct +* struct fpga_manager_ops - Low level FPGA manager driver ops +* devm_fpga_mgr_create() - Allocate and init a manager struct +* fpga_mgr_register() - Register an FPGA manager +* fpga_mgr_unregister() - Unregister an FPGA manager .. kernel-doc:: include/linux/fpga/fpga-mgr.h :functions: fpga_mgr_states diff --git a/Documentation/driver-api/fpga/fpga-programming.rst b/Documentation/driver-api/fpga/fpga-programming.rst index 002392dab04f..fb4da4240e96 100644 --- a/Documentation/driver-api/fpga/fpga-programming.rst +++ b/Documentation/driver-api/fpga/fpga-programming.rst @@ -84,10 +84,10 @@ will generate that list. Here's some sample code of what to do next:: API for programming an FPGA --------------------------- -* fpga_region_program_fpga() — Program an FPGA -* fpga_image_info() — Specifies what FPGA image to program -* fpga_image_info_alloc() — Allocate an FPGA image info struct -* fpga_image_info_free() — Free an FPGA image info struct +* fpga_region_program_fpga() - Program an FPGA +* fpga_image_info() - Specifies what FPGA image to program +* fpga_image_info_alloc() - Allocate an FPGA image info struct +* fpga_image_info_free() - Free an FPGA image info struct .. kernel-doc:: drivers/fpga/fpga-region.c :functions: fpga_region_program_fpga diff --git a/Documentation/driver-api/fpga/fpga-region.rst b/Documentation/driver-api/fpga/fpga-region.rst index 363a8171ab0a..2636a27c11b2 100644 --- a/Documentation/driver-api/fpga/fpga-region.rst +++ b/Documentation/driver-api/fpga/fpga-region.rst @@ -45,19 +45,19 @@ An example of usage can be seen in the probe function of [#f2]_. API to add a new FPGA region ---------------------------- -* struct fpga_region — The FPGA region struct -* devm_fpga_region_create() — Allocate and init a region struct -* fpga_region_register() — Register an FPGA region -* fpga_region_unregister() — Unregister an FPGA region +* struct fpga_region - The FPGA region struct +* devm_fpga_region_create() - Allocate and init a region struct +* fpga_region_register() - Register an FPGA region +* fpga_region_unregister() - Unregister an FPGA region The FPGA region's probe function will need to get a reference to the FPGA Manager it will be using to do the programming. This usually would happen during the region's probe function. -* fpga_mgr_get() — Get a reference to an FPGA manager, raise ref count -* of_fpga_mgr_get() — Get a reference to an FPGA manager, raise ref count, +* fpga_mgr_get() - Get a reference to an FPGA manager, raise ref count +* of_fpga_mgr_get() - Get a reference to an FPGA manager, raise ref count, given a device node. -* fpga_mgr_put() — Put an FPGA manager +* fpga_mgr_put() - Put an FPGA manager The FPGA region will need to specify which bridges to control while programming the FPGA. The region driver can build a list of bridges during probe time @@ -66,11 +66,11 @@ the list of bridges to program just before programming (:c:expr:`fpga_region->get_bridges`). The FPGA bridge framework supplies the following APIs to handle building or tearing down that list. -* fpga_bridge_get_to_list() — Get a ref of an FPGA bridge, add it to a +* fpga_bridge_get_to_list() - Get a ref of an FPGA bridge, add it to a list -* of_fpga_bridge_get_to_list() — Get a ref of an FPGA bridge, add it to a +* of_fpga_bridge_get_to_list() - Get a ref of an FPGA bridge, add it to a list, given a device node -* fpga_bridges_put() — Given a list of bridges, put them +* fpga_bridges_put() - Given a list of bridges, put them .. kernel-doc:: include/linux/fpga/fpga-region.h :functions: fpga_region -- cgit v1.2.3 From 580e3137318edb39d2c6efa5dad51e3fbd7e2536 Mon Sep 17 00:00:00 2001 From: Tom Rix Date: Wed, 19 May 2021 09:30:56 -0700 Subject: fpga: fix spelling mistakes Run the fpga subsystem through aspell. Signed-off-by: Tom Rix Reviewed-by: Fernando Pacheco Signed-off-by: Moritz Fischer --- Documentation/fpga/dfl.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/fpga/dfl.rst b/Documentation/fpga/dfl.rst index 75df90d1e54c..ef9eec71f6f3 100644 --- a/Documentation/fpga/dfl.rst +++ b/Documentation/fpga/dfl.rst @@ -10,7 +10,7 @@ Authors: - Xu Yilun The Device Feature List (DFL) FPGA framework (and drivers according to -this framework) hides the very details of low layer hardwares and provides +this framework) hides the very details of low layer hardware and provides unified interfaces to userspace. Applications could use these interfaces to configure, enumerate, open and access FPGA accelerators on platforms which implement the DFL in the device memory. Besides this, the DFL framework @@ -205,7 +205,7 @@ given Device Feature Lists and create platform devices for feature devices also abstracts operations for the private features and exposes common ops to feature device drivers. -The FPGA DFL Device could be different hardwares, e.g. PCIe device, platform +The FPGA DFL Device could be different hardware, e.g. PCIe device, platform device and etc. Its driver module is always loaded first once the device is created by the system. This driver plays an infrastructural role in the driver architecture. It locates the DFLs in the device memory, handles them -- cgit v1.2.3 From 213ad73d06073b197a02476db3a4998e219ddb06 Mon Sep 17 00:00:00 2001 From: Wei Wang Date: Wed, 21 Jul 2021 10:27:38 -0700 Subject: tcp: disable TFO blackhole logic by default Multiple complaints have been raised from the TFO users on the internet stating that the TFO blackhole logic is too aggressive and gets falsely triggered too often. (e.g. https://blog.apnic.net/2021/07/05/tcp-fast-open-not-so-fast/) Considering that most middleboxes no longer drop TFO packets, we decide to disable the blackhole logic by setting /proc/sys/net/ipv4/tcp_fastopen_blackhole_timeout_set to 0 by default. Fixes: cf1ef3f0719b4 ("net/tcp_fastopen: Disable active side TFO in certain scenarios") Signed-off-by: Wei Wang Signed-off-by: Eric Dumazet Acked-by: Neal Cardwell Acked-by: Soheil Hassas Yeganeh Acked-by: Yuchung Cheng Signed-off-by: David S. Miller --- Documentation/networking/ip-sysctl.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/networking/ip-sysctl.rst b/Documentation/networking/ip-sysctl.rst index b3fa522e4cd9..316c7dfa9693 100644 --- a/Documentation/networking/ip-sysctl.rst +++ b/Documentation/networking/ip-sysctl.rst @@ -826,7 +826,7 @@ tcp_fastopen_blackhole_timeout_sec - INTEGER initial value when the blackhole issue goes away. 0 to disable the blackhole detection. - By default, it is set to 1hr. + By default, it is set to 0 (feature is disabled). tcp_fastopen_key - list of comma separated 32-digit hexadecimal INTEGERs The list consists of a primary key and an optional backup key. The -- cgit v1.2.3 From 9d05c1e00e1045d3651ede7f01a3eb2327be0fe5 Mon Sep 17 00:00:00 2001 From: Paul Kocialkowski Date: Mon, 19 Jul 2021 22:52:41 +0200 Subject: media: dt-bindings: media: rockchip-vpu: Add PX30 compatible The Rockchip PX30 SoC has a Hantro VPU that features a decoder (VDPU2) and an encoder (VEPU2). Suggested-by: Alex Bee Signed-off-by: Paul Kocialkowski Signed-off-by: Ezequiel Garcia Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab --- Documentation/devicetree/bindings/media/rockchip-vpu.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/media/rockchip-vpu.yaml b/Documentation/devicetree/bindings/media/rockchip-vpu.yaml index b88172a59de7..bacb60a34989 100644 --- a/Documentation/devicetree/bindings/media/rockchip-vpu.yaml +++ b/Documentation/devicetree/bindings/media/rockchip-vpu.yaml @@ -22,6 +22,7 @@ properties: - rockchip,rk3288-vpu - rockchip,rk3328-vpu - rockchip,rk3399-vpu + - rockchip,px30-vpu - items: - const: rockchip,rk3188-vpu - const: rockchip,rk3066-vpu -- cgit v1.2.3 From 724fae95889684377c85f85a0ddd7e9846d00752 Mon Sep 17 00:00:00 2001 From: Fabio Estevam Date: Mon, 31 May 2021 13:22:35 +0200 Subject: media: dt-bindings: adv7180: Introduce the 'reset-gpios' property Introduce the 'reset-gpios' property to describe the GPIO that connects to the ADV7180 reset pin. Signed-off-by: Fabio Estevam Acked-by: Rob Herring Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab --- Documentation/devicetree/bindings/media/i2c/adv7180.yaml | 3 +++ 1 file changed, 3 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/media/i2c/adv7180.yaml b/Documentation/devicetree/bindings/media/i2c/adv7180.yaml index 3ce4af143a3a..7b233212d0e6 100644 --- a/Documentation/devicetree/bindings/media/i2c/adv7180.yaml +++ b/Documentation/devicetree/bindings/media/i2c/adv7180.yaml @@ -35,6 +35,9 @@ properties: powerdown-gpios: maxItems: 1 + reset-gpios: + maxItems: 1 + port: $ref: /schemas/graph.yaml#/$defs/port-base unevaluatedProperties: false -- cgit v1.2.3 From 28d1e47694aff751cfb1d86a2f9701f0a22e5f1e Mon Sep 17 00:00:00 2001 From: Fabio Estevam Date: Fri, 4 Jun 2021 23:22:16 +0200 Subject: media: dt-bindings: adv7180: Introduce 'adv,force-bt656-4' property Captured NTSC video would be out of sync when using the adv7280 with the BT.656-4 protocol. Certain registers (0x04, 0x31, 0xE6) need to be configured properly to ensure BT.656-4 compatibility. Introduce the 'adv,force-bt656-4' property to allow the ADV7280 behavior to be consistent with the ADV7180, where BT.656-4 timing is used by default. Signed-off-by: Fabio Estevam Acked-by: Rob Herring Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab --- Documentation/devicetree/bindings/media/i2c/adv7180.yaml | 5 +++++ 1 file changed, 5 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/media/i2c/adv7180.yaml b/Documentation/devicetree/bindings/media/i2c/adv7180.yaml index 7b233212d0e6..c8d887eee3bb 100644 --- a/Documentation/devicetree/bindings/media/i2c/adv7180.yaml +++ b/Documentation/devicetree/bindings/media/i2c/adv7180.yaml @@ -38,6 +38,11 @@ properties: reset-gpios: maxItems: 1 + adv,force-bt656-4: + description: + Indicates that the output is a BT.656-4 compatible stream. + type: boolean + port: $ref: /schemas/graph.yaml#/$defs/port-base unevaluatedProperties: false -- cgit v1.2.3 From 474596fc749ca8c87520fbd3529ff89464a94430 Mon Sep 17 00:00:00 2001 From: Maxime Ripard Date: Wed, 21 Jul 2021 16:03:41 +0200 Subject: dt-bindings: display: simple-bridge: Add corpro,gm7123 compatible The corpro,gm7123 was in use in a DT but was never properly documented, let's add it. Cc: dri-devel@lists.freedesktop.org Reviewed-by: Laurent Pinchart Signed-off-by: Maxime Ripard Acked-by: Sam Ravnborg Link: https://patchwork.freedesktop.org/patch/msgid/20210721140424.725744-12-maxime@cerno.tech --- Documentation/devicetree/bindings/display/bridge/simple-bridge.yaml | 3 +++ 1 file changed, 3 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/bridge/simple-bridge.yaml b/Documentation/devicetree/bindings/display/bridge/simple-bridge.yaml index 6c7b577fd471..43cf4df9811a 100644 --- a/Documentation/devicetree/bindings/display/bridge/simple-bridge.yaml +++ b/Documentation/devicetree/bindings/display/bridge/simple-bridge.yaml @@ -22,6 +22,9 @@ properties: - ti,ths8134a - ti,ths8134b - const: ti,ths8134 + - items: + - const: corpro,gm7123 + - const: adi,adv7123 - enum: - adi,adv7123 - dumb-vga-dac -- cgit v1.2.3 From 7910c23d704794461aba7a72b07aae582496b781 Mon Sep 17 00:00:00 2001 From: Hans Verkuil Date: Mon, 28 Jun 2021 10:23:49 +0200 Subject: media: media/cec-core.rst: update adap_enable doc The description of adap_enable was out-of-date. Improve it so that it corresponds to what really happens. Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab --- Documentation/driver-api/media/cec-core.rst | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/driver-api/media/cec-core.rst b/Documentation/driver-api/media/cec-core.rst index 56345eae9a26..c6194ee81c41 100644 --- a/Documentation/driver-api/media/cec-core.rst +++ b/Documentation/driver-api/media/cec-core.rst @@ -130,9 +130,12 @@ To enable/disable the hardware:: int (*adap_enable)(struct cec_adapter *adap, bool enable); This callback enables or disables the CEC hardware. Enabling the CEC hardware -means powering it up in a state where no logical addresses are claimed. This -op assumes that the physical address (adap->phys_addr) is valid when enable is -true and will not change while the CEC adapter remains enabled. The initial +means powering it up in a state where no logical addresses are claimed. The +physical address will always be valid if CEC_CAP_NEEDS_HPD is set. If that +capability is not set, then the physical address can change while the CEC +hardware is enabled. CEC drivers should not set CEC_CAP_NEEDS_HPD unless +the hardware design requires that as this will make it impossible to wake +up displays that pull the HPD low when in standby mode. The initial state of the CEC adapter after calling cec_allocate_adapter() is disabled. Note that adap_enable must return 0 if enable is false. -- cgit v1.2.3 From 04d21cc278e0d308356a087ff2aadccd97442486 Mon Sep 17 00:00:00 2001 From: Robin Gong Date: Wed, 14 Jul 2021 18:20:50 +0800 Subject: dma: imx-sdma: add i.mx6ul compatible name Add i.mx6ul compatible name in binding doc. Signed-off-by: Robin Gong Reviewed-by: Rob Herring Signed-off-by: Shawn Guo --- Documentation/devicetree/bindings/dma/fsl-imx-sdma.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/dma/fsl-imx-sdma.txt b/Documentation/devicetree/bindings/dma/fsl-imx-sdma.txt index c9e97409e853..12c316ff4834 100644 --- a/Documentation/devicetree/bindings/dma/fsl-imx-sdma.txt +++ b/Documentation/devicetree/bindings/dma/fsl-imx-sdma.txt @@ -9,6 +9,7 @@ Required properties: "fsl,imx53-sdma" "fsl,imx6q-sdma" "fsl,imx7d-sdma" + "fsl,imx6ul-sdma" "fsl,imx8mq-sdma" "fsl,imx8mm-sdma" "fsl,imx8mn-sdma" -- cgit v1.2.3 From ffd1e072594f319b94a0ca9f8602050ef6e404fc Mon Sep 17 00:00:00 2001 From: Christoph Niedermaier Date: Wed, 14 Jul 2021 22:22:52 +0200 Subject: dt-bindings: arm: fsl: Add DHCOM PicoITX and DHCOM DRC02 boards Add DH electronics DHCOM PicoITX and DHCOM DRC02 boards. The DHCOM DRC02 device can only house a SOM with iMX6S and not with iMX6DL, due to some thermal design consideration. But for compatible fsl,imx6dl is chosen, because fsl,imx6s isn't available, the iMX6S is basically a iMX6DL with one CPU core disabled and therefore the kernel discerns the iMX6S/iMX6DL automatically. Signed-off-by: Christoph Niedermaier Cc: linux-arm-kernel@lists.infradead.org Cc: linux-kernel@vger.kernel.org Cc: robh+dt@kernel.org Cc: Shawn Guo Cc: kernel@dh-electronics.com Cc: Fabio Estevam To: devicetree@vger.kernel.org Reviewed-by: Rob Herring Signed-off-by: Shawn Guo --- Documentation/devicetree/bindings/arm/fsl.yaml | 12 ++++++++++++ 1 file changed, 12 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml index 2793d161b24e..e2097011c4b0 100644 --- a/Documentation/devicetree/bindings/arm/fsl.yaml +++ b/Documentation/devicetree/bindings/arm/fsl.yaml @@ -420,6 +420,12 @@ properties: - const: dfi,fs700e-m60 - const: fsl,imx6dl + - description: i.MX6DL DHCOM PicoITX Board + items: + - const: dh,imx6dl-dhcom-picoitx + - const: dh,imx6dl-dhcom-som + - const: fsl,imx6dl + - description: i.MX6DL Gateworks Ventana Boards items: - enum: @@ -471,6 +477,12 @@ properties: - const: toradex,colibri_imx6dl # Colibri iMX6 Module - const: fsl,imx6dl + - description: i.MX6S DHCOM DRC02 Board + items: + - const: dh,imx6s-dhcom-drc02 + - const: dh,imx6s-dhcom-som + - const: fsl,imx6dl + - description: i.MX6SL based Boards items: - enum: -- cgit v1.2.3 From 9bd9e0de1cf5b89c4854be505ac0a418ddcc01bf Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Fri, 23 Jul 2021 09:40:06 +0200 Subject: mfd: hi6421-spmi-pmic: move driver from staging This driver is ready for mainstream. So, move it out of staging. Acked-by: Lee Jones Signed-off-by: Mauro Carvalho Chehab Link: https://lore.kernel.org/r/dd150f3ffa19c2dda0171f7dbe1dd63cce2a7af5.1627025657.git.mchehab+huawei@kernel.org Signed-off-by: Greg Kroah-Hartman --- .../bindings/mfd/hisilicon,hi6421-spmi-pmic.yaml | 136 +++++++++++++++++++++ 1 file changed, 136 insertions(+) create mode 100644 Documentation/devicetree/bindings/mfd/hisilicon,hi6421-spmi-pmic.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mfd/hisilicon,hi6421-spmi-pmic.yaml b/Documentation/devicetree/bindings/mfd/hisilicon,hi6421-spmi-pmic.yaml new file mode 100644 index 000000000000..cedf9d99a34b --- /dev/null +++ b/Documentation/devicetree/bindings/mfd/hisilicon,hi6421-spmi-pmic.yaml @@ -0,0 +1,136 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mfd/hisilicon,hi6421-spmi-pmic.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: HiSilicon 6421v600 SPMI PMIC + +maintainers: + - Mauro Carvalho Chehab + +description: | + HiSilicon 6421v600 should be connected inside a MIPI System Power Management + (SPMI) bus. It provides interrupts and power supply. + + The GPIO and interrupt settings are represented as part of the top-level PMIC + node. + + The SPMI controller part is provided by + Documentation/devicetree/bindings/mfd/hisilicon,hi6421-spmi-pmic.yaml + +properties: + $nodename: + pattern: "pmic@[0-9a-f]" + + compatible: + const: hisilicon,hi6421v600-spmi + + reg: + maxItems: 1 + + '#interrupt-cells': + const: 2 + + interrupt-controller: true + + interrupts: true + + regulators: + type: object + + additionalProperties: false + + properties: + '#address-cells': + const: 1 + + '#size-cells': + const: 0 + + patternProperties: + '^(ldo|LDO)[0-9]+$': + type: object + + $ref: "/schemas/regulator/regulator.yaml#" + + unevaluatedProperties: false + +required: + - compatible + - reg + - regulators + +additionalProperties: false + +examples: + - | + + pmic: pmic@0 { + compatible = "hisilicon,hi6421v600-spmi"; + reg = <0 0>; + + #interrupt-cells = <2>; + interrupt-controller; + interrupt-parent = <&gpio28>; + interrupts = <0 0>; + + regulators { + #address-cells = <1>; + #size-cells = <0>; + + ldo3: LDO3 { + regulator-name = "ldo3"; + regulator-min-microvolt = <1500000>; + regulator-max-microvolt = <2000000>; + regulator-boot-on; + }; + + ldo4: LDO4 { + regulator-name = "ldo4"; + regulator-min-microvolt = <1725000>; + regulator-max-microvolt = <1900000>; + regulator-boot-on; + }; + + ldo9: LDO9 { + regulator-name = "ldo9"; + regulator-min-microvolt = <1750000>; + regulator-max-microvolt = <3300000>; + regulator-boot-on; + }; + + ldo15: LDO15 { + regulator-name = "ldo15"; + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <3000000>; + regulator-always-on; + }; + + ldo16: LDO16 { + regulator-name = "ldo16"; + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <3000000>; + regulator-boot-on; + }; + + ldo17: LDO17 { + regulator-name = "ldo17"; + regulator-min-microvolt = <2500000>; + regulator-max-microvolt = <3300000>; + }; + + ldo33: LDO33 { + regulator-name = "ldo33"; + regulator-min-microvolt = <2500000>; + regulator-max-microvolt = <3300000>; + regulator-boot-on; + }; + + ldo34: LDO34 { + regulator-name = "ldo34"; + regulator-min-microvolt = <2600000>; + regulator-max-microvolt = <3300000>; + }; + }; + }; -- cgit v1.2.3 From d475653672b730a30bd1391f68c98f450afaf725 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?N=C3=ADcolas=20F=2E=20R=2E=20A=2E=20Prado?= Date: Thu, 10 Jun 2021 14:56:13 -0300 Subject: dt-bindings: clk: Convert rockchip,rk3399-cru to DT schema MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Convert the rockchip,rk3399-cru binding to DT schema format. Tested with ARCH=arm64 make dt_binding_check DT_SCHEMA_FILES=Documentation/devicetree/bindings/clock/rockchip,rk3399-cru.yaml ARCH=arm64 make dtbs_check DT_SCHEMA_FILES=Documentation/devicetree/bindings/clock/rockchip,rk3399-cru.yaml Signed-off-by: Nícolas F. R. A. Prado Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20210610175613.167601-1-nfraprado@collabora.com Signed-off-by: Heiko Stuebner --- .../bindings/clock/rockchip,rk3399-cru.txt | 68 ---------------- .../bindings/clock/rockchip,rk3399-cru.yaml | 92 ++++++++++++++++++++++ 2 files changed, 92 insertions(+), 68 deletions(-) delete mode 100644 Documentation/devicetree/bindings/clock/rockchip,rk3399-cru.txt create mode 100644 Documentation/devicetree/bindings/clock/rockchip,rk3399-cru.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/rockchip,rk3399-cru.txt b/Documentation/devicetree/bindings/clock/rockchip,rk3399-cru.txt deleted file mode 100644 index 3bc56fae90ac..000000000000 --- a/Documentation/devicetree/bindings/clock/rockchip,rk3399-cru.txt +++ /dev/null @@ -1,68 +0,0 @@ -* Rockchip RK3399 Clock and Reset Unit - -The RK3399 clock controller generates and supplies clock to various -controllers within the SoC and also implements a reset controller for SoC -peripherals. - -Required Properties: - -- compatible: PMU for CRU should be "rockchip,rk3399-pmucru" -- compatible: CRU should be "rockchip,rk3399-cru" -- reg: physical base address of the controller and length of memory mapped - region. -- #clock-cells: should be 1. -- #reset-cells: should be 1. - -Optional Properties: - -- rockchip,grf: phandle to the syscon managing the "general register files". - It is used for GRF muxes, if missing any muxes present in the GRF will not - be available. - -Each clock is assigned an identifier and client nodes can use this identifier -to specify the clock which they consume. All available clocks are defined as -preprocessor macros in the dt-bindings/clock/rk3399-cru.h headers and can be -used in device tree sources. Similar macros exist for the reset sources in -these files. - -External clocks: - -There are several clocks that are generated outside the SoC. It is expected -that they are defined using standard clock bindings with following -clock-output-names: - - "xin24m" - crystal input - required, - - "xin32k" - rtc clock - optional, - - "clkin_gmac" - external GMAC clock - optional, - - "clkin_i2s" - external I2S clock - optional, - - "pclkin_cif" - external ISP clock - optional, - - "clk_usbphy0_480m" - output clock of the pll in the usbphy0 - - "clk_usbphy1_480m" - output clock of the pll in the usbphy1 - -Example: Clock controller node: - - pmucru: pmu-clock-controller@ff750000 { - compatible = "rockchip,rk3399-pmucru"; - reg = <0x0 0xff750000 0x0 0x1000>; - #clock-cells = <1>; - #reset-cells = <1>; - }; - - cru: clock-controller@ff760000 { - compatible = "rockchip,rk3399-cru"; - reg = <0x0 0xff760000 0x0 0x1000>; - #clock-cells = <1>; - #reset-cells = <1>; - }; - -Example: UART controller node that consumes the clock generated by the clock - controller: - - uart0: serial@ff1a0000 { - compatible = "rockchip,rk3399-uart", "snps,dw-apb-uart"; - reg = <0x0 0xff180000 0x0 0x100>; - clocks = <&cru SCLK_UART0>, <&cru PCLK_UART0>; - clock-names = "baudclk", "apb_pclk"; - interrupts = ; - reg-shift = <2>; - reg-io-width = <4>; - }; diff --git a/Documentation/devicetree/bindings/clock/rockchip,rk3399-cru.yaml b/Documentation/devicetree/bindings/clock/rockchip,rk3399-cru.yaml new file mode 100644 index 000000000000..72b286a1beba --- /dev/null +++ b/Documentation/devicetree/bindings/clock/rockchip,rk3399-cru.yaml @@ -0,0 +1,92 @@ +# SPDX-License-Identifier: GPL-2.0-only +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/rockchip,rk3399-cru.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Rockchip RK3399 Clock and Reset Unit + +maintainers: + - Xing Zheng + - Heiko Stuebner + +description: | + The RK3399 clock controller generates and supplies clock to various + controllers within the SoC and also implements a reset controller for SoC + peripherals. + Each clock is assigned an identifier and client nodes can use this identifier + to specify the clock which they consume. All available clocks are defined as + preprocessor macros in the dt-bindings/clock/rk3399-cru.h headers and can be + used in device tree sources. Similar macros exist for the reset sources in + these files. + There are several clocks that are generated outside the SoC. It is expected + that they are defined using standard clock bindings with following + clock-output-names: + - "xin24m" - crystal input - required, + - "xin32k" - rtc clock - optional, + - "clkin_gmac" - external GMAC clock - optional, + - "clkin_i2s" - external I2S clock - optional, + - "pclkin_cif" - external ISP clock - optional, + - "clk_usbphy0_480m" - output clock of the pll in the usbphy0 + - "clk_usbphy1_480m" - output clock of the pll in the usbphy1 + +properties: + compatible: + enum: + - rockchip,rk3399-pmucru + - rockchip,rk3399-cru + + reg: + maxItems: 1 + + "#clock-cells": + const: 1 + + "#reset-cells": + const: 1 + + clocks: + minItems: 1 + + assigned-clocks: + minItems: 1 + maxItems: 64 + + assigned-clock-parents: + minItems: 1 + maxItems: 64 + + assigned-clock-rates: + minItems: 1 + maxItems: 64 + + rockchip,grf: + $ref: /schemas/types.yaml#/definitions/phandle + description: > + phandle to the syscon managing the "general register files". It is used + for GRF muxes, if missing any muxes present in the GRF will not be + available. + +required: + - compatible + - reg + - "#clock-cells" + - "#reset-cells" + +additionalProperties: false + +examples: + - | + pmucru: pmu-clock-controller@ff750000 { + compatible = "rockchip,rk3399-pmucru"; + reg = <0xff750000 0x1000>; + #clock-cells = <1>; + #reset-cells = <1>; + }; + - | + cru: clock-controller@ff760000 { + compatible = "rockchip,rk3399-cru"; + reg = <0xff760000 0x1000>; + #clock-cells = <1>; + #reset-cells = <1>; + }; -- cgit v1.2.3 From c18c36dc75fefa8e1672d3ae2d565a9c7136d38d Mon Sep 17 00:00:00 2001 From: Maxime Ripard Date: Tue, 20 Jul 2021 16:35:44 +0200 Subject: Documentation: gpu: Mention the requirements for new properties New KMS properties come with a bunch of requirements to avoid each driver from running their own, inconsistent, set of properties, eventually leading to issues like property conflicts, inconsistencies between drivers and semantics, etc. Let's document what we expect. Acked-by: Dave Airlie Reviewed-by: Pekka Paalanen Reviewed-by: Daniel Vetter Signed-off-by: Maxime Ripard Link: https://patchwork.freedesktop.org/patch/msgid/20210720143544.571760-1-maxime@cerno.tech --- Documentation/gpu/drm-kms.rst | 29 +++++++++++++++++++++++++++++ 1 file changed, 29 insertions(+) (limited to 'Documentation') diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst index 87e5023e3f55..12e25119e563 100644 --- a/Documentation/gpu/drm-kms.rst +++ b/Documentation/gpu/drm-kms.rst @@ -463,6 +463,35 @@ KMS Properties This section of the documentation is primarily aimed at user-space developers. For the driver APIs, see the other sections. +Requirements +------------ + +KMS drivers might need to add extra properties to support new features. Each +new property introduced in a driver needs to meet a few requirements, in +addition to the one mentioned above: + +* It must be standardized, documenting: + + * The full, exact, name string; + * If the property is an enum, all the valid value name strings; + * What values are accepted, and what these values mean; + * What the property does and how it can be used; + * How the property might interact with other, existing properties. + +* It must provide a generic helper in the core code to register that + property on the object it attaches to. + +* Its content must be decoded by the core and provided in the object's + associated state structure. That includes anything drivers might want + to precompute, like struct drm_clip_rect for planes. + +* Its initial state must match the behavior prior to the property + introduction. This might be a fixed value matching what the hardware + does, or it may be inherited from the state the firmware left the + system in during boot. + +* An IGT test must be submitted where reasonable. + Property Types and Blob Property Support ---------------------------------------- -- cgit v1.2.3 From 1e3bac71c5053c99d438771fc9fa5082ae5d90aa Mon Sep 17 00:00:00 2001 From: "Steven Rostedt (VMware)" Date: Wed, 21 Jul 2021 11:00:53 -0400 Subject: tracing/histogram: Rename "cpu" to "common_cpu" Currently the histogram logic allows the user to write "cpu" in as an event field, and it will record the CPU that the event happened on. The problem with this is that there's a lot of events that have "cpu" as a real field, and using "cpu" as the CPU it ran on, makes it impossible to run histograms on the "cpu" field of events. For example, if I want to have a histogram on the count of the workqueue_queue_work event on its cpu field, running: ># echo 'hist:keys=cpu' > events/workqueue/workqueue_queue_work/trigger Gives a misleading and wrong result. Change the command to "common_cpu" as no event should have "common_*" fields as that's a reserved name for fields used by all events. And this makes sense here as common_cpu would be a field used by all events. Now we can even do: ># echo 'hist:keys=common_cpu,cpu if cpu < 100' > events/workqueue/workqueue_queue_work/trigger ># cat events/workqueue/workqueue_queue_work/hist # event histogram # # trigger info: hist:keys=common_cpu,cpu:vals=hitcount:sort=hitcount:size=2048 if cpu < 100 [active] # { common_cpu: 0, cpu: 2 } hitcount: 1 { common_cpu: 0, cpu: 4 } hitcount: 1 { common_cpu: 7, cpu: 7 } hitcount: 1 { common_cpu: 0, cpu: 7 } hitcount: 1 { common_cpu: 0, cpu: 1 } hitcount: 1 { common_cpu: 0, cpu: 6 } hitcount: 2 { common_cpu: 0, cpu: 5 } hitcount: 2 { common_cpu: 1, cpu: 1 } hitcount: 4 { common_cpu: 6, cpu: 6 } hitcount: 4 { common_cpu: 5, cpu: 5 } hitcount: 14 { common_cpu: 4, cpu: 4 } hitcount: 26 { common_cpu: 0, cpu: 0 } hitcount: 39 { common_cpu: 2, cpu: 2 } hitcount: 184 Now for backward compatibility, I added a trick. If "cpu" is used, and the field is not found, it will fall back to "common_cpu" and work as it did before. This way, it will still work for old programs that use "cpu" to get the actual CPU, but if the event has a "cpu" as a field, it will get that event's "cpu" field, which is probably what it wants anyway. I updated the tracefs/README to include documentation about both the common_timestamp and the common_cpu. This way, if that text is present in the README, then an application can know that common_cpu is supported over just plain "cpu". Link: https://lkml.kernel.org/r/20210721110053.26b4f641@oasis.local.home Cc: Namhyung Kim Cc: Ingo Molnar Cc: Andrew Morton Cc: stable@vger.kernel.org Fixes: 8b7622bf94a44 ("tracing: Add cpu field for hist triggers") Reviewed-by: Tom Zanussi Reviewed-by: Masami Hiramatsu Signed-off-by: Steven Rostedt (VMware) --- Documentation/trace/histogram.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/trace/histogram.rst b/Documentation/trace/histogram.rst index b71e09f745c3..f99be8062bc8 100644 --- a/Documentation/trace/histogram.rst +++ b/Documentation/trace/histogram.rst @@ -191,7 +191,7 @@ Documentation written by Tom Zanussi with the event, in nanoseconds. May be modified by .usecs to have timestamps interpreted as microseconds. - cpu int the cpu on which the event occurred. + common_cpu int the cpu on which the event occurred. ====================== ==== ======================================= Extended error information -- cgit v1.2.3 From 832e6e3e9d498dea53f03e1e472779dcf4121689 Mon Sep 17 00:00:00 2001 From: Konrad Dybcio Date: Thu, 24 Jun 2021 21:17:40 +0200 Subject: dt-bindings: pinctrl: qcom: Add bindings for MDM9607 Document the newly added MDM9607 pinctrl driver. Signed-off-by: Konrad Dybcio Reviewed-by: Rob Herring Reviewed-by: Bjorn Andersson Link: https://lore.kernel.org/r/20210624191743.617073-1-konrad.dybcio@somainline.org Signed-off-by: Linus Walleij --- .../bindings/pinctrl/qcom,mdm9607-pinctrl.yaml | 133 +++++++++++++++++++++ 1 file changed, 133 insertions(+) create mode 100644 Documentation/devicetree/bindings/pinctrl/qcom,mdm9607-pinctrl.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,mdm9607-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,mdm9607-pinctrl.yaml new file mode 100644 index 000000000000..3b02dc6626ed --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/qcom,mdm9607-pinctrl.yaml @@ -0,0 +1,133 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pinctrl/qcom,mdm9607-pinctrl.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Technologies, Inc. MDM9607 TLMM block + +maintainers: + - Konrad Dybcio + +description: | + This binding describes the Top Level Mode Multiplexer block found in the + MDM9607 platform. + +allOf: + - $ref: /schemas/pinctrl/qcom,tlmm-common.yaml# + +properties: + compatible: + const: qcom,mdm9607-tlmm + + reg: + maxItems: 1 + + interrupts: true + interrupt-controller: true + '#interrupt-cells': true + gpio-controller: true + gpio-reserved-ranges: true + '#gpio-cells': true + gpio-ranges: true + wakeup-parent: true + +required: + - compatible + - reg + +additionalProperties: false + +patternProperties: + '-state$': + oneOf: + - $ref: "#/$defs/qcom-mdm9607-tlmm-state" + - patternProperties: + ".*": + $ref: "#/$defs/qcom-mdm9607-tlmm-state" + +'$defs': + qcom-mdm9607-tlmm-state: + type: object + description: + Pinctrl node's client devices use subnodes for desired pin configuration. + Client device subnodes use below standard properties. + $ref: "qcom,tlmm-common.yaml#/$defs/qcom-tlmm-state" + + properties: + pins: + description: + List of gpio pins affected by the properties specified in this + subnode. + items: + oneOf: + - pattern: "^gpio([1-9]|[1-7][0-9]|80)$" + - enum: [ sdc1_clk, sdc1_cmd, sdc1_data, sdc2_clk, sdc2_cmd, + sdc2_data, qdsd_cmd, qdsd_data0, qdsd_data1, qdsd_data2, + qdsd_data3 ] + minItems: 1 + maxItems: 16 + + function: + description: + Specify the alternative function to be configured for the specified + pins. + + enum: [ adsp_ext, atest_bbrx0, atest_bbrx1, atest_char, atest_char0, + atest_char1, atest_char2, atest_char3, + atest_combodac_to_gpio_native, atest_gpsadc_dtest0_native, + atest_gpsadc_dtest1_native, atest_tsens, backlight_en_b, + bimc_dte0, bimc_dte1, blsp1_spi, blsp2_spi, blsp3_spi, + blsp_i2c1, blsp_i2c2, blsp_i2c3, blsp_i2c4, blsp_i2c5, + blsp_i2c6, blsp_spi1, blsp_spi2, blsp_spi3, blsp_spi4, + blsp_spi5, blsp_spi6, blsp_uart1, blsp_uart2, blsp_uart3, + blsp_uart4, blsp_uart5, blsp_uart6, blsp_uim1, blsp_uim2, + codec_int, codec_rst, coex_uart, cri_trng, cri_trng0, + cri_trng1, dbg_out, ebi0_wrcdc, ebi2_a, ebi2_a_d_8_b, + ebi2_lcd, ebi2_lcd_cs_n_b, ebi2_lcd_te_b, eth_irq, eth_rst, + gcc_gp1_clk_a, gcc_gp1_clk_b, gcc_gp2_clk_a, gcc_gp2_clk_b, + gcc_gp3_clk_a, gcc_gp3_clk_b, gcc_plltest, gcc_tlmm, gmac_mdio, + gpio, gsm0_tx, lcd_rst, ldo_en, ldo_update, m_voc, modem_tsync, + nav_ptp_pps_in_a, nav_ptp_pps_in_b, nav_tsync_out_a, + nav_tsync_out_b, pa_indicator, pbs0, pbs1, pbs2, + pri_mi2s_data0_a, pri_mi2s_data1_a, pri_mi2s_mclk_a, + pri_mi2s_sck_a, pri_mi2s_ws_a, prng_rosc, ptp_pps_out_a, + ptp_pps_out_b, pwr_crypto_enabled_a, pwr_crypto_enabled_b, + pwr_modem_enabled_a, pwr_modem_enabled_b, pwr_nav_enabled_a, + pwr_nav_enabled_b, qdss_cti_trig_in_a0, qdss_cti_trig_in_a1, + qdss_cti_trig_in_b0, qdss_cti_trig_in_b1, qdss_cti_trig_out_a0, + qdss_cti_trig_out_a1, qdss_cti_trig_out_b0, qdss_cti_trig_out_b1, + qdss_traceclk_a, qdss_traceclk_b, qdss_tracectl_a, + qdss_tracectl_b, qdss_tracedata_a, qdss_tracedata_b, rcm_marker1, + rcm_marker2, sd_write, sec_mi2s, sensor_en, sensor_int2, + sensor_int3, sensor_rst, ssbi1, ssbi2, touch_rst, ts_int, + uim1_clk, uim1_data, uim1_present, uim1_reset, uim2_clk, + uim2_data, uim2_present, uim2_reset, uim_batt, wlan_en1, ] + + bias-disable: true + bias-pull-down: true + bias-pull-up: true + drive-strength: true + input-enable: true + output-high: true + output-low: true + + required: + - pins + - function + + additionalProperties: false + +examples: + - | + #include + tlmm: pinctrl@1000000 { + compatible = "qcom,mdm9607-tlmm"; + reg = <0x01000000 0x300000>; + interrupts = ; + gpio-controller; + gpio-ranges = <&msmgpio 0 0 80>; + #gpio-cells = <2>; + interrupt-controller; + #interrupt-cells = <2>; + }; -- cgit v1.2.3 From baf8d6899b1e8906dc076ef26cc633e96a8bb0c3 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Marek=20Beh=C3=BAn?= Date: Mon, 19 Jul 2021 13:29:38 +0200 Subject: pinctrl: armada-37xx: Correct PWM pins definitions MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The PWM pins on North Bridge on Armada 37xx can be configured into PWM or GPIO functions. When in PWM function, each pin can also be configured to drive low on 0 and tri-state on 1 (LED mode). The current definitions handle this by declaring two pin groups for each pin: - group "pwmN" with functions "pwm" and "gpio" - group "ledN_od" ("od" for open drain) with functions "led" and "gpio" This is semantically incorrect. The correct definition for each pin should be one group with three functions: "pwm", "led" and "gpio". Change the "pwmN" groups to support "led" function. Remove "ledN_od" groups. This cannot break backwards compatibility with older device trees: no device tree uses it since there is no PWM driver for this SOC yet. Also "ledN_od" groups are not even documented. Fixes: b835d6953009 ("pinctrl: armada-37xx: swap polarity on LED group") Signed-off-by: Marek Behún Acked-by: Rob Herring Link: https://lore.kernel.org/r/20210719112938.27594-1-kabel@kernel.org Signed-off-by: Linus Walleij --- .../devicetree/bindings/pinctrl/marvell,armada-37xx-pinctrl.txt | 8 ++++---- 1 file changed, 4 insertions(+), 4 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 38dc56a57760..ecec514b3155 100644 --- a/Documentation/devicetree/bindings/pinctrl/marvell,armada-37xx-pinctrl.txt +++ b/Documentation/devicetree/bindings/pinctrl/marvell,armada-37xx-pinctrl.txt @@ -43,19 +43,19 @@ group emmc_nb group pwm0 - pin 11 (GPIO1-11) - - functions pwm, gpio + - functions pwm, led, gpio group pwm1 - pin 12 - - functions pwm, gpio + - functions pwm, led, gpio group pwm2 - pin 13 - - functions pwm, gpio + - functions pwm, led, gpio group pwm3 - pin 14 - - functions pwm, gpio + - functions pwm, led, gpio group pmic1 - pin 7 -- cgit v1.2.3 From 41af189bb38b2692ab5398222f54568719729198 Mon Sep 17 00:00:00 2001 From: Jacky Bai Date: Mon, 7 Jun 2021 14:10:40 +0800 Subject: dt-bindings: pinctrl: imx8ulp: Add pinctrl binding Add pinctrl binding doc for i.MX8ULP Signed-off-by: Jacky Bai Reviewed-by: Rob Herring Reviewed-by: Dong Aisheng Link: https://lore.kernel.org/r/20210607061041.2654568-1-ping.bai@nxp.com Signed-off-by: Linus Walleij --- .../bindings/pinctrl/fsl,imx8ulp-pinctrl.yaml | 79 ++++++++++++++++++++++ 1 file changed, 79 insertions(+) create mode 100644 Documentation/devicetree/bindings/pinctrl/fsl,imx8ulp-pinctrl.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pinctrl/fsl,imx8ulp-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/fsl,imx8ulp-pinctrl.yaml new file mode 100644 index 000000000000..86622c4f374b --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/fsl,imx8ulp-pinctrl.yaml @@ -0,0 +1,79 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pinctrl/fsl,imx8ulp-pinctrl.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Freescale IMX8ULP IOMUX Controller + +maintainers: + - Jacky Bai + +description: + Please refer to fsl,imx-pinctrl.txt and pinctrl-bindings.txt in this directory + for common binding part and usage. + +properties: + compatible: + const: fsl,imx8ulp-iomuxc1 + + reg: + maxItems: 1 + +# Client device subnode's properties +patternProperties: + 'grp$': + type: object + description: + Pinctrl node's client devices use subnodes for desired pin configuration. + Client device subnodes use below standard properties. + + properties: + fsl,pins: + description: + each entry consists of 5 integers and represents the mux and config + setting for one pin. The first 4 integers are specified using a PIN_FUNC_ID macro, which can + be found in . The last + integer CONFIG is the pad setting value like pull-up on this pin. Please + refer to i.MX8ULP Reference Manual for detailed CONFIG settings. + $ref: /schemas/types.yaml#/definitions/uint32-matrix + items: + items: + - description: | + "mux_config_reg" indicates the offset of mux register. + - description: | + "input_reg" indicates the offset of select input register. + - description: | + "mux_mode" indicates the mux value to be applied. + - description: | + "input_val" indicates the select input value to be applied. + - description: | + "pad_setting" indicates the pad configuration value to be applied. + + required: + - fsl,pins + + additionalProperties: false + +required: + - compatible + - reg + +additionalProperties: false + +examples: + # Pinmux controller node + - | + iomuxc: pinctrl@298c0000 { + compatible = "fsl,imx8ulp-iomuxc1"; + reg = <0x298c0000 0x10000>; + + pinctrl_lpuart5: lpuart5grp { + fsl,pins = + <0x0138 0x08F0 0x4 0x3 0x3>, + <0x013C 0x08EC 0x4 0x3 0x3>; + }; + }; + +... -- cgit v1.2.3 From ffdf4cecac07fd16459a82f605aeee8098e3161c Mon Sep 17 00:00:00 2001 From: Bhupesh Sharma Date: Tue, 29 Jun 2021 18:04:04 +0530 Subject: dt-bindings: pinctrl: qcom,pmic-gpio: Arrange compatibles alphabetically Arrange the compatibles inside qcom-pmic gpio device tree bindings alphabetically. While at it, also make some minor cosmetic changes to allow future compatible addition to the bindings simpler. Cc: Linus Walleij Cc: Bjorn Andersson Reviewed-by: Bjorn Andersson Acked-by: Rob Herring Signed-off-by: Bhupesh Sharma Link: https://lore.kernel.org/r/20210629123407.82561-2-bhupesh.sharma@linaro.org Signed-off-by: Linus Walleij --- .../devicetree/bindings/pinctrl/qcom,pmic-gpio.txt | 62 +++++++++++----------- 1 file changed, 31 insertions(+), 31 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.txt b/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.txt index 161216daf463..c9f02062774a 100644 --- a/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.txt +++ b/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.txt @@ -7,10 +7,21 @@ PMIC's from Qualcomm. Usage: required Value type: Definition: must be one of: + "qcom,pm660-gpio" + "qcom,pm660l-gpio" + "qcom,pm6150-gpio" + "qcom,pm6150l-gpio" + "qcom,pm7325-gpio" "qcom,pm8005-gpio" + "qcom,pm8008-gpio" "qcom,pm8018-gpio" "qcom,pm8038-gpio" "qcom,pm8058-gpio" + "qcom,pm8150-gpio" + "qcom,pm8150b-gpio" + "qcom,pm8350-gpio" + "qcom,pm8350b-gpio" + "qcom,pm8350c-gpio" "qcom,pm8916-gpio" "qcom,pm8917-gpio" "qcom,pm8921-gpio" @@ -22,21 +33,10 @@ PMIC's from Qualcomm. "qcom,pmi8950-gpio" "qcom,pmi8994-gpio" "qcom,pmi8998-gpio" - "qcom,pms405-gpio" - "qcom,pm660-gpio" - "qcom,pm660l-gpio" - "qcom,pm8150-gpio" - "qcom,pm8150b-gpio" - "qcom,pm8350-gpio" - "qcom,pm8350b-gpio" - "qcom,pm8350c-gpio" "qcom,pmk8350-gpio" - "qcom,pm7325-gpio" "qcom,pmr735a-gpio" "qcom,pmr735b-gpio" - "qcom,pm6150-gpio" - "qcom,pm6150l-gpio" - "qcom,pm8008-gpio" + "qcom,pms405-gpio" "qcom,pmx55-gpio" And must contain either "qcom,spmi-gpio" or "qcom,ssbi-gpio" @@ -98,35 +98,35 @@ to specify in a pin configuration subnode: Value type: Definition: List of gpio pins affected by the properties specified in this subnode. Valid pins are: - gpio1-gpio4 for pm8005 - gpio1-gpio6 for pm8018 + gpio1-gpio10 for pm6150 + gpio1-gpio12 for pm6150l + gpio1-gpio10 for pm7325 + gpio1-gpio4 for pm8005 + gpio1-gpio2 for pm8008 + gpio1-gpio6 for pm8018 gpio1-gpio12 for pm8038 gpio1-gpio40 for pm8058 - gpio1-gpio4 for pm8916 + gpio1-gpio10 for pm8150 (holes on gpio2, gpio5, gpio7 + and gpio8) + gpio1-gpio12 for pm8150b (holes on gpio3, gpio4, gpio7) + gpio1-gpio12 for pm8150l (hole on gpio7) + gpio1-gpio10 for pm8350 + gpio1-gpio8 for pm8350b + gpio1-gpio9 for pm8350c + gpio1-gpio4 for pm8916 gpio1-gpio38 for pm8917 gpio1-gpio44 for pm8921 gpio1-gpio36 for pm8941 - gpio1-gpio8 for pm8950 (hole on gpio3) + gpio1-gpio8 for pm8950 (hole on gpio3) gpio1-gpio22 for pm8994 gpio1-gpio26 for pm8998 gpio1-gpio22 for pma8084 - gpio1-gpio2 for pmi8950 + gpio1-gpio2 for pmi8950 gpio1-gpio10 for pmi8994 + gpio1-gpio4 for pmk8350 + gpio1-gpio4 for pmr735a + gpio1-gpio4 for pmr735b gpio1-gpio12 for pms405 (holes on gpio1, gpio9 and gpio10) - gpio1-gpio10 for pm8150 (holes on gpio2, gpio5, gpio7 - and gpio8) - gpio1-gpio12 for pm8150b (holes on gpio3, gpio4, gpio7) - gpio1-gpio12 for pm8150l (hole on gpio7) - gpio1-gpio10 for pm8350 - gpio1-gpio8 for pm8350b - gpio1-gpio9 for pm8350c - gpio1-gpio4 for pmk8350 - gpio1-gpio10 for pm7325 - gpio1-gpio4 for pmr735a - gpio1-gpio4 for pmr735b - gpio1-gpio10 for pm6150 - gpio1-gpio12 for pm6150l - gpio1-gpio2 for pm8008 gpio1-gpio11 for pmx55 (holes on gpio3, gpio7, gpio10 and gpio11) -- cgit v1.2.3 From 0ac2c2aebf824809e37fe480b7bcf659f3f295d2 Mon Sep 17 00:00:00 2001 From: Bhupesh Sharma Date: Tue, 29 Jun 2021 18:04:05 +0530 Subject: dt-bindings: pinctrl: qcom,pmic-gpio: Add compatible for SA8155p-adp Add pmic-gpio compatible string for pmm8155au pmic found on the SA8155p-adp board. Cc: Linus Walleij Cc: Bjorn Andersson Reviewed-by: Bjorn Andersson Acked-by: Rob Herring Signed-off-by: Bhupesh Sharma Link: https://lore.kernel.org/r/20210629123407.82561-3-bhupesh.sharma@linaro.org 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 c9f02062774a..261a1d114253 100644 --- a/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.txt +++ b/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.txt @@ -34,6 +34,7 @@ PMIC's from Qualcomm. "qcom,pmi8994-gpio" "qcom,pmi8998-gpio" "qcom,pmk8350-gpio" + "qcom,pmm8155au-gpio" "qcom,pmr735a-gpio" "qcom,pmr735b-gpio" "qcom,pms405-gpio" @@ -124,6 +125,7 @@ to specify in a pin configuration subnode: gpio1-gpio2 for pmi8950 gpio1-gpio10 for pmi8994 gpio1-gpio4 for pmk8350 + gpio1-gpio10 for pmm8155au gpio1-gpio4 for pmr735a gpio1-gpio4 for pmr735b gpio1-gpio12 for pms405 (holes on gpio1, gpio9 and gpio10) -- cgit v1.2.3 From fbe280ee67c4e29e95a052b57328db055557a028 Mon Sep 17 00:00:00 2001 From: Rob Herring Date: Mon, 19 Jul 2021 15:49:02 -0600 Subject: dt-bindings: PCI: intel,lgm-pcie: Add reference to common schemas Add a reference to snps,dw-pcie.yaml (and indirectly pci-bus.yaml) schemas. With this, the common bus properties can be dropped from the schema. Cc: Bjorn Helgaas Cc: linux-pci@vger.kernel.org Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20210719220351.2662758-1-robh@kernel.org --- .../devicetree/bindings/pci/intel-gw-pcie.yaml | 36 +++------------------- 1 file changed, 5 insertions(+), 31 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pci/intel-gw-pcie.yaml b/Documentation/devicetree/bindings/pci/intel-gw-pcie.yaml index a1e2be737eec..54e2890ae631 100644 --- a/Documentation/devicetree/bindings/pci/intel-gw-pcie.yaml +++ b/Documentation/devicetree/bindings/pci/intel-gw-pcie.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: PCIe RC controller on Intel Gateway SoCs maintainers: - - Dilip Kota + - Rahul Tanwar select: properties: @@ -17,21 +17,15 @@ select: required: - compatible +allOf: + - $ref: /schemas/pci/snps,dw-pcie.yaml# + properties: compatible: items: - const: intel,lgm-pcie - const: snps,dw-pcie - device_type: - const: pci - - "#address-cells": - const: 3 - - "#size-cells": - const: 2 - reg: items: - description: Controller control and status registers. @@ -62,30 +56,13 @@ properties: reset-gpios: maxItems: 1 - linux,pci-domain: true - num-lanes: maximum: 2 - description: Number of lanes to use for this port. - - '#interrupt-cells': - const: 1 - - interrupt-map-mask: - description: Standard PCI IRQ mapping properties. - - interrupt-map: - description: Standard PCI IRQ mapping properties. max-link-speed: - description: Specify PCI Gen for link capability. - $ref: /schemas/types.yaml#/definitions/uint32 enum: [1, 2, 3, 4] default: 1 - bus-range: - description: Range of bus numbers associated with this controller. - reset-assert-ms: description: | Delay after asserting reset to the PCIe device. @@ -94,9 +71,6 @@ properties: required: - compatible - - device_type - - "#address-cells" - - "#size-cells" - reg - reg-names - ranges @@ -109,7 +83,7 @@ required: - interrupt-map - interrupt-map-mask -additionalProperties: false +unevaluatedProperties: false examples: - | -- cgit v1.2.3 From 17c1b16340f08607be8b0d4f1376e32ea6cca437 Mon Sep 17 00:00:00 2001 From: Nobuhiro Iwamatsu Date: Sat, 24 Jul 2021 07:14:19 +0900 Subject: dt-bindings: pci: Add DT binding for Toshiba Visconti PCIe controller This commit adds the Device Tree binding documentation that allows to describe the PCIe controller found in Toshiba Visconti SoCs. Signed-off-by: Nobuhiro Iwamatsu Link: https://lore.kernel.org/r/20210723221421.113575-2-nobuhiro1.iwamatsu@toshiba.co.jp [robh: reference snps,dw-pcie.yaml] Signed-off-by: Rob Herring --- .../devicetree/bindings/pci/snps,dw-pcie.yaml | 3 +- .../bindings/pci/toshiba,visconti-pcie.yaml | 110 +++++++++++++++++++++ 2 files changed, 112 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/pci/toshiba,visconti-pcie.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pci/snps,dw-pcie.yaml b/Documentation/devicetree/bindings/pci/snps,dw-pcie.yaml index a8c1db879fb9..66065ae178b1 100644 --- a/Documentation/devicetree/bindings/pci/snps,dw-pcie.yaml +++ b/Documentation/devicetree/bindings/pci/snps,dw-pcie.yaml @@ -34,7 +34,8 @@ properties: minItems: 2 maxItems: 5 items: - enum: [dbi, dbi2, config, atu, app, elbi, mgmt, ctrl, parf, cfg, link] + enum: [ dbi, dbi2, config, atu, app, elbi, mgmt, ctrl, parf, cfg, link, + ulreg, smu, mpu ] num-lanes: description: | diff --git a/Documentation/devicetree/bindings/pci/toshiba,visconti-pcie.yaml b/Documentation/devicetree/bindings/pci/toshiba,visconti-pcie.yaml new file mode 100644 index 000000000000..30b6396d83c8 --- /dev/null +++ b/Documentation/devicetree/bindings/pci/toshiba,visconti-pcie.yaml @@ -0,0 +1,110 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pci/toshiba,visconti-pcie.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Toshiba Visconti5 SoC PCIe Host Controller Device Tree Bindings + +maintainers: + - Nobuhiro Iwamatsu + +description: + Toshiba Visconti5 SoC PCIe host controller is based on the Synopsys DesignWare PCIe IP. + +allOf: + - $ref: /schemas/pci/snps,dw-pcie.yaml# + +properties: + compatible: + const: toshiba,visconti-pcie + + reg: + items: + - description: Data Bus Interface (DBI) registers. + - description: PCIe configuration space region. + - description: Visconti specific additional registers. + - description: Visconti specific SMU registers + - description: Visconti specific memory protection unit registers (MPU) + + reg-names: + items: + - const: dbi + - const: config + - const: ulreg + - const: smu + - const: mpu + + interrupts: + maxItems: 1 + + clocks: + items: + - description: PCIe reference clock + - description: PCIe system clock + - description: Auxiliary clock + + clock-names: + items: + - const: ref + - const: core + - const: aux + + num-lanes: + const: 2 + +required: + - reg + - reg-names + - interrupts + - "#interrupt-cells" + - interrupt-map + - interrupt-map-mask + - num-lanes + - clocks + - clock-names + - max-link-speed + +unevaluatedProperties: false + +examples: + - | + #include + #include + + soc { + #address-cells = <2>; + #size-cells = <2>; + + pcie: pcie@28400000 { + compatible = "toshiba,visconti-pcie"; + reg = <0x0 0x28400000 0x0 0x00400000>, + <0x0 0x70000000 0x0 0x10000000>, + <0x0 0x28050000 0x0 0x00010000>, + <0x0 0x24200000 0x0 0x00002000>, + <0x0 0x24162000 0x0 0x00001000>; + reg-names = "dbi", "config", "ulreg", "smu", "mpu"; + device_type = "pci"; + bus-range = <0x00 0xff>; + num-lanes = <2>; + num-viewport = <8>; + + #address-cells = <3>; + #size-cells = <2>; + #interrupt-cells = <1>; + ranges = <0x81000000 0 0x40000000 0 0x40000000 0 0x00010000>, + <0x82000000 0 0x50000000 0 0x50000000 0 0x20000000>; + interrupts = ; + interrupt-names = "intr"; + interrupt-map-mask = <0 0 0 7>; + interrupt-map = + <0 0 0 1 &gic GIC_SPI 215 IRQ_TYPE_LEVEL_HIGH + 0 0 0 2 &gic GIC_SPI 215 IRQ_TYPE_LEVEL_HIGH + 0 0 0 3 &gic GIC_SPI 215 IRQ_TYPE_LEVEL_HIGH + 0 0 0 4 &gic GIC_SPI 215 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&extclk100mhz>, <&clk600mhz>, <&clk25mhz>; + clock-names = "ref", "core", "aux"; + max-link-speed = <2>; + }; + }; +... -- cgit v1.2.3 From e71e2ace5721a8b921dca18b045069e7bb411277 Mon Sep 17 00:00:00 2001 From: Peter Collingbourne Date: Fri, 23 Jul 2021 15:50:01 -0700 Subject: userfaultfd: do not untag user pointers Patch series "userfaultfd: do not untag user pointers", v5. If a user program uses userfaultfd on ranges of heap memory, it may end up passing a tagged pointer to the kernel in the range.start field of the UFFDIO_REGISTER ioctl. This can happen when using an MTE-capable allocator, or on Android if using the Tagged Pointers feature for MTE readiness [1]. When a fault subsequently occurs, the tag is stripped from the fault address returned to the application in the fault.address field of struct uffd_msg. However, from the application's perspective, the tagged address *is* the memory address, so if the application is unaware of memory tags, it may get confused by receiving an address that is, from its point of view, outside of the bounds of the allocation. We observed this behavior in the kselftest for userfaultfd [2] but other applications could have the same problem. Address this by not untagging pointers passed to the userfaultfd ioctls. Instead, let the system call fail. Also change the kselftest to use mmap so that it doesn't encounter this problem. [1] https://source.android.com/devices/tech/debug/tagged-pointers [2] tools/testing/selftests/vm/userfaultfd.c This patch (of 2): Do not untag pointers passed to the userfaultfd ioctls. Instead, let the system call fail. This will provide an early indication of problems with tag-unaware userspace code instead of letting the code get confused later, and is consistent with how we decided to handle brk/mmap/mremap in commit dcde237319e6 ("mm: Avoid creating virtual address aliases in brk()/mmap()/mremap()"), as well as being consistent with the existing tagged address ABI documentation relating to how ioctl arguments are handled. The code change is a revert of commit 7d0325749a6c ("userfaultfd: untag user pointers") plus some fixups to some additional calls to validate_range that have appeared since then. [1] https://source.android.com/devices/tech/debug/tagged-pointers [2] tools/testing/selftests/vm/userfaultfd.c Link: https://lkml.kernel.org/r/20210714195437.118982-1-pcc@google.com Link: https://lkml.kernel.org/r/20210714195437.118982-2-pcc@google.com Link: https://linux-review.googlesource.com/id/I761aa9f0344454c482b83fcfcce547db0a25501b Fixes: 63f0c6037965 ("arm64: Introduce prctl() options to control the tagged user addresses ABI") Signed-off-by: Peter Collingbourne Reviewed-by: Andrey Konovalov Reviewed-by: Catalin Marinas Cc: Alistair Delva Cc: Andrea Arcangeli Cc: Dave Martin Cc: Evgenii Stepanov Cc: Lokesh Gidra Cc: Mitch Phillips Cc: Vincenzo Frascino Cc: Will Deacon Cc: William McVicker Cc: [5.4] Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/arm64/tagged-address-abi.rst | 26 ++++++++++++++++++-------- 1 file changed, 18 insertions(+), 8 deletions(-) (limited to 'Documentation') diff --git a/Documentation/arm64/tagged-address-abi.rst b/Documentation/arm64/tagged-address-abi.rst index 459e6b66ff68..0c9120ec58ae 100644 --- a/Documentation/arm64/tagged-address-abi.rst +++ b/Documentation/arm64/tagged-address-abi.rst @@ -45,14 +45,24 @@ how the user addresses are used by the kernel: 1. User addresses not accessed by the kernel but used for address space management (e.g. ``mprotect()``, ``madvise()``). The use of valid - tagged pointers in this context is allowed with the exception of - ``brk()``, ``mmap()`` and the ``new_address`` argument to - ``mremap()`` as these have the potential to alias with existing - user addresses. - - NOTE: This behaviour changed in v5.6 and so some earlier kernels may - incorrectly accept valid tagged pointers for the ``brk()``, - ``mmap()`` and ``mremap()`` system calls. + tagged pointers in this context is allowed with these exceptions: + + - ``brk()``, ``mmap()`` and the ``new_address`` argument to + ``mremap()`` as these have the potential to alias with existing + user addresses. + + NOTE: This behaviour changed in v5.6 and so some earlier kernels may + incorrectly accept valid tagged pointers for the ``brk()``, + ``mmap()`` and ``mremap()`` system calls. + + - The ``range.start``, ``start`` and ``dst`` arguments to the + ``UFFDIO_*`` ``ioctl()``s used on a file descriptor obtained from + ``userfaultfd()``, as fault addresses subsequently obtained by reading + the file descriptor will be untagged, which may otherwise confuse + tag-unaware programs. + + NOTE: This behaviour changed in v5.14 and so some earlier kernels may + incorrectly accept valid tagged pointers for this system call. 2. User addresses accessed by the kernel (e.g. ``write()``). This ABI relaxation is disabled by default and the application thread needs to -- cgit v1.2.3 From 39361c997dc781dc590a8e45107b288f3e3f27d7 Mon Sep 17 00:00:00 2001 From: Stephan Gerhold Date: Mon, 14 Jun 2021 18:31:48 +0200 Subject: dt-bindings: iio: accel: bma255: Fix interrupt type Bosch accelerometers similar to BMA255 are initially configured to emit an active-high interrupt signal. This is currently not re-configured in the bmc150-accel driver so the interrupt should most certainly be IRQ_TYPE_EDGE_RISING (or potentially IRQ_TYPE_LEVEL_HIGH). (Unless there is some kind of inverter installed on the board...) At the moment the bmc150-accel driver forcefully requests the IRQ using IRQF_TRIGGER_RISING, which means that the IRQ type is currently ignored in all existing device trees. Fixes: 6259551cf19b ("iio: accel: bmc150-accel: Add DT bindings") Cc: Linus Walleij Signed-off-by: Stephan Gerhold Reviewed-by: Linus Walleij Acked-by: Rob Herring Link: https://lore.kernel.org/r/20210614163150.7774-2-stephan@gerhold.net Signed-off-by: Jonathan Cameron --- Documentation/devicetree/bindings/iio/accel/bosch,bma255.yaml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/iio/accel/bosch,bma255.yaml b/Documentation/devicetree/bindings/iio/accel/bosch,bma255.yaml index e830d5295b92..b37ba902e4a2 100644 --- a/Documentation/devicetree/bindings/iio/accel/bosch,bma255.yaml +++ b/Documentation/devicetree/bindings/iio/accel/bosch,bma255.yaml @@ -38,7 +38,7 @@ properties: description: | The first interrupt listed must be the one connected to the INT1 pin, the second (optional) interrupt listed must be the one connected to the - INT2 pin (if available). + INT2 pin (if available). The type should be IRQ_TYPE_EDGE_RISING. mount-matrix: description: an optional 3x3 mounting rotation matrix. @@ -63,7 +63,7 @@ examples: reg = <0x08>; vddio-supply = <&vddio>; vdd-supply = <&vdd>; - interrupts = <57 IRQ_TYPE_EDGE_FALLING>; + interrupts = <57 IRQ_TYPE_EDGE_RISING>; }; }; - | -- cgit v1.2.3 From 562442d5a93b5b362e304b57accba43e40aad970 Mon Sep 17 00:00:00 2001 From: Stephan Gerhold Date: Mon, 14 Jun 2021 18:31:49 +0200 Subject: dt-bindings: iio: accel: bma255: Sort compatibles Similar to recent rework in the bmc150-accel driver, sort the compatible list in the DT schema so there is a consistent order. Signed-off-by: Stephan Gerhold Reviewed-by: Linus Walleij Acked-by: Rob Herring Link: https://lore.kernel.org/r/20210614163150.7774-3-stephan@gerhold.net Signed-off-by: Jonathan Cameron --- Documentation/devicetree/bindings/iio/accel/bosch,bma255.yaml | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/iio/accel/bosch,bma255.yaml b/Documentation/devicetree/bindings/iio/accel/bosch,bma255.yaml index b37ba902e4a2..f35c57b8105f 100644 --- a/Documentation/devicetree/bindings/iio/accel/bosch,bma255.yaml +++ b/Documentation/devicetree/bindings/iio/accel/bosch,bma255.yaml @@ -16,15 +16,15 @@ description: properties: compatible: enum: - - bosch,bmc150_accel - - bosch,bmi055_accel + - bosch,bma222 + - bosch,bma222e + - bosch,bma250e - bosch,bma253 - bosch,bma254 - bosch,bma255 - - bosch,bma250e - - bosch,bma222 - - bosch,bma222e - bosch,bma280 + - bosch,bmc150_accel + - bosch,bmi055_accel reg: maxItems: 1 -- cgit v1.2.3 From 7e6b78663c2fb96adaff613f2a25c177c7fbd3c4 Mon Sep 17 00:00:00 2001 From: Stephan Gerhold Date: Mon, 14 Jun 2021 18:31:50 +0200 Subject: dt-bindings: iio: accel: bma255: Merge bosch,bma180 schema In Linux the bma180 and bmc150-accel driver cover fairly similar chips from Bosch (just with minor register differences). For the DT schema, this does not make any difference: They both represent I2C/SPI devices, have one or two interrupts plus a vdd/vddio-supply. This means there is no need to duplicate the schema, we can just document the compatibles for both drivers in a single DT schema. Suggested-by: Jonathan Cameron Signed-off-by: Stephan Gerhold Reviewed-by: Linus Walleij Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20210614163150.7774-4-stephan@gerhold.net Signed-off-by: Jonathan Cameron --- .../bindings/iio/accel/bosch,bma180.yaml | 61 ---------------------- .../bindings/iio/accel/bosch,bma255.yaml | 9 ++++ 2 files changed, 9 insertions(+), 61 deletions(-) delete mode 100644 Documentation/devicetree/bindings/iio/accel/bosch,bma180.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/iio/accel/bosch,bma180.yaml b/Documentation/devicetree/bindings/iio/accel/bosch,bma180.yaml deleted file mode 100644 index a7e84089cc3d..000000000000 --- a/Documentation/devicetree/bindings/iio/accel/bosch,bma180.yaml +++ /dev/null @@ -1,61 +0,0 @@ -# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) -%YAML 1.2 ---- -$id: http://devicetree.org/schemas/iio/accel/bosch,bma180.yaml# -$schema: http://devicetree.org/meta-schemas/core.yaml# - -title: Bosch BMA023 / BMA150/ BMA180 / BMA250 / SMB380 triaxial accelerometers - -maintainers: - - Jonathan Cameron - -description: | - https://media.digikey.com/pdf/Data%20Sheets/Bosch/BMA150.pdf - http://omapworld.com/BMA180_111_1002839.pdf - http://ae-bst.resource.bosch.com/media/products/dokumente/bma250/bst-bma250-ds002-05.pdf - -properties: - compatible: - enum: - - bosch,bma023 - - bosch,bma150 - - bosch,bma180 - - bosch,bma250 - - bosch,smb380 - - reg: - maxItems: 1 - - vdd-supply: true - - vddio-supply: true - - interrupts: - minItems: 1 - maxItems: 2 - description: | - Type should be either IRQ_TYPE_LEVEL_HIGH or IRQ_TYPE_EDGE_RISING. - For the bma250 the first interrupt listed must be the one - connected to the INT1 pin, the second (optional) interrupt - listed must be the one connected to the INT2 pin. - -required: - - compatible - - reg - -additionalProperties: false - -examples: - - | - #include - i2c { - #address-cells = <1>; - #size-cells = <0>; - accel@40 { - compatible = "bosch,bma180"; - reg = <0x40>; - interrupt-parent = <&gpio6>; - interrupts = <18 (IRQ_TYPE_LEVEL_HIGH | IRQ_TYPE_EDGE_RISING)>; - }; - }; -... diff --git a/Documentation/devicetree/bindings/iio/accel/bosch,bma255.yaml b/Documentation/devicetree/bindings/iio/accel/bosch,bma255.yaml index f35c57b8105f..5b35856b1942 100644 --- a/Documentation/devicetree/bindings/iio/accel/bosch,bma255.yaml +++ b/Documentation/devicetree/bindings/iio/accel/bosch,bma255.yaml @@ -8,6 +8,7 @@ title: Bosch BMA255 and Similar Accelerometers maintainers: - Linus Walleij + - Stephan Gerhold description: 3 axis accelerometers with varying range and I2C or SPI @@ -16,6 +17,7 @@ description: properties: compatible: enum: + # bmc150-accel driver in Linux - bosch,bma222 - bosch,bma222e - bosch,bma250e @@ -26,6 +28,13 @@ properties: - bosch,bmc150_accel - bosch,bmi055_accel + # bma180 driver in Linux + - bosch,bma023 + - bosch,bma150 + - bosch,bma180 + - bosch,bma250 + - bosch,smb380 + reg: maxItems: 1 -- cgit v1.2.3 From 14a30238ecb8dcf52a9e2be514414e3ec443b536 Mon Sep 17 00:00:00 2001 From: Maxime Ripard Date: Wed, 21 Jul 2021 16:03:45 +0200 Subject: dt-bindings: iio: st: Remove wrong items length check The original bindings was listing the length of the interrupts as either 1 or 2, depending on the setup. This is also what is enforced by the top level schema. However, that is further constrained with an if clause that require exactly two interrupts, even though it might not make sense on those devices or in some setups. Let's remove the clause entirely. Cc: Denis Ciocca Cc: Lars-Peter Clausen Fixes: 0cd71145803d ("iio: st-sensors: Update ST Sensor bindings") Signed-off-by: Maxime Ripard Reviewed-by: Rob Herring Reviewed-by: Linus Walleij Link: https://lore.kernel.org/r/20210721140424.725744-16-maxime@cerno.tech Signed-off-by: Jonathan Cameron --- .../devicetree/bindings/iio/st,st-sensors.yaml | 41 ---------------------- 1 file changed, 41 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/iio/st,st-sensors.yaml b/Documentation/devicetree/bindings/iio/st,st-sensors.yaml index b2a1e42c56fa..71de5631ebae 100644 --- a/Documentation/devicetree/bindings/iio/st,st-sensors.yaml +++ b/Documentation/devicetree/bindings/iio/st,st-sensors.yaml @@ -152,47 +152,6 @@ allOf: maxItems: 1 st,drdy-int-pin: false - - if: - properties: - compatible: - enum: - # Two intertial interrupts i.e. accelerometer/gyro interrupts - - st,h3lis331dl-accel - - st,l3g4200d-gyro - - st,l3g4is-gyro - - st,l3gd20-gyro - - st,l3gd20h-gyro - - st,lis2de12 - - st,lis2dw12 - - st,lis2hh12 - - st,lis2dh12-accel - - st,lis331dl-accel - - st,lis331dlh-accel - - st,lis3de - - st,lis3dh-accel - - st,lis3dhh - - st,lis3mdl-magn - - st,lng2dm-accel - - st,lps331ap-press - - st,lsm303agr-accel - - st,lsm303dlh-accel - - st,lsm303dlhc-accel - - st,lsm303dlm-accel - - st,lsm330-accel - - st,lsm330-gyro - - st,lsm330d-accel - - st,lsm330d-gyro - - st,lsm330dl-accel - - st,lsm330dl-gyro - - st,lsm330dlc-accel - - st,lsm330dlc-gyro - - st,lsm9ds0-gyro - - st,lsm9ds1-magn - then: - properties: - interrupts: - maxItems: 2 - required: - compatible - reg -- cgit v1.2.3 From 49545357bf7e134a4012d4652c2df5f78f4485af Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Sat, 24 Jul 2021 23:49:27 +0200 Subject: nfc: constify nfc_llc_ops Neither the core nor the drivers modify the passed pointer to struct nfc_llc_ops, so make it a pointer to const for correctness and safety. Signed-off-by: Krzysztof Kozlowski Signed-off-by: David S. Miller --- Documentation/driver-api/nfc/nfc-hci.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/driver-api/nfc/nfc-hci.rst b/Documentation/driver-api/nfc/nfc-hci.rst index eb8a1a14e919..f10fe53aa9fe 100644 --- a/Documentation/driver-api/nfc/nfc-hci.rst +++ b/Documentation/driver-api/nfc/nfc-hci.rst @@ -181,7 +181,7 @@ xmit_from_hci(): The llc must be registered with nfc before it can be used. Do that by calling:: - nfc_llc_register(const char *name, struct nfc_llc_ops *ops); + nfc_llc_register(const char *name, const struct nfc_llc_ops *ops); Again, note that the llc does not handle the physical link. It is thus very easy to mix any physical link with any llc for a given chip driver. -- cgit v1.2.3 From 9c0e7ccd831b093d3b44aedd39bc89351c5a9388 Mon Sep 17 00:00:00 2001 From: Faiz Abbas Date: Mon, 10 May 2021 10:55:40 +0530 Subject: dt-bindings: net: can: Document transceiver implementation as phy Some transceivers need a configuration step (for example, pulling the standby or enable lines) for them to start sending messages. The transceiver can be implemented as a phy with the configuration done in the phy driver. The bit rate limitation can the be obtained by the driver using the phy node. Document the above implementation in the bosch mcan bindings. Link: https://lore.kernel.org/r/20210510052541.14168-2-a-govindraju@ti.com Signed-off-by: Faiz Abbas Signed-off-by: Aswath Govindraju Acked-by: Rob Herring Signed-off-by: Marc Kleine-Budde --- Documentation/devicetree/bindings/net/can/bosch,m_can.yaml | 3 +++ 1 file changed, 3 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/can/bosch,m_can.yaml b/Documentation/devicetree/bindings/net/can/bosch,m_can.yaml index f84e31348d80..a7b5807c5543 100644 --- a/Documentation/devicetree/bindings/net/can/bosch,m_can.yaml +++ b/Documentation/devicetree/bindings/net/can/bosch,m_can.yaml @@ -107,6 +107,9 @@ properties: can-transceiver: $ref: can-transceiver.yaml# + phys: + maxItems: 1 + required: - compatible - reg -- cgit v1.2.3 From 6474e67eabfbb6db138820e514f068c2884d1049 Mon Sep 17 00:00:00 2001 From: Oleksij Rempel Date: Wed, 14 Jul 2021 06:53:46 +0200 Subject: dt-bindings: display: simple: add some Logic Technologies and Multi-Inno panels MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Add Logictechno and Multi-Inno panels: - Logic Technologies LTTD800x480 L2RT 7" 800x480 TFT Resistive Touch Module - Logic Technologies LTTD800480070-L6WH-RT 7” 800x480 TFT Resistive Touch Module - Multi-Inno Technology Co.,Ltd MI1010AIT-1CP 10.1" 1280x800 LVDS IPS Cap Touch Mod. Signed-off-by: Oleksij Rempel Acked-by: Rob Herring Signed-off-by: Sam Ravnborg Link: https://patchwork.freedesktop.org/patch/msgid/20210714045349.10963-2-o.rempel@pengutronix.de --- Documentation/devicetree/bindings/display/panel/panel-simple.yaml | 6 ++++++ 1 file changed, 6 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml index 3624363938dd..7cf64ffb34aa 100644 --- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml +++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml @@ -208,8 +208,14 @@ properties: - logictechno,lt161010-2nhr # Logic Technologies LT170410-2WHC 10.1" 1280x800 IPS TFT Cap Touch Mod. - logictechno,lt170410-2whc + # Logic Technologies LTTD800x480 L2RT 7" 800x480 TFT Resistive Touch Module + - logictechno,lttd800480070-l2rt + # Logic Technologies LTTD800480070-L6WH-RT 7” 800x480 TFT Resistive Touch Module + - logictechno,lttd800480070-l6wh-rt # Mitsubishi "AA070MC01 7.0" WVGA TFT LCD panel - mitsubishi,aa070mc01-ca1 + # Multi-Inno Technology Co.,Ltd MI1010AIT-1CP 10.1" 1280x800 LVDS IPS Cap Touch Mod. + - multi-inno,mi1010ait-1cp # NEC LCD Technologies, Ltd. 12.1" WXGA (1280x800) LVDS TFT LCD panel - nec,nl12880bc20-05 # NEC LCD Technologies,Ltd. WQVGA TFT LCD panel -- cgit v1.2.3 From 1f49bf8b6aec78568478647f90367f57fc4f1644 Mon Sep 17 00:00:00 2001 From: Geert Uytterhoeven Date: Wed, 14 Jul 2021 16:51:22 +0200 Subject: dt-bindings: display: ssd1307fb: Convert to json-schema Convert the Solomon SSD1307 Framebuffer Device Tree binding documentation to json-schema. Fix the spelling of the "pwms" property. Document default values. Make properties with default values not required. Signed-off-by: Geert Uytterhoeven Reviewed-by: Rob Herring Signed-off-by: Sam Ravnborg Link: https://patchwork.freedesktop.org/patch/msgid/20210714145122.2530176-1-geert@linux-m68k.org --- .../bindings/display/solomon,ssd1307fb.yaml | 208 +++++++++++++++++++++ .../devicetree/bindings/display/ssd1307fb.txt | 60 ------ 2 files changed, 208 insertions(+), 60 deletions(-) create mode 100644 Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml delete mode 100644 Documentation/devicetree/bindings/display/ssd1307fb.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml b/Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml new file mode 100644 index 000000000000..2ed2a7d0ca2f --- /dev/null +++ b/Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml @@ -0,0 +1,208 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/solomon,ssd1307fb.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Solomon SSD1307 OLED Controller Framebuffer + +maintainers: + - Maxime Ripard + +properties: + compatible: + enum: + - solomon,ssd1305fb-i2c + - solomon,ssd1306fb-i2c + - solomon,ssd1307fb-i2c + - solomon,ssd1309fb-i2c + + reg: + maxItems: 1 + + pwms: + maxItems: 1 + + reset-gpios: + maxItems: 1 + + vbat-supply: + description: The supply for VBAT + + solomon,height: + $ref: /schemas/types.yaml#/definitions/uint32 + default: 16 + description: + Height in pixel of the screen driven by the controller + + solomon,width: + $ref: /schemas/types.yaml#/definitions/uint32 + default: 96 + description: + Width in pixel of the screen driven by the controller + + solomon,page-offset: + $ref: /schemas/types.yaml#/definitions/uint32 + default: 1 + description: + Offset of pages (band of 8 pixels) that the screen is mapped to + + solomon,segment-no-remap: + type: boolean + description: + Display needs normal (non-inverted) data column to segment mapping + + solomon,col-offset: + $ref: /schemas/types.yaml#/definitions/uint32 + default: 0 + description: + Offset of columns (COL/SEG) that the screen is mapped to + + solomon,com-seq: + type: boolean + description: + Display uses sequential COM pin configuration + + solomon,com-lrremap: + type: boolean + description: + Display uses left-right COM pin remap + + solomon,com-invdir: + type: boolean + description: + Display uses inverted COM pin scan direction + + solomon,com-offset: + $ref: /schemas/types.yaml#/definitions/uint32 + default: 0 + description: + Number of the COM pin wired to the first display line + + solomon,prechargep1: + $ref: /schemas/types.yaml#/definitions/uint32 + default: 2 + description: + Length of deselect period (phase 1) in clock cycles + + solomon,prechargep2: + $ref: /schemas/types.yaml#/definitions/uint32 + default: 2 + description: + Length of precharge period (phase 2) in clock cycles. This needs to be + the higher, the higher the capacitance of the OLED's pixels is. + + solomon,dclk-div: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 1 + maximum: 16 + description: + Clock divisor. The default value is controller-dependent. + + solomon,dclk-frq: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 15 + description: + Clock frequency, higher value means higher frequency. + The default value is controller-dependent. + + solomon,lookup-table: + $ref: /schemas/types.yaml#/definitions/uint8-array + maxItems: 4 + description: + 8 bit value array of current drive pulse widths for BANK0, and colors A, + B, and C. Each value in range of 31 to 63 for pulse widths of 32 to 64. + Color D is always width 64. + + solomon,area-color-enable: + type: boolean + description: + Display uses color mode + + solomon,low-power: + type: boolean + description: + Display runs in low power mode + +required: + - compatible + - reg + +allOf: + - if: + properties: + compatible: + contains: + const: solomon,ssd1305fb-i2c + then: + properties: + solomon,dclk-div: + default: 1 + solomon,dclk-frq: + default: 7 + + - if: + properties: + compatible: + contains: + const: solomon,ssd1306fb-i2c + then: + properties: + solomon,dclk-div: + default: 1 + solomon,dclk-frq: + default: 8 + + - if: + properties: + compatible: + contains: + const: solomon,ssd1307fb-i2c + then: + properties: + solomon,dclk-div: + default: 2 + solomon,dclk-frq: + default: 12 + required: + - pwms + + - if: + properties: + compatible: + contains: + const: solomon,ssd1309fb-i2c + then: + properties: + solomon,dclk-div: + default: 1 + solomon,dclk-frq: + default: 10 + +additionalProperties: false + +examples: + - | + i2c1 { + #address-cells = <1>; + #size-cells = <0>; + + ssd1307: oled@3c { + compatible = "solomon,ssd1307fb-i2c"; + reg = <0x3c>; + pwms = <&pwm 4 3000>; + reset-gpios = <&gpio2 7>; + }; + + ssd1306: oled@3d { + compatible = "solomon,ssd1306fb-i2c"; + reg = <0x3c>; + pwms = <&pwm 4 3000>; + reset-gpios = <&gpio2 7>; + solomon,com-lrremap; + solomon,com-invdir; + solomon,com-offset = <32>; + solomon,lookup-table = /bits/ 8 <0x3f 0x3f 0x3f 0x3f>; + }; + }; diff --git a/Documentation/devicetree/bindings/display/ssd1307fb.txt b/Documentation/devicetree/bindings/display/ssd1307fb.txt deleted file mode 100644 index 2dcb6d12d137..000000000000 --- a/Documentation/devicetree/bindings/display/ssd1307fb.txt +++ /dev/null @@ -1,60 +0,0 @@ -* Solomon SSD1307 Framebuffer Driver - -Required properties: - - compatible: Should be "solomon,fb-". The only supported bus for - now is i2c, and the supported chips are ssd1305, ssd1306, ssd1307 and - ssd1309. - - reg: Should contain address of the controller on the I2C bus. Most likely - 0x3c or 0x3d - - pwm: Should contain the pwm to use according to the OF device tree PWM - specification [0]. Only required for the ssd1307. - - solomon,height: Height in pixel of the screen driven by the controller - - solomon,width: Width in pixel of the screen driven by the controller - - solomon,page-offset: Offset of pages (band of 8 pixels) that the screen is - mapped to. - -Optional properties: - - reset-gpios: The GPIO used to reset the OLED display, if available. See - Documentation/devicetree/bindings/gpio/gpio.txt for details. - - vbat-supply: The supply for VBAT - - solomon,segment-no-remap: Display needs normal (non-inverted) data column - to segment mapping - - solomon,col-offset: Offset of columns (COL/SEG) that the screen is mapped to. - - solomon,com-seq: Display uses sequential COM pin configuration - - solomon,com-lrremap: Display uses left-right COM pin remap - - solomon,com-invdir: Display uses inverted COM pin scan direction - - solomon,com-offset: Number of the COM pin wired to the first display line - - solomon,prechargep1: Length of deselect period (phase 1) in clock cycles. - - solomon,prechargep2: Length of precharge period (phase 2) in clock cycles. - This needs to be the higher, the higher the capacitance - of the OLED's pixels is - - solomon,dclk-div: Clock divisor 1 to 16 - - solomon,dclk-frq: Clock frequency 0 to 15, higher value means higher - frequency - - solomon,lookup-table: 8 bit value array of current drive pulse widths for - BANK0, and colors A, B, and C. Each value in range - of 31 to 63 for pulse widths of 32 to 64. Color D - is always width 64. - - solomon,area-color-enable: Display uses color mode - - solomon,low-power. Display runs in low power mode - -[0]: Documentation/devicetree/bindings/pwm/pwm.txt - -Examples: -ssd1307: oled@3c { - compatible = "solomon,ssd1307fb-i2c"; - reg = <0x3c>; - pwms = <&pwm 4 3000>; - reset-gpios = <&gpio2 7>; -}; - -ssd1306: oled@3c { - compatible = "solomon,ssd1306fb-i2c"; - reg = <0x3c>; - pwms = <&pwm 4 3000>; - reset-gpios = <&gpio2 7>; - solomon,com-lrremap; - solomon,com-invdir; - solomon,com-offset = <32>; - solomon,lookup-table = /bits/ 8 <0x3f 0x3f 0x3f 0x3f>; -}; -- cgit v1.2.3 From a8124139845fecfa9c0100f580c03132f9774967 Mon Sep 17 00:00:00 2001 From: Heiko Stuebner Date: Wed, 10 Feb 2021 12:10:16 +0100 Subject: dt-bindings: display: rockchip-dsi: add optional #phy-cells property The Rockchip DSI controller on some SoCs also controls a bidrectional dphy, which would be connected to an Image Signal Processor as a phy in the rx configuration. So allow a #phy-cells property for the dsi controller. Signed-off-by: Heiko Stuebner Acked-by: Rob Herring Tested-by: Sebastian Fricke Acked-by: Helen Koike Link: https://patchwork.freedesktop.org/patch/msgid/20210210111020.2476369-3-heiko@sntech.de --- .../devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt b/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt index 151be3bba06f..39792f051d2d 100644 --- a/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt +++ b/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt @@ -23,6 +23,7 @@ Required properties: Optional properties: - phys: from general PHY binding: the phandle for the PHY device. - phy-names: Should be "dphy" if phys references an external phy. +- #phy-cells: Defined when used as ISP phy, should be 0. - power-domains: a phandle to mipi dsi power domain node. - resets: list of phandle + reset specifier pairs, as described in [3]. - reset-names: string reset name, must be "apb". -- cgit v1.2.3 From 79e93d0a74e7fb6bee5674b1d59a324c22a6338b Mon Sep 17 00:00:00 2001 From: Alyssa Rosenzweig Date: Sun, 25 Jul 2021 11:00:06 -0400 Subject: documentation: Update #nouveau IRC channel network Like many free software projects, Nouveau recently moved from Freenode to OFTC. Update the reference. v3: Add acks. Signed-off-by: Alyssa Rosenzweig Reviewed-by: Karol Herbst Cc: David Airlie Cc: Daniel Vetter Cc: linux-kernel@vger.kernel.org Signed-off-by: Karol Herbst Link: https://patchwork.freedesktop.org/patch/msgid/20210725150007.2818-1-alyssa@rosenzweig.io --- Documentation/driver-api/thermal/nouveau_thermal.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/driver-api/thermal/nouveau_thermal.rst b/Documentation/driver-api/thermal/nouveau_thermal.rst index 79ece266cf6d..aa10db6df309 100644 --- a/Documentation/driver-api/thermal/nouveau_thermal.rst +++ b/Documentation/driver-api/thermal/nouveau_thermal.rst @@ -90,7 +90,7 @@ Bug reports ----------- Thermal management on Nouveau is new and may not work on all cards. If you have -inquiries, please ping mupuf on IRC (#nouveau, freenode). +inquiries, please ping mupuf on IRC (#nouveau, OFTC). Bug reports should be filled on Freedesktop's bug tracker. Please follow https://nouveau.freedesktop.org/wiki/Bugs -- cgit v1.2.3 From 0a03801ca8bddfbf634d3b42d57a0864d6b3c1ec Mon Sep 17 00:00:00 2001 From: Hu Haowen Date: Sat, 24 Jul 2021 21:06:11 +0800 Subject: docs/zh_CN: reformat zh_CN/dev-tools/testing-overview Reorganise several long lines in order to satisfy the kernel coding style. Signed-off-by: Hu Haowen Reviewed-by: Yanteng Si Link: https://lore.kernel.org/r/20210724130611.4231-1-src.res@email.cn Signed-off-by: Jonathan Corbet --- .../translations/zh_CN/dev-tools/testing-overview.rst | 15 ++++++++------- 1 file changed, 8 insertions(+), 7 deletions(-) (limited to 'Documentation') diff --git a/Documentation/translations/zh_CN/dev-tools/testing-overview.rst b/Documentation/translations/zh_CN/dev-tools/testing-overview.rst index 8206d5b477e2..b7a1d13da6c6 100644 --- a/Documentation/translations/zh_CN/dev-tools/testing-overview.rst +++ b/Documentation/translations/zh_CN/dev-tools/testing-overview.rst @@ -70,13 +70,14 @@ kselftest也因此非常适合于全部功能的测试，因为这些功能会 确切函数或代码行。这有助于决定内核被测试了多少，或用来查找合适的测试 中没有覆盖到的极端情况。 -Documentation/translations/zh_CN/dev-tools/gcov.rst 是GCC的覆盖率测试工具，能用于获取内核的全局或每个模块的 -覆盖率。与KCOV不同的是，这个工具不记录每个任务的覆盖率。覆盖率数据可 -以通过debugfs读取，并通过常规的gcov工具进行解释。 - -Documentation/dev-tools/kcov.rst 是能够构建在内核之中，用于在每个任务的层面捕捉覆盖率的一 -个功能。因此，它对于模糊测试和关于代码执行期间信息的其它情况非常有用， -比如在一个单一系统调用里使用它就很有用。 +Documentation/translations/zh_CN/dev-tools/gcov.rst 是GCC的覆盖率测试 +工具，能用于获取内核的全局或每个模块的覆盖率。与KCOV不同的是，这个工具 +不记录每个任务的覆盖率。覆盖率数据可以通过debugfs读取，并通过常规的 +gcov工具进行解释。 + +Documentation/dev-tools/kcov.rst 是能够构建在内核之中，用于在每个任务 +的层面捕捉覆盖率的一个功能。因此，它对于模糊测试和关于代码执行期间信 +息的其它情况非常有用，比如在一个单一系统调用里使用它就很有用。 动态分析工具 ============ -- cgit v1.2.3 From 6ab0493dfc6255a99eb5f157e012eeafd75f5b56 Mon Sep 17 00:00:00 2001 From: Kees Cook Date: Fri, 23 Jul 2021 13:05:26 -0700 Subject: deprecated.rst: Include details on "no_hash_pointers" Linus decided a debug toggle for %p was tolerable, so update the %p deprecation documentation. Signed-off-by: Kees Cook Link: https://lore.kernel.org/r/20210723200526.3424128-1-keescook@chromium.org Signed-off-by: Jonathan Corbet --- Documentation/process/deprecated.rst | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/process/deprecated.rst b/Documentation/process/deprecated.rst index 9d83b8db8874..8ced754a5a0f 100644 --- a/Documentation/process/deprecated.rst +++ b/Documentation/process/deprecated.rst @@ -164,7 +164,9 @@ Paraphrasing Linus's current `guidance `_. +If you are debugging something where "%p" hashing is causing problems, +you can temporarily boot with the debug flag "`no_hash_pointers +`_". Variable Length Arrays (VLAs) ----------------------------- -- cgit v1.2.3 From 5b42d0bfb73d21bc31917c4fcab4def8a398aa0d Mon Sep 17 00:00:00 2001 From: Ioana Ciornei Date: Thu, 22 Jul 2021 13:03:53 +0300 Subject: docs: printk-formats: fix build warning Add an empty line after the '::' starting the code block so that the following lines are properly interpreted. Without this, the following build warnings are visible. Documentation/core-api/printk-formats.rst:136: WARNING: Unexpected indentation. Documentation/core-api/printk-formats.rst:137: WARNING: Block quote ends without a blank line; unexpected unindent. Fixes: 9294523e3768 ("module: add printk formats to add module build ID to stacktraces") Signed-off-by: Ioana Ciornei Reviewed-by: Stephen Boyd Acked-by: Petr Mladek Link: https://lore.kernel.org/r/20210722100356.635078-2-ciorneiioana@gmail.com Signed-off-by: Jonathan Corbet --- Documentation/core-api/printk-formats.rst | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/core-api/printk-formats.rst b/Documentation/core-api/printk-formats.rst index d941717a191b..e08bbe9b0cbf 100644 --- a/Documentation/core-api/printk-formats.rst +++ b/Documentation/core-api/printk-formats.rst @@ -130,6 +130,7 @@ printed after the symbol name with an extra ``b`` appended to the end of the specifier. :: + %pS versatile_init+0x0/0x110 [module_name] %pSb versatile_init+0x0/0x110 [module_name ed5019fdf5e53be37cb1ba7899292d7e143b259e] %pSRb versatile_init+0x9/0x110 [module_name ed5019fdf5e53be37cb1ba7899292d7e143b259e] -- cgit v1.2.3 From 8b9671643d2f6f567669aa54f15b8a2791d324d5 Mon Sep 17 00:00:00 2001 From: Ioana Ciornei Date: Thu, 22 Jul 2021 13:03:54 +0300 Subject: docs: kvm: fix build warnings Fix some small build warnings. The title underline was too short in some cases and a code block was not indented. Documentation/virt/kvm/api.rst:7216: WARNING: Title underline too short. Fixes: 6dba94035203 ("KVM: x86: Introduce KVM_GET_SREGS2 / KVM_SET_SREGS2") Signed-off-by: Ioana Ciornei Link: https://lore.kernel.org/r/20210722100356.635078-3-ciorneiioana@gmail.com Signed-off-by: Jonathan Corbet --- Documentation/virt/kvm/api.rst | 28 ++++++++++++++-------------- 1 file changed, 14 insertions(+), 14 deletions(-) (limited to 'Documentation') diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst index c7b165ca70b6..535ac0efd1b0 100644 --- a/Documentation/virt/kvm/api.rst +++ b/Documentation/virt/kvm/api.rst @@ -5077,7 +5077,7 @@ of bytes successfully copied is returned. If the call completes successfully then ``length`` is returned. 4.131 KVM_GET_SREGS2 ------------------- +-------------------- :Capability: KVM_CAP_SREGS2 :Architectures: x86 @@ -5090,17 +5090,17 @@ This ioctl (when supported) replaces the KVM_GET_SREGS. :: -struct kvm_sregs2 { - /* out (KVM_GET_SREGS2) / in (KVM_SET_SREGS2) */ - struct kvm_segment cs, ds, es, fs, gs, ss; - struct kvm_segment tr, ldt; - struct kvm_dtable gdt, idt; - __u64 cr0, cr2, cr3, cr4, cr8; - __u64 efer; - __u64 apic_base; - __u64 flags; - __u64 pdptrs[4]; -}; + struct kvm_sregs2 { + /* out (KVM_GET_SREGS2) / in (KVM_SET_SREGS2) */ + struct kvm_segment cs, ds, es, fs, gs, ss; + struct kvm_segment tr, ldt; + struct kvm_dtable gdt, idt; + __u64 cr0, cr2, cr3, cr4, cr8; + __u64 efer; + __u64 apic_base; + __u64 flags; + __u64 pdptrs[4]; + }; flags values for ``kvm_sregs2``: @@ -5110,7 +5110,7 @@ flags values for ``kvm_sregs2``: 4.132 KVM_SET_SREGS2 ------------------- +-------------------- :Capability: KVM_CAP_SREGS2 :Architectures: x86 @@ -7213,7 +7213,7 @@ supported in the host. A VMM can check whether the service is available to the guest on migration. 8.33 KVM_CAP_HYPERV_ENFORCE_CPUID ------------------------------ +--------------------------------- Architectures: x86 -- cgit v1.2.3 From a9fd134be7b94622fe487ae6db48bf9514ad1a53 Mon Sep 17 00:00:00 2001 From: Ioana Ciornei Date: Thu, 22 Jul 2021 13:03:55 +0300 Subject: docs: kvm: properly format code blocks and lists Add a '::' so that a code block is interpreted properly and also add a blank line before the start of a list. Fixes: fdc09ddd4064 ("KVM: stats: Add documentation for binary statistics interface") Signed-off-by: Ioana Ciornei Reviewed-by: Jing Zhang Link: https://lore.kernel.org/r/20210722100356.635078-4-ciorneiioana@gmail.com Signed-off-by: Jonathan Corbet --- Documentation/virt/kvm/api.rst | 4 ++++ 1 file changed, 4 insertions(+) (limited to 'Documentation') diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst index 535ac0efd1b0..c8225466f379 100644 --- a/Documentation/virt/kvm/api.rst +++ b/Documentation/virt/kvm/api.rst @@ -5201,6 +5201,7 @@ trailing ``'\0'``, is indicated by the ``name_size`` field in the header. The descriptors block is only needed to be read once for the lifetime of the file descriptor contains a sequence of ``struct kvm_stats_desc``, each followed by a string of size ``name_size``. +:: #define KVM_STATS_TYPE_SHIFT 0 #define KVM_STATS_TYPE_MASK (0xF << KVM_STATS_TYPE_SHIFT) @@ -5234,6 +5235,7 @@ by this descriptor. Its endianness is CPU native. The following flags are supported: Bits 0-3 of ``flags`` encode the type: + * ``KVM_STATS_TYPE_CUMULATIVE`` The statistics data is cumulative. The value of data can only be increased. Most of the counters used in KVM are of this type. @@ -5252,6 +5254,7 @@ Bits 0-3 of ``flags`` encode the type: The corresponding ``size`` field for this type is always 1. Bits 4-7 of ``flags`` encode the unit: + * ``KVM_STATS_UNIT_NONE`` There is no unit for the value of statistics data. This usually means that the value is a simple counter of an event. @@ -5266,6 +5269,7 @@ Bits 4-7 of ``flags`` encode the unit: Bits 8-11 of ``flags``, together with ``exponent``, encode the scale of the unit: + * ``KVM_STATS_BASE_POW10`` The scale is based on power of 10. It is used for measurement of time and CPU clock cycles. For example, an exponent of -9 can be used with -- cgit v1.2.3 From 662fa3d6099374c4615bf64d06895e3573b935b2 Mon Sep 17 00:00:00 2001 From: Ioana Ciornei Date: Thu, 22 Jul 2021 13:03:56 +0300 Subject: docs: networking: dpaa2: fix chapter title format Fix the DPAA2 DPIO driver chapter title by adding the necessary overline. Without this, the index page of the DPAA2 documentation doesn't display properly. Fixes: d8e516bac73f ("soc: fsl: dpio: Convert DPIO documentation to .rst") Signed-off-by: Ioana Ciornei Link: https://lore.kernel.org/r/20210722100356.635078-5-ciorneiioana@gmail.com Signed-off-by: Jonathan Corbet --- .../networking/device_drivers/ethernet/freescale/dpaa2/dpio-driver.rst | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/networking/device_drivers/ethernet/freescale/dpaa2/dpio-driver.rst b/Documentation/networking/device_drivers/ethernet/freescale/dpaa2/dpio-driver.rst index c50fd46631e0..e4ebfe62a183 100644 --- a/Documentation/networking/device_drivers/ethernet/freescale/dpaa2/dpio-driver.rst +++ b/Documentation/networking/device_drivers/ethernet/freescale/dpaa2/dpio-driver.rst @@ -1,5 +1,6 @@ .. include:: +=================================== DPAA2 DPIO (Data Path I/O) Overview =================================== -- cgit v1.2.3 From f3fd34fe0e71cb58ffa16d26fc887c6eb73fb1c0 Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Thu, 22 Jul 2021 11:50:01 +0200 Subject: docs: sound: kernel-api: writing-an-alsa-driver.rst: replace some characters MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The conversion tools used during DocBook/LaTeX/html/Markdown->ReST conversion and some cut-and-pasted text contain some characters that aren't easily reachable on standard keyboards and/or could cause troubles when parsed by the documentation build system. Replace the occurences of the following characters: - U+00a0 (' '): NO-BREAK SPACE as it can cause lines being truncated on PDF output Reviewed-by: Takashi Iwai Signed-off-by: Mauro Carvalho Chehab Link: https://lore.kernel.org/r/21abe5fa495a05ac1f998ed66184a77e19ac89cc.1626947264.git.mchehab+huawei@kernel.org Signed-off-by: Jonathan Corbet --- Documentation/sound/kernel-api/writing-an-alsa-driver.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/sound/kernel-api/writing-an-alsa-driver.rst b/Documentation/sound/kernel-api/writing-an-alsa-driver.rst index 01d59b8aea92..6da9c887a48b 100644 --- a/Documentation/sound/kernel-api/writing-an-alsa-driver.rst +++ b/Documentation/sound/kernel-api/writing-an-alsa-driver.rst @@ -3368,7 +3368,7 @@ This ensures that the device can be closed and the driver unloaded without losing data. This callback is optional. If you do not set ``drain`` in the struct -snd_rawmidi_ops structure, ALSA will simply wait for 50 milliseconds +snd_rawmidi_ops structure, ALSA will simply wait for 50 milliseconds instead. Miscellaneous Devices -- cgit v1.2.3 From dc9c31c3ffc803b5362ca9d6ff1426ccb738f77e Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Thu, 22 Jul 2021 11:50:02 +0200 Subject: docs: firmware-guide: acpi: dsd: graph.rst: replace some characters MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The conversion tools used during DocBook/LaTeX/html/Markdown->ReST conversion and some cut-and-pasted text contain some characters that aren't easily reachable on standard keyboards and/or could cause troubles when parsed by the documentation build system. Replace the occurences of the following characters: - U+00a0 (' '): NO-BREAK SPACE as it can cause lines being truncated on PDF output Acked-by: Rafael J. Wysocki Signed-off-by: Mauro Carvalho Chehab Link: https://lore.kernel.org/r/a65b04a5cf341cff02d4b514dd4889b4fa4f94b8.1626947264.git.mchehab+huawei@kernel.org Signed-off-by: Jonathan Corbet --- Documentation/firmware-guide/acpi/dsd/graph.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/firmware-guide/acpi/dsd/graph.rst b/Documentation/firmware-guide/acpi/dsd/graph.rst index 4341299aa937..0ced07cb1be3 100644 --- a/Documentation/firmware-guide/acpi/dsd/graph.rst +++ b/Documentation/firmware-guide/acpi/dsd/graph.rst @@ -159,7 +159,7 @@ References [2] Devicetree. https://www.devicetree.org, referenced 2016-10-03. -[3] Documentation/devicetree/bindings/graph.txt +[3] Documentation/devicetree/bindings/graph.txt [4] Device Properties UUID For _DSD. https://www.uefi.org/sites/default/files/resources/_DSD-device-properties-UUID.pdf, -- cgit v1.2.3 From b426d9d78efb39800dabaed447a0bfc959038930 Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Thu, 22 Jul 2021 11:50:03 +0200 Subject: docs: virt: kvm: api.rst: replace some characters MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The conversion tools used during DocBook/LaTeX/html/Markdown->ReST conversion and some cut-and-pasted text contain some characters that aren't easily reachable on standard keyboards and/or could cause troubles when parsed by the documentation build system. Replace the occurences of the following characters: - U+00a0 (' '): NO-BREAK SPACE as it can cause lines being truncated on PDF output Signed-off-by: Mauro Carvalho Chehab Link: https://lore.kernel.org/r/ff70cb42d63f3a1da66af1b21b8d038418ed5189.1626947264.git.mchehab+huawei@kernel.org Signed-off-by: Jonathan Corbet --- Documentation/virt/kvm/api.rst | 28 ++++++++++++++-------------- 1 file changed, 14 insertions(+), 14 deletions(-) (limited to 'Documentation') diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst index c8225466f379..7152268c580d 100644 --- a/Documentation/virt/kvm/api.rst +++ b/Documentation/virt/kvm/api.rst @@ -855,7 +855,7 @@ in-kernel irqchip (GIC), and for in-kernel irqchip can tell the GIC to use PPIs designated for specific cpus. The irq field is interpreted like this:: -  bits: | 31 ... 28 | 27 ... 24 | 23 ... 16 | 15 ... 0 | + bits: | 31 ... 28 | 27 ... 24 | 23 ... 16 | 15 ... 0 | field: | vcpu2_index | irq_type | vcpu_index | irq_id | The irq_type field has the following values: @@ -2149,10 +2149,10 @@ prior to calling the KVM_RUN ioctl. Errors: ====== ============================================================ -  ENOENT   no such register -  EINVAL   invalid register ID, or no such register or used with VMs in + ENOENT no such register + EINVAL invalid register ID, or no such register or used with VMs in protected virtualization mode on s390 -  EPERM    (arm64) register access not allowed before vcpu finalization + EPERM (arm64) register access not allowed before vcpu finalization ====== ============================================================ (These error codes are indicative only: do not rely on a specific error @@ -2590,10 +2590,10 @@ following id bit patterns:: Errors include: ======== ============================================================ -  ENOENT   no such register -  EINVAL   invalid register ID, or no such register or used with VMs in + ENOENT no such register + EINVAL invalid register ID, or no such register or used with VMs in protected virtualization mode on s390 -  EPERM    (arm64) register access not allowed before vcpu finalization + EPERM (arm64) register access not allowed before vcpu finalization ======== ============================================================ (These error codes are indicative only: do not rely on a specific error @@ -3112,13 +3112,13 @@ current state. "addr" is ignored. Errors: ====== ================================================================= -  EINVAL    the target is unknown, or the combination of features is invalid. -  ENOENT    a features bit specified is unknown. + EINVAL the target is unknown, or the combination of features is invalid. + ENOENT a features bit specified is unknown. ====== ================================================================= This tells KVM what type of CPU to present to the guest, and what -optional features it should have.  This will cause a reset of the cpu -registers to their initial values.  If this is not called, KVM_RUN will +optional features it should have. This will cause a reset of the cpu +registers to their initial values. If this is not called, KVM_RUN will return ENOEXEC for that vcpu. The initial values are defined as: @@ -3239,8 +3239,8 @@ VCPU matching underlying host. Errors: ===== ============================================================== -  E2BIG     the reg index list is too big to fit in the array specified by -             the user (the number required will be written into n). + E2BIG the reg index list is too big to fit in the array specified by + the user (the number required will be written into n). ===== ============================================================== :: @@ -3288,7 +3288,7 @@ specific device. ARM/arm64 divides the id field into two parts, a device id and an address type id specific to the individual device:: -  bits: | 63 ... 32 | 31 ... 16 | 15 ... 0 | + bits: | 63 ... 32 | 31 ... 16 | 15 ... 0 | field: | 0x00000000 | device id | addr type id | ARM/arm64 currently only require this when using the in-kernel GIC -- cgit v1.2.3 From ce48ee81a1930b2218bea23490adb6673c88bf70 Mon Sep 17 00:00:00 2001 From: "Fabio M. De Francesco" Date: Wed, 21 Jul 2021 21:02:50 +0200 Subject: admin-guide/hw-vuln: Rephrase a section of core-scheduling.rst Rephrase the "For MDS" section in core-scheduling.rst for the purpose of making it clearer what is meant by "kernel memory is still considered untrusted". Suggested-by: Vineeth Pillai Signed-off-by: Fabio M. De Francesco Reviewed-by: Joel Fernandes (Google) Link: https://lore.kernel.org/r/20210721190250.26095-1-fmdefrancesco@gmail.com Signed-off-by: Jonathan Corbet --- Documentation/admin-guide/hw-vuln/core-scheduling.rst | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/admin-guide/hw-vuln/core-scheduling.rst b/Documentation/admin-guide/hw-vuln/core-scheduling.rst index 7b410aef9c5c..0febe458597c 100644 --- a/Documentation/admin-guide/hw-vuln/core-scheduling.rst +++ b/Documentation/admin-guide/hw-vuln/core-scheduling.rst @@ -181,10 +181,12 @@ Open cross-HT issues that core scheduling does not solve -------------------------------------------------------- 1. For MDS ~~~~~~~~~~ -Core scheduling cannot protect against MDS attacks between an HT running in -user mode and another running in kernel mode. Even though both HTs run tasks -which trust each other, kernel memory is still considered untrusted. Such -attacks are possible for any combination of sibling CPU modes (host or guest mode). +Core scheduling cannot protect against MDS attacks between the siblings +running in user mode and the others running in kernel mode. Even though all +siblings run tasks which trust each other, when the kernel is executing +code on behalf of a task, it cannot trust the code running in the +sibling. Such attacks are possible for any combination of sibling CPU modes +(host or guest mode). 2. For L1TF ~~~~~~~~~~~ -- cgit v1.2.3 From d5caec394a78617cbc0eea0870da22aa019c346d Mon Sep 17 00:00:00 2001 From: Yang Xu Date: Wed, 23 Jun 2021 09:37:48 +0800 Subject: admin-guide/cputopology.rst: Remove non-existed cpu-hotplug.txt Since kernel commit ff58fa7f556c ("Documentation: Update CPU hotplug and move it to core-api"), cpu_hotplug.txt has been removed. We should update it in here. Signed-off-by: Yang Xu Link: https://lore.kernel.org/r/1624412269-13155-1-git-send-email-xuyang2018.jy@fujitsu.com Signed-off-by: Jonathan Corbet --- Documentation/admin-guide/cputopology.rst | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) (limited to 'Documentation') diff --git a/Documentation/admin-guide/cputopology.rst b/Documentation/admin-guide/cputopology.rst index 8632a1db36e4..b085dbac60a5 100644 --- a/Documentation/admin-guide/cputopology.rst +++ b/Documentation/admin-guide/cputopology.rst @@ -58,9 +58,9 @@ source for the output is in brackets ("[]"). [NR_CPUS-1] offline: CPUs that are not online because they have been - HOTPLUGGED off (see cpu-hotplug.txt) or exceed the limit - of CPUs allowed by the kernel configuration (kernel_max - above). [~cpu_online_mask + cpus >= NR_CPUS] + HOTPLUGGED off or exceed the limit of CPUs allowed by the + kernel configuration (kernel_max above). + [~cpu_online_mask + cpus >= NR_CPUS] online: CPUs that are online and being scheduled [cpu_online_mask] @@ -96,5 +96,5 @@ online.):: possible: 0-127 present: 0-3 -See cpu-hotplug.txt for the possible_cpus=NUM kernel start parameter -as well as more information on the various cpumasks. +See Documentation/core-api/cpu_hotplug.rst for the possible_cpus=NUM +kernel start parameter as well as more information on the various cpumasks. -- cgit v1.2.3 From 77167b966b7e671d8ab308b1e31ebfed97986402 Mon Sep 17 00:00:00 2001 From: Hannu Hartikainen Date: Wed, 7 Jul 2021 16:36:35 +0300 Subject: docs: submitting-patches: clarify the role of LKML The documentation previously stated that LKML should be used as *last resort*. However, scripts/get_maintainer.pl always suggests it and in a discussion about changing that[0] it turned out that LKML should in fact receive all patches. Update documentation to make it clear that all patches should be sent to LKML by default, in addition to any subsystem-specific lists. [0]: https://lore.kernel.org/lkml/19a701a8d5837088aa7d8ba594c228c0e040e747.camel@perches.com/ Signed-off-by: Hannu Hartikainen Link: https://lore.kernel.org/r/20210707133634.286840-1-hannu@hrtk.in Signed-off-by: Jonathan Corbet --- Documentation/process/submitting-patches.rst | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) (limited to 'Documentation') diff --git a/Documentation/process/submitting-patches.rst b/Documentation/process/submitting-patches.rst index 0852bcf73630..8ad6b93f91e6 100644 --- a/Documentation/process/submitting-patches.rst +++ b/Documentation/process/submitting-patches.rst @@ -216,11 +216,11 @@ cannot find a maintainer for the subsystem you are working on, Andrew Morton (akpm@linux-foundation.org) serves as a maintainer of last resort. You should also normally choose at least one mailing list to receive a copy -of your patch set. linux-kernel@vger.kernel.org functions as a list of -last resort, but the volume on that list has caused a number of developers -to tune it out. Look in the MAINTAINERS file for a subsystem-specific -list; your patch will probably get more attention there. Please do not -spam unrelated lists, though. +of your patch set. linux-kernel@vger.kernel.org should be used by default +for all patches, but the volume on that list has caused a number of +developers to tune it out. Look in the MAINTAINERS file for a +subsystem-specific list; your patch will probably get more attention there. +Please do not spam unrelated lists, though. Many kernel-related lists are hosted on vger.kernel.org; you can find a list of them at http://vger.kernel.org/vger-lists.html. There are -- cgit v1.2.3 From 4a52225d61017c0cb9133b624d5790bf86abf608 Mon Sep 17 00:00:00 2001 From: Hu Haowen Date: Tue, 8 Jun 2021 15:52:07 +0800 Subject: docs/zh_CN: add a translation for index The original file has added a former intro in commit b51208d41c6a4e7fc2f0 ("docs: Tweak the top-level Sphinx page") and hence update the Chinese version for it. Signed-off-by: Hu Haowen Link: https://lore.kernel.org/r/20210608075207.77812-1-src.res@email.cn Signed-off-by: Jonathan Corbet --- Documentation/translations/zh_CN/index.rst | 5 +++++ 1 file changed, 5 insertions(+) (limited to 'Documentation') diff --git a/Documentation/translations/zh_CN/index.rst b/Documentation/translations/zh_CN/index.rst index 1f953d3439a5..e0d51a167032 100644 --- a/Documentation/translations/zh_CN/index.rst +++ b/Documentation/translations/zh_CN/index.rst @@ -17,6 +17,11 @@ **翻译计划:** 内核中文文档欢迎任何翻译投稿，特别是关于内核用户和管理员指南部分。 +这是中文内核文档树的顶级目录。内核文档，就像内核本身一样，在很大程度上是一 +项正在进行的工作；当我们努力将许多分散的文件整合成一个连贯的整体时尤其如此。 +另外，随时欢迎您对内核文档进行改进；如果您想提供帮助，请加入vger.kernel.org +上的linux-doc邮件列表。 + 许可证文档 ---------- -- cgit v1.2.3 From 108547fd85eb9b74090ffa19d8fef67b345d7898 Mon Sep 17 00:00:00 2001 From: Tim Harvey Date: Fri, 23 Jul 2021 11:41:15 -0700 Subject: dt-bindings: arm: imx: add imx8mm/imx8mn GW7902 support The GW7902 is based on the i.MX 8M Mini / Nano SoC featuring: - LPDDR4 DRAM - eMMC FLASH - Gateworks System Controller - LTE CAT M1 modem - USB 2.0 HUB - M.2 Socket with USB2.0, PCIe, and dual-SIM - IMX8M FEC - PCIe based GbE - RS232/RS485/RS422 serial transceiver - GPS - CAN bus - WiFi / Bluetooth - MIPI header (DSI/CSI/GPIO/PWM/I2S) - PMIC Signed-off-by: Tim Harvey Acked-by: Rob Herring Signed-off-by: Shawn Guo --- Documentation/devicetree/bindings/arm/fsl.yaml | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml index e2097011c4b0..4c4c21276a09 100644 --- a/Documentation/devicetree/bindings/arm/fsl.yaml +++ b/Documentation/devicetree/bindings/arm/fsl.yaml @@ -712,6 +712,7 @@ properties: - gw,imx8mm-gw72xx-0x # i.MX8MM Gateworks Development Kit - gw,imx8mm-gw73xx-0x # i.MX8MM Gateworks Development Kit - gw,imx8mm-gw7901 # i.MX8MM Gateworks Board + - gw,imx8mm-gw7902 # i.MX8MM Gateworks Board - kontron,imx8mm-n801x-som # i.MX8MM Kontron SL (N801X) SOM - variscite,var-som-mx8mm # i.MX8MM Variscite VAR-SOM-MX8MM module - const: fsl,imx8mm @@ -742,6 +743,7 @@ properties: - beacon,imx8mn-beacon-kit # i.MX8MN Beacon Development Kit - fsl,imx8mn-ddr4-evk # i.MX8MN DDR4 EVK Board - fsl,imx8mn-evk # i.MX8MN LPDDR4 EVK Board + - gw,imx8mn-gw7902 # i.MX8MM Gateworks Board - const: fsl,imx8mn - description: Variscite VAR-SOM-MX8MN based boards -- cgit v1.2.3 From e538b0985a05cfe245ada0bb92f177efec6b8a88 Mon Sep 17 00:00:00 2001 From: Eric Biggers Date: Thu, 1 Jul 2021 23:53:50 -0700 Subject: fscrypt: remove mention of symlink st_size quirk from documentation Now that the correct st_size is reported for encrypted symlinks on all filesystems, update the documentation accordingly. Link: https://lore.kernel.org/r/20210702065350.209646-6-ebiggers@kernel.org Signed-off-by: Eric Biggers --- Documentation/filesystems/fscrypt.rst | 5 ----- 1 file changed, 5 deletions(-) (limited to 'Documentation') diff --git a/Documentation/filesystems/fscrypt.rst b/Documentation/filesystems/fscrypt.rst index 44b67ebd6e40..02ec57818920 100644 --- a/Documentation/filesystems/fscrypt.rst +++ b/Documentation/filesystems/fscrypt.rst @@ -1063,11 +1063,6 @@ astute users may notice some differences in behavior: - 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 will be slightly longer - than the plaintext due to NUL-padding and an extra 2-byte overhead. - - The maximum length of an encrypted symlink is 2 bytes shorter than the maximum length of an unencrypted symlink. For example, on an EXT4 filesystem with a 4K block size, unencrypted symlinks can be up -- cgit v1.2.3 From ba47b515f59406038a6ad763d4aff1ab50be2038 Mon Sep 17 00:00:00 2001 From: Eric Biggers Date: Sat, 17 Jul 2021 19:01:25 -0500 Subject: fscrypt: align Base64 encoding with RFC 4648 base64url fscrypt uses a Base64 encoding to encode no-key filenames (the filenames that are presented to userspace when a directory is listed without its encryption key). There are many variants of Base64, but the most common ones are specified by RFC 4648. fscrypt can't use the regular RFC 4648 "base64" variant because "base64" uses the '/' character, which isn't allowed in filenames. However, RFC 4648 also specifies a "base64url" variant for use in URLs and filenames. "base64url" is less common than "base64", but it's still implemented in many programming libraries. Unfortunately, what fscrypt actually uses is a custom Base64 variant that differs from "base64url" in several ways: - The binary data is divided into 6-bit chunks differently. - Values 62 and 63 are encoded with '+' and ',' instead of '-' and '_'. - '='-padding isn't used. This isn't a problem per se, as the padding isn't technically necessary, and RFC 4648 doesn't strictly require it. But it needs to be properly documented. There have been two attempts to copy the fscrypt Base64 code into lib/ (https://lkml.kernel.org/r/20200821182813.52570-6-jlayton@kernel.org and https://lkml.kernel.org/r/20210716110428.9727-5-hare@suse.de), and both have been caught up by the fscrypt Base64 variant being nonstandard and not properly documented. Also, the planned use of the fscrypt Base64 code in the CephFS storage back-end will prevent it from being changed later (whereas currently it can still be changed), so we need to choose an encoding that we're happy with before it's too late. Therefore, switch the fscrypt Base64 variant to base64url, in order to align more closely with RFC 4648 and other implementations and uses of Base64. However, I opted not to implement '='-padding, as '='-padding adds complexity, is unnecessary, and isn't required by the RFC. Link: https://lore.kernel.org/r/20210718000125.59701-1-ebiggers@kernel.org Reviewed-by: Hannes Reinecke Signed-off-by: Eric Biggers --- Documentation/filesystems/fscrypt.rst | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) (limited to 'Documentation') diff --git a/Documentation/filesystems/fscrypt.rst b/Documentation/filesystems/fscrypt.rst index 02ec57818920..0eb799d9d05a 100644 --- a/Documentation/filesystems/fscrypt.rst +++ b/Documentation/filesystems/fscrypt.rst @@ -1230,12 +1230,12 @@ 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. +filenames. Therefore, readdir() must base64url-encode the ciphertext +for presentation. For most filenames, this works fine; on ->lookup(), +the filesystem just base64url-decodes the user-supplied name to get +back to the raw ciphertext. -However, for very long filenames, base64 encoding would cause the +However, for very long filenames, base64url 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 -- cgit v1.2.3 From 7d9e2661f268585ca24ab4edbc1e2925b08374b2 Mon Sep 17 00:00:00 2001 From: Jonathan Corbet Date: Sun, 25 Jul 2021 15:16:00 -0600 Subject: printk: Move the printk() kerneldoc comment to its new home Commit 337015573718 ("printk: Userspace format indexing support") turned printk() into a macro, but left the kerneldoc comment for it with the (now) _printk() function, resulting in this docs-build warning: kernel/printk/printk.c:1: warning: 'printk' not found Move the kerneldoc comment back next to the (now) macro it's meant to describe and have the docs build find it there. Fixes: 337015573718b161 ("printk: Userspace format indexing support") Signed-off-by: Jonathan Corbet Signed-off-by: Petr Mladek Link: https://lore.kernel.org/r/87o8aqt7qn.fsf@meer.lwn.net --- Documentation/core-api/printk-basics.rst | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/core-api/printk-basics.rst b/Documentation/core-api/printk-basics.rst index 965e4281eddd..2dde24ca7d9f 100644 --- a/Documentation/core-api/printk-basics.rst +++ b/Documentation/core-api/printk-basics.rst @@ -107,9 +107,6 @@ also ``CONFIG_DYNAMIC_DEBUG`` in the case of pr_debug()) is defined. Function reference ================== -.. kernel-doc:: kernel/printk/printk.c - :functions: printk - .. kernel-doc:: include/linux/printk.h - :functions: pr_emerg pr_alert pr_crit pr_err pr_warn pr_notice pr_info + :functions: printk pr_emerg pr_alert pr_crit pr_err pr_warn pr_notice pr_info pr_fmt pr_debug pr_devel pr_cont -- cgit v1.2.3 From 6149ab604c80a20e5741bea6c90583edde15c488 Mon Sep 17 00:00:00 2001 From: Hao Chen Date: Mon, 26 Jul 2021 10:47:01 +0800 Subject: devlink: add documentation for hns3 driver Add a file to document devlink support for hns3 driver, now support devlink info and devlink reload. Signed-off-by: Hao Chen Signed-off-by: Guangbin Huang Signed-off-by: David S. Miller --- Documentation/networking/devlink/hns3.rst | 25 +++++++++++++++++++++++++ Documentation/networking/devlink/index.rst | 1 + 2 files changed, 26 insertions(+) create mode 100644 Documentation/networking/devlink/hns3.rst (limited to 'Documentation') diff --git a/Documentation/networking/devlink/hns3.rst b/Documentation/networking/devlink/hns3.rst new file mode 100644 index 000000000000..4562a6e4782f --- /dev/null +++ b/Documentation/networking/devlink/hns3.rst @@ -0,0 +1,25 @@ +.. SPDX-License-Identifier: GPL-2.0 + +==================== +hns3 devlink support +==================== + +This document describes the devlink features implemented by the ``hns3`` +device driver. + +The ``hns3`` driver supports reloading via ``DEVLINK_CMD_RELOAD``. + +Info versions +============= + +The ``hns3`` driver reports the following versions + +.. list-table:: devlink info versions implemented + :widths: 10 10 80 + + * - Name + - Type + - Description + * - ``fw`` + - running + - Used to represent the firmware version. diff --git a/Documentation/networking/devlink/index.rst b/Documentation/networking/devlink/index.rst index b3b9e0692088..03f56ed2961f 100644 --- a/Documentation/networking/devlink/index.rst +++ b/Documentation/networking/devlink/index.rst @@ -34,6 +34,7 @@ parameters, info versions, and other features it supports. :maxdepth: 1 bnxt + hns3 ionic ice mlx4 -- cgit v1.2.3 From 1d479f160c500249d8fa4d21e7d2b7aaffc04daf Mon Sep 17 00:00:00 2001 From: John Garry Date: Mon, 12 Jul 2021 19:12:15 +0800 Subject: iommu: Deprecate Intel and AMD cmdline methods to enable strict mode Now that the x86 drivers support iommu.strict, deprecate the custom methods. Signed-off-by: John Garry Acked-by: Robin Murphy Reviewed-by: Lu Baolu Link: https://lore.kernel.org/r/1626088340-5838-2-git-send-email-john.garry@huawei.com Signed-off-by: Joerg Roedel --- Documentation/admin-guide/kernel-parameters.txt | 9 ++------- 1 file changed, 2 insertions(+), 7 deletions(-) (limited to 'Documentation') diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index bdb22006f713..a04d2748c99a 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -290,10 +290,7 @@ amd_iommu= [HW,X86-64] Pass parameters to the AMD IOMMU driver in the system. Possible values are: - fullflush - enable flushing of IO/TLB entries when - they are unmapped. Otherwise they are - flushed before they will be reused, which - is a lot of faster + fullflush - Deprecated, equivalent to iommu.strict=1 off - do not initialize any AMD IOMMU found in the system force_isolation - Force device isolation for all @@ -1944,9 +1941,7 @@ this case, gfx device will use physical address for DMA. strict [Default Off] - With this option on every unmap_single operation will - result in a hardware IOTLB flush operation as opposed - to batching them for performance. + Deprecated, equivalent to iommu.strict=1. sp_off [Default Off] By default, super page will be supported if Intel IOMMU has the capability. With this option, super page will -- cgit v1.2.3 From 712d8f205835c1d170e85d7811da3d9f36d8fab7 Mon Sep 17 00:00:00 2001 From: Zhen Lei Date: Mon, 12 Jul 2021 19:12:17 +0800 Subject: iommu: Enhance IOMMU default DMA mode build options First, add build options IOMMU_DEFAULT_{LAZY|STRICT}, so that we have the opportunity to set {lazy|strict} mode as default at build time. Then put the two config options in an choice, as they are mutually exclusive. [jpg: Make choice between strict and lazy only (and not passthrough)] Signed-off-by: Zhen Lei Signed-off-by: John Garry Reviewed-by: Robin Murphy Reviewed-by: Lu Baolu Link: https://lore.kernel.org/r/1626088340-5838-4-git-send-email-john.garry@huawei.com Signed-off-by: Joerg Roedel --- Documentation/admin-guide/kernel-parameters.txt | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index a04d2748c99a..90b525cf0ec2 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -2042,9 +2042,10 @@ throughput at the cost of reduced device isolation. Will fall back to strict mode if not supported by the relevant IOMMU driver. - 1 - Strict mode (default). + 1 - Strict mode. DMA unmap operations invalidate IOMMU hardware TLBs synchronously. + unset - Use value of CONFIG_IOMMU_DEFAULT_{LAZY,STRICT}. Note: on x86, the default behaviour depends on the equivalent driver-specific parameters, but a strict mode explicitly specified by either method takes -- cgit v1.2.3 From 0e691ee7b5034c91a31b565d3ff9a50e01dde445 Mon Sep 17 00:00:00 2001 From: Vitaly Kuznetsov Date: Thu, 22 Jul 2021 11:26:28 +0200 Subject: KVM: Documentation: Fix KVM_CAP_ENFORCE_PV_FEATURE_CPUID name 'KVM_CAP_ENFORCE_PV_CPUID' doesn't match the define in include/uapi/linux/kvm.h. Signed-off-by: Vitaly Kuznetsov Message-Id: <20210722092628.236474-1-vkuznets@redhat.com> Signed-off-by: Paolo Bonzini --- Documentation/virt/kvm/api.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst index c7b165ca70b6..1a1d2061227b 100644 --- a/Documentation/virt/kvm/api.rst +++ b/Documentation/virt/kvm/api.rst @@ -7049,7 +7049,7 @@ In combination with KVM_CAP_X86_USER_SPACE_MSR, this allows user space to trap and emulate MSRs that are outside of the scope of KVM as well as limit the attack surface on KVM's MSR emulation code. -8.28 KVM_CAP_ENFORCE_PV_CPUID +8.28 KVM_CAP_ENFORCE_PV_FEATURE_CPUID ----------------------------- Architectures: x86 -- cgit v1.2.3 From 3b1c8c5682672d73c1e977944af8c3ebed4a0ce1 Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Thu, 22 Jul 2021 11:50:03 +0200 Subject: docs: virt: kvm: api.rst: replace some characters The conversion tools used during DocBook/LaTeX/html/Markdown->ReST conversion and some cut-and-pasted text contain some characters that aren't easily reachable on standard keyboards and/or could cause troubles when parsed by the documentation build system. Replace the occurences of the following characters: - U+00a0 (' '): NO-BREAK SPACE as it can cause lines being truncated on PDF output Signed-off-by: Mauro Carvalho Chehab Message-Id: Signed-off-by: Paolo Bonzini --- Documentation/virt/kvm/api.rst | 28 ++++++++++++++-------------- 1 file changed, 14 insertions(+), 14 deletions(-) (limited to 'Documentation') diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst index 1a1d2061227b..dae68e68ca23 100644 --- a/Documentation/virt/kvm/api.rst +++ b/Documentation/virt/kvm/api.rst @@ -855,7 +855,7 @@ in-kernel irqchip (GIC), and for in-kernel irqchip can tell the GIC to use PPIs designated for specific cpus. The irq field is interpreted like this:: -  bits: | 31 ... 28 | 27 ... 24 | 23 ... 16 | 15 ... 0 | + bits: | 31 ... 28 | 27 ... 24 | 23 ... 16 | 15 ... 0 | field: | vcpu2_index | irq_type | vcpu_index | irq_id | The irq_type field has the following values: @@ -2149,10 +2149,10 @@ prior to calling the KVM_RUN ioctl. Errors: ====== ============================================================ -  ENOENT   no such register -  EINVAL   invalid register ID, or no such register or used with VMs in + ENOENT no such register + EINVAL invalid register ID, or no such register or used with VMs in protected virtualization mode on s390 -  EPERM    (arm64) register access not allowed before vcpu finalization + EPERM (arm64) register access not allowed before vcpu finalization ====== ============================================================ (These error codes are indicative only: do not rely on a specific error @@ -2590,10 +2590,10 @@ following id bit patterns:: Errors include: ======== ============================================================ -  ENOENT   no such register -  EINVAL   invalid register ID, or no such register or used with VMs in + ENOENT no such register + EINVAL invalid register ID, or no such register or used with VMs in protected virtualization mode on s390 -  EPERM    (arm64) register access not allowed before vcpu finalization + EPERM (arm64) register access not allowed before vcpu finalization ======== ============================================================ (These error codes are indicative only: do not rely on a specific error @@ -3112,13 +3112,13 @@ current state. "addr" is ignored. Errors: ====== ================================================================= -  EINVAL    the target is unknown, or the combination of features is invalid. -  ENOENT    a features bit specified is unknown. + EINVAL the target is unknown, or the combination of features is invalid. + ENOENT a features bit specified is unknown. ====== ================================================================= This tells KVM what type of CPU to present to the guest, and what -optional features it should have.  This will cause a reset of the cpu -registers to their initial values.  If this is not called, KVM_RUN will +optional features it should have. This will cause a reset of the cpu +registers to their initial values. If this is not called, KVM_RUN will return ENOEXEC for that vcpu. The initial values are defined as: @@ -3239,8 +3239,8 @@ VCPU matching underlying host. Errors: ===== ============================================================== -  E2BIG     the reg index list is too big to fit in the array specified by -             the user (the number required will be written into n). + E2BIG the reg index list is too big to fit in the array specified by + the user (the number required will be written into n). ===== ============================================================== :: @@ -3288,7 +3288,7 @@ specific device. ARM/arm64 divides the id field into two parts, a device id and an address type id specific to the individual device:: -  bits: | 63 ... 32 | 31 ... 16 | 15 ... 0 | + bits: | 63 ... 32 | 31 ... 16 | 15 ... 0 | field: | 0x00000000 | device id | addr type id | ARM/arm64 currently only require this when using the in-kernel GIC -- cgit v1.2.3 From fdb57c3217a0fb992dda3aa812878b30d6a391c7 Mon Sep 17 00:00:00 2001 From: Bjorn Andersson Date: Mon, 26 Jul 2021 10:32:59 -0700 Subject: dt-bindings: display: simple: Add AUO B133HAN05 & B140HAN06 Add bindings for the two AUO panels B133HAN05 and B140HAN06, both 1920x1080 panels with 16.7M colors, first being 13.3" and the latter 14.0". Signed-off-by: Bjorn Andersson Signed-off-by: Sam Ravnborg Link: https://patchwork.freedesktop.org/patch/msgid/20210726173300.432039-1-bjorn.andersson@linaro.org --- Documentation/devicetree/bindings/display/panel/panel-simple.yaml | 4 ++++ 1 file changed, 4 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml index 7cf64ffb34aa..eda427ddca1b 100644 --- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml +++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml @@ -46,9 +46,13 @@ properties: # AU Optronics Corporation 11.6" HD (1366x768) color TFT-LCD panel - auo,b116xw03 # AU Optronics Corporation 13.3" FHD (1920x1080) color TFT-LCD panel + - auo,b133han05 + # AU Optronics Corporation 13.3" FHD (1920x1080) color TFT-LCD panel - auo,b133htn01 # AU Optronics Corporation 13.3" WXGA (1366x768) TFT LCD panel - auo,b133xtn01 + # AU Optronics Corporation 14.0" FHD (1920x1080) color TFT-LCD panel + - auo,b140han06 # AU Optronics Corporation 7.0" FHD (800 x 480) TFT LCD panel - auo,g070vvn01 # AU Optronics Corporation 10.1" (1280x800) color TFT LCD panel -- cgit v1.2.3 From f98f273f3a984ea8592a384391c1a38b7e46c404 Mon Sep 17 00:00:00 2001 From: Artjom Vejsel Date: Mon, 26 Jul 2021 01:15:25 +0300 Subject: dt-bindings: Add QiShenglong vendor prefix Add vendor prefix for Shenzhen QiShenglong Industrialist Co., Ltd. QiShenglong is a Chinese manufacturer of handheld gaming consoles, most of which run (very old) versions of Linux. QiShenglong is known as Hamy. Signed-off-by: Artjom Vejsel Signed-off-by: Sam Ravnborg Link: https://patchwork.freedesktop.org/patch/msgid/20210725221527.1771892-2-akawolf0@gmail.com --- Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index b868cefc7c55..1d45a2d7a7bb 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -926,6 +926,8 @@ patternProperties: description: Chengdu Kaixuan Information Technology Co., Ltd. "^qiaodian,.*": description: QiaoDian XianShi Corporation + "^qishenglong,.*": + description: Shenzhen QiShenglong Industrialist Co., Ltd. "^qnap,.*": description: QNAP Systems, Inc. "^radxa,.*": -- cgit v1.2.3 From 3e82868e8523d5426f76866863704b02adacac3e Mon Sep 17 00:00:00 2001 From: Geert Uytterhoeven Date: Mon, 19 Jul 2021 17:38:32 +0200 Subject: dt-bindings: arm: renesas: Document R-Car H3e-2G and M3e-2G SoCs and boards Document the compatible values for the R-Car H3e-2G (R8A779M1) and M3e-2G (R8A779M3) SoCs. These are different gradings of the R-Car H3 ES3.0 (R8A77951) and M3-W+ (R8A77961) SoCs. All R-Car Gen3e on-SoC devices are identical to the devices on the corresponding R-Car Gen3 SoCs, and thus just use the compatible values for the latter. The root compatible properties do gain an additional value, to sort out integration issues if they ever arise. Document the use of these SoCs on the Salvator-XS and ULCB (with and without Kingfisher) development boards. Signed-off-by: Geert Uytterhoeven Reviewed-by: Laurent Pinchart Reviewed-by: Yoshihiro Shimoda Acked-by: Rob Herring Link: https://lore.kernel.org/r/fd11328199d8abba5b9ee1f43f4d467d1bc41df6.1626708063.git.geert+renesas@glider.be --- Documentation/devicetree/bindings/arm/renesas.yaml | 50 +++++++++++++++++----- 1 file changed, 39 insertions(+), 11 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/renesas.yaml b/Documentation/devicetree/bindings/arm/renesas.yaml index a0cce4e25039..8a11918866b8 100644 --- a/Documentation/devicetree/bindings/arm/renesas.yaml +++ b/Documentation/devicetree/bindings/arm/renesas.yaml @@ -238,17 +238,29 @@ properties: - const: renesas,r8a77961 - description: Kingfisher (SBEV-RCAR-KF-M03) - items: - - const: shimafuji,kingfisher - - enum: - - renesas,h3ulcb - - renesas,m3ulcb - - renesas,m3nulcb - - enum: - - renesas,r8a7795 - - renesas,r8a7796 - - renesas,r8a77961 - - renesas,r8a77965 + oneOf: + - items: + - const: shimafuji,kingfisher + - enum: + - renesas,h3ulcb + - renesas,m3ulcb + - renesas,m3nulcb + - enum: + - renesas,r8a7795 + - renesas,r8a7796 + - renesas,r8a77961 + - renesas,r8a77965 + - items: + - const: shimafuji,kingfisher + - enum: + - renesas,h3ulcb + - renesas,m3ulcb + - enum: + - renesas,r8a779m1 + - renesas,r8a779m3 + - enum: + - renesas,r8a7795 + - renesas,r8a77961 - description: R-Car M3-N (R8A77965) items: @@ -296,6 +308,22 @@ properties: - const: renesas,falcon-cpu - const: renesas,r8a779a0 + - description: R-Car H3e-2G (R8A779M1) + items: + - enum: + - renesas,h3ulcb # H3ULCB (R-Car Starter Kit Premier) + - renesas,salvator-xs # Salvator-XS (Salvator-X 2nd version) + - const: renesas,r8a779m1 + - const: renesas,r8a7795 + + - description: R-Car M3e-2G (R8A779M3) + items: + - enum: + - renesas,m3ulcb # M3ULCB (R-Car Starter Kit Pro) + - renesas,salvator-xs # Salvator-XS (Salvator-X 2nd version) + - const: renesas,r8a779m3 + - const: renesas,r8a77961 + - description: RZ/N1D (R9A06G032) items: - enum: -- cgit v1.2.3 From f444f34b4a1afcd2133daaa73778673ca09fb564 Mon Sep 17 00:00:00 2001 From: Linus Walleij Date: Sat, 17 Jul 2021 00:53:19 +0200 Subject: dt-bindings: serial: 8250: Add Exar compatibles The Intel IXP425 Vulcan board has an Exar XR16L2551 8250-compatible. It works like an 8250 but it is always good to specify exactly which component we are using. This allows us to specify: compatible = "exar,xr16l2551", "ns8250"; Put in some sibling Exar serial compatibles while we're at it. Cc: Marc Zyngier Cc: devicetree@vger.kernel.org Acked-by: Rob Herring Signed-off-by: Linus Walleij Link: https://lore.kernel.org/r/20210716225319.1282704-1-linus.walleij@linaro.org Signed-off-by: Greg Kroah-Hartman --- Documentation/devicetree/bindings/serial/8250.yaml | 6 ++++++ 1 file changed, 6 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/serial/8250.yaml b/Documentation/devicetree/bindings/serial/8250.yaml index a0bf061b80fe..fa767440f281 100644 --- a/Documentation/devicetree/bindings/serial/8250.yaml +++ b/Documentation/devicetree/bindings/serial/8250.yaml @@ -64,6 +64,12 @@ properties: - const: nuvoton,npcm750-uart - const: nvidia,tegra20-uart - const: nxp,lpc3220-uart + - items: + - enum: + - exar,xr16l2552 + - exar,xr16l2551 + - exar,xr16l2550 + - const: ns8250 - items: - enum: - altr,16550-FIFO32 -- cgit v1.2.3 From 481975b24c3996352c100be1c3f962bc54ec552d Mon Sep 17 00:00:00 2001 From: Sam Shih Date: Mon, 26 Jul 2021 15:14:36 +0800 Subject: dt-bindings: serial: Add compatible for Mediatek MT7986 This commit adds dt-binding documentation of uart for Mediatek MT7986 SoC Platform. Signed-off-by: Sam Shih Link: https://lore.kernel.org/r/20210726071439.14248-10-sam.shih@mediatek.com Signed-off-by: Greg Kroah-Hartman --- Documentation/devicetree/bindings/serial/mtk-uart.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/serial/mtk-uart.txt b/Documentation/devicetree/bindings/serial/mtk-uart.txt index 64c4fb59acd1..b3a0bfef0d54 100644 --- a/Documentation/devicetree/bindings/serial/mtk-uart.txt +++ b/Documentation/devicetree/bindings/serial/mtk-uart.txt @@ -15,6 +15,7 @@ Required properties: * "mediatek,mt7622-uart" for MT7622 compatible UARTS * "mediatek,mt7623-uart" for MT7623 compatible UARTS * "mediatek,mt7629-uart" for MT7629 compatible UARTS + * "mediatek,mt7986-uart", "mediatek,mt6577-uart" for MT7986 compatible UARTS * "mediatek,mt8127-uart" for MT8127 compatible UARTS * "mediatek,mt8135-uart" for MT8135 compatible UARTS * "mediatek,mt8173-uart" for MT8173 compatible UARTS -- cgit v1.2.3 From ba6cd766e0bf933611dc66fcb86f72ac80a446bc Mon Sep 17 00:00:00 2001 From: Daniel Vetter Date: Fri, 23 Jul 2021 10:34:57 +0200 Subject: drm/plane: Move drm_plane_enable_fb_damage_clips into core MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit We're trying to have a fairly strict split between core functionality that defines the uapi, including the docs, and the helper functions to implement it. Move drm_plane_enable_fb_damage_clips and associated kerneldoc into drm_plane from drm_damage_helper.c to fix this. Reviewed-by: José Roberto de Souza Cc: Ville Syrjälä Cc: Gwan-gyeong Mun Cc: José Roberto de Souza Cc: Hans de Goede Signed-off-by: Daniel Vetter Cc: Maarten Lankhorst Cc: Maxime Ripard Cc: Thomas Zimmermann Cc: David Airlie Cc: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20210723083457.696939-3-daniel.vetter@ffwll.ch --- Documentation/gpu/drm-kms.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst index 12e25119e563..0cc21f6aaef5 100644 --- a/Documentation/gpu/drm-kms.rst +++ b/Documentation/gpu/drm-kms.rst @@ -537,8 +537,8 @@ Plane Composition Properties Damage Tracking Properties -------------------------- -.. kernel-doc:: drivers/gpu/drm/drm_damage_helper.c - :doc: overview +.. kernel-doc:: drivers/gpu/drm/drm_plane.c + :doc: damage tracking Color Management Properties --------------------------- -- cgit v1.2.3 From d4b996f9ef1fe83d9ce9ad5c1ca0bd8231638ce5 Mon Sep 17 00:00:00 2001 From: Ioana Ciornei Date: Fri, 23 Jul 2021 11:42:44 +0300 Subject: docs: networking: dpaa2: add documentation for the switch driver Add a documentation entry for the DPAA2 switch listing its requirements, features and some examples to go along them. Signed-off-by: Ioana Ciornei Reviewed-by: Andrew Lunn Signed-off-by: David S. Miller --- .../ethernet/freescale/dpaa2/index.rst | 1 + .../ethernet/freescale/dpaa2/switch-driver.rst | 174 +++++++++++++++++++++ 2 files changed, 175 insertions(+) create mode 100644 Documentation/networking/device_drivers/ethernet/freescale/dpaa2/switch-driver.rst (limited to 'Documentation') diff --git a/Documentation/networking/device_drivers/ethernet/freescale/dpaa2/index.rst b/Documentation/networking/device_drivers/ethernet/freescale/dpaa2/index.rst index ee40fcc5ddff..62f4a4aff6ec 100644 --- a/Documentation/networking/device_drivers/ethernet/freescale/dpaa2/index.rst +++ b/Documentation/networking/device_drivers/ethernet/freescale/dpaa2/index.rst @@ -9,3 +9,4 @@ DPAA2 Documentation dpio-driver ethernet-driver mac-phy-support + switch-driver diff --git a/Documentation/networking/device_drivers/ethernet/freescale/dpaa2/switch-driver.rst b/Documentation/networking/device_drivers/ethernet/freescale/dpaa2/switch-driver.rst new file mode 100644 index 000000000000..863ca6bd8318 --- /dev/null +++ b/Documentation/networking/device_drivers/ethernet/freescale/dpaa2/switch-driver.rst @@ -0,0 +1,174 @@ +.. SPDX-License-Identifier: GPL-2.0 +.. include:: + +=================== +DPAA2 Switch driver +=================== + +:Copyright: |copy| 2021 NXP + +The DPAA2 Switch driver probes on the Datapath Switch (DPSW) object which can +be instantiated on the following DPAA2 SoCs and their variants: LS2088A and +LX2160A. + +The driver uses the switch device driver model and exposes each switch port as +a network interface, which can be included in a bridge or used as a standalone +interface. Traffic switched between ports is offloaded into the hardware. + +The DPSW can have ports connected to DPNIs or to DPMACs for external access. +:: + + [ethA] [ethB] [ethC] [ethD] [ethE] [ethF] + : : : : : : + : : : : : : + [dpaa2-eth] [dpaa2-eth] [ dpaa2-switch ] + : : : : : : kernel + ============================================================================= + : : : : : : hardware + [DPNI] [DPNI] [============= DPSW =================] + | | | | | | + | ---------- | [DPMAC] [DPMAC] + ------------------------------- | | + | | + [PHY] [PHY] + +Creating an Ethernet Switch +=========================== + +The dpaa2-switch driver probes on DPSW devices found on the fsl-mc bus. These +devices can be either created statically through the boot time configuration +file - DataPath Layout (DPL) - or at runtime using the DPAA2 object APIs +(incorporated already into the restool userspace tool). + +At the moment, the dpaa2-switch driver imposes the following restrictions on +the DPSW object that it will probe: + + * The minimum number of FDBs should be at least equal to the number of switch + interfaces. This is necessary so that separation of switch ports can be + done, ie when not under a bridge, each switch port will have its own FDB. + :: + + fsl_dpaa2_switch dpsw.0: The number of FDBs is lower than the number of ports, cannot probe + + * Both the broadcast and flooding configuration should be per FDB. This + enables the driver to restrict the broadcast and flooding domains of each + FDB depending on the switch ports that are sharing it (aka are under the + same bridge). + :: + + fsl_dpaa2_switch dpsw.0: Flooding domain is not per FDB, cannot probe + fsl_dpaa2_switch dpsw.0: Broadcast domain is not per FDB, cannot probe + + * The control interface of the switch should not be disabled + (DPSW_OPT_CTRL_IF_DIS not passed as a create time option). Without the + control interface, the driver is not capable to provide proper Rx/Tx traffic + support on the switch port netdevices. + :: + + fsl_dpaa2_switch dpsw.0: Control Interface is disabled, cannot probe + +Besides the configuration of the actual DPSW object, the dpaa2-switch driver +will need the following DPAA2 objects: + + * 1 DPMCP - A Management Command Portal object is needed for any interraction + with the MC firmware. + + * 1 DPBP - A Buffer Pool is used for seeding buffers intended for the Rx path + on the control interface. + + * Access to at least one DPIO object (Software Portal) is needed for any + enqueue/dequeue operation to be performed on the control interface queues. + The DPIO object will be shared, no need for a private one. + +Switching features +================== + +The driver supports the configuration of L2 forwarding rules in hardware for +port bridging as well as standalone usage of the independent switch interfaces. + +The hardware is not configurable with respect to VLAN awareness, thus any DPAA2 +switch port should be used only in usecases with a VLAN aware bridge:: + + $ ip link add dev br0 type bridge vlan_filtering 1 + + $ ip link add dev br1 type bridge + $ ip link set dev ethX master br1 + Error: fsl_dpaa2_switch: Cannot join a VLAN-unaware bridge + +Topology and loop detection through STP is supported when ``stp_state 1`` is +used at bridge create :: + + $ ip link add dev br0 type bridge vlan_filtering 1 stp_state 1 + +L2 FDB manipulation (add/delete/dump) is supported. + +HW FDB learning can be configured on each switch port independently through +bridge commands. When the HW learning is disabled, a fast age procedure will be +run and any previously learnt addresses will be removed. +:: + + $ bridge link set dev ethX learning off + $ bridge link set dev ethX learning on + +Restricting the unknown unicast and multicast flooding domain is supported, but +not independently of each other:: + + $ ip link set dev ethX type bridge_slave flood off mcast_flood off + $ ip link set dev ethX type bridge_slave flood off mcast_flood on + Error: fsl_dpaa2_switch: Cannot configure multicast flooding independently of unicast. + +Broadcast flooding on a switch port can be disabled/enabled through the brport sysfs:: + + $ echo 0 > /sys/bus/fsl-mc/devices/dpsw.Y/net/ethX/brport/broadcast_flood + +Offloads +======== + +Routing actions (redirect, trap, drop) +-------------------------------------- + +The DPAA2 switch is able to offload flow-based redirection of packets making +use of ACL tables. Shared filter blocks are supported by sharing a single ACL +table between multiple ports. + +The following flow keys are supported: + + * Ethernet: dst_mac/src_mac + * IPv4: dst_ip/src_ip/ip_proto/tos + * VLAN: vlan_id/vlan_prio/vlan_tpid/vlan_dei + * L4: dst_port/src_port + +Also, the matchall filter can be used to redirect the entire traffic received +on a port. + +As per flow actions, the following are supported: + + * drop + * mirred egress redirect + * trap + +Each ACL entry (filter) can be setup with only one of the listed +actions. + +Example 1: send frames received on eth4 with a SA of 00:01:02:03:04:05 to the +CPU:: + + $ tc qdisc add dev eth4 clsact + $ tc filter add dev eth4 ingress flower src_mac 00:01:02:03:04:05 skip_sw action trap + +Example 2: drop frames received on eth4 with VID 100 and PCP of 3:: + + $ tc filter add dev eth4 ingress protocol 802.1q flower skip_sw vlan_id 100 vlan_prio 3 action drop + +Example 3: redirect all frames received on eth4 to eth1:: + + $ tc filter add dev eth4 ingress matchall action mirred egress redirect dev eth1 + +Example 4: Use a single shared filter block on both eth5 and eth6:: + + $ tc qdisc add dev eth5 ingress_block 1 clsact + $ tc qdisc add dev eth6 ingress_block 1 clsact + $ tc filter add block 1 ingress flower dst_mac 00:01:02:03:04:04 skip_sw \ + action trap + $ tc filter add block 1 ingress protocol ipv4 flower src_ip 192.168.1.1 skip_sw \ + action mirred egress redirect dev eth3 -- cgit v1.2.3 From 18931afe5b4fb7f91da43043c867e504e742a781 Mon Sep 17 00:00:00 2001 From: Biju Das Date: Mon, 19 Jul 2021 13:19:31 +0100 Subject: dt-bindings: reset: Document RZ/G2L USBPHY Control bindings Add device tree binding document for RZ/G2L USBPHY Control Device. It mainly controls reset and power down of the USB/PHY. Signed-off-by: Biju Das Reviewed-by: Lad Prabhakar Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20210719121938.6532-4-biju.das.jz@bp.renesas.com Signed-off-by: Philipp Zabel --- .../bindings/reset/renesas,rzg2l-usbphy-ctrl.yaml | 65 ++++++++++++++++++++++ 1 file changed, 65 insertions(+) create mode 100644 Documentation/devicetree/bindings/reset/renesas,rzg2l-usbphy-ctrl.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/reset/renesas,rzg2l-usbphy-ctrl.yaml b/Documentation/devicetree/bindings/reset/renesas,rzg2l-usbphy-ctrl.yaml new file mode 100644 index 000000000000..b13514e6783d --- /dev/null +++ b/Documentation/devicetree/bindings/reset/renesas,rzg2l-usbphy-ctrl.yaml @@ -0,0 +1,65 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/reset/renesas,rzg2l-usbphy-ctrl.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Renesas RZ/G2L USBPHY Control + +maintainers: + - Biju Das + +description: + The RZ/G2L USBPHY Control mainly controls reset and power down of the + USB/PHY. + +properties: + compatible: + items: + - enum: + - renesas,r9a07g044-usbphy-ctrl # RZ/G2{L,LC} + - const: renesas,rzg2l-usbphy-ctrl + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + + resets: + maxItems: 1 + + power-domains: + maxItems: 1 + + '#reset-cells': + const: 1 + description: | + The phandle's argument in the reset specifier is the PHY reset associated + with the USB port. + 0 = Port 1 Phy reset + 1 = Port 2 Phy reset + +required: + - compatible + - reg + - clocks + - resets + - power-domains + - '#reset-cells' + +additionalProperties: false + +examples: + - | + #include + + phyrst: usbphy-ctrl@11c40000 { + compatible = "renesas,r9a07g044-usbphy-ctrl", + "renesas,rzg2l-usbphy-ctrl"; + reg = <0x11c40000 0x10000>; + clocks = <&cpg CPG_MOD R9A07G044_USB_PCLK>; + resets = <&cpg R9A07G044_USB_PRESETN>; + power-domains = <&cpg>; + #reset-cells = <1>; + }; -- cgit v1.2.3 From a71786d7f519a97fa79cd9e020015b2dee788889 Mon Sep 17 00:00:00 2001 From: Chunfeng Yun Date: Thu, 15 Jul 2021 17:07:46 +0800 Subject: dt-bindings: usb: mtu3: remove support VBUS detection of extcon Due to no platforms use a multi-funtion pin to detect VBUS status until now when support dual role mode, prefer not to support it anymore; Another reason is that the controller doesn't support idle status, the dual role port works as device or as host, using an IDDIG pin is good enough, this will help to save another multi-function pin; And fix a typo of 'neede'; Last modify example using VBUS to turn on/off device, for device only mode, the driver doesn't get extcon. Acked-by: Rob Herring Signed-off-by: Chunfeng Yun Link: https://lore.kernel.org/r/1626340078-29111-2-git-send-email-chunfeng.yun@mediatek.com Signed-off-by: Greg Kroah-Hartman --- .../devicetree/bindings/usb/mediatek,mtu3.yaml | 22 ++++++++++++++++++---- 1 file changed, 18 insertions(+), 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/usb/mediatek,mtu3.yaml b/Documentation/devicetree/bindings/usb/mediatek,mtu3.yaml index dbc7876e0a0b..2cac7a87ce36 100644 --- a/Documentation/devicetree/bindings/usb/mediatek,mtu3.yaml +++ b/Documentation/devicetree/bindings/usb/mediatek,mtu3.yaml @@ -106,7 +106,7 @@ properties: extcon: deprecated: true description: | - Phandle to the extcon device detecting the IDDIG/VBUS state, neede + Phandle to the extcon device detecting the IDDIG state, needed when supports dual-role mode. It's considered valid for compatibility reasons, not allowed for new bindings, and use "usb-role-switch" property instead. @@ -230,7 +230,7 @@ examples: }; }; - # Enable/disable device by an input gpio for VBUS pin + # Dual role switch by gpio-usb-b-connector - | #include #include @@ -244,13 +244,27 @@ examples: power-domains = <&scpsys MT2712_POWER_DOMAIN_USB2>; clocks = <&topckgen CLK_TOP_USB30_SEL>; clock-names = "sys_ck"; - dr_mode = "peripheral"; + dr_mode = "otg"; usb-role-switch; + #address-cells = <1>; + #size-cells = <1>; + ranges; + + host0: usb@11270000 { + compatible = "mediatek,mt2712-xhci", "mediatek,mtk-xhci"; + reg = <0x11270000 0x1000>; + reg-names = "mac"; + interrupts = ; + power-domains = <&scpsys MT2712_POWER_DOMAIN_USB>; + clocks = <&topckgen CLK_TOP_USB30_SEL>, <&clk26m>; + clock-names = "sys_ck", "ref_ck"; + }; connector { compatible = "gpio-usb-b-connector", "usb-b-connector"; type = "micro"; - vbus-gpios = <&pio 13 GPIO_ACTIVE_HIGH>; + id-gpios = <&pio 12 GPIO_ACTIVE_HIGH>; + vbus-supply = <&usb_p0_vbus>; }; }; -- cgit v1.2.3 From 88302047803bc16cd614a587fee653450e7b5de6 Mon Sep 17 00:00:00 2001 From: Chunfeng Yun Date: Thu, 15 Jul 2021 17:07:47 +0800 Subject: dt-bindings: usb: mtu3: add optional property to disable usb2 ports Add support to disable specific usb2 host ports, it's useful when a usb2 port is disabled on some platforms, but enabled on others for the same SoC, another case is that the different package may support different number of ports. Acked-by: Rob Herring Signed-off-by: Chunfeng Yun Link: https://lore.kernel.org/r/1626340078-29111-3-git-send-email-chunfeng.yun@mediatek.com Signed-off-by: Greg Kroah-Hartman --- Documentation/devicetree/bindings/usb/mediatek,mtu3.yaml | 6 ++++++ 1 file changed, 6 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/usb/mediatek,mtu3.yaml b/Documentation/devicetree/bindings/usb/mediatek,mtu3.yaml index 2cac7a87ce36..3e6f2750f48d 100644 --- a/Documentation/devicetree/bindings/usb/mediatek,mtu3.yaml +++ b/Documentation/devicetree/bindings/usb/mediatek,mtu3.yaml @@ -166,6 +166,12 @@ properties: description: The mask to disable u3ports, bit0 for u3port0, bit1 for u3port1, ... etc + mediatek,u2p-dis-msk: + $ref: /schemas/types.yaml#/definitions/uint32 + description: The mask to disable u2ports, bit0 for u2port0, + bit1 for u2port1, ... etc; but can't disable u2port0 if dual role mode + is enabled, so will be skipped in this case. + # Required child node when support dual-role patternProperties: "^usb@[0-9a-f]+$": -- cgit v1.2.3 From 0b44e4ec285275418311424e1163ea490f32dd45 Mon Sep 17 00:00:00 2001 From: Chunfeng Yun Date: Thu, 15 Jul 2021 17:07:48 +0800 Subject: dt-bindings: usb: mtu3: add support property role-switch-default-mode Add support optional property of role-switch-default-mode, used to set default mode while usb role is USB_ROLE_NONE when use usb-role-switch to switch mode. Acked-by: Rob Herring Signed-off-by: Chunfeng Yun Link: https://lore.kernel.org/r/1626340078-29111-4-git-send-email-chunfeng.yun@mediatek.com Signed-off-by: Greg Kroah-Hartman --- Documentation/devicetree/bindings/usb/mediatek,mtu3.yaml | 6 ++++++ 1 file changed, 6 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/usb/mediatek,mtu3.yaml b/Documentation/devicetree/bindings/usb/mediatek,mtu3.yaml index 3e6f2750f48d..104f1f7edaf0 100644 --- a/Documentation/devicetree/bindings/usb/mediatek,mtu3.yaml +++ b/Documentation/devicetree/bindings/usb/mediatek,mtu3.yaml @@ -116,6 +116,10 @@ properties: description: Support role switch. type: boolean + role-switch-default-mode: + enum: [host, peripheral] + default: host + connector: $ref: /connector/usb-connector.yaml# description: @@ -184,6 +188,7 @@ patternProperties: dependencies: connector: [ 'usb-role-switch' ] port: [ 'usb-role-switch' ] + role-switch-default-mode: [ 'usb-role-switch' ] wakeup-source: [ 'mediatek,syscon-wakeup' ] required: @@ -288,6 +293,7 @@ examples: wakeup-source; dr_mode = "otg"; usb-role-switch; + role-switch-default-mode = "host"; #address-cells = <1>; #size-cells = <1>; ranges; -- cgit v1.2.3 From 72c1b91f5de3cedfefa1921bc3987eced2868bd7 Mon Sep 17 00:00:00 2001 From: Chunfeng Yun Date: Thu, 15 Jul 2021 17:07:49 +0800 Subject: dt-bindings: usb: mtu3: add wakeup interrupt Add an dedicated interrupt which is usually EINT to support runtime PM, meanwhile add "interrupt-names" property, for backward compatibility, it's optional and used when wakeup interrupt exists Acked-by: Rob Herring Signed-off-by: Chunfeng Yun Link: https://lore.kernel.org/r/1626340078-29111-5-git-send-email-chunfeng.yun@mediatek.com Signed-off-by: Greg Kroah-Hartman --- Documentation/devicetree/bindings/usb/mediatek,mtu3.yaml | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/usb/mediatek,mtu3.yaml b/Documentation/devicetree/bindings/usb/mediatek,mtu3.yaml index 104f1f7edaf0..77db1233516e 100644 --- a/Documentation/devicetree/bindings/usb/mediatek,mtu3.yaml +++ b/Documentation/devicetree/bindings/usb/mediatek,mtu3.yaml @@ -38,7 +38,18 @@ properties: - const: ippc interrupts: - maxItems: 1 + description: + use "interrupts-extended" when the interrupts are connected to the + separate interrupt controllers + minItems: 1 + items: + - description: SSUSB device controller interrupt + - description: optional, wakeup interrupt used to support runtime PM + + interrupt-names: + items: + - const: device + - const: wakeup power-domains: description: A phandle to USB power domain node to control USB's MTCMOS -- cgit v1.2.3 From 39c0bf564eadbc4cb84e1c81cdd215f33b383a91 Mon Sep 17 00:00:00 2001 From: Maxime Ripard Date: Wed, 21 Jul 2021 16:04:06 +0200 Subject: dt-bindings: usb: ehci: Add Allwinner A83t compatible The A83t EHCI compatible was introduced in device trees, but it was never documented. Signed-off-by: Maxime Ripard Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20210721140424.725744-37-maxime@cerno.tech Signed-off-by: Greg Kroah-Hartman --- Documentation/devicetree/bindings/usb/generic-ehci.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/usb/generic-ehci.yaml b/Documentation/devicetree/bindings/usb/generic-ehci.yaml index f6e5e4abb85b..8913497624de 100644 --- a/Documentation/devicetree/bindings/usb/generic-ehci.yaml +++ b/Documentation/devicetree/bindings/usb/generic-ehci.yaml @@ -34,6 +34,7 @@ properties: - allwinner,sun6i-a31-ehci - allwinner,sun7i-a20-ehci - allwinner,sun8i-a23-ehci + - allwinner,sun8i-a83t-ehci - allwinner,sun8i-h3-ehci - allwinner,sun8i-r40-ehci - allwinner,sun9i-a80-ehci -- cgit v1.2.3 From 4356ad83792fe1633b8645f68cd4eefafca079a7 Mon Sep 17 00:00:00 2001 From: Maxime Ripard Date: Wed, 21 Jul 2021 16:04:07 +0200 Subject: dt-bindings: usb: ohci: Add Allwinner A83t compatible The A83t OHCI compatible was introduced in device trees, but it was never documented. Signed-off-by: Maxime Ripard Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20210721140424.725744-38-maxime@cerno.tech Signed-off-by: Greg Kroah-Hartman --- Documentation/devicetree/bindings/usb/generic-ohci.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/usb/generic-ohci.yaml b/Documentation/devicetree/bindings/usb/generic-ohci.yaml index 569777a76c90..acbf94fa5f74 100644 --- a/Documentation/devicetree/bindings/usb/generic-ohci.yaml +++ b/Documentation/devicetree/bindings/usb/generic-ohci.yaml @@ -24,6 +24,7 @@ properties: - allwinner,sun6i-a31-ohci - allwinner,sun7i-a20-ohci - allwinner,sun8i-a23-ohci + - allwinner,sun8i-a83t-ohci - allwinner,sun8i-h3-ohci - allwinner,sun8i-r40-ohci - allwinner,sun9i-a80-ohci -- cgit v1.2.3 From db60b87e5f11ca8de81724262fb5c1789e577aa0 Mon Sep 17 00:00:00 2001 From: Rob Herring Date: Mon, 19 Jul 2021 13:48:50 -0600 Subject: dt-bindings: media: Fix graph 'unevaluatedProperties' related warnings The graph schema doesn't allow custom properties on endpoint nodes for '#/properties/port' and '#/$defs/port-base' should be used instead. This doesn't matter until 'unevaluatedProperties' support is implemented. Cc: Eugen Hristev Cc: Mauro Carvalho Chehab Cc: Nicolas Ferre Cc: Alexandre Belloni Cc: Ludovic Desroches Cc: Fabrizio Castro Cc: Ramesh Shanmugasundaram Cc: linux-media@vger.kernel.org Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20210719194850.2410511-1-robh@kernel.org --- Documentation/devicetree/bindings/media/atmel,isc.yaml | 3 ++- Documentation/devicetree/bindings/media/microchip,xisc.yaml | 2 +- Documentation/devicetree/bindings/media/renesas,drif.yaml | 2 +- 3 files changed, 4 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/media/atmel,isc.yaml b/Documentation/devicetree/bindings/media/atmel,isc.yaml index 3e4bb8892d94..cd6d7af0c768 100644 --- a/Documentation/devicetree/bindings/media/atmel,isc.yaml +++ b/Documentation/devicetree/bindings/media/atmel,isc.yaml @@ -44,7 +44,8 @@ properties: const: isc-mck port: - $ref: /schemas/graph.yaml#/properties/port + $ref: /schemas/graph.yaml#/$defs/port-base + unevaluatedProperties: false description: Input port node, single endpoint describing the input pad. diff --git a/Documentation/devicetree/bindings/media/microchip,xisc.yaml b/Documentation/devicetree/bindings/media/microchip,xisc.yaml index 41afe2e5f133..086e1430af4f 100644 --- a/Documentation/devicetree/bindings/media/microchip,xisc.yaml +++ b/Documentation/devicetree/bindings/media/microchip,xisc.yaml @@ -52,7 +52,7 @@ properties: of the data and clock lines. port: - $ref: /schemas/graph.yaml#/properties/port + $ref: /schemas/graph.yaml#/$defs/port-base description: Input port node, single endpoint describing the input pad. diff --git a/Documentation/devicetree/bindings/media/renesas,drif.yaml b/Documentation/devicetree/bindings/media/renesas,drif.yaml index 817a6d566738..2867d11fe156 100644 --- a/Documentation/devicetree/bindings/media/renesas,drif.yaml +++ b/Documentation/devicetree/bindings/media/renesas,drif.yaml @@ -96,7 +96,7 @@ properties: Indicates that the channel acts as primary among the bonded channels. port: - $ref: /schemas/graph.yaml#/properties/port + $ref: /schemas/graph.yaml#/$defs/port-base unevaluatedProperties: false description: Child port node corresponding to the data input. The port node must -- cgit v1.2.3 From b4db237e1e23489fdde1fb195e687b50d0ec162f Mon Sep 17 00:00:00 2001 From: Rob Herring Date: Mon, 19 Jul 2021 13:50:01 -0600 Subject: dt-bindings: display: Fix graph 'unevaluatedProperties' related warnings The graph schema doesn't allow custom properties on endpoint nodes for '#/properties/port' and '#/$defs/port-base' should be used instead. This doesn't matter until 'unevaluatedProperties' support is implemented. Cc: David Airlie Cc: Daniel Vetter Cc: Rob Clark Cc: Sean Paul Cc: Marek Vasut Cc: Krishna Manikandan Cc: dri-devel@lists.freedesktop.org Signed-off-by: Rob Herring Acked-by: Sam Ravnborg Link: https://lore.kernel.org/r/20210719195001.2412345-1-robh@kernel.org --- Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml | 6 ++++-- .../devicetree/bindings/display/msm/dsi-controller-main.yaml | 6 ++++-- 2 files changed, 8 insertions(+), 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml index d101233ae17f..07b20383cbca 100644 --- a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml +++ b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml @@ -37,7 +37,8 @@ properties: properties: port@0: - $ref: /schemas/graph.yaml#/properties/port + $ref: /schemas/graph.yaml#/$defs/port-base + unevaluatedProperties: false description: Video port for MIPI DSI Channel-A input properties: @@ -57,7 +58,8 @@ properties: - const: 4 port@1: - $ref: /schemas/graph.yaml#/properties/port + $ref: /schemas/graph.yaml#/$defs/port-base + unevaluatedProperties: false description: Video port for MIPI DSI Channel-B input properties: diff --git a/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml b/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml index 76348b71f736..de23cab9b5f1 100644 --- a/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml +++ b/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml @@ -77,7 +77,8 @@ properties: properties: port@0: - $ref: "/schemas/graph.yaml#/properties/port" + $ref: "/schemas/graph.yaml#/$defs/port-base" + unevaluatedProperties: false description: | Input endpoints of the controller. properties: @@ -92,7 +93,8 @@ properties: enum: [ 0, 1, 2, 3 ] port@1: - $ref: "/schemas/graph.yaml#/properties/port" + $ref: "/schemas/graph.yaml#/$defs/port-base" + unevaluatedProperties: false description: | Output endpoints of the controller. properties: -- cgit v1.2.3 From 61aaaa8110b1207cd70313e219cd8d2ed843b8e3 Mon Sep 17 00:00:00 2001 From: Rob Herring Date: Tue, 20 Jul 2021 11:20:25 -0600 Subject: dt-bindings: Remove "status" from schema examples There's no reason to have "status" properties in examples. "okay" is the default, and "disabled" turns off some schema checks ('required' specifically). Enabling qca,ar71xx causes a warning, so let's fix the node names: Documentation/devicetree/bindings/net/qca,ar71xx.example.dt.yaml: phy@3: '#phy-cells' is a required property From schema: schemas/phy/phy-provider.yaml Cc: Maxime Ripard Cc: Chen-Yu Tsai Cc: Thierry Reding Cc: Sam Ravnborg Cc: "David S. Miller" Cc: Jakub Kicinski Cc: Robert Marko Cc: Alessandro Zummo Cc: Ramesh Shanmugasundaram Cc: "G. Jaya Kumaran" Cc: ChiYuan Huang Cc: Wei Xu Cc: Dilip Kota Cc: Karol Gugala Cc: Mateusz Holenko Cc: Olivier Moysan Cc: Peter Ujfalusi Cc: dri-devel@lists.freedesktop.org Cc: linux-media@vger.kernel.org Cc: netdev@vger.kernel.org Cc: linux-rtc@vger.kernel.org Cc: alsa-devel@alsa-project.org Signed-off-by: Rob Herring Reviewed-by: Rui Miguel Silva Reviewed-by: Linus Walleij Reviewed-by: Laurent Pinchart Reviewed-by: Mauro Carvalho Chehab # For media Acked-by: Mark Brown Acked-by: Alexandre Belloni Reviewed-by: Oleksij Rempel Reviewed-by: Philipp Zabel Link: https://lore.kernel.org/r/20210720172025.363238-1-robh@kernel.org --- .../display/allwinner,sun8i-a83t-dw-hdmi.yaml | 2 -- .../bindings/display/panel/boe,tv101wum-nl6.yaml | 1 - .../bindings/media/nxp,imx7-mipi-csi2.yaml | 2 -- .../devicetree/bindings/media/renesas,drif.yaml | 1 - .../devicetree/bindings/net/intel,dwmac-plat.yaml | 1 - .../bindings/net/intel,ixp4xx-ethernet.yaml | 2 -- .../bindings/net/nfc/samsung,s3fwrn5.yaml | 3 --- .../devicetree/bindings/net/qca,ar71xx.yaml | 25 +++++----------------- .../regulator/richtek,rt6245-regulator.yaml | 1 - .../regulator/vqmmc-ipq4019-regulator.yaml | 1 - .../bindings/reset/hisilicon,hi3660-reset.yaml | 1 - .../devicetree/bindings/reset/intel,rcu-gw.yaml | 1 - .../bindings/rtc/microcrystal,rv3032.yaml | 1 - .../bindings/soc/litex/litex,soc-controller.yaml | 1 - .../devicetree/bindings/sound/st,stm32-sai.yaml | 2 -- .../bindings/sound/ti,j721e-cpb-audio.yaml | 2 -- .../bindings/sound/ti,j721e-cpb-ivi-audio.yaml | 2 -- 17 files changed, 5 insertions(+), 44 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/allwinner,sun8i-a83t-dw-hdmi.yaml b/Documentation/devicetree/bindings/display/allwinner,sun8i-a83t-dw-hdmi.yaml index 5d42d36608d9..4951b5ef5c6a 100644 --- a/Documentation/devicetree/bindings/display/allwinner,sun8i-a83t-dw-hdmi.yaml +++ b/Documentation/devicetree/bindings/display/allwinner,sun8i-a83t-dw-hdmi.yaml @@ -174,7 +174,6 @@ examples: phy-names = "phy"; pinctrl-names = "default"; pinctrl-0 = <&hdmi_pins>; - status = "disabled"; ports { #address-cells = <1>; @@ -233,7 +232,6 @@ examples: phy-names = "phy"; pinctrl-names = "default"; pinctrl-0 = <&hdmi_pins>; - status = "disabled"; ports { #address-cells = <1>; diff --git a/Documentation/devicetree/bindings/display/panel/boe,tv101wum-nl6.yaml b/Documentation/devicetree/bindings/display/panel/boe,tv101wum-nl6.yaml index 38bc1d1b511e..b87a2e28c866 100644 --- a/Documentation/devicetree/bindings/display/panel/boe,tv101wum-nl6.yaml +++ b/Documentation/devicetree/bindings/display/panel/boe,tv101wum-nl6.yaml @@ -70,7 +70,6 @@ examples: avee-supply = <&ppvarp_lcd>; pp1800-supply = <&pp1800_lcd>; backlight = <&backlight_lcd0>; - status = "okay"; port { panel_in: endpoint { remote-endpoint = <&dsi_out>; diff --git a/Documentation/devicetree/bindings/media/nxp,imx7-mipi-csi2.yaml b/Documentation/devicetree/bindings/media/nxp,imx7-mipi-csi2.yaml index 7c09eec78ce5..877183cf4278 100644 --- a/Documentation/devicetree/bindings/media/nxp,imx7-mipi-csi2.yaml +++ b/Documentation/devicetree/bindings/media/nxp,imx7-mipi-csi2.yaml @@ -200,8 +200,6 @@ examples: clock-names = "pclk", "wrap", "phy", "axi"; power-domains = <&mipi_pd>; - status = "disabled"; - ports { #address-cells = <1>; #size-cells = <0>; diff --git a/Documentation/devicetree/bindings/media/renesas,drif.yaml b/Documentation/devicetree/bindings/media/renesas,drif.yaml index 2867d11fe156..9403b235e976 100644 --- a/Documentation/devicetree/bindings/media/renesas,drif.yaml +++ b/Documentation/devicetree/bindings/media/renesas,drif.yaml @@ -242,7 +242,6 @@ examples: power-domains = <&sysc R8A7795_PD_ALWAYS_ON>; resets = <&cpg 513>; renesas,bonding = <&drif11>; - status = "disabled"; }; drif11: rif@e6f70000 { diff --git a/Documentation/devicetree/bindings/net/intel,dwmac-plat.yaml b/Documentation/devicetree/bindings/net/intel,dwmac-plat.yaml index c1948ce00081..08a3f1f6aea2 100644 --- a/Documentation/devicetree/bindings/net/intel,dwmac-plat.yaml +++ b/Documentation/devicetree/bindings/net/intel,dwmac-plat.yaml @@ -116,7 +116,6 @@ examples: snps,mtl-rx-config = <&mtl_rx_setup>; snps,mtl-tx-config = <&mtl_tx_setup>; snps,tso; - status = "okay"; mdio0 { #address-cells = <1>; diff --git a/Documentation/devicetree/bindings/net/intel,ixp4xx-ethernet.yaml b/Documentation/devicetree/bindings/net/intel,ixp4xx-ethernet.yaml index f2e91d1bf7d7..378ed2d3b003 100644 --- a/Documentation/devicetree/bindings/net/intel,ixp4xx-ethernet.yaml +++ b/Documentation/devicetree/bindings/net/intel,ixp4xx-ethernet.yaml @@ -71,7 +71,6 @@ examples: ethernet@c8009000 { compatible = "intel,ixp4xx-ethernet"; reg = <0xc8009000 0x1000>; - status = "disabled"; queue-rx = <&qmgr 4>; queue-txready = <&qmgr 21>; intel,npe-handle = <&npe 1>; @@ -82,7 +81,6 @@ examples: ethernet@c800c000 { compatible = "intel,ixp4xx-ethernet"; reg = <0xc800c000 0x1000>; - status = "disabled"; queue-rx = <&qmgr 3>; queue-txready = <&qmgr 20>; intel,npe-handle = <&npe 2>; diff --git a/Documentation/devicetree/bindings/net/nfc/samsung,s3fwrn5.yaml b/Documentation/devicetree/bindings/net/nfc/samsung,s3fwrn5.yaml index 081742c2b726..64995cbb0f97 100644 --- a/Documentation/devicetree/bindings/net/nfc/samsung,s3fwrn5.yaml +++ b/Documentation/devicetree/bindings/net/nfc/samsung,s3fwrn5.yaml @@ -90,14 +90,11 @@ examples: # UART example on Raspberry Pi - | uart0 { - status = "okay"; - nfc { compatible = "samsung,s3fwrn82"; en-gpios = <&gpio 20 GPIO_ACTIVE_HIGH>; wake-gpios = <&gpio 16 GPIO_ACTIVE_HIGH>; - status = "okay"; }; }; diff --git a/Documentation/devicetree/bindings/net/qca,ar71xx.yaml b/Documentation/devicetree/bindings/net/qca,ar71xx.yaml index f0db22645d73..cf4d35edaa1b 100644 --- a/Documentation/devicetree/bindings/net/qca,ar71xx.yaml +++ b/Documentation/devicetree/bindings/net/qca,ar71xx.yaml @@ -101,8 +101,6 @@ examples: phy-mode = "gmii"; - status = "disabled"; - fixed-link { speed = <1000>; full-duplex; @@ -148,32 +146,24 @@ examples: reg = <0x1>; phy-handle = <&phy_port0>; phy-mode = "internal"; - - status = "disabled"; }; switch_port2: port@2 { reg = <0x2>; phy-handle = <&phy_port1>; phy-mode = "internal"; - - status = "disabled"; }; switch_port3: port@3 { reg = <0x3>; phy-handle = <&phy_port2>; phy-mode = "internal"; - - status = "disabled"; }; switch_port4: port@4 { reg = <0x4>; phy-handle = <&phy_port3>; phy-mode = "internal"; - - status = "disabled"; }; }; @@ -183,34 +173,29 @@ examples: interrupt-parent = <&switch10>; - phy_port0: phy@0 { + phy_port0: ethernet-phy@0 { reg = <0x0>; interrupts = <0>; - status = "disabled"; }; - phy_port1: phy@1 { + phy_port1: ethernet-phy@1 { reg = <0x1>; interrupts = <0>; - status = "disabled"; }; - phy_port2: phy@2 { + phy_port2: ethernet-phy@2 { reg = <0x2>; interrupts = <0>; - status = "disabled"; }; - phy_port3: phy@3 { + phy_port3: ethernet-phy@3 { reg = <0x3>; interrupts = <0>; - status = "disabled"; }; - phy_port4: phy@4 { + phy_port4: ethernet-phy@4 { reg = <0x4>; interrupts = <0>; - status = "disabled"; }; }; }; diff --git a/Documentation/devicetree/bindings/regulator/richtek,rt6245-regulator.yaml b/Documentation/devicetree/bindings/regulator/richtek,rt6245-regulator.yaml index 796ceac87445..e983d0e70c9b 100644 --- a/Documentation/devicetree/bindings/regulator/richtek,rt6245-regulator.yaml +++ b/Documentation/devicetree/bindings/regulator/richtek,rt6245-regulator.yaml @@ -77,7 +77,6 @@ examples: rt6245@34 { compatible = "richtek,rt6245"; - status = "okay"; reg = <0x34>; enable-gpios = <&gpio26 2 0>; diff --git a/Documentation/devicetree/bindings/regulator/vqmmc-ipq4019-regulator.yaml b/Documentation/devicetree/bindings/regulator/vqmmc-ipq4019-regulator.yaml index 6f45582c914e..dd7a2f92634c 100644 --- a/Documentation/devicetree/bindings/regulator/vqmmc-ipq4019-regulator.yaml +++ b/Documentation/devicetree/bindings/regulator/vqmmc-ipq4019-regulator.yaml @@ -39,6 +39,5 @@ examples: regulator-min-microvolt = <1500000>; regulator-max-microvolt = <3000000>; regulator-always-on; - status = "disabled"; }; ... diff --git a/Documentation/devicetree/bindings/reset/hisilicon,hi3660-reset.yaml b/Documentation/devicetree/bindings/reset/hisilicon,hi3660-reset.yaml index 9bf40952e5b7..b0c41ab1a746 100644 --- a/Documentation/devicetree/bindings/reset/hisilicon,hi3660-reset.yaml +++ b/Documentation/devicetree/bindings/reset/hisilicon,hi3660-reset.yaml @@ -72,6 +72,5 @@ examples: resets = <&iomcu_rst 0x20 3>; pinctrl-names = "default"; pinctrl-0 = <&i2c0_pmx_func &i2c0_cfg_func>; - status = "disabled"; }; ... diff --git a/Documentation/devicetree/bindings/reset/intel,rcu-gw.yaml b/Documentation/devicetree/bindings/reset/intel,rcu-gw.yaml index 6b2d56cc3f38..13bf6bb3f097 100644 --- a/Documentation/devicetree/bindings/reset/intel,rcu-gw.yaml +++ b/Documentation/devicetree/bindings/reset/intel,rcu-gw.yaml @@ -57,7 +57,6 @@ examples: }; pwm: pwm@e0d00000 { - status = "disabled"; compatible = "intel,lgm-pwm"; reg = <0xe0d00000 0x30>; clocks = <&cgu0 1>; diff --git a/Documentation/devicetree/bindings/rtc/microcrystal,rv3032.yaml b/Documentation/devicetree/bindings/rtc/microcrystal,rv3032.yaml index a2c55303810d..9593840a4a2b 100644 --- a/Documentation/devicetree/bindings/rtc/microcrystal,rv3032.yaml +++ b/Documentation/devicetree/bindings/rtc/microcrystal,rv3032.yaml @@ -53,7 +53,6 @@ examples: rtc@51 { compatible = "microcrystal,rv3032"; reg = <0x51>; - status = "okay"; pinctrl-0 = <&rtc_nint_pins>; interrupts-extended = <&gpio1 16 IRQ_TYPE_LEVEL_HIGH>; trickle-resistor-ohms = <7000>; diff --git a/Documentation/devicetree/bindings/soc/litex/litex,soc-controller.yaml b/Documentation/devicetree/bindings/soc/litex/litex,soc-controller.yaml index c8b57c7fd08c..ecae9fa8561b 100644 --- a/Documentation/devicetree/bindings/soc/litex/litex,soc-controller.yaml +++ b/Documentation/devicetree/bindings/soc/litex/litex,soc-controller.yaml @@ -35,7 +35,6 @@ examples: soc_ctrl0: soc-controller@f0000000 { compatible = "litex,soc-controller"; reg = <0xf0000000 0xc>; - status = "okay"; }; ... diff --git a/Documentation/devicetree/bindings/sound/st,stm32-sai.yaml b/Documentation/devicetree/bindings/sound/st,stm32-sai.yaml index 06e83461705c..f97132400bb6 100644 --- a/Documentation/devicetree/bindings/sound/st,stm32-sai.yaml +++ b/Documentation/devicetree/bindings/sound/st,stm32-sai.yaml @@ -180,7 +180,6 @@ examples: pinctrl-names = "default", "sleep"; pinctrl-0 = <&sai2a_pins_a>, <&sai2b_pins_b>; pinctrl-1 = <&sai2a_sleep_pins_a>, <&sai2b_sleep_pins_b>; - status = "okay"; sai2a: audio-controller@4400b004 { #sound-dai-cells = <0>; @@ -190,7 +189,6 @@ examples: dma-names = "tx"; clocks = <&rcc SAI2_K>; clock-names = "sai_ck"; - status = "okay"; }; }; diff --git a/Documentation/devicetree/bindings/sound/ti,j721e-cpb-audio.yaml b/Documentation/devicetree/bindings/sound/ti,j721e-cpb-audio.yaml index ec06789b21df..6806f53a4aed 100644 --- a/Documentation/devicetree/bindings/sound/ti,j721e-cpb-audio.yaml +++ b/Documentation/devicetree/bindings/sound/ti,j721e-cpb-audio.yaml @@ -127,8 +127,6 @@ examples: compatible = "ti,j721e-cpb-audio"; model = "j721e-cpb"; - status = "okay"; - ti,cpb-mcasp = <&mcasp10>; ti,cpb-codec = <&pcm3168a_1>; diff --git a/Documentation/devicetree/bindings/sound/ti,j721e-cpb-ivi-audio.yaml b/Documentation/devicetree/bindings/sound/ti,j721e-cpb-ivi-audio.yaml index ee9f960de36b..859d369c71e2 100644 --- a/Documentation/devicetree/bindings/sound/ti,j721e-cpb-ivi-audio.yaml +++ b/Documentation/devicetree/bindings/sound/ti,j721e-cpb-ivi-audio.yaml @@ -119,8 +119,6 @@ examples: compatible = "ti,j721e-cpb-ivi-audio"; model = "j721e-cpb-ivi"; - status = "okay"; - ti,cpb-mcasp = <&mcasp10>; ti,cpb-codec = <&pcm3168a_1>; -- cgit v1.2.3 From cba3c40d1f97adc89537f6b26b66182a23280ce3 Mon Sep 17 00:00:00 2001 From: Fabien Parent Date: Wed, 19 May 2021 18:18:44 +0200 Subject: dt-bindings: arm: mediatek: mmsys: convert to YAML format Convert the mmsys bindings to the YAML format. Signed-off-by: Fabien Parent Reviewed-by: Rob Herring Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20210519161847.3747352-1-fparent@baylibre.com --- .../bindings/arm/mediatek/mediatek,mmsys.txt | 31 ------------ .../bindings/arm/mediatek/mediatek,mmsys.yaml | 57 ++++++++++++++++++++++ 2 files changed, 57 insertions(+), 31 deletions(-) delete mode 100644 Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.txt create mode 100644 Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.txt b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.txt deleted file mode 100644 index 78c50733985c..000000000000 --- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.txt +++ /dev/null @@ -1,31 +0,0 @@ -Mediatek mmsys controller -============================ - -The Mediatek mmsys system controller provides clock control, routing control, -and miscellaneous control in mmsys partition. - -Required Properties: - -- compatible: Should be one of: - - "mediatek,mt2701-mmsys", "syscon" - - "mediatek,mt2712-mmsys", "syscon" - - "mediatek,mt6765-mmsys", "syscon" - - "mediatek,mt6779-mmsys", "syscon" - - "mediatek,mt6797-mmsys", "syscon" - - "mediatek,mt7623-mmsys", "mediatek,mt2701-mmsys", "syscon" - - "mediatek,mt8167-mmsys", "syscon" - - "mediatek,mt8173-mmsys", "syscon" - - "mediatek,mt8183-mmsys", "syscon" -- #clock-cells: Must be 1 - -For the clock control, the mmsys 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: - -mmsys: syscon@14000000 { - compatible = "mediatek,mt8173-mmsys", "syscon"; - reg = <0 0x14000000 0 0x1000>; - #clock-cells = <1>; -}; diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml new file mode 100644 index 000000000000..a419da33e10b --- /dev/null +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml @@ -0,0 +1,57 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/arm/mediatek/mediatek,mmsys.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: MediaTek mmsys controller + +maintainers: + - Matthias Brugger + +description: + The MediaTek mmsys system controller provides clock control, routing control, + and miscellaneous control in mmsys partition. + +properties: + $nodename: + pattern: "^syscon@[0-9a-f]+$" + + compatible: + oneOf: + - items: + - enum: + - mediatek,mt2701-mmsys + - mediatek,mt2712-mmsys + - mediatek,mt6765-mmsys + - mediatek,mt6779-mmsys + - mediatek,mt6797-mmsys + - mediatek,mt8167-mmsys + - mediatek,mt8173-mmsys + - mediatek,mt8183-mmsys + - const: syscon + - items: + - const: mediatek,mt7623-mmsys + - const: mediatek,mt2701-mmsys + - const: syscon + + reg: + maxItems: 1 + + "#clock-cells": + const: 1 + +required: + - compatible + - reg + - "#clock-cells" + +additionalProperties: false + +examples: + - | + mmsys: syscon@14000000 { + compatible = "mediatek,mt8173-mmsys", "syscon"; + reg = <0x14000000 0x1000>; + #clock-cells = <1>; + }; -- cgit v1.2.3 From f72999f51da1ae39e59e08ed8658e7a470d6fee5 Mon Sep 17 00:00:00 2001 From: Fabien Parent Date: Wed, 19 May 2021 18:18:45 +0200 Subject: dt-bindings: arm: mediatek: mmsys: add MT8365 SoC binding Add the MMSYS binding documentation for the MT8365 SoC. Signed-off-by: Fabien Parent Reviewed-by: Rob Herring Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20210519161847.3747352-2-fparent@baylibre.com --- Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml index a419da33e10b..2d4ff0ce387b 100644 --- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml @@ -29,6 +29,7 @@ properties: - mediatek,mt8167-mmsys - mediatek,mt8173-mmsys - mediatek,mt8183-mmsys + - mediatek,mt8365-mmsys - const: syscon - items: - const: mediatek,mt7623-mmsys -- cgit v1.2.3 From 5c872e1d25958aaa9102c57ab8bc4ca591b0e363 Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Sat, 24 Jul 2021 10:41:45 +0200 Subject: dt-bindings: hisilicon,hi6421-spmi-pmic.yaml: make some rules stricter Define maxItems for interrupts and accept only "ldo" in lower case. Reviewed-by: Rob Herring Signed-off-by: Mauro Carvalho Chehab Link: https://lore.kernel.org/r/b7a775808d9c3a87fbe1c5a6dd71f8f18be7e649.1627116034.git.mchehab+huawei@kernel.org Signed-off-by: Greg Kroah-Hartman --- .../bindings/mfd/hisilicon,hi6421-spmi-pmic.yaml | 21 +++++++++++---------- 1 file changed, 11 insertions(+), 10 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mfd/hisilicon,hi6421-spmi-pmic.yaml b/Documentation/devicetree/bindings/mfd/hisilicon,hi6421-spmi-pmic.yaml index cedf9d99a34b..22edcb4b212f 100644 --- a/Documentation/devicetree/bindings/mfd/hisilicon,hi6421-spmi-pmic.yaml +++ b/Documentation/devicetree/bindings/mfd/hisilicon,hi6421-spmi-pmic.yaml @@ -34,7 +34,8 @@ properties: interrupt-controller: true - interrupts: true + interrupts: + maxItems: 1 regulators: type: object @@ -49,7 +50,7 @@ properties: const: 0 patternProperties: - '^(ldo|LDO)[0-9]+$': + '^ldo[0-9]+$': type: object $ref: "/schemas/regulator/regulator.yaml#" @@ -79,55 +80,55 @@ examples: #address-cells = <1>; #size-cells = <0>; - ldo3: LDO3 { + ldo3: ldo3 { regulator-name = "ldo3"; regulator-min-microvolt = <1500000>; regulator-max-microvolt = <2000000>; regulator-boot-on; }; - ldo4: LDO4 { + ldo4: ldo4 { regulator-name = "ldo4"; regulator-min-microvolt = <1725000>; regulator-max-microvolt = <1900000>; regulator-boot-on; }; - ldo9: LDO9 { + ldo9: ldo9 { regulator-name = "ldo9"; regulator-min-microvolt = <1750000>; regulator-max-microvolt = <3300000>; regulator-boot-on; }; - ldo15: LDO15 { + ldo15: ldo15 { regulator-name = "ldo15"; regulator-min-microvolt = <1800000>; regulator-max-microvolt = <3000000>; regulator-always-on; }; - ldo16: LDO16 { + ldo16: ldo16 { regulator-name = "ldo16"; regulator-min-microvolt = <1800000>; regulator-max-microvolt = <3000000>; regulator-boot-on; }; - ldo17: LDO17 { + ldo17: ldo17 { regulator-name = "ldo17"; regulator-min-microvolt = <2500000>; regulator-max-microvolt = <3300000>; }; - ldo33: LDO33 { + ldo33: ldo33 { regulator-name = "ldo33"; regulator-min-microvolt = <2500000>; regulator-max-microvolt = <3300000>; regulator-boot-on; }; - ldo34: LDO34 { + ldo34: ldo34 { regulator-name = "ldo34"; regulator-min-microvolt = <2600000>; regulator-max-microvolt = <3300000>; -- cgit v1.2.3 From 4a803990aeb1582d32e7661e57863cc189a15446 Mon Sep 17 00:00:00 2001 From: Chun-Jie Chen Date: Mon, 26 Jul 2021 18:56:59 +0800 Subject: dt-bindings: ARM: Mediatek: Add new document bindings of MT8192 clock This patch adds the new binding documentation for system clock and functional clock on Mediatek MT8192. Signed-off-by: Chun-Jie Chen Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20210726105719.15793-2-chun-jie.chen@mediatek.com Signed-off-by: Stephen Boyd --- .../arm/mediatek/mediatek,mt8192-clock.yaml | 199 +++++++++++++++++++++ .../arm/mediatek/mediatek,mt8192-sys-clock.yaml | 65 +++++++ 2 files changed, 264 insertions(+) create mode 100644 Documentation/devicetree/bindings/arm/mediatek/mediatek,mt8192-clock.yaml create mode 100644 Documentation/devicetree/bindings/arm/mediatek/mediatek,mt8192-sys-clock.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mt8192-clock.yaml b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mt8192-clock.yaml new file mode 100644 index 000000000000..c8c67c033f8c --- /dev/null +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mt8192-clock.yaml @@ -0,0 +1,199 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/arm/mediatek/mediatek,mt8192-clock.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: MediaTek Functional Clock Controller for MT8192 + +maintainers: + - Chun-Jie Chen + +description: + The Mediatek functional clock controller provides various clocks on MT8192. + +properties: + compatible: + items: + - enum: + - mediatek,mt8192-scp_adsp + - mediatek,mt8192-imp_iic_wrap_c + - mediatek,mt8192-imp_iic_wrap_e + - mediatek,mt8192-imp_iic_wrap_s + - mediatek,mt8192-imp_iic_wrap_ws + - mediatek,mt8192-imp_iic_wrap_w + - mediatek,mt8192-imp_iic_wrap_n + - mediatek,mt8192-msdc_top + - mediatek,mt8192-msdc + - mediatek,mt8192-mfgcfg + - mediatek,mt8192-imgsys + - mediatek,mt8192-imgsys2 + - mediatek,mt8192-vdecsys_soc + - mediatek,mt8192-vdecsys + - mediatek,mt8192-vencsys + - mediatek,mt8192-camsys + - mediatek,mt8192-camsys_rawa + - mediatek,mt8192-camsys_rawb + - mediatek,mt8192-camsys_rawc + - mediatek,mt8192-ipesys + - mediatek,mt8192-mdpsys + + reg: + maxItems: 1 + + '#clock-cells': + const: 1 + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + scp_adsp: clock-controller@10720000 { + compatible = "mediatek,mt8192-scp_adsp"; + reg = <0x10720000 0x1000>; + #clock-cells = <1>; + }; + + - | + imp_iic_wrap_c: clock-controller@11007000 { + compatible = "mediatek,mt8192-imp_iic_wrap_c"; + reg = <0x11007000 0x1000>; + #clock-cells = <1>; + }; + + - | + imp_iic_wrap_e: clock-controller@11cb1000 { + compatible = "mediatek,mt8192-imp_iic_wrap_e"; + reg = <0x11cb1000 0x1000>; + #clock-cells = <1>; + }; + + - | + imp_iic_wrap_s: clock-controller@11d03000 { + compatible = "mediatek,mt8192-imp_iic_wrap_s"; + reg = <0x11d03000 0x1000>; + #clock-cells = <1>; + }; + + - | + imp_iic_wrap_ws: clock-controller@11d23000 { + compatible = "mediatek,mt8192-imp_iic_wrap_ws"; + reg = <0x11d23000 0x1000>; + #clock-cells = <1>; + }; + + - | + imp_iic_wrap_w: clock-controller@11e01000 { + compatible = "mediatek,mt8192-imp_iic_wrap_w"; + reg = <0x11e01000 0x1000>; + #clock-cells = <1>; + }; + + - | + imp_iic_wrap_n: clock-controller@11f02000 { + compatible = "mediatek,mt8192-imp_iic_wrap_n"; + reg = <0x11f02000 0x1000>; + #clock-cells = <1>; + }; + + - | + msdc_top: clock-controller@11f10000 { + compatible = "mediatek,mt8192-msdc_top"; + reg = <0x11f10000 0x1000>; + #clock-cells = <1>; + }; + + - | + msdc: clock-controller@11f60000 { + compatible = "mediatek,mt8192-msdc"; + reg = <0x11f60000 0x1000>; + #clock-cells = <1>; + }; + + - | + mfgcfg: clock-controller@13fbf000 { + compatible = "mediatek,mt8192-mfgcfg"; + reg = <0x13fbf000 0x1000>; + #clock-cells = <1>; + }; + + - | + imgsys: clock-controller@15020000 { + compatible = "mediatek,mt8192-imgsys"; + reg = <0x15020000 0x1000>; + #clock-cells = <1>; + }; + + - | + imgsys2: clock-controller@15820000 { + compatible = "mediatek,mt8192-imgsys2"; + reg = <0x15820000 0x1000>; + #clock-cells = <1>; + }; + + - | + vdecsys_soc: clock-controller@1600f000 { + compatible = "mediatek,mt8192-vdecsys_soc"; + reg = <0x1600f000 0x1000>; + #clock-cells = <1>; + }; + + - | + vdecsys: clock-controller@1602f000 { + compatible = "mediatek,mt8192-vdecsys"; + reg = <0x1602f000 0x1000>; + #clock-cells = <1>; + }; + + - | + vencsys: clock-controller@17000000 { + compatible = "mediatek,mt8192-vencsys"; + reg = <0x17000000 0x1000>; + #clock-cells = <1>; + }; + + - | + camsys: clock-controller@1a000000 { + compatible = "mediatek,mt8192-camsys"; + reg = <0x1a000000 0x1000>; + #clock-cells = <1>; + }; + + - | + camsys_rawa: clock-controller@1a04f000 { + compatible = "mediatek,mt8192-camsys_rawa"; + reg = <0x1a04f000 0x1000>; + #clock-cells = <1>; + }; + + - | + camsys_rawb: clock-controller@1a06f000 { + compatible = "mediatek,mt8192-camsys_rawb"; + reg = <0x1a06f000 0x1000>; + #clock-cells = <1>; + }; + + - | + camsys_rawc: clock-controller@1a08f000 { + compatible = "mediatek,mt8192-camsys_rawc"; + reg = <0x1a08f000 0x1000>; + #clock-cells = <1>; + }; + + - | + ipesys: clock-controller@1b000000 { + compatible = "mediatek,mt8192-ipesys"; + reg = <0x1b000000 0x1000>; + #clock-cells = <1>; + }; + + - | + mdpsys: clock-controller@1f000000 { + compatible = "mediatek,mt8192-mdpsys"; + reg = <0x1f000000 0x1000>; + #clock-cells = <1>; + }; diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mt8192-sys-clock.yaml b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mt8192-sys-clock.yaml new file mode 100644 index 000000000000..5705bcf1fe47 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mt8192-sys-clock.yaml @@ -0,0 +1,65 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/arm/mediatek/mediatek,mt8192-sys-clock.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: MediaTek System Clock Controller for MT8192 + +maintainers: + - Chun-Jie Chen + +description: + The Mediatek system clock controller provides various clocks and system configuration + like reset and bus protection on MT8192. + +properties: + compatible: + items: + - enum: + - mediatek,mt8192-topckgen + - mediatek,mt8192-infracfg + - mediatek,mt8192-pericfg + - mediatek,mt8192-apmixedsys + - const: syscon + + reg: + maxItems: 1 + + '#clock-cells': + const: 1 + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + topckgen: syscon@10000000 { + compatible = "mediatek,mt8192-topckgen", "syscon"; + reg = <0x10000000 0x1000>; + #clock-cells = <1>; + }; + + - | + infracfg: syscon@10001000 { + compatible = "mediatek,mt8192-infracfg", "syscon"; + reg = <0x10001000 0x1000>; + #clock-cells = <1>; + }; + + - | + pericfg: syscon@10003000 { + compatible = "mediatek,mt8192-pericfg", "syscon"; + reg = <0x10003000 0x1000>; + #clock-cells = <1>; + }; + + - | + apmixedsys: syscon@1000c000 { + compatible = "mediatek,mt8192-apmixedsys", "syscon"; + reg = <0x1000c000 0x1000>; + #clock-cells = <1>; + }; -- cgit v1.2.3 From d18eb76bbd6998d57ca647bb0561e10afa404eef Mon Sep 17 00:00:00 2001 From: Chun-Jie Chen Date: Mon, 26 Jul 2021 18:57:00 +0800 Subject: dt-bindings: ARM: Mediatek: Add mmsys document binding for MT8192 This patch adds the mmsys document binding for MT8192 SoC. Signed-off-by: Chun-Jie Chen Reviewed-by: Chun-Kuang Hu Reviewed-by: Matthias Brugger Acked-by: Rob Herring Link: https://lore.kernel.org/r/20210726105719.15793-3-chun-jie.chen@mediatek.com Signed-off-by: Stephen Boyd --- Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.txt b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.txt index 78c50733985c..9712a6831fab 100644 --- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.txt +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.txt @@ -16,6 +16,7 @@ Required Properties: - "mediatek,mt8167-mmsys", "syscon" - "mediatek,mt8173-mmsys", "syscon" - "mediatek,mt8183-mmsys", "syscon" + - "mediatek,mt8192-mmsys", "syscon" - #clock-cells: Must be 1 For the clock control, the mmsys controller uses the common clk binding from -- cgit v1.2.3 From 4af2f62d6fc65e08ca604fab7d7e3beabd927d0d Mon Sep 17 00:00:00 2001 From: Chun-Jie Chen Date: Mon, 26 Jul 2021 18:57:01 +0800 Subject: dt-bindings: ARM: Mediatek: Add audsys document binding for MT8192 This patch adds the audsys document binding for MT8192 SoC. Signed-off-by: Chun-Jie Chen Acked-by: Rob Herring Link: https://lore.kernel.org/r/20210726105719.15793-4-chun-jie.chen@mediatek.com Signed-off-by: Stephen Boyd --- Documentation/devicetree/bindings/arm/mediatek/mediatek,audsys.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,audsys.txt b/Documentation/devicetree/bindings/arm/mediatek/mediatek,audsys.txt index b32d374193c7..699776be1dd3 100644 --- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,audsys.txt +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,audsys.txt @@ -13,6 +13,7 @@ Required Properties: - "mediatek,mt7623-audsys", "mediatek,mt2701-audsys", "syscon" - "mediatek,mt8167-audiosys", "syscon" - "mediatek,mt8183-audiosys", "syscon" + - "mediatek,mt8192-audsys", "syscon" - "mediatek,mt8516-audsys", "syscon" - #clock-cells: Must be 1 -- cgit v1.2.3 From b9067f5dc4a07c8e24e01a1b277c6722d91be39e Mon Sep 17 00:00:00 2001 From: Arnd Bergmann Date: Tue, 27 Jul 2021 15:44:47 +0200 Subject: net: split out SIOCDEVPRIVATE handling from dev_ioctl SIOCDEVPRIVATE ioctl commands are mainly used in really old drivers, and they have a number of problems: - They hide behind the normal .ndo_do_ioctl function that is also used for other things in modern drivers, so it's hard to spot a driver that actually uses one of these - Since drivers use a number different calling conventions, it is impossible to support compat mode for them in a generic way. - With all drivers using the same 16 commands codes, there is no way to introspect the data being passed through things like strace. Add a new net_device_ops callback pointer, to address the first two of these. Separating them from .ndo_do_ioctl makes it easy to grep for drivers with a .ndo_siocdevprivate callback, and the unwieldy name hopefully makes it easier to spot in code review. By passing the ifreq structure and the ifr_data pointer separately, it is no longer necessary to overload these, and the driver can use either one for a given command. Cc: Cong Wang Signed-off-by: Arnd Bergmann Signed-off-by: David S. Miller --- Documentation/networking/netdevices.rst | 7 +++++++ 1 file changed, 7 insertions(+) (limited to 'Documentation') diff --git a/Documentation/networking/netdevices.rst b/Documentation/networking/netdevices.rst index 17bdcb746dcf..02f1faac839a 100644 --- a/Documentation/networking/netdevices.rst +++ b/Documentation/networking/netdevices.rst @@ -222,6 +222,13 @@ ndo_do_ioctl: Synchronization: rtnl_lock() semaphore. Context: process +ndo_siocdevprivate: + Synchronization: rtnl_lock() semaphore. + Context: process + + This is used to implement SIOCDEVPRIVATE ioctl helpers. + These should not be added to new drivers, so don't use. + ndo_get_stats: Synchronization: rtnl_lock() semaphore, dev_base_lock rwlock, or RCU. Context: atomic (can't sleep under rwlock or RCU) -- cgit v1.2.3 From a76053707dbf0dc020a73b4d90cd952409ef3691 Mon Sep 17 00:00:00 2001 From: Arnd Bergmann Date: Tue, 27 Jul 2021 15:45:13 +0200 Subject: dev_ioctl: split out ndo_eth_ioctl Most users of ndo_do_ioctl are ethernet drivers that implement the MII commands SIOCGMIIPHY/SIOCGMIIREG/SIOCSMIIREG, or hardware timestamping with SIOCSHWTSTAMP/SIOCGHWTSTAMP. Separate these from the few drivers that use ndo_do_ioctl to implement SIOCBOND, SIOCBR and SIOCWANDEV commands. This is a purely cosmetic change intended to help readers find their way through the implementation. Cc: Doug Ledford Cc: Jason Gunthorpe Cc: Jay Vosburgh Cc: Veaceslav Falico Cc: Andy Gospodarek Cc: Andrew Lunn Cc: Vivien Didelot Cc: Florian Fainelli Cc: Vladimir Oltean Cc: Leon Romanovsky Cc: linux-rdma@vger.kernel.org Signed-off-by: Arnd Bergmann Acked-by: Jason Gunthorpe Signed-off-by: David S. Miller --- Documentation/networking/netdevices.rst | 4 ++++ Documentation/networking/timestamping.rst | 6 +++--- 2 files changed, 7 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/networking/netdevices.rst b/Documentation/networking/netdevices.rst index 02f1faac839a..f57f255f2397 100644 --- a/Documentation/networking/netdevices.rst +++ b/Documentation/networking/netdevices.rst @@ -229,6 +229,10 @@ ndo_siocdevprivate: This is used to implement SIOCDEVPRIVATE ioctl helpers. These should not be added to new drivers, so don't use. +ndo_eth_ioctl: + Synchronization: rtnl_lock() semaphore. + Context: process + ndo_get_stats: Synchronization: rtnl_lock() semaphore, dev_base_lock rwlock, or RCU. Context: atomic (can't sleep under rwlock or RCU) diff --git a/Documentation/networking/timestamping.rst b/Documentation/networking/timestamping.rst index 7db3985359bc..a722eb30e014 100644 --- a/Documentation/networking/timestamping.rst +++ b/Documentation/networking/timestamping.rst @@ -625,7 +625,7 @@ interfaces of a DSA switch to share the same PHC. By design, PTP timestamping with a DSA switch does not need any special handling in the driver for the host port it is attached to. However, when the host port also supports PTP timestamping, DSA will take care of intercepting -the ``.ndo_do_ioctl`` calls towards the host port, and block attempts to enable +the ``.ndo_eth_ioctl`` calls towards the host port, and block attempts to enable hardware timestamping on it. This is because the SO_TIMESTAMPING API does not allow the delivery of multiple hardware timestamps for the same packet, so anybody else except for the DSA switch port must be prevented from doing so. @@ -688,7 +688,7 @@ ethtool ioctl operations for them need to be mediated by their respective MAC driver. Therefore, as opposed to DSA switches, modifications need to be done to each individual MAC driver for PHY timestamping support. This entails: -- Checking, in ``.ndo_do_ioctl``, whether ``phy_has_hwtstamp(netdev->phydev)`` +- Checking, in ``.ndo_eth_ioctl``, whether ``phy_has_hwtstamp(netdev->phydev)`` is true or not. If it is, then the MAC driver should not process this request but instead pass it on to the PHY using ``phy_mii_ioctl()``. @@ -747,7 +747,7 @@ For example, a typical driver design for TX timestamping might be to split the transmission part into 2 portions: 1. "TX": checks whether PTP timestamping has been previously enabled through - the ``.ndo_do_ioctl`` ("``priv->hwtstamp_tx_enabled == true``") and the + the ``.ndo_eth_ioctl`` ("``priv->hwtstamp_tx_enabled == true``") and the current skb requires a TX timestamp ("``skb_shinfo(skb)->tx_flags & SKBTX_HW_TSTAMP``"). If this is true, it sets the "``skb_shinfo(skb)->tx_flags |= SKBTX_IN_PROGRESS``" flag. Note: as -- cgit v1.2.3 From ad7eab2ab014748b062507b7ac69f8e856057717 Mon Sep 17 00:00:00 2001 From: Arnd Bergmann Date: Tue, 27 Jul 2021 15:45:14 +0200 Subject: net: split out ndo_siowandev ioctl In order to further reduce the scope of ndo_do_ioctl(), move out the SIOCWANDEV handling into a new network device operation function. Adjust the prototype to only pass the if_settings sub-structure in place of the ifreq, and remove the redundant 'cmd' argument in the process. Cc: Krzysztof Halasa Cc: "Jan \"Yenya\" Kasprzak" Cc: Kevin Curtis Cc: Zhao Qiang Cc: Martin Schiller Cc: Jiri Slaby Cc: linux-x25@vger.kernel.org Signed-off-by: Arnd Bergmann Signed-off-by: David S. Miller --- Documentation/networking/netdevices.rst | 7 +++++++ 1 file changed, 7 insertions(+) (limited to 'Documentation') diff --git a/Documentation/networking/netdevices.rst b/Documentation/networking/netdevices.rst index f57f255f2397..3c42b0b0be93 100644 --- a/Documentation/networking/netdevices.rst +++ b/Documentation/networking/netdevices.rst @@ -222,6 +222,13 @@ ndo_do_ioctl: Synchronization: rtnl_lock() semaphore. Context: process +ndo_siocwandev: + Synchronization: rtnl_lock() semaphore. + Context: process + + Used by the drivers/net/wan framework to handle + the SIOCWANDEV ioctl with the if_settings structure. + ndo_siocdevprivate: Synchronization: rtnl_lock() semaphore. Context: process -- cgit v1.2.3 From 3d9d00bd1885afa6b2c766cf9bab7b54b1a951ed Mon Sep 17 00:00:00 2001 From: Arnd Bergmann Date: Tue, 27 Jul 2021 15:45:17 +0200 Subject: net: bonding: move ioctl handling to private ndo operation All other user triggered operations are gone from ndo_ioctl, so move the SIOCBOND family into a custom operation as well. The .ndo_ioctl() helper is no longer called by the dev_ioctl.c code now, but there are still a few definitions in obsolete wireless drivers as well as the appletalk and ieee802154 layers to call SIOCSIFADDR/SIOCGIFADDR helpers from inside the kernel. Cc: Jay Vosburgh Cc: Veaceslav Falico Cc: Andy Gospodarek Signed-off-by: Arnd Bergmann Signed-off-by: David S. Miller --- Documentation/networking/netdevices.rst | 11 +++++++++++ 1 file changed, 11 insertions(+) (limited to 'Documentation') diff --git a/Documentation/networking/netdevices.rst b/Documentation/networking/netdevices.rst index 3c42b0b0be93..9e4cccb90b87 100644 --- a/Documentation/networking/netdevices.rst +++ b/Documentation/networking/netdevices.rst @@ -222,6 +222,17 @@ ndo_do_ioctl: Synchronization: rtnl_lock() semaphore. Context: process + This is only called by network subsystems internally, + not by user space calling ioctl as it was in before + linux-5.14. + +ndo_siocbond: + Synchronization: rtnl_lock() semaphore. + Context: process + + Used by the bonding driver for the SIOCBOND family of + ioctl commands. + ndo_siocwandev: Synchronization: rtnl_lock() semaphore. Context: process -- cgit v1.2.3 From 04a572c51a33bdebf9e31afb874fb36a8d2a6c17 Mon Sep 17 00:00:00 2001 From: Iskren Chernev Date: Sun, 27 Jun 2021 21:59:24 +0300 Subject: dt-bindings: clock: qcom: rpmcc: Document SM6115 compatible Add the dt-binding for the RPM Clock Controller on the SM4250/6115 SoCs. Signed-off-by: Iskren Chernev Link: https://lore.kernel.org/r/20210627185927.695411-3-iskren.chernev@gmail.com Acked-by: Rob Herring 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 6cf5a7ec2b4c..0045583f02b5 100644 --- a/Documentation/devicetree/bindings/clock/qcom,rpmcc.txt +++ b/Documentation/devicetree/bindings/clock/qcom,rpmcc.txt @@ -25,6 +25,7 @@ Required properties : "qcom,rpmcc-msm8998", "qcom,rpmcc" "qcom,rpmcc-qcs404", "qcom,rpmcc" "qcom,rpmcc-sdm660", "qcom,rpmcc" + "qcom,rpmcc-sm6115", "qcom,rpmcc" - #clock-cells : shall contain 1 -- cgit v1.2.3 From 4b1ec711ec2e97fca93adf6640fa5fd61fc17827 Mon Sep 17 00:00:00 2001 From: Martin Botka Date: Tue, 29 Jun 2021 12:26:22 +0200 Subject: dt-bindings: clk: qcom: smd-rpm: Document SM6125 compatible Document the newly added compatible for sm6125 rpmcc. Signed-off-by: Martin Botka Link: https://lore.kernel.org/r/20210629102624.194378-3-martin.botka@somainline.org Acked-by: Rob Herring 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 0045583f02b5..0e92747e53da 100644 --- a/Documentation/devicetree/bindings/clock/qcom,rpmcc.txt +++ b/Documentation/devicetree/bindings/clock/qcom,rpmcc.txt @@ -26,6 +26,7 @@ Required properties : "qcom,rpmcc-qcs404", "qcom,rpmcc" "qcom,rpmcc-sdm660", "qcom,rpmcc" "qcom,rpmcc-sm6115", "qcom,rpmcc" + "qcom,rpmcc-sm6125", "qcom,rpmcc" - #clock-cells : shall contain 1 -- cgit v1.2.3 From 4aece33cacf726d34ecd8824aee369652ec2beec Mon Sep 17 00:00:00 2001 From: Olivier Dautricourt Date: Thu, 17 Jun 2021 21:52:32 +0200 Subject: dt-bindings: dma: altera-msgdma: make response port optional Response port is not required in some configuration of the IP core. Signed-off-by: Olivier Dautricourt Reviewed-by: Rob Herring Reviewed-by: Stefan Roese Link: https://lore.kernel.org/r/fb28146a23a182be9e5435c1d3e5cac36b372294.1623898678.git.olivier.dautricourt@orolia.com Signed-off-by: Vinod Koul --- Documentation/devicetree/bindings/dma/altr,msgdma.yaml | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/dma/altr,msgdma.yaml b/Documentation/devicetree/bindings/dma/altr,msgdma.yaml index a4f9fe23dcd9..b193ee2db4a7 100644 --- a/Documentation/devicetree/bindings/dma/altr,msgdma.yaml +++ b/Documentation/devicetree/bindings/dma/altr,msgdma.yaml @@ -24,13 +24,15 @@ properties: items: - description: Control and Status Register Slave Port - description: Descriptor Slave Port - - description: Response Slave Port + - description: Response Slave Port (Optional) + minItems: 2 reg-names: items: - const: csr - const: desc - const: resp + minItems: 2 interrupts: maxItems: 1 -- cgit v1.2.3 From ef94b0413bf4e0d328989fecf5b773e82c8794ac Mon Sep 17 00:00:00 2001 From: Amelie Delaunay Date: Thu, 24 Jun 2021 11:39:58 +0200 Subject: dt-bindings: dma: add alternative REQ/ACK protocol selection in stm32-dma Default REQ/ACK protocol consists in maintaining ACK signal up to the removal of REQuest and the transfer completion. In case of alternative REQ/ACK protocol, ACK de-assertion does not wait the removal of the REQuest, but only the transfer completion. Due to a possible DMA stream lock when transferring data to/from STM32 USART/UART, this new bindings allow to select this alternative protocol in device tree, especially for STM32 USART/UART nodes. Signed-off-by: Amelie Delaunay Acked-by: Rob Herring Link: https://lore.kernel.org/r/20210624093959.142265-2-amelie.delaunay@foss.st.com Signed-off-by: Vinod Koul --- Documentation/devicetree/bindings/dma/st,stm32-dma.yaml | 7 +++++++ 1 file changed, 7 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/dma/st,stm32-dma.yaml b/Documentation/devicetree/bindings/dma/st,stm32-dma.yaml index 2a5325f480f6..4bf676fd25dc 100644 --- a/Documentation/devicetree/bindings/dma/st,stm32-dma.yaml +++ b/Documentation/devicetree/bindings/dma/st,stm32-dma.yaml @@ -40,6 +40,13 @@ description: | 0x0: FIFO mode with threshold selectable with bit 0-1 0x1: Direct mode: each DMA request immediately initiates a transfer from/to the memory, FIFO is bypassed. + -bit 4: alternative DMA request/acknowledge protocol + 0x0: Use standard DMA ACK management, where ACK signal is maintained + up to the removal of request and transfer completion + 0x1: Use alternative DMA ACK management, where ACK de-assertion does + not wait for the de-assertion of the REQuest, ACK is only managed + by transfer completion. This must only be used on channels + managing transfers for STM32 USART/UART. maintainers: -- cgit v1.2.3 From b7fe54f6c2d437082dcbecfbd832f38edd9caaf4 Mon Sep 17 00:00:00 2001 From: Balbir Singh Date: Fri, 8 Jan 2021 23:10:56 +1100 Subject: Documentation: Add L1D flushing Documentation Add documentation of l1d flushing, explain the need for the feature and how it can be used. Signed-off-by: Balbir Singh Signed-off-by: Thomas Gleixner Link: https://lore.kernel.org/r/20210108121056.21940-6-sblbir@amazon.com --- Documentation/admin-guide/hw-vuln/index.rst | 1 + Documentation/admin-guide/hw-vuln/l1d_flush.rst | 69 +++++++++++++++++++++++++ Documentation/admin-guide/kernel-parameters.txt | 17 ++++++ Documentation/userspace-api/spec_ctrl.rst | 8 +++ 4 files changed, 95 insertions(+) create mode 100644 Documentation/admin-guide/hw-vuln/l1d_flush.rst (limited to 'Documentation') diff --git a/Documentation/admin-guide/hw-vuln/index.rst b/Documentation/admin-guide/hw-vuln/index.rst index f12cda55538b..8cbc711cda93 100644 --- a/Documentation/admin-guide/hw-vuln/index.rst +++ b/Documentation/admin-guide/hw-vuln/index.rst @@ -16,3 +16,4 @@ are configurable at compile, boot or run time. multihit.rst special-register-buffer-data-sampling.rst core-scheduling.rst + l1d_flush.rst diff --git a/Documentation/admin-guide/hw-vuln/l1d_flush.rst b/Documentation/admin-guide/hw-vuln/l1d_flush.rst new file mode 100644 index 000000000000..210020bc3f56 --- /dev/null +++ b/Documentation/admin-guide/hw-vuln/l1d_flush.rst @@ -0,0 +1,69 @@ +L1D Flushing +============ + +With an increasing number of vulnerabilities being reported around data +leaks from the Level 1 Data cache (L1D) the kernel provides an opt-in +mechanism to flush the L1D cache on context switch. + +This mechanism can be used to address e.g. CVE-2020-0550. For applications +the mechanism keeps them safe from vulnerabilities, related to leaks +(snooping of) from the L1D cache. + + +Related CVEs +------------ +The following CVEs can be addressed by this +mechanism + + ============= ======================== ================== + CVE-2020-0550 Improper Data Forwarding OS related aspects + ============= ======================== ================== + +Usage Guidelines +---------------- + +Please see document: :ref:`Documentation/userspace-api/spec_ctrl.rst +` for details. + +**NOTE**: The feature is disabled by default, applications need to +specifically opt into the feature to enable it. + +Mitigation +---------- + +When PR_SET_L1D_FLUSH is enabled for a task a flush of the L1D cache is +performed when the task is scheduled out and the incoming task belongs to a +different process and therefore to a different address space. + +If the underlying CPU supports L1D flushing in hardware, the hardware +mechanism is used, software fallback for the mitigation, is not supported. + +Mitigation control on the kernel command line +--------------------------------------------- + +The kernel command line allows to control the L1D flush mitigations at boot +time with the option "l1d_flush=". The valid arguments for this option are: + + ============ ============================================================= + on Enables the prctl interface, applications trying to use + the prctl() will fail with an error if l1d_flush is not + enabled + ============ ============================================================= + +By default the mechanism is disabled. + +Limitations +----------- + +The mechanism does not mitigate L1D data leaks between tasks belonging to +different processes which are concurrently executing on sibling threads of +a physical CPU core when SMT is enabled on the system. + +This can be addressed by controlled placement of processes on physical CPU +cores or by disabling SMT. See the relevant chapter in the L1TF mitigation +document: :ref:`Documentation/admin-guide/hw-vuln/l1tf.rst `. + +**NOTE** : The opt-in of a task for L1D flushing works only when the task's +affinity is limited to cores running in non-SMT mode. If a task which +requested L1D flushing is scheduled on a SMT-enabled core the kernel sends +a SIGBUS to the task. diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index bdb22006f713..b105db25f7a5 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -2421,6 +2421,23 @@ feature (tagged TLBs) on capable Intel chips. Default is 1 (enabled) + l1d_flush= [X86,INTEL] + Control mitigation for L1D based snooping vulnerability. + + Certain CPUs are vulnerable to an exploit against CPU + internal buffers which can forward information to a + disclosure gadget under certain conditions. + + In vulnerable processors, the speculatively + forwarded data can be used in a cache side channel + attack, to access data to which the attacker does + not have direct access. + + This parameter controls the mitigation. The + options are: + + on - enable the interface for the mitigation + l1tf= [X86] Control mitigation of the L1TF vulnerability on affected CPUs diff --git a/Documentation/userspace-api/spec_ctrl.rst b/Documentation/userspace-api/spec_ctrl.rst index 7ddd8f667459..5e8ed9eef9aa 100644 --- a/Documentation/userspace-api/spec_ctrl.rst +++ b/Documentation/userspace-api/spec_ctrl.rst @@ -106,3 +106,11 @@ Speculation misfeature controls * prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_INDIRECT_BRANCH, PR_SPEC_ENABLE, 0, 0); * prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_INDIRECT_BRANCH, PR_SPEC_DISABLE, 0, 0); * prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_INDIRECT_BRANCH, PR_SPEC_FORCE_DISABLE, 0, 0); + +- PR_SPEC_L1D_FLUSH: Flush L1D Cache on context switch out of the task + (works only when tasks run on non SMT cores) + + Invocations: + * prctl(PR_GET_SPECULATION_CTRL, PR_SPEC_L1D_FLUSH, 0, 0, 0); + * prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_L1D_FLUSH, PR_SPEC_ENABLE, 0, 0); + * prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_L1D_FLUSH, PR_SPEC_DISABLE, 0, 0); -- cgit v1.2.3 From ade8a86b512cf8db0d0e975a971ce356953cfcb3 Mon Sep 17 00:00:00 2001 From: Dave Jiang Date: Tue, 20 Jul 2021 13:42:10 -0700 Subject: dmaengine: idxd: Set defaults for GRPCFG traffic class Set GRPCFG traffic class to value of 1 for best performance on current generation of accelerators. Also add override option to allow experimentation. Sysfs knobs are disabled for DSA/IAX gen1 devices. Signed-off-by: Dave Jiang Link: https://lore.kernel.org/r/162681373005.1968485.3761065664382799202.stgit@djiang5-desk3.ch.intel.com Signed-off-by: Vinod Koul --- Documentation/admin-guide/kernel-parameters.txt | 5 +++++ 1 file changed, 5 insertions(+) (limited to 'Documentation') diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index bdb22006f713..ec5411cdec20 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -1747,6 +1747,11 @@ support for the idxd driver. By default it is set to true (1). + idxd.tc_override= [HW] + Format: + Allow override of default traffic class configuration + for the device. By default it is set to false (0). + ieee754= [MIPS] Select IEEE Std 754 conformance mode Format: { strict | legacy | 2008 | relaxed } Default: strict -- cgit v1.2.3 From 125d10373ad991888c9e94d2da49bcc5ccba2127 Mon Sep 17 00:00:00 2001 From: Dave Jiang Date: Tue, 20 Jul 2021 13:42:15 -0700 Subject: dmanegine: idxd: add software command status Enabling device and wq returns standard errno and that does not provide enough details to indicate what exactly failed. The hardware command status is only 8bits. Expand the command status to 32bits and use the upper 16 bits to define software errors to provide more details on the exact failure. Bit 31 will be used to indicate the error is software set as the driver is using some of the spec defined hardware error as well. Cc: Ramesh Thomas Signed-off-by: Dave Jiang Link: https://lore.kernel.org/r/162681373579.1968485.5891788397526827892.stgit@djiang5-desk3.ch.intel.com Signed-off-by: Vinod Koul --- Documentation/ABI/stable/sysfs-driver-dma-idxd | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/ABI/stable/sysfs-driver-dma-idxd b/Documentation/ABI/stable/sysfs-driver-dma-idxd index adb0c93e8dfc..df4afbccf037 100644 --- a/Documentation/ABI/stable/sysfs-driver-dma-idxd +++ b/Documentation/ABI/stable/sysfs-driver-dma-idxd @@ -128,6 +128,8 @@ Date: Aug 28, 2020 KernelVersion: 5.10.0 Contact: dmaengine@vger.kernel.org Description: The last executed device administrative command's status/error. + Also last configuration error overloaded. + Writing to it will clear the status. What: /sys/bus/dsa/devices/wq./block_on_fault Date: Oct 27, 2020 -- cgit v1.2.3 From 5d886947039d029f8ba1da6030c0a00ef330373d Mon Sep 17 00:00:00 2001 From: Joakim Zhang Date: Wed, 28 Jul 2021 19:51:57 +0800 Subject: dt-bindings: net: fsl,fec: update compatible items Add more compatible items for i.MX8/8M platforms. Signed-off-by: Joakim Zhang Signed-off-by: David S. Miller --- Documentation/devicetree/bindings/net/fsl,fec.yaml | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/fsl,fec.yaml b/Documentation/devicetree/bindings/net/fsl,fec.yaml index dbcbec95fc9e..b14e0e7c1e42 100644 --- a/Documentation/devicetree/bindings/net/fsl,fec.yaml +++ b/Documentation/devicetree/bindings/net/fsl,fec.yaml @@ -40,6 +40,24 @@ properties: - enum: - fsl,imx7d-fec - const: fsl,imx6sx-fec + - items: + - const: fsl,imx8mq-fec + - const: fsl,imx6sx-fec + - items: + - enum: + - fsl,imx8mm-fec + - fsl,imx8mn-fec + - fsl,imx8mp-fec + - const: fsl,imx8mq-fec + - const: fsl,imx6sx-fec + - items: + - const: fsl,imx8qm-fec + - const: fsl,imx6sx-fec + - items: + - enum: + - fsl,imx8qxp-fec + - const: fsl,imx8qm-fec + - const: fsl,imx6sx-fec reg: maxItems: 1 -- cgit v1.2.3 From df11b8073e19bd0eedae630dae82f38eb374b80d Mon Sep 17 00:00:00 2001 From: Joakim Zhang Date: Wed, 28 Jul 2021 19:51:58 +0800 Subject: dt-bindings: net: fsl,fec: add RGMII internal clock delay Add RGMII internal clock delay for FEC controller. Signed-off-by: Joakim Zhang Signed-off-by: David S. Miller --- Documentation/devicetree/bindings/net/fsl,fec.yaml | 9 +++++++++ 1 file changed, 9 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/fsl,fec.yaml b/Documentation/devicetree/bindings/net/fsl,fec.yaml index b14e0e7c1e42..eca41443fcce 100644 --- a/Documentation/devicetree/bindings/net/fsl,fec.yaml +++ b/Documentation/devicetree/bindings/net/fsl,fec.yaml @@ -96,6 +96,8 @@ properties: SOC internal PLL. The "enet_out"(option), output clock for external device, like supply clock for PHY. The clock is required if PHY clock source from SOC. + The "enet_2x_txclk"(option), for RGMII sampling clock which fixed at 250Mhz. + The clock is required if SoC RGMII enable clock delay. clock-names: minItems: 2 @@ -107,6 +109,7 @@ properties: - ptp - enet_clk_ref - enet_out + - enet_2x_txclk phy-mode: true @@ -118,6 +121,12 @@ properties: mac-address: true + tx-internal-delay-ps: + enum: [0, 2000] + + rx-internal-delay-ps: + enum: [0, 2000] + phy-supply: description: Regulator that powers the Ethernet PHY. -- cgit v1.2.3 From 7882c55ef64a8179160f24d86e82e525ffcce020 Mon Sep 17 00:00:00 2001 From: Randy Dunlap Date: Tue, 27 Jul 2021 16:22:12 -0700 Subject: filesystems/locking: fix Malformed table warning Update the bottom border to be the same as the top border. Documentation/filesystems/locking.rst:274: WARNING: Malformed table. Bottom/header table border does not match top border. Fixes: 730633f0b7f9 ("mm: Protect operations adding pages to page cache with invalidate_lock") Link: https://lore.kernel.org/r/20210727232212.12510-1-rdunlap@infradead.org Signed-off-by: Randy Dunlap Reviewed-by: Darrick J. Wong Cc: Darrick J. Wong Cc: Christoph Hellwig Cc: Jan Kara Cc: linux-fsdevel@vger.kernel.org Signed-off-by: Jan Kara --- Documentation/filesystems/locking.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/filesystems/locking.rst b/Documentation/filesystems/locking.rst index 38a3097b6f1c..2a75dd5da7b5 100644 --- a/Documentation/filesystems/locking.rst +++ b/Documentation/filesystems/locking.rst @@ -295,7 +295,7 @@ is_partially_uptodate: yes error_remove_page: yes swap_activate: no swap_deactivate: no -====================== ======================== ========= +====================== ======================== ========= =============== ->write_begin(), ->write_end() and ->readpage() may be called from the request handler (/dev/loop). -- cgit v1.2.3 From 80c7c36fb3ddea8e06f75822bfb7634f64d0edcb Mon Sep 17 00:00:00 2001 From: Peter Collingbourne Date: Tue, 27 Jul 2021 13:52:59 -0700 Subject: Documentation: document the preferred tag checking mode feature Document the functionality added in the previous patches. Link: https://linux-review.googlesource.com/id/I48217cc3e8b8da33abc08cbaddc11cf4360a1b86 Signed-off-by: Peter Collingbourne Reviewed-by: Catalin Marinas Acked-by: Will Deacon Link: https://lore.kernel.org/r/20210727205300.2554659-6-pcc@google.com Acked-by: Will Deacon [catalin.marinas@arm.com: clarify that the change happens on task scheduling] Signed-off-by: Catalin Marinas --- Documentation/ABI/testing/sysfs-devices-system-cpu | 17 ++++++++ Documentation/arm64/memory-tagging-extension.rst | 48 ++++++++++++++++++---- 2 files changed, 58 insertions(+), 7 deletions(-) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-devices-system-cpu b/Documentation/ABI/testing/sysfs-devices-system-cpu index 160b10c029c0..edb19b31d710 100644 --- a/Documentation/ABI/testing/sysfs-devices-system-cpu +++ b/Documentation/ABI/testing/sysfs-devices-system-cpu @@ -640,3 +640,20 @@ Description: SPURR ticks for cpuX when it was idle. This sysfs interface exposes the number of SPURR ticks for cpuX when it was idle. + +What: /sys/devices/system/cpu/cpuX/mte_tcf_preferred +Date: July 2021 +Contact: Linux ARM Kernel Mailing list +Description: Preferred MTE tag checking mode + + When a user program specifies more than one MTE tag checking + mode, this sysfs node is used to specify which mode should + be preferred when scheduling a task on that CPU. Possible + values: + + ================ ============================================== + "sync" Prefer synchronous mode + "async" Prefer asynchronous mode + ================ ============================================== + + See also: Documentation/arm64/memory-tagging-extension.rst diff --git a/Documentation/arm64/memory-tagging-extension.rst b/Documentation/arm64/memory-tagging-extension.rst index b540178a93f8..7b99c8f428eb 100644 --- a/Documentation/arm64/memory-tagging-extension.rst +++ b/Documentation/arm64/memory-tagging-extension.rst @@ -77,14 +77,20 @@ configurable behaviours: address is unknown). The user can select the above modes, per thread, using the -``prctl(PR_SET_TAGGED_ADDR_CTRL, flags, 0, 0, 0)`` system call where -``flags`` contain one of the following values in the ``PR_MTE_TCF_MASK`` +``prctl(PR_SET_TAGGED_ADDR_CTRL, flags, 0, 0, 0)`` system call where ``flags`` +contains any number of the following values in the ``PR_MTE_TCF_MASK`` bit-field: -- ``PR_MTE_TCF_NONE`` - *Ignore* tag check faults +- ``PR_MTE_TCF_NONE``  - *Ignore* tag check faults + (ignored if combined with other options) - ``PR_MTE_TCF_SYNC`` - *Synchronous* tag check fault mode - ``PR_MTE_TCF_ASYNC`` - *Asynchronous* tag check fault mode +If no modes are specified, tag check faults are ignored. If a single +mode is specified, the program will run in that mode. If multiple +modes are specified, the mode is selected as described in the "Per-CPU +preferred tag checking modes" section below. + The current tag check fault mode can be read using the ``prctl(PR_GET_TAGGED_ADDR_CTRL, 0, 0, 0, 0)`` system call. @@ -120,13 +126,39 @@ in the ``PR_MTE_TAG_MASK`` bit-field. interface provides an include mask. An include mask of ``0`` (exclusion mask ``0xffff``) results in the CPU always generating tag ``0``. +Per-CPU preferred tag checking mode +----------------------------------- + +On some CPUs the performance of MTE in stricter tag checking modes +is similar to that of less strict tag checking modes. This makes it +worthwhile to enable stricter checks on those CPUs when a less strict +checking mode is requested, in order to gain the error detection +benefits of the stricter checks without the performance downsides. To +support this scenario, a privileged user may configure a stricter +tag checking mode as the CPU's preferred tag checking mode. + +The preferred tag checking mode for each CPU is controlled by +``/sys/devices/system/cpu/cpu/mte_tcf_preferred``, to which a +privileged user may write the value ``async`` or ``sync``. The default +preferred mode for each CPU is ``async``. + +To allow a program to potentially run in the CPU's preferred tag +checking mode, the user program may set multiple tag check fault mode +bits in the ``flags`` argument to the ``prctl(PR_SET_TAGGED_ADDR_CTRL, +flags, 0, 0, 0)`` system call. If the CPU's preferred tag checking +mode is in the task's set of provided tag checking modes (this will +always be the case at present because the kernel only supports two +tag checking modes, but future kernels may support more modes), that +mode will be selected. Otherwise, one of the modes in the task's mode +set will be selected in a currently unspecified manner. + Initial process state --------------------- On ``execve()``, the new process has the following configuration: - ``PR_TAGGED_ADDR_ENABLE`` set to 0 (disabled) -- Tag checking mode set to ``PR_MTE_TCF_NONE`` +- No tag checking modes are selected (tag check faults ignored) - ``PR_MTE_TAG_MASK`` set to 0 (all tags excluded) - ``PSTATE.TCO`` set to 0 - ``PROT_MTE`` not set on any of the initial memory maps @@ -251,11 +283,13 @@ Example of correct usage return EXIT_FAILURE; /* - * Enable the tagged address ABI, synchronous MTE tag check faults and - * allow all non-zero tags in the randomly generated set. + * Enable the tagged address ABI, synchronous or asynchronous MTE + * tag check faults (based on per-CPU preference) and allow all + * non-zero tags in the randomly generated set. */ if (prctl(PR_SET_TAGGED_ADDR_CTRL, - PR_TAGGED_ADDR_ENABLE | PR_MTE_TCF_SYNC | (0xfffe << PR_MTE_TAG_SHIFT), + PR_TAGGED_ADDR_ENABLE | PR_MTE_TCF_SYNC | PR_MTE_TCF_ASYNC | + (0xfffe << PR_MTE_TAG_SHIFT), 0, 0, 0)) { perror("prctl() failed"); return EXIT_FAILURE; -- cgit v1.2.3 From 883d71a55e968371d1ff151249732466b5581f58 Mon Sep 17 00:00:00 2001 From: Hu Haowen Date: Wed, 28 Jul 2021 23:59:12 +0800 Subject: Documentation: networking: add ioam6-sysctl into index Append ioam6-sysctl to toctree in order to get rid of building warnings. Signed-off-by: Hu Haowen Signed-off-by: David S. Miller --- Documentation/networking/index.rst | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/networking/index.rst b/Documentation/networking/index.rst index e9ce55992aa9..a91a2739f8ed 100644 --- a/Documentation/networking/index.rst +++ b/Documentation/networking/index.rst @@ -57,6 +57,7 @@ Contents: gen_stats gtp ila + ioam6-sysctl ipddp ip_dynaddr ipsec -- cgit v1.2.3 From d793b8f732d6acbc6390be7342fb2e92b069dc7f Mon Sep 17 00:00:00 2001 From: Desmond Cheong Zhi Xi Date: Wed, 28 Jul 2021 18:27:39 +0800 Subject: drm: clarify usage of drm leases We make the following changes to the documentation of drm leases to make it easier to reason about their usage. In particular, we clarify the lifetime and locking rules of lease fields in drm_master: 1. Make it clear that &drm_device.mode_config.idr_mutex protects the lease idr and list structures for drm_master. The lessor field itself doesn't need to be protected as it doesn't change after it's set in drm_lease_create. 2. Add descriptions for the lifetime of lessors and leases. 3. Add an overview DOC: section in drm-uapi.rst that defines the terminology for drm leasing, and explains how leases work and why they're used. Signed-off-by: Desmond Cheong Zhi Xi Reviewed-by: Daniel Vetter Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20210728102739.441543-1-desmondcheongzx@gmail.com --- Documentation/gpu/drm-uapi.rst | 9 +++++++++ 1 file changed, 9 insertions(+) (limited to 'Documentation') diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst index 7e51dd40bf6e..199afb503ab1 100644 --- a/Documentation/gpu/drm-uapi.rst +++ b/Documentation/gpu/drm-uapi.rst @@ -37,6 +37,15 @@ Primary Nodes, DRM Master and Authentication .. kernel-doc:: include/drm/drm_auth.h :internal: + +.. _drm_leasing: + +DRM Display Resource Leasing +============================ + +.. kernel-doc:: drivers/gpu/drm/drm_lease.c + :doc: drm leasing + Open-Source Userspace Requirements ================================== -- cgit v1.2.3 From 6a2d98b18900002b6d24c4c3850c1c2467d13898 Mon Sep 17 00:00:00 2001 From: Jeremy Kerr Date: Thu, 29 Jul 2021 10:20:53 +0800 Subject: mctp: Add MCTP overview document This change adds a brief document about the sockets API provided for sending and receiving MCTP messages from userspace. This is roughly based on the OpenBMC design document, at: https://github.com/openbmc/docs/blob/master/designs/mctp/mctp-kernel.md Signed-off-by: Jeremy Kerr Signed-off-by: David S. Miller --- Documentation/networking/index.rst | 1 + Documentation/networking/mctp.rst | 213 +++++++++++++++++++++++++++++++++++++ 2 files changed, 214 insertions(+) create mode 100644 Documentation/networking/mctp.rst (limited to 'Documentation') diff --git a/Documentation/networking/index.rst b/Documentation/networking/index.rst index a91a2739f8ed..58bc8cd367c6 100644 --- a/Documentation/networking/index.rst +++ b/Documentation/networking/index.rst @@ -69,6 +69,7 @@ Contents: l2tp lapb-module mac80211-injection + mctp mpls-sysctl mptcp-sysctl multiqueue diff --git a/Documentation/networking/mctp.rst b/Documentation/networking/mctp.rst new file mode 100644 index 000000000000..6100cdc220f6 --- /dev/null +++ b/Documentation/networking/mctp.rst @@ -0,0 +1,213 @@ +.. SPDX-License-Identifier: GPL-2.0 + +============================================== +Management Component Transport Protocol (MCTP) +============================================== + +net/mctp/ contains protocol support for MCTP, as defined by DMTF standard +DSP0236. Physical interface drivers ("bindings" in the specification) are +provided in drivers/net/mctp/. + +The core code provides a socket-based interface to send and receive MCTP +messages, through an AF_MCTP, SOCK_DGRAM socket. + +Structure: interfaces & networks +================================ + +The kernel models the local MCTP topology through two items: interfaces and +networks. + +An interface (or "link") is an instance of an MCTP physical transport binding +(as defined by DSP0236, section 3.2.47), likely connected to a specific hardware +device. This is represented as a ``struct netdevice``. + +A network defines a unique address space for MCTP endpoints by endpoint-ID +(described by DSP0236, section 3.2.31). A network has a user-visible identifier +to allow references from userspace. Route definitions are specific to one +network. + +Interfaces are associated with one network. A network may be associated with one +or more interfaces. + +If multiple networks are present, each may contain endpoint IDs (EIDs) that are +also present on other networks. + +Sockets API +=========== + +Protocol definitions +-------------------- + +MCTP uses ``AF_MCTP`` / ``PF_MCTP`` for the address- and protocol- families. +Since MCTP is message-based, only ``SOCK_DGRAM`` sockets are supported. + +.. code-block:: C + + int sd = socket(AF_MCTP, SOCK_DGRAM, 0); + +The only (current) value for the ``protocol`` argument is 0. + +As with all socket address families, source and destination addresses are +specified with a ``sockaddr`` type, with a single-byte endpoint address: + +.. code-block:: C + + typedef __u8 mctp_eid_t; + + struct mctp_addr { + mctp_eid_t s_addr; + }; + + struct sockaddr_mctp { + unsigned short int smctp_family; + int smctp_network; + struct mctp_addr smctp_addr; + __u8 smctp_type; + __u8 smctp_tag; + }; + + #define MCTP_NET_ANY 0x0 + #define MCTP_ADDR_ANY 0xff + + +Syscall behaviour +----------------- + +The following sections describe the MCTP-specific behaviours of the standard +socket system calls. These behaviours have been chosen to map closely to the +existing sockets APIs. + +``bind()`` : set local socket address +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Sockets that receive incoming request packets will bind to a local address, +using the ``bind()`` syscall. + +.. code-block:: C + + struct sockaddr_mctp addr; + + addr.smctp_family = AF_MCTP; + addr.smctp_network = MCTP_NET_ANY; + addr.smctp_addr.s_addr = MCTP_ADDR_ANY; + addr.smctp_type = MCTP_TYPE_PLDM; + addr.smctp_tag = MCTP_TAG_OWNER; + + int rc = bind(sd, (struct sockaddr *)&addr, sizeof(addr)); + +This establishes the local address of the socket. Incoming MCTP messages that +match the network, address, and message type will be received by this socket. +The reference to 'incoming' is important here; a bound socket will only receive +messages with the TO bit set, to indicate an incoming request message, rather +than a response. + +The ``smctp_tag`` value will configure the tags accepted from the remote side of +this socket. Given the above, the only valid value is ``MCTP_TAG_OWNER``, which +will result in remotely "owned" tags being routed to this socket. Since +``MCTP_TAG_OWNER`` is set, the 3 least-significant bits of ``smctp_tag`` are not +used; callers must set them to zero. + +A ``smctp_network`` value of ``MCTP_NET_ANY`` will configure the socket to +receive incoming packets from any locally-connected network. A specific network +value will cause the socket to only receive incoming messages from that network. + +The ``smctp_addr`` field specifies a local address to bind to. A value of +``MCTP_ADDR_ANY`` configures the socket to receive messages addressed to any +local destination EID. + +The ``smctp_type`` field specifies which message types to receive. Only the +lower 7 bits of the type is matched on incoming messages (ie., the +most-significant IC bit is not part of the match). This results in the socket +receiving packets with and without a message integrity check footer. + +``sendto()``, ``sendmsg()``, ``send()`` : transmit an MCTP message +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +An MCTP message is transmitted using one of the ``sendto()``, ``sendmsg()`` or +``send()`` syscalls. Using ``sendto()`` as the primary example: + +.. code-block:: C + + struct sockaddr_mctp addr; + char buf[14]; + ssize_t len; + + /* set message destination */ + addr.smctp_family = AF_MCTP; + addr.smctp_network = 0; + addr.smctp_addr.s_addr = 8; + addr.smctp_tag = MCTP_TAG_OWNER; + addr.smctp_type = MCTP_TYPE_ECHO; + + /* arbitrary message to send, with message-type header */ + buf[0] = MCTP_TYPE_ECHO; + memcpy(buf + 1, "hello, world!", sizeof(buf) - 1); + + len = sendto(sd, buf, sizeof(buf), 0, + (struct sockaddr_mctp *)&addr, sizeof(addr)); + +The network and address fields of ``addr`` define the remote address to send to. +If ``smctp_tag`` has the ``MCTP_TAG_OWNER``, the kernel will ignore any bits set +in ``MCTP_TAG_VALUE``, and generate a tag value suitable for the destination +EID. If ``MCTP_TAG_OWNER`` is not set, the message will be sent with the tag +value as specified. If a tag value cannot be allocated, the system call will +report an errno of ``EAGAIN``. + +The application must provide the message type byte as the first byte of the +message buffer passed to ``sendto()``. If a message integrity check is to be +included in the transmitted message, it must also be provided in the message +buffer, and the most-significant bit of the message type byte must be 1. + +The ``sendmsg()`` system call allows a more compact argument interface, and the +message buffer to be specified as a scatter-gather list. At present no ancillary +message types (used for the ``msg_control`` data passed to ``sendmsg()``) are +defined. + +Transmitting a message on an unconnected socket with ``MCTP_TAG_OWNER`` +specified will cause an allocation of a tag, if no valid tag is already +allocated for that destination. The (destination-eid,tag) tuple acts as an +implicit local socket address, to allow the socket to receive responses to this +outgoing message. If any previous allocation has been performed (to for a +different remote EID), that allocation is lost. + +Sockets will only receive responses to requests they have sent (with TO=1) and +may only respond (with TO=0) to requests they have received. + +``recvfrom()``, ``recvmsg()``, ``recv()`` : receive an MCTP message +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +An MCTP message can be received by an application using one of the +``recvfrom()``, ``recvmsg()``, or ``recv()`` system calls. Using ``recvfrom()`` +as the primary example: + +.. code-block:: C + + struct sockaddr_mctp addr; + socklen_t addrlen; + char buf[14]; + ssize_t len; + + addrlen = sizeof(addr); + + len = recvfrom(sd, buf, sizeof(buf), 0, + (struct sockaddr_mctp *)&addr, &addrlen); + + /* We can expect addr to describe an MCTP address */ + assert(addrlen >= sizeof(buf)); + assert(addr.smctp_family == AF_MCTP); + + printf("received %zd bytes from remote EID %d\n", rc, addr.smctp_addr); + +The address argument to ``recvfrom`` and ``recvmsg`` is populated with the +remote address of the incoming message, including tag value (this will be needed +in order to reply to the message). + +The first byte of the message buffer will contain the message type byte. If an +integrity check follows the message, it will be included in the received buffer. + +The ``recv()`` system call behaves in a similar way, but does not provide a +remote address to the application. Therefore, these are only useful if the +remote address is already known, or the message does not require a reply. + +Like the send calls, sockets will only receive responses to requests they have +sent (TO=1) and may only respond (TO=0) to requests they have received. -- cgit v1.2.3 From 10102a890b543a8a08457dc69fa55bc032403c7d Mon Sep 17 00:00:00 2001 From: Dmitry Safonov Date: Tue, 27 Jul 2021 14:06:35 +0100 Subject: printk: Add printk.console_no_auto_verbose boot parameter console_verbose() increases console loglevel to CONSOLE_LOGLEVEL_MOTORMOUTH, which provides more information to debug a panic/oops. Unfortunately, in Arista we maintain some DUTs (Device Under Test) that are configured to have 9600 baud rate. While verbose console messages have their value to post-analyze crashes, on such setup they: - may prevent panic/oops messages being printed - take too long to flush on console resulting in watchdog reboot In all our setups we use kdump which saves dmesg buffer after panic, so in reality those extra messages on console provide no additional value, but rather add risk of not getting to __crash_kexec(). Provide printk.console_no_auto_verbose boot parameter, which allows to switch off printk being verbose on oops/panic/lockdep. Cc: Andrew Morton Cc: John Ogness Cc: Petr Mladek Cc: Sergey Senozhatsky Cc: Steven Rostedt Signed-off-by: Dmitry Safonov Suggested-by: Petr Mladek Reviewed-by: Sergey Senozhatsky Reviewed-by: Petr Mladek Tested-by: Petr Mladek Signed-off-by: Petr Mladek Link: https://lore.kernel.org/r/20210727130635.675184-3-dima@arista.com --- Documentation/admin-guide/kernel-parameters.txt | 9 +++++++++ 1 file changed, 9 insertions(+) (limited to 'Documentation') diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index 26453f250683..fdd80888217a 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -4101,6 +4101,15 @@ Format: (1/Y/y=enable, 0/N/n=disable) default: disabled + printk.console_no_auto_verbose= + Disable console loglevel raise on oops, panic + or lockdep-detected issues (only if lock debug is on). + With an exception to setups with low baudrate on + serial console, keeping this 0 is a good choice + in order to provide more debug information. + Format: + default: 0 (auto_verbose is enabled) + printk.devkmsg={on,off,ratelimit} Control writing to /dev/kmsg. on - unlimited logging to /dev/kmsg from userspace -- cgit v1.2.3 From 0132bf6f395837fc77fb38ac3d2806d22426be51 Mon Sep 17 00:00:00 2001 From: Konrad Dybcio Date: Thu, 29 Jul 2021 00:19:21 +0200 Subject: drivers: usb: dwc3-qcom: Add sdm660 compatible Add a new compatible for SDM660's DWC3. Acked-by: Felipe Balbi Signed-off-by: Konrad Dybcio Link: https://lore.kernel.org/r/20210728221921.52068-1-konrad.dybcio@somainline.org Signed-off-by: Greg Kroah-Hartman --- Documentation/devicetree/bindings/usb/qcom,dwc3.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml b/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml index 4e6451789806..e70afc40edb2 100644 --- a/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml +++ b/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml @@ -17,6 +17,7 @@ properties: - qcom,msm8998-dwc3 - qcom,sc7180-dwc3 - qcom,sc7280-dwc3 + - qcom,sdm660-dwc3 - qcom,sdm845-dwc3 - qcom,sdx55-dwc3 - qcom,sm4250-dwc3 -- cgit v1.2.3 From 7ee9e21c9f28106ad236c66816759047981b6527 Mon Sep 17 00:00:00 2001 From: Nobuhiro Iwamatsu Date: Thu, 15 Jul 2021 18:56:27 +0900 Subject: dt-bindings: power: reset: convert Xilinx Zynq MPSoC bindings to YAML Convert power managemnet for Xilinx Zynq MPSoC bindings documentation to YAML. Signed-off-by: Nobuhiro Iwamatsu Link: https://lore.kernel.org/r/20210715095627.228176-1-iwamatsu@nigauri.org Signed-off-by: Rob Herring --- .../bindings/power/reset/xlnx,zynqmp-power.txt | 61 ---------------- .../bindings/power/reset/xlnx,zynqmp-power.yaml | 83 ++++++++++++++++++++++ 2 files changed, 83 insertions(+), 61 deletions(-) delete mode 100644 Documentation/devicetree/bindings/power/reset/xlnx,zynqmp-power.txt create mode 100644 Documentation/devicetree/bindings/power/reset/xlnx,zynqmp-power.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/power/reset/xlnx,zynqmp-power.txt b/Documentation/devicetree/bindings/power/reset/xlnx,zynqmp-power.txt deleted file mode 100644 index bb529ecf8a57..000000000000 --- a/Documentation/devicetree/bindings/power/reset/xlnx,zynqmp-power.txt +++ /dev/null @@ -1,61 +0,0 @@ --------------------------------------------------------------------- -Device Tree Bindings for the Xilinx Zynq MPSoC Power Management --------------------------------------------------------------------- -The zynqmp-power node describes the power management configurations. -It will control remote suspend/shutdown interfaces. - -Required properties: - - compatible: Must contain: "xlnx,zynqmp-power" - - interrupts: Interrupt specifier - -Optional properties: - - mbox-names : Name given to channels seen in the 'mboxes' property. - "tx" - Mailbox corresponding to transmit path - "rx" - Mailbox corresponding to receive path - - mboxes : Standard property to specify a Mailbox. Each value of - the mboxes property should contain a phandle to the - mailbox controller device node and an args specifier - that will be the phandle to the intended sub-mailbox - child node to be used for communication. See - Documentation/devicetree/bindings/mailbox/mailbox.txt - for more details about the generic mailbox controller - and client driver bindings. Also see - Documentation/devicetree/bindings/mailbox/ \ - xlnx,zynqmp-ipi-mailbox.txt for typical controller that - is used to communicate with this System controllers. - --------- -Examples --------- - -Example with interrupt method: - -firmware { - zynqmp_firmware: zynqmp-firmware { - compatible = "xlnx,zynqmp-firmware"; - method = "smc"; - - zynqmp_power: zynqmp-power { - compatible = "xlnx,zynqmp-power"; - interrupts = <0 35 4>; - }; - }; -}; - -Example with IPI mailbox method: - -firmware { - zynqmp_firmware: zynqmp-firmware { - compatible = "xlnx,zynqmp-firmware"; - method = "smc"; - - zynqmp_power: zynqmp-power { - compatible = "xlnx,zynqmp-power"; - interrupt-parent = <&gic>; - interrupts = <0 35 4>; - mboxes = <&ipi_mailbox_pmu0 0>, - <&ipi_mailbox_pmu0 1>; - mbox-names = "tx", "rx"; - }; - }; -}; diff --git a/Documentation/devicetree/bindings/power/reset/xlnx,zynqmp-power.yaml b/Documentation/devicetree/bindings/power/reset/xlnx,zynqmp-power.yaml new file mode 100644 index 000000000000..68d7c14a7163 --- /dev/null +++ b/Documentation/devicetree/bindings/power/reset/xlnx,zynqmp-power.yaml @@ -0,0 +1,83 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/power/reset/xlnx,zynqmp-power.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Xilinx Zynq MPSoC Power Management Device Tree Bindings + +maintainers: + - Michal Simek + +description: | + The zynqmp-power node describes the power management configurations. + It will control remote suspend/shutdown interfaces. + +properties: + compatible: + const: "xlnx,zynqmp-power" + + interrupts: + maxItems: 1 + + mboxes: + description: | + Standard property to specify a Mailbox. Each value of + the mboxes property should contain a phandle to the + mailbox controller device node and an args specifier + that will be the phandle to the intended sub-mailbox + child node to be used for communication. See + Documentation/devicetree/bindings/mailbox/mailbox.txt + for more details about the generic mailbox controller + and client driver bindings. Also see + Documentation/devicetree/bindings/mailbox/ \ + xlnx,zynqmp-ipi-mailbox.txt for typical controller that + is used to communicate with this System controllers. + items: + - description: tx channel + - description: rx channel + + mbox-names: + description: + Name given to channels seen in the 'mboxes' property. + items: + - const: tx + - const: rx + +required: + - compatible + - interrupts + +additionalProperties: false + +examples: + - |+ + + // Example with interrupt method: + + firmware { + zynqmp-firmware { + zynqmp-power { + compatible = "xlnx,zynqmp-power"; + interrupts = <0 35 4>; + }; + }; + }; + + - |+ + + // Example with IPI mailbox method: + + firmware { + zynqmp-firmware { + zynqmp-power { + compatible = "xlnx,zynqmp-power"; + interrupt-parent = <&gic>; + interrupts = <0 35 4>; + mboxes = <&ipi_mailbox_pmu1 0>, + <&ipi_mailbox_pmu1 1>; + mbox-names = "tx", "rx"; + }; + }; + }; +... -- cgit v1.2.3 From d4fd4f01e19771ee4e1827acb757ac529ac829d7 Mon Sep 17 00:00:00 2001 From: Nobuhiro Iwamatsu Date: Sat, 17 Jul 2021 06:26:21 +0900 Subject: dt-bindings: fpga: convert Xilinx Zynq MPSoC bindings to YAML Convert FPGA Manager for Xilinx Zynq MPSoC bindings documentation to YAML. Signed-off-by: Nobuhiro Iwamatsu Link: https://lore.kernel.org/r/20210716212621.286806-1-iwamatsu@nigauri.org Signed-off-by: Rob Herring --- .../bindings/fpga/xlnx,zynqmp-pcap-fpga.txt | 25 --------------- .../bindings/fpga/xlnx,zynqmp-pcap-fpga.yaml | 36 ++++++++++++++++++++++ 2 files changed, 36 insertions(+), 25 deletions(-) delete mode 100644 Documentation/devicetree/bindings/fpga/xlnx,zynqmp-pcap-fpga.txt create mode 100644 Documentation/devicetree/bindings/fpga/xlnx,zynqmp-pcap-fpga.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/fpga/xlnx,zynqmp-pcap-fpga.txt b/Documentation/devicetree/bindings/fpga/xlnx,zynqmp-pcap-fpga.txt deleted file mode 100644 index 3052bf619dd5..000000000000 --- a/Documentation/devicetree/bindings/fpga/xlnx,zynqmp-pcap-fpga.txt +++ /dev/null @@ -1,25 +0,0 @@ -Devicetree bindings for Zynq Ultrascale MPSoC FPGA Manager. -The ZynqMP SoC uses the PCAP (Processor configuration Port) to configure the -Programmable Logic (PL). The configuration uses the firmware interface. - -Required properties: -- compatible: should contain "xlnx,zynqmp-pcap-fpga" - -Example for full FPGA configuration: - - fpga-region0 { - compatible = "fpga-region"; - fpga-mgr = <&zynqmp_pcap>; - #address-cells = <0x1>; - #size-cells = <0x1>; - }; - - firmware { - zynqmp_firmware: zynqmp-firmware { - compatible = "xlnx,zynqmp-firmware"; - method = "smc"; - zynqmp_pcap: pcap { - compatible = "xlnx,zynqmp-pcap-fpga"; - }; - }; - }; diff --git a/Documentation/devicetree/bindings/fpga/xlnx,zynqmp-pcap-fpga.yaml b/Documentation/devicetree/bindings/fpga/xlnx,zynqmp-pcap-fpga.yaml new file mode 100644 index 000000000000..6cd2bdc06b5f --- /dev/null +++ b/Documentation/devicetree/bindings/fpga/xlnx,zynqmp-pcap-fpga.yaml @@ -0,0 +1,36 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/fpga/xlnx,zynqmp-pcap-fpga.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Xilinx Zynq Ultrascale MPSoC FPGA Manager Device Tree Bindings + +maintainers: + - Nava kishore Manne + +description: | + Device Tree Bindings for Zynq Ultrascale MPSoC FPGA Manager. + The ZynqMP SoC uses the PCAP (Processor Configuration Port) to + configure the Programmable Logic (PL). The configuration uses the + firmware interface. + +properties: + compatible: + const: xlnx,zynqmp-pcap-fpga + +required: + - compatible + +additionalProperties: false + +examples: + - | + firmware { + zynqmp_firmware: zynqmp-firmware { + zynqmp_pcap: pcap { + compatible = "xlnx,zynqmp-pcap-fpga"; + }; + }; + }; +... -- cgit v1.2.3 From 4b2545dd19ed61392d183bddc77c53d6d790b8bb Mon Sep 17 00:00:00 2001 From: Kunihiko Hayashi Date: Mon, 19 Jul 2021 11:31:03 +0900 Subject: dt-bindings: nvmem: Extend patternProperties to optionally indicate bit position Allow to extend expression of sub nodes to optionally indicate bit position. This extension is needed to distinguish between different bit positions in the same address. For example, there are two nvmem nodes starting with bit 4 and bit 0 at the same address 0x54. In this case, it can be expressed as follows. trim@54,4 { reg = <0x54 1>; bits = <4 2>; }; trim@54,0 { reg = <0x54 1>; bits = <0 4>; }; Signed-off-by: Kunihiko Hayashi Link: https://lore.kernel.org/r/1626661864-15473-2-git-send-email-hayashi.kunihiko@socionext.com Signed-off-by: Rob Herring --- Documentation/devicetree/bindings/nvmem/nvmem.yaml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/nvmem/nvmem.yaml b/Documentation/devicetree/bindings/nvmem/nvmem.yaml index b8dc3d2b6e92..456fb808100a 100644 --- a/Documentation/devicetree/bindings/nvmem/nvmem.yaml +++ b/Documentation/devicetree/bindings/nvmem/nvmem.yaml @@ -40,7 +40,7 @@ properties: maxItems: 1 patternProperties: - "^.*@[0-9a-f]+$": + "@[0-9a-f]+(,[0-7])?$": type: object properties: -- cgit v1.2.3 From 90eed0f89520d92b3ee691c1487395b99070fd81 Mon Sep 17 00:00:00 2001 From: Kunihiko Hayashi Date: Mon, 19 Jul 2021 11:31:04 +0900 Subject: dt-bindings: nvmem: Convert UniPhier eFuse bindings to json-schema Convert the UniPhier eFuse binding to DT schema format. Cc: Keiji Hayashibara Signed-off-by: Kunihiko Hayashi Link: https://lore.kernel.org/r/1626661864-15473-3-git-send-email-hayashi.kunihiko@socionext.com Signed-off-by: Rob Herring --- .../bindings/nvmem/socionext,uniphier-efuse.yaml | 95 ++++++++++++++++++++++ .../devicetree/bindings/nvmem/uniphier-efuse.txt | 49 ----------- 2 files changed, 95 insertions(+), 49 deletions(-) create mode 100644 Documentation/devicetree/bindings/nvmem/socionext,uniphier-efuse.yaml delete mode 100644 Documentation/devicetree/bindings/nvmem/uniphier-efuse.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/nvmem/socionext,uniphier-efuse.yaml b/Documentation/devicetree/bindings/nvmem/socionext,uniphier-efuse.yaml new file mode 100644 index 000000000000..2578e39deda9 --- /dev/null +++ b/Documentation/devicetree/bindings/nvmem/socionext,uniphier-efuse.yaml @@ -0,0 +1,95 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/nvmem/socionext,uniphier-efuse.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Socionext UniPhier eFuse bindings + +maintainers: + - Keiji Hayashibara + - Kunihiko Hayashi + +allOf: + - $ref: "nvmem.yaml#" + +properties: + "#address-cells": true + "#size-cells": true + + compatible: + const: socionext,uniphier-efuse + + reg: + maxItems: 1 + +required: + - compatible + - reg + +unevaluatedProperties: false + +examples: + - | + // The UniPhier eFuse should be a subnode of a "soc-glue" node. + + soc-glue@5f900000 { + compatible = "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_rterm0: trim@54,4 { + reg = <0x54 1>; + bits = <4 2>; + }; + usb_rterm1: trim@55,4 { + reg = <0x55 1>; + bits = <4 2>; + }; + usb_rterm2: trim@58,4 { + reg = <0x58 1>; + bits = <4 2>; + }; + usb_rterm3: trim@59,4 { + reg = <0x59 1>; + bits = <4 2>; + }; + usb_sel_t0: trim@54,0 { + reg = <0x54 1>; + bits = <0 4>; + }; + usb_sel_t1: trim@55,0 { + reg = <0x55 1>; + bits = <0 4>; + }; + usb_sel_t2: trim@58,0 { + reg = <0x58 1>; + bits = <0 4>; + }; + usb_sel_t3: trim@59,0 { + reg = <0x59 1>; + bits = <0 4>; + }; + usb_hs_i0: trim@56,0 { + reg = <0x56 1>; + bits = <0 4>; + }; + usb_hs_i2: trim@5a,0 { + reg = <0x5a 1>; + bits = <0 4>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/nvmem/uniphier-efuse.txt b/Documentation/devicetree/bindings/nvmem/uniphier-efuse.txt deleted file mode 100644 index eccf490d5a6d..000000000000 --- a/Documentation/devicetree/bindings/nvmem/uniphier-efuse.txt +++ /dev/null @@ -1,49 +0,0 @@ -= 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 390436f17c12819a4a4a143af13545676aefd60c Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Thu, 22 Jul 2021 11:59:58 +0200 Subject: dt-bindings: mtd: update mtd-physmap.yaml reference Changeset 63f8e9e0ac65 ("dt-bindings: mtd: Convert mtd-physmap to DT schema") renamed: Documentation/devicetree/bindings/mtd/mtd-physmap.txt to: Documentation/devicetree/bindings/mtd/mtd-physmap.yaml. Update its cross-reference accordingly. Fixes: 63f8e9e0ac65 ("dt-bindings: mtd: Convert mtd-physmap to DT schema") Signed-off-by: Mauro Carvalho Chehab Link: https://lore.kernel.org/r/ab2ff9ee66110c37691b467ec8b4679e9d426416.1626947923.git.mchehab+huawei@kernel.org Signed-off-by: Rob Herring --- Documentation/devicetree/bindings/mtd/gpmc-nor.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mtd/gpmc-nor.txt b/Documentation/devicetree/bindings/mtd/gpmc-nor.txt index c8567b40fe13..2133be0d52f2 100644 --- a/Documentation/devicetree/bindings/mtd/gpmc-nor.txt +++ b/Documentation/devicetree/bindings/mtd/gpmc-nor.txt @@ -10,7 +10,7 @@ Documentation/devicetree/bindings/memory-controllers/omap-gpmc.txt Required properties: - bank-width: Width of NOR flash in bytes. GPMC supports 8-bit and 16-bit devices and so must be either 1 or 2 bytes. -- compatible: Documentation/devicetree/bindings/mtd/mtd-physmap.txt +- compatible: Documentation/devicetree/bindings/mtd/mtd-physmap.yaml - gpmc,cs-on-ns: Chip-select assertion time - gpmc,cs-rd-off-ns: Chip-select de-assertion time for reads - gpmc,cs-wr-off-ns: Chip-select de-assertion time for writes @@ -21,7 +21,7 @@ Required properties: - gpmc,access-ns: Start cycle to first data capture (read access) - gpmc,rd-cycle-ns: Total read cycle time - gpmc,wr-cycle-ns: Total write cycle time -- linux,mtd-name: Documentation/devicetree/bindings/mtd/mtd-physmap.txt +- linux,mtd-name: Documentation/devicetree/bindings/mtd/mtd-physmap.yaml - reg: Chip-select, base address (relative to chip-select) and size of NOR flash. Note that base address will be typically 0 as this is the start of the chip-select. -- cgit v1.2.3 From d1626a1c273d0e66834006b10ebe12062dce2b6f Mon Sep 17 00:00:00 2001 From: Ioana Ciornei Date: Thu, 29 Jul 2021 20:19:01 +0300 Subject: docs: networking: dpaa2: document mirroring support on the switch Document the mirroring capabilities of the dpaa2-switch driver, any restrictions that are imposed and some example commands. Signed-off-by: Ioana Ciornei Signed-off-by: David S. Miller --- .../ethernet/freescale/dpaa2/switch-driver.rst | 43 ++++++++++++++++++++++ 1 file changed, 43 insertions(+) (limited to 'Documentation') diff --git a/Documentation/networking/device_drivers/ethernet/freescale/dpaa2/switch-driver.rst b/Documentation/networking/device_drivers/ethernet/freescale/dpaa2/switch-driver.rst index 863ca6bd8318..8bf411b857d4 100644 --- a/Documentation/networking/device_drivers/ethernet/freescale/dpaa2/switch-driver.rst +++ b/Documentation/networking/device_drivers/ethernet/freescale/dpaa2/switch-driver.rst @@ -172,3 +172,46 @@ Example 4: Use a single shared filter block on both eth5 and eth6:: action trap $ tc filter add block 1 ingress protocol ipv4 flower src_ip 192.168.1.1 skip_sw \ action mirred egress redirect dev eth3 + +Mirroring +~~~~~~~~~ + +The DPAA2 switch supports only per port mirroring and per VLAN mirroring. +Adding mirroring filters in shared blocks is also supported. + +When using the tc-flower classifier with the 802.1q protocol, only the +''vlan_id'' key will be accepted. Mirroring based on any other fields from the +802.1q protocol will be rejected:: + + $ tc qdisc add dev eth8 ingress_block 1 clsact + $ tc filter add block 1 ingress protocol 802.1q flower skip_sw vlan_prio 3 action mirred egress mirror dev eth6 + Error: fsl_dpaa2_switch: Only matching on VLAN ID supported. + We have an error talking to the kernel + +If a mirroring VLAN filter is requested on a port, the VLAN must to be +installed on the switch port in question either using ''bridge'' or by creating +a VLAN upper device if the switch port is used as a standalone interface:: + + $ tc qdisc add dev eth8 ingress_block 1 clsact + $ tc filter add block 1 ingress protocol 802.1q flower skip_sw vlan_id 200 action mirred egress mirror dev eth6 + Error: VLAN must be installed on the switch port. + We have an error talking to the kernel + + $ bridge vlan add vid 200 dev eth8 + $ tc filter add block 1 ingress protocol 802.1q flower skip_sw vlan_id 200 action mirred egress mirror dev eth6 + + $ ip link add link eth8 name eth8.200 type vlan id 200 + $ tc filter add block 1 ingress protocol 802.1q flower skip_sw vlan_id 200 action mirred egress mirror dev eth6 + +Also, it should be noted that the mirrored traffic will be subject to the same +egress restrictions as any other traffic. This means that when a mirrored +packet will reach the mirror port, if the VLAN found in the packet is not +installed on the port it will get dropped. + +The DPAA2 switch supports only a single mirroring destination, thus multiple +mirror rules can be installed but their ''to'' port has to be the same:: + + $ tc filter add block 1 ingress protocol 802.1q flower skip_sw vlan_id 200 action mirred egress mirror dev eth6 + $ tc filter add block 1 ingress protocol 802.1q flower skip_sw vlan_id 100 action mirred egress mirror dev eth7 + Error: fsl_dpaa2_switch: Multiple mirror ports not supported. + We have an error talking to the kernel -- cgit v1.2.3 From 7da6ebf5f5a5efef1a7c8ec5a3a79b4298c902f0 Mon Sep 17 00:00:00 2001 From: Linus Walleij Date: Fri, 23 Jul 2021 17:23:56 +0200 Subject: dt-bindings: arm: Convert Gemini boards to YAML This removes the old plaintext Gemini binding and replace it with a YAML schema, adding some new boards in the process. While we are at it, add the missing vendors to the vendor prefix file. Drop the overly deliberate description of subnodes and the big example from the old document. Keep the elaborate description. I noticed that "wiliboard" is not a real vendor, the vendor is named "wiligear" so deprecated this and replaced with the proper vendor. Cc: Corentin Labbe Signed-off-by: Linus Walleij Link: https://lore.kernel.org/r/20210723152356.1874088-1-linus.walleij@linaro.org Signed-off-by: Rob Herring --- Documentation/devicetree/bindings/arm/gemini.txt | 108 --------------------- Documentation/devicetree/bindings/arm/gemini.yaml | 95 ++++++++++++++++++ .../devicetree/bindings/vendor-prefixes.yaml | 10 ++ 3 files changed, 105 insertions(+), 108 deletions(-) delete mode 100644 Documentation/devicetree/bindings/arm/gemini.txt create mode 100644 Documentation/devicetree/bindings/arm/gemini.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/gemini.txt b/Documentation/devicetree/bindings/arm/gemini.txt deleted file mode 100644 index 55bf7ce96c44..000000000000 --- a/Documentation/devicetree/bindings/arm/gemini.txt +++ /dev/null @@ -1,108 +0,0 @@ -Cortina systems Gemini platforms - -The Gemini SoC is the project name for an ARMv4 FA525-based SoC originally -produced by Storlink Semiconductor around 2005. The company was renamed -later renamed Storm Semiconductor. The chip product name is Storlink SL3516. -It was derived from earlier products from Storm named SL3316 (Centroid) and -SL3512 (Bulverde). - -Storm Semiconductor was acquired by Cortina Systems in 2008 and the SoC was -produced and used for NAS and similar usecases. In 2014 Cortina Systems was -in turn acquired by Inphi, who seem to have discontinued this product family. - -Many of the IP blocks used in the SoC comes from Faraday Technology. - -Required properties (in root node): - compatible = "cortina,gemini"; - -Required nodes: - -- soc: the SoC should be represented by a simple bus encompassing all the - onchip devices, this is referred to as the soc bus node. - -- syscon: the soc bus node must have a system controller node pointing to the - global control registers, with the compatible string - "cortina,gemini-syscon", "syscon"; - - Required properties on the syscon: - - reg: syscon register location and size. - - #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. - - The clock sources have shorthand defines in the include file: - - - The reset lines have shorthand defines in the include file: - - -- timer: the soc bus node must have a timer node pointing to the SoC timer - block, with the compatible string "cortina,gemini-timer" - See: clocksource/cortina,gemini-timer.txt - -- interrupt-controller: the sob bus node must have an interrupt controller - node pointing to the SoC interrupt controller block, with the compatible - string "cortina,gemini-interrupt-controller" - See interrupt-controller/cortina,gemini-interrupt-controller.txt - -Example: - -/ { - model = "Foo Gemini Machine"; - compatible = "cortina,gemini"; - #address-cells = <1>; - #size-cells = <1>; - - memory { - device_type = "memory"; - reg = <0x00000000 0x8000000>; - }; - - soc { - #address-cells = <1>; - #size-cells = <1>; - ranges; - compatible = "simple-bus"; - interrupt-parent = <&intcon>; - - syscon: syscon@40000000 { - compatible = "cortina,gemini-syscon", "syscon"; - reg = <0x40000000 0x1000>; - #clock-cells = <1>; - #reset-cells = <1>; - }; - - uart0: serial@42000000 { - compatible = "ns16550a"; - reg = <0x42000000 0x100>; - resets = <&syscon GEMINI_RESET_UART>; - clocks = <&syscon GEMINI_CLK_UART>; - interrupts = <18 IRQ_TYPE_LEVEL_HIGH>; - reg-shift = <2>; - }; - - timer@43000000 { - compatible = "cortina,gemini-timer"; - reg = <0x43000000 0x1000>; - interrupt-parent = <&intcon>; - interrupts = <14 IRQ_TYPE_EDGE_FALLING>, /* Timer 1 */ - <15 IRQ_TYPE_EDGE_FALLING>, /* Timer 2 */ - <16 IRQ_TYPE_EDGE_FALLING>; /* Timer 3 */ - resets = <&syscon GEMINI_RESET_TIMER>; - /* APB clock or RTC clock */ - clocks = <&syscon GEMINI_CLK_APB>, - <&syscon GEMINI_CLK_RTC>; - clock-names = "PCLK", "EXTCLK"; - syscon = <&syscon>; - }; - - intcon: interrupt-controller@48000000 { - compatible = "cortina,gemini-interrupt-controller"; - reg = <0x48000000 0x1000>; - resets = <&syscon GEMINI_RESET_INTCON0>; - interrupt-controller; - #interrupt-cells = <2>; - }; - }; -}; diff --git a/Documentation/devicetree/bindings/arm/gemini.yaml b/Documentation/devicetree/bindings/arm/gemini.yaml new file mode 100644 index 000000000000..f6a0b675830f --- /dev/null +++ b/Documentation/devicetree/bindings/arm/gemini.yaml @@ -0,0 +1,95 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/arm/gemini.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Cortina systems Gemini platforms + +description: | + The Gemini SoC is the project name for an ARMv4 FA525-based SoC originally + produced by Storlink Semiconductor around 2005. The company was renamed + later renamed Storm Semiconductor. The chip product name is Storlink SL3516. + It was derived from earlier products from Storm named SL3316 (Centroid) and + SL3512 (Bulverde). + + Storm Semiconductor was acquired by Cortina Systems in 2008 and the SoC was + produced and used for NAS and similar usecases. In 2014 Cortina Systems was + in turn acquired by Inphi, who seem to have discontinued this product family. + + Many of the IP blocks used in the SoC comes from Faraday Technology. + +maintainers: + - Linus Walleij + +properties: + $nodename: + const: '/' + compatible: + oneOf: + + - description: Storlink Semiconductor Gemini324 EV-Board also known + as Storm Semiconductor SL93512R_BRD + items: + - const: storlink,gemini324 + - const: storm,sl93512r + - const: cortina,gemini + + - description: D-Link DIR-685 Xtreme N Storage Router + items: + - const: dlink,dir-685 + - const: cortina,gemini + + - description: D-Link DNS-313 1-Bay Network Storage Enclosure + items: + - const: dlink,dns-313 + - const: cortina,gemini + + - description: Edimax NS-2502 + items: + - const: edimax,ns-2502 + - const: cortina,gemini + + - description: ITian Square One SQ201 + items: + - const: itian,sq201 + - const: cortina,gemini + + - description: Raidsonic NAS IB-4220-B + items: + - const: raidsonic,ib-4220-b + - const: cortina,gemini + + - description: SSI 1328 + items: + - const: ssi,1328 + - const: cortina,gemini + + - description: Teltonika RUT1xx Mobile Router + items: + - const: teltonika,rut1xx + - const: cortina,gemini + + - description: Wiligear Wiliboard WBD-111 + items: + - const: wiligear,wiliboard-wbd111 + - const: cortina,gemini + + - description: Wiligear Wiliboard WBD-222 + items: + - const: wiligear,wiliboard-wbd222 + - const: cortina,gemini + + - description: Wiligear Wiliboard WBD-111 - old incorrect binding + items: + - const: wiliboard,wbd111 + - const: cortina,gemini + deprecated: true + + - description: Wiligear Wiliboard WBD-222 - old incorrect binding + items: + - const: wiliboard,wbd222 + - const: cortina,gemini + deprecated: true + +additionalProperties: true diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index 07fb0d25fc15..13f01fba90ec 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -563,6 +563,8 @@ patternProperties: description: ITE Tech. Inc. "^itead,.*": description: ITEAD Intelligent Systems Co.Ltd + "^itian,.*": + description: ITian Corporation "^iwave,.*": description: iWave Systems Technologies Pvt. Ltd. "^jdi,.*": @@ -1111,6 +1113,10 @@ patternProperties: "^st-ericsson,.*": description: ST-Ericsson deprecated: true + "^storlink,.*": + description: StorLink Semiconductors, Inc. + "^storm,.*": + description: Storm Semiconductor, Inc. "^summit,.*": description: Summit microelectronics "^sunchip,.*": @@ -1143,6 +1149,8 @@ patternProperties: description: TechNexion "^technologic,.*": description: Technologic Systems + "^teltonika,.*": + description: Teltonika Networks "^tempo,.*": description: Tempo Semiconductor "^techstar,.*": @@ -1268,6 +1276,8 @@ patternProperties: description: Shenzhen whwave Electronics, Inc. "^wi2wi,.*": description: Wi2Wi, Inc. + "^wiligear,.*": + description: Wiligear, Ltd. "^winbond,.*": description: Winbond Electronics corp. "^winstar,.*": -- cgit v1.2.3 From 6ef02f9c394c5f821a27b7c54f0145e0c54050eb Mon Sep 17 00:00:00 2001 From: Sam Shih Date: Mon, 26 Jul 2021 15:14:35 +0800 Subject: dt-bindings: rng: mediatek: add mt7986 to mtk rng binding Add RNG binding for MT7986 SoC. Signed-off-by: Sam Shih Link: https://lore.kernel.org/r/20210726071439.14248-9-sam.shih@mediatek.com Signed-off-by: Rob Herring --- Documentation/devicetree/bindings/rng/mtk-rng.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/rng/mtk-rng.yaml b/Documentation/devicetree/bindings/rng/mtk-rng.yaml index 61888e07bda0..bb32491ee8ae 100644 --- a/Documentation/devicetree/bindings/rng/mtk-rng.yaml +++ b/Documentation/devicetree/bindings/rng/mtk-rng.yaml @@ -21,6 +21,7 @@ properties: - enum: - mediatek,mt7622-rng - mediatek,mt7629-rng + - mediatek,mt7986-rng - mediatek,mt8365-rng - mediatek,mt8516-rng - const: mediatek,mt7623-rng -- cgit v1.2.3 From 153df45acda08afec4bd13dd9145464111ef7ba7 Mon Sep 17 00:00:00 2001 From: Sai Krishna Potthuri Date: Wed, 21 Jul 2021 17:22:30 +0530 Subject: dt-bindings: pinctrl: pinctrl-zynq: Convert to yaml Convert the Zynq pinctrl binding file to yaml. Signed-off-by: Sai Krishna Potthuri Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/1626868353-96475-2-git-send-email-lakshmi.sai.krishna.potthuri@xilinx.com Signed-off-by: Linus Walleij --- .../bindings/pinctrl/xlnx,zynq-pinctrl.txt | 105 ---------- .../bindings/pinctrl/xlnx,zynq-pinctrl.yaml | 216 +++++++++++++++++++++ 2 files changed, 216 insertions(+), 105 deletions(-) delete mode 100644 Documentation/devicetree/bindings/pinctrl/xlnx,zynq-pinctrl.txt create mode 100644 Documentation/devicetree/bindings/pinctrl/xlnx,zynq-pinctrl.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pinctrl/xlnx,zynq-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/xlnx,zynq-pinctrl.txt deleted file mode 100644 index f488b0f77406..000000000000 --- a/Documentation/devicetree/bindings/pinctrl/xlnx,zynq-pinctrl.txt +++ /dev/null @@ -1,105 +0,0 @@ - Binding for Xilinx Zynq Pinctrl - -Required properties: -- compatible: "xlnx,zynq-pinctrl" -- syscon: phandle to SLCR -- reg: Offset and length of pinctrl space in SLCR - -Please refer to pinctrl-bindings.txt in this directory for details of the -common pinctrl bindings used by client devices, including the meaning of the -phrase "pin configuration node". - -Zynq's pin configuration nodes act as a container for an arbitrary number of -subnodes. Each of these subnodes represents some desired configuration for a -pin, a group, or a list of pins or groups. This configuration can include the -mux function to select on those pin(s)/group(s), and various pin configuration -parameters, such as pull-up, slew rate, etc. - -Each configuration node can consist of multiple nodes describing the pinmux and -pinconf options. Those nodes can be pinmux nodes or pinconf nodes. - -The name of each subnode is not important; all subnodes should be enumerated -and processed purely based on their content. - -Required properties for pinmux nodes are: - - groups: A list of pinmux groups. - - function: The name of a pinmux function to activate for the specified set - of groups. - -Required properties for configuration nodes: -One of: - - pins: a list of pin names - - groups: A list of pinmux groups. - -The following generic properties as defined in pinctrl-bindings.txt are valid -to specify in a pinmux subnode: - groups, function - -The following generic properties as defined in pinctrl-bindings.txt are valid -to specify in a pinconf subnode: - groups, pins, bias-disable, bias-high-impedance, bias-pull-up, slew-rate, - low-power-disable, low-power-enable - - Valid arguments for 'slew-rate' are '0' and '1' to select between slow and fast - respectively. - - Valid values for groups are: - ethernet0_0_grp, ethernet1_0_grp, mdio0_0_grp, mdio1_0_grp, - qspi0_0_grp, qspi1_0_grp, qspi_fbclk, qspi_cs1_grp, spi0_0_grp - spi0_2_grp, - spi0_X_ssY (X=0..2, Y=0..2), spi1_0_grp - spi1_3_grp, - spi1_X_ssY (X=0..3, Y=0..2), sdio0_0_grp - sdio0_2_grp, - sdio1_0_grp - sdio1_3_grp, sdio0_emio_wp, sdio0_emio_cd, sdio1_emio_wp, - sdio1_emio_cd, smc0_nor, smc0_nor_cs1_grp, smc0_nor_addr25_grp, smc0_nand, - can0_0_grp - can0_10_grp, can1_0_grp - can1_11_grp, uart0_0_grp - uart0_10_grp, - uart1_0_grp - uart1_11_grp, i2c0_0_grp - i2c0_10_grp, i2c1_0_grp - i2c1_10_grp, - ttc0_0_grp - ttc0_2_grp, ttc1_0_grp - ttc1_2_grp, swdt0_0_grp - swdt0_4_grp, - gpio0_0_grp - gpio0_53_grp, usb0_0_grp, usb1_0_grp - - Valid values for pins are: - MIO0 - MIO53 - - Valid values for function are: - ethernet0, ethernet1, mdio0, mdio1, qspi0, qspi1, qspi_fbclk, qspi_cs1, - spi0, spi0_ss, spi1, spi1_ss, sdio0, sdio0_pc, sdio0_cd, sdio0_wp, - sdio1, sdio1_pc, sdio1_cd, sdio1_wp, - smc0_nor, smc0_nor_cs1, smc0_nor_addr25, smc0_nand, can0, can1, uart0, uart1, - i2c0, i2c1, ttc0, ttc1, swdt0, gpio0, usb0, usb1 - -The following driver-specific properties as defined here are valid to specify in -a pin configuration subnode: - - io-standard: Configure the pin to use the selected IO standard according to - this mapping: - 1: LVCMOS18 - 2: LVCMOS25 - 3: LVCMOS33 - 4: HSTL - -Example: - pinctrl0: pinctrl@700 { - compatible = "xlnx,pinctrl-zynq"; - reg = <0x700 0x200>; - syscon = <&slcr>; - - pinctrl_uart1_default: uart1-default { - mux { - groups = "uart1_10_grp"; - function = "uart1"; - }; - - conf { - groups = "uart1_10_grp"; - slew-rate = <0>; - io-standard = <1>; - }; - - conf-rx { - pins = "MIO49"; - bias-high-impedance; - }; - - conf-tx { - pins = "MIO48"; - bias-disable; - }; - }; - }; diff --git a/Documentation/devicetree/bindings/pinctrl/xlnx,zynq-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/xlnx,zynq-pinctrl.yaml new file mode 100644 index 000000000000..2da1969e02ec --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/xlnx,zynq-pinctrl.yaml @@ -0,0 +1,216 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pinctrl/xlnx,zynq-pinctrl.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Xilinx Zynq Pinctrl + +maintainers: + - Sai Krishna Potthuri + +description: | + Please refer to pinctrl-bindings.txt in this directory for details of the + common pinctrl bindings used by client devices, including the meaning of the + phrase "pin configuration node". + + Zynq's pin configuration nodes act as a container for an arbitrary number of + subnodes. Each of these subnodes represents some desired configuration for a + pin, a group, or a list of pins or groups. This configuration can include the + mux function to select on those pin(s)/group(s), and various pin configuration + parameters, such as pull-up, slew rate, etc. + + Each configuration node can consist of multiple nodes describing the pinmux and + pinconf options. Those nodes can be pinmux nodes or pinconf nodes. + + The name of each subnode is not important; all subnodes should be enumerated + and processed purely based on their content. + +properties: + compatible: + const: xlnx,zynq-pinctrl + + reg: + description: Specifies the base address and size of the SLCR space. + maxItems: 1 + + syscon: + description: + phandle to the SLCR. + +patternProperties: + '^(.*-)?(default|gpio)$': + type: object + patternProperties: + '^mux': + type: object + description: + Pinctrl node's client devices use subnodes for pin muxes, + which in turn use below standard properties. + $ref: pinmux-node.yaml# + + properties: + groups: + description: + List of groups to select (either this or "pins" must be + specified), available groups for this subnode. + items: + enum: [ethernet0_0_grp, ethernet1_0_grp, mdio0_0_grp, + mdio1_0_grp, qspi0_0_grp, qspi1_0_grp, qspi_fbclk, + qspi_cs1_grp, spi0_0_grp, spi0_1_grp, spi0_2_grp, + spi0_0_ss0, spi0_0_ss1, spi0_0_ss2, spi0_1_ss0, + spi0_1_ss1, spi0_1_ss2, spi0_2_ss0, spi0_2_ss1, + spi0_2_ss2, spi1_0_grp, spi1_1_grp, spi1_2_grp, + spi1_3_grp, spi1_0_ss0, spi1_0_ss1, spi1_0_ss2, + spi1_1_ss0, spi1_1_ss1, spi1_1_ss2, spi1_2_ss0, + spi1_2_ss1, spi1_2_ss2, spi1_3_ss0, spi1_3_ss1, + spi1_3_ss2, sdio0_0_grp, sdio0_1_grp, sdio0_2_grp, + sdio1_0_grp, sdio1_1_grp, sdio1_2_grp, sdio1_3_grp, + sdio0_emio_wp, sdio0_emio_cd, sdio1_emio_wp, + sdio1_emio_cd, smc0_nor, smc0_nor_cs1_grp, + smc0_nor_addr25_grp, smc0_nand, can0_0_grp, can0_1_grp, + can0_2_grp, can0_3_grp, can0_4_grp, can0_5_grp, + can0_6_grp, can0_7_grp, can0_8_grp, can0_9_grp, + can0_10_grp, can1_0_grp, can1_1_grp, can1_2_grp, + can1_3_grp, can1_4_grp, can1_5_grp, can1_6_grp, + can1_7_grp, can1_8_grp, can1_9_grp, can1_10_grp, + can1_11_grp, uart0_0_grp, uart0_1_grp, uart0_2_grp, + uart0_3_grp, uart0_4_grp, uart0_5_grp, uart0_6_grp, + uart0_7_grp, uart0_8_grp, uart0_9_grp, uart0_10_grp, + uart1_0_grp, uart1_1_grp, uart1_2_grp, uart1_3_grp, + uart1_4_grp, uart1_5_grp, uart1_6_grp, uart1_7_grp, + uart1_8_grp, uart1_9_grp, uart1_10_grp, uart1_11_grp, + i2c0_0_grp, i2c0_1_grp, i2c0_2_grp, i2c0_3_grp, + i2c0_4_grp, i2c0_5_grp, i2c0_6_grp, i2c0_7_grp, + i2c0_8_grp, i2c0_9_grp, i2c0_10_grp, i2c1_0_grp, + i2c1_1_grp, i2c1_2_grp, i2c1_3_grp, i2c1_4_grp, + i2c1_5_grp, i2c1_6_grp, i2c1_7_grp, i2c1_8_grp, + i2c1_9_grp, i2c1_10_grp, ttc0_0_grp, ttc0_1_grp, + ttc0_2_grp, ttc1_0_grp, ttc1_1_grp, ttc1_2_grp, + swdt0_0_grp, swdt0_1_grp, swdt0_2_grp, swdt0_3_grp, + swdt0_4_grp, gpio0_0_grp, gpio0_1_grp, gpio0_2_grp, + gpio0_3_grp, gpio0_4_grp, gpio0_5_grp, gpio0_6_grp, + gpio0_7_grp, gpio0_8_grp, gpio0_9_grp, gpio0_10_grp, + gpio0_11_grp, gpio0_12_grp, gpio0_13_grp, gpio0_14_grp, + gpio0_15_grp, gpio0_16_grp, gpio0_17_grp, gpio0_18_grp, + gpio0_19_grp, gpio0_20_grp, gpio0_21_grp, gpio0_22_grp, + gpio0_23_grp, gpio0_24_grp, gpio0_25_grp, gpio0_26_grp, + gpio0_27_grp, gpio0_28_grp, gpio0_29_grp, gpio0_30_grp, + gpio0_31_grp, gpio0_32_grp, gpio0_33_grp, gpio0_34_grp, + gpio0_35_grp, gpio0_36_grp, gpio0_37_grp, gpio0_38_grp, + gpio0_39_grp, gpio0_40_grp, gpio0_41_grp, gpio0_42_grp, + gpio0_43_grp, gpio0_44_grp, gpio0_45_grp, gpio0_46_grp, + gpio0_47_grp, gpio0_48_grp, gpio0_49_grp, gpio0_50_grp, + gpio0_51_grp, gpio0_52_grp, gpio0_53_grp, usb0_0_grp, + usb1_0_grp] + maxItems: 54 + + function: + description: + Specify the alternative function to be configured for the + given pin groups. + enum: [ethernet0, ethernet1, mdio0, mdio1, qspi0, qspi1, qspi_fbclk, + qspi_cs1, spi0, spi0_ss, spi1, spi1_ss, sdio0, sdio0_pc, + sdio0_cd, sdio0_wp, sdio1, sdio1_pc, sdio1_cd, sdio1_wp, + smc0_nor, smc0_nor_cs1, smc0_nor_addr25, smc0_nand, can0, + can1, uart0, uart1, i2c0, i2c1, ttc0, ttc1, swdt0, gpio0, + usb0, usb1] + + required: + - groups + - function + + additionalProperties: false + + '^conf': + type: object + description: + Pinctrl node's client devices use subnodes for pin configurations, + which in turn use the standard properties below. + $ref: pincfg-node.yaml# + + properties: + groups: + description: + List of pin groups as mentioned above. + + pins: + description: + List of pin names to select in this subnode. + items: + pattern: '^MIO([0-9]|[1-4][0-9]|5[0-3])$' + maxItems: 54 + + bias-pull-up: true + + bias-pull-down: true + + bias-disable: true + + bias-high-impedance: true + + low-power-enable: true + + low-power-disable: true + + slew-rate: + enum: [0, 1] + + io-standard: + description: + Selects the IO standard for MIO pins, this is driver specific. + $ref: "/schemas/types.yaml#/definitions/uint32" + enum: [1, 2, 3, 4] + + oneOf: + - required: [ groups ] + - required: [ pins ] + + additionalProperties: false + + additionalProperties: false + +required: + - compatible + - reg + - syscon + +additionalProperties: false + +examples: + - | + pinctrl0: pinctrl@700 { + compatible = "xlnx,zynq-pinctrl"; + reg = <0x700 0x200>; + syscon = <&slcr>; + + pinctrl_uart1_default: uart1-default { + mux { + groups = "uart1_10_grp"; + function = "uart1"; + }; + + conf { + groups = "uart1_10_grp"; + slew-rate = <0>; + io-standard = <1>; + }; + + conf-rx { + pins = "MIO49"; + bias-high-impedance; + }; + + conf-tx { + pins = "MIO48"; + bias-disable; + }; + }; + }; + + uart1 { + pinctrl-names = "default"; + pinctrl-0 = <&pinctrl_uart1_default>; + }; + +... -- cgit v1.2.3 From ef641c449e8083c4314c125d8e32b37644ddd852 Mon Sep 17 00:00:00 2001 From: Sai Krishna Potthuri Date: Wed, 21 Jul 2021 17:22:31 +0530 Subject: dt-bindings: pinctrl-zynq: Replace 'io-standard' with 'power-source' Replace custom pin configuration option 'io-standard' with generic property 'power-source' for Zynq pinctrl also add dt-binding file contains pin configuration defines for Zynq pinctrl. Signed-off-by: Sai Krishna Potthuri Link: https://lore.kernel.org/r/1626868353-96475-3-git-send-email-lakshmi.sai.krishna.potthuri@xilinx.com Signed-off-by: Linus Walleij --- Documentation/devicetree/bindings/pinctrl/xlnx,zynq-pinctrl.yaml | 8 +++----- 1 file changed, 3 insertions(+), 5 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pinctrl/xlnx,zynq-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/xlnx,zynq-pinctrl.yaml index 2da1969e02ec..ac97dbf6998e 100644 --- a/Documentation/devicetree/bindings/pinctrl/xlnx,zynq-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/xlnx,zynq-pinctrl.yaml @@ -156,10 +156,7 @@ patternProperties: slew-rate: enum: [0, 1] - io-standard: - description: - Selects the IO standard for MIO pins, this is driver specific. - $ref: "/schemas/types.yaml#/definitions/uint32" + power-source: enum: [1, 2, 3, 4] oneOf: @@ -179,6 +176,7 @@ additionalProperties: false examples: - | + #include pinctrl0: pinctrl@700 { compatible = "xlnx,zynq-pinctrl"; reg = <0x700 0x200>; @@ -193,7 +191,7 @@ examples: conf { groups = "uart1_10_grp"; slew-rate = <0>; - io-standard = <1>; + power-source = ; }; conf-rx { -- cgit v1.2.3 From 8d7e415d55610d503fdb8815344846b72d194a40 Mon Sep 17 00:00:00 2001 From: Leon Romanovsky Date: Wed, 28 Jul 2021 16:04:12 +0300 Subject: docs: Fix infiniband uverbs minor number Starting from the beginning of infiniband subsystem, the uverbs char devices start from 192 as a minor number, see commit bc38a6abdd5a ("[PATCH] IB uverbs: core implementation"). This patch updates the admin guide documentation to reflect it. Fixes: 9d85025b0418 ("docs-rst: create an user's manual book") Link: https://lore.kernel.org/r/bad03e6bcde45550c01e12908a6fe7dfa4770703.1627477347.git.leonro@nvidia.com Signed-off-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe --- Documentation/admin-guide/devices.txt | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/admin-guide/devices.txt b/Documentation/admin-guide/devices.txt index 9c2be821c225..922c23bb4372 100644 --- a/Documentation/admin-guide/devices.txt +++ b/Documentation/admin-guide/devices.txt @@ -2993,10 +2993,10 @@ 65 = /dev/infiniband/issm1 Second InfiniBand IsSM device ... 127 = /dev/infiniband/issm63 63rd InfiniBand IsSM device - 128 = /dev/infiniband/uverbs0 First InfiniBand verbs device - 129 = /dev/infiniband/uverbs1 Second InfiniBand verbs device + 192 = /dev/infiniband/uverbs0 First InfiniBand verbs device + 193 = /dev/infiniband/uverbs1 Second InfiniBand verbs device ... - 159 = /dev/infiniband/uverbs31 31st InfiniBand verbs device + 223 = /dev/infiniband/uverbs31 31st InfiniBand verbs device 232 char Biometric Devices 0 = /dev/biometric/sensor0/fingerprint first fingerprint sensor on first device -- cgit v1.2.3 From 2b761f476f3a6e0a212c8c88e7855f66edb177e0 Mon Sep 17 00:00:00 2001 From: Biju Das Date: Mon, 19 Jul 2021 14:40:33 +0100 Subject: ASoC: dt-bindings: Document RZ/G2L bindings Document RZ/G2L ASoC serial sound interface bindings. Signed-off-by: Biju Das Reviewed-by: Lad Prabhakar Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20210719134040.7964-2-biju.das.jz@bp.renesas.com Signed-off-by: Mark Brown --- .../devicetree/bindings/sound/renesas,rz-ssi.yaml | 85 ++++++++++++++++++++++ 1 file changed, 85 insertions(+) create mode 100644 Documentation/devicetree/bindings/sound/renesas,rz-ssi.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/renesas,rz-ssi.yaml b/Documentation/devicetree/bindings/sound/renesas,rz-ssi.yaml new file mode 100644 index 000000000000..891f381ee5b8 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/renesas,rz-ssi.yaml @@ -0,0 +1,85 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/renesas,rz-ssi.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Renesas RZ/G2L ASoC Sound Serial Interface (SSIF-2) + +maintainers: + - Biju Das + +properties: + compatible: + items: + - enum: + - renesas,r9a07g044-ssi # RZ/G2{L,LC} + - const: renesas,rz-ssi + + reg: + maxItems: 1 + + interrupts: + maxItems: 4 + + interrupt-names: + items: + - const: int_req + - const: dma_rx + - const: dma_tx + - const: dma_rt + + clocks: + maxItems: 4 + + clock-names: + items: + - const: ssi + - const: ssi_sfr + - const: audio_clk1 + - const: audio_clk2 + + power-domains: + maxItems: 1 + + resets: + maxItems: 1 + + '#sound-dai-cells': + const: 0 + +required: + - compatible + - reg + - interrupts + - interrupt-names + - clocks + - clock-names + - resets + - '#sound-dai-cells' + +additionalProperties: false + +examples: + - | + #include + #include + + ssi0: ssi@10049c00 { + compatible = "renesas,r9a07g044-ssi", + "renesas,rz-ssi"; + reg = <0x10049c00 0x400>; + interrupts = , + , + , + ; + interrupt-names = "int_req", "dma_rx", "dma_tx", "dma_rt"; + clocks = <&cpg CPG_MOD R9A07G044_SSI0_PCLK2>, + <&cpg CPG_MOD R9A07G044_SSI0_PCLK_SFR>, + <&audio_clk1>, + <&audio_clk2>; + clock-names = "ssi", "ssi_sfr", "audio_clk1", "audio_clk2"; + power-domains = <&cpg>; + resets = <&cpg R9A07G044_SSI0_RST_M2_REG>; + #sound-dai-cells = <0>; + }; -- cgit v1.2.3 From 5df6dfbb6de815ba3a75c788a916865212fd5221 Mon Sep 17 00:00:00 2001 From: Biju Das Date: Mon, 19 Jul 2021 14:40:38 +0100 Subject: ASoC: dt-bindings: sound: renesas,rz-ssi: Document DMA support Document DMA support in binding document. Signed-off-by: Biju Das Reviewed-by: Lad Prabhakar Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20210719134040.7964-7-biju.das.jz@bp.renesas.com Signed-off-by: Mark Brown --- .../devicetree/bindings/sound/renesas,rz-ssi.yaml | 15 +++++++++++++++ 1 file changed, 15 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/renesas,rz-ssi.yaml b/Documentation/devicetree/bindings/sound/renesas,rz-ssi.yaml index 891f381ee5b8..471937cb8d05 100644 --- a/Documentation/devicetree/bindings/sound/renesas,rz-ssi.yaml +++ b/Documentation/devicetree/bindings/sound/renesas,rz-ssi.yaml @@ -45,6 +45,18 @@ properties: resets: maxItems: 1 + dmas: + minItems: 1 + maxItems: 2 + + dma-names: + oneOf: + - items: + - const: tx + - const: rx + - items: + - const: rt + '#sound-dai-cells': const: 0 @@ -81,5 +93,8 @@ examples: clock-names = "ssi", "ssi_sfr", "audio_clk1", "audio_clk2"; power-domains = <&cpg>; resets = <&cpg R9A07G044_SSI0_RST_M2_REG>; + dmas = <&dmac 0x255>, + <&dmac 0x256>; + dma-names = "tx", "rx"; #sound-dai-cells = <0>; }; -- cgit v1.2.3 From 76f1fc266b897de07ad585667b574e03fd2e9d01 Mon Sep 17 00:00:00 2001 From: Hu Haowen Date: Thu, 29 Jul 2021 23:56:25 +0800 Subject: docs: add traditional Chinese translation for kernel Documentation Add traditional Chinese translation (zh_TW) for the Linux Kernel documentation with a series of translated files. Signed-off-by: Hu Haowen Reviewed-by: Pan Yunwang Link: https://lore.kernel.org/r/20210729155627.41744-1-src.res@email.cn Signed-off-by: Jonathan Corbet --- Documentation/translations/index.rst | 1 + Documentation/translations/zh_TW/IRQ.txt | 41 + .../translations/zh_TW/admin-guide/README.rst | 351 +++++ .../translations/zh_TW/admin-guide/bug-bisect.rst | 85 ++ .../translations/zh_TW/admin-guide/bug-hunting.rst | 344 +++++ .../zh_TW/admin-guide/clearing-warn-once.rst | 16 + .../translations/zh_TW/admin-guide/cpu-load.rst | 112 ++ .../translations/zh_TW/admin-guide/index.rst | 135 ++ .../translations/zh_TW/admin-guide/init.rst | 58 + .../zh_TW/admin-guide/reporting-issues.rst | 1337 ++++++++++++++++++++ .../zh_TW/admin-guide/security-bugs.rst | 78 ++ .../zh_TW/admin-guide/tainted-kernels.rst | 161 +++ .../translations/zh_TW/admin-guide/unicode.rst | 174 +++ .../translations/zh_TW/disclaimer-zh_TW.rst | 11 + Documentation/translations/zh_TW/gpio.txt | 651 ++++++++++ Documentation/translations/zh_TW/index.rst | 162 +++ Documentation/translations/zh_TW/io_ordering.txt | 68 + Documentation/translations/zh_TW/oops-tracing.txt | 212 ++++ Documentation/translations/zh_TW/sparse.txt | 91 ++ 19 files changed, 4088 insertions(+) create mode 100644 Documentation/translations/zh_TW/IRQ.txt create mode 100644 Documentation/translations/zh_TW/admin-guide/README.rst create mode 100644 Documentation/translations/zh_TW/admin-guide/bug-bisect.rst create mode 100644 Documentation/translations/zh_TW/admin-guide/bug-hunting.rst create mode 100644 Documentation/translations/zh_TW/admin-guide/clearing-warn-once.rst create mode 100644 Documentation/translations/zh_TW/admin-guide/cpu-load.rst create mode 100644 Documentation/translations/zh_TW/admin-guide/index.rst create mode 100644 Documentation/translations/zh_TW/admin-guide/init.rst create mode 100644 Documentation/translations/zh_TW/admin-guide/reporting-issues.rst create mode 100644 Documentation/translations/zh_TW/admin-guide/security-bugs.rst create mode 100644 Documentation/translations/zh_TW/admin-guide/tainted-kernels.rst create mode 100644 Documentation/translations/zh_TW/admin-guide/unicode.rst create mode 100644 Documentation/translations/zh_TW/disclaimer-zh_TW.rst create mode 100644 Documentation/translations/zh_TW/gpio.txt create mode 100644 Documentation/translations/zh_TW/index.rst create mode 100644 Documentation/translations/zh_TW/io_ordering.txt create mode 100644 Documentation/translations/zh_TW/oops-tracing.txt create mode 100644 Documentation/translations/zh_TW/sparse.txt (limited to 'Documentation') diff --git a/Documentation/translations/index.rst b/Documentation/translations/index.rst index 556b050884fc..1175a47d07f0 100644 --- a/Documentation/translations/index.rst +++ b/Documentation/translations/index.rst @@ -8,6 +8,7 @@ Translations :maxdepth: 1 zh_CN/index + zh_TW/index it_IT/index ko_KR/index ja_JP/index diff --git a/Documentation/translations/zh_TW/IRQ.txt b/Documentation/translations/zh_TW/IRQ.txt new file mode 100644 index 000000000000..73d435a0d1e7 --- /dev/null +++ b/Documentation/translations/zh_TW/IRQ.txt @@ -0,0 +1,41 @@ +Chinese translated version of Documentation/core-api/irq/index.rst + +If you have any comment or update to the content, please contact the +original document maintainer directly. However, if you have a problem +communicating in English you can also ask the Chinese maintainer for +help. Contact the Chinese maintainer if this translation is outdated +or if there is a problem with the translation. + +Maintainer: Eric W. Biederman +Traditional Chinese maintainer: Hu Haowen +--------------------------------------------------------------------- +Documentation/core-api/irq/index.rst 的繁體中文翻譯 + +如果想評論或更新本文的內容，請直接聯繫原文檔的維護者。如果你使用英文 +交流有困難的話，也可以向繁體中文版維護者求助。如果本翻譯更新不及時或 +者翻譯存在問題，請聯繫繁體中文版維護者。 + +英文版維護者： Eric W. Biederman +繁體中文版維護者： 胡皓文 Hu Haowen +繁體中文版翻譯者： 胡皓文 Hu Haowen +繁體中文版校譯者： 胡皓文 Hu Haowen + + +以下爲正文 +--------------------------------------------------------------------- +何爲 IRQ? + +一個 IRQ 是來自某個設備的一個中斷請求。目前，它們可以來自一個硬體引腳， +或來自一個數據包。多個設備可能連接到同個硬體引腳，從而共享一個 IRQ。 + +一個 IRQ 編號是用於告知硬體中斷源的內核標識。通常情況下，這是一個 +全局 irq_desc 數組的索引，但是除了在 linux/interrupt.h 中的實現， +具體的細節是體系結構特定的。 + +一個 IRQ 編號是設備上某個可能的中斷源的枚舉。通常情況下，枚舉的編號是 +該引腳在系統內中斷控制器的所有輸入引腳中的編號。對於 ISA 總線中的情況， +枚舉的是在兩個 i8259 中斷控制器中 16 個輸入引腳。 + +架構可以對 IRQ 編號指定額外的含義，在硬體涉及任何手工配置的情況下， +是被提倡的。ISA 的 IRQ 是一個分配這類額外含義的典型例子。 + diff --git a/Documentation/translations/zh_TW/admin-guide/README.rst b/Documentation/translations/zh_TW/admin-guide/README.rst new file mode 100644 index 000000000000..b752e50359e6 --- /dev/null +++ b/Documentation/translations/zh_TW/admin-guide/README.rst @@ -0,0 +1,351 @@ +.. SPDX-License-Identifier: GPL-2.0 + +.. include:: ../disclaimer-zh_TW.rst + +:Original: Documentation/admin-guide/README.rst + +:譯者: + + 吳想成 Wu XiangCheng + 胡皓文 Hu Haowen + +Linux內核5.x版本 +========================================= + +以下是Linux版本5的發行註記。仔細閱讀它們， +它們會告訴你這些都是什麼，解釋如何安裝內核，以及遇到問題時該如何做。 + +什麼是Linux？ +--------------- + + Linux是Unix作業系統的克隆版本，由Linus Torvalds在一個鬆散的網絡黑客 + （Hacker，無貶義）團隊的幫助下從頭開始編寫。它旨在實現兼容POSIX和 + 單一UNIX規範。 + + 它具有在現代成熟的Unix中應當具有的所有功能，包括真正的多任務處理、虛擬內存、 + 共享庫、按需加載、共享的寫時拷貝（COW）可執行文件、恰當的內存管理以及包括 + IPv4和IPv6在內的複合網絡棧。 + + Linux在GNU通用公共許可證，版本2（GNU GPLv2）下分發，詳見隨附的COPYING文件。 + +它能在什麼樣的硬體上運行？ +----------------------------- + + 雖然Linux最初是爲32位的x86 PC機（386或更高版本）開發的，但今天它也能運行在 + （至少）Compaq Alpha AXP、Sun SPARC與UltraSPARC、Motorola 68000、PowerPC、 + PowerPC64、ARM、Hitachi SuperH、Cell、IBM S/390、MIPS、HP PA-RISC、Intel + IA-64、DEC VAX、AMD x86-64 Xtensa和ARC架構上。 + + Linux很容易移植到大多數通用的32位或64位體系架構，只要它們有一個分頁內存管理 + 單元（PMMU）和一個移植的GNU C編譯器（gcc；GNU Compiler Collection，GCC的一 + 部分）。Linux也被移植到許多沒有PMMU的體系架構中，儘管功能顯然受到了一定的 + 限制。 + Linux也被移植到了其自己上。現在可以將內核作爲用戶空間應用程式運行——這被 + 稱爲用戶模式Linux（UML）。 + +文檔 +----- +網際網路上和書籍上都有大量的電子文檔，既有Linux專屬文檔，也有與一般UNIX問題相關 +的文檔。我建議在任何Linux FTP站點上查找LDP（Linux文檔項目）書籍的文檔子目錄。 +本自述文件並不是關於系統的文檔：有更好的可用資源。 + + - 網際網路上和書籍上都有大量的（電子）文檔，既有Linux專屬文檔，也有與普通 + UNIX問題相關的文檔。我建議在任何有LDP（Linux文檔項目）書籍的Linux FTP + 站點上查找文檔子目錄。本自述文件並不是關於系統的文檔：有更好的可用資源。 + + - 文檔/子目錄中有各種自述文件：例如，這些文件通常包含一些特定驅動程序的 + 內核安裝說明。請閱讀 + :ref:`Documentation/process/changes.rst ` 文件，它包含了升級內核 + 可能會導致的問題的相關信息。 + +安裝內核原始碼 +--------------- + + - 如果您要安裝完整的原始碼，請把內核tar檔案包放在您有權限的目錄中（例如您 + 的主目錄）並將其解包:: + + xz -cd linux-5.x.tar.xz | tar xvf - + + 將「X」替換成最新內核的版本號。 + + 【不要】使用 /usr/src/linux 目錄！這裡有一組庫頭文件使用的內核頭文件 + （通常是不完整的）。它們應該與庫匹配，而不是被內核的變化搞得一團糟。 + + - 您還可以通過打補丁在5.x版本之間升級。補丁以xz格式分發。要通過打補丁進行 + 安裝，請獲取所有較新的補丁文件，進入內核原始碼（linux-5.x）的目錄並 + 執行:: + + xz -cd ../patch-5.x.xz | patch -p1 + + 請【按順序】替換所有大於當前原始碼樹版本的「x」，這樣就可以了。您可能想要 + 刪除備份文件（文件名類似xxx~ 或 xxx.orig)，並確保沒有失敗的補丁（文件名 + 類似xxx# 或 xxx.rej）。如果有，不是你就是我犯了錯誤。 + + 與5.x內核的補丁不同，5.x.y內核（也稱爲穩定版內核）的補丁不是增量的，而是 + 直接應用於基本的5.x內核。例如，如果您的基本內核是5.0，並且希望應用5.0.3 + 補丁，則不應先應用5.0.1和5.0.2的補丁。類似地，如果您運行的是5.0.2內核， + 並且希望跳轉到5.0.3，那麼在應用5.0.3補丁之前，必須首先撤銷5.0.2補丁 + （即patch -R）。更多關於這方面的內容，請閱讀 + :ref:`Documentation/process/applying-patches.rst ` 。 + + 或者，腳本 patch-kernel 可以用來自動化這個過程。它能確定當前內核版本並 + 應用找到的所有補丁:: + + linux/scripts/patch-kernel linux + + 上面命令中的第一個參數是內核原始碼的位置。補丁是在當前目錄應用的，但是 + 可以將另一個目錄指定爲第二個參數。 + + - 確保沒有過時的 .o 文件和依賴項:: + + cd linux + make mrproper + + 現在您應該已經正確安裝了原始碼。 + +軟體要求 +--------- + + 編譯和運行5.x內核需要各種軟體包的最新版本。請參考 + :ref:`Documentation/process/changes.rst ` + 來了解最低版本要求以及如何升級軟體包。請注意，使用過舊版本的這些包可能會 + 導致很難追蹤的間接錯誤，因此不要以爲在生成或操作過程中出現明顯問題時可以 + 只更新包。 + +爲內核建立目錄 +--------------- + + 編譯內核時，默認情況下所有輸出文件都將與內核原始碼放在一起。使用 + ``make O=output/dir`` 選項可以爲輸出文件（包括 .config）指定備用位置。 + 例如:: + + kernel source code: /usr/src/linux-5.x + build directory: /home/name/build/kernel + + 要配置和構建內核，請使用:: + + cd /usr/src/linux-5.x + make O=/home/name/build/kernel menuconfig + make O=/home/name/build/kernel + sudo make O=/home/name/build/kernel modules_install install + + 請注意：如果使用了 ``O=output/dir`` 選項，那麼它必須用於make的所有調用。 + +配置內核 +--------- + + 即使只升級一個小版本，也不要跳過此步驟。每個版本中都會添加新的配置選項， + 如果配置文件沒有按預定設置，就會出現奇怪的問題。如果您想以最少的工作量 + 將現有配置升級到新版本，請使用 ``makeoldconfig`` ，它只會詢問您新配置 + 選項的答案。 + + - 其他配置命令包括:: + + "make config" 純文本界面。 + + "make menuconfig" 基於文本的彩色菜單、選項列表和對話框。 + + "make nconfig" 增強的基於文本的彩色菜單。 + + "make xconfig" 基於Qt的配置工具。 + + "make gconfig" 基於GTK+的配置工具。 + + "make oldconfig" 基於現有的 ./.config 文件選擇所有選項，並詢問 + 新配置選項。 + + "make olddefconfig" + 類似上一個，但不詢問直接將新選項設置爲默認值。 + + "make defconfig" 根據體系架構，使用arch/$arch/defconfig或 + arch/$arch/configs/${PLATFORM}_defconfig中的 + 默認選項值創建./.config文件。 + + "make ${PLATFORM}_defconfig" + 使用arch/$arch/configs/${PLATFORM}_defconfig中 + 的默認選項值創建一個./.config文件。 + 用「makehelp」來獲取您體系架構中所有可用平台的列表。 + + "make allyesconfig" + 通過儘可能將選項值設置爲「y」，創建一個 + ./.config文件。 + + "make allmodconfig" + 通過儘可能將選項值設置爲「m」，創建一個 + ./.config文件。 + + "make allnoconfig" 通過儘可能將選項值設置爲「n」，創建一個 + ./.config文件。 + + "make randconfig" 通過隨機設置選項值來創建./.config文件。 + + "make localmodconfig" 基於當前配置和加載的模塊（lsmod）創建配置。禁用 + 已加載的模塊不需要的任何模塊選項。 + + 要爲另一台計算機創建localmodconfig，請將該計算機 + 的lsmod存儲到一個文件中，並將其作爲lsmod參數傳入。 + + 此外，通過在參數LMC_KEEP中指定模塊的路徑，可以將 + 模塊保留在某些文件夾或kconfig文件中。 + + target$ lsmod > /tmp/mylsmod + target$ scp /tmp/mylsmod host:/tmp + + host$ make LSMOD=/tmp/mylsmod \ + LMC_KEEP="drivers/usb:drivers/gpu:fs" \ + localmodconfig + + 上述方法在交叉編譯時也適用。 + + "make localyesconfig" 與localmodconfig類似，只是它會將所有模塊選項轉換 + 爲內置（=y）。你可以同時通過LMC_KEEP保留模塊。 + + "make kvmconfig" 爲kvm客體內核支持啓用其他選項。 + + "make xenconfig" 爲xen dom0客體內核支持啓用其他選項。 + + "make tinyconfig" 配置儘可能小的內核。 + + 更多關於使用Linux內核配置工具的信息，見文檔 + Documentation/kbuild/kconfig.rst。 + + - ``make config`` 注意事項: + + - 包含不必要的驅動程序會使內核變大，並且在某些情況下會導致問題： + 探測不存在的控制器卡可能會混淆其他控制器。 + + - 如果存在協處理器，則編譯了數學仿真的內核仍將使用協處理器：在 + 這種情況下，數學仿真永遠不會被使用。內核會稍微大一點，但不管 + 是否有數學協處理器，都可以在不同的機器上工作。 + + - 「kernel hacking」配置細節通常會導致更大或更慢的內核（或兩者 + 兼而有之），甚至可以通過配置一些例程來主動嘗試破壞壞代碼以發現 + 內核問題，從而降低內核的穩定性（kmalloc()）。因此，您可能應該 + 用於研究「開發」、「實驗」或「調試」特性相關問題。 + +編譯內核 +--------- + + - 確保您至少有gcc 4.9可用。 + 有關更多信息，請參閱 :ref:`Documentation/process/changes.rst ` 。 + + 請注意，您仍然可以使用此內核運行a.out用戶程序。 + + - 執行 ``make`` 來創建壓縮內核映像。如果您安裝了lilo以適配內核makefile， + 那麼也可以進行 ``makeinstall`` ，但是您可能需要先檢查特定的lilo設置。 + + 實際安裝必須以root身份執行，但任何正常構建都不需要。 + 無須徒然使用root身份。 + + - 如果您將內核的任何部分配置爲模塊，那麼還必須執行 ``make modules_install`` 。 + + - 詳細的內核編譯/生成輸出： + + 通常，內核構建系統在相當安靜的模式下運行（但不是完全安靜）。但是有時您或 + 其他內核開發人員需要看到編譯、連結或其他命令的執行過程。爲此，可使用 + 「verbose（詳細）」構建模式。 + 向 ``make`` 命令傳遞 ``V=1`` 來實現，例如:: + + make V=1 all + + 如需構建系統也給出內個目標重建的願意，請使用 ``V=2`` 。默認爲 ``V=0`` 。 + + - 準備一個備份內核以防出錯。對於開發版本尤其如此，因爲每個新版本都包含 + 尚未調試的新代碼。也要確保保留與該內核對應的模塊的備份。如果要安裝 + 與工作內核版本號相同的新內核，請在進行 ``make modules_install`` 安裝 + 之前備份modules目錄。 + + 或者，在編譯之前，使用內核配置選項「LOCALVERSION」向常規內核版本附加 + 一個唯一的後綴。LOCALVERSION可以在「General Setup」菜單中設置。 + + - 爲了引導新內核，您需要將內核映像（例如編譯後的 + .../linux/arch/x86/boot/bzImage）複製到常規可引導內核的位置。 + + - 不再支持在沒有LILO等啓動裝載程序幫助的情況下直接從軟盤引導內核。 + + 如果從硬碟引導Linux，很可能使用LILO，它使用/etc/lilo.conf文件中 + 指定的內核映像文件。內核映像文件通常是/vmlinuz、/boot/vmlinuz、 + /bzImage或/boot/bzImage。使用新內核前，請保存舊映像的副本，並複製 + 新映像覆蓋舊映像。然後您【必須重新運行LILO】來更新加載映射！否則， + 將無法啓動新的內核映像。 + + 重新安裝LILO通常需要運行/sbin/LILO。您可能希望編輯/etc/lilo.conf + 文件爲舊內核映像指定一個條目（例如/vmlinux.old)防止新的不能正常 + 工作。有關更多信息，請參閱LILO文檔。 + + 重新安裝LILO之後，您應該就已經準備好了。關閉系統，重新啓動，盡情 + 享受吧！ + + 如果需要更改內核映像中的默認根設備、視頻模式等，請在適當的地方使用 + 啓動裝載程序的引導選項。無需重新編譯內核即可更改這些參數。 + + - 使用新內核重新啓動並享受它吧。 + +若遇到問題 +----------- + + - 如果您發現了一些可能由於內核缺陷所導致的問題，請檢查MAINTAINERS（維護者） + 文件看看是否有人與令您遇到麻煩的內核部分相關。如果無人在此列出，那麼第二 + 個最好的方案就是把它們發給我（torvalds@linux-foundation.org），也可能發送 + 到任何其他相關的郵件列表或新聞組。 + + - 在所有的缺陷報告中，【請】告訴我們您在說什麼內核，如何復現問題，以及您的 + 設置是什麼的（使用您的常識）。如果問題是新的，請告訴我；如果問題是舊的， + 請嘗試告訴我您什麼時候首次注意到它。 + + - 如果缺陷導致如下消息:: + + unable to handle kernel paging request at address C0000010 + Oops: 0002 + EIP: 0010:XXXXXXXX + eax: xxxxxxxx ebx: xxxxxxxx ecx: xxxxxxxx edx: xxxxxxxx + esi: xxxxxxxx edi: xxxxxxxx ebp: xxxxxxxx + ds: xxxx es: xxxx fs: xxxx gs: xxxx + Pid: xx, process nr: xx + xx xx xx xx xx xx xx xx xx xx + + 或者類似的內核調試信息顯示在屏幕上或在系統日誌里，請【如實】複製它。 + 可能對你來說轉儲（dump）看起來不可理解，但它確實包含可能有助於調試問題的 + 信息。轉儲上方的文本也很重要：它說明了內核轉儲代碼的原因（在上面的示例中， + 是由於內核指針錯誤）。更多關於如何理解轉儲的信息，請參見 + Documentation/admin-guide/bug-hunting.rst。 + + - 如果使用 CONFIG_KALLSYMS 編譯內核，則可以按原樣發送轉儲，否則必須使用 + ``ksymoops`` 程序來理解轉儲（但通常首選使用CONFIG_KALLSYMS編譯）。 + 此實用程序可從 + https://www.kernel.org/pub/linux/utils/kernel/ksymoops/ 下載。 + 或者，您可以手動執行轉儲查找： + + - 在調試像上面這樣的轉儲時，如果您可以查找EIP值的含義，這將非常有幫助。 + 十六進位值本身對我或其他任何人都沒有太大幫助：它會取決於特定的內核設置。 + 您應該做的是從EIP行獲取十六進位值（忽略 ``0010:`` ），然後在內核名字列表 + 中查找它，以查看哪個內核函數包含有問題的地址。 + + 要找到內核函數名，您需要找到與顯示症狀的內核相關聯的系統二進位文件。就是 + 文件「linux/vmlinux」。要提取名字列表並將其與內核崩潰中的EIP進行匹配， + 請執行:: + + nm vmlinux | sort | less + + 這將爲您提供一個按升序排序的內核地址列表，從中很容易找到包含有問題的地址 + 的函數。請注意，內核調試消息提供的地址不一定與函數地址完全匹配（事實上， + 這是不可能的），因此您不能只「grep」列表：不過列表將爲您提供每個內核函數 + 的起點，因此通過查找起始地址低於你正在搜索的地址，但後一個函數的高於的 + 函數，你會找到您想要的。實際上，在您的問題報告中加入一些「上下文」可能是 + 一個好主意，給出相關的上下幾行。 + + 如果您由於某些原因無法完成上述操作（如您使用預編譯的內核映像或類似的映像）， + 請儘可能多地告訴我您的相關設置信息，這會有所幫助。有關詳細信息請閱讀 + 『Documentation/admin-guide/reporting-issues.rst』。 + + - 或者，您可以在正在運行的內核上使用gdb（只讀的；即不能更改值或設置斷點）。 + 爲此，請首先使用-g編譯內核；適當地編輯arch/x86/Makefile，然後執行 ``make + clean`` 。您還需要啓用CONFIG_PROC_FS（通過 ``make config`` ）。 + + 使用新內核重新啓動後，執行 ``gdb vmlinux /proc/kcore`` 。現在可以使用所有 + 普通的gdb命令。查找系統崩潰點的命令是 ``l *0xXXXXXXXX`` （將xxx替換爲EIP + 值）。 + + 用gdb無法調試一個當前未運行的內核是由於gdb（錯誤地）忽略了編譯內核的起始 + 偏移量。 + diff --git a/Documentation/translations/zh_TW/admin-guide/bug-bisect.rst b/Documentation/translations/zh_TW/admin-guide/bug-bisect.rst new file mode 100644 index 000000000000..41a39aebb8d6 --- /dev/null +++ b/Documentation/translations/zh_TW/admin-guide/bug-bisect.rst @@ -0,0 +1,85 @@ +.. SPDX-License-Identifier: GPL-2.0 + +.. include:: ../disclaimer-zh_TW.rst + +:Original: :doc:`../../../admin-guide/bug-bisect` + +:譯者: + + 吳想成 Wu XiangCheng + 胡皓文 Hu Haowen + +二分（bisect）缺陷 ++++++++++++++++++++ + +（英文版）最後更新：2016年10月28日 + +引言 +===== + +始終嘗試由來自kernel.org的原始碼構建的最新內核。如果您沒有信心這樣做，請將 +錯誤報告給您的發行版供應商，而不是內核開發人員。 + +找到缺陷（bug）並不總是那麼容易，不過仍然得去找。如果你找不到它，不要放棄。 +儘可能多的向相關維護人員報告您發現的信息。請參閱MAINTAINERS文件以了解您所 +關注的子系統的維護人員。 + +在提交錯誤報告之前，請閱讀「Documentation/admin-guide/reporting-issues.rst」。 + +設備未出現（Devices not appearing） +==================================== + +這通常是由udev/systemd引起的。在將其歸咎於內核之前先檢查一下。 + +查找導致缺陷的補丁 +=================== + +使用 ``git`` 提供的工具可以很容易地找到缺陷，只要缺陷是可復現的。 + +操作步驟： + +- 從git原始碼構建內核 +- 以此開始二分 [#f1]_:: + + $ git bisect start + +- 標記損壞的變更集:: + + $ git bisect bad [commit] + +- 標記正常工作的變更集:: + + $ git bisect good [commit] + +- 重新構建內核並測試 +- 使用以下任一與git bisect進行交互:: + + $ git bisect good + + 或:: + + $ git bisect bad + + 這取決於您測試的變更集上是否有缺陷 +- 在一些交互之後，git bisect將給出可能導致缺陷的變更集。 + +- 例如，如果您知道當前版本有問題，而4.8版本是正常的，則可以執行以下操作:: + + $ git bisect start + $ git bisect bad # Current version is bad + $ git bisect good v4.8 + + +.. [#f1] 您可以（可選地）在開始git bisect的時候提供good或bad參數 + ``git bisect start [BAD] [GOOD]`` + +如需進一步參考，請閱讀： + +- ``git-bisect`` 的手冊頁 +- `Fighting regressions with git bisect（用git bisect解決回歸） + `_ +- `Fully automated bisecting with "git bisect run"（使用git bisect run + 來全自動二分） `_ +- `Using Git bisect to figure out when brokenness was introduced + （使用Git二分來找出何時引入了錯誤） `_ + diff --git a/Documentation/translations/zh_TW/admin-guide/bug-hunting.rst b/Documentation/translations/zh_TW/admin-guide/bug-hunting.rst new file mode 100644 index 000000000000..4d813aec77d2 --- /dev/null +++ b/Documentation/translations/zh_TW/admin-guide/bug-hunting.rst @@ -0,0 +1,344 @@ +.. SPDX-License-Identifier: GPL-2.0 + +.. include:: ../disclaimer-zh_TW.rst + +:Original: :doc:`../../../admin-guide/bug-hunting` + +:譯者: + + 吳想成 Wu XiangCheng + 胡皓文 Hu Haowen + +追蹤缺陷 +========= + +內核錯誤報告通常附帶如下堆棧轉儲:: + + ------------[ cut here ]------------ + WARNING: CPU: 1 PID: 28102 at kernel/module.c:1108 module_put+0x57/0x70 + Modules linked in: dvb_usb_gp8psk(-) dvb_usb dvb_core nvidia_drm(PO) nvidia_modeset(PO) snd_hda_codec_hdmi snd_hda_intel snd_hda_codec snd_hwdep snd_hda_core snd_pcm snd_timer snd soundcore nvidia(PO) [last unloaded: rc_core] + CPU: 1 PID: 28102 Comm: rmmod Tainted: P WC O 4.8.4-build.1 #1 + Hardware name: MSI MS-7309/MS-7309, BIOS V1.12 02/23/2009 + 00000000 c12ba080 00000000 00000000 c103ed6a c1616014 00000001 00006dc6 + c1615862 00000454 c109e8a7 c109e8a7 00000009 ffffffff 00000000 f13f6a10 + f5f5a600 c103ee33 00000009 00000000 00000000 c109e8a7 f80ca4d0 c109f617 + Call Trace: + [] ? dump_stack+0x44/0x64 + [] ? __warn+0xfa/0x120 + [] ? module_put+0x57/0x70 + [] ? module_put+0x57/0x70 + [] ? warn_slowpath_null+0x23/0x30 + [] ? module_put+0x57/0x70 + [] ? gp8psk_fe_set_frontend+0x460/0x460 [dvb_usb_gp8psk] + [] ? symbol_put_addr+0x27/0x50 + [] ? dvb_usb_adapter_frontend_exit+0x3a/0x70 [dvb_usb] + [] ? dvb_usb_exit+0x2f/0xd0 [dvb_usb] + [] ? usb_disable_endpoint+0x7c/0xb0 + [] ? dvb_usb_device_exit+0x2a/0x50 [dvb_usb] + [] ? usb_unbind_interface+0x62/0x250 + [] ? __pm_runtime_idle+0x44/0x70 + [] ? __device_release_driver+0x78/0x120 + [] ? driver_detach+0x87/0x90 + [] ? bus_remove_driver+0x38/0x90 + [] ? usb_deregister+0x58/0xb0 + [] ? SyS_delete_module+0x130/0x1f0 + [] ? task_work_run+0x64/0x80 + [] ? exit_to_usermode_loop+0x85/0x90 + [] ? do_fast_syscall_32+0x80/0x130 + [] ? sysenter_past_esp+0x40/0x6a + ---[ end trace 6ebc60ef3981792f ]--- + +這樣的堆棧跟蹤提供了足夠的信息來識別內核原始碼中發生錯誤的那一行。根據問題的 +嚴重性，它還可能包含 **「Oops」** 一詞，比如:: + + BUG: unable to handle kernel NULL pointer dereference at (null) + IP: [] iret_exc+0x7d0/0xa59 + *pdpt = 000000002258a001 *pde = 0000000000000000 + Oops: 0002 [#1] PREEMPT SMP + ... + +儘管有 **Oops** 或其他類型的堆棧跟蹤，但通常需要找到出問題的行來識別和處理缺 +陷。在本章中，我們將參考「Oops」來了解需要分析的各種堆棧跟蹤。 + +如果內核是用 ``CONFIG_DEBUG_INFO`` 編譯的，那麼可以使用文件： +`scripts/decode_stacktrace.sh` 。 + +連結的模塊 +----------- + +受到汙染或正在加載/卸載的模塊用「（…）」標記，汙染標誌在 +`Documentation/admin-guide/tainted-kernels.rst` 文件中進行了描述，「正在被加 +載」用「+」標註，「正在被卸載」用「-」標註。 + + +Oops消息在哪？ +--------------- + +通常，Oops文本由klogd從內核緩衝區讀取，然後交給 ``syslogd`` ，後者將其寫入 +syslog文件，通常是 ``/var/log/messages`` （取決於 ``/etc/syslog.conf`` ）。 +在使用systemd的系統上，它也可以由 ``journald`` 守護進程存儲，並通過運行 +``journalctl`` 命令進行訪問。 + +有時 ``klogd`` 會掛掉，這種情況下您可以運行 ``dmesg > file`` 從內核緩衝區 +讀取數據並保存它。或者您可以 ``cat /proc/kmsg > file`` ，但是您必須適時 +中斷以停止傳輸，因爲 ``kmsg`` 是一個「永無止境的文件」。 + +如果機器嚴重崩潰，無法輸入命令或磁碟不可用，那還有三個選項： + +(1) 手動複製屏幕上的文本，並在機器重新啓動後輸入。很難受，但這是突然崩潰下 + 唯一的選擇。或者你可以用數位相機拍下屏幕——雖然不那麼好，但總比什麼都沒 + 有好。如果消息滾動超出控制台頂部，使用更高解析度（例如 ``vga=791`` ） + 引導啓動將允許您閱讀更多文本。（警告：這需要 ``vesafb`` ，因此對「早期」 + 的Oppses沒有幫助） + +(2) 從串口終端啓動（參見 + :ref:`Documentation/admin-guide/serial-console.rst ` ）， + 在另一台機器上運行數據機然後用你喜歡的通信程序捕獲輸出。 + Minicom運行良好。 + +(3) 使用Kdump（參閱 Documentation/admin-guide/kdump/kdump.rst ），使用 + Documentation/admin-guide/kdump/gdbmacros.txt 中的dmesg gdbmacro從舊內存 + 中提取內核環形緩衝區。 + +找到缺陷位置 +------------- + +如果你能指出缺陷在內核原始碼中的位置，則報告缺陷的效果會非常好。這有兩種方法。 +通常來說使用 ``gdb`` 會比較容易，不過內核需要用調試信息來預編譯。 + +gdb +^^^^ + +GNU 調試器（GNU debugger， ``gdb`` ）是從 ``vmlinux`` 文件中找出OOPS的確切 +文件和行號的最佳方法。 + +在使用 ``CONFIG_DEBUG_INFO`` 編譯的內核上使用gdb效果最好。可通過運行以下命令 +進行設置:: + + $ ./scripts/config -d COMPILE_TEST -e DEBUG_KERNEL -e DEBUG_INFO + +在用 ``CONFIG_DEBUG_INFO`` 編譯的內核上，你可以直接從OOPS複製EIP值:: + + EIP: 0060:[] Not tainted VLI + +並使用GDB來將其翻譯成可讀形式:: + + $ gdb vmlinux + (gdb) l *0xc021e50e + +如果沒有啓用 ``CONFIG_DEBUG_INFO`` ，則使用OOPS的函數偏移:: + + EIP is at vt_ioctl+0xda8/0x1482 + +並在啓用 ``CONFIG_DEBUG_INFO`` 的情況下重新編譯內核:: + + $ ./scripts/config -d COMPILE_TEST -e DEBUG_KERNEL -e DEBUG_INFO + $ make vmlinux + $ gdb vmlinux + (gdb) l *vt_ioctl+0xda8 + 0x1888 is in vt_ioctl (drivers/tty/vt/vt_ioctl.c:293). + 288 { + 289 struct vc_data *vc = NULL; + 290 int ret = 0; + 291 + 292 console_lock(); + 293 if (VT_BUSY(vc_num)) + 294 ret = -EBUSY; + 295 else if (vc_num) + 296 vc = vc_deallocate(vc_num); + 297 console_unlock(); + +或者若您想要更詳細的顯示:: + + (gdb) p vt_ioctl + $1 = {int (struct tty_struct *, unsigned int, unsigned long)} 0xae0 + (gdb) l *0xae0+0xda8 + +您也可以使用對象文件作爲替代:: + + $ make drivers/tty/ + $ gdb drivers/tty/vt/vt_ioctl.o + (gdb) l *vt_ioctl+0xda8 + +如果你有調用跟蹤，類似:: + + Call Trace: + [] :jbd:log_wait_commit+0xa3/0xf5 + [] autoremove_wake_function+0x0/0x2e + [] :jbd:journal_stop+0x1be/0x1ee + ... + +這表明問題可能在 :jbd: 模塊中。您可以在gdb中加載該模塊並列出相關代碼:: + + $ gdb fs/jbd/jbd.ko + (gdb) l *log_wait_commit+0xa3 + +.. note:: + + 您還可以對堆棧跟蹤處的任何函數調用執行相同的操作，例如:: + + [] ? dvb_usb_adapter_frontend_exit+0x3a/0x70 [dvb_usb] + + 上述調用發生的位置可以通過以下方式看到:: + + $ gdb drivers/media/usb/dvb-usb/dvb-usb.o + (gdb) l *dvb_usb_adapter_frontend_exit+0x3a + +objdump +^^^^^^^^ + +要調試內核，請使用objdump並從崩潰輸出中查找十六進位偏移，以找到有效的代碼/匯 +編行。如果沒有調試符號，您將看到所示例程的彙編程序代碼，但是如果內核有調試 +符號，C代碼也將可見（調試符號可以在內核配置菜單的hacking項中啓用）。例如:: + + $ objdump -r -S -l --disassemble net/dccp/ipv4.o + +.. note:: + + 您需要處於內核樹的頂層以便此獲得您的C文件。 + +如果您無法訪問原始碼，仍然可以使用以下方法調試一些崩潰轉儲（如Dave Miller的 +示例崩潰轉儲輸出所示）:: + + EIP is at +0x14/0x4c0 + ... + Code: 44 24 04 e8 6f 05 00 00 e9 e8 fe ff ff 8d 76 00 8d bc 27 00 00 + 00 00 55 57 56 53 81 ec bc 00 00 00 8b ac 24 d0 00 00 00 8b 5d 08 + <8b> 83 3c 01 00 00 89 44 24 14 8b 45 28 85 c0 89 44 24 18 0f 85 + + Put the bytes into a "foo.s" file like this: + + .text + .globl foo + foo: + .byte .... /* bytes from Code: part of OOPS dump */ + + Compile it with "gcc -c -o foo.o foo.s" then look at the output of + "objdump --disassemble foo.o". + + Output: + + ip_queue_xmit: + push %ebp + push %edi + push %esi + push %ebx + sub $0xbc, %esp + mov 0xd0(%esp), %ebp ! %ebp = arg0 (skb) + mov 0x8(%ebp), %ebx ! %ebx = skb->sk + mov 0x13c(%ebx), %eax ! %eax = inet_sk(sk)->opt + +`scripts/decodecode` 文件可以用來自動完成大部分工作，這取決於正在調試的CPU +體系結構。 + +報告缺陷 +--------- + +一旦你通過定位缺陷找到了其發生的地方，你可以嘗試自己修復它或者向上游報告它。 + +爲了向上游報告，您應該找出用於開發受影響代碼的郵件列表。這可以使用 ``get_maintainer.pl`` 。 + + +例如，您在gspca的sonixj.c文件中發現一個缺陷，則可以通過以下方法找到它的維護者:: + + $ ./scripts/get_maintainer.pl -f drivers/media/usb/gspca/sonixj.c + Hans Verkuil (odd fixer:GSPCA USB WEBCAM DRIVER,commit_signer:1/1=100%) + Mauro Carvalho Chehab (maintainer:MEDIA INPUT INFRASTRUCTURE (V4L/DVB),commit_signer:1/1=100%) + Tejun Heo (commit_signer:1/1=100%) + Bhaktipriya Shridhar (commit_signer:1/1=100%,authored:1/1=100%,added_lines:4/4=100%,removed_lines:9/9=100%) + linux-media@vger.kernel.org (open list:GSPCA USB WEBCAM DRIVER) + linux-kernel@vger.kernel.org (open list) + +請注意它將指出： + +- 最後接觸原始碼的開發人員（如果這是在git樹中完成的）。在上面的例子中是Tejun + 和Bhaktipriya（在這個特定的案例中，沒有人真正參與這個文件的開發）； +- 驅動維護人員（Hans Verkuil）； +- 子系統維護人員（Mauro Carvalho Chehab）； +- 驅動程序和/或子系統郵件列表（linux-media@vger.kernel.org）； +- Linux內核郵件列表（linux-kernel@vger.kernel.org）。 + +通常，修復缺陷的最快方法是將它報告給用於開發相關代碼的郵件列表（linux-media +ML），抄送驅動程序維護者（Hans）。 + +如果你完全不知道該把報告寄給誰，且 ``get_maintainer.pl`` 也沒有提供任何有用 +的信息，請發送到linux-kernel@vger.kernel.org。 + +感謝您的幫助，這使Linux儘可能穩定:-) + +修復缺陷 +--------- + +如果你懂得編程，你不僅可以通過報告錯誤來幫助我們，還可以提供一個解決方案。 +畢竟，開源就是分享你的工作，你不想因爲你的天才而被認可嗎？ + +如果你決定這樣做，請在制定解決方案後將其提交到上游。 + +請務必閱讀 +:ref:`Documentation/process/submitting-patches.rst ` ， +以幫助您的代碼被接受。 + + +--------------------------------------------------------------------------- + +用 ``klogd`` 進行Oops跟蹤的注意事項 +------------------------------------ + +爲了幫助Linus和其他內核開發人員， ``klogd`` 對保護故障的處理提供了大量支持。 +爲了完整支持地址解析，至少應該使用 ``sysklogd`` 包的1.3-pl3版本。 + +當發生保護故障時， ``klogd`` 守護進程會自動將內核日誌消息中的重要地址轉換爲 +它們的等效符號。然後通過 ``klogd`` 使用的任何報告機制來轉發這個已翻譯的內核 +消息。保護錯誤消息可以直接從消息文件中剪切出來並轉發給內核開發人員。 + +``klogd`` 執行兩種類型的地址解析，靜態翻譯和動態翻譯。靜態翻譯使用System.map +文件。爲了進行靜態轉換， ``klogd`` 守護進程必須能夠在守護進程初始化時找到系 +統映射文件。有關 ``klogd`` 如何搜索映射文件的信息，請參見klogd手冊頁。 + +當使用內核可加載模塊時，動態地址轉換非常重要。由於內核模塊的內存是從內核的 +動態內存池中分配的，因此無論是模塊的開頭還是模塊中的函數和符號都沒有固定的 +位置。 + +內核支持系統調用，允許程序確定加載哪些模塊及其在內存中的位置。klogd守護進程 +使用這些系統調用構建了一個符號表，可用於調試可加載內核模塊中發生的保護錯誤。 + +klogd至少會提供產生保護故障的模塊的名稱。如果可加載模塊的開發人員選擇從模塊 +導出符號信息，則可能會有其他可用的符號信息。 + +由於內核模塊環境可以是動態的，因此當模塊環境發生變化時，必須有一種通知 +``klogd`` 守護進程的機制。有一些可用的命令行選項允許klogd向當前正在執行的守 +護進程發出信號示意應該刷新符號信息。有關更多信息，請參閱 ``klogd`` 手冊頁。 + +sysklogd發行版附帶了一個補丁，它修改了 ``modules-2.0.0`` 包，以便在加載或 +卸載模塊時自動向klogd發送信號。應用此補丁基本上可無縫支持調試內核可加載模塊 +發生的保護故障。 + +以下是 ``klogd`` 處理的可加載模塊中的保護故障示例:: + + Aug 29 09:51:01 blizard kernel: Unable to handle kernel paging request at virtual address f15e97cc + Aug 29 09:51:01 blizard kernel: current->tss.cr3 = 0062d000, %cr3 = 0062d000 + Aug 29 09:51:01 blizard kernel: *pde = 00000000 + Aug 29 09:51:01 blizard kernel: Oops: 0002 + Aug 29 09:51:01 blizard kernel: CPU: 0 + Aug 29 09:51:01 blizard kernel: EIP: 0010:[oops:_oops+16/3868] + Aug 29 09:51:01 blizard kernel: EFLAGS: 00010212 + Aug 29 09:51:01 blizard kernel: eax: 315e97cc ebx: 003a6f80 ecx: 001be77b edx: 00237c0c + Aug 29 09:51:01 blizard kernel: esi: 00000000 edi: bffffdb3 ebp: 00589f90 esp: 00589f8c + Aug 29 09:51:01 blizard kernel: ds: 0018 es: 0018 fs: 002b gs: 002b ss: 0018 + Aug 29 09:51:01 blizard kernel: Process oops_test (pid: 3374, process nr: 21, stackpage=00589000) + Aug 29 09:51:01 blizard kernel: Stack: 315e97cc 00589f98 0100b0b4 bffffed4 0012e38e 00240c64 003a6f80 00000001 + Aug 29 09:51:01 blizard kernel: 00000000 00237810 bfffff00 0010a7fa 00000003 00000001 00000000 bfffff00 + Aug 29 09:51:01 blizard kernel: bffffdb3 bffffed4 ffffffda 0000002b 0007002b 0000002b 0000002b 00000036 + Aug 29 09:51:01 blizard kernel: Call Trace: [oops:_oops_ioctl+48/80] [_sys_ioctl+254/272] [_system_call+82/128] + Aug 29 09:51:01 blizard kernel: Code: c7 00 05 00 00 00 eb 08 90 90 90 90 90 90 90 90 89 ec 5d c3 + +--------------------------------------------------------------------------- + +:: + + Dr. G.W. Wettstein Oncology Research Div. Computing Facility + Roger Maris Cancer Center INTERNET: greg@wind.rmcc.com + 820 4th St. N. + Fargo, ND 58122 + Phone: 701-234-7556 + diff --git a/Documentation/translations/zh_TW/admin-guide/clearing-warn-once.rst b/Documentation/translations/zh_TW/admin-guide/clearing-warn-once.rst new file mode 100644 index 000000000000..bdc1a22046cf --- /dev/null +++ b/Documentation/translations/zh_TW/admin-guide/clearing-warn-once.rst @@ -0,0 +1,16 @@ +.. SPDX-License-Identifier: GPL-2.0 + +.. include:: ../disclaimer-zh_TW.rst + +:Translator: 胡皓文 Hu Haowen + +清除 WARN_ONCE +-------------- + +WARN_ONCE / WARN_ON_ONCE / printk_once 僅僅列印一次消息. + +echo 1 > /sys/kernel/debug/clear_warn_once + +可以清除這種狀態並且再次允許列印一次告警信息，這對於運行測試集後重現問題 +很有用。 + diff --git a/Documentation/translations/zh_TW/admin-guide/cpu-load.rst b/Documentation/translations/zh_TW/admin-guide/cpu-load.rst new file mode 100644 index 000000000000..be087cef1967 --- /dev/null +++ b/Documentation/translations/zh_TW/admin-guide/cpu-load.rst @@ -0,0 +1,112 @@ +.. SPDX-License-Identifier: GPL-2.0 + +.. include:: ../disclaimer-zh_TW.rst + +:Translator: 胡皓文 Hu Haowen + +======== +CPU 負載 +======== + +Linux通過``/proc/stat``和``/proc/uptime``導出各種信息，用戶空間工具 +如top(1)使用這些信息計算系統花費在某個特定狀態的平均時間。 +例如： + + $ iostat + Linux 2.6.18.3-exp (linmac) 02/20/2007 + + avg-cpu: %user %nice %system %iowait %steal %idle + 10.01 0.00 2.92 5.44 0.00 81.63 + + ... + +這裡系統認爲在默認採樣周期內有10.01%的時間工作在用戶空間，2.92%的時 +間用在系統空間，總體上有81.63%的時間是空閒的。 + +大多數情況下``/proc/stat``的信息幾乎真實反映了系統信息，然而，由於內 +核採集這些數據的方式/時間的特點，有時這些信息根本不可靠。 + +那麼這些信息是如何被搜集的呢？每當時間中斷觸發時，內核查看此刻運行的 +進程類型，並增加與此類型/狀態進程對應的計數器的值。這種方法的問題是 +在兩次時間中斷之間系統（進程）能夠在多種狀態之間切換多次，而計數器只 +增加最後一種狀態下的計數。 + +舉例 +--- + +假設系統有一個進程以如下方式周期性地占用cpu:: + + 兩個時鐘中斷之間的時間線 + |-----------------------| + ^ ^ + |_ 開始運行 | + |_ 開始睡眠 + （很快會被喚醒） + +在上面的情況下，根據``/proc/stat``的信息（由於當系統處於空閒狀態時， +時間中斷經常會發生）系統的負載將會是0 + +大家能夠想像內核的這種行爲會發生在許多情況下，這將導致``/proc/stat`` +中存在相當古怪的信息:: + + /* gcc -o hog smallhog.c */ + #include + #include + #include + #include + #define HIST 10 + + static volatile sig_atomic_t stop; + + static void sighandler (int signr) + { + (void) signr; + stop = 1; + } + static unsigned long hog (unsigned long niters) + { + stop = 0; + while (!stop && --niters); + return niters; + } + int main (void) + { + int i; + struct itimerval it = { .it_interval = { .tv_sec = 0, .tv_usec = 1 }, + .it_value = { .tv_sec = 0, .tv_usec = 1 } }; + sigset_t set; + unsigned long v[HIST]; + double tmp = 0.0; + unsigned long n; + signal (SIGALRM, &sighandler); + setitimer (ITIMER_REAL, &it, NULL); + + hog (ULONG_MAX); + for (i = 0; i < HIST; ++i) v[i] = ULONG_MAX - hog (ULONG_MAX); + for (i = 0; i < HIST; ++i) tmp += v[i]; + tmp /= HIST; + n = tmp - (tmp / 3.0); + + sigemptyset (&set); + sigaddset (&set, SIGALRM); + + for (;;) { + hog (n); + sigwait (&set, &i); + } + return 0; + } + + +參考 +--- + +- https://lore.kernel.org/r/loom.20070212T063225-663@post.gmane.org +- Documentation/filesystems/proc.rst (1.8) + + +謝謝 +--- + +Con Kolivas, Pavel Machek + diff --git a/Documentation/translations/zh_TW/admin-guide/index.rst b/Documentation/translations/zh_TW/admin-guide/index.rst new file mode 100644 index 000000000000..293c20245783 --- /dev/null +++ b/Documentation/translations/zh_TW/admin-guide/index.rst @@ -0,0 +1,135 @@ +.. SPDX-License-Identifier: GPL-2.0 + +.. include:: ../disclaimer-zh_TW.rst + +:Original: :doc:`../../../admin-guide/index` +:Translator: 胡皓文 Hu Haowen + +Linux 內核用戶和管理員指南 +========================== + +下面是一組隨時間添加到內核中的面向用戶的文檔的集合。到目前爲止，還沒有一個 +整體的順序或組織 - 這些材料不是一個單一的，連貫的文件！幸運的話，情況會隨著 +時間的推移而迅速改善。 + +這個初始部分包含總體信息，包括描述內核的README， 關於內核參數的文檔等。 + +.. toctree:: + :maxdepth: 1 + + README + +Todolist: + + kernel-parameters + devices + sysctl/index + +本節介紹CPU漏洞及其緩解措施。 + +Todolist: + + hw-vuln/index + +下面的一組文檔，針對的是試圖跟蹤問題和bug的用戶。 + +.. toctree:: + :maxdepth: 1 + + reporting-issues + security-bugs + bug-hunting + bug-bisect + tainted-kernels + init + +Todolist: + + reporting-bugs + ramoops + dynamic-debug-howto + kdump/index + perf/index + +這是應用程式開發人員感興趣的章節的開始。可以在這裡找到涵蓋內核ABI各個 +方面的文檔。 + +Todolist: + + sysfs-rules + +本手冊的其餘部分包括各種指南，介紹如何根據您的喜好配置內核的特定行爲。 + + +.. toctree:: + :maxdepth: 1 + + clearing-warn-once + cpu-load + unicode + +Todolist: + + acpi/index + aoe/index + auxdisplay/index + bcache + binderfs + binfmt-misc + blockdev/index + bootconfig + braille-console + btmrvl + cgroup-v1/index + cgroup-v2 + cifs/index + cputopology + dell_rbu + device-mapper/index + edid + efi-stub + ext4 + nfs/index + gpio/index + highuid + hw_random + initrd + iostats + java + jfs + kernel-per-CPU-kthreads + laptops/index + lcd-panel-cgram + ldm + lockup-watchdogs + LSM/index + md + media/index + mm/index + module-signing + mono + namespaces/index + numastat + parport + perf-security + pm/index + pnp + rapidio + ras + rtc + serial-console + svga + sysrq + thunderbolt + ufs + vga-softcursor + video-output + xfs + +.. only:: subproject and html + + Indices + ======= + + * :ref:`genindex` + diff --git a/Documentation/translations/zh_TW/admin-guide/init.rst b/Documentation/translations/zh_TW/admin-guide/init.rst new file mode 100644 index 000000000000..32cdf134948f --- /dev/null +++ b/Documentation/translations/zh_TW/admin-guide/init.rst @@ -0,0 +1,58 @@ +.. SPDX-License-Identifier: GPL-2.0 + +.. include:: ../disclaimer-zh_TW.rst + +:Original: :doc:`../../../admin-guide/init` + +:譯者: + + 吳想成 Wu XiangCheng + 胡皓文 Hu Haowen + +解釋「No working init found.」啓動掛起消息 +========================================== + +:作者: + + Andreas Mohr + + Cristian Souza + +本文檔提供了加載初始化二進位（init binary）失敗的一些高層級原因（大致按執行 +順序列出）。 + +1) **無法掛載根文件系統Unable to mount root FS** ：請設置「debug」內核參數（在 + 引導加載程序bootloader配置文件或CONFIG_CMDLINE）以獲取更詳細的內核消息。 + +2) **初始化二進位不存在於根文件系統上init binary doesn't exist on rootfs** ： + 確保您的根文件系統類型正確（並且 ``root=`` 內核參數指向正確的分區）；擁有 + 所需的驅動程序，例如SCSI或USB等存儲硬體；文件系統（ext3、jffs2等）是內建的 + （或者作爲模塊由initrd預加載）。 + +3) **控制台設備損壞Broken console device** ： ``console= setup`` 中可能存在 + 衝突 --> 初始控制台不可用（initial console unavailable）。例如，由於串行 + IRQ問題（如缺少基於中斷的配置）導致的某些串行控制台不可靠。嘗試使用不同的 + ``console= device`` 或像 ``netconsole=`` 。 + +4) **二進位存在但依賴項不可用Binary exists but dependencies not available** ： + 例如初始化二進位的必需庫依賴項，像 ``/lib/ld-linux.so.2`` 丟失或損壞。使用 + ``readelf -d |grep NEEDED`` 找出需要哪些庫。 + +5) **無法加載二進位Binary cannot be loaded** ：請確保二進位的體系結構與您的 + 硬體匹配。例如i386不匹配x86_64，或者嘗試在ARM硬體上加載x86。如果您嘗試在 + 此處加載非二進位文件（shell腳本？），您應該確保腳本在其工作頭（shebang + header）行 ``#!/...`` 中指定能正常工作的解釋器（包括其庫依賴項）。在處理 + 腳本之前，最好先測試一個簡單的非腳本二進位文件，比如 ``/bin/sh`` ，並確認 + 它能成功執行。要了解更多信息，請將代碼添加到 ``init/main.c`` 以顯示 + kernel_execve()的返回值。 + +當您發現新的失敗原因時，請擴展本解釋（畢竟加載初始化二進位是一個 **關鍵** 且 +艱難的過渡步驟，需要儘可能無痛地進行），然後向LKML提交一個補丁。 + +待辦事項： + +- 通過一個可以存儲 ``kernel_execve()`` 結果值的結構體數組實現各種 + ``run_init_process()`` 調用，並在失敗時通過疊代 **所有** 結果來記錄一切 + （非常重要的可用性修復）。 +- 試著使實現本身在一般情況下更有幫助，例如在受影響的地方提供額外的錯誤消息。 + diff --git a/Documentation/translations/zh_TW/admin-guide/reporting-issues.rst b/Documentation/translations/zh_TW/admin-guide/reporting-issues.rst new file mode 100644 index 000000000000..27638e199f13 --- /dev/null +++ b/Documentation/translations/zh_TW/admin-guide/reporting-issues.rst @@ -0,0 +1,1337 @@ +.. SPDX-License-Identifier: (GPL-2.0+ OR CC-BY-4.0) +.. + If you want to distribute this text under CC-BY-4.0 only, please use 'The + Linux kernel developers' for author attribution and link this as source: + https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/plain/Documentation/admin-guide/reporting-issues.rst +.. + Note: Only the content of this RST file as found in the Linux kernel sources + is available under CC-BY-4.0, as versions of this text that were processed + (for example by the kernel's build system) might contain content taken from + files which use a more restrictive license. + +.. include:: ../disclaimer-zh_TW.rst + +:Original: Documentation/admin-guide/reporting-issues.rst + +:譯者: + + 吳想成 Wu XiangCheng + 胡皓文 Hu Haowen + + +報告問題 ++++++++++ + + +簡明指南（亦即 太長不看） +========================== + +您面臨的是否爲同系列穩定版或長期支持內核的普通內核的回歸？是否仍然受支持？ +請搜索 `LKML內核郵件列表 `_ 和 +`Linux穩定版郵件列表 `_ 存檔中匹配的報告並 +加入討論。如果找不到匹配的報告，請安裝該系列的最新版本。如果它仍然出現問題， +報告給穩定版郵件列表（stable@vger.kernel.org）。 + +在所有其他情況下，請儘可能猜測是哪個內核部分導致了問題。查看MAINTAINERS文件， +了解開發人員希望如何得知問題，大多數情況下，報告問題都是通過電子郵件和抄送 +相關郵件列表進行的。檢查報告目的地的存檔中是否已有匹配的報告；也請搜索 +`LKML `_ 和網絡。如果找不到可加入的討論，請 +安裝 `最新的主線內核 `_ 。如果仍存在問題，請發送報告。 + +問題已經解決了，但是您希望看到它在一個仍然支持的穩定版或長期支持系列中得到 +解決？請安裝其最新版本。如果它出現了問題，那麼在主線中搜索修復它的更改，並 +檢查是否正在回傳（backporting）或者已放棄；如果兩者都沒有，那麼可詢問處理 +更改的人員。 + +**通用提醒** ：當安裝和測試上述內核時，請確保它是普通的（即：沒有補丁，也沒 +有使用附加模塊）。還要確保它是在一個正常的環境中構建和運行，並且在問題發生 +之前沒有被汙染（tainted）。 + +在編寫報告時，要涵蓋與問題相關的所有信息，如使用的內核和發行版。在碰見回歸時， +嘗試給出引入它的更改的提交ID，二分可以找到它。如果您同時面臨Linux內核的多個 +問題，請分別報告每個問題。 + +一旦報告發出，請回答任何出現的問題，並儘可能地提供幫助。這包括通過不時重新 +測試新版本並發送狀態更新來推動進展。 + + +如何向內核維護人員報告問題的逐步指南 +===================================== + +上面的簡明指南概述了如何向Linux內核開發人員報告問題。對於已經熟悉向自由和開 +源軟體（FLOSS）項目報告問題的人來說，這可能是他們所需要的全部內容。對於其他 +人，本部分更爲詳細，並一步一步地描述。爲了便於閱讀，它仍然儘量簡潔，並省略 +了許多細節；這些在逐步指南後的參考章節中進行了描述，該章節更詳細地解釋了每 +個步驟。 + +注意：本節涉及的方面比簡明指南多，順序也稍有不同。這符合你的利益，以確保您 +儘早意識到看起來像Linux內核毛病的問題可能實際上是由其他原因引起的。這些步驟 +可以確保你最終不會覺得在這一過程中投入的時間是浪費： + + * 您是否面臨硬體或軟體供應商提供的Linux內核的問題？那麼基本上您最好停止閱讀 + 本文檔，轉而向您的供應商報告問題，除非您願意自己安裝最新的Linux版本。尋找 + 和解決問題往往需要後者。 + + * 使用您喜愛的網絡搜尋引擎對現有報告進行粗略搜索；此外，請檢查 + `Linux內核郵件列表（LKML） `_ 的存檔。如果 + 找到匹配的報告，請加入討論而不是發送新報告。 + + * 看看你正在處理的問題是否爲回歸問題、安全問題或非常嚴重的問題：這些都是需 + 要在接下來的一些步驟中特別處理的「高優先級問題」。 + + * 確保不是內核環境導致了您面臨的問題。 + + * 創建一個新的備份，並將系統修復和恢復工具放在手邊。 + + * 確保您的系統不會通過動態構建額外的內核模塊來增強其內核，像DKMS這樣的解決 + 方案可能在您不知情的情況下就在本地進行了這樣的工作。 + + * 當問題發生時，檢查您的內核是否被「汙染」，因爲使內核設置這個標誌的事件可能 + 會導致您面臨的問題。 + + * 粗略地寫下如何重現這個問題。如果您同時處理多個問題，請爲每個問題單獨寫注 + 釋，並確保它們在新啓動的系統上獨立出現。這是必要的，因爲每個問題都需要分 + 別報告給內核開發人員，除非它們嚴重糾纏在一起。 + + * 如果您正面臨穩定版或長期支持版本線的回歸（例如從5.10.4更新到5.10.5時出現 + 故障），請查看後文「報告穩定版和長期支持內核線的回歸」小節。 + + * 定位可能引起問題的驅動程序或內核子系統。找出其開發人員期望的報告的方式和 + 位置。注意：大多數情況下不會是 bugzilla.kernel.org，因爲問題通常需要通 + 過郵件發送給維護人員和公共郵件列表。 + + * 在缺陷追蹤器或問題相關郵件列表的存檔中徹底搜索可能與您的問題匹配的報告。 + 如果你發現了一些相關討論，請加入討論而不是發送新的報告。 + +在完成這些準備之後，你將進入主要部分： + + * 除非您已經在運行最新的「主線」Linux內核，否則最好在報告流程前安裝它。在某些 + 情況下，使用最新的「穩定版」Linux進行測試和報告也是可以接受的替代方案；在 + 合併窗口期間，這實際上可能是最好的方法，但在開發階段最好還是暫停幾天。無論 + 你選擇什麼版本，最好使用「普通」構建。忽略這些建議會大大增加您的報告被拒絕 + 或忽略的風險。 + + * 確保您剛剛安裝的內核在運行時不會「汙染」自己。 + + * 在您剛剛安裝的內核中復現這個問題。如果它沒有出現，請查看下方只發生在 + 穩定版和長期支持內核的問題的說明。 + + * 優化你的筆記：試著找到並寫出最直接的復現問題的方法。確保最終結果包含所有 + 重要的細節，同時讓第一次聽說的人容易閱讀和理解。如果您在此過程中學到了一 + 些東西，請考慮再次搜索關於該問題的現有報告。 + + * 如果失敗涉及「panic」、「Oops」、「warning」或「BUG」，請考慮解碼內核日誌以查找觸 + 發錯誤的代碼行。 + + * 如果您的問題是回歸問題，請儘可能縮小引入問題時的範圍。 + + * 通過詳細描述問題來開始編寫報告。記得包括以下條目：您爲復現而安裝的最新內 + 核版本、使用的Linux發行版以及關於如何復現該問題的說明。如果可能，將內核 + 構建配置（.config）和 ``dmesg`` 的輸出放在網上的某個地方，並連結到它。包 + 含或上傳所有其他可能相關的信息，如Oops的輸出/截圖或來自 ``lspci`` 的輸出 + 。一旦你寫完了這個主要部分，請在上方插入一個正常長度的段落快速概述問題和 + 影響。再在此之上添加一個簡單描述問題的句子，以得到人們的閱讀。現在給出一 + 個更短的描述性標題或主題。然後就可以像MAINTAINERS文件告訴你的那樣發送或 + 提交報告了，除非你在處理一個「高優先級問題」：它們需要按照下面「高優先級問 + 題的特殊處理」所述特別關照。 + + * 等待別人的反應，繼續推進事情，直到你能夠接受這樣或那樣的結果。因此，請公 + 開和及時地回應任何詢問。測試提出的修復。積極地測試：至少重新測試每個新主 + 線版本的首個候選版本（RC），並報告你的結果。如果出現拖延，就友好地提醒一 + 下。如果你沒有得到任何幫助或者未能滿意，請試著自己幫助自己。 + + +報告穩定版和長期支持內核線的回歸 +---------------------------------- + +如果您發現了穩定版或長期支持內核版本線中的回歸問題並按上述流程跳到這裡，那麼 +請閱讀本小節。即例如您在從5.10.4更新到5.10.5時出現了問題（從5.9.15到5.10.5則 +不是）。開發人員希望儘快修復此類回歸，因此有一個簡化流程來報告它們： + + * 檢查內核開發人員是否仍然維護你關心的Linux內核版本線：去 `kernel.org 的首頁 + `_ ，確保此特定版本線的最新版沒有「[EOL]」標記。 + + * 檢查 `Linux穩定版郵件列表 `_ 中的現有報告。 + + * 從特定的版本線安裝最新版本作爲純淨內核。確保這個內核沒有被汙染，並且仍然 + 存在問題，因爲問題可能已經在那裡被修復了。如果您第一次發現供應商內核的問題， + 請檢查已知最新版本的普通構建是否可以正常運行。 + + * 向Linux穩定版郵件列表發送一個簡短的問題報告(stable@vger.kernel.org)。大致 + 描述問題，並解釋如何復現。講清楚首個出現問題的版本和最後一個工作正常的版本。 + 然後等待進一步的指示。 + +下面的參考章節部分詳細解釋了這些步驟中的每一步。 + + +報告只發生在較舊內核版本線的問題 +---------------------------------- + +若您嘗試了上述的最新主線內核，但未能在那裡復現問題，那麼本小節適用於您；以下 +流程有助於使問題在仍然支持的穩定版或長期支持版本線，或者定期基於最新穩定版或 +長期支持內核的供應商內核中得到修復。如果是這種情況，請執行以下步驟： + + * 請做好準備，接下來的幾個步驟可能無法在舊版本中解決問題：修復可能太大或太 + 冒險，無法移植到那裡。 + + * 執行前節「報告穩定版和長期支持內核線的回歸」中的前三個步驟。 + + * 在Linux內核版本控制系統中搜索修復主線問題的更改，因爲它的提交消息可能會 + 告訴你修復是否已經計劃好了支持。如果你沒有找到，搜索適當的郵件列表，尋找 + 討論此類問題或同行評議可能修復的帖子；然後檢查討論是否認爲修復不適合支持。 + 如果支持根本不被考慮，加入最新的討論，詢問是否有可能。 + + * 前面的步驟之一應該會給出一個解決方案。如果仍未能成功，請向可能引起問題的 + 子系統的維護人員詢問建議；抄送特定子系統的郵件列表以及穩定版郵件列表 + +下面的參考章節部分詳細解釋了這些步驟中的每一步。 + + +參考章節：向內核維護者報告問題 +=============================== + +上面的詳細指南簡要地列出了所有主要步驟，這對大多數人來說應該足夠了。但有時， +即使是有經驗的用戶也可能想知道如何實際執行這些步驟之一。這就是本節的目的， +因爲它將提供關於上述每個步驟的更多細節。請將此作爲參考文檔：可以從頭到尾 +閱讀它。但它主要是爲了瀏覽和查找如何實際執行這些步驟的詳細信息。 + +在深入挖掘細節之前，我想先給你一些一般性建議： + + * Linux內核開發人員很清楚這個過程很複雜，比其他的FLOSS項目要求更多。我們很 + 希望讓它更簡單。但這需要在不同的地方以及一些基礎設施上付諸努力，這些基礎 + 設施需要持續的維護；尚未有人站出來做這些工作，所以目前情況就是這樣。 + + * 與某些供應商簽訂的保證或支持合同並不能使您有權要求上游Linux內核社區的開 + 發人員進行修復：這樣的合同完全在Linux內核、其開發社區和本文檔的範圍之外。 + 這就是爲什麼在這種情況下，你不能要求任何契約保證，即使開發人員處理的問 + 題對供應商有效。如果您想主張您的權利，使用供應商的支持渠道代替。當這樣做 + 的時候，你可能想提出你希望看到這個問題在上游Linux內核中修復；可以這是確 + 保最終修復將被納入所有Linux發行版的唯一方法來鼓勵他們。 + + * 如果您從未向FLOSS項目報告過任何問題，那麼您應該考慮閱讀 `如何有效地報告 + 缺陷 `_ ， `如何 + 以明智的方式提問 `_ ， + 和 `如何提出好問題 `_ 。 + +解決這些問題之後，可以在下面找到如何正確地向Linux內核報告問題的詳細信息。 + + +確保您使用的是上游Linux內核 +---------------------------- + + *您是否面臨硬體或軟體供應商提供的Linux內核的問題？那麼基本上您最好停止閱 + 讀本文檔，轉而向您的供應商報告問題，除非您願意自己安裝最新的Linux版本。 + 尋找和解決問題往往需要後者。* + +與大多數程式設計師一樣，Linux內核開發人員不喜歡花時間處理他們維護的原始碼中根本 +不會發生的問題的報告。這只會浪費每個人的時間，尤其是你的時間。不幸的是，當 +涉及到內核時，這樣的情況很容易發生，並且常常導致雙方氣餒。這是因爲幾乎所有預 +裝在設備（台式機、筆記本電腦、智慧型手機、路由器等）上的Linux內核，以及大多數 +由Linux發行商提供的內核，都與由kernel.org發行的官方Linux內核相距甚遠：從Linux +開發的角度來看，這些供應商提供的內核通常是古老的或者經過了大量修改，通常兩點 +兼具。 + +大多數供應商內核都不適合用來向Linux內核開發人員報告問題：您在其中遇到的問題 +可能已經由Linux內核開發人員在數月或數年前修復；此外，供應商的修改和增強可能 +會導致您面臨的問題，即使它們看起來很小或者完全不相關。這就是爲什麼您應該向 +供應商報告這些內核的問題。它的開發者應該查看報告，如果它是一個上游問題，直接 +於上游修復或將報告轉發到那裡。在實踐中，這有時行不通。因此，您可能需要考慮 +通過自己安裝最新的Linux內核內核來繞過供應商。如果如果您選擇此方法，那麼本指 +南後面的步驟將解釋如何在排除了其他可能導致您的問題的原因後執行此操作。 + +注意前段使用的詞語是「大多數」，因爲有時候開發人員實際上願意處理供應商內核出現 +的問題報告。他們是否這麼做很大程度上取決於開發人員和相關問題。如果發行版只 +根據最近的Linux版本對內核進行了較小修改，那麼機會就比較大；例如對於Debian +GNU/Linux Sid或Fedora Rawhide所提供的主線內核。一些開發人員還將接受基於最新 +穩定內核的發行版內核問題報告，只要它改動不大；例如Arch Linux、常規Fedora版本 +和openSUSE Turboweed。但是請記住，您最好使用主線Linux，並避免在此流程中使用 +穩定版內核，如「安裝一個新的內核進行測試」一節中所詳述。 + +當然，您可以忽略所有這些建議，並向上游Linux開發人員報告舊的或經過大量修改的 +供應商內核的問題。但是注意，這樣的報告經常被拒絕或忽視，所以自行小心考慮一下。 +不過這還是比根本不報告問題要好：有時候這樣的報告會直接或間接地幫助解決之後的 +問題。 + + +搜索現有報告（第一部分） +------------------------- + + *使用您喜愛的網絡搜尋引擎對現有報告進行粗略搜索；此外，請檢查Linux內核 + 郵件列表（LKML）的存檔。如果找到匹配的報告，請加入討論而不是發送新報告。* + +報告一個別人已經提出的問題，對每個人來說都是浪費時間，尤其是作爲報告人的你。 +所以徹底檢查是否有人已經報告了這個問題，這對你自己是有利的。在流程中的這一步， +可以只執行一個粗略的搜索：一旦您知道您的問題需要報告到哪裡，稍後的步驟將告訴 +您如何詳細搜索。儘管如此，不要倉促完成這一步，它可以節省您的時間和減少麻煩。 + +只需先用你最喜歡的搜尋引擎在網際網路上搜索。然後再搜索Linux內核郵件列表（LKML） +存檔。 + +如果搜索結果實在太多，可以考慮讓你的搜尋引擎將搜索時間範圍限制在過去的一個 +月或一年。而且無論你在哪裡搜索，一定要用恰當的搜索關鍵詞；也要變化幾次關鍵 +詞。同時，試著從別人的角度看問題：這將幫助你想出其他的關鍵詞。另外，一定不 +要同時使用過多的關鍵詞。記住搜索時要同時嘗試包含和不包含內核驅動程序的名稱 +或受影響的硬體組件的名稱等信息。但其確切的品牌名稱（比如說「華碩紅魔 Radeon +RX 5700 XT Gaming OC」）往往幫助不大，因爲它太具體了。相反，嘗試搜索術語，如 +型號（Radeon 5700 或 Radeon 5000）和核心代號（「Navi」或「Navi10」），以及包含 +和不包含其製造商（「AMD」）。 + +如果你發現了關於你的問題的現有報告，請加入討論，因爲你可能會提供有價值的額 +外信息。這一點很重要，即使是在修復程序已經準備好或處於最後階段，因爲開發人 +員可能會尋找能夠提供額外信息或測試建議修復程序的人。跳到「發布報告後的責任」 +一節，了解有關如何正確參與的細節。 + +注意，搜索 `bugzilla.kernel.org `_ 網站可能 +也是一個好主意，因爲這可能會提供有價值的見解或找到匹配的報告。如果您發現後者， +請記住：大多數子系統都希望在不同的位置報告，如下面「你需要將問題報告到何處」 +一節中所述。因此本應處理這個問題的開發人員甚至可能不知道bugzilla的工單。所以 +請檢查工單中的問題是否已經按照本文檔所述得到報告，如果沒有，請考慮這樣做。 + +高優先級的問題？ +----------------- + + *看看你正在處理的問題是否是回歸問題、安全問題或非常嚴重的問題：這些都是 + 需要在接下來的一些步驟中特別處理的「高優先級問題」。* + +Linus Torvalds和主要的Linux內核開發人員希望看到一些問題儘快得到解決，因此在 +報告過程中有一些「高優先級問題」的處理略有不同。有三種情況符合條件:回歸、安全 +問題和非常嚴重的問題。 + +如果在舊版本的Linux內核中工作的東西不能在新版本的Linux內核中工作，或者某種 +程度上在新版本的Linux內核中工作得更差，那麼你就需要處理「回歸」。因此，當一個 +在Linux 5.7中表現良好的WiFi驅動程序在5.8中表現不佳或根本不能工作時，這是一 +種回歸。如果應用程式在新的內核中出現不穩定的現象，這也是一種回歸，這可能是 +由於內核和用戶空間之間的接口（如procfs和sysfs）發生不兼容的更改造成的。顯著 +的性能降低或功耗增加也可以稱爲回歸。但是請記住:新內核需要使用與舊內核相似的 +配置來構建（參見下面如何實現這一點）。這是因爲內核開發人員在實現新特性時有 +時無法避免不兼容性；但是爲了避免回歸，這些特性必須在構建配置期間顯式地啓用。 + +什麼是安全問題留給您自己判斷。在繼續之前，請考慮閱讀 +「Documentation/translations/zh_TW/admin-guide/security-bugs.rst」， +因爲它提供了如何最恰當地處理安全問題的額外細節。 + +當發生了完全無法接受的糟糕事情時，此問題就是一個「非常嚴重的問題」。例如， +Linux內核破壞了它處理的數據或損壞了它運行的硬體。當內核突然顯示錯誤消息 +（「kernel panic」）並停止工作，或者根本沒有任何停止信息時，您也在處理一個嚴重 +的問題。注意：不要混淆「panic」（內核停止自身的致命錯誤）和「Oops」（可恢復錯誤）， +因爲顯示後者之後內核仍然在運行。 + + +確保環境健康 +-------------- + + *確保不是內核所處環境導致了你所面臨的問題。* + +看起來很像內核問題的問題有時是由構建或運行時環境引起的。很難完全排除這種問 +題，但你應該儘量減少這種問題： + + * 構建內核時，請使用經過驗證的工具，因爲編譯器或二進位文件中的錯誤可能會導 + 致內核出現錯誤行爲。 + + * 確保您的計算機組件在其設計規範內運行；這對處理器、內存和主板尤爲重要。因 + 此，當面臨潛在的內核問題時，停止低電壓或超頻。 + + * 儘量確保不是硬體故障導致了你的問題。例如，內存損壞會導致大量的問題，這些 + 問題會表現爲看起來像內核問題。 + + * 如果你正在處理一個文件系統問題，你可能需要用 ``fsck`` 檢查一下文件系統， + 因爲它可能會以某種方式被損壞，從而導致無法預期的內核行爲。 + + * 在處理回歸問題時，要確保沒有在更新內核的同時發生了其他變化。例如，這個問 + 題可能是由同時更新的其他軟體引起的。也有可能是在你第一次重啓進入新內核時， + 某個硬體巧合地壞了。更新系統 BIOS 或改變 BIOS 設置中的某些內容也會導致 + 一些看起來很像內核回歸的問題。 + + +爲緊急情況做好準備 +------------------- + + *創建一個全新的備份，並將系統修復和還原工具放在手邊* + +我得提醒您，您正在和計算機打交道，計算機有時會出現意想不到的事情，尤其是當 +您折騰其作業系統的內核等關鍵部件時。而這就是你在這個過程中要做的事情。因此， +一定要創建一個全新的備份；還要確保你手頭有修復或重裝作業系統的所有工具， +以及恢復備份所需的一切。 + + +確保你的內核不會被增強 +------------------------ + + *確保您的系統不會通過動態構建額外的內核模塊來增強其內核，像DKMS這樣的解 + 決方案可能在您不知情的情況下就在本地進行了這樣的工作。* + +如果內核以任何方式得到增強，那麼問題報告被忽略或拒絕的風險就會急劇增加。這就 +是爲什麼您應該刪除或禁用像akmods和DKMS這樣的機制：這些機制會自動構建額外內核 +模塊，例如當您安裝新的Linux內核或第一次引導它時。也要記得同時刪除他們可能安裝 +的任何模塊。然後重新啓動再繼續。 + +注意，你可能不知道你的系統正在使用這些解決方案之一：當你安裝 Nvidia 專有圖 +形驅動程序、VirtualBox 或其他需要 Linux 內核以外的模塊支持的軟體時，它們通 +常會靜默設置。這就是爲什麼你可能需要卸載這些軟體的軟體包，以擺脫任何第三方 +內核模塊。 + + +檢測「汙染」標誌 +---------------- + + *當問題發生時，檢查您的內核是否被「汙染」，因爲使內核設置這個標誌的事件可 + 能會導致您面臨的問題。* + +當某些可能會導致看起來完全不相關的後續錯誤的事情發生時，內核會用「汙染 +（taint）」標誌標記自己。如果您的內核受到汙染，那麼您面臨的可能是這樣的錯誤。 +因此在投入更多時間到這個過程中之前，儘早排除此情況可能對你有好處。這是這個 +步驟出現在這裡的唯一原因，因爲這個過程稍後會告訴您安裝最新的主線內核；然後 +您將需要再次檢查汙染標誌，因爲當它出問題的時候內核報告會關注它。 + +在正在運行的系統上檢查內核是否汙染非常容易：如果 ``cat /proc/sys/kernel/tainted`` +返回「0」，那麼內核沒有被汙染，一切正常。在某些情況下無法檢查該文件；這就是 +爲什麼當內核報告內部問題（「kernel bug」）、可恢復錯誤（「kernel Oops」）或停止 +操作前不可恢復的錯誤（「kernel panic」）時，它也會提到汙染狀態。當其中一個錯 +誤發生時，查看列印的錯誤消息的頂部，搜索以「CPU:」開頭的行。如果發現問題時內 +核未被汙染，那麼它應該以「Not infected」結束；如果你看到「Tainted:」且後跟一些 +空格和字母，那就被汙染了。 + +如果你的內核被汙染了，請閱讀「Documentation/translations/zh_TW/admin-guide/tainted-kernels.rst」 +以找出原因。設法消除汙染因素。通常是由以下三種因素之一引起的： + + 1. 發生了一個可恢復的錯誤（「kernel Oops」），內核汙染了自己，因爲內核知道在 + 此之後它可能會出現奇怪的行爲錯亂。在這種情況下，檢查您的內核或系統日誌， + 並尋找以下列文字開頭的部分:: + + Oops: 0000 [#1] SMP + + 如方括號中的「#1」所示，這是自啓動以來的第一次Oops。每個Oops和此後發生的 + 任何其他問題都可能是首個Oops的後續問題，即使這兩個問題看起來完全不相關。 + 通過消除首個Oops的原因並在之後復現該問題，可以排除這種情況。有時僅僅 + 重新啓動就足夠了，有時更改配置後重新啓動可以消除Oops。但是在這個流程中 + 不要花費太多時間在這一點上，因爲引起Oops的原因可能已經在您稍後將按流程 + 安裝的新Linux內核版本中修復了。 + + 2. 您的系統使用的軟體安裝了自己的內核模塊，例如Nvidia的專有圖形驅動程序或 + VirtualBox。當內核從外部源（即使它們是開源的）加載此類模塊時，它會汙染 + 自己：它們有時會在不相關的內核區域導致錯誤，從而可能導致您面臨的問題。 + 因此，當您想要向Linux內核開發人員報告問題時，您必須阻止這些模塊加載。 + 大多數情況下最簡單的方法是：臨時卸載這些軟體，包括它們可能已經安裝的任 + 何模塊。之後重新啓動。 + + 3. 當內核加載駐留在Linux內核原始碼staging樹中的模塊時，它也會汙染自身。這 + 是一個特殊的區域，代碼（主要是驅動程序）還沒有達到正常Linux內核的質量 + 標準。當您報告此種模塊的問題時，內核受到汙染顯然是沒有問題的；只需確保 + 問題模塊是造成汙染的唯一原因。如果問題發生在一個不相關的區域，重新啓動 + 並通過指定 ``foo.blacklist=1`` 作爲內核參數臨時阻止該模塊被加載（用有 + 問題的模塊名替換「foo」）。 + + +記錄如何重現問題 +------------------ + + *粗略地寫下如何重現這個問題。如果您同時處理多個問題，請爲每個問題單獨寫 + 注釋，並確保它們在新啓動的系統上獨立出現。這是必要的，因爲每個問題都需 + 要分別報告給內核開發人員，除非它們嚴重糾纏在一起。* + +如果你同時處理多個問題，必須分別報告每個問題，因爲它們可能由不同的開發人員 +處理。在一份報告中描述多種問題，也會讓其他人難以將其分開。因此只有在問題嚴 +重糾纏的情況下，才能將問題合併在一份報告中。 + +此外，在報告過程中，你必須測試該問題是否發生在其他內核版本上。因此，如果您 +知道如何在一個新啓動的系統上快速重現問題，將使您的工作更加輕鬆。 + +注意：報告只發生過一次的問題往往是沒有結果的，因爲它們可能是由於宇宙輻射導 +致的位翻轉。所以你應該嘗試通過重現問題來排除這種情況，然後再繼續。如果你有 +足夠的經驗來區分由於硬體故障引起的一次性錯誤和難以重現的罕見內核問題，可以 +忽略這個建議。 + + +穩定版或長期支持內核的回歸？ +----------------------------- + + *如果您正面臨穩定版或長期支持版本線的回歸（例如從5.10.4更新到5.10.5時出現 + 故障），請查看後文「報告穩定版和長期支持內核線的回歸」小節。* + +穩定版和長期支持內核版本線中的回歸是Linux開發人員非常希望解決的問題，這樣的 +問題甚至比主線開發分支中的回歸更不應出現，因爲它們會很快影響到很多人。開發人員 +希望儘快了解此類問題，因此有一個簡化流程來報告這些問題。注意，使用更新內核版 +本線的回歸（比如從5.9.15切換到5.10.5時出現故障）不符合條件。 + + +你需要將問題報告到何處 +------------------------ + + *定位可能引起問題的驅動程序或內核子系統。找出其開發人員期望的報告的方式 + 和位置。注意：大多數情況下不會是bugzilla.kernel.org，因爲問題通常需要通 + 過郵件發送給維護人員和公共郵件列表。* + +將報告發送給合適的人是至關重要的，因爲Linux內核是一個大項目，大多數開發人員 +只熟悉其中的一小部分。例如，相當多的程式設計師只關心一個驅動程序，比如一個WiFi +晶片驅動程序；它的開發人員可能對疏遠的或不相關的「子系統」（如TCP堆棧、 +PCIe/PCI子系統、內存管理或文件系統）的內部知識了解很少或完全不了解。 + +問題在於：Linux內核缺少一個，可以簡單地將問題歸檔並讓需要了解它的開發人員了 +解它的，中心化缺陷跟蹤器。這就是爲什麼你必須找到正確的途徑來自己報告問題。 +您可以在腳本的幫助下做到這一點（見下文），但它主要針對的是內核開發人員和專 +家。對於其他人來說，MAINTAINERS（維護人員）文件是更好的選擇。 + +如何閱讀MAINTAINERS維護者文件 +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +爲了說明如何使用 :ref:`MAINTAINERS ` 文件，讓我們假設您的筆記 +本電腦中的WiFi在更新內核後突然出現了錯誤行爲。這種情況下可能是WiFi驅動的問 +題。顯然，它也可能由於驅動基於的某些代碼，但除非你懷疑有這樣的東西會附著在 +驅動程序上。如果真的是其他的問題，驅動程序的開發人員會讓合適的人參與進來。 + +遺憾的是，沒有通用且簡單的辦法來檢查哪個代碼驅動了特定硬體組件。 + +在WiFi驅動出現問題的情況下，你可能想查看 ``lspci -k`` 的輸出，因爲它列出了 +PCI/PCIe總線上的設備和驅動它的內核模塊:: + + [user@something ~]$ lspci -k + [...] + 3a:00.0 Network controller: Qualcomm Atheros QCA6174 802.11ac Wireless Network Adapter (rev 32) + Subsystem: Bigfoot Networks, Inc. Device 1535 + Kernel driver in use: ath10k_pci + Kernel modules: ath10k_pci + [...] + +但如果你的WiFi晶片通過USB或其他內部總線連接，這種方法就行不通了。在這種情況 +下，您可能需要檢查您的WiFi管理器或 ``ip link`` 的輸出。尋找有問題的網絡接口 +的名稱，它可能類似於「wlp58s0」。此名稱可以用來找到驅動它的模塊:: + + [user@something ~]$ realpath --relative-to=/sys/module//sys/class/net/wlp58s0/device/driver/module + ath10k_pci + +如果這些技巧不能進一步幫助您，請嘗試在網上搜索如何縮小相關驅動程序或子系統 +的範圍。如果你不確定是哪一個：試著猜一下，即使你猜得不好，也會有人會幫助你 +的。 + +一旦您知道了相應的驅動程序或子系統，您就希望在MAINTAINERS文件中搜索它。如果 +是「ath10k_pci」，您不會找到任何東西，因爲名稱太具體了。有時你需要在網上尋找 +幫助；但在此之前，請嘗試使用一個稍短或修改過的名稱來搜索MAINTAINERS文件，因 +爲這樣你可能會發現類似這樣的東西:: + + QUALCOMM ATHEROS ATH10K WIRELESS DRIVER + Mail: A. Some Human + Mailing list: ath10k@lists.infradead.org + Status: Supported + Web-page: https://wireless.wiki.kernel.org/en/users/Drivers/ath10k + SCM: git git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git + Files: drivers/net/wireless/ath/ath10k/ + +注意：如果您閱讀在Linux原始碼樹的根目錄中找到的原始維護者文件，則行描述將是 +縮寫。例如，「Mail:（郵件）」將是「M:」，「Mailing list:（郵件列表）」將是「L」， +「Status:（狀態）」將是「S:」。此文件頂部有一段解釋了這些和其他縮寫。 + +首先查看「Status」狀態行。理想情況下，它應該得到「Supported（支持）」或 +「Maintained（維護）」。如果狀態爲「Obsolete（過時的）」，那麼你在使用一些過時的 +方法，需要轉換到新的解決方案上。有時候，只有在感到有動力時，才會有人爲代碼 +提供「Odd Fixes」。如果碰見「Orphan」，你就完全不走運了，因爲再也沒有人關心代碼 +了，只剩下這些選項:準備好與問題共存，自己修復它，或者找一個願意修復它的程式設計師。 + +檢查狀態後，尋找以「bug:」開頭的一行：它將告訴你在哪裡可以找到子系統特定的缺 +陷跟蹤器來提交你的問題。上面的例子沒有此行。大多數部分都是這樣，因爲 Linux +內核的開發完全是由郵件驅動的。很少有子系統使用缺陷跟蹤器，且其中只有一部分 +依賴於 bugzilla.kernel.org。 + +在這種以及其他很多情況下，你必須尋找以「Mail:」開頭的行。這些行提到了特定代碼 +的維護者的名字和電子郵件地址。也可以查找以「Mailing list:」開頭的行，它告訴你 +開發代碼的公共郵件列表。你的報告之後需要通過郵件發到這些地址。另外，對於所有 +通過電子郵件發送的問題報告，一定要抄送 Linux Kernel Mailing List（LKML） +。在以後通過郵件發送問題報告時，不要遺漏任何 +一個郵件列表!維護者都是大忙人，可能會把一些工作留給子系統特定列表上的其他開 +發者；而 LKML 很重要，因爲需要一個可以找到所有問題報告的地方。 + + +藉助腳本找到維護者 +~~~~~~~~~~~~~~~~~~~~ + +對於手頭有Linux源碼的人來說，有第二個可以找到合適的報告地點的選擇：腳本 +「scripts/get_maintainer.pl」，它嘗試找到所有要聯繫的人。它會查詢MAINTAINERS +文件，並需要用相關原始碼的路徑來調用。對於編譯成模塊的驅動程序，經常可以用 +這樣的命令找到:: + + $ modinfo ath10k_pci | grep filename | sed 's!/lib/modules/.*/kernel/!!; s!filename:!!; s!\.ko\(\|\.xz\)!!' + drivers/net/wireless/ath/ath10k/ath10k_pci.ko + +將其中的部分內容傳遞給腳本:: + + $ ./scripts/get_maintainer.pl -f drivers/net/wireless/ath/ath10k* + Some Human (supporter:QUALCOMM ATHEROS ATH10K WIRELESS DRIVER) + Another S. Human (maintainer:NETWORKING DRIVERS) + ath10k@lists.infradead.org (open list:QUALCOMM ATHEROS ATH10K WIRELESS DRIVER) + linux-wireless@vger.kernel.org (open list:NETWORKING DRIVERS (WIRELESS)) + netdev@vger.kernel.org (open list:NETWORKING DRIVERS) + linux-kernel@vger.kernel.org (open list) + +不要把你的報告發給所有的人。發送給維護者，腳本稱之爲「supporter:」；另外抄送 +代碼最相關的郵件列表，以及 Linux 內核郵件列表（LKML）。在此例中，你需要將報 +告發送給 「Some Human 」 ，並抄送 +「ath10k@lists.infradead.org」和「linux-kernel@vger.kernel.org」。 + +注意：如果你用 git 克隆了 Linux 原始碼，你可能需要用--git 再次調用 +get_maintainer.pl。腳本會查看提交歷史，以找到最近哪些人參與了相關代碼的編寫， +因爲他們可能會提供幫助。但要小心使用這些結果，因爲它很容易讓你誤入歧途。 +例如，這種情況常常會發生在很少被修改的地方（比如老舊的或未維護的驅動程序）： +有時這樣的代碼會在樹級清理期間被根本不關心此驅動程序的開發者修改。 + + +搜索現有報告（第二部分） +-------------------------- + + *在缺陷追蹤器或問題相關郵件列表的存檔中徹底搜索可能與您的問題匹配的報告。 + 如果找到匹配的報告，請加入討論而不是發送新報告。* + +如前所述：報告一個別人已經提出的問題，對每個人來說都是浪費時間，尤其是作爲報告 +人的你。這就是爲什麼你應該再次搜索現有的報告。現在你已經知道問題需要報告到哪裡。 +如果是郵件列表，那麼一般在 `lore.kernel.org `_ 可以 +找到相應存檔。 + +但有些列表運行在其他地方。例如前面步驟中當例子的ath10k WiFi驅動程序就是這種 +情況。但是你通常可以在網上很容易地找到這些列表的檔案。例如搜索「archive +ath10k@lists.infradead.org」，將引導您到ath10k郵件列表的信息頁，該頁面頂部連結 +到其 `列表存檔 `_ 。遺憾的是， +這個列表和其他一些列表缺乏搜索其存檔的功能。在這種情況下可以使用常規的網際網路 +搜尋引擎，並添加類似「site:lists.infadead.org/pipermail/ath10k/」這 +樣的搜索條件，這會把結果限制在該連結中的檔案。 + +也請進一步搜索網絡、LKML和bugzilla.kernel.org網站。 + +有關如何搜索以及在找到匹配報告時如何操作的詳細信息，請參閱上面的「搜索現有報告 +（第一部分）」。 + +不要急著完成報告過程的這一步：花30到60分鐘甚至更多的時間可以爲你和其他人節省 / +減少相當多的時間和麻煩。 + + +安裝一個新的內核進行測試 +-------------------------- + + *除非您已經在運行最新的「主線」Linux內核，否則最好在報告流程前安裝它。在 + 某些情況下，使用最新的「穩定版」Linux進行測試和報告也是可以接受的替代方案； + 在合併窗口期間，這實際上可能是最好的方法，但在開發階段最好還是暫停幾天。 + 無論你選擇什麼版本，最好使用「普通」構建。忽略這些建議會大大增加您的報告 + 被拒絕或忽略的風險。* + +正如第一步的詳細解釋中所提到的：與大多數程式設計師一樣，與大多數程式設計師一樣，Linux +內核開發人員不喜歡花時間處理他們維護的原始碼中根本不會發生的問題的報告。這隻 +會浪費每個人的時間，尤其是你的時間。這就是爲什麼在報告問題之前，您必須先確認 +問題仍然存在於最新的上游代碼中，這符合每個人的利益。您可以忽略此建議，但如前 +所述：這樣做會極大地增加問題報告被拒絕或被忽略的風險。 + +內核「最新上游」的範圍通常指： + + * 安裝一個主線內核；最新的穩定版內核也可以是一個選擇，但大多數時候都最好避免。 + 長期支持內核（有時稱爲「LTS內核」）不適合此流程。下一小節將更詳細地解釋所有 + 這些。 + + * 下一小節描述獲取和安裝這樣一個內核的方法。它還指出了使用預編譯內核是可以的， + 但普通的內核更好，這意味著：它是直接使用從 `kernel.org `_ + 獲得的Linux原始碼構建並且沒有任何方式修改或增強。 + + +選擇適合測試的版本 +~~~~~~~~~~~~~~~~~~~~ + +前往 `kernel.org `_ 來決定使用哪個版本。忽略那個寫著 +「Latest release最新版本」的巨大黃色按鈕，往下看有一個表格。在表格的頂部，你會 +看到一行以「mainline」開頭的字樣，大多數情況下它會指向一個版本號類似「5.8-rc2」 +的預發布版本。如果是這樣的話，你將需要使用這個主線內核進行測試。不要讓「rc」 +嚇到你，這些「開發版內核」實際上非常可靠——而且你已經按照上面的指示做了備份， +不是嗎？ + +大概每九到十周，「mainline」可能會給你指出一個版本號類似「5.7」的正式版本。如果 +碰見這種情況，請考慮暫停報告過程，直到下一個版本的第一個預發布（5.8-rc1）出 +現在 `kernel.org `_ 上。這是因爲 Linux 的開發周期正在 +兩周的「合併窗口」內。大部分的改動和所有干擾性的改動都會在這段時間內被合併到 +下一個版本中。在此期間使用主線是比較危險的。內核開發者通常也很忙，可能沒有 +多餘的時間來處理問題報告。這也是很有可能在合併窗口中應用了許多修改來修復你 +所面臨的問題；這就是爲什麼你很快就得用一個新的內核版本重新測試，就像下面「發 +布報告後的責任」一節中所述的那樣。 + +這就是爲什麼要等到合併窗口結束後才去做。但是如果你處理的是一些不應該等待的 +東西，則無需這樣做。在這種情況下，可以考慮通過 git 獲取最新的主線內核（見下 +文），或者使用 kernel.org 上提供的最新穩定版本。如果 mainline 因爲某些原因 +不無法正常工作，那麼使用它也是可以接受的。總的來說：用它來重現問題也比完全 +不報告問題要好。 + +最好避免在合併窗口外使用最新的穩定版內核，因爲所有修復都必須首先應用於主線。 +這就是爲什麼檢查最新的主線內核是如此重要：你希望看到在舊版本線修復的任何問題 +需要先在主線修復，然後才能得到回傳，這可能需要幾天或幾周。另一個原因是：您 +希望的修復對於回傳來說可能太難或太冒險；因此再次報告問題不太可能改變任何事情。 + +這些方面也部分表明了爲什麼長期支持內核（有時稱爲「LTS內核」）不適合報告流程： +它們與當前代碼的距離太遠。因此，先去測試主線，然後再按流程走：如果主線沒有 +出現問題，流程將指導您如何在舊版本線中修復它。 + +如何獲得新的 Linux 內核 +~~~~~~~~~~~~~~~~~~~~~~~~~ + +你可以使用預編譯或自編譯的內核進行測試；如果你選擇後者，可以使用 git 獲取源 +代碼，或者下載其 tar 存檔包。 + +**使用預編譯的內核** ：這往往是最快速、最簡單、最安全的方法——尤其是在你不熟 +悉 Linux 內核的情況下。問題是：發行商或附加存儲庫提供的大多數版本都是從修改 +過的Linux原始碼構建的。因此它們不是普通的，通常不適合於測試和問題報告：這些 +更改可能會導致您面臨的問題或以某種方式影響問題。 + +但是如果您使用的是流行的Linux發行版，那麼您就很幸運了：對於大部分的發行版， +您可以在網上找到包含最新主線或穩定版本Linux內核包的存儲庫。使用這些是完全可 +以的，只要從存儲庫的描述中確認它們是普通的或者至少接近普通。此外，請確保軟體 +包包含kernel.org上提供的最新版本內核。如果這些軟體包的時間超過一周，那麼它們 +可能就不合適了，因爲新的主線和穩定版內核通常至少每周發布一次。 + +請注意，您以後可能需要手動構建自己的內核：有時這是調試或測試修復程序所必需的， +如後文所述。還要注意，預編譯的內核可能缺少在出現panic、Oops、warning或BUG時 +解碼內核列印的消息所需的調試符號；如果您計劃解碼這些消息，最好自己編譯內核 +（有關詳細信息，請參閱本小節結尾和「解碼失敗信息」小節）。 + +**使用git** ：熟悉 git 的開發者和有經驗的 Linux 用戶通常最好直接從 +`kernel.org 上的官方開發倉庫 +`_ +中獲取最新的 Linux 內核原始碼。這些很可能比最新的主線預發布版本更新一些。不 +用擔心：它們和正式的預發布版本一樣可靠，除非內核的開發周期目前正處於合併窗 +口中。不過即便如此，它們也是相當可靠的。 + +**常規方法** ：不熟悉 git 的人通常最好從 `kernel.org `_ +下載源碼的tar 存檔包。 + +如何實際構建一個內核並不在這裡描述，因爲許多網站已經解釋了必要的步驟。如果 +你是新手，可以考慮按照那些建議使用 ``make localmodconfig`` 來做，它將嘗試獲 +取你當前內核的配置，然後根據你的系統進行一些調整。這樣做並不能使編譯出來的 +內核更好，但可以更快地編譯。 + +注意：如果您正在處理來自內核的pannc、Oops、warning或BUG，請在配置內核時嘗試 +啓用 CONFIG_KALLSYMS 選項。此外，還可以啓用 CONFIG_DEBUG_KERNEL 和 +CONFIG_DEBUG_INFO；後者是相關選項，但只有啓用前者才能開啓。請注意， +CONFIG_DEBUG_INFO 會需要更多儲存空間來構建內核。但這是值得的，因爲這些選項將 +允許您稍後精確定位觸發問題的確切代碼行。下面的「解碼失敗信息」一節對此進行了更 +詳細的解釋。 + +但請記住：始終記錄遇到的問題，以防難以重現。發送未解碼的報告總比不報告要好。 + + +檢查「汙染」標誌 +---------------- + + *確保您剛剛安裝的內核在運行時不會「汙染」自己。* + +正如上面已經詳細介紹過的：當發生一些可能會導致一些看起來完全不相關的後續錯 +誤的事情時，內核會設置一個「汙染」標誌。這就是爲什麼你需要檢查你剛剛安裝的內 +核是否有設置此標誌。如果有的話，幾乎在任何情況下你都需要在報告問題之前先消 +除它。詳細的操作方法請看上面的章節。 + + +用新內核重現問題 +------------------ + + *在您剛剛安裝的內核中復現這個問題。如果它沒有出現，請查看下方只發生在 + 穩定版和長期支持內核的問題的說明。* + +檢查這個問題是否發生在你剛剛安裝的新 Linux 內核版本上。如果新內核已經修復了， +可以考慮使用此版本線，放棄報告問題。但是請記住，只要它沒有在 `kernel.org +`_ 的穩定版和長期版（以及由這些版本衍生出來的廠商內核） +中得到修復，其他用戶可能仍然會受到它的困擾。如果你喜歡使用其中的一個，或 +者只是想幫助它們的用戶，請前往下面的「報告只發生在較舊內核版本線的問題」一節。 + + +優化復現問題的描述 +-------------------- + + *優化你的筆記：試著找到並寫出最直接的復現問題的方法。確保最終結果包含所 + 有重要的細節，同時讓第一次聽說的人容易閱讀和理解。如果您在此過程中學到 + 了一些東西，請考慮再次搜索關於該問題的現有報告。* + +過於複雜的報告會讓別人很難理解。因此請儘量找到一個可以直接描述、易於以書面 +形式理解的再現方法。包含所有重要的細節，但同時也要儘量保持簡短。 + +在這在前面的步驟中，你很可能已經了解了一些關於你所面臨的問題的點。利用這些 +知識，再次搜索可以轉而加入的現有報告。 + + +解碼失敗信息 +------------- + + *如果失敗涉及「panic」、「Oops」、「warning」或「BUG」，請考慮解碼內核日誌以查找 + 觸發錯誤的代碼行。* + +當內核檢測到內部問題時，它會記錄一些有關已執行代碼的信息。這使得在原始碼中精 +確定位觸發問題的行並顯示如何調用它成爲可能。但只有在配置內核時啓用了 +CONFIG_DEBUG_INFO 和 CONFIG_KALLSYMS選項時，這種方法才起效。如果已啓用此選項， +請考慮解碼內核日誌中的信息。這將使我們更容易理解是什麼導致了「panic」、「Oops」、 +「warning」或「BUG」，從而增加了有人提供修復的機率。 + +解碼可以通過Linux原始碼樹中的腳本來完成。如果您運行的內核是之前自己編譯的， +這樣這樣調用它:: + + [user@something ~]$ sudo dmesg | ./linux-5.10.5/scripts/decode_stacktrace.sh ./linux-5.10.5/vmlinux + /usr/lib/debug/lib/modules/5.10.10-4.1.x86_64/vmlinux /usr/src/kernels/5.10.10-4.1.x86_64/ + +如果您運行的是打包好的普通內核，則可能需要安裝帶有調試符號的相應包。然後按以下 +方式調用腳本（如果發行版未打包，則可能需要從Linux原始碼獲取）:: + + [user@something ~]$ sudo dmesg | ./linux-5.10.5/scripts/decode_stacktrace.sh \ + /usr/lib/debug/lib/modules/5.10.10-4.1.x86_64/vmlinux /usr/src/kernels/5.10.10-4.1.x86_64/ + +腳本將解碼如下的日誌行，這些日誌行顯示內核在發生錯誤時正在執行的代碼的地址:: + + [ 68.387301] RIP: 0010:test_module_init+0x5/0xffa [test_module] + +解碼之後，這些行將變成這樣:: + + [ 68.387301] RIP: 0010:test_module_init (/home/username/linux-5.10.5/test-module/test-module.c:16) test_module + +在本例中，執行的代碼是從文件「~/linux-5.10.5/test-module/test-module.c」構建的， +錯誤出現在第16行的指令中。 + +該腳本也會如此解碼以「Call trace」開頭的部分中提到的地址，該部分顯示出現問題的 +函數的路徑。此外，腳本還會顯示內核正在執行的代碼部分的彙編輸出。 + +注意，如果你沒法做到這一點，只需跳過這一步，並在報告中說明原因。如果你幸運的 +話，可能無需解碼。如果需要的話，也許有人會幫你做這件事情。還要注意，這只是解 +碼內核堆棧跟蹤的幾種方法之一。有時需要採取不同的步驟來檢索相關的詳細信息。 +別擔心，如果您碰到的情況需要這樣做，開發人員會告訴您該怎麼做。 + + +對回歸的特別關照 +----------------- + + *如果您的問題是回歸問題，請儘可能縮小引入問題時的範圍。* + +Linux 首席開發者 Linus Torvalds 認爲 Linux 內核永遠不應惡化，這就是爲什麼他 +認爲回歸是不可接受的，並希望看到它們被迅速修復。這就是爲什麼引入了回歸的改 +動導致的問題若無法通過其他方式快速解決，通常會被迅速撤銷。因此，報告回歸有 +點像「王炸」，會迅速得到修復。但要做到這一點，需要知道導致回歸的變化。通常情 +況下，要由報告者來追查罪魁禍首，因爲維護者往往沒有時間或手頭設置不便來自行 +重現它。 + +有一個叫做「二分」的過程可以來尋找變化，這在 +「Documentation/translations/zh_TW/admin-guide/bug-bisect.rst」文檔中進行了詳細 +的描述，這個過程通常需要你構建十到二十個內核鏡像，每次都嘗試在構建下一個鏡像 +之前重現問題。是的，這需要花費一些時間，但不用擔心，它比大多數人想像的要快得多。 +多虧了「binary search二進位搜索」，這將引導你在原始碼管理系統中找到導致回歸的提交。 +一旦你找到它，就在網上搜索其主題、提交ID和縮短的提交ID（提交ID的前12個字符）。 +如果有的話，這將引導您找到關於它的現有報告。 + +需要注意的是，二分法需要一點竅門，不是每個人都懂得訣竅，也需要相當多的努力， +不是每個人都願意投入。儘管如此，還是強烈建議自己進行一次二分。如果你真的 +不能或者不想走這條路，至少要找出是哪個主線內核引入的回歸。比如說從 5.5.15 +切換到 5.8.4 的時候出現了一些問題，那麼至少可以嘗試一下相近的所有的主線版本 +（5.6、5.7 和 5.8）來檢查它是什麼時候出現的。除非你想在一個穩定版或長期支持 +內核中找到一個回歸，否則要避免測試那些編號有三段的版本（5.6.12、5.7.8），因 +爲那會使結果難以解釋，可能會讓你的測試變得無用。一旦你找到了引入回歸的主要 +版本，就可以放心地繼續報告了。但請記住：在不知道罪魁禍首的情況下，開發人員 +是否能夠提供幫助取決於手頭的問題。有時他們可能會從報告中確認是什麼出現了問 +題，並能修復它；有時他們可能無法提供幫助，除非你進行二分。 + +當處理回歸問題時，請確保你所面臨的問題真的是由內核引起的，而不是由其他東西 +引起的，如上文所述。 + +在整個過程中，請記住：只有當舊內核和新內核的配置相似時，問題才算回歸。最好 +的方法是：把配置文件（``.config``）從舊的工作內核直接複製到你嘗試的每個新內 +核版本。之後運行 ``make oldnoconfig`` 來調整它以適應新版本的需要，而不啓用 +任何新的功能，因爲那些功能也可能導致回歸。 + + +撰寫並發送報告 +--------------- + + *通過詳細描述問題來開始編寫報告。記得包括以下條目：您爲復現而安裝的最新 + 內核版本、使用的Linux發行版以及關於如何復現該問題的說明。如果可能，將內 + 核構建配置（.config）和 ``dmesg`` 的輸出放在網上的某個地方，並連結到它。 + 包含或上傳所有其他可能相關的信息，如Oops的輸出/截圖或來自 ``lspci`` + 的輸出。一旦你寫完了這個主要部分，請在上方插入一個正常長度的段落快速概 + 述問題和影響。再在此之上添加一個簡單描述問題的句子，以得到人們的閱讀。 + 現在給出一個更短的描述性標題或主題。然後就可以像MAINTAINERS文件告訴你的 + 那樣發送或提交報告了，除非你在處理一個「高優先級問題」：它們需要按照下面 + 「高優先級問題的特殊處理」所述特別關照。* + +現在你已經準備好了一切，是時候寫你的報告了。上文前言中連結的三篇文檔對如何 +寫報告做了部分解釋。這就是爲什麼本文將只提到一些基本的內容以及 Linux 內核特 +有的東西。 + +有一點是符合這兩類的：你的報告中最關鍵的部分是標題/主題、第一句話和第一段。 +開發者經常會收到許多郵件。因此，他們往往只是花幾秒鐘的時間瀏覽一下郵件，然 +後再決定繼續下一封或仔細查看。因此，你報告的開頭越好，有人研究並幫助你的機 +會就越大。這就是爲什麼你應該暫時忽略他們，先寫出詳細的報告。;-) + +每份報告都應提及的事項 +~~~~~~~~~~~~~~~~~~~~~~~~ + +詳細描述你的問題是如何發生在你安裝的新純淨內核上的。試著包含你之前寫的和優 +化過的分步說明，概述你和其他人如何重現這個問題；在極少數無法重現的情況下， +儘量描述你做了什麼來觸發它。 + +還應包括其他人爲了解該問題及其環境而可能需要的所有相關信息。實際需要的東西 +在很大程度上取決於具體問題，但有些事項你總是應該包括在內： + + * ``cat /proc/version`` 的輸出，其中包含 Linux 內核版本號和構建時的編譯器。 + + * 機器正在運行的 Linux 發行版（ ``hostnamectl | grep 「Operating System「`` ） + + * CPU 和作業系統的架構（ ``uname -mi`` ） + + * 如果您正在處理回歸，並進行了二分，請提及導致回歸的變更的主題和提交ID。 + +許多情況下，讓讀你報告的人多了解兩件事也是明智之舉： + + * 用於構建 Linux 內核的配置（「.config」文件） + + * 內核的信息，你從 ``dmesg`` 得到的信息寫到一個文件里。確保它以像「Linux + version 5.8-1 (foobar@example.com) (gcc (GCC) 10.2.1, GNU ld version + 2.34) #1 SMP Mon Aug 3 14:54:37 UTC 2020」這樣的行開始，如果沒有，那麼第 + 一次啓動階段的重要信息已經被丟棄了。在這種情況下，可以考慮使用 + ``journalctl -b 0 -k`` ；或者你也可以重啓，重現這個問題，然後調用 + ``dmesg`` 。 + +這兩個文件很大，所以直接把它們放到你的報告中是個壞主意。如果你是在缺陷跟蹤 +器中提交問題，那麼將它們附加到工單中。如果你通過郵件報告問題，不要用附件附 +上它們，因爲那會使郵件變得太大，可以按下列之一做： + + * 將文件上傳到某個公開的地方（你的網站，公共文件粘貼服務，在 + `bugzilla.kernel.org `_ 上創建的工單……）， + 並在你的報告中放上連結。理想情況下請使用允許這些文件保存很多年的地方，因 + 爲它們可能在很多年後對別人有用；例如 5 年或 10 年後，一個開發者正在修改 + 一些代碼，而這些代碼正是爲了修復你的問題。 + + * 把文件放在一邊，然後說明你會在他人回復時再單獨發送。只要記得報告發出去後， + 真正做到這一點就可以了。;-) + +提供這些東西可能是明智的 +~~~~~~~~~~~~~~~~~~~~~~~~~~ + +根據問題的不同，你可能需要提供更多的背景數據。這裡有一些關於提供什麼比較好 +的建議： + + * 如果你處理的是內核的「warning」、「OOPS」或「panic」，請包含它。如果你不能複製 + 粘貼它，試著用netconsole網絡終端遠程跟蹤或者至少拍一張屏幕的照片。 + + * 如果問題可能與你的電腦硬體有關，請說明你使用的是什麼系統。例如，如果你的 + 顯卡有問題，請提及它的製造商，顯卡的型號，以及使用的晶片。如果是筆記本電 + 腦，請提及它的型號名稱，但儘量確保意義明確。例如「戴爾 XPS 13」就不很明確， + 因爲它可能是 2012 年的那款，那款除了看起來和現在銷售的沒有什麼不同之外， + 兩者沒有任何共同之處。因此，在這種情況下，要加上準確的型號，例如 2019 + 年內推出的 XPS 13 型號爲「9380」或「7390」。像「聯想 Thinkpad T590」這樣的名字 + 也有些含糊不清：這款筆記本有帶獨立顯卡和不帶的子型號，所以要儘量找到準確 + 的型號名稱或註明主要部件。 + + * 說明正在使用的相關軟體。如果你在加載模塊時遇到了問題，你要說明正在使用的 + kmod、systemd 和 udev 的版本。如果其中一個 DRM 驅動出現問題，你要說明 + libdrm 和 Mesa 的版本；還要說明你的 Wayland 合成器或 X-Server 及其驅動。 + 如果你有文件系統問題，請註明相應的文件系統實用程序的版本（e2fsprogs, + btrfs-progs, xfsprogs……）。 + + * 從內核中收集可能有用的額外信息。例如， ``lspci -nn`` 的輸出可以幫助別人 + 識別你使用的硬體。如果你的硬體有問題，你甚至可以給出 ``sudo lspci -vvv`` + 的結果，因爲它提供了組件是如何配置的信息。對於一些問題，可能最好包含 + ``/proc/cpuinfo`` ， ``/proc/ioports`` ， ``/proc/iomem`` ， + ``/proc/modules`` 或 ``/proc/scsi/scsi`` 等文件的內容。一些子系統還提 + 供了收集相關信息的工具。 ``alsa-info.sh`` `就是這樣一個工具，它是音頻/聲 + 音子系統開發者提供的 `_ 。 + +這些例子應該會給你一些知識點，讓你知道附上什麼數據可能是明智的，但你自己也 +要想一想，哪些數據對別人會有幫助。不要太擔心忘記一些東西，因爲開發人員會要 +求提供他們需要的額外細節。但從一開始就把所有重要的東西都提供出來，會增加別 +人仔細查看的機會。 + + +重要部分：報告的開頭 +~~~~~~~~~~~~~~~~~~~~~~ + +現在你已經準備好了報告的詳細部分，讓我們進入最重要的部分：開頭幾句。現在到 +報告的最前面，在你剛才寫的部分之前加上類似「The detailed description:」（詳細 +描述）這樣的內容，並在最前面插入兩個新行。現在寫一個正常長度的段落，大致概 +述這個問題。去掉所有枯燥的細節，把重點放在讀者需要知道的關鍵部分，以讓人了 +解這是怎麼回事；如果你認爲這個缺陷影響了很多用戶，就提一下這點來吸引大家關 +注。 + +做好這一點後，在頂部再插入兩行，寫一句話的摘要，快速解釋報告的內容。之後你 +要更加抽象，爲報告寫一個更短的主題/標題。 + +現在你已經寫好了這部分，請花點時間來優化它，因爲它是你的報告中最重要的部分： +很多人會先讀這部分，然後才會決定是否值得花時間閱讀其他部分。 + +現在就像 :ref:`MAINTAINERS ` 維護者文件告訴你的那樣發送或提交 +報告，除非它是前面概述的那些「高優先級問題」之一：在這種情況下，請先閱讀下一 +小節，然後再發送報告。 + +高優先級問題的特殊處理 +~~~~~~~~~~~~~~~~~~~~~~~~ + +高優先級問題的報告需要特殊處理。 + +**非常嚴重的缺陷** ：確保在主題或工單標題以及第一段中明顯標出 severeness +（非常嚴重的）。 + +**回歸** ：如果問題是一個回歸，請在郵件的主題或缺陷跟蹤器的標題中添加 +[REGRESSION]。如果您沒有進行二分，請至少註明您測試的最新主線版本（比如 5.7） +和出現問題的最新版本（比如 5.8）。如果您成功地進行了二分，請註明導致回歸 +的提交ID和主題。也請添加該變更的作者到你的報告中；如果您需要將您的缺陷提交 +到缺陷跟蹤器中，請將報告以私人郵件的形式轉發給他，並註明報告提交地點。 + +**安全問題** ：對於這種問題，你將必須評估：如果細節被公開披露，是否會對其他 +用戶產生短期風險。如果不會，只需按照所述繼續報告問題。如果有此風險，你需要 +稍微調整一下報告流程。 + + * 如果 MAINTAINERS 文件指示您通過郵件報告問題，請不要抄送任何公共郵件列表。 + + * 如果你應該在缺陷跟蹤器中提交問題，請確保將工單標記爲「私有」或「安全問題」。 + 如果缺陷跟蹤器沒有提供保持報告私密性的方法，那就別想了，把你的報告以私人 + 郵件的形式發送給維護者吧。 + +在這兩種情況下，都一定要將報告發到 MAINTAINERS 文件中「安全聯絡」部分列出的 +地址。理想的情況是在發送報告的時候直接抄送他們。如果您在缺陷跟蹤器中提交了 +報告，請將報告的文本轉發到這些地址；但請在報告的頂部加上注釋，表明您提交了 +報告，並附上工單連結。 + +更多信息請參見「Documentation/translations/zh_TW/admin-guide/security-bugs.rst」。 + + +發布報告後的責任 +------------------ + + *等待別人的反應，繼續推進事情，直到你能夠接受這樣或那樣的結果。因此，請 + 公開和及時地回應任何詢問。測試提出的修復。積極地測試：至少重新測試每個 + 新主線版本的首個候選版本（RC），並報告你的結果。如果出現拖延，就友好地 + 提醒一下。如果你沒有得到任何幫助或者未能滿意，請試著自己幫助自己。* + +如果你的報告非常優秀，而且你真的很幸運，那麼某個開發者可能會立即發現導致問 +題的原因；然後他們可能會寫一個補丁來修復、測試它，並直接發送給主線集成，同 +時標記它以便以後回溯到需要它的穩定版和長期支持內核。那麼你需要做的就是回復 +一句「Thank you very much」（非常感謝），然後在發布後換上修復好的版本。 + +但這種理想狀況很少發生。這就是爲什麼你把報告拿出來之後工作才開始。你要做的 +事情要視情況而定，但通常會是下面列出的事情。但在深入研究細節之前，這裡有幾 +件重要的事情，你需要記住這部分的過程。 + + +關於進一步互動的一般建議 +~~~~~~~~~~~~~~~~~~~~~~~~~~ + +**總是公開回復** ：當你在缺陷跟蹤器中提交問題時，一定要在那裡回復，不要私下 +聯繫任何開發者。對於郵件報告，在回復您收到的任何郵件時，總是使用「全部回復」 +功能。這包括帶有任何你可能想要添加到你的報告中的額外數據的郵件：進入郵件應 +用程序「已發送」文件夾，並在郵件上使用「全部回復」來回復報告。這種方法可以確保 +公共郵件列表和其他所有參與者都能及時了解情況；它還能保持郵件線程的完整性， +這對於郵件列表將所有相關郵件歸爲一類是非常重要的。 + +只有兩種情況不適合在缺陷跟蹤器或「全部回復」中發表評論： + + * 有人讓你私下發東西。 + + * 你被告知要發送一些東西，但注意到其中包含需要保密的敏感信息。在這種情況下， + 可以私下發送給要求發送的開發者。但要在工單或郵件中註明你是這麼做的，這 + 樣其他人就知道你尊重了這個要求。 + +**在請求解釋或幫助之前先研究一下** ：在這部分過程中，有人可能會告訴你用尚未 +掌握的技能做一些事情。例如你可能會被要求使用一些你從未聽說過的測試工具；或 +者你可能會被要求在 Linux 內核原始碼上應用一個補丁來測試它是否有幫助。在某些 +情況下，發個回復詢問如何做就可以了。但在走這條路之前，儘量通過在網際網路上搜 +索自行找到答案；或者考慮在其他地方詢問建議。比如詢問朋友，或者到你平時常去 +的聊天室或論壇發帖諮詢。 + +**要有耐心** ：如果你真的很幸運，你可能會在幾個小時內收到對你的報告的答覆。 +但大多數情況下會花費更多的時間，因爲維護者分散在全球各地，因此可能在不同的 +時區——在那裡他們已經享受著遠離鍵盤的夜晚。 + +一般來說，內核開發者需要一到五個工作日來回復報告。有時會花費更長的時間，因 +爲他們可能正忙於合併窗口、其他工作、參加開發者會議，或者只是在享受一個漫長 +的暑假。 + +「高優先級的問題」（見上面的解釋）例外：維護者應該儘快解決這些問題；這就是爲 +什麼你應該最多等待一個星期（如果是緊急的事情，則只需兩天），然後再發送友好 +的提醒。 + +有時維護者可能沒有及時回復；有時候可能會出現分歧，例如一個問題是否符合回歸 +的條件。在這種情況下，在郵件列表上提出你的顧慮，並請求其他人公開或私下回復 +如何繼續推進。如果失敗了，可能應該讓更高級別的維護者介入。如果是 WiFi 驅動， +那就是無線維護者；如果沒有更高級別的維護者，或者其他一切努力都失敗了，那 +這可能是一種罕見的、可以讓 Linus Torvalds 參與進來的情況。 + +**主動測試** ：每當一個新的主線內核版本的第一個預發布版本（rc1）發布的時候， +去檢查一下這個問題是否得到了解決，或者是否有什麼重要的變化。在工單中或在 +回復報告的郵件中提及結果（確保所有參與討論的人都被抄送）。這將表明你的承諾 +和你願意幫忙。如果問題持續存在，它也會提醒開發者確保他們不會忘記它。其他一 +些不定期的重新測試（例如用rc3、rc5 和最終版本）也是一個好主意，但只有在相關 +的東西發生變化或者你正在寫什麼東西的時候才報告你的結果。 + +這些些常規的事情就不說了，我們來談談報告後如何幫助解決問題的細節。 + +查詢和測試請求 +~~~~~~~~~~~~~~~ + +如果你的報告得到了回復則需履行以下責任： + +**檢查與你打交道的人** ：大多數情況下，會是維護者或特定代碼區域的開發人員對 +你的報告做出回應。但由於問題通常是公開報告的，所以回復的可能是任何人——包括 +那些想要幫忙的人，但最後可能會用他們的問題或請求引導你完全偏離軌道。這很少 +發生，但這是快速上網搜搜看你正在與誰互動是明智之舉的許多原因之一。通過這樣 +做，你也可以知道你的報告是否被正確的人聽到，因爲如果討論沒有導致滿意的問題 +解決方案而淡出，之後可能需要提醒維護者（見下文）。 + +**查詢數據** ：通常你會被要求測試一些東西或提供更多細節。儘快提供所要求的信 +息，因爲你已經得到了可能會幫助你的人的注意，你等待的時間越長就有越可能失去 +關注；如果你不在數個工作日內提供信息，甚至可能出現這種結果。 + +**測試請求** ：當你被要求測試一個診斷補丁或可能的修復時，也要儘量及時測試。 +但要做得恰當，一定不要急於求成：混淆事情很容易發生，這會給所有人帶來許多困 +惑。例如一個常見的錯誤是以爲應用了一個帶修復的建議補丁，但事實上並沒有。即 +使是有經驗的測試人員也會偶爾發生這樣的事情，但當有修復的內核和沒有修復的內 +核表現得一樣時，他們大多時候會注意到。 + +當沒有任何實質性進展時該怎麼辦 +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +有些報告不會得到負有相關責任的 Linux 內核開發者的任何反應；或者圍繞這個問題 +的討論有所發展，但漸漸淡出，沒有任何實質內容產出。 + +在這種情況下，要等兩個星期（最好是三個星期）後再發出友好的提醒：也許當你的 +報告到達時，維護者剛剛離開鍵盤一段時間，或者有更重要的事情要處理。在寫提醒 +信的時候，要善意地問一下，是否還需要你這邊提供什麼來讓事情推進下去。如果報 +告是通過郵件發出來的，那就在郵件的第一行回覆你的初始郵件（見上文），其中包 +括下方的原始報告的完整引用：這是少數幾種情況下，這樣的「TOFU」（Text Over, +Fullquote Under文字在上，完整引用在下）是正確的做法，因爲這樣所有的收件人都 +會以適當的順序立即讓細節到手頭上來。 + +在提醒之後，再等三周的回覆。如果你仍然沒有得到適當的反饋，你首先應該重新考 +慮你的方法。你是否可能嘗試接觸了錯誤的人？是不是報告也許令人反感或者太混亂， +以至於人們決定完全遠離它？排除這些因素的最好方法是：把報告給一兩個熟悉 +FLOSS 問題報告的人看，詢問他們的意見。同時徵求他們關於如何繼續推進的建議。 +這可能意味著：準備一份更好的報告，讓這些人在你發出去之前對它進行審查。這樣 +的方法完全可以；只需說明這是關於這個問題的第二份改進的報告，並附上第一份報 +告的連結。 + +如果報告是恰當的，你可以發送第二封提醒信；在其中詢問爲什麼報告沒有得到任何 +回復。第二封提醒郵件的好時機是在新 Linux 內核版本的首個預發布版本（'rc1'） +發布後不久，因爲無論如何你都應該在那個時候重新測試並提供狀態更新（見上文）。 + +如果第二次提醒的結果又在一周內沒有任何反應，可以嘗試聯繫上級維護者詢問意見： +即使再忙的維護者在這時候也至少應該發過某種確認。 + +記住要做好失望的準備：理想狀況下維護者最好對每一個問題報告做出回應，但他們 +只有義務解決之前列出的「高優先級問題」。所以，如果你得到的回覆是「謝謝你的報告， +我目前有更重要的問題要處理，在可預見的未來沒有時間去研究這個問題」，那請不 +要太沮喪。 + +也有可能在缺陷跟蹤器或列表中進行了一些討論之後，什麼都沒有發生，提醒也無助 +於激勵大家進行修復。這種情況可能是毀滅性的，但在 Linux 內核開發中確實會發生。 +這些和其他得不到幫助的原因在本文結尾處的「爲什麼有些問題在被報告後沒有得到 +任何回應或者仍然沒有修復」中進行了解釋。 + +如果你沒有得到任何幫助或問題最終沒有得到解決，不要沮喪：Linux 內核是 FLOSS， +因此你仍然可以自己幫助自己。例如，你可以試著找到其他受影響的人，和他們一 +起合作來解決這個問題。這樣的團隊可以一起準備一份新的報告，提到團隊有多少人， +爲什麼你們認爲這是應該得到解決的事情。也許你們還可以一起縮小確切原因或引 +入回歸的變化，這往往會使修復更容易。而且如果運氣好的話，團隊中可能會有懂點 +編程的人，也許能寫出一個修複方案。 + + + +「報告穩定版和長期支持內核線的回歸」的參考 +------------------------------------------ + +本小節提供了在穩定版和長期支持內核線中面對回歸時需要執行的步驟的詳細信息。 + +確保特定版本線仍然受支持 +~~~~~~~~~~~~~~~~~~~~~~~~~ + + *檢查內核開發人員是否仍然維護你關心的Linux內核版本線：去 kernel.org 的 + 首頁，確保此特定版本線的最新版沒有「[EOL]」標記。* + +大多數內核版本線只支持三個月左右，因爲延長維護時間會帶來相當多的工作。因此， +每年只會選擇一個版本來支持至少兩年（通常是六年）。這就是爲什麼你需要檢查 +內核開發者是否還支持你關心的版本線。 + +注意，如果 `kernel.org `_ 在首頁上列出了兩個「穩定」版本， +你應該考慮切換到較新的版本，而忘掉較舊的版本：對它的支持可能很快就會結束。 +然後，它將被標記爲「生命周期結束」（EOL）。達到這個程度的版本線仍然會在 +`kernel.org `_ 首頁上被顯示一兩周，但不適合用於測試和 +報告。 + +搜索穩定版郵件列表 +~~~~~~~~~~~~~~~~~~~ + + *檢查Linux穩定版郵件列表中的現有報告。* + +也許你所面臨的問題已經被發現，並且已經或即將被修復。因此，請在 `Linux 穩定 +版郵件列表的檔案 `_ 中搜索類似問題的報告。 +如果你找到任何匹配的問題，可以考慮加入討論，除非修復工作已經完成並計劃很快 +得到應用。 + +用最新版本復現問題 +~~~~~~~~~~~~~~~~~~~ + + *從特定的版本線安裝最新版本作爲純淨內核。確保這個內核沒有被汙染，並且仍 + 然存在問題，因爲問題可能已經在那裡被修復了。* + +在投入更多時間到這個過程中之前，你要檢查這個問題是否在你關注的版本線的最新 +版本中已經得到了修復。這個內核需要是純淨的，在問題發生之前不應該被汙染，正 +如上面已經在測試主線的過程中詳細介紹過的一樣。 + +您是否是第一次注意到供應商內核的回歸？供應商的更改可能會發生變化。你需要重新 +檢查排除來這個問題。當您從5.10.4-vendor.42更新到5.10.5-vendor.43時，記錄損壞 +的信息。然後在測試了前一段中所述的最新5.10版本之後，檢查Linux 5.10.4的普通版本 +是否也可以正常工作。如果問題在那裡出現，那就不符合上游回歸的條件，您需要切換 +回主逐步指南來報告問題。 + +報告回歸 +~~~~~~~~~~ + + *向Linux穩定版郵件列表發送一個簡短的問題報告(stable@vger.kernel.org)。 + 大致描述問題，並解釋如何復現。講清楚首個出現問題的版本和最後一個工作正常 + 的版本。然後等待進一步的指示。* + +當報告在穩定版或長期支持內核線內發生的回歸（例如在從5.10.4更新到5.10.5時）， +一份簡短的報告足以快速報告問題。因此只需要粗略的描述。 + +但是請注意，如果您能夠指明引入問題的確切版本，這將對開發人員有很大幫助。因此 +如果有時間的話，請嘗試使用普通內核找到該版本。讓我們假設發行版發布Linux內核 +5.10.5到5.10.8的更新時發生了故障。那麼按照上面的指示，去檢查該版本線中的最新 +內核，比如5.10.9。如果問題出現，請嘗試普通5.10.5，以確保供應商應用的補丁不會 +干擾。如果問題沒有出現，那麼嘗試5.10.7，然後直到5.10.8或5.10.6（取決於結果） +找到第一個引入問題的版本。在報告中寫明這一點，並指出5.10.9仍然存在故障。 + +前一段基本粗略地概述了「二分」方法。一旦報告出來，您可能會被要求做一個正確的 +報告，因爲它允許精確地定位導致問題的確切更改（然後很容易被恢復以快速修復問題）。 +因此如果時間允許，考慮立即進行適當的二分。有關如何詳細信息，請參閱「對回歸的 +特別關照」部分和文檔「Documentation/translations/zh_TW/admin-guide/bug-bisect.rst」。 + + +「報告僅在舊內核版本線中發生的問題」的參考 +------------------------------------------ + +本節詳細介紹了如果無法用主線內核重現問題，但希望在舊版本線（又稱穩定版內核和 +長期支持內核）中修復問題時需要採取的步驟。 + +有些修復太複雜 +~~~~~~~~~~~~~~~ + + *請做好準備，接下來的幾個步驟可能無法在舊版本中解決問題：修復可能太大或 + 太冒險，無法移植到那裡。* + +即使是微小的、看似明顯的代碼變化，有時也會帶來新的、完全意想不到的問題。穩 +定版和長期支持內核的維護者非常清楚這一點，因此他們只對這些內核進行符合 +「Documentation/translations/zh_TW/process/stable-kernel-rules.rst」中所列出的 +規則的修改。 + +複雜或有風險的修改不符合條件，因此只能應用於主線。其他的修復很容易被回溯到 +最新的穩定版和長期支持內核，但是風險太大，無法集成到舊版內核中。所以要注意 +你所希望的修復可能是那些不會被回溯到你所關心的版本線的修復之一。在這種情況 +下，你將別無選擇，要麼忍受這個問題，要麼切換到一個較新的 Linux 版本，除非你 +想自己把修復補丁應用到你的內核中。 + +通用準備 +~~~~~~~~~~ + + *執行上面「報告僅在舊內核版本線中發生的問題」一節中的前三個步驟。* + +您需要執行本指南另一節中已經描述的幾個步驟。這些步驟將讓您： + + * 檢查內核開發人員是否仍然維護您關心的Linux內核版本行。 + + * 在Linux穩定郵件列表中搜索退出的報告。 + + * 檢查最新版本。 + + +檢查代碼歷史和搜索現有的討論 +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + + *在Linux內核版本控制系統中搜索修復主線問題的更改，因爲它的提交消息可能 + 會告訴你修復是否已經計劃好了支持。如果你沒有找到，搜索適當的郵件列表， + 尋找討論此類問題或同行評議可能修復的帖子；然後檢查討論是否認爲修復不適 + 合支持。如果支持根本不被考慮，加入最新的討論，詢問是否有可能。* + +在許多情況下，你所處理的問題會發生在主線上，但已在主線上得到了解決。修正它 +的提交也需要被回溯才能解決這個問題。這就是爲什麼你要搜索它或任何相關討論。 + + * 首先嘗試在存放 Linux 內核原始碼的 Git 倉庫中找到修復。你可以通過 + `kernel.org 上的網頁 + `_ + 或 `GitHub 上的鏡像 `_ 來實現；如果你 + 有一個本地克隆，你也可以在命令行用 ``git log --grep=`` 來搜索。 + + 如果你找到了修復，請查看提交消息的尾部是否包含了類似這樣的「穩定版標籤」： + + Cc: # 5.4+ + + 像上面這行，開發者標記了安全修復可以回傳到 5.4 及以後的版本。大多數情況 + 下，它會在兩周內被應用到那裡，但有時需要更長的時間。 + + * 如果提交沒有告訴你任何東西，或者你找不到修復，請再找找關於這個問題的討論。 + 用你最喜歡的搜尋引擎搜索網絡，以及 `Linux kernel developers mailing + list 內核開發者郵件列表 `_ 的檔案。也可以 + 閱讀上面的 `定位導致問題的內核區域` 一節，然後按照說明找到導致問題的子系 + 統：它的缺陷跟蹤器或郵件列表存檔中可能有你要找的答案。 + + * 如果你看到了一個計劃的修復，請按上所述在版本控制系統中搜索它，因爲提交可 + 能會告訴你是否可以進行回溯。 + + * 檢查討論中是否有任何跡象表明，該修復程序可能風險太大，無法回溯到你關心 + 的版本線。如果是這樣的話，你必須忍受這個問題，或者切換到應用了修復的內 + 核版本線。 + + * 如果修復的問題未包含穩定版標籤，並且沒有討論過回溯問題，請加入討論：如 + 果合適的話，請提及你所面對的問題的版本，以及你希望看到它被修復。 + + +請求建議 +~~~~~~~~~ + + *前面的步驟之一應該會給出一個解決方案。如果仍未能成功，請向可能引起問題 + 的子系統的維護人員詢問建議；抄送特定子系統的郵件列表以及穩定版郵件列表。* + +如果前面的三個步驟都沒有讓你更接近解決方案，那麼只剩下一個選擇：請求建議。 +在你發給可能是問題根源的子系統的維護者的郵件中這樣做；抄送子系統的郵件列表 +以及穩定版郵件列表（stable@vger.kernel.org）。 + + +爲什麼有些問題在報告後沒有任何回應或仍未解決？ +=============================================== + +當向 Linux 開發者報告問題時，要注意只有「高優先級的問題」（回歸、安全問題、嚴 +重問題）才一定會得到解決。如果維護者或其他人都失敗了，Linus Torvalds 他自己 +會確保這一點。他們和其他內核開發者也會解決很多其他問題。但是要知道，有時他 +們也會不能或不願幫忙；有時甚至沒有人發報告給他們。 + +最好的解釋就是那些內核開發者常常是在業餘時間爲 Linux 內核做出貢獻。內核中的 +不少驅動程序都是由這樣的程式設計師編寫的，往往只是因爲他們想讓自己的硬體可以在 +自己喜歡的作業系統上使用。 + +這些程式設計師大多數時候會很樂意修復別人報告的問題。但是沒有人可以強迫他們這樣 +做，因爲他們是自願貢獻的。 + +還有一些情況下，這些開發者真的很想解決一個問題，但卻不能解決：有時他們缺乏 +硬體編程文檔來解決問題。這種情況往往由於公開的文檔太簡陋，或者驅動程序是通 +過逆向工程編寫的。 + +業餘開發者遲早也會不再關心某驅動。也許他們的測試硬體壞了，被更高級的玩意取 +代了，或者是太老了以至於只能在計算機博物館裡找到。有時開發者根本就不關心他 +們的代碼和 Linux 了，因爲在他們的生活中一些不同的東西變得更重要了。在某些情 +況下，沒有人願意接手維護者的工作——也沒有人可以被強迫，因爲對 Linux 內核的貢 +獻是自願的。然而被遺棄的驅動程序仍然存在於內核中：它們對人們仍然有用，刪除 +它們可能導致回歸。 + +對於那些爲 Linux 內核工作而獲得報酬的開發者來說，情況並沒有什麼不同。這些人 +現在貢獻了大部分的變更。但是他們的僱主遲早也會停止關注他們的代碼或者讓程序 +員專注於其他事情。例如，硬體廠商主要通過銷售新硬體來賺錢；因此，他們中的不 +少人並沒有投入太多時間和精力來維護他們多年前就停止銷售的東西的 Linux 內核驅 +動。企業級 Linux 發行商往往持續維護的時間比較長，但在新版本中往往會把對老舊 +和稀有硬體的支持放在一邊，以限制範圍。一旦公司拋棄了一些代碼，往往由業餘貢 +獻者接手，但正如上面提到的：他們遲早也會放下代碼。 + +優先級是一些問題沒有被修復的另一個原因，因爲維護者相當多的時候是被迫設置這 +些優先級的，因爲在 Linux 上工作的時間是有限的。對於業餘時間或者僱主給予他們 +的開發人員用於上游內核維護工作的時間也是如此。有時維護人員也會被報告淹沒， +即使一個驅動程序幾乎完美地工作。爲了不被完全纏住，程式設計師可能別無選擇，只能 +對問題報告進行優先級排序而拒絕其中的一些報告。 + +不過這些都不用太過擔心，很多驅動都有積極的維護者，他們對儘可能多的解決問題 +相當感興趣。 + + +結束語 +======= + +與其他免費/自由&開源軟體（Free/Libre & Open Source Software，FLOSS）相比， +向 Linux 內核開發者報告問題是很難的：這個文檔的長度和複雜性以及字裡行間的內 +涵都說明了這一點。但目前就是這樣了。這篇文字的主要作者希望通過記錄現狀來爲 +以後改善這種狀況打下一些基礎。 + diff --git a/Documentation/translations/zh_TW/admin-guide/security-bugs.rst b/Documentation/translations/zh_TW/admin-guide/security-bugs.rst new file mode 100644 index 000000000000..eed260ef0c37 --- /dev/null +++ b/Documentation/translations/zh_TW/admin-guide/security-bugs.rst @@ -0,0 +1,78 @@ +.. SPDX-License-Identifier: GPL-2.0 + +.. include:: ../disclaimer-zh_TW.rst + +:Original: :doc:`../../../admin-guide/security-bugs` + +:譯者: + + 吳想成 Wu XiangCheng + 胡皓文 Hu Haowen + +安全缺陷 +========= + +Linux內核開發人員非常重視安全性。因此我們想知道何時發現了安全漏洞，以便儘快 +修復和披露。請向Linux內核安全團隊報告安全漏洞。 + +聯絡 +----- + +可以通過電子郵件聯繫Linux內核安全團隊。這是一個安全人員 +的私有列表，他們將幫助驗證錯誤報告並開發和發布修復程序。如果您已經有了一個 +修復，請將其包含在您的報告中，這樣可以大大加快進程。安全團隊可能會從區域維護 +人員那裡獲得額外的幫助，以理解和修復安全漏洞。 + +與任何缺陷一樣，提供的信息越多，診斷和修復就越容易。如果您不清楚哪些信息有用， +請查看「Documentation/translations/zh_TW/admin-guide/reporting-issues.rst」中 +概述的步驟。任何利用漏洞的攻擊代碼都非常有用，未經報告者同意不會對外發布，除 +非已經公開。 + +請儘可能發送無附件的純文本電子郵件。如果所有的細節都藏在附件里，那麼就很難對 +一個複雜的問題進行上下文引用的討論。把它想像成一個 +:doc:`常規的補丁提交 <../process/submitting-patches>` （即使你還沒有補丁）： +描述問題和影響，列出復現步驟，然後給出一個建議的解決方案，所有這些都是純文本的。 + +披露和限制信息 +--------------- + +安全列表不是公開渠道。爲此，請參見下面的協作。 + +一旦開發出了健壯的補丁，發布過程就開始了。對公開的缺陷的修復會立即發布。 + +儘管我們傾向於在未公開缺陷的修復可用時即發布補丁，但應報告者或受影響方的請求， +這可能會被推遲到發布過程開始後的7日內，如果根據缺陷的嚴重性需要更多的時間， +則可額外延長到14天。推遲發布修復的唯一有效原因是爲了適應QA的邏輯和需要發布 +協調的大規模部署。 + +雖然可能與受信任的個人共享受限信息以開發修復，但未經報告者許可，此類信息不會 +與修復程序一起發布或發布在任何其他披露渠道上。這包括但不限於原始錯誤報告和 +後續討論（如有）、漏洞、CVE信息或報告者的身份。 + +換句話說，我們唯一感興趣的是修復缺陷。提交給安全列表的所有其他資料以及對報告 +的任何後續討論，即使在解除限制之後，也將永久保密。 + +協調 +------ + +對敏感缺陷（例如那些可能導致權限提升的缺陷）的修復可能需要與私有郵件列表 +進行協調，以便分發供應商做好準備，在公開披露 +上游補丁時發布一個已修復的內核。發行版將需要一些時間來測試建議的補丁，通常 +會要求至少幾天的限制，而供應商更新發布更傾向於周二至周四。若合適，安全團隊 +可以協助這種協調，或者報告者可以從一開始就包括linux發行版。在這種情況下，請 +記住在電子郵件主題行前面加上「[vs]」，如linux發行版wiki中所述： +。 + +CVE分配 +-------- + +安全團隊通常不分配CVE，我們也不需要它們來進行報告或修復，因爲這會使過程不必 +要的複雜化，並可能耽誤缺陷處理。如果報告者希望在公開披露之前分配一個CVE編號， +他們需要聯繫上述的私有linux-distros列表。當在提供補丁之前已有這樣的CVE編號時， +如報告者願意，最好在提交消息中提及它。 + +保密協議 +--------- + +Linux內核安全團隊不是一個正式的機構實體，因此無法簽訂任何保密協議。 + diff --git a/Documentation/translations/zh_TW/admin-guide/tainted-kernels.rst b/Documentation/translations/zh_TW/admin-guide/tainted-kernels.rst new file mode 100644 index 000000000000..d7b3c4276417 --- /dev/null +++ b/Documentation/translations/zh_TW/admin-guide/tainted-kernels.rst @@ -0,0 +1,161 @@ +.. SPDX-License-Identifier: GPL-2.0 + +.. include:: ../disclaimer-zh_TW.rst + +:Original: :doc:`../../../admin-guide/tainted-kernels` + +:譯者: + + 吳想成 Wu XiangCheng + 胡皓文 Hu Haowen + +受汙染的內核 +------------- + +當發生一些在稍後調查問題時可能相關的事件時，內核會將自己標記爲「受汙染 +（tainted）」的。不用太過擔心，大多數情況下運行受汙染的內核沒有問題；這些信息 +主要在有人想調查某個問題時才有意義的，因爲問題的真正原因可能是導致內核受汙染 +的事件。這就是爲什麼來自受汙染內核的缺陷報告常常被開發人員忽略，因此請嘗試用 +未受汙染的內核重現問題。 + +請注意，即使在您消除導致汙染的原因（亦即卸載專有內核模塊）之後，內核仍將保持 +汙染狀態，以表示內核仍然不可信。這也是爲什麼內核在注意到內部問題（「kernel +bug」）、可恢復錯誤（「kernel oops」）或不可恢復錯誤（「kernel panic」）時會列印 +受汙染狀態，並將有關此的調試信息寫入日誌 ``dmesg`` 輸出。也可以通過 +``/proc/`` 中的文件在運行時檢查受汙染的狀態。 + + +BUG、Oops或Panics消息中的汙染標誌 +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +在頂部以「CPU:」開頭的一行中可以找到受汙染的狀態；內核是否受到汙染和原因會顯示 +在進程ID（「PID:」）和觸發事件命令的縮寫名稱（「Comm:」）之後:: + + BUG: unable to handle kernel NULL pointer dereference at 0000000000000000 + Oops: 0002 [#1] SMP PTI + CPU: 0 PID: 4424 Comm: insmod Tainted: P W O 4.20.0-0.rc6.fc30 #1 + Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011 + RIP: 0010:my_oops_init+0x13/0x1000 [kpanic] + [...] + +如果內核在事件發生時沒有被汙染，您將在那裡看到「Not-tainted:」；如果被汙染，那 +麼它將是「Tainted:」以及字母或空格。在上面的例子中，它看起來是這樣的:: + + Tainted: P W O + +下表解釋了這些字符的含義。在本例中，由於加載了專有模塊（ ``P`` ），出現了 +警告（ ``W`` ），並且加載了外部構建的模塊（ ``O`` ），所以內核早些時候受到 +了汙染。要解碼其他字符，請使用下表。 + + +解碼運行時的汙染狀態 +~~~~~~~~~~~~~~~~~~~~~ + +在運行時，您可以通過讀取 ``cat /proc/sys/kernel/tainted`` 來查詢受汙染狀態。 +如果返回 ``0`` ，則內核沒有受到汙染；任何其他數字都表示受到汙染的原因。解碼 +這個數字的最簡單方法是使用腳本 ``tools/debugging/kernel-chktaint`` ，您的 +發行版可能會將其作爲名爲 ``linux-tools`` 或 ``kernel-tools`` 的包的一部分提 +供；如果沒有，您可以從 +`git.kernel.org `_ +網站下載此腳本並用 ``sh kernel-chktaint`` 執行，它會在上面引用的日誌中有類似 +語句的機器上列印這樣的內容:: + + Kernel is Tainted for following reasons: + * Proprietary module was loaded (#0) + * Kernel issued warning (#9) + * Externally-built ('out-of-tree') module was loaded (#12) + See Documentation/admin-guide/tainted-kernels.rst in the Linux kernel or + https://www.kernel.org/doc/html/latest/admin-guide/tainted-kernels.html for + a more details explanation of the various taint flags. + Raw taint value as int/string: 4609/'P W O ' + +你也可以試著自己解碼這個數字。如果內核被汙染的原因只有一個，那麼這很簡單， +在本例中您可以通過下表找到數字。如果你需要解碼有多個原因的數字，因爲它是一 +個位域（bitfield），其中每個位表示一個特定類型的汙染的存在或不存在，最好讓 +前面提到的腳本來處理。但是如果您需要快速看一下，可以使用這個shell命令來檢查 +設置了哪些位:: + + $ for i in $(seq 18); do echo $(($i-1)) $(($(cat /proc/sys/kernel/tainted)>>($i-1)&1));done + +汙染狀態代碼表 +~~~~~~~~~~~~~~~ + +=== ===== ====== ======================================================== + 位 日誌 數字 內核被汙染的原因 +=== ===== ====== ======================================================== + 0 G/P 1 已加載專用模塊 + 1 _/F 2 模塊被強制加載 + 2 _/S 4 內核運行在不合規範的系統上 + 3 _/R 8 模塊被強制卸載 + 4 _/M 16 處理器報告了機器檢測異常（MCE） + 5 _/B 32 引用了錯誤的頁或某些意外的頁標誌 + 6 _/U 64 用戶空間應用程式請求的汙染 + 7 _/D 128 內核最近死機了，即曾出現OOPS或BUG + 8 _/A 256 ACPI表被用戶覆蓋 + 9 _/W 512 內核發出警告 + 10 _/C 1024 已加載staging驅動程序 + 11 _/I 2048 已應用平台固件缺陷的解決方案 + 12 _/O 4096 已加載外部構建（「樹外」）模塊 + 13 _/E 8192 已加載未簽名的模塊 + 14 _/L 16384 發生軟鎖定 + 15 _/K 32768 內核已實時打補丁 + 16 _/X 65536 備用汙染，爲發行版定義並使用 + 17 _/T 131072 內核是用結構隨機化插件構建的 +=== ===== ====== ======================================================== + +註：字符 ``_`` 表示空白，以便於閱讀表。 + +汙染的更詳細解釋 +~~~~~~~~~~~~~~~~~ + + 0) ``G`` 加載的所有模塊都有GPL或兼容許可證， ``P`` 加載了任何專有模塊。 + 沒有MODULE_LICENSE（模塊許可證）或MODULE_LICENSE未被insmod認可爲GPL + 兼容的模塊被認爲是專有的。 + + + 1) ``F`` 任何模塊被 ``insmod -f`` 強制加載， ``' '`` 所有模塊正常加載。 + + 2) ``S`` 內核運行在不合規範的處理器或系統上：硬體已運行在不受支持的配置中， + 因此無法保證正確執行。內核將被汙染，例如： + + - 在x86上：PAE是通過intel CPU（如Pentium M）上的forcepae強制執行的，這些 + CPU不報告PAE，但可能有功能實現，SMP內核在非官方支持的SMP Athlon CPU上 + 運行，MSR被暴露到用戶空間中。 + - 在arm上：在某些CPU（如Keystone 2）上運行的內核，沒有啓用某些內核特性。 + - 在arm64上：CPU之間存在不匹配的硬體特性，引導加載程序以不同的模式引導CPU。 + - 某些驅動程序正在被用在不受支持的體系結構上（例如x86_64以外的其他系統 + 上的scsi/snic，非x86/x86_64/itanium上的scsi/ips，已經損壞了arm64上 + irqchip/irq-gic的固件設置…）。 + + 3) ``R`` 模塊被 ``rmmod -f`` 強制卸載， ``' '`` 所有模塊都正常卸載。 + + 4) ``M`` 任何處理器報告了機器檢測異常， ``' '`` 未發生機器檢測異常。 + + 5) ``B`` 頁面釋放函數發現錯誤的頁面引用或某些意外的頁面標誌。這表示硬體問題 + 或內核錯誤；日誌中應該有其他信息指示發生此汙染的原因。 + + 6) ``U`` 用戶或用戶應用程式特意請求設置受汙染標誌，否則應爲 ``' '`` 。 + + 7) ``D`` 內核最近死機了，即出現了OOPS或BUG。 + + 8) ``A`` ACPI表被重寫。 + + 9) ``W`` 內核之前已發出過警告（儘管有些警告可能會設置更具體的汙染標誌）。 + + 10) ``C`` 已加載staging驅動程序。 + + 11) ``I`` 內核正在處理平台固件（BIOS或類似軟體）中的嚴重錯誤。 + + 12) ``O`` 已加載外部構建（「樹外」）模塊。 + + 13) ``E`` 在支持模塊簽名的內核中加載了未簽名的模塊。 + + 14) ``L`` 系統上先前發生過軟鎖定。 + + 15) ``K`` 內核已經實時打了補丁。 + + 16) ``X`` 備用汙染，由Linux發行版定義和使用。 + + 17) ``T`` 內核構建時使用了randstruct插件，它可以有意生成非常不尋常的內核結構 + 布局（甚至是性能病態的布局），這在調試時非常有用。於構建時設置。 + diff --git a/Documentation/translations/zh_TW/admin-guide/unicode.rst b/Documentation/translations/zh_TW/admin-guide/unicode.rst new file mode 100644 index 000000000000..720875be5ef8 --- /dev/null +++ b/Documentation/translations/zh_TW/admin-guide/unicode.rst @@ -0,0 +1,174 @@ +.. SPDX-License-Identifier: GPL-2.0 + +.. include:: ../disclaimer-zh_TW.rst + +:Original: Documentation/admin-guide/unicode.rst + +:譯者: + + 吳想成 Wu XiangCheng + 胡皓文 Hu Haowen + +Unicode（統一碼）支持 +====================== + + （英文版）上次更新：2005-01-17，版本號 1.4 + +此文檔由H. Peter Anvin 管理，是Linux註冊名稱與編號管理局 +（Linux Assigned Names And Numbers Authority，LANANA）項目的一部分。 +現行版本請見： + + http://www.lanana.org/docs/unicode/admin-guide/unicode.rst + +簡介 +----- + +Linux內核代碼已被重寫以使用Unicode來將字符映射到字體。下載一個Unicode到字體 +（Unicode-to-font）表，八位字符集與UTF-8模式都將改用此字體來顯示。 + +這微妙地改變了八位字符表的語義。現在的四個字符表是： + +=============== =============================== ================ +映射代號 映射名稱 Escape代碼 (G0) +=============== =============================== ================ +LAT1_MAP Latin-1 (ISO 8859-1) ESC ( B +GRAF_MAP DEC VT100 pseudographics ESC ( 0 +IBMPC_MAP IBM code page 437 ESC ( U +USER_MAP User defined ESC ( K +=============== =============================== ================ + +特別是 ESC ( U 不再是「直通字體」，因爲字體可能與IBM字符集完全不同。 +例如，即使加載了一個Latin-1字體，也允許使用塊圖形（block graphics）。 + +請注意，儘管這些代碼與ISO 2022類似，但這些代碼及其用途都與ISO 2022不匹配； +Linux有兩個八位代碼（G0和G1），而ISO 2022有四個七位代碼（G0-G3）。 + +根據Unicode標準/ISO 10646，U+F000到U+F8FF被保留用於作業系統範圍內的分配 +（Unicode標準將其稱爲「團體區域（Corporate Zone）」，因爲這對於Linux是不準確 +的，所以我們稱之爲「Linux區域」）。選擇U+F000作爲起點，因爲它允許直接映射 +區域以2的大倍數開始（以防需要1024或2048個字符的字體）。這就留下U+E000到 +U+EFFF作爲最終用戶區。 + +[v1.2]：Unicodes範圍從U+F000到U+F7FF已經被硬編碼爲直接映射到加載的字體， +繞過了翻譯表。用戶定義的映射現在默認爲U+F000到U+F0FF，模擬前述行爲。實際上， +此範圍可能較短；例如，vgacon只能處理256字符（U+F000..U+F0FF）或512字符 +（U+F000..U+F1FF）字體。 + +Linux 區域中定義的實際字符 +--------------------------- + +此外，還定義了Unicode 1.1.4中不存在的以下字符；這些字符由DEC VT圖形映射使用。 +[v1.2]此用法已過時，不應再使用；請參見下文。 + +====== ====================================== +U+F800 DEC VT GRAPHICS HORIZONTAL LINE SCAN 1 +U+F801 DEC VT GRAPHICS HORIZONTAL LINE SCAN 3 +U+F803 DEC VT GRAPHICS HORIZONTAL LINE SCAN 7 +U+F804 DEC VT GRAPHICS HORIZONTAL LINE SCAN 9 +====== ====================================== + +DEC VT220使用6x10字符矩陣，這些字符在DEC VT圖形字符集中形成一個平滑的過渡。 +我省略了掃描5行，因爲它也被用作塊圖形字符，因此被編碼爲U+2500 FORMS LIGHT +HORIZONTAL。 + +[v1.3]：這些字符已正式添加到Unicode 3.2.0中；它們在U+23BA、U+23BB、U+23BC、 +U+23BD處添加。Linux現在使用新值。 + +[v1.2]：添加了以下字符來表示常見的鍵盤符號，這些符號不太可能被添加到Unicode +中，因爲它們非常討厭地取決於特定供應商。當然，這是糟糕設計的一個好例子。 + +====== ====================================== +U+F810 KEYBOARD SYMBOL FLYING FLAG +U+F811 KEYBOARD SYMBOL PULLDOWN MENU +U+F812 KEYBOARD SYMBOL OPEN APPLE +U+F813 KEYBOARD SYMBOL SOLID APPLE +====== ====================================== + +克林貢（Klingon）語支持 +------------------------ + +1996年，Linux是世界上第一個添加對人工語言克林貢支持的作業系統，克林貢是由 +Marc Okrand爲《星際迷航》電視連續劇創造的。這種編碼後來被徵募Unicode註冊表 +（ConScript Unicode Registry，CSUR）採用，並建議（但最終被拒絕）納入Unicode +平面一。不過，它仍然是Linux區域中的Linux/CSUR私有分配。 + +這種編碼已經得到克林貢語言研究所（Klingon Language Institute）的認可。 +有關更多信息，請聯繫他們： + + http://www.kli.org/ + +由於Linux CZ開頭部分的字符大多是dingbats/symbols/forms類型，而且這是一種 +語言，因此根據標準Unicode慣例，我將它放置在16單元的邊界上。 + +.. note:: + + 這個範圍現在由徵募Unicode註冊表正式管理。規範性引用文件爲： + + https://www.evertype.com/standards/csur/klingon.html + +克林貢語有一個26個字符的字母表，一個10位數的位置數字書寫系統，從左到右 +，從上到下書寫。 + +克林貢字母的幾種字形已經被提出。但是由於這組符號看起來始終是一致的，只有實際 +的形狀不同，因此按照標準Unicode慣例，這些差異被認爲是字體變體。 + +====== ======================================================= +U+F8D0 KLINGON LETTER A +U+F8D1 KLINGON LETTER B +U+F8D2 KLINGON LETTER CH +U+F8D3 KLINGON LETTER D +U+F8D4 KLINGON LETTER E +U+F8D5 KLINGON LETTER GH +U+F8D6 KLINGON LETTER H +U+F8D7 KLINGON LETTER I +U+F8D8 KLINGON LETTER J +U+F8D9 KLINGON LETTER L +U+F8DA KLINGON LETTER M +U+F8DB KLINGON LETTER N +U+F8DC KLINGON LETTER NG +U+F8DD KLINGON LETTER O +U+F8DE KLINGON LETTER P +U+F8DF KLINGON LETTER Q + - Written in standard Okrand Latin transliteration +U+F8E0 KLINGON LETTER QH + - Written in standard Okrand Latin transliteration +U+F8E1 KLINGON LETTER R +U+F8E2 KLINGON LETTER S +U+F8E3 KLINGON LETTER T +U+F8E4 KLINGON LETTER TLH +U+F8E5 KLINGON LETTER U +U+F8E6 KLINGON LETTER V +U+F8E7 KLINGON LETTER W +U+F8E8 KLINGON LETTER Y +U+F8E9 KLINGON LETTER GLOTTAL STOP + +U+F8F0 KLINGON DIGIT ZERO +U+F8F1 KLINGON DIGIT ONE +U+F8F2 KLINGON DIGIT TWO +U+F8F3 KLINGON DIGIT THREE +U+F8F4 KLINGON DIGIT FOUR +U+F8F5 KLINGON DIGIT FIVE +U+F8F6 KLINGON DIGIT SIX +U+F8F7 KLINGON DIGIT SEVEN +U+F8F8 KLINGON DIGIT EIGHT +U+F8F9 KLINGON DIGIT NINE + +U+F8FD KLINGON COMMA +U+F8FE KLINGON FULL STOP +U+F8FF KLINGON SYMBOL FOR EMPIRE +====== ======================================================= + +其他虛構和人工字母 +------------------- + +自從分配了克林貢Linux Unicode塊之後，John Cowan +和 Michael Everson 建立了一個虛構和人工字母的註冊表。 +徵募Unicode註冊表請訪問： + + https://www.evertype.com/standards/csur/ + +所使用的範圍位於最終用戶區域的低端，因此無法進行規範化分配，但建議希望對虛構 +字母進行編碼的人員使用這些代碼，以實現互操作性。對於克林貢語，CSUR採用了Linux +編碼。CSUR的人正在推動將Tengwar和Cirth添加到Unicode平面一；將克林貢添加到 +Unicode平面一被拒絕，因此上述編碼仍然是官方的。 + diff --git a/Documentation/translations/zh_TW/disclaimer-zh_TW.rst b/Documentation/translations/zh_TW/disclaimer-zh_TW.rst new file mode 100644 index 000000000000..f4cf87d03dc5 --- /dev/null +++ b/Documentation/translations/zh_TW/disclaimer-zh_TW.rst @@ -0,0 +1,11 @@ +:orphan: + +.. warning:: + 此文件的目的是爲讓中文讀者更容易閱讀和理解，而不是作爲一個分支。因此， + 如果您對此文件有任何意見或改動，請先嘗試更新原始英文文件。如果要更改或 + 修正某處翻譯文件，請將意見或補丁發送給維護者（聯繫方式見下）。 + +.. note:: + 如果您發現本文檔與原始文件有任何不同或者有翻譯問題，請聯繫該文件的譯者， + 或者發送電子郵件給胡皓文以獲取幫助：。 + diff --git a/Documentation/translations/zh_TW/gpio.txt b/Documentation/translations/zh_TW/gpio.txt new file mode 100644 index 000000000000..e3c076dd75a5 --- /dev/null +++ b/Documentation/translations/zh_TW/gpio.txt @@ -0,0 +1,651 @@ +Chinese translated version of Documentation/admin-guide/gpio + +If you have any comment or update to the content, please contact the +original document maintainer directly. However, if you have a problem +communicating in English you can also ask the Chinese maintainer for +help. Contact the Chinese maintainer if this translation is outdated +or if there is a problem with the translation. + +Maintainer: Grant Likely + Linus Walleij +Traditional Chinese maintainer: Hu Haowen +--------------------------------------------------------------------- +Documentation/admin-guide/gpio 的繁體中文翻譯 + +如果想評論或更新本文的內容，請直接聯繫原文檔的維護者。如果你使用英文 +交流有困難的話，也可以向繁體中文版維護者求助。如果本翻譯更新不及時或 +者翻譯存在問題，請聯繫繁體中文版維護者。 + +英文版維護者： Grant Likely + Linus Walleij +繁體中文版維護者： 胡皓文 Hu Haowen +繁體中文版翻譯者： 胡皓文 Hu Haowen +繁體中文版校譯者： 胡皓文 Hu Haowen + +以下爲正文 +--------------------------------------------------------------------- +GPIO 接口 + +本文檔提供了一個在Linux下訪問GPIO的公約概述。 + +這些函數以 gpio_* 作爲前綴。其他的函數不允許使用這樣的前綴或相關的 +__gpio_* 前綴。 + + +什麼是GPIO? +========== +"通用輸入/輸出口"(GPIO)是一個靈活的由軟體控制的數位訊號。他們可 +由多種晶片提供,且對於從事嵌入式和定製硬體的 Linux 開發者來說是 +比較熟悉。每個GPIO 都代表一個連接到特定引腳或球柵陣列(BGA)封裝中 +「球珠」的一個位。電路板原理圖顯示了 GPIO 與外部硬體的連接關係。 +驅動可以編寫成通用代碼，以使板級啓動代碼可傳遞引腳配置數據給驅動。 + +片上系統 (SOC) 處理器對 GPIO 有很大的依賴。在某些情況下,每個 +非專用引腳都可配置爲 GPIO,且大多數晶片都最少有一些 GPIO。 +可編程邏輯器件(類似 FPGA) 可以方便地提供 GPIO。像電源管理和 +音頻編解碼器這樣的多功能晶片經常留有一些這樣的引腳來幫助那些引腳 +匱乏的 SOC。同時還有通過 I2C 或 SPI 串行總線連接的「GPIO擴展器」 +晶片。大多數 PC 的南橋有一些擁有 GPIO 能力的引腳 (只有BIOS +固件才知道如何使用他們)。 + +GPIO 的實際功能因系統而異。通常用法有: + + - 輸出值可寫 (高電平=1，低電平=0)。一些晶片也有如何驅動這些值的選項, + 例如只允許輸出一個值、支持「線與」及其他取值類似的模式(值得注意的是 + 「開漏」信號) + + - 輸入值可讀(1、0)。一些晶片支持引腳在配置爲「輸出」時回讀，這對於類似 + 「線與」的情況(以支持雙向信號)是非常有用的。GPIO 控制器可能有輸入 + 去毛刺/消抖邏輯,這有時需要軟體控制。 + + - 輸入通常可作爲 IRQ 信號,一般是沿觸發,但有時是電平觸發。這樣的 IRQ + 可能配置爲系統喚醒事件,以將系統從低功耗狀態下喚醒。 + + - 通常一個 GPIO 根據不同產品電路板的需求,可以配置爲輸入或輸出,也有僅 + 支持單向的。 + + - 大部分 GPIO 可以在持有自旋鎖時訪問,但是通常由串行總線擴展的 GPIO + 不允許持有自旋鎖。但某些系統也支持這種類型。 + +對於給定的電路板,每個 GPIO 都用於某個特定的目的,如監控 MMC/SD 卡的 +插入/移除、檢測卡的防寫狀態、驅動 LED、配置收發器、模擬串行總線、 +復位硬體看門狗、感知開關狀態等等。 + + +GPIO 公約 +========= +注意,這個叫做「公約」，因爲這不是強制性的，不遵循這個公約是無傷大雅的， +因爲此時可移植性並不重要。GPIO 常用於板級特定的電路邏輯,甚至可能 +隨著電路板的版本而改變，且不可能在不同走線的電路板上使用。僅有在少數 +功能上才具有可移植性，其他功能是平台特定。這也是由於「膠合」的邏輯造成的。 + +此外，這不需要任何的執行框架，只是一個接口。某個平台可能通過一個簡單地 +訪問晶片寄存器的內聯函數來實現它，其他平台可能通過委託一系列不同的GPIO +控制器的抽象函數來實現它。(有一些可選的代碼能支持這種策略的實現,本文檔 +後面會介紹，但作爲 GPIO 接口的客戶端驅動程序必須與它的實現無關。) + +也就是說,如果在他們的平台上支持這個公約，驅動應儘可能的使用它。同時，平台 +必須在 Kconfig 中選擇 ARCH_REQUIRE_GPIOLIB 或者 ARCH_WANT_OPTIONAL_GPIOLIB +選項。那些調用標準 GPIO 函數的驅動應該在 Kconfig 入口中聲明依賴GENERIC_GPIO。 +當驅動包含文件: + + #include + +則 GPIO 函數是可用,無論是「真實代碼」還是經優化過的語句。如果你遵守 +這個公約，當你的代碼完成後，對其他的開發者來說會更容易看懂和維護。 + +注意，這些操作包含所用平台的 I/O 屏障代碼，驅動無須顯式地調用他們。 + + +標識 GPIO +--------- +GPIO 是通過無符號整型來標識的,範圍是 0 到 MAX_INT。保留「負」數 +用於其他目的,例如標識信號「在這個板子上不可用」或指示錯誤。未接觸底層 +硬體的代碼會忽略這些整數。 + +平台會定義這些整數的用法,且通常使用 #define 來定義 GPIO，這樣 +板級特定的啓動代碼可以直接關聯相應的原理圖。相對來說，驅動應該僅使用 +啓動代碼傳遞過來的 GPIO 編號，使用 platform_data 保存板級特定 +引腳配置數據 (同時還有其他須要的板級特定數據)，避免可能出現的問題。 + +例如一個平台使用編號 32-159 來標識 GPIO,而在另一個平台使用編號0-63 +標識一組 GPIO 控制器,64-79標識另一類 GPIO 控制器,且在一個含有 +FPGA 的特定板子上使用 80-95。編號不一定要連續,那些平台中，也可以 +使用編號2000-2063來標識一個 I2C 接口的 GPIO 擴展器中的 GPIO。 + +如果你要初始化一個帶有無效 GPIO 編號的結構體,可以使用一些負編碼 +(如"-EINVAL")，那將使其永遠不會是有效。來測試這樣一個結構體中的編號 +是否關聯一個 GPIO，你可使用以下斷言: + + int gpio_is_valid(int number); + +如果編號不存在，則請求和釋放 GPIO 的函數將拒絕執行相關操作(見下文)。 +其他編號也可能被拒絕,比如一個編號可能存在，但暫時在給定的電路上不可用。 + +一個平台是否支持多個 GPIO 控制器爲平台特定的實現問題，就像是否可以 +在 GPIO 編號空間中有「空洞」和是否可以在運行時添加新的控制器一樣。 +這些問題會影響其他事情，包括相鄰的 GPIO 編號是否存在等。 + +使用 GPIO +--------- +對於一個 GPIO，系統應該做的第一件事情就是通過 gpio_request() +函數分配它，見下文。 + +接下來是設置I/O方向，這通常是在板級啓動代碼中爲所使用的 GPIO 設置 +platform_device 時完成。 + + /* 設置爲輸入或輸出, 返回 0 或負的錯誤代碼 */ + int gpio_direction_input(unsigned gpio); + int gpio_direction_output(unsigned gpio, int value); + +返回值爲零代表成功，否則返回一個負的錯誤代碼。這個返回值需要檢查，因爲 +get/set(獲取/設置)函數調用沒法返回錯誤,且有可能是配置錯誤。通常， +你應該在進程上下文中調用這些函數。然而,對於自旋鎖安全的 GPIO，在板子 +啓動的早期、進程啓動前使用他們也是可以的。 + +對於作爲輸出的 GPIO，爲其提供初始輸出值，對於避免在系統啓動期間出現 +信號毛刺是很有幫助的。 + +爲了與傳統的 GPIO 接口兼容, 在設置一個 GPIO 方向時，如果它還未被申請， +則隱含了申請那個 GPIO 的操作(見下文)。這種兼容性正在從可選的 gpiolib +框架中移除。 + +如果這個 GPIO 編碼不存在，或者特定的 GPIO 不能用於那種模式，則方向 +設置可能失敗。依賴啓動固件來正確地設置方向通常是一個壞主意，因爲它可能 +除了啓動Linux，並沒有做更多的驗證工作。(同理, 板子的啓動代碼可能需要 +將這個復用的引腳設置爲 GPIO，並正確地配置上拉/下拉電阻。) + + +訪問自旋鎖安全的 GPIO +------------------- +大多數 GPIO 控制器可以通過內存讀/寫指令來訪問。這些指令不會休眠,可以 +安全地在硬(非線程)中斷例程和類似的上下文中完成。 + +對於那些用 gpio_cansleep()測試總是返回失敗的 GPIO(見下文)，使用 +以下的函數訪問: + + /* GPIO 輸入:返回零或非零 */ + int gpio_get_value(unsigned gpio); + + /* GPIO 輸出 */ + void gpio_set_value(unsigned gpio, int value); + +GPIO值是布爾值，零表示低電平，非零表示高電平。當讀取一個輸出引腳的值時， +返回值應該是引腳上的值。這個值不總是和輸出值相符，因爲存在開漏輸出信號和 +輸出延遲問題。 + +以上的 get/set 函數無錯誤返回值，因爲之前 gpio_direction_*()應已檢查過 +其是否爲「無效GPIO」。此外，還需要注意的是並不是所有平台都可以從輸出引腳 +中讀取數據，對於不能讀取的引腳應總返回零。另外，對那些在原子上下文中無法 +安全訪問的 GPIO (譯者註：因爲訪問可能導致休眠)使用這些函數是不合適的 +(見下文)。 + +在 GPIO 編號(還有輸出、值)爲常數的情況下,鼓勵通過平台特定的實現來優化 +這兩個函數來訪問 GPIO 值。這種情況(讀寫一個硬體寄存器)下只需要幾條指令 +是很正常的,且無須自旋鎖。這種優化函數比起那些在子程序上花費許多指令的 +函數可以使得模擬接口(譯者注:例如 GPIO 模擬 I2C、1-wire 或 SPI)的 +應用(在空間和時間上都)更具效率。 + + +訪問可能休眠的 GPIO +----------------- +某些 GPIO 控制器必須通過基於總線(如 I2C 或 SPI)的消息訪問。讀或寫這些 +GPIO 值的命令需要等待其信息排到隊首才發送命令，再獲得其反饋。期間需要 +休眠，這不能在 IRQ 例程(中斷上下文)中執行。 + +支持此類 GPIO 的平台通過以下函數返回非零值來區分出這種 GPIO。(此函數需要 +一個之前通過 gpio_request 分配到的有效 GPIO 編號): + + int gpio_cansleep(unsigned gpio); + +爲了訪問這種 GPIO,內核定義了一套不同的函數: + + /* GPIO 輸入:返回零或非零 ,可能會休眠 */ + int gpio_get_value_cansleep(unsigned gpio); + + /* GPIO 輸出,可能會休眠 */ + void gpio_set_value_cansleep(unsigned gpio, int value); + + +訪問這樣的 GPIO 需要一個允許休眠的上下文，例如線程 IRQ 處理例程，並用以上的 +訪問函數替換那些沒有 cansleep()後綴的自旋鎖安全訪問函數。 + +除了這些訪問函數可能休眠，且它們操作的 GPIO 不能在硬體 IRQ 處理例程中訪問的 +事實，這些處理例程實際上和自旋鎖安全的函數是一樣的。 + +** 除此之外 ** 調用設置和配置此類 GPIO 的函數也必須在允許休眠的上下文中， +因爲它們可能也需要訪問 GPIO 控制器晶片: (這些設置函數通常在板級啓動代碼或者 +驅動探測/斷開代碼中，所以這是一個容易滿足的約束條件。) + + gpio_direction_input() + gpio_direction_output() + gpio_request() + +## gpio_request_one() +## gpio_request_array() +## gpio_free_array() + + gpio_free() + gpio_set_debounce() + + + +聲明和釋放 GPIO +---------------------------- +爲了有助於捕獲系統配置錯誤,定義了兩個函數。 + + /* 申請 GPIO, 返回 0 或負的錯誤代碼. + * 非空標籤可能有助於診斷. + */ + int gpio_request(unsigned gpio, const char *label); + + /* 釋放之前聲明的 GPIO */ + void gpio_free(unsigned gpio); + +將無效的 GPIO 編碼傳遞給 gpio_request()會導致失敗，申請一個已使用這個 +函數聲明過的 GPIO 也會失敗。gpio_request()的返回值必須檢查。你應該在 +進程上下文中調用這些函數。然而,對於自旋鎖安全的 GPIO,在板子啓動的早期、 +進入進程之前是可以申請的。 + +這個函數完成兩個基本的目標。一是標識那些實際上已作爲 GPIO 使用的信號線， +這樣便於更好地診斷;系統可能需要服務幾百個可用的 GPIO，但是對於任何一個 +給定的電路板通常只有一些被使用。另一個目的是捕獲衝突，查明錯誤:如兩個或 +更多驅動錯誤地認爲他們已經獨占了某個信號線,或是錯誤地認爲移除一個管理著 +某個已激活信號的驅動是安全的。也就是說，申請 GPIO 的作用類似一種鎖機制。 + +某些平台可能也使用 GPIO 作爲電源管理激活信號(例如通過關閉未使用晶片區和 +簡單地關閉未使用時鐘)。 + +對於 GPIO 使用 pinctrl 子系統已知的引腳，子系統應該被告知其使用情況； +一個 gpiolib 驅動的 .request()操作應調用 pinctrl_gpio_request()， +而 gpiolib 驅動的 .free()操作應調用 pinctrl_gpio_free()。pinctrl +子系統允許 pinctrl_gpio_request()在某個引腳或引腳組以復用形式「屬於」 +一個設備時都成功返回。 + +任何須將 GPIO 信號導向適當引腳的引腳復用硬體的編程應該發生在 GPIO +驅動的 .direction_input()或 .direction_output()函數中，以及 +任何輸出 GPIO 值的設置之後。這樣可使從引腳特殊功能到 GPIO 的轉換 +不會在引腳產生毛刺波形。有時當用一個 GPIO 實現其信號驅動一個非 GPIO +硬體模塊的解決方案時，就需要這種機制。 + +某些平台允許部分或所有 GPIO 信號使用不同的引腳。類似的，GPIO 或引腳的 +其他方面也需要配置，如上拉/下拉。平台軟體應該在對這些 GPIO 調用 +gpio_request()前將這類細節配置好，例如使用 pinctrl 子系統的映射表， +使得 GPIO 的用戶無須關注這些細節。 + +還有一個值得注意的是在釋放 GPIO 前，你必須停止使用它。 + + +注意:申請一個 GPIO 並沒有以任何方式配置它，只不過標識那個 GPIO 處於使用 +狀態。必須有另外的代碼來處理引腳配置(如控制 GPIO 使用的引腳、上拉/下拉)。 +考慮到大多數情況下聲明 GPIO 之後就會立即配置它們,所以定義了以下三個輔助函數: + + /* 申請一個 GPIO 信號, 同時通過特定的'flags'初始化配置, + * 其他和 gpio_request()的參數和返回值相同 + * + */ + int gpio_request_one(unsigned gpio, unsigned long flags, const char *label); + + /* 在單個函數中申請多個 GPIO + */ + int gpio_request_array(struct gpio *array, size_t num); + + /* 在單個函數中釋放多個 GPIO + */ + void gpio_free_array(struct gpio *array, size_t num); + +這裡 'flags' 當前定義可指定以下屬性: + + * GPIOF_DIR_IN - 配置方向爲輸入 + * GPIOF_DIR_OUT - 配置方向爲輸出 + + * GPIOF_INIT_LOW - 在作爲輸出時,初始值爲低電平 + * GPIOF_INIT_HIGH - 在作爲輸出時,初始值爲高電平 + * GPIOF_OPEN_DRAIN - gpio引腳爲開漏信號 + * GPIOF_OPEN_SOURCE - gpio引腳爲源極開路信號 + + * GPIOF_EXPORT_DIR_FIXED - 將 gpio 導出到 sysfs，並保持方向 + * GPIOF_EXPORT_DIR_CHANGEABLE - 同樣是導出, 但允許改變方向 + +因爲 GPIOF_INIT_* 僅有在配置爲輸出的時候才存在,所以有效的組合爲: + + * GPIOF_IN - 配置爲輸入 + * GPIOF_OUT_INIT_LOW - 配置爲輸出,並初始化爲低電平 + * GPIOF_OUT_INIT_HIGH - 配置爲輸出,並初始化爲高電平 + +當設置 flag 爲 GPIOF_OPEN_DRAIN 時，則假設引腳是開漏信號。這樣的引腳 +將不會在輸出模式下置1。這樣的引腳需要連接上拉電阻。通過使能這個標誌，gpio庫 +將會在被要求輸出模式下置1時將引腳變爲輸入狀態來使引腳置高。引腳在輸出模式下 +通過置0使其輸出低電平。 + +當設置 flag 爲 GPIOF_OPEN_SOURCE 時，則假設引腳爲源極開路信號。這樣的引腳 +將不會在輸出模式下置0。這樣的引腳需要連接下拉電阻。通過使能這個標誌，gpio庫 +將會在被要求輸出模式下置0時將引腳變爲輸入狀態來使引腳置低。引腳在輸出模式下 +通過置1使其輸出高電平。 + +將來這些標誌可能擴展到支持更多的屬性。 + +更進一步,爲了更簡單地聲明/釋放多個 GPIO,'struct gpio'被引進來封裝所有 +這三個領域: + + struct gpio { + unsigned gpio; + unsigned long flags; + const char *label; + }; + +一個典型的用例: + + static struct gpio leds_gpios[] = { + { 32, GPIOF_OUT_INIT_HIGH, "Power LED" }, /* 默認開啓 */ + { 33, GPIOF_OUT_INIT_LOW, "Green LED" }, /* 默認關閉 */ + { 34, GPIOF_OUT_INIT_LOW, "Red LED" }, /* 默認關閉 */ + { 35, GPIOF_OUT_INIT_LOW, "Blue LED" }, /* 默認關閉 */ + { ... }, + }; + + err = gpio_request_one(31, GPIOF_IN, "Reset Button"); + if (err) + ... + + err = gpio_request_array(leds_gpios, ARRAY_SIZE(leds_gpios)); + if (err) + ... + + gpio_free_array(leds_gpios, ARRAY_SIZE(leds_gpios)); + + +GPIO 映射到 IRQ +-------------------- +GPIO 編號是無符號整數;IRQ 編號也是。這些構成了兩個邏輯上不同的命名空間 +(GPIO 0 不一定使用 IRQ 0)。你可以通過以下函數在它們之間實現映射: + + /* 映射 GPIO 編號到 IRQ 編號 */ + int gpio_to_irq(unsigned gpio); + + /* 映射 IRQ 編號到 GPIO 編號 (儘量避免使用) */ + int irq_to_gpio(unsigned irq); + +它們的返回值爲對應命名空間的相關編號，或是負的錯誤代碼(如果無法映射)。 +(例如,某些 GPIO 無法做爲 IRQ 使用。)以下的編號錯誤是未經檢測的:使用一個 +未通過 gpio_direction_input()配置爲輸入的 GPIO 編號，或者使用一個 +並非來源於gpio_to_irq()的 IRQ 編號。 + +這兩個映射函數可能會在信號編號的加減計算過程上花些時間。它們不可休眠。 + +gpio_to_irq()返回的非錯誤值可以傳遞給 request_irq()或者 free_irq()。 +它們通常通過板級特定的初始化代碼存放到平台設備的 IRQ 資源中。注意:IRQ +觸發選項是 IRQ 接口的一部分，如 IRQF_TRIGGER_FALLING，系統喚醒能力 +也是如此。 + +irq_to_gpio()返回的非錯誤值大多數通常可以被 gpio_get_value()所使用， +比如在 IRQ 是沿觸發時初始化或更新驅動狀態。注意某些平台不支持反映射,所以 +你應該儘量避免使用它。 + + +模擬開漏信號 +---------------------------- +有時在只有低電平信號作爲實際驅動結果(譯者注:多個輸出連接於一點，邏輯電平 +結果爲所有輸出的邏輯與)的時候,共享的信號線需要使用「開漏」信號。(該術語 +適用於 CMOS 管；而 TTL 用「集電極開路」。)一個上拉電阻使信號爲高電平。這 +有時被稱爲「線與」。實際上，從負邏輯(低電平爲真)的角度來看，這是一個「線或」。 + +一個開漏信號的常見例子是共享的低電平使能 IRQ 信號線。此外,有時雙向數據總線 +信號也使用漏極開路信號。 + +某些 GPIO 控制器直接支持開漏輸出，還有許多不支持。當你需要開漏信號，但 +硬體又不直接支持的時候，一個常用的方法是用任何即可作輸入也可作輸出的 GPIO +引腳來模擬: + + LOW: gpio_direction_output(gpio, 0) ... 這代碼驅動信號並覆蓋 + 上拉配置。 + + HIGH: gpio_direction_input(gpio) ... 這代碼關閉輸出,所以上拉電阻 + (或其他的一些器件)控制了信號。 + +如果你將信號線「驅動」爲高電平，但是 gpio_get_value(gpio)報告了一個 +低電平(在適當的上升時間後)，你就可以知道是其他的一些組件將共享信號線拉低了。 +這不一定是錯誤的。一個常見的例子就是 I2C 時鐘的延長：一個需要較慢時鐘的 +從設備延遲 SCK 的上升沿，而 I2C 主設備相應地調整其信號傳輸速率。 + + +這些公約忽略了什麼? +================ +這些公約忽略的最大一件事就是引腳復用，因爲這屬於高度晶片特定的屬性且 +沒有可移植性。某個平台可能不需要明確的復用信息；有的對於任意給定的引腳 +可能只有兩個功能選項；有的可能每個引腳有八個功能選項；有的可能可以將 +幾個引腳中的任何一個作爲給定的 GPIO。(是的，這些例子都來自於當前運行 +Linux 的系統。) + +在某些系統中,與引腳復用相關的是配置和使能集成的上、下拉模式。並不是所有 +平台都支持這種模式,或者不會以相同的方式來支持這種模式；且任何給定的電路板 +可能使用外置的上拉(或下拉)電阻,這時晶片上的就不應該使用。(當一個電路需要 +5kOhm 的拉動電阻,晶片上的 100 kOhm 電阻就不能做到。)同樣的，驅動能力 +(2 mA vs 20 mA)和電壓(1.8V vs 3.3V)是平台特定問題,就像模型一樣在 +可配置引腳和 GPIO 之間(沒)有一一對應的關係。 + +還有其他一些系統特定的機制沒有在這裡指出，例如上述的輸入去毛刺和線與輸出 +選項。硬體可能支持批量讀或寫 GPIO，但是那一般是配置相關的：對於處於同一 +塊區(bank)的GPIO。(GPIO 通常以 16 或 32 個組成一個區塊，一個給定的 +片上系統一般有幾個這樣的區塊。)某些系統可以通過輸出 GPIO 觸發 IRQ， +或者從並非以 GPIO 管理的引腳取值。這些機制的相關代碼沒有必要具有可移植性。 + +當前，動態定義 GPIO 並不是標準的，例如作爲配置一個帶有某些 GPIO 擴展器的 +附加電路板的副作用。 + +GPIO 實現者的框架 (可選) +===================== +前面提到了，有一個可選的實現框架，讓平台使用相同的編程接口，更加簡單地支持 +不同種類的 GPIO 控制器。這個框架稱爲"gpiolib"。 + +作爲一個輔助調試功能，如果 debugfs 可用，就會有一個 /sys/kernel/debug/gpio +文件。通過這個框架，它可以列出所有註冊的控制器,以及當前正在使用中的 GPIO +的狀態。 + + +控制器驅動: gpio_chip +------------------- +在框架中每個 GPIO 控制器都包裝爲一個 "struct gpio_chip"，他包含了 +該類型的每個控制器的常用信息: + + - 設置 GPIO 方向的方法 + - 用於訪問 GPIO 值的方法 + - 告知調用其方法是否可能休眠的標誌 + - 可選的 debugfs 信息導出方法 (顯示類似上拉配置一樣的額外狀態) + - 診斷標籤 + +也包含了來自 device.platform_data 的每個實例的數據：它第一個 GPIO 的 +編號和它可用的 GPIO 的數量。 + +實現 gpio_chip 的代碼應支持多控制器實例，這可能使用驅動模型。那些代碼要 +配置每個 gpio_chip，並發起gpiochip_add()。卸載一個 GPIO 控制器很少見， +但在必要的時候可以使用 gpiochip_remove()。 + +大部分 gpio_chip 是一個實例特定結構體的一部分，而並不將 GPIO 接口單獨 +暴露出來,比如編址、電源管理等。類似編解碼器這樣的晶片會有複雜的非 GPIO +狀態。 + +任何一個 debugfs 信息導出方法通常應該忽略還未申請作爲 GPIO 的信號線。 +他們可以使用 gpiochip_is_requested()測試，當這個 GPIO 已經申請過了 +就返回相關的標籤，否則返回 NULL。 + + +平台支持 +------- +爲了支持這個框架，一個平台的 Kconfig 文件將會 "select"(選擇) +ARCH_REQUIRE_GPIOLIB 或 ARCH_WANT_OPTIONAL_GPIOLIB，並讓它的 + 包含 ，同時定義三個方法: +gpio_get_value()、gpio_set_value()和 gpio_cansleep()。 + +它也應提供一個 ARCH_NR_GPIOS 的定義值，這樣可以更好地反映該平台 GPIO +的實際數量,節省靜態表的空間。(這個定義值應該包含片上系統內建 GPIO 和 +GPIO 擴展器中的數據。) + +ARCH_REQUIRE_GPIOLIB 意味著 gpiolib 核心在這個構架中將總是編譯進內核。 + +ARCH_WANT_OPTIONAL_GPIOLIB 意味著 gpiolib 核心默認關閉,且用戶可以 +使能它,並將其編譯進內核(可選)。 + +如果這些選項都沒被選擇,該平台就不通過 GPIO-lib 支持 GPIO,且代碼不可以 +被用戶使能。 + +以下這些方法的實現可以直接使用框架代碼,並總是通過 gpio_chip 調度: + + #define gpio_get_value __gpio_get_value + #define gpio_set_value __gpio_set_value + #define gpio_cansleep __gpio_cansleep + +這些定義可以用更理想的實現方法替代，那就是使用經過邏輯優化的內聯函數來訪問 +基於特定片上系統的 GPIO。例如,若引用的 GPIO (寄存器位偏移)是常量「12」， +讀取或設置它可能只需少則兩或三個指令，且不會休眠。當這樣的優化無法實現時， +那些函數必須使用框架提供的代碼，那就至少要幾十條指令才可以實現。對於用 GPIO +模擬的 I/O 接口, 如此精簡指令是很有意義的。 + +對於片上系統，平台特定代碼爲片上 GPIO 每個區(bank)定義並註冊 gpio_chip +實例。那些 GPIO 應該根據晶片廠商的文檔進行編碼/標籤,並直接和電路板原理圖 +對應。他們應該開始於零並終止於平台特定的限制。這些 GPIO(代碼)通常從 +arch_initcall()或者更早的地方集成進平台初始化代碼，使這些 GPIO 總是可用， +且他們通常可以作爲 IRQ 使用。 + +板級支持 +------- +對於外部 GPIO 控制器(例如 I2C 或 SPI 擴展器、專用晶片、多功能器件、FPGA +或 CPLD)，大多數常用板級特定代碼都可以註冊控制器設備，並保證他們的驅動知道 +gpiochip_add()所使用的 GPIO 編號。他們的起始編號通常跟在平台特定的 GPIO +編號之後。 + +例如板級啓動代碼應該創建結構體指明晶片公開的 GPIO 範圍，並使用 platform_data +將其傳遞給每個 GPIO 擴展器晶片。然後晶片驅動中的 probe()例程可以將這個 +數據傳遞給 gpiochip_add()。 + +初始化順序很重要。例如，如果一個設備依賴基於 I2C 的(擴展)GPIO，那麼它的 +probe()例程就應該在那個 GPIO 有效以後才可以被調用。這意味著設備應該在 +GPIO 可以工作之後才可被註冊。解決這類依賴的的一種方法是讓這種 gpio_chip +控制器向板級特定代碼提供 setup()和 teardown()回調函數。一旦所有必須的 +資源可用之後，這些板級特定的回調函數將會註冊設備，並可以在這些 GPIO 控制器 +設備變成無效時移除它們。 + + +用戶空間的 Sysfs 接口(可選) +======================== +使用「gpiolib」實現框架的平台可以選擇配置一個 GPIO 的 sysfs 用戶接口。 +這不同於 debugfs 接口，因爲它提供的是對 GPIO方向和值的控制，而不只顯示 +一個GPIO 的狀態摘要。此外,它可以出現在沒有調試支持的產品級系統中。 + +例如，通過適當的系統硬體文檔，用戶空間可以知道 GIOP #23 控制 Flash +存儲器的防寫(用於保護其中 Bootloader 分區)。產品的系統升級可能需要 +臨時解除這個保護：首先導入一個 GPIO，改變其輸出狀態，然後在重新使能防寫 +前升級代碼。通常情況下,GPIO #23 是不會被觸及的，並且內核也不需要知道他。 + +根據適當的硬體文檔，某些系統的用戶空間 GPIO 可以用於確定系統配置數據， +這些數據是標準內核不知道的。在某些任務中，簡單的用戶空間 GPIO 驅動可能是 +系統真正需要的。 + +注意：標準內核驅動中已經存在通用的「LED 和按鍵」GPIO 任務，分別是: +"leds-gpio" 和 "gpio_keys"。請使用這些來替代直接訪問 GPIO，因爲集成在 +內核框架中的這類驅動比你在用戶空間的代碼更好。 + + +Sysfs 中的路徑 +-------------- +在/sys/class/gpio 中有 3 類入口: + + - 用於在用戶空間控制 GPIO 的控制接口; + + - GPIOs 本身;以及 + + - GPIO 控制器 ("gpio_chip" 實例)。 + +除了這些標準的文件,還包含「device」符號連結。 + +控制接口是只寫的: + + /sys/class/gpio/ + + "export" ... 用戶空間可以通過寫其編號到這個文件，要求內核導出 + 一個 GPIO 的控制到用戶空間。 + + 例如: 如果內核代碼沒有申請 GPIO #19,"echo 19 > export" + 將會爲 GPIO #19 創建一個 "gpio19" 節點。 + + "unexport" ... 導出到用戶空間的逆操作。 + + 例如: "echo 19 > unexport" 將會移除使用"export"文件導出的 + "gpio19" 節點。 + +GPIO 信號的路徑類似 /sys/class/gpio/gpio42/ (對於 GPIO #42 來說)， +並有如下的讀/寫屬性: + + /sys/class/gpio/gpioN/ + + "direction" ... 讀取得到 "in" 或 "out"。這個值通常運行寫入。 + 寫入"out" 時,其引腳的默認輸出爲低電平。爲了確保無故障運行， + "low" 或 "high" 的電平值應該寫入 GPIO 的配置，作爲初始輸出值。 + + 注意:如果內核不支持改變 GPIO 的方向，或者在導出時內核代碼沒有 + 明確允許用戶空間可以重新配置 GPIO 方向，那麼這個屬性將不存在。 + + "value" ... 讀取得到 0 (低電平) 或 1 (高電平)。如果 GPIO 配置爲 + 輸出,這個值允許寫操作。任何非零值都以高電平看待。 + + 如果引腳可以配置爲中斷信號，且如果已經配置了產生中斷的模式 + （見"edge"的描述），你可以對這個文件使用輪詢操作(poll(2))， + 且輪詢操作會在任何中斷觸發時返回。如果你使用輪詢操作(poll(2))， + 請在 events 中設置 POLLPRI 和 POLLERR。如果你使用輪詢操作 + (select(2))，請在 exceptfds 設置你期望的文件描述符。在 + 輪詢操作(poll(2))返回之後，既可以通過 lseek(2)操作讀取 + sysfs 文件的開始部分，也可以關閉這個文件並重新打開它來讀取數據。 + + "edge" ... 讀取得到「none」、「rising」、「falling」或者「both」。 + 將這些字符串寫入這個文件可以選擇沿觸發模式，會使得輪詢操作 + (select(2))在"value"文件中返回。 + + 這個文件僅有在這個引腳可以配置爲可產生中斷輸入引腳時，才存在。 + + "active_low" ... 讀取得到 0 (假) 或 1 (真)。寫入任何非零值可以 + 翻轉這個屬性的(讀寫)值。已存在或之後通過"edge"屬性設置了"rising" + 和 "falling" 沿觸發模式的輪詢操作(poll(2))將會遵循這個設置。 + +GPIO 控制器的路徑類似 /sys/class/gpio/gpiochip42/ (對於從#42 GPIO +開始實現控制的控制器),並有著以下只讀屬性: + + /sys/class/gpio/gpiochipN/ + + "base" ... 與以上的 N 相同,代表此晶片管理的第一個 GPIO 的編號 + + "label" ... 用於診斷 (並不總是只有唯一值) + + "ngpio" ... 此控制器所管理的 GPIO 數量(而 GPIO 編號從 N 到 + N + ngpio - 1) + +大多數情況下,電路板的文檔應當標明每個 GPIO 的使用目的。但是那些編號並不總是 +固定的,例如在擴展卡上的 GPIO會根據所使用的主板或所在堆疊架構中其他的板子而 +有所不同。在這種情況下,你可能需要使用 gpiochip 節點(儘可能地結合電路圖)來 +確定給定信號所用的 GPIO 編號。 + + +從內核代碼中導出 +------------- +內核代碼可以明確地管理那些已通過 gpio_request()申請的 GPIO 的導出: + + /* 導出 GPIO 到用戶空間 */ + int gpio_export(unsigned gpio, bool direction_may_change); + + /* gpio_export()的逆操作 */ + void gpio_unexport(); + + /* 創建一個 sysfs 連接到已導出的 GPIO 節點 */ + int gpio_export_link(struct device *dev, const char *name, + unsigned gpio) + +在一個內核驅動申請一個 GPIO 之後，它可以通過 gpio_export()使其在 sysfs +接口中可見。該驅動可以控制信號方向是否可修改。這有助於防止用戶空間代碼無意間 +破壞重要的系統狀態。 + +這個明確的導出有助於(通過使某些實驗更容易來)調試，也可以提供一個始終存在的接口， +與文檔配合作爲板級支持包的一部分。 + +在 GPIO 被導出之後，gpio_export_link()允許在 sysfs 文件系統的任何地方 +創建一個到這個 GPIO sysfs 節點的符號連結。這樣驅動就可以通過一個描述性的 +名字，在 sysfs 中他們所擁有的設備下提供一個(到這個 GPIO sysfs 節點的)接口。 + diff --git a/Documentation/translations/zh_TW/index.rst b/Documentation/translations/zh_TW/index.rst new file mode 100644 index 000000000000..cab58e428825 --- /dev/null +++ b/Documentation/translations/zh_TW/index.rst @@ -0,0 +1,162 @@ +.. SPDX-License-Identifier: GPL-2.0 + +.. raw:: latex + + \renewcommand\thesection* + \renewcommand\thesubsection* + \kerneldocCJKon + +.. _linux_doc_zh_tw: + +繁體中文翻譯 +============ + + +.. note:: + 內核文檔繁體中文版的翻譯工作正在進行中。如果您願意並且有時間參與這項工 + 作，歡迎提交補丁給胡皓文 。 + +許可證文檔 +---------- + +下面的文檔介紹了Linux內核原始碼的許可證（GPLv2）、如何在原始碼樹中正確標記 +單個文件的許可證、以及指向完整許可證文本的連結。 + +TODOList: + +* Documentation/translations/zh_TW/process/license-rules.rst + +用戶文檔 +-------- + +下面的手冊是爲內核用戶編寫的——即那些試圖讓它在給定系統上以最佳方式工作的 +用戶。 + +.. toctree:: + :maxdepth: 2 + + admin-guide/index + +TODOList: + +* kbuild/index + +固件相關文檔 +------------ + +下列文檔描述了內核需要的平台固件相關信息。 + +TODOList: + +* firmware-guide/index +* devicetree/index + +應用程式開發人員文檔 +-------------------- + +用戶空間API手冊涵蓋了描述應用程式開發人員可見內核接口方面的文檔。 + +TODOlist: + +* userspace-api/index + +內核開發簡介 +------------ + +這些手冊包含有關如何開發內核的整體信息。內核社區非常龐大，一年下來有數千名 +開發人員做出貢獻。與任何大型社區一樣，知道如何完成任務將使得更改合併的過程 +變得更加容易。 + +TODOList: + +* process/index +* dev-tools/index +* doc-guide/index +* kernel-hacking/index +* trace/index +* maintainer/index +* fault-injection/index +* livepatch/index +* rust/index + +內核API文檔 +----------- + +以下手冊從內核開發人員的角度詳細介紹了特定的內核子系統是如何工作的。這裡的 +大部分信息都是直接從內核原始碼獲取的，並根據需要添加補充材料（或者至少是在 +我們設法添加的時候——可能不是所有的都是有需要的）。 + +TODOList: + +* driver-api/index +* core-api/index +* locking/index +* accounting/index +* block/index +* cdrom/index +* cpu-freq/index +* ide/index +* fb/index +* fpga/index +* hid/index +* i2c/index +* iio/index +* isdn/index +* infiniband/index +* leds/index +* netlabel/index +* networking/index +* pcmcia/index +* power/index +* target/index +* timers/index +* spi/index +* w1/index +* watchdog/index +* virt/index +* input/index +* hwmon/index +* gpu/index +* security/index +* sound/index +* crypto/index +* filesystems/index +* vm/index +* bpf/index +* usb/index +* PCI/index +* scsi/index +* misc-devices/index +* scheduler/index +* mhi/index + +體系結構無關文檔 +---------------- + +TODOList: + +* asm-annotations + +特定體系結構文檔 +---------------- + +TODOList: + +* arch + +其他文檔 +-------- + +有幾份未排序的文檔似乎不適合放在文檔的其他部分，或者可能需要進行一些調整和/或 +轉換爲reStructureText格式，也有可能太舊。 + +TODOList: + +* staging/index +* watch_queue + +目錄和表格 +---------- + +* :ref:`genindex` + diff --git a/Documentation/translations/zh_TW/io_ordering.txt b/Documentation/translations/zh_TW/io_ordering.txt new file mode 100644 index 000000000000..1e99206c8421 --- /dev/null +++ b/Documentation/translations/zh_TW/io_ordering.txt @@ -0,0 +1,68 @@ +Chinese translated version of Documentation/driver-api/io_ordering.rst + +If you have any comment or update to the content, please contact the +original document maintainer directly. However, if you have a problem +communicating in English you can also ask the Chinese maintainer for +help. Contact the Chinese maintainer if this translation is outdated +or if there is a problem with the translation. + +Traditional Chinese maintainer: Hu Haowen +--------------------------------------------------------------------- +Documentation/driver-api/io_ordering.rst 的繁體中文翻譯 + +如果想評論或更新本文的內容，請直接聯繫原文檔的維護者。如果你使用英文 +交流有困難的話，也可以向繁體中文版維護者求助。如果本翻譯更新不及時或 +者翻譯存在問題，請聯繫繁體中文版維護者。 + +繁體中文版維護者： 胡皓文 Hu Haowen +繁體中文版翻譯者： 胡皓文 Hu Haowen +繁體中文版校譯者： 胡皓文 Hu Haowen + + +以下爲正文 +--------------------------------------------------------------------- + +在某些平台上，所謂的內存映射I/O是弱順序。在這些平台上，驅動開發者有責任 +保證I/O內存映射地址的寫操作按程序圖意的順序達到設備。通常讀取一個「安全」 +設備寄存器或橋寄存器，觸發IO晶片清刷未處理的寫操作到達設備後才處理讀操作， +而達到保證目的。驅動程序通常在spinlock保護的臨界區退出之前使用這種技術。 +這也可以保證後面的寫操作只在前面的寫操作之後到達設備（這非常類似於內存 +屏障操作，mb()，不過僅適用於I/O）。 + +假設一個設備驅動程的具體例子： + + ... +CPU A: spin_lock_irqsave(&dev_lock, flags) +CPU A: val = readl(my_status); +CPU A: ... +CPU A: writel(newval, ring_ptr); +CPU A: spin_unlock_irqrestore(&dev_lock, flags) + ... +CPU B: spin_lock_irqsave(&dev_lock, flags) +CPU B: val = readl(my_status); +CPU B: ... +CPU B: writel(newval2, ring_ptr); +CPU B: spin_unlock_irqrestore(&dev_lock, flags) + ... + +上述例子中，設備可能會先接收到newval2的值，然後接收到newval的值，問題就 +發生了。不過很容易通過下面方法來修復： + + ... +CPU A: spin_lock_irqsave(&dev_lock, flags) +CPU A: val = readl(my_status); +CPU A: ... +CPU A: writel(newval, ring_ptr); +CPU A: (void)readl(safe_register); /* 配置寄存器？*/ +CPU A: spin_unlock_irqrestore(&dev_lock, flags) + ... +CPU B: spin_lock_irqsave(&dev_lock, flags) +CPU B: val = readl(my_status); +CPU B: ... +CPU B: writel(newval2, ring_ptr); +CPU B: (void)readl(safe_register); /* 配置寄存器？*/ +CPU B: spin_unlock_irqrestore(&dev_lock, flags) + +在解決方案中，讀取safe_register寄存器，觸發IO晶片清刷未處理的寫操作， +再處理後面的讀操作，防止引發數據不一致問題。 + diff --git a/Documentation/translations/zh_TW/oops-tracing.txt b/Documentation/translations/zh_TW/oops-tracing.txt new file mode 100644 index 000000000000..be8e59f2abaf --- /dev/null +++ b/Documentation/translations/zh_TW/oops-tracing.txt @@ -0,0 +1,212 @@ +Chinese translated version of Documentation/admin-guide/bug-hunting.rst + +If you have any comment or update to the content, please contact the +original document maintainer directly. However, if you have a problem +communicating in English you can also ask the Chinese maintainer for +help. Contact the Chinese maintainer if this translation is outdated +or if there is a problem with the translation. + +Traditional Chinese maintainer: Hu Haowen +--------------------------------------------------------------------- +Documentation/admin-guide/bug-hunting.rst 的繁體中文版翻譯 + +如果想評論或更新本文的內容，請直接聯繫原文檔的維護者。如果你使用英文 +交流有困難的話，也可以向繁體中文版維護者求助。如果本翻譯更新不及時或 +者翻譯存在問題，請聯繫繁體中文版維護者。 + +繁體中文版維護者： 胡皓文 Hu Haowen +繁體中文版翻譯者： 胡皓文 Hu Haowen +繁體中文版校譯者： 胡皓文 Hu Haowen + +以下爲正文 +--------------------------------------------------------------------- + +注意： ksymoops 在2.6中是沒有用的。 請以原有格式使用Oops(來自dmesg，等等)。 +忽略任何這樣那樣關於「解碼Oops」或者「通過ksymoops運行」的文檔。 如果你貼出運行過 +ksymoops的來自2.6的Oops，人們只會讓你重貼一次。 + +快速總結 +------------- + +發現Oops並發送給看似相關的內核領域的維護者。別太擔心對不上號。如果你不確定就發給 +和你所做的事情相關的代碼的負責人。 如果可重現試著描述怎樣重構。 那甚至比oops更有 +價值。 + +如果你對於發送給誰一無所知， 發給linux-kernel@vger.kernel.org。感謝你幫助Linux +儘可能地穩定。 + +Oops在哪裡? +---------------------- + +通常Oops文本由klogd從內核緩衝區里讀取並傳給syslogd，由syslogd寫到syslog文件中， +典型地是/var/log/messages(依賴於/etc/syslog.conf)。有時klogd崩潰了,這種情況下你 +能夠運行dmesg > file來從內核緩衝區中讀取數據並保存下來。 否則你可以 +cat /proc/kmsg > file， 然而你必須介入中止傳輸， kmsg是一個「永不結束的文件」。如 +果機器崩潰壞到你不能輸入命令或者磁碟不可用那麼你有三種選擇:- + +（1） 手抄屏幕上的文本待機器重啓後再輸入計算機。 麻煩但如果沒有針對崩潰的準備， +這是僅有的選擇。 另外，你可以用數位相機把屏幕拍下來-不太好，但比沒有強。 如果信 +息滾動到了終端的上面，你會發現以高分辯率啓動（比如，vga=791）會讓你讀到更多的文 +本。（注意：這需要vesafb，所以對『早期』的oops沒有幫助） + +（2）用串口終端啓動（請參看Documentation/admin-guide/serial-console.rst），運行一個null +modem到另一台機器並用你喜歡的通訊工具獲取輸出。Minicom工作地很好。 + +（3）使用Kdump（請參看Documentation/admin-guide/kdump/kdump.rst）， +使用在Documentation/admin-guide/kdump/gdbmacros.txt中定義的dmesg gdb宏，從舊的內存中提取內核 +環形緩衝區。 + +完整信息 +---------------- + +注意：以下來自於Linus的郵件適用於2.4內核。 我因爲歷史原因保留了它，並且因爲其中 +一些信息仍然適用。 特別注意的是，請忽略任何ksymoops的引用。 + +From: Linus Torvalds + +怎樣跟蹤Oops.. [原發到linux-kernel的一封郵件] + +主要的竅門是有五年和這些煩人的oops消息打交道的經驗;-) + +實際上，你有辦法使它更簡單。我有兩個不同的方法： + + gdb /usr/src/linux/vmlinux + gdb> disassemble + +那是發現問題的簡單辦法，至少如果bug報告做的好的情況下（象這個一樣-運行ksymoops +得到oops發生的函數及函數內的偏移）。 + +哦，如果報告發生的內核以相同的編譯器和相似的配置編譯它會有幫助的。 + +另一件要做的事是反彙編bug報告的「Code」部分：ksymoops也會用正確的工具來做這件事， +但如果沒有那些工具你可以寫一個傻程序： + + char str[] = "\xXX\xXX\xXX..."; + main(){} + +並用gcc -g編譯它然後執行「disassemble str」（XX部分是由Oops報告的值-你可以僅剪切 +粘貼並用「\x」替換空格-我就是這麼做的，因爲我懶得寫程序自動做這一切）。 + +另外，你可以用scripts/decodecode這個shell腳本。它的使用方法是： +decodecode < oops.txt + +「Code」之後的十六進位字節可能（在某些架構上）有一些當前指令之前的指令字節以及 +當前和之後的指令字節 + +Code: f9 0f 8d f9 00 00 00 8d 42 0c e8 dd 26 11 c7 a1 60 ea 2b f9 8b 50 08 a1 +64 ea 2b f9 8d 34 82 8b 1e 85 db 74 6d 8b 15 60 ea 2b f9 <8b> 43 04 39 42 54 +7e 04 40 89 42 54 8b 43 04 3b 05 00 f6 52 c0 + +最後，如果你想知道代碼來自哪裡，你可以： + + cd /usr/src/linux + make fs/buffer.s # 或任何產生BUG的文件 + +然後你會比gdb反彙編更清楚的知道發生了什麼。 + +現在，問題是把你所擁有的所有數據結合起來：C源碼（關於它應該怎樣的一般知識）， +彙編代碼及其反彙編得到的代碼（另外還有從「oops」消息得到的寄存器狀態-對了解毀壞的 +指針有用，而且當你有了彙編代碼你也能拿其它的寄存器和任何它們對應的C表達式做匹配 +）。 + +實際上，你僅需看看哪裡不匹配（這個例子是「Code」反彙編和編譯器生成的代碼不匹配）。 +然後你須要找出爲什麼不匹配。通常很簡單-你看到代碼使用了空指針然後你看代碼想知道 +空指針是怎麼出現的，還有檢查它是否合法.. + +現在，如果明白這是一項耗時的工作而且需要一丁點兒的專心，沒錯。這就是我爲什麼大多 +只是忽略那些沒有符號表信息的崩潰報告的原因：簡單的說太難查找了（我有一些 +程序用於在內核代碼段中搜索特定的模式，而且有時我也已經能找出那些崩潰的地方，但是 +僅僅是找出正確的序列也確實需要相當紮實的內核知識） + +_有時_會發生這種情況，我僅看到崩潰中的反彙編代碼序列， 然後我馬上就明白問題出在 +哪裡。這時我才意識到自己幹這個工作已經太長時間了;-) + + Linus + + +--------------------------------------------------------------------------- +關於Oops跟蹤的註解： + +爲了幫助Linus和其它內核開發者，klogd納入了大量的支持來處理保護錯誤。爲了擁有對 +地址解析的完整支持至少應該使用1.3-pl3的sysklogd包。 + +當保護錯誤發生時，klogd守護進程自動把內核日誌信息中的重要地址翻譯成它們相應的符 +號。 + +klogd執行兩種類型的地址解析。首先是靜態翻譯其次是動態翻譯。靜態翻譯和ksymoops +一樣使用System.map文件。爲了做靜態翻譯klogd守護進程必須在初始化時能找到system +map文件。關於klogd怎樣搜索map文件請參看klogd手冊頁。 + +動態地址翻譯在使用內核可裝載模塊時很重要。 因爲內核模塊的內存是從內核動態內存池 +里分配的，所以不管是模塊開始位置還是模塊中函數和符號的位置都不是固定的。 + +內核支持允許程序決定裝載哪些模塊和它們在內存中位置的系統調用。使用這些系統調用 +klogd守護進程生成一張符號表用於調試發生在可裝載模塊中的保護錯誤。 + +至少klogd會提供產生保護錯誤的模塊名。還可有額外的符號信息供可裝載模塊開發者選擇 +以從模塊中輸出符號信息。 + +因爲內核模塊環境可能是動態的，所以必須有一種機制當模塊環境發生改變時來通知klogd +守護進程。 有一些可用的命令行選項允許klogd向當前執行中的守護進程發送信號，告知符 +號信息應該被刷新了。 更多信息請參看klogd手冊頁。 + +sysklogd發布時包含一個補丁修改了modules-2.0.0包，無論何時一個模塊裝載或者卸載都 +會自動向klogd發送信號。打上這個補丁提供了必要的對調試發生於內核可裝載模塊的保護 +錯誤的無縫支持。 + +以下是被klogd處理過的發生在可裝載模塊中的一個保護錯誤例子： +--------------------------------------------------------------------------- +Aug 29 09:51:01 blizard kernel: Unable to handle kernel paging request at virtual address f15e97cc +Aug 29 09:51:01 blizard kernel: current->tss.cr3 = 0062d000, %cr3 = 0062d000 +Aug 29 09:51:01 blizard kernel: *pde = 00000000 +Aug 29 09:51:01 blizard kernel: Oops: 0002 +Aug 29 09:51:01 blizard kernel: CPU: 0 +Aug 29 09:51:01 blizard kernel: EIP: 0010:[oops:_oops+16/3868] +Aug 29 09:51:01 blizard kernel: EFLAGS: 00010212 +Aug 29 09:51:01 blizard kernel: eax: 315e97cc ebx: 003a6f80 ecx: 001be77b edx: 00237c0c +Aug 29 09:51:01 blizard kernel: esi: 00000000 edi: bffffdb3 ebp: 00589f90 esp: 00589f8c +Aug 29 09:51:01 blizard kernel: ds: 0018 es: 0018 fs: 002b gs: 002b ss: 0018 +Aug 29 09:51:01 blizard kernel: Process oops_test (pid: 3374, process nr: 21, stackpage=00589000) +Aug 29 09:51:01 blizard kernel: Stack: 315e97cc 00589f98 0100b0b4 bffffed4 0012e38e 00240c64 003a6f80 00000001 +Aug 29 09:51:01 blizard kernel: 00000000 00237810 bfffff00 0010a7fa 00000003 00000001 00000000 bfffff00 +Aug 29 09:51:01 blizard kernel: bffffdb3 bffffed4 ffffffda 0000002b 0007002b 0000002b 0000002b 00000036 +Aug 29 09:51:01 blizard kernel: Call Trace: [oops:_oops_ioctl+48/80] [_sys_ioctl+254/272] [_system_call+82/128] +Aug 29 09:51:01 blizard kernel: Code: c7 00 05 00 00 00 eb 08 90 90 90 90 90 90 90 90 89 ec 5d c3 +--------------------------------------------------------------------------- + +Dr. G.W. Wettstein Oncology Research Div. Computing Facility +Roger Maris Cancer Center INTERNET: greg@wind.rmcc.com +820 4th St. N. +Fargo, ND 58122 +Phone: 701-234-7556 + + +--------------------------------------------------------------------------- +受汙染的內核 + +一些oops報告在程序記數器之後包含字符串'Tainted: '。這表明內核已經被一些東西給汙 +染了。 該字符串之後緊跟著一系列的位置敏感的字符，每個代表一個特定的汙染值。 + + 1：'G'如果所有裝載的模塊都有GPL或相容的許可證，'P'如果裝載了任何的專有模塊。 +沒有模塊MODULE_LICENSE或者帶有insmod認爲是與GPL不相容的的MODULE_LICENSE的模塊被 +認定是專有的。 + + 2：'F'如果有任何通過「insmod -f」被強制裝載的模塊，' '如果所有模塊都被正常裝載。 + + 3：'S'如果oops發生在SMP內核中，運行於沒有證明安全運行多處理器的硬體。 當前這種 +情況僅限於幾種不支持SMP的速龍處理器。 + + 4：'R'如果模塊通過「insmod -f」被強制裝載，' '如果所有模塊都被正常裝載。 + + 5：'M'如果任何處理器報告了機器檢查異常，' '如果沒有發生機器檢查異常。 + + 6：'B'如果頁釋放函數發現了一個錯誤的頁引用或者一些非預期的頁標誌。 + + 7：'U'如果用戶或者用戶應用程式特別請求設置汙染標誌，否則' '。 + + 8：'D'如果內核剛剛死掉，比如有OOPS或者BUG。 + +使用'Tainted: '字符串的主要原因是要告訴內核調試者，這是否是一個乾淨的內核亦或發 +生了任何的不正常的事。汙染是永久的：即使出錯的模塊已經被卸載了，汙染值仍然存在， +以表明內核不再值得信任。 + diff --git a/Documentation/translations/zh_TW/sparse.txt b/Documentation/translations/zh_TW/sparse.txt new file mode 100644 index 000000000000..c9acb2c926cb --- /dev/null +++ b/Documentation/translations/zh_TW/sparse.txt @@ -0,0 +1,91 @@ +Chinese translated version of Documentation/dev-tools/sparse.rst + +If you have any comment or update to the content, please contact the +original document maintainer directly. However, if you have a problem +communicating in English you can also ask the Chinese maintainer for +help. Contact the Chinese maintainer if this translation is outdated +or if there is a problem with the translation. + +Traditional Chinese maintainer: Hu Haowen +--------------------------------------------------------------------- +Documentation/dev-tools/sparse.rst 的繁體中文翻譯 + +如果想評論或更新本文的內容，請直接聯繫原文檔的維護者。如果你使用英文 +交流有困難的話，也可以向繁體中文版維護者求助。如果本翻譯更新不及時或 +者翻譯存在問題，請聯繫繁體中文版維護者。 + +繁體中文版維護者： 胡皓文 Hu Haowen +繁體中文版翻譯者： 胡皓文 Hu Haowen + +以下爲正文 +--------------------------------------------------------------------- + +Copyright 2004 Linus Torvalds +Copyright 2004 Pavel Machek +Copyright 2006 Bob Copeland + +使用 sparse 工具做類型檢查 +~~~~~~~~~~~~~~~~~~~~~~~~~~ + +"__bitwise" 是一種類型屬性，所以你應該這樣使用它： + + typedef int __bitwise pm_request_t; + + enum pm_request { + PM_SUSPEND = (__force pm_request_t) 1, + PM_RESUME = (__force pm_request_t) 2 + }; + +這樣會使 PM_SUSPEND 和 PM_RESUME 成爲位方式(bitwise)整數（使用"__force" +是因爲 sparse 會抱怨改變位方式的類型轉換，但是這裡我們確實需要強制進行轉 +換）。而且因爲所有枚舉值都使用了相同的類型，這裡的"enum pm_request"也將 +會使用那個類型做爲底層實現。 + +而且使用 gcc 編譯的時候，所有的 __bitwise/__force 都會消失，最後在 gcc +看來它們只不過是普通的整數。 + +坦白來說，你並不需要使用枚舉類型。上面那些實際都可以濃縮成一個特殊的"int +__bitwise"類型。 + +所以更簡單的辦法只要這樣做： + + typedef int __bitwise pm_request_t; + + #define PM_SUSPEND ((__force pm_request_t) 1) + #define PM_RESUME ((__force pm_request_t) 2) + +現在你就有了嚴格的類型檢查所需要的所有基礎架構。 + +一個小提醒：常數整數"0"是特殊的。你可以直接把常數零當作位方式整數使用而 +不用擔心 sparse 會抱怨。這是因爲"bitwise"（恰如其名）是用來確保不同位方 +式類型不會被弄混（小尾模式，大尾模式，cpu尾模式，或者其他），對他們來說 +常數"0"確實是特殊的。 + +獲取 sparse 工具 +~~~~~~~~~~~~~~~~ + +你可以從 Sparse 的主頁獲取最新的發布版本： + + http://www.kernel.org/pub/linux/kernel/people/josh/sparse/ + +或者，你也可以使用 git 克隆最新的 sparse 開發版本： + + git://git.kernel.org/pub/scm/linux/kernel/git/josh/sparse.git + +一旦你下載了源碼，只要以普通用戶身份運行： + + make + make install + +它將會被自動安裝到你的 ~/bin 目錄下。 + +使用 sparse 工具 +~~~~~~~~~~~~~~~~ + +用"make C=1"命令來編譯內核，會對所有重新編譯的 C 文件使用 sparse 工具。 +或者使用"make C=2"命令，無論文件是否被重新編譯都會對其使用 sparse 工具。 +如果你已經編譯了內核，用後一種方式可以很快地檢查整個源碼樹。 + +make 的可選變量 CHECKFLAGS 可以用來向 sparse 工具傳遞參數。編譯系統會自 +動向 sparse 工具傳遞 -Wbitwise 參數。 + -- cgit v1.2.3 From 390f915a12a668c2add6a37bbf4dc30bc6a0e4d4 Mon Sep 17 00:00:00 2001 From: Hu Haowen Date: Thu, 29 Jul 2021 23:56:26 +0800 Subject: docs/zh_TW: add translations for zh_TW/process Create new translations for zh_TW/process and link them to index. Signed-off-by: Hu Haowen Reviewed-by: Pan Yunwang Link: https://lore.kernel.org/r/20210729155627.41744-2-src.res@email.cn Signed-off-by: Jonathan Corbet --- Documentation/translations/zh_TW/index.rst | 10 +- .../translations/zh_TW/process/1.Intro.rst | 199 +++++ .../translations/zh_TW/process/2.Process.rst | 369 ++++++++ .../translations/zh_TW/process/3.Early-stage.rst | 172 ++++ .../translations/zh_TW/process/4.Coding.rst | 297 +++++++ .../translations/zh_TW/process/5.Posting.rst | 251 ++++++ .../translations/zh_TW/process/6.Followthrough.rst | 156 ++++ .../zh_TW/process/7.AdvancedTopics.rst | 137 +++ .../translations/zh_TW/process/8.Conclusion.rst | 74 ++ .../process/code-of-conduct-interpretation.rst | 112 +++ .../translations/zh_TW/process/code-of-conduct.rst | 76 ++ .../translations/zh_TW/process/coding-style.rst | 958 +++++++++++++++++++++ .../zh_TW/process/development-process.rst | 30 + .../translations/zh_TW/process/email-clients.rst | 252 ++++++ .../zh_TW/process/embargoed-hardware-issues.rst | 232 +++++ Documentation/translations/zh_TW/process/howto.rst | 500 +++++++++++ Documentation/translations/zh_TW/process/index.rst | 67 ++ .../zh_TW/process/kernel-driver-statement.rst | 203 +++++ .../zh_TW/process/kernel-enforcement-statement.rst | 155 ++++ .../translations/zh_TW/process/license-rules.rst | 374 ++++++++ .../translations/zh_TW/process/magic-number.rst | 148 ++++ .../zh_TW/process/management-style.rst | 211 +++++ .../zh_TW/process/programming-language.rst | 76 ++ .../zh_TW/process/stable-api-nonsense.rst | 159 ++++ .../zh_TW/process/stable-kernel-rules.rst | 68 ++ .../zh_TW/process/submit-checklist.rst | 109 +++ .../zh_TW/process/submitting-drivers.rst | 164 ++++ .../zh_TW/process/submitting-patches.rst | 686 +++++++++++++++ .../zh_TW/process/volatile-considered-harmful.rst | 110 +++ 29 files changed, 6351 insertions(+), 4 deletions(-) create mode 100644 Documentation/translations/zh_TW/process/1.Intro.rst create mode 100644 Documentation/translations/zh_TW/process/2.Process.rst create mode 100644 Documentation/translations/zh_TW/process/3.Early-stage.rst create mode 100644 Documentation/translations/zh_TW/process/4.Coding.rst create mode 100644 Documentation/translations/zh_TW/process/5.Posting.rst create mode 100644 Documentation/translations/zh_TW/process/6.Followthrough.rst create mode 100644 Documentation/translations/zh_TW/process/7.AdvancedTopics.rst create mode 100644 Documentation/translations/zh_TW/process/8.Conclusion.rst create mode 100644 Documentation/translations/zh_TW/process/code-of-conduct-interpretation.rst create mode 100644 Documentation/translations/zh_TW/process/code-of-conduct.rst create mode 100644 Documentation/translations/zh_TW/process/coding-style.rst create mode 100644 Documentation/translations/zh_TW/process/development-process.rst create mode 100644 Documentation/translations/zh_TW/process/email-clients.rst create mode 100644 Documentation/translations/zh_TW/process/embargoed-hardware-issues.rst create mode 100644 Documentation/translations/zh_TW/process/howto.rst create mode 100644 Documentation/translations/zh_TW/process/index.rst create mode 100644 Documentation/translations/zh_TW/process/kernel-driver-statement.rst create mode 100644 Documentation/translations/zh_TW/process/kernel-enforcement-statement.rst create mode 100644 Documentation/translations/zh_TW/process/license-rules.rst create mode 100644 Documentation/translations/zh_TW/process/magic-number.rst create mode 100644 Documentation/translations/zh_TW/process/management-style.rst create mode 100644 Documentation/translations/zh_TW/process/programming-language.rst create mode 100644 Documentation/translations/zh_TW/process/stable-api-nonsense.rst create mode 100644 Documentation/translations/zh_TW/process/stable-kernel-rules.rst create mode 100644 Documentation/translations/zh_TW/process/submit-checklist.rst create mode 100644 Documentation/translations/zh_TW/process/submitting-drivers.rst create mode 100644 Documentation/translations/zh_TW/process/submitting-patches.rst create mode 100644 Documentation/translations/zh_TW/process/volatile-considered-harmful.rst (limited to 'Documentation') diff --git a/Documentation/translations/zh_TW/index.rst b/Documentation/translations/zh_TW/index.rst index cab58e428825..76981b2111f6 100644 --- a/Documentation/translations/zh_TW/index.rst +++ b/Documentation/translations/zh_TW/index.rst @@ -22,9 +22,7 @@ 下面的文檔介紹了Linux內核原始碼的許可證（GPLv2）、如何在原始碼樹中正確標記 單個文件的許可證、以及指向完整許可證文本的連結。 -TODOList: - -* Documentation/translations/zh_TW/process/license-rules.rst +Documentation/translations/zh_TW/process/license-rules.rst 用戶文檔 -------- @@ -67,9 +65,13 @@ TODOlist: 開發人員做出貢獻。與任何大型社區一樣，知道如何完成任務將使得更改合併的過程 變得更加容易。 +.. toctree:: + :maxdepth: 2 + + process/index + TODOList: -* process/index * dev-tools/index * doc-guide/index * kernel-hacking/index diff --git a/Documentation/translations/zh_TW/process/1.Intro.rst b/Documentation/translations/zh_TW/process/1.Intro.rst new file mode 100644 index 000000000000..ca2b931be6c5 --- /dev/null +++ b/Documentation/translations/zh_TW/process/1.Intro.rst @@ -0,0 +1,199 @@ +.. SPDX-License-Identifier: GPL-2.0 + +.. include:: ../disclaimer-zh_TW.rst + +:Original: :ref:`Documentation/process/1.Intro.rst ` + +:Translator: + + 時奎亮 Alex Shi + +:校譯: + + 吳想成 Wu XiangCheng + 胡皓文 Hu Haowen + +.. _tw_development_process_intro: + +引言 +==== + +內容提要 +-------- + +本節的其餘部分涵蓋了內核開發的過程，以及開發人員及其僱主在這方面可能遇到的 +各種問題。有很多原因使內核代碼應被合併到正式的（「主線」）內核中，包括對用戶 +的自動可用性、多種形式的社區支持以及影響內核開發方向的能力。提供給Linux內核 +的代碼必須在與GPL兼容的許可證下可用。 + +:ref:`tw_development_process` 介紹了開發過程、內核發布周期和合併窗口的機制。 +涵蓋了補丁開發、審查和合併周期中的各個階段。還有一些關於工具和郵件列表的討論？ +鼓勵希望開始內核開發的開發人員跟蹤並修復缺陷以作爲初步練習。 + + +:ref:`tw_development_early_stage` 包括項目的早期規劃，重點是儘快讓開發社區 +參與進來。 + +:ref:`tw_development_coding` 是關於編程過程的；介紹了其他開發人員遇到的幾個 +陷阱。也涵蓋了對補丁的一些要求，並且介紹了一些工具，這些工具有助於確保內核 +補丁是正確的。 + +:ref:`tw_development_posting` 描述發布補丁以供評審的過程。爲了讓開發社區能 +認真對待，補丁必須被正確格式化和描述，並且必須發送到正確的地方。遵循本節中的 +建議有助於確保您的工作能被較好地接納。 + +:ref:`tw_development_followthrough` 介紹了發布補丁之後發生的事情；工作在這時 +還遠遠沒有完成。與審閱者一起工作是開發過程中的一個重要部分；本節提供了一些 +關於如何在這個重要階段避免問題的提示。當補丁被合併到主線中時，開發人員要注意 +不要假定任務已經完成。 + +:ref:`tw_development_advancedtopics` 介紹了兩個「高級」主題：使用Git管理補丁 +和查看其他人發布的補丁。 + +:ref:`tw_development_conclusion` 總結了有關內核開發的更多信息，附帶有相關資源 +連結。 + +這個文檔是關於什麼的 +-------------------- + +Linux內核有超過800萬行代碼，每個版本的貢獻者超過1000人，是現存最大、最活躍的 +免費軟體項目之一。從1991年開始，這個內核已經發展成爲一個最好的作業系統組件， +運行在袖珍數位音樂播放器、桌上型電腦、現存最大的超級計算機以及所有類型的系統上。 +它是一種適用於幾乎任何情況的健壯、高效和可擴展的解決方案。 + +隨著Linux的發展，希望參與其開發的開發人員（和公司）的數量也在增加。硬體供應商 +希望確保Linux能夠很好地支持他們的產品，使這些產品對Linux用戶具有吸引力。嵌入 +式系統供應商使用Linux作爲集成產品的組件，希望Linux能夠儘可能地勝任手頭的任務。 +分銷商和其他基於Linux的軟體供應商切實關心Linux內核的功能、性能和可靠性。最終 +用戶也常常希望修改Linux，使之能更好地滿足他們的需求。 + +Linux最引人注目的特性之一是這些開發人員可以訪問它；任何具備必要技能的人都可以 +改進Linux並影響其開發方向。專有產品不能提供這種開放性，這是自由軟體的一個特點。 +如果有什麼不同的話，那就是內核比大多數其他自由軟體項目更開放。一個典型的三個 +月內核開發周期可以涉及1000多個開發人員，他們爲100多個不同的公司（或者根本不 +隸屬公司）工作。 + +與內核開發社區合作並不是特別困難。但儘管如此，仍有許多潛在的貢獻者在嘗試做 +內核工作時遇到了困難。內核社區已經發展出自己獨特的操作方式，使其能夠在每天 +都要更改數千行代碼的環境中順利運行（並生成高質量的產品）。因此，Linux內核開發 +過程與專有的開發模式有很大的不同也就不足爲奇了。 + +對於新開發人員來說，內核的開發過程可能會讓人感到奇怪和恐懼，但這背後有充分的 +理由和堅實的經驗。一個不了解內核社區工作方式的開發人員（或者更糟的是，他們 +試圖拋棄或規避之）會得到令人沮喪的體驗。開發社區在幫助那些試圖學習的人的同時， +沒有時間幫助那些不願意傾聽或不關心開發過程的人。 + +希望閱讀本文的人能夠避免這種令人沮喪的經歷。這些材料很長，但閱讀它們時所做的 +努力會在短時間內得到回報。開發社區總是需要能讓內核變更好的開發人員；下面的 +文字應該幫助您或爲您工作的人員加入我們的社區。 + +致謝 +---- + +本文檔由Jonathan Corbet 撰寫。以下人員的建議使之更爲完善： +Johannes Berg, James Berry, Alex Chiang, Roland Dreier, Randy Dunlap, +Jake Edge, Jiri Kosina, Matt Mackall, Arthur Marsh, Amanda McPherson, +Andrew Morton, Andrew Price, Tsugikazu Shibata 和 Jochen Voß 。 + +這項工作得到了Linux基金會的支持，特別感謝Amanda McPherson，他看到了這項工作 +的價值並將其變成現實。 + +代碼進入主線的重要性 +-------------------- + +有些公司和開發人員偶爾會想，爲什麼他們要費心學習如何與內核社區合作，並將代碼 +放入主線內核（「主線」是由Linus Torvalds維護的內核，Linux發行商將其用作基礎）。 +在短期內，貢獻代碼看起來像是一種可以避免的開銷；維護獨立代碼並直接支持用戶 +似乎更容易。事實上，保持代碼獨立（「樹外」）是在經濟上是錯誤的。 + +爲了說明樹外代碼成本，下面給出內核開發過程的一些相關方面；本文稍後將更詳細地 +討論其中的大部分內容。請考慮： + +- 所有Linux用戶都可以使用合併到主線內核中的代碼。它將自動出現在所有啓用它的 + 發行版上。無需驅動程序磁碟、額外下載，也不需要爲多個發行版的多個版本提供 + 支持；這一切將方便所有開發人員和用戶。併入主線解決了大量的分發和支持問題。 + +- 當內核開發人員努力維護一個穩定的用戶空間接口時，內核內部API處於不斷變化之中。 + 不維持穩定的內部接口是一個慎重的設計決策；它允許在任何時候進行基本的改進， + 並產出更高質量的代碼。但該策略導致結果是，若要使用新的內核，任何樹外代碼都 + 需要持續的維護。維護樹外代碼會需要大量的工作才能使代碼保持正常運行。 + + 相反，位於主線中的代碼不需要這樣做，因爲基本規則要求進行API更改的任何開發 + 人員也必須修復由於該更改而破壞的任何代碼。因此，合併到主線中的代碼大大降低 + 了維護成本。 + +- 除此之外，內核中的代碼通常會被其他開發人員改進。您授權的用戶社區和客戶對您 + 產品的改進可能會令人驚喜。 + +- 內核代碼在合併到主線之前和之後都要經過審查。無論原始開發人員的技能有多強， + 這個審查過程總是能找到改進代碼的方法。審查經常發現嚴重的錯誤和安全問題。 + 對於在封閉環境中開發的代碼尤其如此；這種代碼從外部開發人員的審查中獲益匪淺。 + 樹外代碼是低質量代碼。 + +- 參與開發過程是您影響內核開發方向的方式。旁觀者的抱怨會被聽到，但是活躍的 + 開發人員有更強的聲音——並且能夠實現使內核更好地滿足其需求的更改。 + +- 當單獨維護代碼時，總是存在第三方爲類似功能提供不同實現的可能性。如果發生 + 這種情況，合併代碼將變得更加困難——甚至成爲不可能。之後，您將面臨以下令人 + 不快的選擇：（1）無限期地維護樹外的非標準特性，或（2）放棄代碼並將用戶遷移 + 到樹內版本。 + +- 代碼的貢獻是使整個流程工作的根本。通過貢獻代碼，您可以向內核添加新功能，並 + 提供其他內核開發人員使用的功能和示例。如果您已經爲Linux開發了代碼（或者正在 + 考慮這樣做），那麼您顯然對這個平台的持續成功感興趣；貢獻代碼是確保成功的 + 最好方法之一。 + +上述所有理由都適用於任何樹外內核代碼，包括以專有的、僅二進位形式分發的代碼。 +然而，在考慮任何類型的純二進位內核代碼分布之前，還需要考慮其他因素。包括： + +- 圍繞專有內核模塊分發的法律問題其實較爲模糊；相當多的內核版權所有者認爲， + 大多數僅二進位的模塊是內核的派生產品，因此，它們的分發違反了GNU通用公共 + 許可證（下面將詳細介紹）。本文作者不是律師，本文檔中的任何內容都不可能被 + 視爲法律建議。封閉原始碼模塊的真實法律地位只能由法院決定。但不管怎樣，困擾 + 這些模塊的不確定性仍然存在。 + +- 二進位模塊大大增加了調試內核問題的難度，以至於大多數內核開發人員甚至都不會 + 嘗試。因此，只分發二進位模塊將使您的用戶更難從社區獲得支持。 + +- 對於僅二進位的模塊的發行者來說，支持也更加困難，他們必須爲他們希望支持的 + 每個發行版和每個內核版本提供不同版本的模塊。爲了提供較爲全面的覆蓋範圍， + 可能需要一個模塊的幾十個構建，並且每次升級內核時，您的用戶都必須單獨升級 + 這些模塊。 + +- 上面提到的關於代碼評審的所有問題都更加存在於封閉原始碼中。由於該代碼根本 + 不可得，因此社區無法對其進行審查，毫無疑問，它將存在嚴重問題。 + +尤其是嵌入式系統的製造商，可能會傾向於忽視本節中所說的大部分內容；因爲他們 +相信自己正在商用一種使用凍結內核版本的獨立產品，在發布後不需要再進行開發。 +這個論點忽略了廣泛的代碼審查的價值以及允許用戶向產品添加功能的價值。但這些 +產品的商業壽命有限，之後必須發布新版本的產品。在這一點上，代碼在主線上並得到 +良好維護的供應商將能夠更好地占位，以使新產品快速上市。 + +許可 +---- + +代碼是根據一些許可證提供給Linux內核的，但是所有代碼都必須與GNU通用公共許可 +證（GPLV2）的版本2兼容，該版本是覆蓋整個內核分發的許可證。在實踐中，這意味 +著所有代碼貢獻都由GPLv2（可選地，語言允許在更高版本的GPL下分發）或3子句BSD +許可（New BSD License，譯者注）覆蓋。任何不包含在兼容許可證中的貢獻都不會 +被接受到內核中。 + +貢獻給內核的代碼不需要（或請求）版權分配。合併到主線內核中的所有代碼都保留 +其原始所有權；因此，內核現在擁有數千個所有者。 + +這種所有權結構也暗示著，任何改變內核許可的嘗試都註定會失敗。很少有實際情況 +可以獲得所有版權所有者的同意（或者從內核中刪除他們的代碼）。因此，尤其是在 +可預見的將來，許可證不大可能遷移到GPL的版本3。 + +所有貢獻給內核的代碼都必須是合法的免費軟體。因此，不接受匿名（或化名）貢獻 +者的代碼。所有貢獻者都需要在他們的代碼上「sign off（簽發）」，聲明代碼可以 +在GPL下與內核一起分發。無法提供未被其所有者許可爲免費軟體的代碼，或可能爲 +內核造成版權相關問題的代碼（例如，由缺乏適當保護的反向工程工作派生的代碼） +不能被接受。 + +有關版權問題的提問在Linux開發郵件列表中很常見。這樣的問題通常會得到不少答案， +但請記住，回答這些問題的人不是律師，不能提供法律諮詢。如果您有關於Linux原始碼 +的法律問題，沒有什麼可以代替諮詢了解這一領域的律師。依賴從技術郵件列表中獲得 +的答案是一件冒險的事情。 + + diff --git a/Documentation/translations/zh_TW/process/2.Process.rst b/Documentation/translations/zh_TW/process/2.Process.rst new file mode 100644 index 000000000000..b01cdd3a39ae --- /dev/null +++ b/Documentation/translations/zh_TW/process/2.Process.rst @@ -0,0 +1,369 @@ +.. SPDX-License-Identifier: GPL-2.0 + +.. include:: ../disclaimer-zh_TW.rst + +:Original: :ref:`Documentation/process/2.Process.rst ` + +:Translator: + + 時奎亮 Alex Shi + +:校譯: + + 吳想成 Wu XiangCheng + 胡皓文 Hu Haowen + +.. _tw_development_process: + +開發流程如何進行 +================ + +90年代早期的Linux內核開發是一件相當鬆散的事情，涉及的用戶和開發人員相對較少。 +由於擁有數以百萬計的用戶羣，且每年有大約2000名開發人員參與進來，內核因此必須 +發展出許多既定流程來保證開發的順利進行。要參與到流程中來，需要對此流程的進行 +方式有一個紮實的理解。 + +總覽 +---- + +內核開發人員使用一個鬆散的基於時間的發布過程，每兩到三個月發布一次新的主要 +內核版本。最近的發布歷史記錄如下： + + ====== ================= + 5.0 2019年3月3日 + 5.1 2019年5月5日 + 5.2 2019年7月7日 + 5.3 2019年9月15日 + 5.4 2019年11月24日 + 5.5 2020年1月6日 + ====== ================= + +每個5.x版本都是一個主要的內核版本，具有新特性、內部API更改等等。一個典型的5.x +版本包含大約13000個變更集，變更了幾十萬行代碼。因此，5.x是Linux內核開發的前 +沿；內核使用滾動開發模型，不斷集成重大變化。 + +對於每個版本的補丁合併，遵循一個相對簡單的規則。在每個開發周期的開頭，「合併 +窗口」被打開。這時，被認爲足夠穩定（並且被開發社區接受）的代碼被合併到主線內 +核中。在這段時間內，新開發周期的大部分變更（以及所有主要變更）將以接近每天 +1000次變更（「補丁」或「變更集」）的速度合併。 + +（順便說一句，值得注意的是，合併窗口期間集成的更改並不是憑空產生的；它們是經 +提前收集、測試和分級的。稍後將詳細描述該過程的工作方式。） + +合併窗口持續大約兩周。在這段時間結束時，LinusTorvalds將聲明窗口已關閉，並 +釋放第一個「rc」內核。例如，對於目標爲5.6的內核，在合併窗口結束時發生的釋放 +將被稱爲5.6-rc1。-rc1 版本是一個信號，表示合併新特性的時間已經過去，穩定下一 +個內核的時間已經到來。 + +在接下來的6到10周內，只有修復問題的補丁才應該提交給主線。有時會允許更大的 +更改，但這種情況很少發生；試圖在合併窗口外合併新功能的開發人員往往受不到 +友好的接待。一般來說，如果您錯過了給定特性的合併窗口，最好的做法是等待下一 +個開發周期。（偶爾會對未支持硬體的驅動程序進行例外；如果它們不改變已有代碼， +則不會導致回歸，應該可以隨時被安全地加入）。 + +隨著修復程序進入主線，補丁速度將隨著時間的推移而變慢。Linus大約每周發布一次 +新的-rc內核；在內核被認爲足夠穩定並最終發布前，一般會達到-rc6到-rc9之間。 +然後，整個過程又重新開始了。 + +例如，這裡是5.4的開發周期進行情況（2019年）: + + ============== ============================== + 九月 15 5.3 穩定版發布 + 九月 30 5.4-rc1 合併窗口關閉 + 十月 6 5.4-rc2 + 十月 13 5.4-rc3 + 十月 20 5.4-rc4 + 十月 27 5.4-rc5 + 十一月 3 5.4-rc6 + 十一月 10 5.4-rc7 + 十一月 17 5.4-rc8 + 十一月 24 5.4 穩定版發布 + ============== ============================== + +開發人員如何決定何時結束開發周期並創建穩定版本？最重要的指標是以前版本的 +回歸列表。不歡迎出現任何錯誤，但是那些破壞了以前能工作的系統的錯誤被認爲是 +特別嚴重的。因此，導致回歸的補丁是不受歡迎的，很可能在穩定期內刪除。 + +開發人員的目標是在穩定發布之前修復所有已知的回歸。在現實世界中，這種完美是 +很難實現的；在這種規模的項目中，變數太多了。需要說明的是，延遲最終版本只會 +使問題變得更糟；等待下一個合併窗口的更改將變多，導致下次出現更多的回歸錯誤。 +因此，大多數5.x內核都有一些已知的回歸錯誤，不過，希望沒有一個是嚴重的。 + +一旦一個穩定的版本發布，它的持續維護工作就被移交給「穩定團隊」，目前由 +Greg Kroah-Hartman領導。穩定團隊將使用5.x.y編號方案不定期地發布穩定版本的 +更新。要合入更新版本，補丁必須（1）修復一個重要的缺陷，且（2）已經合併到 +下一個開發版本主線中。內核通常會在其初始版本後的一個以上的開發周期內收到 +穩定版更新。例如，5.2內核的歷史如下（2019年）： + + ============== =============================== + 七月 7 5.2 穩定版發布 + 七月 13 5.2.1 + 七月 21 5.2.2 + 七月 26 5.2.3 + 七月 28 5.2.4 + 七月 31 5.2.5 + ... ... + 十月 11 5.2.21 + ============== =============================== + +5.2.21是5.2版本的最終穩定更新。 + +有些內核被指定爲「長期」內核；它們將得到更長時間的支持。在本文中，當前的長期 +內核及其維護者是： + + ====== ================================ ================ + 3.16 Ben Hutchings （長期穩定內核） + 4.4 Greg Kroah-Hartman & Sasha Levin （長期穩定內核） + 4.9 Greg Kroah-Hartman & Sasha Levin + 4.14 Greg Kroah-Hartman & Sasha Levin + 4.19 Greg Kroah-Hartman & Sasha Levin + 5.4 Greg Kroah-Hartman & Sasha Levin + ====== ================================ ================ + +長期支持內核的選擇純粹是維護人員是否有需求和時間來維護該版本的問題。 +目前還沒有爲即將發布的任何特定版本提供長期支持的已知計劃。 + +補丁的生命周期 +-------------- + +補丁不會直接從開發人員的鍵盤進入主線內核。相反，有一個稍微複雜（如果有些非 +正式）的過程，旨在確保對每個補丁進行質量審查，並確保每個補丁實現了一個在主線 +中需要的更改。對於小的修復，這個過程可能會很快完成，，而對於較大或有爭議的 +變更，可能會持續數年。許多開發人員的沮喪來自於對這個過程缺乏理解或者試圖繞過它。 + +爲了減少這種挫敗，本文將描述補丁如何進入內核。下面的介紹以一種較爲理想化的 +方式描述了這個過程。更詳細的過程將在後面的章節中介紹。 + +補丁通常要經歷以下階段： + +- 設計。這就是補丁的真正需求——以及滿足這些需求的方式——所在。設計工作通常 + 是在不涉及社區的情況下完成的，但是如果可能的話，最好是在公開的情況下完成 + 這項工作；這樣可以節省很多稍後再重新設計的時間。 + +- 早期評審。補丁被發布到相關的郵件列表中，列表中的開發人員會回復他們可能有 + 的任何評論。如果一切順利的話，這個過程應該會發現補丁的任何主要問題。 + +- 更廣泛的評審。當補丁接近準備好納入主線時，它應該被相關的子系統維護人員 + 接受——儘管這種接受並不能保證補丁會一直延伸到主線。補丁將出現在維護人員的 + 子系統樹中，並進入 -next 樹（如下所述）。當流程進行時，此步驟將會對補丁 + 進行更廣泛的審查，並發現由於將此補丁與其他人所做的工作合併而導致的任何 + 問題。 + +- 請注意，大多數維護人員也有日常工作，因此合併補丁可能不是他們的最優先工作。 + 如果您的補丁得到了需要更改的反饋，那麼您應該進行這些更改，或者解釋爲何 + 不應該進行這些更改。如果您的補丁沒有評審意見，也沒有被其相應的子系統或 + 驅動程序維護者接受，那麼您應該堅持不懈地將補丁更新到當前內核使其可被正常 + 應用，並不斷地發送它以供審查和合併。 + +- 合併到主線。最終，一個成功的補丁將被合併到由LinusTorvalds管理的主線存儲庫 + 中。此時可能會出現更多的評論和/或問題；對開發人員來說應對這些問題並解決 + 出現的任何問題仍很重要。 + +- 穩定版發布。大量用戶可能受此補丁影響，因此可能再次出現新的問題。 + +- 長期維護。雖然開發人員在合併代碼後可能會忘記代碼，但這種行爲往往會給開發 + 社區留下不良印象。合併代碼消除了一些維護負擔，因爲其他人將修復由API更改 + 引起的問題。但是，如果代碼要長期保持可用，原始開發人員應該繼續爲代碼負責。 + +內核開發人員（或他們的僱主）犯的最大錯誤之一是試圖將流程簡化爲一個「合併到 +主線」步驟。這種方法總是會讓所有相關人員感到沮喪。 + +補丁如何進入內核 +---------------- + +只有一個人可以將補丁合併到主線內核存儲庫中：LinusTorvalds。但是，在進入 +2.6.38內核的9500多個補丁中，只有112個（大約1.3%）是由Linus自己直接選擇的。 +內核項目已經發展到一個沒有一個開發人員可以在沒有支持的情況下檢查和選擇每個 +補丁的規模。內核開發人員處理這種增長的方式是使用圍繞信任鏈構建的助理系統。 + +內核代碼庫在邏輯上被分解爲一組子系統：網絡、特定體系結構支持、內存管理、視 +頻設備等。大多數子系統都有一個指定的維護人員，其總體負責該子系統中的代碼。 +這些子系統維護者（鬆散地）是他們所管理的內核部分的「守門員」；他們（通常） +會接受一個補丁以包含到主線內核中。 + +子系統維護人員每個人都管理著自己版本的內核原始碼樹，通常（並非總是）使用Git。 +Git等工具（以及Quilt或Mercurial等相關工具）允許維護人員跟蹤補丁列表，包括作者 +信息和其他元數據。在任何給定的時間，維護人員都可以確定他或她的存儲庫中的哪 +些補丁在主線中找不到。 + +當合併窗口打開時，頂級維護人員將要求Linus從存儲庫中「拉出」他們爲合併選擇 +的補丁。如果Linus同意，補丁流將流向他的存儲庫，成爲主線內核的一部分。 +Linus對拉取中接收到的特定補丁的關注程度各不相同。很明顯，有時他看起來很 +關注。但是一般來說，Linus相信子系統維護人員不會向上游發送壞補丁。 + +子系統維護人員反過來也可以從其他維護人員那裡獲取補丁。例如，網絡樹是由首先 +在專用於網絡設備驅動程序、無線網絡等的樹中積累的補丁構建的。此存儲鏈可以 +任意長，但很少超過兩個或三個連結。由於鏈中的每個維護者都信任那些管理較低 +級別樹的維護者，所以這個過程稱爲「信任鏈」。 + +顯然，在這樣的系統中，獲取內核補丁取決於找到正確的維護者。直接向Linus發送 +補丁通常不是正確的方法。 + +Next 樹 +------- + +子系統樹鏈引導補丁流到內核，但它也提出了一個有趣的問題：如果有人想查看爲 +下一個合併窗口準備的所有補丁怎麼辦？開發人員將感興趣的是，還有什麼其他的 +更改有待解決，以了解是否存在需要擔心的衝突；例如，更改核心內核函數原型的 +修補程序將與使用該函數舊形式的任何其他修補程序衝突。審查人員和測試人員希望 +在所有這些變更到達主線內核之前，能夠訪問它們的集成形式的變更。您可以從所有 +相關的子系統樹中提取更改，但這將是一項複雜且容易出錯的工作。 + +解決方案以-next樹的形式出現，在這裡子系統樹被收集以供測試和審查。這些樹中 +由Andrew Morton維護的較老的一個，被稱爲「-mm」（用於內存管理，創建時爲此）。 +-mm 樹集成了一長串子系統樹中的補丁；它還包含一些旨在幫助調試的補丁。 + +除此之外，-mm 還包含大量由Andrew直接選擇的補丁。這些補丁可能已經發布在郵件 +列表上，或者它們可能應用於內核中未指定子系統樹的部分。同時，-mm 作爲最後 +手段的子系統樹；如果沒有其他明顯的路徑可以讓補丁進入主線，那麼它很可能最 +終選擇-mm 樹。累積在-mm 中的各種補丁最終將被轉發到適當的子系統樹，或者直接 +發送到Linus。在典型的開發周期中，大約5-10%的補丁通過-mm 進入主線。 + +當前-mm 補丁可在「mmotm」（-mm of the moment）目錄中找到： + + https://www.ozlabs.org/~akpm/mmotm/ + +然而，使用MMOTM樹可能會十分令人頭疼；它甚至可能無法編譯。 + +下一個周期補丁合併的主要樹是linux-next，由Stephen Rothwell 維護。根據設計 +linux-next 是下一個合併窗口關閉後主線的快照。linux-next樹在Linux-kernel 和 +Linux-next 郵件列表中發布，可從以下位置下載： + + https://www.kernel.org/pub/linux/kernel/next/ + +Linux-next 已經成爲內核開發過程中不可或缺的一部分；在一個給定的合併窗口中合併 +的所有補丁都應該在合併窗口打開之前的一段時間內找到進入Linux-next 的方法。 + +Staging 樹 +---------- + +內核原始碼樹包含drivers/staging/目錄，其中有許多驅動程序或文件系統的子目錄 +正在被添加到內核樹中。它們在仍然需要更多的修正的時候可以保留在driver/staging/ +目錄中；一旦完成，就可以將它們移到內核中。這是一種跟蹤不符合Linux內核編碼或 +質量標準的驅動程序的方法，人們可能希望使用它們並跟蹤開發。 + +Greg Kroah Hartman 目前負責維護staging 樹。仍需要修正的驅動程序將發送給他， +每個驅動程序在drivers/staging/中都有自己的子目錄。除了驅動程序源文件之外， +目錄中還應該有一個TODO文件。TODO文件列出了驅動程序需要接受的暫停的工作， +以及驅動程序的任何補丁都應該抄送的人員列表。當前的規則要求，staging的驅動 +程序必須至少正確編譯。 + +Staging 是一種讓新的驅動程序進入主線的相對容易的方法，它們會幸運地引起其他 +開發人員的注意，並迅速改進。然而，進入staging並不是故事的結尾；staging中 +沒有看到常規進展的代碼最終將被刪除。經銷商也傾向於相對不願意使用staging驅動 +程序。因此，在成爲一個合適的主線驅動的路上，staging 僅是一個中轉站。 + +工具 +---- + +從上面的文本可以看出，內核開發過程在很大程度上依賴於在不同方向上聚集補丁的 +能力。如果沒有適當強大的工具，整個系統將無法在任何地方正常工作。關於如何使用 +這些工具的教程遠遠超出了本文檔的範圍，但還是用一點篇幅介紹一些關鍵點。 + +到目前爲止，內核社區使用的主要原始碼管理系統是git。Git是在自由軟體社區中開發 +的許多分布式版本控制系統之一。它非常適合內核開發，因爲它在處理大型存儲庫和 +大量補丁時性能非常好。它也以難以學習和使用而著稱，儘管隨著時間的推移它變得 +更好了。對於內核開發人員來說，對Git的某種熟悉幾乎是一種要求；即使他們不將它 +用於自己的工作，他們也需要Git來跟上其他開發人員（以及主線）正在做的事情。 + +現在幾乎所有的Linux發行版都打包了Git。Git主頁位於： + + https://git-scm.com/ + +此頁面包含了文檔和教程的連結。 + +在不使用git的內核開發人員中，最流行的選擇幾乎肯定是Mercurial： + + http://www.seleric.com/mercurial/ + +Mercurial與Git共享許多特性，但它提供了一個界面，許多人覺得它更易於使用。 + +另一個值得了解的工具是Quilt: + + https://savannah.nongnu.org/projects/quilt + +Quilt 是一個補丁管理系統，而不是原始碼管理系統。它不會隨著時間的推移跟蹤歷史； +相反，它面向根據不斷發展的代碼庫跟蹤一組特定的更改。一些主要的子系統維護人員 +使用Quilt來管理打算向上游移動的補丁。對於某些樹的管理（例如-mm），quilt 是 +最好的工具。 + +郵件列表 +-------- + +大量的Linux內核開發工作是通過郵件列表完成的。如果不加入至少一個某個列表， +就很難成爲社區中的一個「全功能」成員。但是，Linux郵件列表對開發人員來說也是 +一個潛在的危險，他們可能會被一堆電子郵件淹沒、違反Linux列表上使用的約定， +或者兩者兼而有之。 + +大多數內核郵件列表都在vger.kernel.org上運行；主列表位於： + + http://vger.kernel.org/vger-lists.html + +不過，也有一些列表託管在別處；其中一些列表位於 +redhat.com/mailman/listinfo。 + +當然，內核開發的核心郵件列表是linux-kernel。這個列表是一個令人生畏的地方： +每天的信息量可以達到500條，噪音很高，談話技術性很強，且參與者並不總是表現出 +高度的禮貌。但是，沒有其他地方可以讓內核開發社區作爲一個整體聚集在一起； +不使用此列表的開發人員將錯過重要信息。 + +以下一些提示可以幫助在linux-kernel生存： + +- 將郵件轉移到單獨的文件夾，而不是主郵箱文件夾。我們必須能夠持續地忽略洪流。 + +- 不要試圖跟上每一次談話——沒人會這樣。重要的是要篩選感興趣的主題（但請注意 + 長時間的對話可能會偏離原來的主題，儘管未改變電子郵件的主題）和參與的人。 + +- 不要回復挑事的人。如果有人試圖激起憤怒，請忽略他們。 + +- 當回復Linux內核電子郵件（或其他列表上的電子郵件）時，請爲所有相關人員保留 + Cc: 抄送頭。如果沒有確實的理由（如明確的請求），則不應刪除收件人。一定要 + 確保你要回復的人在抄送列表中。這個慣例也使你不必在回覆郵件時明確要求被抄送。 + +- 在提出問題之前，搜索列表存檔（和整個網絡）。有些開發人員可能會對那些顯然 + 沒有完成家庭作業的人感到不耐煩。 + +- 避免頂部回復（把你的答案放在你要回復的引文上面的做法）。這會讓你的回答更難 + 理解，印象也很差。 + +- 在正確的郵件列表發問。linux-kernel 可能是通用的討論場所，但它不是尋找所有 + 子系統開發人員的最佳場所。 + +最後一點——找到正確的郵件列表——是開發人員常出錯的地方。在linux-kernel上 +提出與網絡相關的問題的人幾乎肯定會收到一個禮貌的建議，轉到netdev列表上提出， +因爲這是大多數網絡開發人員經常出現的列表。還有其他列表可用於scsi、video4linux、 +ide、filesystem等子系統。查找郵件列表的最佳位置是與內核原始碼一起打包的 +MAINTAINERS文件。 + +開始內核開發 +------------ + +關於如何開始內核開發過程的問題很常見——個人和公司皆然。同樣常見的是失誤，這 +使得關係的開始比本應的更困難。 + +公司通常希望聘請知名的開發人員來啓動開發團隊。實際上，這是一種有效的技術。 +但它也往往是昂貴的，而且對增加有經驗的內核開發人員的數量沒有多大幫助。考 +慮到時間投入，可以讓內部開發人員加快Linux內核的開發速度。利用這段時間可以 +讓僱主擁有一批既了解內核又了解公司的開發人員，還可以幫助培訓其他人。從中期 +來看，這通常是更有利可圖的方法。 + +可以理解的是，單個開發人員往往對起步感到茫然。從一個大型項目開始可能會很 +嚇人；人們往往想先用一些較小的東西來試試水。由此，一些開發人員開始創建修補 +拼寫錯誤或輕微編碼風格問題的補丁。不幸的是，這樣的補丁會產生一定程度的噪音， +這會分散整個開發社區的注意力，因此，它們越來越被人不看重。希望向社區介紹 +自己的新開發人員將無法通過這些方式獲得他們期待的反響。 + +Andrew Morton 爲有抱負的內核開發人員提供了如下建議 + +:: + + 所有內核開發者的第一個項目肯定應該是「確保內核在您可以操作的所有 + 機器上始終完美運行」。通常的方法是和其他人一起解決問題（這可能需 + 要堅持！），但就是如此——這是內核開發的一部分。 + +(http://lwn.net/articles/283982/) + +在沒有明顯問題需要解決的情況下，通常建議開發人員查看當前的回歸和開放缺陷 +列表。從來都不缺少需要解決的問題；通過解決這些問題，開發人員將從該過程獲得 +經驗，同時與開發社區的其他成員建立相互尊重。 + diff --git a/Documentation/translations/zh_TW/process/3.Early-stage.rst b/Documentation/translations/zh_TW/process/3.Early-stage.rst new file mode 100644 index 000000000000..ab2a45fd65a4 --- /dev/null +++ b/Documentation/translations/zh_TW/process/3.Early-stage.rst @@ -0,0 +1,172 @@ +.. SPDX-License-Identifier: GPL-2.0 + +.. include:: ../disclaimer-zh_TW.rst + +:Original: :ref:`Documentation/process/3.Early-stage.rst ` + +:Translator: + + 時奎亮 Alex Shi + +:校譯: + + 吳想成 Wu XiangCheng + 胡皓文 Hu Haowen + +.. _tw_development_early_stage: + +早期規劃 +======== + +當考慮一個Linux內核開發項目時，很可能會直接跳進去開始編碼。然而，與任何重要 +的項目一樣，許多成功的基礎最好是在第一行代碼編寫之前就打下。在早期計劃和 +溝通中花費一些時間可以在之後節省更多的時間。 + +搞清問題 +-------- + +與任何工程項目一樣，成功的內核改善從清晰描述要解決的問題開始。在某些情況 +下，這個步驟很容易：例如當某個特定硬體需要驅動程序時。不過，在其他情況下， +很容易將實際問題與建議的解決方案混在一起，這可能會導致麻煩。 + +舉個例子：幾年前，Linux音頻的開發人員尋求一種方法來運行應用程式，而不會因 +系統延遲過大而導致退出或其他問題。他們得到的解決方案是一個連接到Linux安全 +模塊（LSM）框架中的內核模塊；這個模塊可以配置爲允許特定的應用程式訪問實時 +調度程序。這個模塊被實現並發到linux-kernel郵件列表，在那裡它立即遇到了麻煩。 + +對於音頻開發人員來說，這個安全模塊足以解決他們當前的問題。但是，對於更廣泛的 +內核社區來說，這被視爲對LSM框架的濫用（LSM框架並不打算授予他們原本不具備的 +進程特權），並對系統穩定性造成風險。他們首選的解決方案包括短期的通過rlimit +機制進行實時調度訪問，以及長期的減少延遲的工作。 + +然而，音頻社區無法超越他們實施的特定解決方案來看問題；他們不願意接受替代方案。 +由此產生的分歧使這些開發人員對整個內核開發過程感到失望；其中一個開發人員返回 +到audio列表並發布了以下內容： + + 有很多非常好的Linux內核開發人員，但他們往往會被一羣傲慢的傻瓜所壓倒。 + 試圖向這些人傳達用戶需求是浪費時間。他們太「聰明」了，根本聽不到少數 + 人的話。 + +（http://lwn.net/articles/131776/） + +實際情況卻是不同的；與特定模塊相比，內核開發人員更關心系統穩定性、長期維護 +以及找到問題的正確解決方案。這個故事的寓意是把重點放在問題上——而不是具體的 +解決方案上——並在開始編寫代碼之前與開發社區討論這個問題。 + +因此，在考慮一個內核開發項目時，我們應該得到一組簡短問題的答案： + + - 需要解決的問題究竟是什麼？ + + - 受此問題影響的用戶有哪些？解決方案應該解決哪些使用案例？ + + - 內核現在爲何沒能解決這個問題？ + +只有這樣，才能開始考慮可能的解決方案。 + + +早期討論 +-------- + +在計劃內核開發項目時，在開始實施之前與社區進行討論是很有意義的。早期溝通可以 +通過多種方式節省時間和麻煩： + + - 很可能問題是由內核以您不理解的方式解決的。Linux內核很大，具有許多不明顯 + 的特性和功能。並不是所有的內核功能都像人們所希望的那樣有文檔記錄，而且很 + 容易遺漏一些東西。某作者發布了一個完整的驅動程序，重複了一個其不 + 知道的現有驅動程序。重新發明現有輪子的代碼不僅浪費，而且不會被接受到主線 + 內核中。 + + - 建議的解決方案中可能有一些要素不適合併入主線。在編寫代碼之前，最好先了解 + 這樣的問題。 + + - 其他開發人員完全有可能考慮過這個問題；他們可能有更好的解決方案的想法，並且 + 可能願意幫助創建這個解決方案。 + +在內核開發社區的多年經驗給了我們一個明確的教訓：閉門設計和開發的內核代碼總是 +有一些問題，這些問題只有在代碼發布到社區中時才會被發現。有時這些問題很嚴重， +需要數月或數年的努力才能使代碼達到內核社區的標準。例如： + + - 設計並實現了單處理器系統的DeviceScape網絡棧。只有使其適合於多處理器系統， + 才能將其合併到主線中。在代碼中修改鎖等等是一項困難的任務；因此，這段代碼 + （現在稱爲mac80211）的合併被推遲了一年多。 + + - Reiser4文件系統包含許多功能，核心內核開發人員認爲這些功能應該在虛擬文件 + 系統層中實現。它還包括一些特性，這些特性在不將系統暴露於用戶引起的死鎖的 + 情況下是不容易實現的。這些問題過遲發現——以及拒絕處理其中一些問題——已經 + 導致Reiser4置身主線內核之外。 + + - Apparmor安全模塊以被認爲不安全和不可靠的方式使用內部虛擬文件系統數據結構。 + 這種擔心（包括其他）使Apparmor多年來無法進入主線。 + +在這些情況下，與內核開發人員的早期討論，可以避免大量的痛苦和額外的工作。 + +找誰交流？ +---------- + +當開發人員決定公開他們的計劃時，下一個問題是：我們從哪裡開始？答案是找到正確 +的郵件列表和正確的維護者。對於郵件列表，最好的方法是在維護者(MAINTAINERS)文件 +中查找要發布的相關位置。如果有一個合適的子系統列表，那麼其上發布通常比在 +linux-kernel上發布更可取；您更有可能接觸到在相關子系統中具有專業知識的開發 +人員，並且環境可能具支持性。 + +找到維護人員可能會有點困難。同樣，維護者文件是開始的地方。但是，該文件往往不 +是最新的，並且並非所有子系統都在那裡顯示。實際上，維護者文件中列出的人員可能 +不是當前實際擔任該角色的人員。因此，當對聯繫誰有疑問時，一個有用的技巧是使用 +git（尤其是「git-log」）查看感興趣的子系統中當前活動的用戶。看看誰在寫補丁、 +誰會在這些補丁上加上Signed-off-by行簽名（如有）。這些人將是幫助新開發項目的 +最佳人選。 + +找到合適的維護者有時是非常具有挑戰性的，以至於內核開發人員添加了一個腳本來 +簡化這個過程： + +:: + + .../scripts/get_maintainer.pl + +當給定「-f」選項時，此腳本將返回指定文件或目錄的當前維護者。如果在命令行上 +給出了一個補丁，它將列出可能接收補丁副本的維護人員。有許多選項可以調節 +get_maintainer.pl搜索維護者的嚴格程度；請小心使用更激進的選項，因爲最終結果 +可能會包括對您正在修改的代碼沒有真正興趣的開發人員。 + +如果所有其他方法都失敗了，那麼與Andrew Morton交流是跟蹤特定代碼段維護人員 +的一種有效方法。 + +何時郵寄？ +---------- + +如果可能的話，在早期階段發布你的計劃只會更有幫助。描述正在解決的問題以及已經 +制定的關於如何實施的任何計劃。您可以提供的任何信息都可以幫助開發社區爲項目 +提供有用的輸入。 + +在這個階段可能發生的一件令人沮喪的事情不是得到反對意見，而是很少或根本沒有 +反饋。令人傷心的事實是：（1）內核開發人員往往很忙；（2）不缺少有宏偉計劃但 +代碼（甚至代碼設想）很少的人去支持他們；（3）沒有人有義務審查或評論別人發表 +的想法。除此之外，高層級的設計常常隱藏著一些問題，這些問題只有在有人真正嘗試 +實現這些設計時才會被發現；因此，內核開發人員寧願看到代碼。 + +如果發布請求評論（RFC）並沒得到什麼有用的評論，不要以爲這意味著無人對此項目 +有興趣，同時你也不能假設你的想法沒有問題。在這種情況下，最好的做法是繼續進 +行，把你的進展隨時通知社區。 + +獲得官方認可 +----------------------- + +如果您的工作是在公司環境中完成的，就像大多數Linux內核工作一樣；顯然，在您將 +公司的計劃或代碼發布到公共郵件列表之前，必須獲得有適當權利經理的許可。發布 +不確定是否兼容GPL的代碼尤其會帶來問題；公司的管理層和法律人員越早能夠就發布 +內核開發項目達成一致，對參與的每個人都越好。 + +一些讀者可能會認爲他們的核心工作是爲了支持還沒有正式承認存在的產品。將僱主 +的計劃公布在公共郵件列表上可能不是一個可行的選擇。在這種情況下，有必要考慮 +保密是否真的是必要的；通常不需要把開發計劃關在門內。 + +的確，有些情況下一家公司在開發過程的早期無法合法地披露其計劃。擁有經驗豐富 +的內核開發人員的公司可能選擇以開環的方式進行開發，前提是他們以後能夠避免 +嚴重的集成問題。對於沒有這種內部專業知識的公司，最好的選擇往往是聘請外部 +開發者根據保密協議審查計劃。Linux基金會運行了一個NDA程序，旨在幫助解決這種 +情況；更多信息參見： + + http://www.linuxfoundation.org/nda/ + +這種審查通常足以避免以後出現嚴重問題，而無需公開披露項目。 + diff --git a/Documentation/translations/zh_TW/process/4.Coding.rst b/Documentation/translations/zh_TW/process/4.Coding.rst new file mode 100644 index 000000000000..ccc3946227a0 --- /dev/null +++ b/Documentation/translations/zh_TW/process/4.Coding.rst @@ -0,0 +1,297 @@ +.. SPDX-License-Identifier: GPL-2.0 + +.. include:: ../disclaimer-zh_TW.rst + +:Original: :ref:`Documentation/process/4.Coding.rst ` + +:Translator: + + 時奎亮 Alex Shi + +:校譯: + + 吳想成 Wu XiangCheng + 胡皓文 Hu Haowen + +.. _tw_development_coding: + +使代碼正確 +====================== + +雖然一個堅實的、面向社區的設計過程有很多值得說道的，但是任何內核開發項目工作 +的證明都反映在代碼中。它是將由其他開發人員檢查併合並（或不合併）到主線樹中 +的代碼。所以這段代碼的質量決定了項目的最終成功。 + +本節將檢查編碼過程。我們將從內核開發人員常犯的幾種錯誤開始。然後重點將轉移 +到正確的做法和相關有用的工具上。 + +陷阱 +---- + +代碼風格 +******** + +內核長期以來都有其標準的代碼風格，如 +:ref:`Documentation/translations/zh_TW/process/coding-style.rst ` +中所述。在多數時候，該文檔中描述的準則至多被認爲是建議性的。因此，內核中存在 +大量不符合代碼風格準則的代碼。這種代碼的存在會給內核開發人員帶來兩方面的危害。 + +首先，相信內核代碼標準並不重要，也不強制執行。但事實上，如果沒有按照標準 +編寫代碼，那麼新代碼將很難加入到內核中；許多開發人員甚至會在審查代碼之前要求 +對代碼進行重新格式化。一個像內核這麼大的代碼庫需要一些統一格式的代碼，以使 +開發人員能夠快速理解其中的任何部分。所以再也經不起奇怪格式的代碼的折騰了。 + +內核的代碼風格偶爾會與僱主的強制風格發生衝突。在這種情況下，必須在代碼合併 +之前遵從內核代碼風格。將代碼放入內核意味著以多種方式放棄一定程度的控制權—— +包括控制代碼樣式。 + +另一個危害是認爲已經在內核中的代碼迫切需要修復代碼樣式。開發者可能會開始編寫 +重新格式化補丁，作爲熟悉開發過程的一種方式，或者作爲將其名字寫入內核變更日誌 +的一種方式，或者兩者兼而有之。但是純代碼風格的修復被開發社區視爲噪音，它們往 +往受到冷遇。因此，最好避免編寫這種類型的補丁。在由於其他原因處理一段代碼的 +同時順帶修復其樣式是很自然的，但是不應該僅爲了更改代碼樣式而更改之。 + +代碼風格文檔也不應該被視爲絕對不可違反的規則。如果有一個足夠的理由反對這種 +樣式（例如爲了80列限制拆分行會導致可讀性大大降低），那麼就這樣做吧。 + +注意您還可以使用 ``clang-format`` 工具來幫助您處理這些規則，快速自動重新格式 +化部分代碼，和審閱完整的文件以發現代碼樣式錯誤、拼寫錯誤和可能的改進。它還 +可以方便地排序 ``#includes`` 、對齊變量/宏、重排文本和其他類似任務。有關詳細 +信息，請參閱文檔 :ref:`Documentation/process/clang-format.rst ` + +抽象層 +****** + +計算機科學教授教學生以靈活性和信息隱藏的名義廣泛使用抽象層。當然，內核廣泛 +地使用了抽象；任何涉及數百萬行代碼的項目都必須做到這一點以存續下來。但經驗 +表明，過度或過早的抽象可能和過早的優化一樣有害。抽象應用在適當層級， +不要過度。 + +簡單點，先考慮一個調用時始終只有一個參數且總爲零的函數。我們可以保留這個參數， +以在需要使用它時提供的額外靈活性。不過，在那時實現了這個額外參數的代碼很有 +可能以某種從未被注意到的微妙方式被破壞——因爲它從未被使用過。或者當需要額外 +的靈活性時，它並未以符合程式設計師當初期望的方式來實現。內核開發人員通常會提交 +補丁來刪除未使用的參數；一般來說，一開始就不應該添加這些參數。 + +隱藏硬體訪問的抽象層——通常爲了允許大量的驅動程序兼容多個作業系統——尤其不受 +歡迎。這樣的層使代碼變得模糊，可能會造成性能損失；它們不屬於Linux內核。 + +另一方面，如果您發現自己從另一個內核子系統複製了大量的代碼，那麼是時候 +了解一下：是否需要將這些代碼中的部分提取到單獨的庫中，或者在更高的層次上 +實現這些功能。在整個內核中複製相同的代碼沒有價值。 + +#ifdef 和預處理 +*************** + +C預處理器似乎給一些C程式設計師帶來了強大的誘惑，他們認爲它是一種將大量靈活性加入 +原始碼中的方法。但是預處理器不是C，大量使用它會導致代碼對其他人來說更難閱讀， +對編譯器來說更難檢查正確性。使用了大量預處理器幾乎總是代碼需要一些 +清理工作的標誌。 + +使用#ifdef的條件編譯實際上是一個強大的功能，它在內核中使用。但是很少有人希望 +看到代碼被鋪滿#ifdef塊。一般規定，ifdef的使用應儘可能限制在頭文件中。條件 +編譯代碼可以限制函數，如果代碼不存在，這些函數就直接變成空的。然後編譯器將 +悄悄地優化對空函數的調用。使得代碼更加清晰，更容易理解。 + +C預處理器宏存在許多危險性，包括可能對具有副作用且沒有類型安全的表達式進行多 +重評估。如果您試圖定義宏，請考慮創建一個內聯函數替代。結果相同的代碼，內聯 +函數更容易閱讀，不會多次計算其參數，並且允許編譯器對參數和返回值執行類型檢查。 + +內聯函數 +******** + +不過，內聯函數本身也存在風險。程式設計師可以傾心於避免函數調用和用內聯函數填充源 +文件所固有的效率。然而，這些功能實際上會降低性能。因爲它們的代碼在每個調用站 +點都被複製一遍，所以最終會增加編譯內核的大小。此外，這也對處理器的內存緩存 +造成壓力，從而大大降低執行速度。通常內聯函數應該非常小，而且相對較少。畢竟 +函數調用的成本並不高；大量創建內聯函數是過早優化的典型例子。 + +一般來說，內核程式設計師會自冒風險忽略緩存效果。在數據結構課程開頭中的經典 +時間/空間權衡通常不適用於當代硬體。空間 *就是* 時間，因爲一個大的程序比一個 +更緊湊的程序運行得慢。 + +較新的編譯器越來越激進地決定一個給定函數是否應該內聯。因此，隨意放置使用 +「inline」關鍵字可能不僅僅是過度的，也可能是無用的。 + +鎖 +** + +2006年5月，「deviceescape」網絡堆棧在前呼後擁下以GPL發布，並被納入主線內核。 +這是一個受歡迎的消息；Linux中對無線網絡的支持充其量被認爲是不合格的，而 +Deviceescape堆棧承諾修復這種情況。然而直到2007年6月（2.6.22），這段代碼才真 +正進入主線。發生了什麼？ + +這段代碼出現了許多閉門造車的跡象。但一個大麻煩是，它並不是爲多處理器系統而 +設計。在合併這個網絡堆棧（現在稱爲mac80211）之前，需要對其進行一個鎖方案的 +改造。 + +曾經，Linux內核代碼可以在不考慮多處理器系統所帶來的並發性問題的情況下進行 +開發。然而現在，這個文檔就是在雙核筆記本電腦上寫的。即使在單處理器系統上， +爲提高響應能力所做的工作也會提高內核內的並發性水平。編寫內核代碼而不考慮鎖 +的日子早已遠去。 + +可以由多個線程並發訪問的任何資源（數據結構、硬體寄存器等）必須由鎖保護。新 +的代碼應該謹記這一要求；事後修改鎖是一項相當困難的任務。內核開發人員應該花 +時間充分了解可用的鎖原語，以便爲工作選擇正確的工具。對並發性缺乏關注的代碼 +很難進入主線。 + +回歸 +**** + +最後一個值得一提的危險是回歸：它可能會引起導致現有用戶的某些東西中斷的改變 +（這也可能會帶來很大的改進）。這種變化被稱爲「回歸」，回歸已經成爲主線內核 +最不受歡迎的問題。除了少數例外情況，如果回歸不能及時修正，會導致回歸的修改 +將被取消。最好首先避免回歸發生。 + +人們常常爭論，如果回歸帶來的功能遠超過產生的問題，那麼回歸是否爲可接受的。 +如果它破壞了一個系統卻爲十個系統帶來新的功能，爲何不改改態度呢？2007年7月， +Linus對這個問題給出了最佳答案: + +:: + + 所以我們不會通過引入新問題來修復錯誤。這種方式是靠不住的，沒人知道 + 是否真的有進展。是前進兩步、後退一步，還是前進一步、後退兩步？ + +（http://lwn.net/articles/243460/） + +特別不受歡迎的一種回歸類型是用戶空間ABI的任何變化。一旦接口被導出到用戶空間， +就必須無限期地支持它。這一事實使得用戶空間接口的創建特別具有挑戰性：因爲它們 +不能以不兼容的方式進行更改，所以必須一次就對。因此，用戶空間接口總是需要大量 +的思考、清晰的文檔和廣泛的審查。 + + +代碼檢查工具 +------------ + +至少目前，編寫無錯誤代碼仍然是我們中很少人能達到的理想狀態。不過，我們希望做 +的是，在代碼進入主線內核之前，儘可能多地捕獲並修復這些錯誤。爲此，內核開發人 +員已經提供了一系列令人印象深刻的工具，可以自動捕獲各種各樣的隱藏問題。計算機 +發現的任何問題都是一個以後不會困擾用戶的問題，因此，只要有可能，就應該使用 +自動化工具。 + +第一步是注意編譯器產生的警告。當前版本的GCC可以檢測（並警告）大量潛在錯誤。 +通常，這些警告都指向真正的問題。提交以供審閱的代碼一般不會產生任何編譯器警告。 +在消除警告時，注意了解真正的原因，並儘量避免僅「修復」使警告消失而不解決其原因。 + +請注意，並非所有編譯器警告都默認啓用。使用「make KCFLAGS=-W」構建內核以 +獲得完整集合。 + +內核提供了幾個配置選項，可以打開調試功能；大多數配置選項位於「kernel hacking」 +子菜單中。對於任何用於開發或測試目的的內核，都應該啓用其中幾個選項。特別是， +您應該打開： + + - FRAME_WARN 獲取大於給定數量的堆棧幀的警告。 + 這些警告生成的輸出可能比較冗長，但您不必擔心來自內核其他部分的警告。 + + - DEBUG_OBJECTS 將添加代碼以跟蹤內核創建的各種對象的生命周期，並在出現問題 + 時發出警告。如果你要添加創建（和導出）關於其自己的複雜對象的子系統，請 + 考慮打開對象調試基礎結構的支持。 + + - DEBUG_SLAB 可以發現各種內存分配和使用錯誤；它應該用於大多數開發內核。 + + - DEBUG_SPINLOCK, DEBUG_ATOMIC_SLEEP 和 DEBUG_MUTEXES 會發現許多常見的 + 鎖錯誤。 + +還有很多其他調試選項，其中一些將在下面討論。其中一些有顯著的性能影響，不應 +一直使用。在學習可用選項上花費一些時間，可能會在短期內得到許多回報。 + +其中一個較重的調試工具是鎖檢查器或「lockdep」。該工具將跟蹤系統中每個鎖 +（spinlock或mutex）的獲取和釋放、獲取鎖的相對順序、當前中斷環境等等。然後， +它可以確保總是以相同的順序獲取鎖，相同的中斷假設適用於所有情況等等。換句話 +說，lockdep可以找到許多導致系統死鎖的場景。在部署的系統中，這種問題可能會 +很痛苦（對於開發人員和用戶而言）；LockDep允許提前以自動方式發現問題。具有 +任何類型的非普通鎖的代碼在提交合併前應在啓用lockdep的情況下運行測試。 + +作爲一個勤奮的內核程式設計師，毫無疑問，您將檢查任何可能失敗的操作（如內存分配） +的返回狀態。然而，事實上，最終的故障復現路徑可能完全沒有經過測試。未測試的 +代碼往往會出問題；如果所有這些錯誤處理路徑都被執行了幾次，那麼您可能對代碼 +更有信心。 + +內核提供了一個可以做到這一點的錯誤注入框架，特別是在涉及內存分配的情況下。 +啓用故障注入後，內存分配的可配置失敗的百分比；這些失敗可以限定在特定的代碼 +範圍內。在啓用了故障注入的情況下運行，程式設計師可以看到當情況惡化時代碼如何響 +應。有關如何使用此工具的詳細信息，請參閱 +Documentation/fault-injection/fault-injection.rst。 + +「sparse」靜態分析工具可以發現其他類型的錯誤。sparse可以警告程式設計師用戶空間 +和內核空間地址之間的混淆、大端序與小端序的混淆、在需要一組位標誌的地方傳遞 +整數值等等。sparse必須單獨安裝(如果您的分發伺服器沒有將其打包， +可以在 https://sparse.wiki.kernel.org/index.php/Main_page 找到）, +然後可以通過在make命令中添加「C=1」在代碼上運行它。 + +「Coccinelle」工具 :ref:`http://coccinelle.lip6.fr/ ` +能夠發現各種潛在的編碼問題；它還可以爲這些問題提出修複方案。在 +scripts/coccinelle目錄下已經打包了相當多的內核「語義補丁」；運行 +「make coccicheck」將運行這些語義補丁並報告發現的任何問題。有關詳細信息，請參閱 +:ref:`Documentation/dev-tools/coccinelle.rst ` + + +其他類型的可移植性錯誤最好通過爲其他體系結構編譯代碼來發現。如果沒有S/390系統 +或Blackfin開發板，您仍然可以執行編譯步驟。可以在以下位置找到一大堆用於x86系統的 +交叉編譯器： + + https://www.kernel.org/pub/tools/crosstool/ + +花一些時間安裝和使用這些編譯器將有助於避免以後的尷尬。 + +文檔 +---- + +文檔通常比內核開發規則更爲例外。即便如此，足夠的文檔將有助於簡化將新代碼合併 +到內核中的過程，使其他開發人員的生活更輕鬆，並對您的用戶有所幫助。在許多情況 +下，添加文檔已基本上是強制性的。 + +任何補丁的第一個文檔是其關聯的變更日誌。日誌條目應該描述正在解決的問題、解決 +方案的形式、處理補丁的人員、對性能的任何相關影響，以及理解補丁可能需要的任何 +其他內容。確保變更日誌說明了*爲什麼*補丁值得應用；大量開發者未能提供這些信息。 + +任何添加新用戶空間接口的代碼——包括新的sysfs或/proc文件——都應該包含該接口 +的文檔，該文檔使用戶空間開發人員能夠知道他們在使用什麼。請參閱 +Documentation/ABI/README，了解如何此文檔格式以及需要提供哪些信息。 + +文檔 :ref:`Documentation/admin-guide/kernel-parameters.rst ` +描述了內核的所有引導時間參數。任何添加新參數的補丁都應該向該文檔添加適當的 +條目。 + +任何新的配置選項都必須附有幫助文本，幫助文本需清楚地解釋這些選項以及用戶可能 +希望何時使用它們。 + +許多子系統的內部API信息通過專門格式化的注釋進行記錄；這些注釋可以通過 +「kernel-doc」腳本以多種方式提取和格式化。如果您在具有kerneldoc注釋的子系統中 +工作，則應該維護它們，並根據需要爲外部可用的功能添加它們。即使在沒有如此記錄 +的領域中，爲將來添加kerneldoc注釋也沒有壞處；實際上，這對於剛開始開發內核的人 +來說是一個有用的活動。這些注釋的格式以及如何創建kerneldoc模板的一些信息可以在 +:ref:`Documentation/doc-guide/ ` 上找到。 + +任何閱讀大量現有內核代碼的人都會注意到，注釋的缺失往往是最值得注意的。同時， +對新代碼的要求比過去更高；合併未注釋的代碼將更加困難。這就是說，人們並不期望 +詳細注釋的代碼。代碼本身應該是自解釋的，注釋闡釋了更微妙的方面。 + +某些事情應該總是被注釋。使用內存屏障時，應附上一行文字，解釋爲什麼需要設置內存 +屏障。數據結構的鎖規則通常需要在某個地方解釋。一般來說，主要數據結構需要全面 +的文檔。應該指出代碼中分立的位之間不明顯的依賴性。任何可能誘使代碼管理人進行 +錯誤的「清理」的事情都需要一個注釋來說明爲什麼要這樣做。等等。 + + +內部API更改 +----------- + +內核提供給用戶空間的二進位接口不能被破壞，除非逼不得已。而內核的內部編程接口 +是高度流動的，當需要時可以更改。如果你發現自己不得不處理一個內核API，或者僅 +僅因爲它不滿足你的需求導致無法使用特定的功能，這可能是API需要改變的一個標誌。 +作爲內核開發人員，您有權進行此類更改。 + +的確可以進行API更改，但更改必須是合理的。因此任何進行內部API更改的補丁都應該 +附帶關於更改內容和必要原因的描述。這種變化也應該拆分成一個單獨的補丁，而不是 +埋在一個更大的補丁中。 + +另一個要點是，更改內部API的開發人員通常要負責修復內核樹中被更改破壞的任何代碼。 +對於一個廣泛使用的函數，這個責任可以導致成百上千的變化，其中許多變化可能與其他 +開發人員正在做的工作相衝突。不用說，這可能是一項大工程，所以最好確保理由是 +可靠的。請注意，coccinelle工具可以幫助進行廣泛的API更改。 + +在進行不兼容的API更改時，應儘可能確保編譯器捕獲未更新的代碼。這將幫助您確保找 +到該接口的樹內用處。它還將警告開發人員樹外代碼存在他們需要響應的更改。支持樹外 +代碼不是內核開發人員需要擔心的事情，但是我們也不必使樹外開發人員的生活有不必要 +的困難。 + diff --git a/Documentation/translations/zh_TW/process/5.Posting.rst b/Documentation/translations/zh_TW/process/5.Posting.rst new file mode 100644 index 000000000000..5578bca403e6 --- /dev/null +++ b/Documentation/translations/zh_TW/process/5.Posting.rst @@ -0,0 +1,251 @@ +.. SPDX-License-Identifier: GPL-2.0 + +.. include:: ../disclaimer-zh_TW.rst + +:Original: :ref:`Documentation/process/5.Posting.rst ` + +:Translator: + + 時奎亮 Alex Shi + +:校譯: + + 吳想成 Wu XiangCheng + 胡皓文 Hu Haowen + +.. _tw_development_posting: + +發布補丁 +======== + +您的工作遲早會準備好提交給社區進行審查，並最終包含到主線內核中。毫不稀奇， +內核開發社區已經發展出一套用於發布補丁的約定和過程；遵循這些約定和過程將使 +參與其中的每個人的生活更加輕鬆。本文檔試圖描述這些約定的部分細節；更多信息 +也可在以下文檔中找到 +:ref:`Documentation/translations/zh_TW/process/submitting-patches.rst `， +:ref:`Documentation/translations/zh_TW/process/submitting-drivers.rst ` +和 :ref:`Documentation/translations/zh_TW/process/submit-checklist.rst `。 + +何時郵寄 +-------- + +在補丁完全「準備好」之前，避免發布補丁是一種持續的誘惑。對於簡單的補丁，這 +不是問題。但是如果正在完成的工作很複雜，那麼在工作完成之前從社區獲得反饋就 +可以獲得很多好處。因此，您應該考慮發布正在進行的工作，甚至維護一個可用的Git +樹，以便感興趣的開發人員可以隨時趕上您的工作。 + +當發布中有尚未準備好被包含的代碼，最好在發布中說明。還應提及任何有待完成的 +主要工作和任何已知問題。很少有人會願意看那些被認爲是半生不熟的補丁，但是 +那些願意的人會帶著他們的點子來一起幫助你把工作推向正確的方向。 + +創建補丁之前 +------------ + +在考慮將補丁發送到開發社區之前，有許多事情應該做。包括： + + - 儘可能地測試代碼。利用內核的調試工具，確保內核使用了所有可能的配置選項組合 + 進行構建，使用交叉編譯器爲不同的體系結構進行構建等。 + + - 確保您的代碼符合內核代碼風格指南。 + + - 您的更改是否具有性能影響？如果是這樣，您應該運行基準測試來顯示您的變更的 + 影響（或好處）；結果的摘要應該包含在補丁中。 + + - 確保您有權發布代碼。如果這項工作是爲僱主完成的，僱主對這項工作具有所有權， + 並且必須同意根據GPL對其進行發布。 + +一般來說，在發布代碼之前進行一些額外的思考，幾乎總是能在短時間內得到回報。 + +補丁準備 +-------- + +準備補丁發布的工作量可能很驚人，但在此嘗試節省時間通常是不明智的，即使在短期 +內亦然。 + +必須針對內核的特定版本準備補丁。一般來說，補丁應該基於Linus的Git樹中的當前 +主線。當以主線爲基礎時，請從一個衆所周知的發布點開始——如穩定版本或 -rc +版本發布點——而不是在一個任意的主線分支點。 + +也可能需要針對-mm、linux-next或子系統樹生成版本，以便於更廣泛的測試和審查。 +根據補丁的區域以及其他地方的情況，針對其他樹建立的補丁可能需要大量的工作來 +解決衝突和處理API更改。 + +只有最簡單的更改才應格式化爲單個補丁；其他所有更改都應作爲一系列邏輯更改進行。 +分割補丁是一門藝術；一些開發人員花了很長時間來弄清楚如何按照社區期望的方式來 +分割。不過，這些經驗法則也許有幫助： + + - 您發布的補丁系列幾乎肯定不會是開發過程中版本控制系統中的一系列更改。相反， + 需要對您所做更改的最終形式加以考慮，然後以有意義的方式進行拆分。開發人員對 + 離散的、自包含的更改感興趣，而不是您創造這些更改的原始路徑。 + + - 每個邏輯上獨立的變更都應該格式化爲單獨的補丁。這些更改可以是小的（如「向 + 此結構體添加欄位」）或大的（如添加一個重要的新驅動程序），但它們在概念上 + 應該是小的，並且可以在一行內簡述。每個補丁都應該做一個特定的、可以單獨 + 檢查並驗證它所做的事情的更改。 + + - 換種方式重申上述準則，也就是說：不要在同一補丁中混合不同類型的更改。如果 + 一個補丁修復了一個關鍵的安全漏洞，又重新排列了一些結構，還重新格式化了代 + 碼，那麼它很有可能會被忽略，從而導致重要的修復丟失。 + + - 每個補丁都應該能創建一個可以正確地構建和運行的內核；如果補丁系列在中間被 + 斷開，那麼結果仍應是一個正常工作的內核。部分應用一系列補丁是使用 + 「git bisct」工具查找回歸的一個常見場景；如果結果是一個損壞的內核，那麼將使 + 那些從事追蹤問題的高尚工作的開發人員和用戶的生活更加艱難。 + + - 不要過分分割。一位開發人員曾經將一組針對單個文件的編輯分成500個單獨的補丁 + 發布，這並沒有使他成爲內核郵件列表中最受歡迎的人。一個補丁可以相當大， + 只要它仍然包含一個單一的 *邏輯* 變更。 + + - 用一系列補丁添加一個全新的基礎設施，但是該設施在系列中的最後一個補丁啓用 + 整個變更之前不能使用，這看起來很誘人。如果可能的話，應該避免這種誘惑； + 如果這個系列增加了回歸，那麼二分法將指出最後一個補丁是導致問題的補丁， + 即使真正的bug在其他地方。只要有可能，添加新代碼的補丁程序應該立即激活該 + 代碼。 + +創建完美補丁系列的工作可能是一個令人沮喪的過程，在完成「真正的工作」之後需要 +花費大量的時間和思考。但是如果做得好，花費的時間就是值得的。 + +補丁格式和更改日誌 +------------------ + +所以現在你有了一系列完美的補丁可以發布，但是這項工作還沒有完成。每個補丁都 +需要被格式化成一條消息，以快速而清晰地將其目的傳達到世界其他地方。爲此， +每個補丁將由以下部分組成： + + - 可選的「From」行，表明補丁作者。只有當你通過電子郵件發送別人的補丁時，這一行 + 才是必須的，但是爲防止疑問加上它也不會有什麼壞處。 + + - 一行描述，說明補丁的作用。對於在沒有其他上下文的情況下看到該消息的讀者來說， + 該消息應足以確定修補程序的範圍；此行將顯示在「short form（簡短格式）」變更 + 日誌中。此消息通常需要先加上子系統名稱前綴，然後是補丁的目的。例如： + + :: + + gpio: fix build on CONFIG_GPIO_SYSFS=n + + - 一行空白，後接補丁內容的詳細描述。此描述可以是任意需要的長度；它應該說明補丁 + 的作用以及爲什麼它應該應用於內核。 + + - 一個或多個標記行，至少有一個由補丁作者的 Signed-off-by 簽名。標記將在下面 + 詳細描述。 + +上面的項目一起構成補丁的變更日誌。寫一則好的變更日誌是一門至關重要但常常被 +忽視的藝術；值得花一點時間來討論這個問題。當你編寫變更日誌時，你應該記住有 +很多不同的人會讀你的話。其中包括子系統維護人員和審查人員，他們需要決定是否 +應該合併補丁，分銷商和其他維護人員試圖決定是否應該將補丁反向移植到其他內核， +缺陷搜尋人員想知道補丁是否導致他們正在追查的問題，以及想知道內核如何變化的 +用戶等等。一個好的變更日誌以最直接和最簡潔的方式向所有這些人傳達所需的信息。 + +在結尾，總結行應該描述變更的影響和動機，以及在一行約束條件下可能發生的變化。 +然後，詳細的描述可以詳述這些主題，並提供任何需要的附加信息。如果補丁修復了 +一個缺陷，請引用引入該缺陷的提交（如果可能，請在引用提交時同時提供其 id 和 +標題）。如果某個問題與特定的日誌或編譯器輸出相關聯，請包含該輸出以幫助其他 +人搜索同一問題的解決方案。如果更改是爲了支持以後補丁中的其他更改，那麼應當 +說明。如果更改了內部API，請詳細說明這些更改以及其他開發人員應該如何響應。 +一般來說，你越把自己放在每個閱讀你變更日誌的人的位置上，變更日誌（和內核 +作爲一個整體）就越好。 + +不消說，變更日誌是將變更提交到版本控制系統時使用的文本。接下來將是： + + - 補丁本身，採用統一的（「-u」）補丁格式。使用「-p」選項來diff將使函數名與 + 更改相關聯，從而使結果補丁更容易被其他人讀取。 + +您應該避免在補丁中包括與更改不相關文件（例如，構建過程生成的文件或編輯器 +備份文件）。文檔目錄中的「dontdiff」文件在這方面有幫助；使用「-X」選項將 +其傳遞給diff。 + +上面提到的標籤（tag）用於描述各種開發人員如何與這個補丁的開發相關聯。 +:ref:`Documentation/translations/zh_TW/process/submitting-patches.rst ` +文檔中對它們進行了詳細描述；下面是一個簡短的總結。每一行的格式如下： + +:: + + tag: Full Name optional-other-stuff + +常用的標籤有： + + - Signed-off-by: 這是一個開發人員的證明，證明他或她有權提交補丁以包含到內核 + 中。這表明同意開發者來源認證協議，其全文見 + :ref:`Documentation/translations/zh_TW/process/submitting-patches.rst ` + 如果沒有合適的簽字，則不能合併到主線中。 + + - Co-developed-by: 聲明補丁是由多個開發人員共同創建的；當幾個人在一個補丁上 + 工作時，它用於給出共同作者（除了 From: 所給出的作者之外）。由於 + Co-developed-by: 表示作者身份，所以每個共同開發人，必須緊跟在相關合作作者 + 的Signed-off-by之後。具體內容和示例見以下文件 + :ref:`Documentation/translations/zh_TW/process/submitting-patches.rst ` + + - Acked-by: 表示另一個開發人員（通常是相關代碼的維護人員）同意補丁適合包含 + 在內核中。 + + - Tested-by: 聲明某人已經測試了補丁並確認它可以工作。 + + - Reviewed-by: 表示某開發人員已經審查了補丁的正確性；有關詳細信息，請參閱 + :ref:`Documentation/translations/zh_TW/process/submitting-patches.rst ` + + - Reported-by: 指定報告此補丁修復的問題的用戶；此標記用於表示感謝。 + + - Cc：指定某人收到了補丁的副本，並有機會對此發表評論。 + +在補丁中添加標籤時要小心：只有Cc:才適合在沒有指定人員明確許可的情況下添加。 + +發送補丁 +-------- + +在寄出補丁之前，您還需要注意以下幾點： + + - 您確定您的郵件發送程序不會損壞補丁嗎？被郵件客戶端更改空白或修飾了行的補丁 + 無法被另一端接受，並且通常不會進行任何詳細檢查。如果有任何疑問，先把補丁寄 + 給你自己，讓你自己確定它是完好無損的。 + + :ref:`Documentation/translations/zh_TW/process/email-clients.rst ` + 提供了一些有用的提示，可以讓特定的郵件客戶端正常發送補丁。 + + - 你確定你的補丁沒有荒唐的錯誤嗎？您應該始終通過scripts/checkpatch.pl檢查 + 補丁程序，並解決它提出的問題。請記住，checkpatch.pl，雖然體現了對內核補丁 + 應該是什麼樣的大量思考，但它並不比您聰明。如果修復checkpatch.pl給的問題會 + 使代碼變得更糟，請不要這樣做。 + +補丁應始終以純文本形式發送。請不要將它們作爲附件發送；這使得審閱者在答覆中更難 +引用補丁的部分。相反，只需將補丁直接放到您的消息中。 + +寄出補丁時，重要的是將副本發送給任何可能感興趣的人。與其他一些項目不同，內核 +鼓勵人們甚至錯誤地發送過多的副本；不要假定相關人員會看到您在郵件列表中的發布。 +尤其是，副本應發送至： + + - 受影響子系統的維護人員。如前所述，維護人員文件是查找這些人員的首選地方。 + + - 其他在同一領域工作的開發人員，尤其是那些現在可能在那裡工作的開發人員。使用 + git查看還有誰修改了您正在處理的文件，這很有幫助。 + + - 如果您對某錯誤報告或功能請求做出響應，也可以抄送原始發送人。 + + - 將副本發送到相關郵件列表，或者若無相關列表，則發送到linux-kernel列表。 + + - 如果您正在修復一個缺陷，請考慮該修復是否應進入下一個穩定更新。如果是這樣， + 補丁副本也應發到stable@vger.kernel.org 。另外，在補丁本身的標籤中添加一個 + 「Cc: stable@vger.kernel.org」；這將使穩定版團隊在修復進入主線時收到通知。 + +當爲一個補丁選擇接收者時，最好清楚你認爲誰最終會接受這個補丁並將其合併。雖然 +可以將補丁直接發給Linus Torvalds並讓他合併，但通常情況下不會這樣做。Linus很 +忙，並且有子系統維護人員負責監視內核的特定部分。通常您會希望維護人員合併您的 +補丁。如果沒有明顯的維護人員，Andrew Morton通常是最後的補丁接收者。 + +補丁需要好的主題行。補丁主題行的規範格式如下： + +:: + + [PATCH nn/mm] subsys: one-line description of the patch + +其中「nn」是補丁的序號，「mm」是系列中補丁的總數，「subsys」是受影響子系統的 +名稱。當然，一個單獨的補丁可以省略nn/mm。 + +如果您有一系列重要的補丁，那麼通常發送一個簡介作爲第〇部分。不過，這個約定 +並沒有得到普遍遵循；如果您使用它，請記住簡介中的信息不會進入內核變更日誌。 +因此，請確保補丁本身具有完整的變更日誌信息。 + +一般來說，多部分補丁的第二部分和後續部分應作爲對第一部分的回覆發送，以便它們 +在接收端都連接在一起。像git和coilt這樣的工具有命令，可以通過適當的線程發送 +一組補丁。但是，如果您有一長串補丁，並正使用git，請不要使用–-chain-reply-to +選項，以避免創建過深的嵌套。 + diff --git a/Documentation/translations/zh_TW/process/6.Followthrough.rst b/Documentation/translations/zh_TW/process/6.Followthrough.rst new file mode 100644 index 000000000000..4af782742db3 --- /dev/null +++ b/Documentation/translations/zh_TW/process/6.Followthrough.rst @@ -0,0 +1,156 @@ +.. SPDX-License-Identifier: GPL-2.0 + +.. include:: ../disclaimer-zh_TW.rst + +:Original: :ref:`Documentation/process/6.Followthrough.rst ` + +:Translator: + + 時奎亮 Alex Shi + +:校譯: + + 吳想成 Wu XiangCheng + 胡皓文 Hu Haowen + +.. _tw_development_followthrough: + +跟進 +==== + +此時，您已經遵循了到目前爲止給出的指導方針，並且，隨著您自己的工程技能的增加， +已經發布了一系列完美的補丁。即使是經驗豐富的內核開發人員也能犯的最大錯誤之一 +是，認爲他們的工作現在已經完成了。事實上，發布補丁意味著進入流程的下一個階段， +可能還需要做很多工作。 + +一個補丁在首次發布時就非常出色、沒有改進的餘地，這是很罕見的。內核開發流程已 +認識到這一事實，因此它非常注重對已發布代碼的改進。作爲代碼的作者，您應該與 +內核社區合作，以確保您的代碼符合內核的質量標準。如果不參與這個過程，很可能會 +無法將補丁合併到主線中。 + +與審閱者合作 +------------ + +任何意義上的補丁都會導致其他開發人員在審查代碼時發表大量評論。對於許多開發 +人員來說，與審閱人員合作可能是內核開發過程中最令人生畏的部分。但是如果你 +記住一些事情，生活會變得容易得多： + + - 如果你已經很好地解釋了你的補丁，審閱人員會理解它的價值，以及爲什麼你會 + 費盡心思去寫它。但是這個並不能阻止他們提出一個基本的問題：在五年或十年後 + 維護含有此代碼的內核會怎麼樣？你可能被要求做出的許多改變——從編碼風格的 + 調整到大量的重寫——都來自於對Linux的理解，即從現在起十年後，Linux仍將 + 在開發中。 + + - 代碼審查是一項艱苦的工作，這是一項相對吃力不討好的工作；人們記得誰編寫了 + 內核代碼，但對於那些審查它的人來說，幾乎沒有什麼長久的名聲。因此，審閱 + 人員可能會變得暴躁，尤其是當他們看到同樣的錯誤被一遍又一遍地犯下時。如果 + 你得到了一個看起來憤怒、侮辱或完全冒犯你的評論，請抑制以同樣方式回應的衝動。 + 代碼審查是關於代碼的，而不是關於人的，代碼審閱人員不會親自攻擊您。 + + - 同樣，代碼審閱人員也不想以犧牲你僱主的利益爲代價來宣傳他們僱主的議程。 + 內核開發人員通常希望今後幾年能在內核上工作，但他們明白他們的僱主可能會改 + 變。他們真的，幾乎毫無例外地，致力於創造他們所能做到的最好的內核；他們並 + 沒有試圖給僱主的競爭對手造成不適。 + +所有這些歸根結底就是，當審閱者向您發送評論時，您需要注意他們正在進行的技術 +評論。不要讓他們的表達方式或你自己的驕傲阻止此事。當你在一個補丁上得到評論 +時，花點時間去理解評論人想說什麼。如果可能的話，請修覆審閱者要求您修復的內 +容。然後回覆審閱者：謝謝他們，並描述你將如何回答他們的問題。 + +請注意，您不必同意審閱者建議的每個更改。如果您認爲審閱者誤解了您的代碼，請 +解釋到底發生了什麼。如果您對建議的更改有技術上的異議，請描述它並證明您對該 +問題的解決方案是正確的。如果你的解釋有道理，審閱者會接受的。不過，如果你的 +解釋證明缺乏說服力，尤其是當其他人開始同意審稿人的觀點時，請花些時間重新考慮 +一下。你很容易對自己解決問題的方法視而不見，以至於你沒有意識到某些東西完全 +是錯誤的，或者你甚至沒有解決正確的問題。 + +Andrew Morton建議，每一個不會導致代碼更改的審閱評論都應該產生一個額外的代碼 +注釋；這可以幫助未來的審閱人員避免第一次出現的問題。 + +一個致命的錯誤是忽視評論，希望它們會消失。它們不會走的。如果您在沒有對之前 +收到的評論做出響應的情況下重新發布代碼，那麼很可能會發現補丁毫無用處。 + +說到重新發布代碼：請記住，審閱者不會記住您上次發布的代碼的所有細節。因此， +提醒審閱人員以前提出的問題以及您如何處理這些問題總是一個好主意；補丁變更 +日誌是提供此類信息的好地方。審閱者不必搜索列表檔案來熟悉上次所說的內容； +如果您幫助他們直接開始，當他們重新查看您的代碼時，心情會更好。 + +如果你已經試著做正確的事情，但事情仍然沒有進展呢？大多數技術上的分歧都可以 +通過討論來解決，但有時人們仍需要做出決定。如果你真的認爲這個決定對你不利， +你可以試著向有更高權力的人上訴。對於本文，更高權力的人是 Andrew Morton 。 +Andrew 在內核開發社區中非常受尊敬；他經常爲似乎被絕望阻塞的事情清障。儘管 +如此，不應輕易就直接找 Andrew ，也不應在所有其他替代方案都被嘗試之前找他。 +當然，記住，他也可能不同意你的意見。 + +接下來會發生什麼 +---------------- + +如果一個補丁被認爲適合添加到內核中，並且大多數審查問題得到解決，下一步通常 +是進入子系統維護人員的樹中。工作方式因子系統而異；每個維護人員都有自己的 +工作方式。特別是可能有不止一棵樹——也許一棵樹專門用於計劃下一個合併窗口的 +補丁，另一棵樹用於長期工作。 + +對於應用到不屬於明顯子系統樹（例如內存管理修補程序）的區域的修補程序，默認樹 +通常上溯到-mm。影響多個子系統的補丁也可以最終進入-mm樹。 + +包含在子系統樹中可以提高補丁的可見性。現在，使用該樹的其他開發人員將默認獲 +得補丁。子系統樹通常也爲Linux提供支持，使其內容對整個開發社區可見。在這一點 +上，您很可能會從一組新的審閱者那裡得到更多的評論；這些評論需要像上一輪那樣 +得到回應。 + +在這時也會發生點什麼，這取決於你的補丁的性質，是否與其他人正在做的工作發生 +衝突。在最壞的情況下，嚴重的補丁衝突可能會導致一些工作被擱置，以便剩餘的補丁 +可以成形併合並。另一些時候，衝突解決將涉及到與其他開發人員合作，可能還會 +在樹之間移動一些補丁，以確保所有的應用都是乾淨的。這項工作可能是一件痛苦的 +事情，但也需慶幸現在的幸福：在linux-next樹出現之前，這些衝突通常只在合併窗口 +中出現，必須迅速解決。現在可以在合併窗口打開之前的空閒時間解決這些問題。 + +有朝一日，如果一切順利，您將登錄並看到您的補丁已經合併到主線內核中。祝賀你！ +然而，一旦慶祝完了（並且您已經將自己添加到維護人員文件中），就一定要記住 +一個重要的小事實：工作仍然沒有完成。併入主線也帶來了它的挑戰。 + +首先，補丁的可見性再次提高。可能會有以前不知道這個補丁的開發者的新一輪評論。 +忽略它們可能很有誘惑力，因爲您的代碼不再存在任何被合併的問題。但是，要抵制 +這種誘惑，您仍然需要對有問題或建議的開發人員作出響應。 + +不過，更重要的是：將代碼包含在主線中會將代碼交給更多的一些測試人員。即使您 +爲尚未可用的硬體提供了驅動程序，您也會驚訝於有多少人會將您的代碼構建到內核 +中。當然，如果有測試人員，也可能會有錯誤報告。 + +最糟糕的錯誤報告是回歸。如果你的補丁導致回歸，你會發現多到讓你不舒服的眼睛盯 +著你；回歸需要儘快修復。如果您不願意或無法修復回歸（其他人都不會爲您修復）， +那麼在穩定期內，您的補丁幾乎肯定會被移除。除了否定您爲使補丁進入主線所做的 +所有工作之外，如果由於未能修復回歸而取消補丁，很可能會使將來的工作更難被合併。 + +在處理完任何回歸之後，可能還有其他普通缺陷需要處理。穩定期是修復這些錯誤並 +確保代碼在主線內核版本中的首次發布儘可能可靠的最好機會。所以，請回應錯誤 +報告，並儘可能解決問題。這就是穩定期的目的；一旦解決了舊補丁的任何問題，就 +可以開始盡情創建新補丁。 + +別忘了，還有其他節點也可能會創建缺陷報告：下一個主線穩定版本，當著名的發行 +商選擇包含您補丁的內核版本時等等。繼續響應這些報告是您工作的基本素養。但是 +如果這不能提供足夠的動機，那麼也需要考慮：開發社區會記住那些在合併後對代碼 +失去興趣的開發人員。下一次你發布補丁時，他們會以你以後不會持續維護它爲前提 +來評估它。 + +其他可能發生的事情 +------------------ + +某天，當你打開你的郵件客戶端時，看到有人給你寄了一個代碼補丁。畢竟，這是 +讓您的代碼公開存在的好處之一。如果您同意這個補丁，您可以將它轉發給子系統 +維護人員（確保包含一個正確的From:行，這樣屬性是正確的，並添加一個您自己的 +signoff ），或者回復一個 Acked-by: 讓原始發送者向上發送它。 + +如果您不同意補丁，請禮貌地回復，解釋原因。如果可能的話，告訴作者需要做哪些 +更改才能讓您接受補丁。合併代碼的編寫者和維護者所反對的補丁的確存在著一定的 +阻力，但僅此而已。如果你被認爲不必要的阻礙了好的工作，那麼這些補丁最終會 +繞過你並進入主線。在Linux內核中，沒有人對任何代碼擁有絕對的否決權。可能除 +了Linus。 + +在非常罕見的情況下，您可能會看到完全不同的東西：另一個開發人員發布了針對您 +的問題的不同解決方案。在這時，兩個補丁之一可能不會被合併，「我的補丁首先 +發布」不被認爲是一個令人信服的技術論據。如果有別人的補丁取代了你的補丁而進 +入了主線，那麼只有一種方法可以回應你：很高興你的問題解決了，請繼續工作吧。 +以這種方式把某人的工作推到一邊可能導致傷心和氣餒，但是社區會記住你的反應， +即使很久以後他們已經忘記了誰的補丁真正被合併。 + diff --git a/Documentation/translations/zh_TW/process/7.AdvancedTopics.rst b/Documentation/translations/zh_TW/process/7.AdvancedTopics.rst new file mode 100644 index 000000000000..3de093d0f170 --- /dev/null +++ b/Documentation/translations/zh_TW/process/7.AdvancedTopics.rst @@ -0,0 +1,137 @@ +.. SPDX-License-Identifier: GPL-2.0 + +.. include:: ../disclaimer-zh_TW.rst + +:Original: :ref:`Documentation/process/7.AdvancedTopics.rst ` + +:Translator: + + 時奎亮 Alex Shi + +:校譯: + + 吳想成 Wu XiangCheng + 胡皓文 Hu Haowen + +.. _tw_development_advancedtopics: + +高級主題 +======== + +現在，希望您能夠掌握開發流程的工作方式。然而，還有更多的東西要學！本節將介紹 +一些主題，這些主題對希望成爲Linux內核開發過程常規部分的開發人員有幫助。 + +使用Git管理補丁 +--------------- + +內核使用分布式版本控制始於2002年初，當時Linus首次開始使用專有的Bitkeeper應用 +程序。雖然BitKeeper存在爭議，但它所體現的軟體版本管理方法卻肯定不是。分布式 +版本控制可以立即加速內核開發項目。現在有好幾種免費的BitKeeper替代品。 +但無論好壞，內核項目都已經選擇了Git作爲其工具。 + +使用Git管理補丁可以使開發人員的生活更加輕鬆，尤其是隨著補丁數量的增長。Git也 +有其粗糙的邊角和一定的危險性，它是一個年輕和強大的工具，仍然在其開發人員完善 +中。本文檔不會試圖教會讀者如何使用git；這會是個巨長的文檔。相反，這裡的重點 +將是Git如何特別適合內核開發過程。想要加快用Git速度的開發人員可以在以下網站上 +找到更多信息： + + https://git-scm.com/ + + https://www.kernel.org/pub/software/scm/git/docs/user-manual.html + +同時網上也能找到各種各樣的教程。 + +在嘗試使用它生成補丁供他人使用之前，第一要務是閱讀上述網頁，對Git的工作方式 +有一個紮實的了解。使用Git的開發人員應能進行拉取主線存儲庫的副本，查詢修訂 +歷史，提交對樹的更改，使用分支等操作。了解Git用於重寫歷史的工具（如rebase） +也很有用。Git有自己的術語和概念；Git的新用戶應該了解引用、遠程分支、索引、 +快進合併、推拉、游離頭等。一開始可能有點嚇人，但這些概念不難通過一點學習來 +理解。 + +使用git生成通過電子郵件提交的補丁是提高速度的一個很好的練習。 + +當您準備好開始建立Git樹供其他人查看時，無疑需要一個可以從中拉取的伺服器。 +如果您有一個可以訪問網際網路的系統，那麼使用git-daemon設置這樣的伺服器相對 +簡單。同時，免費的公共託管網站（例如github）也開始出現在網絡上。成熟的開發 +人員可以在kernel.org上獲得一個帳戶，但這些帳戶並不容易得到；更多有關信息， +請參閱 https://kernel.org/faq/ 。 + +正常的Git工作流程涉及到許多分支的使用。每一條開發線都可以分爲單獨的「主題 +分支」，並獨立維護。Git的分支很容易使用，沒有理由不使用它們。而且，在任何 +情況下，您都不應該在任何您打算讓其他人從中拉取的分支中進行開發。應該小心地 +創建公開可用的分支；當開發分支處於完整狀態並已準備好時(而不是之前）才合併 +開發分支的補丁。 + +Git提供了一些強大的工具，可以讓您重寫開發歷史。一個不方便的補丁（比如說， +一個打破二分法的補丁，或者有其他一些明顯的缺陷）可以在適當的位置修復，或者 +完全從歷史中消失。一個補丁系列可以被重寫，就好像它是在今天的主線上寫的一樣， +即使你已經花了幾個月的時間在寫它。可以透明地將更改從一個分支轉移到另一個 +分支。等等。明智地使用git修改歷史的能力可以幫助創建問題更少的乾淨補丁集。 + +然而，過度使用這種功能可能會導致其他問題，而不僅僅是對創建完美項目歷史的 +簡單癡迷。重寫歷史將重寫該歷史中包含的更改，將經過測試（希望如此）的內核樹 +變爲未經測試的內核樹。除此之外，如果開發人員沒有共享項目歷史，他們就無法 +輕鬆地協作；如果您重寫了其他開發人員拉入他們存儲庫的歷史，您將使這些開發 +人員的生活更加困難。因此，這裡有一個簡單的經驗法則：被導出到其他地方的歷史 +在此後通常被認爲是不可變的。 + +因此，一旦將一組更改推送到公開可用的伺服器上，就不應該重寫這些更改。如果您 +嘗試強制進行無法快進合併的更改（即不共享同一歷史記錄的更改），Git將嘗試強制 +執行此規則。這可能覆蓋檢查，有時甚至需要重寫導出的樹。在樹之間移動變更集以 +避免linux-next中的衝突就是一個例子。但這種行爲應該是罕見的。這就是爲什麼 +開發應該在私有分支中進行（必要時可以重寫）並且只有在公共分支處於合理的較新 +狀態時才轉移到公共分支中的原因之一。 + +當主線（或其他一組變更所基於的樹）前進時，很容易與該樹合併以保持領先地位。 +對於一個私有的分支，rebasing 可能是一個很容易跟上另一棵樹的方法，但是一旦 +一棵樹被導出到外界，rebasing就不可取了。一旦發生這種情況，就必須進行完全 +合併（merge）。合併有時是很有意義的，但是過於頻繁的合併會不必要地擾亂歷史。 +在這種情況下建議的做法是不要頻繁合併，通常只在特定的發布點（如主線-rc發布） +合併。如果您對特定的更改感到緊張，則可以始終在私有分支中執行測試合併。在 +這種情況下，git「rerere」工具很有用；它能記住合併衝突是如何解決的，這樣您 +就不必重複相同的工作。 + +關於Git這樣的工具的一個最大的反覆抱怨是：補丁從一個存儲庫到另一個存儲庫的 +大量移動使得很容易陷入錯誤建議的變更中，這些變更避開審查雷達進入主線。當內 +核開發人員看到這種情況發生時，他們往往會感到不高興；在Git樹上放置未審閱或 +主題外的補丁可能會影響您將來讓樹被拉取的能力。引用Linus的話: + +:: + + 你可以給我發補丁，但當我從你那裡拉取一個Git補丁時，我需要知道你清楚 + 自己在做什麼，我需要能夠相信事情而 *無需* 手動檢查每個單獨的更改。 + +（http://lwn.net/articles/224135/）。 + +爲了避免這種情況，請確保給定分支中的所有補丁都與相關主題緊密相關；「驅動程序 +修復」分支不應更改核心內存管理代碼。而且，最重要的是，不要使用Git樹來繞過 +審查過程。不時的將樹的摘要發布到相關的列表中，在合適時候請求linux-next中 +包含該樹。 + +如果其他人開始發送補丁以包含到您的樹中，不要忘記審閱它們。還要確保您維護正確 +的作者信息； git 「am」工具在這方面做得最好，但是如果補丁通過第三方轉發給您， +您可能需要在補丁中添加「From:」行。 + +請求拉取時，請務必提供所有相關信息：樹的位置、要拉取的分支以及拉取將導致的 +更改。在這方面 git request-pull 命令非常有用；它將按照其他開發人員所期望的 +格式化請求，並檢查以確保您已記得將這些更改推送到公共伺服器。 + +審閱補丁 +-------- + +一些讀者顯然會反對將本節與「高級主題」放在一起，因爲即使是剛開始的內核開發人員 +也應該審閱補丁。當然，沒有比查看其他人發布的代碼更好的方法來學習如何在內核環境 +中編程了。此外，審閱者永遠供不應求；通過審閱代碼，您可以對整個流程做出重大貢獻。 + +審查代碼可能是一副令人生畏的圖景，特別是對一個新的內核開發人員來說，他們 +可能會對公開詢問代碼感到緊張，而這些代碼是由那些有更多經驗的人發布的。不過， +即使是最有經驗的開發人員編寫的代碼也可以得到改進。也許對（所有）審閱者最好 +的建議是：把審閱評論當成問題而不是批評。詢問「在這條路徑中如何釋放鎖？」 +總是比說「這裡的鎖是錯誤的」更好。 + +不同的開發人員將從不同的角度審查代碼。部分人會主要關注代碼風格以及代碼行是 +否有尾隨空格。其他人會主要關注補丁作爲一個整體實現的變更是否對內核有好處。 +同時也有人會檢查是否存在鎖問題、堆棧使用過度、可能的安全問題、在其他地方 +發現的代碼重複、足夠的文檔、對性能的不利影響、用戶空間ABI更改等。所有類型 +的檢查，只要它們能引導更好的代碼進入內核，都是受歡迎和值得的。 + diff --git a/Documentation/translations/zh_TW/process/8.Conclusion.rst b/Documentation/translations/zh_TW/process/8.Conclusion.rst new file mode 100644 index 000000000000..7572b17667d9 --- /dev/null +++ b/Documentation/translations/zh_TW/process/8.Conclusion.rst @@ -0,0 +1,74 @@ +.. SPDX-License-Identifier: GPL-2.0 + +.. include:: ../disclaimer-zh_TW.rst + +:Original: :ref:`Documentation/process/8.Conclusion.rst ` +:Translator: + + 時奎亮 Alex Shi + +:校譯: + + 吳想成 Wu XiangCheng + 胡皓文 Hu Haowen + +.. _tw_development_conclusion: + +更多信息 +======== + +關於Linux內核開發和相關主題的信息來源很多。首先是在內核原始碼分發中找到的 +文檔目錄。頂級 +:ref:`Documentation/translations/zh_TW/process/howto.rst ` +文件是一個重要的起點； +:ref:`Documentation/translations/zh_TW/process/submitting-patches.rst ` +和 :ref:`Documentation/translations/zh_TW/process/submitting-drivers.rst ` +也是所有內核開發人員都應該閱讀的內容。許多內部內核API都是使用kerneldoc機制 +記錄的；「make htmldocs」或「make pdfdocs」可用於以HTML或PDF格式生成這些文檔 +（儘管某些發行版提供的tex版本會遇到內部限制，無法正確處理文檔）。 + +不同的網站在各個細節層次上討論內核開發。本文作者想謙虛地建議用 https://lwn.net/ +作爲來源；有關許多特定內核主題的信息可以通過以下網址的 LWN 內核索引找到： + + http://lwn.net/kernel/index/ + +除此之外，內核開發人員的一個寶貴資源是： + + https://kernelnewbies.org/ + +當然，也不應該忘記 https://kernel.org/ ，這是內核發布信息的最終位置。 + +關於內核開發有很多書： + + 《Linux設備驅動程序》第三版（Jonathan Corbet、Alessandro Rubini和Greg Kroah Hartman） + 線上版本在 http://lwn.net/kernel/ldd3/ + + 《Linux內核設計與實現》（Robert Love） + + 《深入理解Linux內核》(Daniel Bovet和Marco Cesati） + +然而，所有這些書都有一個共同的缺點：它們上架時就往往有些過時，而且已經上架 +一段時間了。不過，在那裡還是可以找到相當多的好信息。 + +有關git的文檔，請訪問： + + https://www.kernel.org/pub/software/scm/git/docs/ + + https://www.kernel.org/pub/software/scm/git/docs/user-manual.html + +結論 +==== + +祝賀所有通過這篇冗長的文檔的人。希望它能夠幫助您理解Linux內核是如何開發的， +以及您如何參與這個過程。 + +最後，重要的是參與。任何開源軟體項目都不會超過其貢獻者投入其中的總和。Linux +內核的發展速度和以前一樣快，因爲它得到了大量開發人員的幫助，他們都在努力使它 +變得更好。內核是一個最成功的例子，說明了當成千上萬的人爲了一個共同的目標一起 +工作時，可以做出什麼。 + +不過，內核總是可以從更大的開發人員基礎中獲益。總有更多的工作要做。但是同樣 +重要的是，Linux生態系統中的大多數其他參與者可以通過爲內核做出貢獻而受益。使 +代碼進入主線是提高代碼質量、降低維護和分發成本、提高對內核開發方向的影響程度 +等的關鍵。這是一種共贏的局面。啓動你的編輯器，來加入我們吧；你會非常受歡迎的。 + diff --git a/Documentation/translations/zh_TW/process/code-of-conduct-interpretation.rst b/Documentation/translations/zh_TW/process/code-of-conduct-interpretation.rst new file mode 100644 index 000000000000..949d831aaf6c --- /dev/null +++ b/Documentation/translations/zh_TW/process/code-of-conduct-interpretation.rst @@ -0,0 +1,112 @@ +.. SPDX-License-Identifier: GPL-2.0 + +.. include:: ../disclaimer-zh_TW.rst + +:Original: :ref:`Documentation/process/code-of-conduct-interpretation.rst ` +:Translator: Alex Shi + Hu Haowen + +.. _tw_code_of_conduct_interpretation: + +Linux內核貢獻者契約行為準則解釋 +=============================== + +:ref:`tw_code_of_conduct` 準則是一個通用文檔，旨在爲幾乎所有開源社區提供一套規則。 +每個開源社區都是獨一無二的，Linux內核也不例外。因此，本文描述了Linux內核社區中 +如何解釋它。我們也不希望這種解釋隨著時間的推移是靜態的，並將根據需要進行調整。 + +與開發軟體的「傳統」方法相比，Linux內核開發工作是一個非常個人化的過程。你的貢獻 +和背後的想法將被仔細審查，往往導致批判和批評。審查將幾乎總是需要改進，材料才 +能包括在內核中。要知道這是因爲所有相關人員都希望看到Linux整體成功的最佳解決方 +案。這個開發過程已經被證明可以創建有史以來最健壯的作業系統內核，我們不想做任何 +事情來導致提交質量和最終結果的下降。 + +維護者 +------ + +行為準則多次使用「維護者」一詞。在內核社區中，「維護者」是負責子系統、驅動程序或 +文件的任何人，並在內核原始碼樹的維護者文件中列出。 + +責任 +---- + +《行為準則》提到了維護人員的權利和責任，這需要進一步澄清。 + +首先，最重要的是，有一個合理的期望是由維護人員通過實例來領導。 + +也就是說，我們的社區是廣闊的，對維護者沒有新的要求，他們單方面處理其他人在 +他們活躍的社區的行爲。這一責任由我們所有人承擔，最終《行為準則》記錄了最終的 +上訴路徑，以防有關行爲問題的問題懸而未決。 + +維護人員應該願意在出現問題時提供幫助，並在需要時與社區中的其他人合作。如果您 +不確定如何處理出現的情況，請不要害怕聯繫技術諮詢委員會（TAB）或其他維護人員。 +除非您願意，否則不會將其視爲違規報告。如果您不確定是否該聯繫TAB 或任何其他維 +護人員，請聯繫我們的衝突調解人 Mishi Choudhary 。 + +最後，「善待對方」才是每個人的最終目標。我們知道每個人都是人，有時我們都會失敗， +但我們所有人的首要目標應該是努力友好地解決問題。執行行為準則將是最後的選擇。 + +我們的目標是創建一個強大的、技術先進的作業系統，以及所涉及的技術複雜性，這自 +然需要專業知識和決策。 + +所需的專業知識因貢獻領域而異。它主要由上下文和技術複雜性決定，其次由貢獻者和 +維護者的期望決定。 + +專家的期望和決策都要經過討論，但在最後，爲了取得進展，必須能夠做出決策。這一 +特權掌握在維護人員和項目領導的手中，預計將善意使用。 + +因此，設定專業知識期望、作出決定和拒絕不適當的貢獻不被視爲違反行為準則。 + +雖然維護人員一般都歡迎新來者，但他們幫助（新）貢獻者克服障礙的能力有限，因此 +他們必須確定優先事項。這也不應被視爲違反了行為準則。內核社區意識到這一點，並 +以各種形式提供入門級節目，如 kernelnewbies.org 。 + +範圍 +---- + +Linux內核社區主要在一組公共電子郵件列表上進行交互，這些列表分布在由多個不同 +公司或個人控制的多個不同伺服器上。所有這些列表都在內核原始碼樹中的 +MAINTAINERS 文件中定義。發送到這些郵件列表的任何電子郵件都被視爲包含在行爲 +準則中。 + +使用 kernel.org bugzilla和其他子系統bugzilla 或bug跟蹤工具的開發人員應該遵循 +行為準則的指導原則。Linux內核社區沒有「官方」項目電子郵件地址或「官方」社交媒體 +地址。使用kernel.org電子郵件帳戶執行的任何活動必須遵循爲kernel.org發布的行爲 +準則，就像任何使用公司電子郵件帳戶的個人必須遵循該公司的特定規則一樣。 + +行為準則並不禁止在郵件列表消息、內核更改日誌消息或代碼注釋中繼續包含名稱、 +電子郵件地址和相關注釋。 + +其他論壇中的互動包括在適用於上述論壇的任何規則中，通常不包括在行為準則中。 +除了在極端情況下可考慮的例外情況。 + +提交給內核的貢獻應該使用適當的語言。在行為準則之前已經存在的內容現在不會被 +視爲違反。然而，不適當的語言可以被視爲一個bug；如果任何相關方提交補丁， +這樣的bug將被更快地修復。當前屬於用戶/內核API的一部分的表達式，或者反映已 +發布標準或規範中使用的術語的表達式，不被視爲bug。 + +執行 +---- + +行為準則中列出的地址屬於行為準則委員會。https://kernel.org/code-of-conduct.html +列出了在任何給定時間接收這些電子郵件的確切成員。成員不能訪問在加入委員會之前 +或離開委員會之後所做的報告。 + +最初的行為準則委員會由TAB的志願者以及作爲中立第三方的專業調解人組成。委員會 +的首要任務是建立文件化的流程，並將其公開。 + +如果報告人不希望將整個委員會納入投訴或關切，可直接聯繫委員會的任何成員，包括 +調解人。 + +行為準則委員會根據流程審查案例（見上文），並根據需要和適當與TAB協商，例如請求 +和接收有關內核社區的信息。 + +委員會做出的任何決定都將提交到表中，以便在必要時與相關維護人員一起執行。行爲 +準則委員會的決定可以通過三分之二的投票推翻。 + +每季度，行為準則委員會和標籤將提供一份報告，概述行為準則委員會收到的匿名報告 +及其狀態，以及任何否決決定的細節，包括完整和可識別的投票細節。 + +我們希望在啓動期之後爲行為準則委員會人員配備建立一個不同的流程。發生此情況時， +將使用該信息更新此文檔。 + diff --git a/Documentation/translations/zh_TW/process/code-of-conduct.rst b/Documentation/translations/zh_TW/process/code-of-conduct.rst new file mode 100644 index 000000000000..716e5843b6e9 --- /dev/null +++ b/Documentation/translations/zh_TW/process/code-of-conduct.rst @@ -0,0 +1,76 @@ +.. SPDX-License-Identifier: GPL-2.0 + +.. include:: ../disclaimer-zh_TW.rst + +:Original: :ref:`Documentation/process/code-of-conduct.rst ` +:Translator: Alex Shi + Hu Haowen + +.. _tw_code_of_conduct: + +貢獻者契約行為準則 +++++++++++++++++++ + +我們的誓言 +========== + +爲了營造一個開放、友好的環境，我們作爲貢獻者和維護人承諾，讓我們的社區和參 +與者，擁有一個無騷擾的體驗，無論年齡、體型、殘疾、種族、性別特徵、性別認同 +和表達、經驗水平、教育程度、社會狀況，經濟地位、國籍、個人外貌、種族、宗教 +或性身份和取向。 + +我們的標準 +========== + +有助於創造積極環境的行爲包括： + +* 使用歡迎和包容的語言 +* 尊重不同的觀點和經驗 +* 優雅地接受建設性的批評 +* 關注什麼對社區最有利 +* 對其他社區成員表示同情 + +參與者的不可接受行爲包括： + +* 使用性意味的語言或意象以及不受歡迎的性注意或者更過分的行爲 +* 煽動、侮辱/貶損評論以及個人或政治攻擊 +* 公開或私下騷擾 +* 未經明確許可，發布他人的私人信息，如物理或電子地址。 +* 在專業場合被合理認爲不適當的其他行爲 + +我們的責任 +========== + +維護人員負責澄清可接受行爲的標準，並應針對任何不可接受行爲採取適當和公平的 +糾正措施。 + +維護人員有權和責任刪除、編輯或拒絕與本行為準則不一致的評論、承諾、代碼、 +wiki編輯、問題和其他貢獻，或暫時或永久禁止任何貢獻者從事他們認爲不適當、 +威脅、冒犯或有害的其他行爲。 + +範圍 +==== + +當個人代表項目或其社區時，本行為準則既適用於項目空間，也適用於公共空間。 +代表一個項目或社區的例子包括使用一個正式的項目電子郵件地址，通過一個正式 +的社交媒體帳戶發布，或者在在線或離線事件中擔任指定的代表。項目維護人員可以 +進一步定義和澄清項目的表示。 + +執行 +==== + +如有濫用、騷擾或其他不可接受的行爲，可聯繫行為準則委員會。 +所有投訴都將接受審查和調查，並將得到必要和適當的答覆。行為準則委員會有義務 +對事件報告人保密。具體執行政策的進一步細節可單獨公布。 + +歸屬 +==== + +本行為準則改編自《貢獻者契約》，版本1.4，可從 +https://www.contributor-covenant.org/version/1/4/code-of-conduct.html 獲取。 + +解釋 +==== + +有關Linux內核社區如何解釋此文檔，請參閱 :ref:`tw_code_of_conduct_interpretation` + diff --git a/Documentation/translations/zh_TW/process/coding-style.rst b/Documentation/translations/zh_TW/process/coding-style.rst new file mode 100644 index 000000000000..61e614aad6a7 --- /dev/null +++ b/Documentation/translations/zh_TW/process/coding-style.rst @@ -0,0 +1,958 @@ +.. SPDX-License-Identifier: GPL-2.0 + +.. include:: ../disclaimer-zh_TW.rst + +:Original: :ref:`Documentation/process/coding-style.rst ` + +.. _tw_codingstyle: + +譯者:: + + 中文版維護者： 張樂 Zhang Le + 中文版翻譯者： 張樂 Zhang Le + 中文版校譯者： 王聰 Wang Cong + wheelz + 管旭東 Xudong Guan + Li Zefan + Wang Chen + Hu Haowen + +Linux 內核代碼風格 +========================= + +這是一個簡短的文檔，描述了 linux 內核的首選代碼風格。代碼風格是因人而異的， +而且我不願意把自己的觀點強加給任何人，但這就像我去做任何事情都必須遵循的原則 +那樣，我也希望在絕大多數事上保持這種的態度。請 (在寫代碼時) 至少考慮一下這裡 +的代碼風格。 + +首先，我建議你列印一份 GNU 代碼規範，然後不要讀。燒了它，這是一個具有重大象徵 +性意義的動作。 + +不管怎樣，現在我們開始： + + +1) 縮進 +-------------- + +制表符是 8 個字符，所以縮進也是 8 個字符。有些異端運動試圖將縮進變爲 4 (甚至 +2！) 字符深，這幾乎相當於嘗試將圓周率的值定義爲 3。 + +理由：縮進的全部意義就在於清楚的定義一個控制塊起止於何處。尤其是當你盯著你的 +屏幕連續看了 20 小時之後，你將會發現大一點的縮進會使你更容易分辨縮進。 + +現在，有些人會抱怨 8 個字符的縮進會使代碼向右邊移動的太遠，在 80 個字符的終端 +屏幕上就很難讀這樣的代碼。這個問題的答案是，如果你需要 3 級以上的縮進，不管用 +何種方式你的代碼已經有問題了，應該修正你的程序。 + +簡而言之，8 個字符的縮進可以讓代碼更容易閱讀，還有一個好處是當你的函數嵌套太 +深的時候可以給你警告。留心這個警告。 + +在 switch 語句中消除多級縮進的首選的方式是讓 ``switch`` 和從屬於它的 ``case`` +標籤對齊於同一列，而不要 ``兩次縮進`` ``case`` 標籤。比如： + +.. code-block:: c + + switch (suffix) { + case 'G': + case 'g': + mem <<= 30; + break; + case 'M': + case 'm': + mem <<= 20; + break; + case 'K': + case 'k': + mem <<= 10; + fallthrough; + default: + break; + } + +不要把多個語句放在一行里，除非你有什麼東西要隱藏： + +.. code-block:: c + + if (condition) do_this; + do_something_everytime; + +也不要在一行里放多個賦值語句。內核代碼風格超級簡單。就是避免可能導致別人誤讀 +的表達式。 + +除了注釋、文檔和 Kconfig 之外，不要使用空格來縮進，前面的例子是例外，是有意爲 +之。 + +選用一個好的編輯器，不要在行尾留空格。 + + +2) 把長的行和字符串打散 +------------------------------ + +代碼風格的意義就在於使用平常使用的工具來維持代碼的可讀性和可維護性。 + +每一行的長度的限制是 80 列，我們強烈建議您遵守這個慣例。 + +長於 80 列的語句要打散成有意義的片段。除非超過 80 列能顯著增加可讀性，並且不 +會隱藏信息。子片段要明顯短於母片段，並明顯靠右。這同樣適用於有著很長參數列表 +的函數頭。然而，絕對不要打散對用戶可見的字符串，例如 printk 信息，因爲這樣就 +很難對它們 grep。 + + +3) 大括號和空格的放置 +------------------------------ + +C 語言風格中另外一個常見問題是大括號的放置。和縮進大小不同，選擇或棄用某种放 +置策略並沒有多少技術上的原因，不過首選的方式，就像 Kernighan 和 Ritchie 展示 +給我們的，是把起始大括號放在行尾，而把結束大括號放在行首，所以： + +.. code-block:: c + + if (x is true) { + we do y + } + +這適用於所有的非函數語句塊 (if, switch, for, while, do)。比如： + +.. code-block:: c + + switch (action) { + case KOBJ_ADD: + return "add"; + case KOBJ_REMOVE: + return "remove"; + case KOBJ_CHANGE: + return "change"; + default: + return NULL; + } + +不過，有一個例外，那就是函數：函數的起始大括號放置於下一行的開頭，所以： + +.. code-block:: c + + int function(int x) + { + body of function + } + +全世界的異端可能會抱怨這個不一致性是... 呃... 不一致的，不過所有思維健全的人 +都知道 (a) K&R 是 **正確的** 並且 (b) K&R 是正確的。此外，不管怎樣函數都是特 +殊的 (C 函數是不能嵌套的)。 + +注意結束大括號獨自占據一行，除非它後面跟著同一個語句的剩餘部分，也就是 do 語 +句中的 "while" 或者 if 語句中的 "else"，像這樣： + +.. code-block:: c + + do { + body of do-loop + } while (condition); + +和 + +.. code-block:: c + + if (x == y) { + .. + } else if (x > y) { + ... + } else { + .... + } + +理由：K&R。 + +也請注意這種大括號的放置方式也能使空 (或者差不多空的) 行的數量最小化，同時不 +失可讀性。因此，由於你的屏幕上的新行是不可再生資源 (想想 25 行的終端屏幕)，你 +將會有更多的空行來放置注釋。 + +當只有一個單獨的語句的時候，不用加不必要的大括號。 + +.. code-block:: c + + if (condition) + action(); + +和 + +.. code-block:: c + + if (condition) + do_this(); + else + do_that(); + +這並不適用於只有一個條件分支是單語句的情況；這時所有分支都要使用大括號： + +.. code-block:: c + + if (condition) { + do_this(); + do_that(); + } else { + otherwise(); + } + +3.1) 空格 +******************** + +Linux 內核的空格使用方式 (主要) 取決於它是用於函數還是關鍵字。(大多數) 關鍵字 +後要加一個空格。值得注意的例外是 sizeof, typeof, alignof 和 __attribute__，這 +些關鍵字某些程度上看起來更像函數 (它們在 Linux 里也常常伴隨小括號而使用，儘管 +在 C 里這樣的小括號不是必需的，就像 ``struct fileinfo info;`` 聲明過後的 +``sizeof info``)。 + +所以在這些關鍵字之後放一個空格:: + + if, switch, case, for, do, while + +但是不要在 sizeof, typeof, alignof 或者 __attribute__ 這些關鍵字之後放空格。 +例如， + +.. code-block:: c + + s = sizeof(struct file); + +不要在小括號里的表達式兩側加空格。這是一個 **反例** ： + +.. code-block:: c + + s = sizeof( struct file ); + +當聲明指針類型或者返回指針類型的函數時， ``*`` 的首選使用方式是使之靠近變量名 +或者函數名，而不是靠近類型名。例子： + +.. code-block:: c + + char *linux_banner; + unsigned long long memparse(char *ptr, char **retptr); + char *match_strdup(substring_t *s); + +在大多數二元和三元操作符兩側使用一個空格，例如下面所有這些操作符:: + + = + - < > * / % | & ^ <= >= == != ? : + +但是一元操作符後不要加空格:: + + & * + - ~ ! sizeof typeof alignof __attribute__ defined + +後綴自加和自減一元操作符前不加空格:: + + ++ -- + +前綴自加和自減一元操作符後不加空格:: + + ++ -- + +``.`` 和 ``->`` 結構體成員操作符前後不加空格。 + +不要在行尾留空白。有些可以自動縮進的編輯器會在新行的行首加入適量的空白，然後 +你就可以直接在那一行輸入代碼。不過假如你最後沒有在那一行輸入代碼，有些編輯器 +就不會移除已經加入的空白，就像你故意留下一個只有空白的行。包含行尾空白的行就 +這樣產生了。 + +當 git 發現補丁包含了行尾空白的時候會警告你，並且可以應你的要求去掉行尾空白； +不過如果你是正在打一系列補丁，這樣做會導致後面的補丁失敗，因爲你改變了補丁的 +上下文。 + + +4) 命名 +------------------------------ + +C 是一個簡樸的語言，你的命名也應該這樣。和 Modula-2 和 Pascal 程式設計師不同， +C 程式設計師不使用類似 ThisVariableIsATemporaryCounter 這樣華麗的名字。C 程式設計師會 +稱那個變量爲 ``tmp`` ，這樣寫起來會更容易，而且至少不會令其難於理解。 + +不過，雖然混用大小寫的名字是不提倡使用的，但是全局變量還是需要一個具描述性的 +名字。稱一個全局函數爲 ``foo`` 是一個難以饒恕的錯誤。 + +全局變量 (只有當你 **真正** 需要它們的時候再用它) 需要有一個具描述性的名字，就 +像全局函數。如果你有一個可以計算活動用戶數量的函數，你應該叫它 +``count_active_users()`` 或者類似的名字，你不應該叫它 ``cntuser()`` 。 + +在函數名中包含函數類型 (所謂的匈牙利命名法) 是腦子出了問題——編譯器知道那些類 +型而且能夠檢查那些類型，這樣做只能把程式設計師弄糊塗了。難怪微軟總是製造出有問題 +的程序。 + +本地變量名應該簡短，而且能夠表達相關的含義。如果你有一些隨機的整數型的循環計 +數器，它應該被稱爲 ``i`` 。叫它 ``loop_counter`` 並無益處，如果它沒有被誤解的 +可能的話。類似的， ``tmp`` 可以用來稱呼任意類型的臨時變量。 + +如果你怕混淆了你的本地變量名，你就遇到另一個問題了，叫做函數增長荷爾蒙失衡綜 +合症。請看第六章 (函數)。 + + +5) Typedef +----------- + +不要使用類似 ``vps_t`` 之類的東西。 + +對結構體和指針使用 typedef 是一個 **錯誤** 。當你在代碼里看到： + +.. code-block:: c + + vps_t a; + +這代表什麼意思呢？ + +相反，如果是這樣 + +.. code-block:: c + + struct virtual_container *a; + +你就知道 ``a`` 是什麼了。 + +很多人認爲 typedef ``能提高可讀性`` 。實際不是這樣的。它們只在下列情況下有用： + + (a) 完全不透明的對象 (這種情況下要主動使用 typedef 來 **隱藏** 這個對象實際上 + 是什麼)。 + + 例如： ``pte_t`` 等不透明對象，你只能用合適的訪問函數來訪問它們。 + + .. note:: + + 不透明性和 "訪問函數" 本身是不好的。我們使用 pte_t 等類型的原因在於真 + 的是完全沒有任何共用的可訪問信息。 + + (b) 清楚的整數類型，如此，這層抽象就可以 **幫助** 消除到底是 ``int`` 還是 + ``long`` 的混淆。 + + u8/u16/u32 是完全沒有問題的 typedef，不過它們更符合類別 (d) 而不是這裡。 + + .. note:: + + 要這樣做，必須事出有因。如果某個變量是 ``unsigned long`` ，那麼沒有必要 + + typedef unsigned long myflags_t; + + 不過如果有一個明確的原因，比如它在某種情況下可能會是一個 ``unsigned int`` + 而在其他情況下可能爲 ``unsigned long`` ，那麼就不要猶豫，請務必使用 + typedef。 + + (c) 當你使用 sparse 按字面的創建一個 **新** 類型來做類型檢查的時候。 + + (d) 和標準 C99 類型相同的類型，在某些例外的情況下。 + + 雖然讓眼睛和腦筋來適應新的標準類型比如 ``uint32_t`` 不需要花很多時間，可 + 是有些人仍然拒絕使用它們。 + + 因此，Linux 特有的等同於標準類型的 ``u8/u16/u32/u64`` 類型和它們的有符號 + 類型是被允許的——儘管在你自己的新代碼中，它們不是強制要求要使用的。 + + 當編輯已經使用了某個類型集的已有代碼時，你應該遵循那些代碼中已經做出的選 + 擇。 + + (e) 可以在用戶空間安全使用的類型。 + + 在某些用戶空間可見的結構體裡，我們不能要求 C99 類型而且不能用上面提到的 + ``u32`` 類型。因此，我們在與用戶空間共享的所有結構體中使用 __u32 和類似 + 的類型。 + +可能還有其他的情況，不過基本的規則是 **永遠不要** 使用 typedef，除非你可以明 +確的應用上述某個規則中的一個。 + +總的來說，如果一個指針或者一個結構體裡的元素可以合理的被直接訪問到，那麼它們 +就不應該是一個 typedef。 + + +6) 函數 +------------------------------ + +函數應該簡短而漂亮，並且只完成一件事情。函數應該可以一屏或者兩屏顯示完 (我們 +都知道 ISO/ANSI 屏幕大小是 80x24)，只做一件事情，而且把它做好。 + +一個函數的最大長度是和該函數的複雜度和縮進級數成反比的。所以，如果你有一個理 +論上很簡單的只有一個很長 (但是簡單) 的 case 語句的函數，而且你需要在每個 case +里做很多很小的事情，這樣的函數儘管很長，但也是可以的。 + +不過，如果你有一個複雜的函數，而且你懷疑一個天分不是很高的高中一年級學生可能 +甚至搞不清楚這個函數的目的，你應該嚴格遵守前面提到的長度限制。使用輔助函數， +並爲之取個具描述性的名字 (如果你覺得它們的性能很重要的話，可以讓編譯器內聯它 +們，這樣的效果往往會比你寫一個複雜函數的效果要好。) + +函數的另外一個衡量標準是本地變量的數量。此數量不應超過 5－10 個，否則你的函數 +就有問題了。重新考慮一下你的函數，把它分拆成更小的函數。人的大腦一般可以輕鬆 +的同時跟蹤 7 個不同的事物，如果再增多的話，就會糊塗了。即便你聰穎過人，你也可 +能會記不清你 2 個星期前做過的事情。 + +在源文件里，使用空行隔開不同的函數。如果該函數需要被導出，它的 **EXPORT** 宏 +應該緊貼在它的結束大括號之下。比如： + +.. code-block:: c + + int system_is_up(void) + { + return system_state == SYSTEM_RUNNING; + } + EXPORT_SYMBOL(system_is_up); + +在函數原型中，包含函數名和它們的數據類型。雖然 C 語言裡沒有這樣的要求，在 +Linux 里這是提倡的做法，因爲這樣可以很簡單的給讀者提供更多的有價值的信息。 + + +7) 集中的函數退出途徑 +------------------------------ + +雖然被某些人聲稱已經過時，但是 goto 語句的等價物還是經常被編譯器所使用，具體 +形式是無條件跳轉指令。 + +當一個函數從多個位置退出，並且需要做一些類似清理的常見操作時，goto 語句就很方 +便了。如果並不需要清理操作，那麼直接 return 即可。 + +選擇一個能夠說明 goto 行爲或它爲何存在的標籤名。如果 goto 要釋放 ``buffer``, +一個不錯的名字可以是 ``out_free_buffer:`` 。別去使用像 ``err1:`` 和 ``err2:`` +這樣的GW_BASIC 名稱，因爲一旦你添加或刪除了 (函數的) 退出路徑，你就必須對它們 +重新編號，這樣會難以去檢驗正確性。 + +使用 goto 的理由是： + +- 無條件語句容易理解和跟蹤 +- 嵌套程度減小 +- 可以避免由於修改時忘記更新個別的退出點而導致錯誤 +- 讓編譯器省去刪除冗餘代碼的工作 ;) + +.. code-block:: c + + int fun(int a) + { + int result = 0; + char *buffer; + + buffer = kmalloc(SIZE, GFP_KERNEL); + if (!buffer) + return -ENOMEM; + + if (condition1) { + while (loop1) { + ... + } + result = 1; + goto out_free_buffer; + } + ... + out_free_buffer: + kfree(buffer); + return result; + } + +一個需要注意的常見錯誤是 ``一個 err 錯誤`` ，就像這樣： + +.. code-block:: c + + err: + kfree(foo->bar); + kfree(foo); + return ret; + +這段代碼的錯誤是，在某些退出路徑上 ``foo`` 是 NULL。通常情況下，通過把它分離 +成兩個錯誤標籤 ``err_free_bar:`` 和 ``err_free_foo:`` 來修復這個錯誤： + +.. code-block:: c + + err_free_bar: + kfree(foo->bar); + err_free_foo: + kfree(foo); + return ret; + +理想情況下，你應該模擬錯誤來測試所有退出路徑。 + + +8) 注釋 +------------------------------ + +注釋是好的，不過有過度注釋的危險。永遠不要在注釋里解釋你的代碼是如何運作的： +更好的做法是讓別人一看你的代碼就可以明白，解釋寫的很差的代碼是浪費時間。 + +一般的，你想要你的注釋告訴別人你的代碼做了什麼，而不是怎麼做的。也請你不要把 +注釋放在一個函數體內部：如果函數複雜到你需要獨立的注釋其中的一部分，你很可能 +需要回到第六章看一看。你可以做一些小注釋來註明或警告某些很聰明 (或者槽糕) 的 +做法，但不要加太多。你應該做的，是把注釋放在函數的頭部，告訴人們它做了什麼， +也可以加上它做這些事情的原因。 + +當注釋內核 API 函數時，請使用 kernel-doc 格式。請看 +Documentation/doc-guide/ 和 scripts/kernel-doc 以獲得詳細信息。 + +長 (多行) 注釋的首選風格是： + +.. code-block:: c + + /* + * This is the preferred style for multi-line + * comments in the Linux kernel source code. + * Please use it consistently. + * + * Description: A column of asterisks on the left side, + * with beginning and ending almost-blank lines. + */ + +對於在 net/ 和 drivers/net/ 的文件，首選的長 (多行) 注釋風格有些不同。 + +.. code-block:: c + + /* The preferred comment style for files in net/ and drivers/net + * looks like this. + * + * It is nearly the same as the generally preferred comment style, + * but there is no initial almost-blank line. + */ + +注釋數據也是很重要的，不管是基本類型還是衍生類型。爲了方便實現這一點，每一行 +應只聲明一個數據 (不要使用逗號來一次聲明多個數據)。這樣你就有空間來爲每個數據 +寫一段小注釋來解釋它們的用途了。 + + +9) 你已經把事情弄糟了 +------------------------------ + +這沒什麼，我們都是這樣。可能你的使用了很長時間 Unix 的朋友已經告訴你 +``GNU emacs`` 能自動幫你格式化 C 原始碼，而且你也注意到了，確實是這樣，不過它 +所使用的默認值和我們想要的相去甚遠 (實際上，甚至比隨機打的還要差——無數個猴子 +在 GNU emacs 里打字永遠不會創造出一個好程序) (譯註：Infinite Monkey Theorem) + +所以你要麼放棄 GNU emacs，要麼改變它讓它使用更合理的設定。要採用後一個方案， +你可以把下面這段粘貼到你的 .emacs 文件里。 + +.. code-block:: none + + (defun c-lineup-arglist-tabs-only (ignored) + "Line up argument lists by tabs, not spaces" + (let* ((anchor (c-langelem-pos c-syntactic-element)) + (column (c-langelem-2nd-pos c-syntactic-element)) + (offset (- (1+ column) anchor)) + (steps (floor offset c-basic-offset))) + (* (max steps 1) + c-basic-offset))) + + (dir-locals-set-class-variables + 'linux-kernel + '((c-mode . ( + (c-basic-offset . 8) + (c-label-minimum-indentation . 0) + (c-offsets-alist . ( + (arglist-close . c-lineup-arglist-tabs-only) + (arglist-cont-nonempty . + (c-lineup-gcc-asm-reg c-lineup-arglist-tabs-only)) + (arglist-intro . +) + (brace-list-intro . +) + (c . c-lineup-C-comments) + (case-label . 0) + (comment-intro . c-lineup-comment) + (cpp-define-intro . +) + (cpp-macro . -1000) + (cpp-macro-cont . +) + (defun-block-intro . +) + (else-clause . 0) + (func-decl-cont . +) + (inclass . +) + (inher-cont . c-lineup-multi-inher) + (knr-argdecl-intro . 0) + (label . -1000) + (statement . 0) + (statement-block-intro . +) + (statement-case-intro . +) + (statement-cont . +) + (substatement . +) + )) + (indent-tabs-mode . t) + (show-trailing-whitespace . t) + )))) + + (dir-locals-set-directory-class + (expand-file-name "~/src/linux-trees") + 'linux-kernel) + +這會讓 emacs 在 ``~/src/linux-trees`` 下的 C 源文件獲得更好的內核代碼風格。 + +不過就算你嘗試讓 emacs 正確的格式化代碼失敗了，也並不意味著你失去了一切：還可 +以用 ``indent`` 。 + +不過，GNU indent 也有和 GNU emacs 一樣有問題的設定，所以你需要給它一些命令選 +項。不過，這還不算太糟糕，因爲就算是 GNU indent 的作者也認同 K&R 的權威性 +(GNU 的人並不是壞人，他們只是在這個問題上被嚴重的誤導了)，所以你只要給 indent +指定選項 ``-kr -i8`` (代表 ``K&R，8 字符縮進``)，或使用 ``scripts/Lindent`` +這樣就可以以最時髦的方式縮進原始碼。 + +``indent`` 有很多選項，特別是重新格式化注釋的時候，你可能需要看一下它的手冊。 +不過記住： ``indent`` 不能修正壞的編程習慣。 + + +10) Kconfig 配置文件 +------------------------------ + +對於遍布源碼樹的所有 Kconfig* 配置文件來說，它們縮進方式有所不同。緊挨著 +``config`` 定義的行，用一個制表符縮進，然而 help 信息的縮進則額外增加 2 個空 +格。舉個例子:: + + config AUDIT + bool "Auditing support" + depends on NET + help + Enable auditing infrastructure that can be used with another + kernel subsystem, such as SELinux (which requires this for + logging of avc messages output). Does not do system-call + auditing without CONFIG_AUDITSYSCALL. + +而那些危險的功能 (比如某些文件系統的寫支持) 應該在它們的提示字符串里顯著的聲 +明這一點:: + + config ADFS_FS_RW + bool "ADFS write support (DANGEROUS)" + depends on ADFS_FS + ... + +要查看配置文件的完整文檔，請看 Documentation/kbuild/kconfig-language.rst。 + + +11) 數據結構 +------------------------------ + +如果一個數據結構，在創建和銷毀它的單線執行環境之外可見，那麼它必須要有一個引 +用計數器。內核里沒有垃圾收集 (並且內核之外的垃圾收集慢且效率低下)，這意味著你 +絕對需要記錄你對這種數據結構的使用情況。 + +引用計數意味著你能夠避免上鎖，並且允許多個用戶並行訪問這個數據結構——而不需要 +擔心這個數據結構僅僅因爲暫時不被使用就消失了，那些用戶可能不過是沉睡了一陣或 +者做了一些其他事情而已。 + +注意上鎖 **不能** 取代引用計數。上鎖是爲了保持數據結構的一致性，而引用計數是一 +個內存管理技巧。通常二者都需要，不要把兩個搞混了。 + +很多數據結構實際上有 2 級引用計數，它們通常有不同 ``類`` 的用戶。子類計數器統 +計子類用戶的數量，每當子類計數器減至零時，全局計數器減一。 + +這種 ``多級引用計數`` 的例子可以在內存管理 (``struct mm_struct``: mm_users 和 +mm_count)，和文件系統 (``struct super_block``: s_count 和 s_active) 中找到。 + +記住：如果另一個執行線索可以找到你的數據結構，但這個數據結構沒有引用計數器， +這裡幾乎肯定是一個 bug。 + + +12) 宏，枚舉和RTL +------------------------------ + +用於定義常量的宏的名字及枚舉里的標籤需要大寫。 + +.. code-block:: c + + #define CONSTANT 0x12345 + +在定義幾個相關的常量時，最好用枚舉。 + +宏的名字請用大寫字母，不過形如函數的宏的名字可以用小寫字母。 + +一般的，如果能寫成內聯函數就不要寫成像函數的宏。 + +含有多個語句的宏應該被包含在一個 do-while 代碼塊里： + +.. code-block:: c + + #define macrofun(a, b, c) \ + do { \ + if (a == 5) \ + do_this(b, c); \ + } while (0) + +使用宏的時候應避免的事情： + +1) 影響控制流程的宏： + +.. code-block:: c + + #define FOO(x) \ + do { \ + if (blah(x) < 0) \ + return -EBUGGERED; \ + } while (0) + +**非常** 不好。它看起來像一個函數，不過卻能導致 ``調用`` 它的函數退出；不要打 +亂讀者大腦里的語法分析器。 + +2) 依賴於一個固定名字的本地變量的宏： + +.. code-block:: c + + #define FOO(val) bar(index, val) + +可能看起來像是個不錯的東西，不過它非常容易把讀代碼的人搞糊塗，而且容易導致看起 +來不相關的改動帶來錯誤。 + +3) 作爲左值的帶參數的宏： FOO(x) = y；如果有人把 FOO 變成一個內聯函數的話，這 + 種用法就會出錯了。 + +4) 忘記了優先級：使用表達式定義常量的宏必須將表達式置於一對小括號之內。帶參數 + 的宏也要注意此類問題。 + +.. code-block:: c + + #define CONSTANT 0x4000 + #define CONSTEXP (CONSTANT | 3) + +5) 在宏里定義類似函數的本地變量時命名衝突： + +.. code-block:: c + + #define FOO(x) \ + ({ \ + typeof(x) ret; \ + ret = calc_ret(x); \ + (ret); \ + }) + +ret 是本地變量的通用名字 - __foo_ret 更不容易與一個已存在的變量衝突。 + +cpp 手冊對宏的講解很詳細。gcc internals 手冊也詳細講解了 RTL，內核里的彙編語 +言經常用到它。 + + +13) 列印內核消息 +------------------------------ + +內核開發者應該是受過良好教育的。請一定注意內核信息的拼寫，以給人以好的印象。 +不要用不規範的單詞比如 ``dont``，而要用 ``do not`` 或者 ``don't`` 。保證這些信 +息簡單明了,無歧義。 + +內核信息不必以英文句號結束。 + +在小括號里列印數字 (%d) 沒有任何價值，應該避免這樣做。 + + 里有一些驅動模型診斷宏，你應該使用它們，以確保信息對應於正確 +的設備和驅動，並且被標記了正確的消息級別。這些宏有：dev_err(), dev_warn(), +dev_info() 等等。對於那些不和某個特定設備相關連的信息， 定義 +了 pr_notice(), pr_info(), pr_warn(), pr_err() 和其他。 + +寫出好的調試信息可以是一個很大的挑戰；一旦你寫出後，這些信息在遠程除錯時能提 +供極大的幫助。然而列印調試信息的處理方式同列印非調試信息不同。其他 pr_XXX() +函數能無條件地列印，pr_debug() 卻不；默認情況下它不會被編譯，除非定義了 DEBUG +或設定了 CONFIG_DYNAMIC_DEBUG。實際這同樣是爲了 dev_dbg()，一個相關約定是在一 +個已經開啓了 DEBUG 時，使用 VERBOSE_DEBUG 來添加 dev_vdbg()。 + +許多子系統擁有 Kconfig 調試選項來開啓 -DDEBUG 在對應的 Makefile 裡面；在其他 +情況下，特殊文件使用 #define DEBUG。當一條調試信息需要被無條件列印時，例如， +如果已經包含一個調試相關的 #ifdef 條件，printk(KERN_DEBUG ...) 就可被使用。 + + +14) 分配內存 +------------------------------ + +內核提供了下面的一般用途的內存分配函數： +kmalloc(), kzalloc(), kmalloc_array(), kcalloc(), vmalloc() 和 vzalloc()。 +請參考 API 文檔以獲取有關它們的詳細信息。 + +傳遞結構體大小的首選形式是這樣的： + +.. code-block:: c + + p = kmalloc(sizeof(*p), ...); + +另外一種傳遞方式中，sizeof 的操作數是結構體的名字，這樣會降低可讀性，並且可能 +會引入 bug。有可能指針變量類型被改變時，而對應的傳遞給內存分配函數的 sizeof +的結果不變。 + +強制轉換一個 void 指針返回值是多餘的。C 語言本身保證了從 void 指針到其他任何 +指針類型的轉換是沒有問題的。 + +分配一個數組的首選形式是這樣的： + +.. code-block:: c + + p = kmalloc_array(n, sizeof(...), ...); + +分配一個零長數組的首選形式是這樣的： + +.. code-block:: c + + p = kcalloc(n, sizeof(...), ...); + +兩種形式檢查分配大小 n * sizeof(...) 的溢出，如果溢出返回 NULL。 + + +15) 內聯弊病 +------------------------------ + +有一個常見的誤解是 ``內聯`` 是 gcc 提供的可以讓代碼運行更快的一個選項。雖然使 +用內聯函數有時候是恰當的 (比如作爲一種替代宏的方式，請看第十二章)，不過很多情 +況下不是這樣。inline 的過度使用會使內核變大，從而使整個系統運行速度變慢。 +因爲體積大內核會占用更多的指令高速緩存，而且會導致 pagecache 的可用內存減少。 +想像一下，一次 pagecache 未命中就會導致一次磁碟尋址，將耗時 5 毫秒。5 毫秒的 +時間內 CPU 能執行很多很多指令。 + +一個基本的原則是如果一個函數有 3 行以上，就不要把它變成內聯函數。這個原則的一 +個例外是，如果你知道某個參數是一個編譯時常量，而且因爲這個常量你確定編譯器在 +編譯時能優化掉你的函數的大部分代碼，那仍然可以給它加上 inline 關鍵字。 +kmalloc() 內聯函數就是一個很好的例子。 + +人們經常主張給 static 的而且只用了一次的函數加上 inline，如此不會有任何損失， +因爲沒有什麼好權衡的。雖然從技術上說這是正確的，但是實際上這種情況下即使不加 +inline gcc 也可以自動使其內聯。而且其他用戶可能會要求移除 inline，由此而來的 +爭論會抵消 inline 自身的潛在價值，得不償失。 + + +16) 函數返回值及命名 +------------------------------ + +函數可以返回多種不同類型的值，最常見的一種是表明函數執行成功或者失敗的值。這樣 +的一個值可以表示爲一個錯誤代碼整數 (-Exxx＝失敗，0＝成功) 或者一個 ``成功`` +布爾值 (0＝失敗，非0＝成功)。 + +混合使用這兩種表達方式是難於發現的 bug 的來源。如果 C 語言本身嚴格區分整形和 +布爾型變量，那麼編譯器就能夠幫我們發現這些錯誤... 不過 C 語言不區分。爲了避免 +產生這種 bug，請遵循下面的慣例:: + + 如果函數的名字是一個動作或者強制性的命令，那麼這個函數應該返回錯誤代 + 碼整數。如果是一個判斷，那麼函數應該返回一個 "成功" 布爾值。 + +比如， ``add work`` 是一個命令，所以 add_work() 在成功時返回 0，在失敗時返回 +-EBUSY。類似的，因爲 ``PCI device present`` 是一個判斷，所以 pci_dev_present() +在成功找到一個匹配的設備時應該返回 1，如果找不到時應該返回 0。 + +所有 EXPORTed 函數都必須遵守這個慣例，所有的公共函數也都應該如此。私有 +(static) 函數不需要如此，但是我們也推薦這樣做。 + +返回值是實際計算結果而不是計算是否成功的標誌的函數不受此慣例的限制。一般的， +他們通過返回一些正常值範圍之外的結果來表示出錯。典型的例子是返回指針的函數， +他們使用 NULL 或者 ERR_PTR 機制來報告錯誤。 + + +17) 不要重新發明內核宏 +------------------------------ + +頭文件 include/linux/kernel.h 包含了一些宏，你應該使用它們，而不要自己寫一些 +它們的變種。比如，如果你需要計算一個數組的長度，使用這個宏 + +.. code-block:: c + + #define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0])) + +類似的，如果你要計算某結構體成員的大小，使用 + +.. code-block:: c + + #define sizeof_field(t, f) (sizeof(((t*)0)->f)) + +還有可以做嚴格的類型檢查的 min() 和 max() 宏，如果你需要可以使用它們。你可以 +自己看看那個頭文件里還定義了什麼你可以拿來用的東西，如果有定義的話，你就不應 +在你的代碼里自己重新定義。 + + +18) 編輯器模式行和其他需要羅嗦的事情 +-------------------------------------------------- + +有一些編輯器可以解釋嵌入在源文件里的由一些特殊標記標明的配置信息。比如，emacs +能夠解釋被標記成這樣的行： + +.. code-block:: c + + -*- mode: c -*- + +或者這樣的： + +.. code-block:: c + + /* + Local Variables: + compile-command: "gcc -DMAGIC_DEBUG_FLAG foo.c" + End: + */ + +Vim 能夠解釋這樣的標記： + +.. code-block:: c + + /* vim:set sw=8 noet */ + +不要在原始碼中包含任何這樣的內容。每個人都有他自己的編輯器配置，你的源文件不 +應該覆蓋別人的配置。這包括有關縮進和模式配置的標記。人們可以使用他們自己定製 +的模式，或者使用其他可以產生正確的縮進的巧妙方法。 + + +19) 內聯彙編 +------------------------------ + +在特定架構的代碼中，你可能需要內聯彙編與 CPU 和平台相關功能連接。需要這麼做時 +就不要猶豫。然而，當 C 可以完成工作時，不要平白無故地使用內聯彙編。在可能的情 +況下，你可以並且應該用 C 和硬體溝通。 + +請考慮去寫捆綁通用位元 (wrap common bits) 的內聯彙編的簡單輔助函數，別去重複 +地寫下只有細微差異內聯彙編。記住內聯彙編可以使用 C 參數。 + +大型，有一定複雜度的彙編函數應該放在 .S 文件內，用相應的 C 原型定義在 C 頭文 +件中。彙編函數的 C 原型應該使用 ``asmlinkage`` 。 + +你可能需要把彙編語句標記爲 volatile，用來阻止 GCC 在沒發現任何副作用後就把它 +移除了。你不必總是這樣做，儘管，這不必要的舉動會限制優化。 + +在寫一個包含多條指令的單個內聯彙編語句時，把每條指令用引號分割而且各占一行， +除了最後一條指令外，在每個指令結尾加上 \n\t，讓彙編輸出時可以正確地縮進下一條 +指令： + +.. code-block:: c + + asm ("magic %reg1, #42\n\t" + "more_magic %reg2, %reg3" + : /* outputs */ : /* inputs */ : /* clobbers */); + + +20) 條件編譯 +------------------------------ + +只要可能，就不要在 .c 文件裡面使用預處理條件 (#if, #ifdef)；這樣做讓代碼更難 +閱讀並且更難去跟蹤邏輯。替代方案是，在頭文件中用預處理條件提供給那些 .c 文件 +使用，再給 #else 提供一個空樁 (no-op stub) 版本，然後在 .c 文件內無條件地調用 +那些 (定義在頭文件內的) 函數。這樣做，編譯器會避免爲樁函數 (stub) 的調用生成 +任何代碼，產生的結果是相同的，但邏輯將更加清晰。 + +最好傾向於編譯整個函數，而不是函數的一部分或表達式的一部分。與其放一個 ifdef +在表達式內，不如分解出部分或全部表達式，放進一個單獨的輔助函數，並應用預處理 +條件到這個輔助函數內。 + +如果你有一個在特定配置中，可能變成未使用的函數或變量，編譯器會警告它定義了但 +未使用，把它標記爲 __maybe_unused 而不是將它包含在一個預處理條件中。(然而，如 +果一個函數或變量總是未使用，就直接刪除它。) + +在代碼中，儘可能地使用 IS_ENABLED 宏來轉化某個 Kconfig 標記爲 C 的布爾 +表達式，並在一般的 C 條件中使用它： + +.. code-block:: c + + if (IS_ENABLED(CONFIG_SOMETHING)) { + ... + } + +編譯器會做常量摺疊，然後就像使用 #ifdef 那樣去包含或排除代碼塊，所以這不會帶 +來任何運行時開銷。然而，這種方法依舊允許 C 編譯器查看塊內的代碼，並檢查它的正 +確性 (語法，類型，符號引用，等等)。因此，如果條件不滿足，代碼塊內的引用符號就 +不存在時，你還是必須去用 #ifdef。 + +在任何有意義的 #if 或 #ifdef 塊的末尾 (超過幾行的)，在 #endif 同一行的後面寫下 +註解，注釋這個條件表達式。例如： + +.. code-block:: c + + #ifdef CONFIG_SOMETHING + ... + #endif /* CONFIG_SOMETHING */ + + +附錄 I) 參考 +------------------- + +The C Programming Language, 第二版 +作者：Brian W. Kernighan 和 Denni M. Ritchie. +Prentice Hall, Inc., 1988. +ISBN 0-13-110362-8 (軟皮), 0-13-110370-9 (硬皮). + +The Practice of Programming +作者：Brian W. Kernighan 和 Rob Pike. +Addison-Wesley, Inc., 1999. +ISBN 0-201-61586-X. + +GNU 手冊 - 遵循 K&R 標準和此文本 - cpp, gcc, gcc internals and indent, +都可以從 https://www.gnu.org/manual/ 找到 + +WG14 是 C 語言的國際標準化工作組，URL: http://www.open-std.org/JTC1/SC22/WG14/ + +Kernel process/coding-style.rst，作者 greg@kroah.com 發表於 OLS 2002： +http://www.kroah.com/linux/talks/ols_2002_kernel_codingstyle_talk/html/ + diff --git a/Documentation/translations/zh_TW/process/development-process.rst b/Documentation/translations/zh_TW/process/development-process.rst new file mode 100644 index 000000000000..45e6385647cd --- /dev/null +++ b/Documentation/translations/zh_TW/process/development-process.rst @@ -0,0 +1,30 @@ +.. SPDX-License-Identifier: GPL-2.0 + +.. include:: ../disclaimer-zh_TW.rst + +:Original: :ref:`Documentation/process/development-process.rst ` +:Translator: Alex Shi + Hu Haowen + +.. _tw_development_process_main: + +內核開發過程指南 +================ + +內容: + +.. toctree:: + :numbered: + :maxdepth: 2 + + 1.Intro + 2.Process + 3.Early-stage + 4.Coding + 5.Posting + 6.Followthrough + 7.AdvancedTopics + 8.Conclusion + +本文檔的目的是幫助開發人員（及其經理）以最小的挫折感與開發社區合作。它試圖記錄這個社區如何以一種不熟悉Linux內核開發（或者實際上是自由軟體開發）的人可以訪問的方式工作。雖然這裡有一些技術資料，但這是一個面向過程的討論，不需要深入了解內核編程就可以理解。 + diff --git a/Documentation/translations/zh_TW/process/email-clients.rst b/Documentation/translations/zh_TW/process/email-clients.rst new file mode 100644 index 000000000000..4ba543d06f3b --- /dev/null +++ b/Documentation/translations/zh_TW/process/email-clients.rst @@ -0,0 +1,252 @@ +.. SPDX-License-Identifier: GPL-2.0 + +.. _tw_email_clients: + +.. include:: ../disclaimer-zh_TW.rst + +:Original: :ref:`Documentation/process/email-clients.rst ` + +譯者:: + + 中文版維護者： 賈威威 Harry Wei + 中文版翻譯者： 賈威威 Harry Wei + 時奎亮 Alex Shi + 中文版校譯者： Yinglin Luan + Xiaochen Wang + yaxinsn + Hu Haowen + +Linux郵件客戶端配置信息 +======================= + +Git +--- + +現在大多數開發人員使用 ``git send-email`` 而不是常規的電子郵件客戶端。這方面 +的手冊非常好。在接收端，維護人員使用 ``git am`` 加載補丁。 + +如果你是 ``git`` 新手，那麼把你的第一個補丁發送給你自己。將其保存爲包含所有 +標題的原始文本。運行 ``git am raw_email.txt`` ，然後使用 ``git log`` 查看更 +改日誌。如果工作正常，再將補丁發送到相應的郵件列表。 + + +普通配置 +-------- +Linux內核補丁是通過郵件被提交的，最好把補丁作爲郵件體的內嵌文本。有些維護者 +接收附件，但是附件的內容格式應該是"text/plain"。然而，附件一般是不贊成的， +因爲這會使補丁的引用部分在評論過程中變的很困難。 + +用來發送Linux內核補丁的郵件客戶端在發送補丁時應該處於文本的原始狀態。例如， +他們不能改變或者刪除制表符或者空格，甚至是在每一行的開頭或者結尾。 + +不要通過"format=flowed"模式發送補丁。這樣會引起不可預期以及有害的斷行。 + +不要讓你的郵件客戶端進行自動換行。這樣也會破壞你的補丁。 + +郵件客戶端不能改變文本的字符集編碼方式。要發送的補丁只能是ASCII或者UTF-8編碼方式， +如果你使用UTF-8編碼方式發送郵件，那麼你將會避免一些可能發生的字符集問題。 + +郵件客戶端應該形成並且保持 References: 或者 In-Reply-To: 標題，那麼 +郵件話題就不會中斷。 + +複製粘帖(或者剪貼粘帖)通常不能用於補丁，因爲制表符會轉換爲空格。使用xclipboard, xclip +或者xcutsel也許可以，但是最好測試一下或者避免使用複製粘帖。 + +不要在使用PGP/GPG署名的郵件中包含補丁。這樣會使得很多腳本不能讀取和適用於你的補丁。 +（這個問題應該是可以修復的） + +在給內核郵件列表發送補丁之前，給自己發送一個補丁是個不錯的主意，保存接收到的 +郵件，將補丁用'patch'命令打上，如果成功了，再給內核郵件列表發送。 + + +一些郵件客戶端提示 +------------------ +這裡給出一些詳細的MUA配置提示，可以用於給Linux內核發送補丁。這些並不意味是 +所有的軟體包配置總結。 + +說明： +TUI = 以文本爲基礎的用戶接口 +GUI = 圖形界面用戶接口 + +Alpine (TUI) +~~~~~~~~~~~~ + +配置選項： +在"Sending Preferences"部分： + +- "Do Not Send Flowed Text"必須開啓 +- "Strip Whitespace Before Sending"必須關閉 + +當寫郵件時，光標應該放在補丁會出現的地方，然後按下CTRL-R組合鍵，使指定的 +補丁文件嵌入到郵件中。 + +Evolution (GUI) +~~~~~~~~~~~~~~~ + +一些開發者成功的使用它發送補丁 + +當選擇郵件選項：Preformat + 從Format->Heading->Preformatted (Ctrl-7)或者工具欄 + +然後使用： + Insert->Text File... (Alt-n x)插入補丁文件。 + +你還可以"diff -Nru old.c new.c | xclip"，選擇Preformat，然後使用中間鍵進行粘帖。 + +Kmail (GUI) +~~~~~~~~~~~ + +一些開發者成功的使用它發送補丁。 + +默認設置不爲HTML格式是合適的；不要啓用它。 + +當書寫一封郵件的時候，在選項下面不要選擇自動換行。唯一的缺點就是你在郵件中輸入的任何文本 +都不會被自動換行，因此你必須在發送補丁之前手動換行。最簡單的方法就是啓用自動換行來書寫郵件， +然後把它保存爲草稿。一旦你在草稿中再次打開它，它已經全部自動換行了，那麼你的郵件雖然沒有 +選擇自動換行，但是還不會失去已有的自動換行。 + +在郵件的底部，插入補丁之前，放上常用的補丁定界符：三個連字號(---)。 + +然後在"Message"菜單條目，選擇插入文件，接著選取你的補丁文件。還有一個額外的選項，你可以 +通過它配置你的郵件建立工具欄菜單，還可以帶上"insert file"圖標。 + +你可以安全地通過GPG標記附件，但是內嵌補丁最好不要使用GPG標記它們。作爲內嵌文本的簽發補丁， +當從GPG中提取7位編碼時會使他們變的更加複雜。 + +如果你非要以附件的形式發送補丁，那麼就右鍵點擊附件，然後選中屬性，突出"Suggest automatic +display"，這樣內嵌附件更容易讓讀者看到。 + +當你要保存將要發送的內嵌文本補丁，你可以從消息列表窗格選擇包含補丁的郵件，然後右擊選擇 +"save as"。你可以使用一個沒有更改的包含補丁的郵件，如果它是以正確的形式組成。當你正真在它 +自己的窗口之下察看，那時沒有選項可以保存郵件--已經有一個這樣的bug被匯報到了kmail的bugzilla +並且希望這將會被處理。郵件是以只針對某個用戶可讀寫的權限被保存的，所以如果你想把郵件複製到其他地方， +你不得不把他們的權限改爲組或者整體可讀。 + +Lotus Notes (GUI) +~~~~~~~~~~~~~~~~~ + +不要使用它。 + +Mutt (TUI) +~~~~~~~~~~ + +很多Linux開發人員使用mutt客戶端，所以證明它肯定工作的非常漂亮。 + +Mutt不自帶編輯器，所以不管你使用什麼編輯器都不應該帶有自動斷行。大多數編輯器都帶有 +一個"insert file"選項，它可以通過不改變文件內容的方式插入文件。 + +'vim'作爲mutt的編輯器： + set editor="vi" + + 如果使用xclip，敲入以下命令 + :set paste + 按中鍵之前或者shift-insert或者使用 + :r filename + +如果想要把補丁作爲內嵌文本。 +(a)ttach工作的很好，不帶有"set paste"。 + +你可以通過 ``git format-patch`` 生成補丁，然後用 Mutt發送它們:: + + $ mutt -H 0001-some-bug-fix.patch + +配置選項： +它應該以默認設置的形式工作。 +然而，把"send_charset"設置爲"us-ascii::utf-8"也是一個不錯的主意。 + +Mutt 是高度可配置的。 這裡是個使用mutt通過 Gmail 發送的補丁的最小配置:: + + # .muttrc + # ================ IMAP ==================== + set imap_user = 'yourusername@gmail.com' + set imap_pass = 'yourpassword' + set spoolfile = imaps://imap.gmail.com/INBOX + set folder = imaps://imap.gmail.com/ + set record="imaps://imap.gmail.com/[Gmail]/Sent Mail" + set postponed="imaps://imap.gmail.com/[Gmail]/Drafts" + set mbox="imaps://imap.gmail.com/[Gmail]/All Mail" + + # ================ SMTP ==================== + set smtp_url = "smtp://username@smtp.gmail.com:587/" + set smtp_pass = $imap_pass + set ssl_force_tls = yes # Require encrypted connection + + # ================ Composition ==================== + set editor = `echo \$EDITOR` + set edit_headers = yes # See the headers when editing + set charset = UTF-8 # value of $LANG; also fallback for send_charset + # Sender, email address, and sign-off line must match + unset use_domain # because joe@localhost is just embarrassing + set realname = "YOUR NAME" + set from = "username@gmail.com" + set use_from = yes + +Mutt文檔含有更多信息: + + http://dev.mutt.org/trac/wiki/UseCases/Gmail + + http://dev.mutt.org/doc/manual.html + +Pine (TUI) +~~~~~~~~~~ + +Pine過去有一些空格刪減問題，但是這些現在應該都被修復了。 + +如果可以，請使用alpine(pine的繼承者) + +配置選項： +- 最近的版本需要消除流程文本 +- "no-strip-whitespace-before-send"選項也是需要的。 + + +Sylpheed (GUI) +~~~~~~~~~~~~~~ + +- 內嵌文本可以很好的工作（或者使用附件）。 +- 允許使用外部的編輯器。 +- 對於目錄較多時非常慢。 +- 如果通過non-SSL連接，無法使用TLS SMTP授權。 +- 在組成窗口中有一個很有用的ruler bar。 +- 給地址本中添加地址就不會正確的了解顯示名。 + +Thunderbird (GUI) +~~~~~~~~~~~~~~~~~ + +默認情況下，thunderbird很容易損壞文本，但是還有一些方法可以強制它變得更好。 + +- 在用戶帳號設置里，組成和尋址，不要選擇"Compose messages in HTML format"。 + +- 編輯你的Thunderbird配置設置來使它不要拆行使用：user_pref("mailnews.wraplength", 0); + +- 編輯你的Thunderbird配置設置，使它不要使用"format=flowed"格式：user_pref("mailnews. + send_plaintext_flowed", false); + +- 你需要使Thunderbird變爲預先格式方式： + 如果默認情況下你書寫的是HTML格式，那不是很難。僅僅從標題欄的下拉框中選擇"Preformat"格式。 + 如果默認情況下你書寫的是文本格式，你不得把它改爲HTML格式（僅僅作爲一次性的）來書寫新的消息， + 然後強制使它回到文本格式，否則它就會拆行。要實現它，在寫信的圖標上使用shift鍵來使它變爲HTML + 格式，然後標題欄的下拉框中選擇"Preformat"格式。 + +- 允許使用外部的編輯器： + 針對Thunderbird打補丁最簡單的方法就是使用一個"external editor"擴展，然後使用你最喜歡的 + $EDITOR來讀取或者合併補丁到文本中。要實現它，可以下載並且安裝這個擴展，然後添加一個使用它的 + 按鍵View->Toolbars->Customize...最後當你書寫信息的時候僅僅點擊它就可以了。 + +TkRat (GUI) +~~~~~~~~~~~ + +可以使用它。使用"Insert file..."或者外部的編輯器。 + +Gmail (Web GUI) +~~~~~~~~~~~~~~~ + +不要使用它發送補丁。 + +Gmail網頁客戶端自動地把制表符轉換爲空格。 + +雖然制表符轉換爲空格問題可以被外部編輯器解決，同時它還會使用回車換行把每行拆分爲78個字符。 + +另一個問題是Gmail還會把任何不是ASCII的字符的信息改爲base64編碼。它把東西變的像歐洲人的名字。 + + ### + diff --git a/Documentation/translations/zh_TW/process/embargoed-hardware-issues.rst b/Documentation/translations/zh_TW/process/embargoed-hardware-issues.rst new file mode 100644 index 000000000000..6c76fc96131a --- /dev/null +++ b/Documentation/translations/zh_TW/process/embargoed-hardware-issues.rst @@ -0,0 +1,232 @@ +.. SPDX-License-Identifier: GPL-2.0 + +.. include:: ../disclaimer-zh_TW.rst + +:Original: :ref:`Documentation/process/embargoed-hardware-issues.rst ` +:Translator: Alex Shi + Hu Haowen + +被限制的硬體問題 +================ + +範圍 +---- + +導致安全問題的硬體問題與只影響Linux內核的純軟體錯誤是不同的安全錯誤類別。 + +必須區別對待諸如熔毀(Meltdown)、Spectre、L1TF等硬體問題，因爲它們通常會影響 +所有作業系統（「OS」），因此需要在不同的OS供應商、發行版、硬體供應商和其他各方 +之間進行協調。對於某些問題，軟體緩解可能依賴於微碼或固件更新，這需要進一步的 +協調。 + +.. _tw_Contact: + +接觸 +---- + +Linux內核硬體安全小組獨立於普通的Linux內核安全小組。 + +該小組只負責協調被限制的硬體安全問題。Linux內核中純軟體安全漏洞的報告不由該 +小組處理，報告者將被引導至常規Linux內核安全小組(:ref:`Documentation/admin-guide/ +`)聯繫。 + +可以通過電子郵件 與小組聯繫。這是一份私密的安全 +官名單，他們將幫助您根據我們的文檔化流程協調問題。 + +郵件列表是加密的，發送到列表的電子郵件可以通過PGP或S/MIME加密，並且必須使用報告 +者的PGP密鑰或S/MIME證書籤名。該列表的PGP密鑰和S/MIME證書可從 +https://www.kernel.org/.... 獲得。 + +雖然硬體安全問題通常由受影響的硬體供應商處理，但我們歡迎發現潛在硬體缺陷的研究 +人員或個人與我們聯繫。 + +硬體安全官 +^^^^^^^^^^ + +目前的硬體安全官小組: + + - Linus Torvalds（Linux基金會院士） + - Greg Kroah Hartman（Linux基金會院士） + - Thomas Gleixner（Linux基金會院士） + +郵件列表的操作 +^^^^^^^^^^^^^^ + +處理流程中使用的加密郵件列表託管在Linux Foundation的IT基礎設施上。通過提供這項 +服務，Linux基金會的IT基礎設施安全總監在技術上有能力訪問被限制的信息，但根據他 +的僱傭合同，他必須保密。Linux基金會的IT基礎設施安全總監還負責 kernel.org 基礎 +設施。 + +Linux基金會目前的IT基礎設施安全總監是 Konstantin Ryabitsev。 + +保密協議 +-------- + +Linux內核硬體安全小組不是正式的機構，因此無法簽訂任何保密協議。核心社區意識到 +這些問題的敏感性，並提供了一份諒解備忘錄。 + +諒解備忘錄 +---------- + +Linux內核社區深刻理解在不同作業系統供應商、發行商、硬體供應商和其他各方之間 +進行協調時，保持硬體安全問題處於限制狀態的要求。 + +Linux內核社區在過去已經成功地處理了硬體安全問題，並且有必要的機制允許在限制 +限制下進行符合社區的開發。 + +Linux內核社區有一個專門的硬體安全小組負責初始聯繫，並監督在限制規則下處理 +此類問題的過程。 + +硬體安全小組確定開發人員（領域專家），他們將組成特定問題的初始響應小組。最初 +的響應小組可以引入更多的開發人員（領域專家）以最佳的技術方式解決這個問題。 + +所有相關開發商承諾遵守限制規定，並對收到的信息保密。違反承諾將導致立即從當前 +問題中排除，並從所有相關郵件列表中刪除。此外，硬體安全小組還將把違反者排除在 +未來的問題之外。這一後果的影響在我們社區是一種非常有效的威懾。如果發生違規 +情況，硬體安全小組將立即通知相關方。如果您或任何人發現潛在的違規行爲，請立即 +向硬體安全人員報告。 + +流程 +^^^^ + +由於Linux內核開發的全球分布式特性，面對面的會議幾乎不可能解決硬體安全問題。 +由於時區和其他因素，電話會議很難協調，只能在絕對必要時使用。加密電子郵件已被 +證明是解決此類問題的最有效和最安全的通信方法。 + +開始披露 +"""""""" + +披露內容首先通過電子郵件聯繫Linux內核硬體安全小組。此初始聯繫人應包含問題的 +描述和任何已知受影響硬體的列表。如果您的組織製造或分發受影響的硬體，我們建議 +您也考慮哪些其他硬體可能會受到影響。 + +硬體安全小組將提供一個特定於事件的加密郵件列表，用於與報告者進行初步討論、 +進一步披露和協調。 + +硬體安全小組將向披露方提供一份開發人員（領域專家）名單，在與開發人員確認他們 +將遵守本諒解備忘錄和文件化流程後，應首先告知開發人員有關該問題的信息。這些開發 +人員組成初始響應小組，並在初始接觸後負責處理問題。硬體安全小組支持響應小組， +但不一定參與緩解開發過程。 + +雖然個別開發人員可能通過其僱主受到保密協議的保護，但他們不能以Linux內核開發 +人員的身份簽訂個別保密協議。但是，他們將同意遵守這一書面程序和諒解備忘錄。 + +披露方應提供已經或應該被告知該問題的所有其他實體的聯繫人名單。這有幾個目的: + + - 披露的實體列表允許跨行業通信，例如其他作業系統供應商、硬體供應商等。 + + - 可聯繫已披露的實體，指定應參與緩解措施開發的專家。 + + - 如果需要處理某一問題的專家受僱於某一上市實體或某一上市實體的成員，則響應 + 小組可要求該實體披露該專家。這確保專家也是實體反應小組的一部分。 + +披露 +"""" + +披露方通過特定的加密郵件列表向初始響應小組提供詳細信息。 + +根據我們的經驗，這些問題的技術文檔通常是一個足夠的起點，最好通過電子郵件進行 +進一步的技術澄清。 + +緩解開發 +"""""""" + +初始響應小組設置加密郵件列表，或在適當的情況下重新修改現有郵件列表。 + +使用郵件列表接近於正常的Linux開發過程，並且在過去已經成功地用於爲各種硬體安全 +問題開發緩解措施。 + +郵件列表的操作方式與正常的Linux開發相同。發布、討論和審查修補程序，如果同意， +則應用於非公共git存儲庫，參與開發人員只能通過安全連接訪問該存儲庫。存儲庫包含 +針對主線內核的主開發分支，並根據需要爲穩定的內核版本提供向後移植分支。 + +最初的響應小組將根據需要從Linux內核開發人員社區中確定更多的專家。引進專家可以 +在開發過程中的任何時候發生，需要及時處理。 + +如果專家受僱於披露方提供的披露清單上的實體或其成員，則相關實體將要求其參與。 + +否則，披露方將被告知專家參與的情況。諒解備忘錄涵蓋了專家，要求披露方確認參與。 +如果披露方有令人信服的理由提出異議，則必須在五個工作日內提出異議，並立即與事件 +小組解決。如果披露方在五個工作日內未作出回應，則視爲默許。 + +在確認或解決異議後，專家由事件小組披露，並進入開發過程。 + +協調發布 +"""""""" + +有關各方將協商限制結束的日期和時間。此時，準備好的緩解措施集成到相關的內核樹中 +並發布。 + +雖然我們理解硬體安全問題需要協調限制時間，但限制時間應限制在所有有關各方制定、 +測試和準備緩解措施所需的最短時間內。人爲地延長限制時間以滿足會議討論日期或其他 +非技術原因，會給相關的開發人員和響應小組帶來了更多的工作和負擔，因爲補丁需要 +保持最新，以便跟蹤正在進行的上游內核開發，這可能會造成衝突的更改。 + +CVE分配 +""""""" + +硬體安全小組和初始響應小組都不分配CVE，開發過程也不需要CVE。如果CVE是由披露方 +提供的，則可用於文檔中。 + +流程專使 +-------- + +爲了協助這一進程，我們在各組織設立了專使，他們可以回答有關報告流程和進一步處理 +的問題或提供指導。專使不參與特定問題的披露，除非響應小組或相關披露方提出要求。 +現任專使名單: + + ============= ======================================================== + ARM + AMD Tom Lendacky + IBM + Intel Tony Luck + Qualcomm Trilok Soni + + Microsoft Sasha Levin + VMware + Xen Andrew Cooper + + Canonical John Johansen + Debian Ben Hutchings + Oracle Konrad Rzeszutek Wilk + Red Hat Josh Poimboeuf + SUSE Jiri Kosina + + Amazon + Google Kees Cook + ============= ======================================================== + +如果要將您的組織添加到專使名單中，請與硬體安全小組聯繫。被提名的專使必須完全 +理解和支持我們的過程，並且在Linux內核社區中很容易聯繫。 + +加密郵件列表 +------------ + +我們使用加密郵件列表進行通信。這些列表的工作原理是，發送到列表的電子郵件使用 +列表的PGP密鑰或列表的/MIME證書進行加密。郵件列表軟體對電子郵件進行解密，並 +使用訂閱者的PGP密鑰或S/MIME證書爲每個訂閱者分別對其進行重新加密。有關郵件列表 +軟體和用於確保列表安全和數據保護的設置的詳細信息，請訪問: +https://www.kernel.org/.... + +關鍵點 +^^^^^^ + +初次接觸見 :ref:`tw_Contact`. 對於特定於事件的郵件列表，密鑰和S/MIME證書通過 +特定列表發送的電子郵件傳遞給訂閱者。 + +訂閱事件特定列表 +^^^^^^^^^^^^^^^^ + +訂閱由響應小組處理。希望參與通信的披露方將潛在訂戶的列表發送給響應組，以便 +響應組可以驗證訂閱請求。 + +每個訂戶都需要通過電子郵件向響應小組發送訂閱請求。電子郵件必須使用訂閱伺服器 +的PGP密鑰或S/MIME證書籤名。如果使用PGP密鑰，則必須從公鑰伺服器獲得該密鑰， +並且理想情況下該密鑰連接到Linux內核的PGP信任網。另請參見: +https://www.kernel.org/signature.html. + +響應小組驗證訂閱者，並將訂閱者添加到列表中。訂閱後，訂閱者將收到來自郵件列表 +的電子郵件，該郵件列表使用列表的PGP密鑰或列表的/MIME證書籤名。訂閱者的電子郵件 +客戶端可以從簽名中提取PGP密鑰或S/MIME證書，以便訂閱者可以向列表發送加密電子 +郵件。 + diff --git a/Documentation/translations/zh_TW/process/howto.rst b/Documentation/translations/zh_TW/process/howto.rst new file mode 100644 index 000000000000..2043691b92e3 --- /dev/null +++ b/Documentation/translations/zh_TW/process/howto.rst @@ -0,0 +1,500 @@ +.. SPDX-License-Identifier: GPL-2.0 + +.. _tw_process_howto: + +.. include:: ../disclaimer-zh_TW.rst + +:Original: :ref:`Documentation/process/howto.rst ` + +譯者:: + + 英文版維護者： Greg Kroah-Hartman + 中文版維護者： 李陽 Li Yang + 中文版翻譯者： 李陽 Li Yang + 時奎亮 Alex Shi + 中文版校譯者: + 鍾宇 TripleX Chung + 陳琦 Maggie Chen + 王聰 Wang Cong + 胡皓文 Hu Haowen + +如何參與Linux內核開發 +===================== + +這是一篇將如何參與Linux內核開發的相關問題一網打盡的終極祕笈。它將指導你 +成爲一名Linux內核開發者，並且學會如何同Linux內核開發社區合作。它儘可能不 +包括任何關於內核編程的技術細節，但會給你指引一條獲得這些知識的正確途徑。 + +如果這篇文章中的任何內容不再適用，請給文末列出的文件維護者發送補丁。 + + +入門 +---- + +你想了解如何成爲一名Linux內核開發者？或者老闆吩咐你「給這個設備寫個Linux +驅動程序」？這篇文章的目的就是教會你達成這些目標的全部訣竅，它將描述你需 +要經過的流程以及給出如何同內核社區合作的一些提示。它還將試圖解釋內核社區 +爲何這樣運作。 + +Linux內核大部分是由C語言寫成的，一些體系結構相關的代碼用到了彙編語言。要 +參與內核開發，你必須精通C語言。除非你想爲某個架構開發底層代碼，否則你並 +不需要了解（任何體系結構的）彙編語言。下面列舉的書籍雖然不能替代紮實的C +語言教育和多年的開發經驗，但如果需要的話，做爲參考還是不錯的： + + - "The C Programming Language" by Kernighan and Ritchie [Prentice Hall] + 《C程序設計語言（第2版·新版）》（徐寶文 李志 譯）[機械工業出版社] + - "Practical C Programming" by Steve Oualline [O'Reilly] + 《實用C語言編程（第三版）》（郭大海 譯）[中國電力出版社] + - "C: A Reference Manual" by Harbison and Steele [Prentice Hall] + 《C語言參考手冊（原書第5版）》（邱仲潘 等譯）[機械工業出版社] + +Linux內核使用GNU C和GNU工具鏈開發。雖然它遵循ISO C89標準，但也用到了一些 +標準中沒有定義的擴展。內核是自給自足的C環境，不依賴於標準C庫的支持，所以 +並不支持C標準中的部分定義。比如long long類型的大數除法和浮點運算就不允許 +使用。有時候確實很難弄清楚內核對工具鏈的要求和它所使用的擴展，不幸的是目 +前還沒有明確的參考資料可以解釋它們。請查閱gcc信息頁（使用「info gcc」命令 +顯示）獲得一些這方面信息。 + +請記住你是在學習怎麼和已經存在的開發社區打交道。它由一羣形形色色的人組成， +他們對代碼、風格和過程有著很高的標準。這些標準是在長期實踐中總結出來的， +適應於地理上分散的大型開發團隊。它們已經被很好得整理成檔，建議你在開發 +之前儘可能多的學習這些標準，而不要期望別人來適應你或者你公司的行爲方式。 + + +法律問題 +-------- + +Linux內核原始碼都是在GPL（通用公共許可證）的保護下發布的。要了解這種許可 +的細節請查看原始碼主目錄下的COPYING文件。Linux內核許可準則和如何使用 +`SPDX ` 標誌符說明在這個文件中 +:ref:`Documentation/translations/zh_TW/process/license-rules.rst ` +如果你對它還有更深入問題請聯繫律師，而不要在Linux內核郵件組上提問。因爲 +郵件組裡的人並不是律師，不要期望他們的話有法律效力。 + +對於GPL的常見問題和解答，請訪問以下連結： + https://www.gnu.org/licenses/gpl-faq.html + + +文檔 +---- + +Linux內核代碼中包含有大量的文檔。這些文檔對於學習如何與內核社區互動有著 +不可估量的價值。當一個新的功能被加入內核，最好把解釋如何使用這個功能的文 +檔也放進內核。當內核的改動導致面向用戶空間的接口發生變化時，最好將相關信 +息或手冊頁(manpages)的補丁發到mtk.manpages@gmail.com，以向手冊頁(manpages) +的維護者解釋這些變化。 + +以下是內核代碼中需要閱讀的文檔： + :ref:`Documentation/admin-guide/README.rst ` + 文件簡要介紹了Linux內核的背景，並且描述了如何配置和編譯內核。內核的 + 新用戶應該從這裡開始。 + + + :ref:`Documentation/process/changes.rst ` + 文件給出了用來編譯和使用內核所需要的最小軟體包列表。 + + :ref:`Documentation/translations/zh_TW/process/coding-style.rst ` + 描述Linux內核的代碼風格和理由。所有新代碼需要遵守這篇文檔中定義的規 + 范。大多數維護者只會接收符合規定的補丁，很多人也只會幫忙檢查符合風格 + 的代碼。 + + :ref:`Documentation/translations/zh_TW/process/submitting-patches.rst ` + :ref:`Documentation/process/submitting-drivers.rst ` + + 這兩份文檔明確描述如何創建和發送補丁，其中包括（但不僅限於)： + - 郵件內容 + - 郵件格式 + - 選擇收件人 + + 遵守這些規定並不能保證提交成功（因爲所有補丁需要通過嚴格的內容和風格 + 審查），但是忽視他們幾乎就意味著失敗。 + + 其他關於如何正確地生成補丁的優秀文檔包括： + "The Perfect Patch" + + https://www.ozlabs.org/~akpm/stuff/tpp.txt + + "Linux kernel patch submission format" + + https://web.archive.org/web/20180829112450/http://linux.yyz.us/patch-format.html + + :ref:`Documentation/translations/zh_TW/process/stable-api-nonsense.rst ` + 論證內核爲什麼特意不包括穩定的內核內部API，也就是說不包括像這樣的特 + 性： + + - 子系統中間層（爲了兼容性？） + - 在不同作業系統間易於移植的驅動程序 + - 減緩（甚至阻止）內核代碼的快速變化 + + 這篇文檔對於理解Linux的開發哲學至關重要。對於將開發平台從其他操作系 + 統轉移到Linux的人來說也很重要。 + + :ref:`Documentation/admin-guide/security-bugs.rst ` + 如果你認爲自己發現了Linux內核的安全性問題，請根據這篇文檔中的步驟來 + 提醒其他內核開發者並幫助解決這個問題。 + + :ref:`Documentation/translations/zh_TW/process/management-style.rst ` + + 描述內核維護者的工作方法及其共有特點。這對於剛剛接觸內核開發（或者對 + 它感到好奇）的人來說很重要，因爲它解釋了很多對於內核維護者獨特行爲的 + 普遍誤解與迷惑。 + + :ref:`Documentation/process/stable-kernel-rules.rst ` + 解釋了穩定版內核發布的規則，以及如何將改動放入這些版本的步驟。 + + :ref:`Documentation/process/kernel-docs.rst ` + 有助於內核開發的外部文檔列表。如果你在內核自帶的文檔中沒有找到你想找 + 的內容，可以查看這些文檔。 + + :ref:`Documentation/process/applying-patches.rst ` + 關於補丁是什麼以及如何將它打在不同內核開發分支上的好介紹 + +內核還擁有大量從代碼自動生成或者從 ReStructuredText(ReST) 標記生成的文檔， +比如這個文檔，它包含內核內部API的全面介紹以及如何妥善處理加鎖的規則。所有 +這些文檔都可以通過運行以下命令從內核代碼中生成爲PDF或HTML文檔:: + + make pdfdocs + make htmldocs + +ReST格式的文檔會生成在 Documentation/output. 目錄中。 +它們也可以用下列命令生成 LaTeX 和 ePub 格式文檔:: + + make latexdocs + make epubdocs + +如何成爲內核開發者 +------------------ +如果你對Linux內核開發一無所知，你應該訪問「Linux內核新手」計劃： + + https://kernelnewbies.org + +它擁有一個可以問各種最基本的內核開發問題的郵件列表（在提問之前一定要記得 +查找已往的郵件，確認是否有人已經回答過相同的問題）。它還擁有一個可以獲得 +實時反饋的IRC聊天頻道，以及大量對於學習Linux內核開發相當有幫助的文檔。 + +網站簡要介紹了原始碼組織結構、子系統劃分以及目前正在進行的項目（包括內核 +中的和單獨維護的）。它還提供了一些基本的幫助信息，比如如何編譯內核和打補 +丁。 + +如果你想加入內核開發社區並協助完成一些任務，卻找不到從哪裡開始，可以訪問 +「Linux內核房管員」計劃： + + https://kernelnewbies.org/KernelJanitors + +這是極佳的起點。它提供一個相對簡單的任務列表，列出內核代碼中需要被重新 +整理或者改正的地方。通過和負責這個計劃的開發者們一同工作，你會學到將補丁 +集成進內核的基本原理。如果還沒有決定下一步要做什麼的話，你還可能會得到方 +向性的指點。 + +在真正動手修改內核代碼之前，理解要修改的代碼如何運作是必需的。要達到這個 +目的，沒什麼辦法比直接讀代碼更有效了（大多數花招都會有相應的注釋），而且 +一些特製的工具還可以提供幫助。例如，「Linux代碼交叉引用」項目就是一個值得 +特別推薦的幫助工具，它將原始碼顯示在有編目和索引的網頁上。其中一個更新及 +時的內核源碼庫，可以通過以下地址訪問： + + https://elixir.bootlin.com/ + + +開發流程 +-------- + +目前Linux內核開發流程包括幾個「主內核分支」和很多子系統相關的內核分支。這 +些分支包括： + + - Linus 的內核源碼樹 + - 多個主要版本的穩定版內核樹 + - 子系統相關的內核樹 + - linux-next 集成測試樹 + + +主線樹 +------ +主線樹是由Linus Torvalds 維護的。你可以在https://kernel.org 網站或者代碼 +庫中下找到它。它的開發遵循以下步驟： + + - 每當一個新版本的內核被發布，爲期兩周的集成窗口將被打開。在這段時間裡 + 維護者可以向Linus提交大段的修改，通常這些修改已經被放到-mm內核中幾個 + 星期了。提交大量修改的首選方式是使用git工具（內核的代碼版本管理工具 + ，更多的信息可以在 https://git-scm.com/ 獲取），不過使用普通補丁也是 + 可以的。 + - 兩個星期以後-rc1版本內核發布。之後只有不包含可能影響整個內核穩定性的 + 新功能的補丁才可能被接受。請注意一個全新的驅動程序（或者文件系統）有 + 可能在-rc1後被接受是因爲這樣的修改完全獨立，不會影響其他的代碼，所以 + 沒有造成內核退步的風險。在-rc1以後也可以用git向Linus提交補丁，不過所 + 有的補丁需要同時被發送到相應的公衆郵件列表以徵詢意見。 + - 當Linus認爲當前的git源碼樹已經達到一個合理健全的狀態足以發布供人測試 + 時，一個新的-rc版本就會被發布。計劃是每周都發布新的-rc版本。 + - 這個過程一直持續下去直到內核被認爲達到足夠穩定的狀態，持續時間大概是 + 6個星期。 + +關於內核發布，值得一提的是Andrew Morton在linux-kernel郵件列表中如是說： + 「沒有人知道新內核何時會被發布，因爲發布是根據已知bug的情況來決定 + 的，而不是根據一個事先制定好的時間表。」 + +子系統特定樹 +------------ + +各種內核子系統的維護者——以及許多內核子系統開發人員——在原始碼庫中公開了他們 +當前的開發狀態。這樣，其他人就可以看到內核的不同區域發生了什麼。在開發速度 +很快的領域，可能會要求開發人員將提交的內容建立在這樣的子系統內核樹上，這樣 +就避免了提交與其他已經進行的工作之間的衝突。 + +這些存儲庫中的大多數都是Git樹，但是也有其他的scm在使用，或者補丁隊列被發布 +爲Quilt系列。這些子系統存儲庫的地址列在MAINTAINERS文件中。其中許多可以在 +https://git.kernel.org/上瀏覽。 + +在將一個建議的補丁提交到這樣的子系統樹之前，需要對它進行審查，審查主要發生 +在郵件列表上（請參見下面相應的部分）。對於幾個內核子系統，這個審查過程是通 +過工具補丁跟蹤的。Patchwork提供了一個Web界面，顯示補丁發布、對補丁的任何評 +論或修訂，維護人員可以將補丁標記爲正在審查、接受或拒絕。大多數補丁網站都列 +在 https://patchwork.kernel.org/ + +Linux-next 集成測試樹 +--------------------- + +在將子系統樹的更新合併到主線樹之前，需要對它們進行集成測試。爲此，存在一個 +特殊的測試存儲庫，其中幾乎每天都會提取所有子系統樹： + + https://git.kernel.org/？p=linux/kernel/git/next/linux-next.git + +通過這種方式，Linux-next 對下一個合併階段將進入主線內核的內容給出了一個概要 +展望。非常歡冒險的測試者運行測試Linux-next。 + +多個主要版本的穩定版內核樹 +----------------------------------- +由3個數字組成的內核版本號說明此內核是-stable版本。它們包含內核的相對較小且 +至關重要的修補，這些修補針對安全性問題或者嚴重的內核退步。 + +這種版本的內核適用於那些期望獲得最新的穩定版內核並且不想參與測試開發版或 +者實驗版的用戶。 + +穩定版內核樹版本由「穩定版」小組（郵件地址）維護，一般 +隔周發布新版本。 + +內核源碼中的 :ref:`Documentation/process/stable-kernel-rules.rst ` +文件具體描述了可被穩定版內核接受的修改類型以及發布的流程。 + + +報告bug +------- + +bugzilla.kernel.org是Linux內核開發者們用來跟蹤內核Bug的網站。我們鼓勵用 +戶在這個工具中報告找到的所有bug。如何使用內核bugzilla的細節請訪問： + + http://test.kernel.org/bugzilla/faq.html + +內核源碼主目錄中的:ref:`admin-guide/reporting-bugs.rst ` +文件里有一個很好的模板。它指導用戶如何報告可能的內核bug以及需要提供哪些信息 +來幫助內核開發者們找到問題的根源。 + + +利用bug報告 +----------- + +練習內核開發技能的最好辦法就是修改其他人報告的bug。你不光可以幫助內核變 +得更加穩定，還可以學會如何解決實際問題從而提高自己的技能，並且讓其他開發 +者感受到你的存在。修改bug是贏得其他開發者讚譽的最好辦法，因爲並不是很多 +人都喜歡浪費時間去修改別人報告的bug。 + +要嘗試修改已知的bug，請訪問 http://bugzilla.kernel.org 網址。 + + +郵件列表 +-------- + +正如上面的文檔所描述，大多數的骨幹內核開發者都加入了Linux Kernel郵件列 +表。如何訂閱和退訂列表的細節可以在這裡找到： + + http://vger.kernel.org/vger-lists.html#linux-kernel + +網上很多地方都有這個郵件列表的存檔(archive)。可以使用搜尋引擎來找到這些 +存檔。比如： + + http://dir.gmane.org/gmane.linux.kernel + +在發信之前，我們強烈建議你先在存檔中搜索你想要討論的問題。很多已經被詳細 +討論過的問題只在郵件列表的存檔中可以找到。 + +大多數內核子系統也有自己獨立的郵件列表來協調各自的開發工作。從 +MAINTAINERS文件中可以找到不同話題對應的郵件列表。 + +很多郵件列表架設在kernel.org伺服器上。這些列表的信息可以在這裡找到： + + http://vger.kernel.org/vger-lists.html + +在使用這些郵件列表時，請記住保持良好的行爲習慣。下面的連結提供了與這些列 +表（或任何其它郵件列表）交流的一些簡單規則，雖然內容有點濫竽充數。 + + http://www.albion.com/netiquette/ + +當有很多人回覆你的郵件時，郵件的抄送列表會變得很長。請不要將任何人從抄送 +列表中刪除，除非你有足夠的理由這麼做。也不要只回復到郵件列表。請習慣於同 +一封郵件接收兩次（一封來自發送者一封來自郵件列表），而不要試圖通過添加一 +些奇特的郵件頭來解決這個問題，人們不會喜歡的。 + +記住保留你所回復內容的上下文和源頭。在你回覆郵件的頂部保留「某某某說到……」 +這幾行。將你的評論加在被引用的段落之間而不要放在郵件的頂部。 + +如果你在郵件中附帶補丁，請確認它們是可以直接閱讀的純文本（如 +:ref:`Documentation/translations/zh_TW/process/submitting-patches.rst ` +文檔中所述）。內核開發者們不希望遇到附件或者被壓縮了的補丁。只有這樣才能 +保證他們可以直接評論你的每行代碼。請確保你使用的郵件發送程序不會修改空格 +和制表符。一個防範性的測試方法是先將郵件發送給自己，然後自己嘗試是否可以 +順利地打上收到的補丁。如果測試不成功，請調整或者更換你的郵件發送程序直到 +它正確工作爲止。 + +總而言之，請尊重其他的郵件列表訂閱者。 + + +同內核社區合作 +---------------- + +內核社區的目標就是提供盡善盡美的內核。所以當你提交補丁期望被接受進內核的 +時候，它的技術價值以及其他方面都將被評審。那麼你可能會得到什麼呢？ + + - 批評 + - 評論 + - 要求修改 + - 要求證明修改的必要性 + - 沉默 + +要記住，這些是把補丁放進內核的正常情況。你必須學會聽取對補丁的批評和評論， +從技術層面評估它們，然後要麼重寫你的補丁要麼簡明扼要地論證修改是不必要 +的。如果你發的郵件沒有得到任何回應，請過幾天後再試一次，因爲有時信件會湮 +沒在茫茫信海中。 + +你不應該做的事情： + + - 期望自己的補丁不受任何質疑就直接被接受 + - 翻臉 + - 忽略別人的評論 + - 沒有按照別人的要求做任何修改就重新提交 + +在一個努力追尋最好技術方案的社區里，對於一個補丁有多少好處總會有不同的見 +解。你必須要抱著合作的態度，願意改變自己的觀點來適應內核的風格。或者至少 +願意去證明你的想法是有價值的。記住，犯錯誤是允許的，只要你願意朝著正確的 +方案去努力。 + +如果你的第一個補丁換來的是一堆修改建議，這是很正常的。這並不代表你的補丁 +不會被接受，也不意味著有人和你作對。你只需要改正所有提出的問題然後重新發 +送你的補丁。 + +內核社區和公司文化的差異 +------------------------ + +內核社區的工作模式同大多數傳統公司開發隊伍的工作模式並不相同。下面這些例 +子，可以幫助你避免某些可能發生問題： +用這些話介紹你的修改提案會有好處： + + - 它同時解決了多個問題 + - 它刪除了2000行代碼 + - 這是補丁，它已經解釋了我想要說明的 + - 我在5種不同的體系結構上測試過它…… + - 這是一系列小補丁用來…… + - 這個修改提高了普通機器的性能…… + +應該避免如下的說法： + + - 我們在AIX/ptx/Solaris就是這麼做的，所以這麼做肯定是好的…… + - 我做這行已經20年了，所以…… + - 爲了我們公司賺錢考慮必須這麼做 + - 這是我們的企業產品線所需要的 + - 這裡是描述我觀點的1000頁設計文檔 + - 這是一個5000行的補丁用來…… + - 我重寫了現在亂七八糟的代碼，這就是…… + - 我被規定了最後期限，所以這個補丁需要立刻被接受 + +另外一個內核社區與大部分傳統公司的軟體開發隊伍不同的地方是無法面對面地交 +流。使用電子郵件和IRC聊天工具做爲主要溝通工具的一個好處是性別和種族歧視 +將會更少。Linux內核的工作環境更能接受婦女和少數族羣，因爲每個人在別人眼 +里只是一個郵件地址。國際化也幫助了公平的實現，因爲你無法通過姓名來判斷人 +的性別。男人有可能叫李麗，女人也有可能叫王剛。大多數在Linux內核上工作過 +並表達過看法的女性對在linux上工作的經歷都給出了正面的評價。 + +對於一些不習慣使用英語的人來說，語言可能是一個引起問題的障礙。在郵件列表 +中要正確地表達想法必需良好地掌握語言，所以建議你在發送郵件之前最好檢查一 +下英文寫得是否正確。 + + +拆分修改 +-------- + +Linux內核社區並不喜歡一下接收大段的代碼。修改需要被恰當地介紹、討論並且 +拆分成獨立的小段。這幾乎完全和公司中的習慣背道而馳。你的想法應該在開發最 +開始的階段就讓大家知道，這樣你就可以及時獲得對你正在進行的開發的反饋。這 +樣也會讓社區覺得你是在和他們協作，而不是僅僅把他們當作傾銷新功能的對象。 +無論如何，你不要一次性地向郵件列表發送50封信，你的補丁序列應該永遠用不到 +這麼多。 + +將補丁拆開的原因如下： + +1) 小的補丁更有可能被接受，因爲它們不需要太多的時間和精力去驗證其正確性。 + 一個5行的補丁，可能在維護者看了一眼以後就會被接受。而500行的補丁則 + 需要數個小時來審查其正確性（所需時間隨補丁大小增加大約呈指數級增長）。 + + 當出了問題的時候，小的補丁也會讓調試變得非常容易。一個一個補丁地回溯 + 將會比仔細剖析一個被打上的大補丁（這個補丁破壞了其他東西）容易得多。 + +2）不光發送小的補丁很重要，在提交之前重新編排、化簡（或者僅僅重新排列） + 補丁也是很重要的。 + +這裡有內核開發者Al Viro打的一個比方： + 「想像一個老師正在給學生批改數學作業。老師並不希望看到學生爲了得 + 到正確解法所進行的嘗試和產生的錯誤。他希望看到的是最乾淨最優雅的 + 解答。好學生了解這點，絕不會把最終解決之前的中間方案提交上去。」 + + 內核開發也是這樣。維護者和評審者不希望看到一個人在解決問題時的思 + 考過程。他們只希望看到簡單和優雅的解決方案。 + +直接給出一流的解決方案，和社區一起協作討論尚未完成的工作，這兩者之間似乎 +很難找到一個平衡點。所以最好儘早開始收集有利於你進行改進的反饋；同時也要 +保證修改分成很多小塊，這樣在整個項目都準備好被包含進內核之前，其中的一部 +分可能會先被接收。 + +必須了解這樣做是不可接受的：試圖將未完成的工作提交進內核，然後再找時間修 +復。 + + +證明修改的必要性 +---------------- +除了將補丁拆成小塊，很重要的一點是讓Linux社區了解他們爲什麼需要這樣修改。 +你必須證明新功能是有人需要的並且是有用的。 + + +記錄修改 +-------- + +當你發送補丁的時候，需要特別留意郵件正文的內容。因爲這裡的信息將會做爲補 +丁的修改記錄(ChangeLog)，會被一直保留以備大家查閱。它需要完全地描述補丁， +包括： + + - 爲什麼需要這個修改 + - 補丁的總體設計 + - 實現細節 + - 測試結果 + +想了解它具體應該看起來像什麼，請查閱以下文檔中的「ChangeLog」章節： + 「The Perfect Patch」 + https://www.ozlabs.org/~akpm/stuff/tpp.txt + + +這些事情有時候做起來很難。要在任何方面都做到完美可能需要好幾年時間。這是 +一個持續提高的過程，它需要大量的耐心和決心。只要不放棄，你一定可以做到。 +很多人已經做到了，而他們都曾經和現在的你站在同樣的起點上。 + + +感謝 +---- +感謝Paolo Ciarrocchi允許「開發流程」部分基於他所寫的文章 +(http://www.kerneltravel.net/newbie/2.6-development_process)，感謝Randy +Dunlap和Gerrit Huizenga完善了應該說和不該說的列表。感謝Pat Mochel, Hanna +Linder, Randy Dunlap, Kay Sievers, Vojtech Pavlik, Jan Kara, Josh Boyer, +Kees Cook, Andrew Morton, Andi Kleen, Vadim Lobanov, Jesper Juhl, Adrian +Bunk, Keri Harris, Frans Pop, David A. Wheeler, Junio Hamano, Michael +Kerrisk和Alex Shepard的評審、建議和貢獻。沒有他們的幫助，這篇文檔是不可 +能完成的。 + + + +英文版維護者： Greg Kroah-Hartman + diff --git a/Documentation/translations/zh_TW/process/index.rst b/Documentation/translations/zh_TW/process/index.rst new file mode 100644 index 000000000000..ec7ad14bfd13 --- /dev/null +++ b/Documentation/translations/zh_TW/process/index.rst @@ -0,0 +1,67 @@ +.. SPDX-License-Identifier: GPL-2.0 + +.. raw:: latex + + \renewcommand\thesection* + \renewcommand\thesubsection* + +.. include:: ../disclaimer-zh_TW.rst + +:Original: :ref:`Documentation/process/index.rst ` +:Translator: Alex Shi + Hu Haowen + +.. _tw_process_index: + +與Linux 內核社區一起工作 +======================== + +你想成爲Linux內核開發人員嗎？歡迎之至！在學習許多關於內核的技術知識的同時， +了解我們社區的工作方式也很重要。閱讀這些文檔可以讓您以更輕鬆的、麻煩更少的 +方式將更改合併到內核。 + +以下是每位開發人員都應閱讀的基本指南： + +.. toctree:: + :maxdepth: 1 + + howto + code-of-conduct + code-of-conduct-interpretation + submitting-patches + programming-language + coding-style + development-process + email-clients + license-rules + kernel-enforcement-statement + kernel-driver-statement + +其它大多數開發人員感興趣的社區指南： + + +.. toctree:: + :maxdepth: 1 + + submitting-drivers + submit-checklist + stable-api-nonsense + stable-kernel-rules + management-style + embargoed-hardware-issues + +這些是一些總體性技術指南，由於不大好分類而放在這裡： + +.. toctree:: + :maxdepth: 1 + + magic-number + volatile-considered-harmful + +.. only:: subproject and html + + 目錄 + ==== + + * :ref:`genindex` + diff --git a/Documentation/translations/zh_TW/process/kernel-driver-statement.rst b/Documentation/translations/zh_TW/process/kernel-driver-statement.rst new file mode 100644 index 000000000000..8f225379b12c --- /dev/null +++ b/Documentation/translations/zh_TW/process/kernel-driver-statement.rst @@ -0,0 +1,203 @@ +.. SPDX-License-Identifier: GPL-2.0 + +.. _zh_process_statement_driver: + +.. include:: ../disclaimer-zh_TW.rst + +:Original: :ref:`Documentation/process/kernel-driver-statement.rst ` +:Translator: Alex Shi + Hu Haowen + +內核驅動聲明 +------------ + +關於Linux內核模塊的立場聲明 +=========================== + +我們，以下署名的Linux內核開發人員，認爲任何封閉源Linux內核模塊或驅動程序都是 +有害的和不可取的。我們已經一再發現它們對Linux用戶，企業和更大的Linux生態系統 +有害。這樣的模塊否定了Linux開發模型的開放性，穩定性，靈活性和可維護性，並使 +他們的用戶無法使用Linux社區的專業知識。提供閉源內核模塊的供應商迫使其客戶 +放棄Linux的主要優勢或選擇新的供應商。因此，爲了充分利用開源所提供的成本節省和 +共享支持優勢，我們敦促供應商採取措施，以開源內核代碼在Linux上爲其客戶提供支持。 + +我們只爲自己說話，而不是我們今天可能會爲之工作，過去或將來會爲之工作的任何公司。 + + - 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 + - Aaro Koskinen + - 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 + diff --git a/Documentation/translations/zh_TW/process/kernel-enforcement-statement.rst b/Documentation/translations/zh_TW/process/kernel-enforcement-statement.rst new file mode 100644 index 000000000000..99e21d22800d --- /dev/null +++ b/Documentation/translations/zh_TW/process/kernel-enforcement-statement.rst @@ -0,0 +1,155 @@ +.. SPDX-License-Identifier: GPL-2.0 + +.. _tw_process_statement_kernel: + +.. include:: ../disclaimer-zh_TW.rst + +:Original: :ref:`Documentation/process/kernel-enforcement-statement.rst ` +:Translator: Alex Shi + Hu Haowen + +Linux 內核執行聲明 +------------------ + +作爲Linux內核的開發人員，我們對如何使用我們的軟體以及如何實施軟體許可證有著 +濃厚的興趣。遵守GPL-2.0的互惠共享義務對我們軟體和社區的長期可持續性至關重要。 + +雖然有權強制執行對我們社區的貢獻中的單獨版權權益，但我們有共同的利益，即確保 +個人強制執行行動的方式有利於我們的社區，不會對我們軟體生態系統的健康和增長 +產生意外的負面影響。爲了阻止無益的執法行動，我們同意代表我們自己和我們版權 +利益的任何繼承人對Linux內核用戶作出以下符合我們開發社區最大利益的承諾: + + 儘管有GPL-2.0的終止條款，我們同意，採用以下GPL-3.0條款作爲我們許可證下的 + 附加許可，作爲任何對許可證下權利的非防禦性主張，這符合我們開發社區的最佳 + 利益。 + + 但是，如果您停止所有違反本許可證的行爲，則您從特定版權持有人處獲得的 + 許可證將被恢復：（a）暫時恢復，除非版權持有人明確並最終終止您的許可證； + 以及（b）永久恢復, 如果版權持有人未能在你終止違反後60天內以合理方式 + 通知您違反本許可證的行爲，則永久恢復您的許可證。 + + 此外，如果版權所有者以某種合理的方式通知您違反了本許可，這是您第一次 + 從該版權所有者處收到違反本許可的通知（對於任何作品），並且您在收到通知 + 後的30天內糾正違規行爲。則您從特定版權所有者處獲得的許可將永久恢復. + +我們提供這些保證的目的是鼓勵更多地使用該軟體。我們希望公司和個人使用、修改和 +分發此軟體。我們希望以公開和透明的方式與用戶合作，以消除我們對法規遵從性或強制 +執行的任何不確定性，這些不確定性可能會限制我們軟體的採用。我們將法律行動視爲 +最後手段，只有在其他社區努力未能解決這一問題時才採取行動。 + +最後，一旦一個不合規問題得到解決，我們希望用戶會感到歡迎，加入我們爲之努力的 +這個項目。共同努力，我們會更強大。 + +除了下面提到的以外，我們只爲自己說話，而不是爲今天、過去或將來可能爲之工作的 +任何公司說話。 + + - Laura Abbott + - Bjorn Andersson (Linaro) + - Andrea Arcangeli + - Neil Armstrong + - Jens Axboe + - Pablo Neira Ayuso + - Khalid Aziz + - Ralf Baechle + - Felipe Balbi + - Arnd Bergmann + - Ard Biesheuvel + - Tim Bird + - Paolo Bonzini + - Christian Borntraeger + - Mark Brown (Linaro) + - Paul Burton + - Javier Martinez Canillas + - Rob Clark + - Kees Cook (Google) + - Jonathan Corbet + - Dennis Dalessandro + - Vivien Didelot (Savoir-faire Linux) + - Hans de Goede + - Mel Gorman (SUSE) + - Sven Eckelmann + - Alex Elder (Linaro) + - Fabio Estevam + - Larry Finger + - Bhumika Goyal + - Andy Gross + - Juergen Gross + - Shawn Guo + - Ulf Hansson + - Stephen Hemminger (Microsoft) + - 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 + - Chuck Lever (Oracle) + - Daniel Lezcano + - Shaohua Li + - Xin Long + - Tony Luck + - Catalin Marinas (Arm Ltd) + - Mike Marshall + - Chris Mason + - Paul E. McKenney + - Arnaldo Carvalho de Melo + - David S. Miller + - Ingo Molnar + - Kuninori Morimoto + - Trond Myklebust + - Martin K. Petersen (Oracle) + - Borislav Petkov + - Jiri Pirko + - Josh Poimboeuf + - Sebastian Reichel (Collabora) + - Guenter Roeck + - Joerg Roedel + - Leon Romanovsky + - Steven Rostedt (VMware) + - Frank Rowand + - Ivan Safonov + - Anna Schumaker + - Jes Sorensen + - K.Y. Srinivasan + - David Sterba (SUSE) + - Heiko Stuebner + - Jiri Kosina (SUSE) + - Willy Tarreau + - Dmitry Torokhov + - Linus Torvalds + - Thierry Reding + - Rik van Riel + - Luis R. Rodriguez + - Geert Uytterhoeven (Glider bvba) + - Eduardo Valentin (Amazon.com) + - Daniel Vetter + - Linus Walleij + - Richard Weinberger + - Dan Williams + - Rafael J. Wysocki + - Arvind Yadav + - Masahiro Yamada + - Wei Yongjun + - Lv Zheng + - Marc Zyngier (Arm Ltd) + diff --git a/Documentation/translations/zh_TW/process/license-rules.rst b/Documentation/translations/zh_TW/process/license-rules.rst new file mode 100644 index 000000000000..ad2b80f97123 --- /dev/null +++ b/Documentation/translations/zh_TW/process/license-rules.rst @@ -0,0 +1,374 @@ +.. SPDX-License-Identifier: GPL-2.0 + +.. SPDX-License-Identifier: GPL-2.0 + +.. include:: ../disclaimer-zh_TW.rst + +:Original: :ref:`Documentation/process/license-rules.rst ` +:Translator: Alex Shi + Hu Haowen + +.. _tw_kernel_licensing: + +Linux內核許可規則 +================= + +Linux內核根據LICENSES/preferred/GPL-2.0中提供的GNU通用公共許可證版本2 +（GPL-2.0）的條款提供，並在LICENSES/exceptions/Linux-syscall-note中顯式 +描述了例外的系統調用，如COPYING文件中所述。 + +此文檔文件提供了如何對每個源文件進行注釋以使其許可證清晰明確的說明。 +它不會取代內核的許可證。 + +內核原始碼作爲一個整體適用於COPYING文件中描述的許可證，但是單個源文件可以 +具有不同的與GPL-20兼容的許可證:: + + GPL-1.0+ : GNU通用公共許可證v1.0或更高版本 + GPL-2.0+ : GNU通用公共許可證v2.0或更高版本 + LGPL-2.0 : 僅限GNU庫通用公共許可證v2 + LGPL-2.0+: GNU 庫通用公共許可證v2或更高版本 + LGPL-2.1 : 僅限GNU寬通用公共許可證v2.1 + LGPL-2.1+: GNU寬通用公共許可證v2.1或更高版本 + +除此之外，個人文件可以在雙重許可下提供，例如一個兼容的GPL變體，或者BSD， +MIT等許可。 + +用戶空間API（UAPI）頭文件描述了用戶空間程序與內核的接口，這是一種特殊情況。 +根據內核COPYING文件中的注釋，syscall接口是一個明確的邊界，它不會將GPL要求 +擴展到任何使用它與內核通信的軟體。由於UAPI頭文件必須包含在創建在Linux內核 +上運行的可執行文件的任何源文件中，因此此例外必須記錄在特別的許可證表述中。 + +表達源文件許可證的常用方法是將匹配的樣板文本添加到文件的頂部注釋中。由於 +格式，拼寫錯誤等，這些「樣板」很難通過那些在上下文中使用的驗證許可證合規性 +的工具。 + +樣板文本的替代方法是在每個源文件中使用軟體包數據交換（SPDX）許可證標識符。 +SPDX許可證標識符是機器可解析的，並且是用於提供文件內容的許可證的精確縮寫。 +SPDX許可證標識符由Linux 基金會的SPDX 工作組管理，並得到了整個行業，工具 +供應商和法律團隊的合作夥伴的一致同意。有關詳細信息，請參閱 +https://spdx.org/ + +Linux內核需要所有源文件中的精確SPDX標識符。內核中使用的有效標識符在 +`許可標識符`_ 一節中進行了解釋，並且已可以在 +https://spdx.org/licenses/ 上的官方SPDX許可證列表中檢索，並附帶許可證 +文本。 + +許可標識符語法 +-------------- + +1.安置: + +   內核文件中的SPDX許可證標識符應添加到可包含注釋的文件中的第一行。對於大多 + 數文件，這是第一行，除了那些在第一行中需要'#!PATH_TO_INTERPRETER'的腳本。 + 對於這些腳本，SPDX標識符進入第二行。 + +| + +2. 風格: + + SPDX許可證標識符以注釋的形式添加。注釋樣式取決於文件類型:: + + C source: // SPDX-License-Identifier: + C header: /* SPDX-License-Identifier: */ + ASM: /* SPDX-License-Identifier: */ + scripts: # SPDX-License-Identifier: + .rst: .. SPDX-License-Identifier: + .dts{i}: // SPDX-License-Identifier: + + 如果特定工具無法處理標準注釋樣式，則應使用工具接受的相應注釋機制。這是在 + C 頭文件中使用「/\*\*/」樣式注釋的原因。過去在使用生成的.lds文件中觀察到 + 構建被破壞，其中'ld'無法解析C++注釋。現在已經解決了這個問題，但仍然有較 + 舊的彙編程序工具無法處理C++樣式的注釋。 + +| + +3. 句法: + + 是SPDX許可證列表中的SPDX短格式許可證標識符，或者在許可 + 證例外適用時由「WITH」分隔的兩個SPDX短格式許可證標識符的組合。當應用多個許 + 可證時，表達式由分隔子表達式的關鍵字「AND」，「OR」組成，並由「（」，「）」包圍。 + + 帶有「或更高」選項的[L]GPL等許可證的許可證標識符通過使用「+」來表示「或更高」 + 選項來構建。:: + + // SPDX-License-Identifier: GPL-2.0+ + // SPDX-License-Identifier: LGPL-2.1+ + + 當需要修正的許可證時，應使用WITH。 例如，linux內核UAPI文件使用表達式:: + + // SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note + // SPDX-License-Identifier: GPL-2.0+ WITH Linux-syscall-note + + 其它在內核中使用WITH例外的事例如下:: + + // SPDX-License-Identifier: GPL-2.0 WITH mif-exception + // SPDX-License-Identifier: GPL-2.0+ WITH GCC-exception-2.0 + + 例外只能與特定的許可證標識符一起使用。有效的許可證標識符列在異常文本文件 + 的標記中。有關詳細信息，請參閱 `許可標識符`_ 一章中的 `例外`_ 。 + + 如果文件是雙重許可且只選擇一個許可證，則應使用OR。例如，一些dtsi文件在雙 + 許可下可用:: + + // SPDX-License-Identifier: GPL-2.0 OR BSD-3-Clause + + 內核中雙許可文件中許可表達式的示例:: + + // SPDX-License-Identifier: GPL-2.0 OR MIT + // SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause + // SPDX-License-Identifier: GPL-2.0 OR Apache-2.0 + // SPDX-License-Identifier: GPL-2.0 OR MPL-1.1 + // SPDX-License-Identifier: (GPL-2.0 WITH Linux-syscall-note) OR MIT + // SPDX-License-Identifier: GPL-1.0+ OR BSD-3-Clause OR OpenSSL + + 如果文件具有多個許可證，其條款全部適用於使用該文件，則應使用AND。例如， + 如果代碼是從另一個項目繼承的，並且已經授予了將其放入內核的權限，但原始 + 許可條款需要保持有效:: + + // SPDX-License-Identifier: (GPL-2.0 WITH Linux-syscall-note) AND MIT + + 另一個需要遵守兩套許可條款的例子是:: + + // SPDX-License-Identifier: GPL-1.0+ AND LGPL-2.1+ + +許可標識符 +---------- + +當前使用的許可證以及添加到內核的代碼許可證可以分解爲： + +1. _`優先許可`: + + 應儘可能使用這些許可證，因爲它們已知完全兼容並廣泛使用。這些許可證在內核 + 目錄:: + + LICENSES/preferred/ + + 此目錄中的文件包含完整的許可證文本和 `元標記`_ 。文件名與SPDX許可證標識 + 符相同，後者應用於源文件中的許可證。 + + 例如:: + + LICENSES/preferred/GPL-2.0 + + 包含GPLv2許可證文本和所需的元標籤:: + + LICENSES/preferred/MIT + + 包含MIT許可證文本和所需的元標記 + + _`元標記`: + + 許可證文件中必須包含以下元標記： + + - Valid-License-Identifier: + +   一行或多行, 聲明那些許可標識符在項目內有效, 以引用此特定許可的文本。通 + 常這是一個有效的標識符，但是例如對於帶有'或更高'選項的許可證，兩個標識 + 符都有效。 + + - SPDX-URL: + + SPDX頁面的URL，其中包含與許可證相關的其他信息. + + - Usage-Guidance: + + 使用建議的自由格式文本。該文本必須包含SPDX許可證標識符的正確示例，因爲 + 它們應根據 `許可標識符語法`_ 指南放入源文件中。 + + - License-Text: + + 此標記之後的所有文本都被視爲原始許可文本 + + 文件格式示例:: + + Valid-License-Identifier: GPL-2.0 + Valid-License-Identifier: GPL-2.0+ + SPDX-URL: https://spdx.org/licenses/GPL-2.0.html + Usage-Guide: + To use this license in source code, put one of the following SPDX + tag/value pairs into a comment according to the placement + guidelines in the licensing rules documentation. + For 'GNU General Public License (GPL) version 2 only' use: + SPDX-License-Identifier: GPL-2.0 + For 'GNU General Public License (GPL) version 2 or any later version' use: + SPDX-License-Identifier: GPL-2.0+ + License-Text: + Full license text + + :: + + SPDX-License-Identifier: MIT + SPDX-URL: https://spdx.org/licenses/MIT.html + Usage-Guide: + To use this license in source code, put the following SPDX + tag/value pair into a comment according to the placement + guidelines in the licensing rules documentation. + SPDX-License-Identifier: MIT + License-Text: + Full license text + +| + +2. 不推薦的許可證: + + 這些許可證只應用於現有代碼或從其他項目導入代碼。這些許可證在內核目錄:: + + LICENSES/other/ + + 此目錄中的文件包含完整的許可證文本和 `元標記`_ 。文件名與SPDX許可證標識 + 符相同，後者應用於源文件中的許可證。 + + 例如:: + + LICENSES/other/ISC + + 包含國際系統聯合許可文本和所需的元標籤:: + + LICENSES/other/ZLib + + 包含ZLIB許可文本和所需的元標籤. + + 元標籤: + + 「其他」許可證的元標籤要求與 `優先許可`_ 的要求相同。 + + 文件格式示例:: + + Valid-License-Identifier: ISC + SPDX-URL: https://spdx.org/licenses/ISC.html + Usage-Guide: + Usage of this license in the kernel for new code is discouraged + and it should solely be used for importing code from an already + existing project. + To use this license in source code, put the following SPDX + tag/value pair into a comment according to the placement + guidelines in the licensing rules documentation. + SPDX-License-Identifier: ISC + License-Text: + Full license text + +| + +3. _`例外`: + + 某些許可證可以修改，並允許原始許可證不具有的某些例外權利。這些例外在 + 內核目錄:: + + LICENSES/exceptions/ + + 此目錄中的文件包含完整的例外文本和所需的 `例外元標記`_ 。 + + 例如:: + + LICENSES/exceptions/Linux-syscall-note + + 包含Linux內核的COPYING文件中記錄的Linux系統調用例外，該文件用於UAPI + 頭文件。例如:: + + LICENSES/exceptions/GCC-exception-2.0 + + 包含GCC'連結例外'，它允許獨立於其許可證的任何二進位文件與標記有此例外的 + 文件的編譯版本連結。這是從GPL不兼容原始碼創建可運行的可執行文件所必需的。 + + _`例外元標記`: + + 以下元標記必須在例外文件中可用： + + - SPDX-Exception-Identifier: + +   一個可與SPDX許可證標識符一起使用的例外標識符。 + + - SPDX-URL: + + SPDX頁面的URL，其中包含與例外相關的其他信息。 + + - SPDX-Licenses: + +   以逗號分隔的例外可用的SPDX許可證標識符列表。 + + - Usage-Guidance: + + 使用建議的自由格式文本。必須在文本後面加上SPDX許可證標識符的正確示例， + 因爲它們應根據 `許可標識符語法`_ 指南放入源文件中。 + + - Exception-Text: + + 此標記之後的所有文本都被視爲原始異常文本 + + 文件格式示例:: + + SPDX-Exception-Identifier: Linux-syscall-note + SPDX-URL: https://spdx.org/licenses/Linux-syscall-note.html + SPDX-Licenses: GPL-2.0, GPL-2.0+, GPL-1.0+, LGPL-2.0, LGPL-2.0+, LGPL-2.1, LGPL-2.1+ + Usage-Guidance: + This exception is used together with one of the above SPDX-Licenses + to mark user-space API (uapi) header files so they can be included + into non GPL compliant user-space application code. + To use this exception add it with the keyword WITH to one of the + identifiers in the SPDX-Licenses tag: + SPDX-License-Identifier: WITH Linux-syscall-note + Exception-Text: + Full exception text + + :: + + SPDX-Exception-Identifier: GCC-exception-2.0 + SPDX-URL: https://spdx.org/licenses/GCC-exception-2.0.html + SPDX-Licenses: GPL-2.0, GPL-2.0+ + Usage-Guidance: + The "GCC Runtime Library exception 2.0" is used together with one + of the above SPDX-Licenses for code imported from the GCC runtime + library. + To use this exception add it with the keyword WITH to one of the + identifiers in the SPDX-Licenses tag: + SPDX-License-Identifier: WITH GCC-exception-2.0 + Exception-Text: + Full exception text + + +所有SPDX許可證標識符和例外都必須在LICENSES子目錄中具有相應的文件。這是允許 +工具驗證（例如checkpatch.pl）以及準備好從源讀取和提取許可證所必需的, 這是 +各種FOSS組織推薦的，例如 `FSFE REUSE initiative `_. + +_`模塊許可` +----------------- + + 可加載內核模塊還需要MODULE_LICENSE（）標記。此標記既不替代正確的原始碼 + 許可證信息（SPDX-License-Identifier），也不以任何方式表示或確定提供模塊 + 原始碼的確切許可證。 + + 此標記的唯一目的是提供足夠的信息，該模塊是否是自由軟體或者是內核模塊加 + 載器和用戶空間工具的專有模塊。 + + MODULE_LICENSE（）的有效許可證字符串是: + + ============================= ============================================= + "GPL" 模塊是根據GPL版本2許可的。這並不表示僅限於 + GPL-2.0或GPL-2.0或更高版本之間的任何區別。 + 最正確許可證信息只能通過相應源文件中的許可證 + 信息來確定 + + "GPL v2" 和"GPL"相同，它的存在是因爲歷史原因。 + + "GPL and additional rights" 表示模塊源在GPL v2變體和MIT許可下雙重許可的 + 歷史變體。請不要在新代碼中使用。 + + "Dual MIT/GPL" 表達該模塊在GPL v2變體或MIT許可證選擇下雙重 + 許可的正確方式。 + + "Dual BSD/GPL" 該模塊根據GPL v2變體或BSD許可證選擇進行雙重 + 許可。 BSD許可證的確切變體只能通過相應源文件 + 中的許可證信息來確定。 + + "Dual MPL/GPL" 該模塊根據GPL v2變體或Mozilla Public License + （MPL）選項進行雙重許可。 MPL許可證的確切變體 + 只能通過相應的源文件中的許可證信息來確定。 + + "Proprietary" 該模塊屬於專有許可。此字符串僅用於專有的第三 + 方模塊，不能用於在內核樹中具有原始碼的模塊。 + 以這種方式標記的模塊在加載時會使用'P'標記汙 + 染內核，並且內核模塊加載器拒絕將這些模塊連結 + 到使用EXPORT_SYMBOL_GPL（）導出的符號。 + ============================= ============================================= + + diff --git a/Documentation/translations/zh_TW/process/magic-number.rst b/Documentation/translations/zh_TW/process/magic-number.rst new file mode 100644 index 000000000000..ae321a9aaece --- /dev/null +++ b/Documentation/translations/zh_TW/process/magic-number.rst @@ -0,0 +1,148 @@ +.. SPDX-License-Identifier: GPL-2.0 + +.. _tw_magicnumbers: + +.. include:: ../disclaimer-zh_TW.rst + +:Original: :ref:`Documentation/process/magic-number.rst ` + +如果想評論或更新本文的內容，請直接發信到LKML。如果你使用英文交流有困難的話，也可 +以向中文版維護者求助。如果本翻譯更新不及時或者翻譯存在問題，請聯繫中文版維護者:: + + 中文版維護者： 賈威威 Jia Wei Wei + 中文版翻譯者： 賈威威 Jia Wei Wei + 中文版校譯者： 賈威威 Jia Wei Wei + 胡皓文 Hu Haowen + +Linux 魔術數 +============ + +這個文件是有關當前使用的魔術值註冊表。當你給一個結構添加了一個魔術值，你也應該把這個魔術值添加到這個文件，因爲我們最好把用於各種結構的魔術值統一起來。 + +使用魔術值來保護內核數據結構是一個非常好的主意。這就允許你在運行期檢查(a)一個結構是否已經被攻擊，或者(b)你已經給一個例行程序通過了一個錯誤的結構。後一種情況特別地有用---特別是當你通過一個空指針指向結構體的時候。tty源碼，例如，經常通過特定驅動使用這種方法並且反覆地排列特定方面的結構。 + +使用魔術值的方法是在結構的開始處聲明的，如下:: + + struct tty_ldisc { + int magic; + ... + }; + +當你以後給內核添加增強功能的時候，請遵守這條規則！這樣就會節省數不清的調試時間，特別是一些古怪的情況，例如，數組超出範圍並且重新寫了超出部分。遵守這個規則，‪這些情況可以被快速地，安全地避免。 + + Theodore Ts'o + 31 Mar 94 + +給當前的Linux 2.1.55添加魔術表。 + + Michael Chastain + + 22 Sep 1997 + +現在應該最新的Linux 2.1.112.因爲在特性凍結期間，不能在2.2.x前改變任何東西。這些條目被數域所排序。 + + Krzysztof G.Baranowski + + 29 Jul 1998 + +更新魔術表到Linux 2.5.45。剛好越過特性凍結，但是有可能還會有一些新的魔術值在2.6.x之前融入到內核中。 + + Petr Baudis + + 03 Nov 2002 + +更新魔術表到Linux 2.5.74。 + + Fabian Frederick + + 09 Jul 2003 + +===================== ================ ======================== ========================================== +魔術數名 數字 結構 文件 +===================== ================ ======================== ========================================== +PG_MAGIC 'P' pg_{read,write}_hdr ``include/linux/pg.h`` +CMAGIC 0x0111 user ``include/linux/a.out.h`` +MKISS_DRIVER_MAGIC 0x04bf mkiss_channel ``drivers/net/mkiss.h`` +HDLC_MAGIC 0x239e n_hdlc ``drivers/char/n_hdlc.c`` +APM_BIOS_MAGIC 0x4101 apm_user ``arch/x86/kernel/apm_32.c`` +DB_MAGIC 0x4442 fc_info ``drivers/net/iph5526_novram.c`` +DL_MAGIC 0x444d fc_info ``drivers/net/iph5526_novram.c`` +FASYNC_MAGIC 0x4601 fasync_struct ``include/linux/fs.h`` +FF_MAGIC 0x4646 fc_info ``drivers/net/iph5526_novram.c`` +PTY_MAGIC 0x5001 ``drivers/char/pty.c`` +PPP_MAGIC 0x5002 ppp ``include/linux/if_pppvar.h`` +SSTATE_MAGIC 0x5302 serial_state ``include/linux/serial.h`` +SLIP_MAGIC 0x5302 slip ``drivers/net/slip.h`` +STRIP_MAGIC 0x5303 strip ``drivers/net/strip.c`` +SIXPACK_MAGIC 0x5304 sixpack ``drivers/net/hamradio/6pack.h`` +AX25_MAGIC 0x5316 ax_disp ``drivers/net/mkiss.h`` +TTY_MAGIC 0x5401 tty_struct ``include/linux/tty.h`` +MGSL_MAGIC 0x5401 mgsl_info ``drivers/char/synclink.c`` +TTY_DRIVER_MAGIC 0x5402 tty_driver ``include/linux/tty_driver.h`` +MGSLPC_MAGIC 0x5402 mgslpc_info ``drivers/char/pcmcia/synclink_cs.c`` +USB_SERIAL_MAGIC 0x6702 usb_serial ``drivers/usb/serial/usb-serial.h`` +FULL_DUPLEX_MAGIC 0x6969 ``drivers/net/ethernet/dec/tulip/de2104x.c`` +USB_BLUETOOTH_MAGIC 0x6d02 usb_bluetooth ``drivers/usb/class/bluetty.c`` +RFCOMM_TTY_MAGIC 0x6d02 ``net/bluetooth/rfcomm/tty.c`` +USB_SERIAL_PORT_MAGIC 0x7301 usb_serial_port ``drivers/usb/serial/usb-serial.h`` +CG_MAGIC 0x00090255 ufs_cylinder_group ``include/linux/ufs_fs.h`` +LSEMAGIC 0x05091998 lse ``drivers/fc4/fc.c`` +GDTIOCTL_MAGIC 0x06030f07 gdth_iowr_str ``drivers/scsi/gdth_ioctl.h`` +RIEBL_MAGIC 0x09051990 ``drivers/net/atarilance.c`` +NBD_REQUEST_MAGIC 0x12560953 nbd_request ``include/linux/nbd.h`` +RED_MAGIC2 0x170fc2a5 (any) ``mm/slab.c`` +BAYCOM_MAGIC 0x19730510 baycom_state ``drivers/net/baycom_epp.c`` +ISDN_X25IFACE_MAGIC 0x1e75a2b9 isdn_x25iface_proto_data ``drivers/isdn/isdn_x25iface.h`` +ECP_MAGIC 0x21504345 cdkecpsig ``include/linux/cdk.h`` +LSOMAGIC 0x27091997 lso ``drivers/fc4/fc.c`` +LSMAGIC 0x2a3b4d2a ls ``drivers/fc4/fc.c`` +WANPIPE_MAGIC 0x414C4453 sdla_{dump,exec} ``include/linux/wanpipe.h`` +CS_CARD_MAGIC 0x43525553 cs_card ``sound/oss/cs46xx.c`` +LABELCL_MAGIC 0x4857434c labelcl_info_s ``include/asm/ia64/sn/labelcl.h`` +ISDN_ASYNC_MAGIC 0x49344C01 modem_info ``include/linux/isdn.h`` +CTC_ASYNC_MAGIC 0x49344C01 ctc_tty_info ``drivers/s390/net/ctctty.c`` +ISDN_NET_MAGIC 0x49344C02 isdn_net_local_s ``drivers/isdn/i4l/isdn_net_lib.h`` +SAVEKMSG_MAGIC2 0x4B4D5347 savekmsg ``arch/*/amiga/config.c`` +CS_STATE_MAGIC 0x4c4f4749 cs_state ``sound/oss/cs46xx.c`` +SLAB_C_MAGIC 0x4f17a36d kmem_cache ``mm/slab.c`` +COW_MAGIC 0x4f4f4f4d cow_header_v1 ``arch/um/drivers/ubd_user.c`` +I810_CARD_MAGIC 0x5072696E i810_card ``sound/oss/i810_audio.c`` +TRIDENT_CARD_MAGIC 0x5072696E trident_card ``sound/oss/trident.c`` +ROUTER_MAGIC 0x524d4157 wan_device [in ``wanrouter.h`` pre 3.9] +SAVEKMSG_MAGIC1 0x53415645 savekmsg ``arch/*/amiga/config.c`` +GDA_MAGIC 0x58464552 gda ``arch/mips/include/asm/sn/gda.h`` +RED_MAGIC1 0x5a2cf071 (any) ``mm/slab.c`` +EEPROM_MAGIC_VALUE 0x5ab478d2 lanai_dev ``drivers/atm/lanai.c`` +HDLCDRV_MAGIC 0x5ac6e778 hdlcdrv_state ``include/linux/hdlcdrv.h`` +PCXX_MAGIC 0x5c6df104 channel ``drivers/char/pcxx.h`` +KV_MAGIC 0x5f4b565f kernel_vars_s ``arch/mips/include/asm/sn/klkernvars.h`` +I810_STATE_MAGIC 0x63657373 i810_state ``sound/oss/i810_audio.c`` +TRIDENT_STATE_MAGIC 0x63657373 trient_state ``sound/oss/trident.c`` +M3_CARD_MAGIC 0x646e6f50 m3_card ``sound/oss/maestro3.c`` +FW_HEADER_MAGIC 0x65726F66 fw_header ``drivers/atm/fore200e.h`` +SLOT_MAGIC 0x67267321 slot ``drivers/hotplug/cpqphp.h`` +SLOT_MAGIC 0x67267322 slot ``drivers/hotplug/acpiphp.h`` +LO_MAGIC 0x68797548 nbd_device ``include/linux/nbd.h`` +M3_STATE_MAGIC 0x734d724d m3_state ``sound/oss/maestro3.c`` +VMALLOC_MAGIC 0x87654320 snd_alloc_track ``sound/core/memory.c`` +KMALLOC_MAGIC 0x87654321 snd_alloc_track ``sound/core/memory.c`` +PWC_MAGIC 0x89DC10AB pwc_device ``drivers/usb/media/pwc.h`` +NBD_REPLY_MAGIC 0x96744668 nbd_reply ``include/linux/nbd.h`` +ENI155_MAGIC 0xa54b872d midway_eprom ``drivers/atm/eni.h`` +CODA_MAGIC 0xC0DAC0DA coda_file_info ``fs/coda/coda_fs_i.h`` +DPMEM_MAGIC 0xc0ffee11 gdt_pci_sram ``drivers/scsi/gdth.h`` +YAM_MAGIC 0xF10A7654 yam_port ``drivers/net/hamradio/yam.c`` +CCB_MAGIC 0xf2691ad2 ccb ``drivers/scsi/ncr53c8xx.c`` +QUEUE_MAGIC_FREE 0xf7e1c9a3 queue_entry ``drivers/scsi/arm/queue.c`` +QUEUE_MAGIC_USED 0xf7e1cc33 queue_entry ``drivers/scsi/arm/queue.c`` +HTB_CMAGIC 0xFEFAFEF1 htb_class ``net/sched/sch_htb.c`` +NMI_MAGIC 0x48414d4d455201 nmi_s ``arch/mips/include/asm/sn/nmi.h`` +===================== ================ ======================== ========================================== + + +請注意，在聲音記憶管理中仍然有一些特殊的爲每個驅動定義的魔術值。查看include/sound/sndmagic.h來獲取他們完整的列表信息。很多OSS聲音驅動擁有自己從音效卡PCI ID構建的魔術值-他們也沒有被列在這裡。 + +IrDA子系統也使用了大量的自己的魔術值，查看include/net/irda/irda.h來獲取他們完整的信息。 + +HFS是另外一個比較大的使用魔術值的文件系統-你可以在fs/hfs/hfs.h中找到他們。 + diff --git a/Documentation/translations/zh_TW/process/management-style.rst b/Documentation/translations/zh_TW/process/management-style.rst new file mode 100644 index 000000000000..dce248470063 --- /dev/null +++ b/Documentation/translations/zh_TW/process/management-style.rst @@ -0,0 +1,211 @@ +.. SPDX-License-Identifier: GPL-2.0 + +.. include:: ../disclaimer-zh_TW.rst + +:Original: :ref:`Documentation/process/management-style.rst ` +:Translator: Alex Shi + Hu Haowen + +.. _tw_managementstyle: + +Linux內核管理風格 +================= + +這是一個簡短的文檔，描述了Linux內核首選的（或胡編的，取決於您問誰）管理風格。 +它的目的是在某種程度上參照 :ref:`process/coding-style.rst ` +主要是爲了避免反覆回答 [#cnf1]_ 相同（或類似）的問題。 + +管理風格是非常個人化的，比簡單的編碼風格規則更難以量化，因此本文檔可能與實 +際情況有關，也可能與實際情況無關。起初它是一個玩笑，但這並不意味著它可能不 +是真的。你得自己決定。 + +順便說一句，在談到「核心管理者」時，主要是技術負責人，而不是在公司內部進行傳 +統管理的人。如果你簽署了採購訂單或者對你的團隊的預算有任何了解，你幾乎肯定 +不是一個核心管理者。這些建議可能適用於您，也可能不適用於您。 + +首先，我建議你購買「高效人的七個習慣」，而不是閱讀它。燒了它，這是一個偉大的 +象徵性姿態。 + +.. [#cnf1] 本文件並不是通過回答問題，而是通過讓提問者痛苦地明白，我們不知道 + 答案是什麼。 + +不管怎樣，這裡是： + +.. _tw_decisions: + +1）決策 +------- + +每個人都認爲管理者做決定，而且決策很重要。決定越大越痛苦，管理者就必須越高級。 +這很明顯，但事實並非如此。 + +遊戲的名字是 **避免** 做出決定。尤其是，如果有人告訴你「選擇（a）或（b）， +我們真的需要你來做決定」，你就是陷入麻煩的管理者。你管理的人比你更了解細節， +所以如果他們來找你做技術決策，你完蛋了。你顯然沒有能力爲他們做這個決定。 + +（推論：如果你管理的人不比你更了解細節，你也會被搞砸，儘管原因完全不同。 +也就是說，你的工作是錯的，他們應該管理你的才智） + +所以遊戲的名字是 **避免** 做出決定，至少是那些大而痛苦的決定。做一些小的 +和非結果性的決定是很好的，並且使您看起來好像知道自己在做什麼，所以內核管理者 +需要做的是將那些大的和痛苦的決定變成那些沒有人真正關心的小事情。 + +這有助於認識到一個大的決定和一個小的決定之間的關鍵區別是你是否可以在事後修正 +你的決定。任何決定都可以通過始終確保如果你錯了（而且你一定會錯），你以後總是 +可以通過回溯來彌補損失。突然間，你就要做兩個無關緊要的決定，一個是錯誤的，另 +一個是正確的。 + +人們甚至會認爲這是真正的領導能力（咳，胡說，咳）。 + +因此，避免重大決策的關鍵在於避免做那些無法挽回的事情。不要被引導到一個你無法 +逃離的角落。走投無路的老鼠可能很危險——走投無路的管理者真可憐。 + +事實證明，由於沒有人會愚蠢到讓內核管理者承擔巨大的財政責任，所以通常很容易 +回溯。既然你不可能浪費掉你無法償還的巨額資金，你唯一可以回溯的就是技術決策， +而回溯很容易：只要告訴大家你是個不稱職的傻瓜，說對不起，然後撤銷你去年讓別 +人所做的毫無價值的工作。突然間，你一年前做的決定不在是一個重大的決定，因爲 +它很容易被推翻。 + +事實證明，有些人對接受這種方法有困難，原因有兩個： + + - 承認你是個白癡比看起來更難。我們都喜歡保持形象，在公共場合說你錯了有時 + 確實很難。 + - 如果有人告訴你，你去年所做的工作終究是不值得的，那麼對那些可憐的低級工 + 程師來說也是很困難的，雖然實際的 **工作** 很容易刪除，但你可能已經不可 + 挽回地失去了工程師的信任。記住：「不可撤銷」是我們一開始就試圖避免的， + 而你的決定終究是一個重大的決定。 + +令人欣慰的是，這兩個原因都可以通過預先承認你沒有任何線索，提前告訴人們你的 +決定完全是初步的，而且可能是錯誤的事情來有效地緩解。你應該始終保留改變主意 +的權利，並讓人們 **意識** 到這一點。當你 **還沒有** 做過真正愚蠢的事情的時 +候，承認自己是愚蠢的要容易得多。 + +然後，當它真的被證明是愚蠢的時候，人們就轉動他們的眼珠說「哎呀，下次不要了」。 + +這種對不稱職的先發制人的承認，也可能使真正做這項工作的人也會三思是否值得做。 +畢竟，如果他們不確定這是否是一個好主意，你肯定不應該通過向他們保證他們所做 +的工作將會進入（內核）鼓勵他們。在他們開始一項巨大的努力之前，至少讓他們三 +思而後行。 + +記住：他們最好比你更了解細節，而且他們通常認爲他們對每件事都有答案。作爲一 +個管理者，你能做的最好的事情不是灌輸自信，而是對他們所做的事情進行健康的批 +判性思考。 + +順便說一句，另一種避免做出決定的方法是看起來很可憐的抱怨 「我們不能兩者兼 +得嗎？」 相信我，它是有效的。如果不清楚哪種方法更好，他們最終會弄清楚的。 +最終的答案可能是兩個團隊都會因爲這種情況而感到沮喪，以至於他們放棄了。 + +這聽起來像是一個失敗，但這通常是一個跡象，表明兩個項目都有問題，而參與其中 +的人不能做決定的原因是他們都是錯誤的。你最終會聞到玫瑰的味道，你避免了另一 +個你本可以搞砸的決定。 + +2）人 +----- + +大多數人都是白癡，做一名管理者意味著你必須處理好這件事，也許更重要的是, +**他們** 必須處理好你。 + +事實證明，雖然很容易糾正技術錯誤，但不容易糾正人格障礙。你只能和他們的和 +你的（人格障礙）共處。 + +但是，爲了做好作爲內核管理者的準備，最好記住不要燒掉任何橋樑，不要轟炸任何 +無辜的村民，也不要疏遠太多的內核開發人員。事實證明，疏遠人是相當容易的，而 +親近一個疏遠的人是很難的。因此，「疏遠」立即屬於「不可逆」的範疇，並根據 +:ref:`tw_decisions` 成爲絕不可以做的事情。 + +這裡只有幾個簡單的規則： + + (1) 不要叫人笨蛋（至少不要在公共場合） + (2) 學習如何在忘記規則(1)時道歉 + +問題在於 #1 很容易去做，因爲你可以用數百萬種不同的方式說「你是一個笨蛋」 [#cnf2]_ +有時甚至沒有意識到，而且幾乎總是帶著一種白熱化的信念，認爲你是對的。 + +你越確信自己是對的（讓我們面對現實吧，你可以把幾乎所有人都稱爲壞人，而且你 +經常是對的），事後道歉就越難。 + +要解決此問題，您實際上只有兩個選項： + + - 非常擅長道歉 + - 把「愛」均勻地散開，沒有人會真正感覺到自己被不公平地瞄準了。讓它有足夠的 + 創造性，他們甚至可能會覺得好笑。 + +選擇永遠保持禮貌是不存在的。沒有人會相信一個如此明顯地隱藏了他們真實性格的人。 + +.. [#cnf2] 保羅·西蒙演唱了「離開愛人的50種方法」，因爲坦率地說，「告訴開發者 + 他們是D*CKHEAD" 的100萬種方法都無法確認。但我確信他已經這麼想了。 + +3）人2 - 好人 +------------- + +雖然大多數人都是白癡，但不幸的是，據此推論你也是白癡，儘管我們都自我感覺良 +好，我們比普通人更好（讓我們面對現實吧，沒有人相信他們是普通人或低於普通人）， +我們也應該承認我們不是最鋒利的刀，而且會有其他人比你更不像白癡。 + +有些人對聰明人反應不好。其他人利用它們。 + +作爲內核維護人員，確保您在第二組中。接受他們，因爲他們會讓你的工作更容易。 +特別是，他們能夠爲你做決定，這就是遊戲的全部內容。 + +所以當你發現一個比你聰明的人時，就順其自然吧。你的管理職責在很大程度上變成 +了「聽起來像是個好主意——去嘗試吧」，或者「聽起來不錯，但是XXX呢？」「。第二個版 +本尤其是一個很好的方法，要麼學習一些關於「XXX」的新東西，要麼通過指出一些聰明 +人沒有想到的東西來顯得更具管理性。無論哪種情況，你都會贏。 + +要注意的一件事是認識到一個領域的偉大不一定會轉化爲其他領域。所以你可能會向 +特定的方向刺激人們，但讓我們面對現實吧，他們可能擅長他們所做的事情，而且對 +其他事情都很差勁。好消息是，人們往往會自然而然地重拾他們擅長的東西，所以當 +你向某個方向刺激他們時，你並不是在做不可逆轉的事情，只是不要用力推。 + +4）責備 +------- + +事情會出問題的，人們希望去責備人。貼標籤，你就是受責備的人。 + +事實上，接受責備並不難，尤其是當人們意識到這不 **全是** 你的過錯時。這讓我 +們找到了承擔責任的最佳方式：爲別人承擔這件事。你會感覺很好，他們會感覺很好， +沒有受到指責. 那誰，失去了他們的全部36GB色情收藏的人，因爲你的無能將勉強承 +認，你至少沒有試圖逃避責任。 + +然後讓真正搞砸了的開發人員（如果你能找到他們）私下知道他們搞砸了。不僅是爲 +了將來可以避免，而且爲了讓他們知道他們欠你一個人情。而且，也許更重要的是， +他們也可能是能夠解決問題的人。因爲，讓我們面對現實吧，肯定不是你。 + +承擔責任也是你首先成爲管理者的原因。這是讓人們信任你，讓你獲得潛在的榮耀的 +一部分，因爲你就是那個會說「我搞砸了」的人。如果你已經遵循了以前的規則，你現 +在已經很擅長說了。 + +5）應避免的事情 +--------------- + +有一件事人們甚至比被稱爲「笨蛋」更討厭，那就是在一個神聖的聲音中被稱爲「笨蛋」。 +第一個你可以道歉，第二個你不會真正得到機會。即使你做得很好，他們也可能不再 +傾聽。 + +我們都認爲自己比別人強，這意味著當別人裝腔作勢時，這會讓我們很惱火。你也許 +在道德和智力上比你周圍的每個人都優越，但不要試圖太明顯，除非你真的打算激怒 +某人 [#cnf3]_ + +同樣，不要對事情太客氣或太微妙。禮貌很容易落得落花流水，把問題隱藏起來， +正如他們所說，「在網際網路上，沒人能聽到你的含蓄。」用一個鈍器把這一點錘進去， +因爲你不能真的依靠別人來獲得你的觀點。 + +一些幽默可以幫助緩和直率和道德化。過度到荒謬的地步，可以灌輸一個觀點，而不 +會讓接受者感到痛苦，他們只是認爲你是愚蠢的。因此，它可以幫助我們擺脫對批評 +的個人心理障礙。 + +.. [#cnf3] 提示：與你的工作沒有直接關係的網絡新聞組是消除你對他人不滿的好 + 方法。偶爾寫些侮辱性的帖子，打個噴嚏，讓你的情緒得到淨化。別把牢騷帶回家 + +6）爲什麼是我？ +--------------- + +既然你的主要責任似乎是爲別人的錯誤承擔責任，並且讓別人痛苦地明白你是不稱職 +的，那麼顯而易見的問題之一就變成了爲什麼首先要這樣做。 + +首先，雖然你可能會或可能不會聽到十幾歲女孩（或男孩，讓我們不要在這裡評判或 +性別歧視）敲你的更衣室門，你會得到一個巨大的個人成就感爲「負責」。別介意你真 +的在領導別人，你要跟上別人，儘可能快地追趕他們。每個人都會認爲你是負責人。 + +如果你可以做到這個， 這是個偉大的工作！ + diff --git a/Documentation/translations/zh_TW/process/programming-language.rst b/Documentation/translations/zh_TW/process/programming-language.rst new file mode 100644 index 000000000000..54e3699eadf8 --- /dev/null +++ b/Documentation/translations/zh_TW/process/programming-language.rst @@ -0,0 +1,76 @@ +.. SPDX-License-Identifier: GPL-2.0 + +.. include:: ../disclaimer-zh_TW.rst + +:Original: :ref:`Documentation/process/programming-language.rst ` +:Translator: Alex Shi + Hu Haowen + +.. _tw_programming_language: + +程序設計語言 +============ + +內核是用C語言 :ref:`c-language ` 編寫的。更準確地說，內核通常是用 :ref:`gcc ` +在 ``-std=gnu89`` :ref:`gcc-c-dialect-options ` 下編譯的：ISO C90的 GNU 方言（ +包括一些C99特性） + +這種方言包含對語言 :ref:`gnu-extensions ` 的許多擴展，當然，它們許多都在內核中使用。 + +對於一些體系結構，有一些使用 :ref:`clang ` 和 :ref:`icc ` 編譯內核 +的支持，儘管在編寫此文檔時還沒有完成，仍需要第三方補丁。 + +屬性 +---- + +在整個內核中使用的一個常見擴展是屬性（attributes） :ref:`gcc-attribute-syntax ` +屬性允許將實現定義的語義引入語言實體（如變量、函數或類型），而無需對語言進行 +重大的語法更改（例如添加新關鍵字） :ref:`n2049 ` + +在某些情況下，屬性是可選的（即不支持這些屬性的編譯器仍然應該生成正確的代碼， +即使其速度較慢或執行的編譯時檢查/診斷次數不夠） + +內核定義了僞關鍵字（例如， ``pure`` ），而不是直接使用GNU屬性語法（例如, +``__attribute__((__pure__))`` ），以檢測可以使用哪些關鍵字和/或縮短代碼, 具體 +請參閱 ``include/linux/compiler_attributes.h`` + +.. _tw_c-language: + +c-language + http://www.open-std.org/jtc1/sc22/wg14/www/standards + +.. _tw_gcc: + +gcc + https://gcc.gnu.org + +.. _tw_clang: + +clang + https://clang.llvm.org + +.. _tw_icc: + +icc + https://software.intel.com/en-us/c-compilers + +.. _tw_gcc-c-dialect-options: + +c-dialect-options + https://gcc.gnu.org/onlinedocs/gcc/C-Dialect-Options.html + +.. _tw_gnu-extensions: + +gnu-extensions + https://gcc.gnu.org/onlinedocs/gcc/C-Extensions.html + +.. _tw_gcc-attribute-syntax: + +gcc-attribute-syntax + https://gcc.gnu.org/onlinedocs/gcc/Attribute-Syntax.html + +.. _tw_n2049: + +n2049 + http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2049.pdf + diff --git a/Documentation/translations/zh_TW/process/stable-api-nonsense.rst b/Documentation/translations/zh_TW/process/stable-api-nonsense.rst new file mode 100644 index 000000000000..22caa5b8d422 --- /dev/null +++ b/Documentation/translations/zh_TW/process/stable-api-nonsense.rst @@ -0,0 +1,159 @@ +.. SPDX-License-Identifier: GPL-2.0 + +.. _tw_stable_api_nonsense: + +.. include:: ../disclaimer-zh_TW.rst + +:Original: :ref:`Documentation/process/stable-api-nonsense.rst + ` + +譯者:: + + 中文版維護者： 鍾宇 TripleX Chung + 中文版翻譯者： 鍾宇 TripleX Chung + 中文版校譯者： 李陽 Li Yang + 胡皓文 Hu Haowen + +Linux 內核驅動接口 +================== + +寫作本文檔的目的，是爲了解釋爲什麼Linux既沒有二進位內核接口，也沒有穩定 +的內核接口。這裡所說的內核接口，是指內核里的接口，而不是內核和用戶空間 +的接口。內核到用戶空間的接口，是提供給應用程式使用的系統調用，系統調用 +在歷史上幾乎沒有過變化，將來也不會有變化。我有一些老應用程式是在0.9版本 +或者更早版本的內核上編譯的，在使用2.6版本內核的Linux發布上依然用得很好 +。用戶和應用程式作者可以將這個接口看成是穩定的。 + + +執行綱要 +-------- + +你也許以爲自己想要穩定的內核接口，但是你不清楚你要的實際上不是它。你需 +要的其實是穩定的驅動程序，而你只有將驅動程序放到公版內核的原始碼樹里， +才有可能達到這個目的。而且這樣做還有很多其它好處，正是因爲這些好處使得 +Linux能成爲強壯，穩定，成熟的作業系統，這也是你最開始選擇Linux的原因。 + + +入門 +----- + +只有那些寫驅動程序的「怪人」才會擔心內核接口的改變，對廣大用戶來說，既 +看不到內核接口，也不需要去關心它。 + +首先，我不打算討論關於任何非GPL許可的內核驅動的法律問題，這些非GPL許可 +的驅動程序包括不公開原始碼，隱藏原始碼，二進位或者是用原始碼包裝，或者 +是其它任何形式的不能以GPL許可公開原始碼的驅動程序。如果有法律問題，請咨 +詢律師，我只是一個程式設計師，所以我只打算探討技術問題（不是小看法律問題， +法律問題很實際，並且需要一直關注）。 + +既然只談技術問題，我們就有了下面兩個主題：二進位內核接口和穩定的內核源 +代碼接口。這兩個問題是互相關聯的，讓我們先解決掉二進位接口的問題。 + + +二進位內核接口 +-------------- +假如我們有一個穩定的內核原始碼接口，那麼自然而然的，我們就擁有了穩定的 +二進位接口，是這樣的嗎？錯。讓我們看看關於Linux內核的幾點事實： + + - 取決於所用的C編譯器的版本，不同的內核數據結構里的結構體的對齊方 + 式會有差別，代碼中不同函數的表現形式也不一樣（函數是不是被inline + 編譯取決於編譯器行爲）。不同的函數的表現形式並不重要，但是數據 + 結構內部的對齊方式很關鍵。 + + - 取決於內核的配置選項，不同的選項會讓內核的很多東西發生改變： + + - 同一個結構體可能包含不同的成員變量 + - 有的函數可能根本不會被實現（比如編譯的時候沒有選擇SMP支持 + 一些鎖函數就會被定義成空函數）。 + - 內核使用的內存會以不同的方式對齊，這取決於不同的內核配置選 + 項。 + + - Linux可以在很多的不同體系結構的處理器上運行。在某個體系結構上編 + 譯好的二進位驅動程序，不可能在另外一個體系結構上正確的運行。 + +對於一個特定的內核，滿足這些條件並不難，使用同一個C編譯器和同樣的內核配 +置選項來編譯驅動程序模塊就可以了。這對於給一個特定Linux發布的特定版本提 +供驅動程序，是完全可以滿足需求的。但是如果你要給不同發布的不同版本都發 +布一個驅動程序，就需要在每個發布上用不同的內核設置參數都編譯一次內核， +這簡直跟噩夢一樣。而且還要注意到，每個Linux發布還提供不同的Linux內核， +這些內核都針對不同的硬體類型進行了優化（有很多種不同的處理器，還有不同 +的內核設置選項）。所以每發布一次驅動程序，都需要提供很多不同版本的內核 +模塊。 + +相信我，如果你真的要採取這種發布方式，一定會慢慢瘋掉，我很久以前就有過 +深刻的教訓... + + +穩定的內核原始碼接口 +-------------------- + +如果有人不將他的內核驅動程序，放入公版內核的原始碼樹，而又想讓驅動程序 +一直保持在最新的內核中可用，那麼這個話題將會變得沒完沒了。 +內核開發是持續而且快節奏的，從來都不會慢下來。內核開發人員在當前接口中 +找到bug，或者找到更好的實現方式。一旦發現這些，他們就很快會去修改當前的 +接口。修改接口意味著，函數名可能會改變，結構體可能被擴充或者刪減，函數 +的參數也可能發生改變。一旦接口被修改，內核中使用這些接口的地方需要同時 +修正，這樣才能保證所有的東西繼續工作。 + +舉一個例子，內核的USB驅動程序接口在USB子系統的整個生命周期中，至少經歷 +了三次重寫。這些重寫解決以下問題： + + - 把數據流從同步模式改成非同步模式，這個改動減少了一些驅動程序的 + 複雜度，提高了所有USB驅動程序的吞吐率，這樣幾乎所有的USB設備都 + 能以最大速率工作了。 + - 修改了USB核心代碼中爲USB驅動分配數據包內存的方式，所有的驅動都 + 需要提供更多的參數給USB核心，以修正了很多已經被記錄在案的死鎖。 + +這和一些封閉原始碼的作業系統形成鮮明的對比，在那些作業系統上，不得不額 +外的維護舊的USB接口。這導致了一個可能性，新的開發者依然會不小心使用舊的 +接口，以不恰當的方式編寫代碼，進而影響到作業系統的穩定性。 +在上面的例子中，所有的開發者都同意這些重要的改動，在這樣的情況下修改代 +價很低。如果Linux保持一個穩定的內核原始碼接口，那麼就得創建一個新的接口 +；舊的，有問題的接口必須一直維護，給Linux USB開發者帶來額外的工作。既然 +所有的Linux USB驅動的作者都是利用自己的時間工作，那麼要求他們去做毫無意 +義的免費額外工作，是不可能的。 +安全問題對Linux來說十分重要。一個安全問題被發現，就會在短時間內得到修 +正。在很多情況下，這將導致Linux內核中的一些接口被重寫，以從根本上避免安 +全問題。一旦接口被重寫，所有使用這些接口的驅動程序，必須同時得到修正， +以確定安全問題已經得到修復並且不可能在未來還有同樣的安全問題。如果內核 +內部接口不允許改變，那麼就不可能修復這樣的安全問題，也不可能確認這樣的 +安全問題以後不會發生。 +開發者一直在清理內核接口。如果一個接口沒有人在使用了，它就會被刪除。這 +樣可以確保內核儘可能的小，而且所有潛在的接口都會得到儘可能完整的測試 +（沒有人使用的接口是不可能得到良好的測試的）。 + + +要做什麼 +-------- + +如果你寫了一個Linux內核驅動，但是它還不在Linux原始碼樹里，作爲一個開發 +者，你應該怎麼做？爲每個發布的每個版本提供一個二進位驅動，那簡直是一個 +噩夢，要跟上永遠處於變化之中的內核接口，也是一件辛苦活。 +很簡單，讓你的驅動進入內核原始碼樹（要記得我們在談論的是以GPL許可發行 +的驅動，如果你的代碼不符合GPL，那麼祝你好運，你只能自己解決這個問題了， +你這個吸血鬼<把Andrew和Linus對吸血鬼的定義連結到這裡>）。當你的代碼加入 +公版內核原始碼樹之後，如果一個內核接口改變，你的驅動會直接被修改接口的 +那個人修改。保證你的驅動永遠都可以編譯通過，並且一直工作，你幾乎不需要 +做什麼事情。 + +把驅動放到內核原始碼樹里會有很多的好處： + + - 驅動的質量會提升，而維護成本（對原始作者來說）會下降。 + - 其他人會給驅動添加新特性。 + - 其他人會找到驅動中的bug並修復。 + - 其他人會在驅動中找到性能優化的機會。 + - 當外部的接口的改變需要修改驅動程序的時候，其他人會修改驅動程序 + - 不需要聯繫任何發行商，這個驅動會自動的隨著所有的Linux發布一起發 + 布。 + +和別的作業系統相比，Linux爲更多不同的設備提供現成的驅動，而且能在更多不 +同體系結構的處理器上支持這些設備。這個經過考驗的開發模式，必然是錯不了 +的 :) + +感謝 +---- +感謝 Randy Dunlap, Andrew Morton, David Brownell, Hanna Linder, +Robert Love, and Nishanth Aravamudan 對於本文檔早期版本的評審和建議。 + +英文版維護者： Greg Kroah-Hartman + diff --git a/Documentation/translations/zh_TW/process/stable-kernel-rules.rst b/Documentation/translations/zh_TW/process/stable-kernel-rules.rst new file mode 100644 index 000000000000..9bb0d9b4f3ac --- /dev/null +++ b/Documentation/translations/zh_TW/process/stable-kernel-rules.rst @@ -0,0 +1,68 @@ +.. SPDX-License-Identifier: GPL-2.0 + +.. _tw_stable_kernel_rules: + +.. include:: ../disclaimer-zh_TW.rst + +:Original: :ref:`Documentation/process/stable-kernel-rules.rst ` + +如果想評論或更新本文的內容，請直接聯繫原文檔的維護者。如果你使用英文 +交流有困難的話，也可以向中文版維護者求助。如果本翻譯更新不及時或者翻 +譯存在問題，請聯繫中文版維護者:: + + 中文版維護者： 鍾宇 TripleX Chung + 中文版翻譯者： 鍾宇 TripleX Chung + 中文版校譯者： + - 李陽 Li Yang + - Kangkai Yin + - 胡皓文 Hu Haowen + +所有你想知道的事情 - 關於linux穩定版發布 +======================================== + +關於Linux 2.6穩定版發布，所有你想知道的事情。 + +關於哪些類型的補丁可以被接收進入穩定版代碼樹，哪些不可以的規則： +---------------------------------------------------------------- + + - 必須是顯而易見的正確，並且經過測試的。 + - 連同上下文，不能大於100行。 + - 必須只修正一件事情。 + - 必須修正了一個給大家帶來麻煩的真正的bug（不是「這也許是一個問題...」 + 那樣的東西）。 + - 必須修正帶來如下後果的問題：編譯錯誤（對被標記爲CONFIG_BROKEN的例外）， + 內核崩潰，掛起，數據損壞，真正的安全問題，或者一些類似「哦，這不 + 好」的問題。簡短的說，就是一些致命的問題。 + - 沒有「理論上的競爭條件」，除非能給出競爭條件如何被利用的解釋。 + - 不能存在任何的「瑣碎的」修正（拼寫修正，去掉多餘空格之類的）。 + - 必須被相關子系統的維護者接受。 + - 必須遵循Documentation/translations/zh_TW/process/submitting-patches.rst里的規則。 + +向穩定版代碼樹提交補丁的過程： +------------------------------ + + - 在確認了補丁符合以上的規則後，將補丁發送到stable@vger.kernel.org。 + - 如果補丁被接受到隊列里，發送者會收到一個ACK回復，如果沒有被接受，收 + 到的是NAK回復。回復需要幾天的時間，這取決於開發者的時間安排。 + - 被接受的補丁會被加到穩定版本隊列里，等待其他開發者的審查。 + - 安全方面的補丁不要發到這個列表，應該發送到security@kernel.org。 + +審查周期： +---------- + + - 當穩定版的維護者決定開始一個審查周期，補丁將被發送到審查委員會，以 + 及被補丁影響的領域的維護者（除非提交者就是該領域的維護者）並且抄送 + 到linux-kernel郵件列表。 + - 審查委員會有48小時的時間，用來決定給該補丁回復ACK還是NAK。 + - 如果委員會中有成員拒絕這個補丁，或者linux-kernel列表上有人反對這個 + 補丁，並提出維護者和審查委員會之前沒有意識到的問題，補丁會從隊列中 + 丟棄。 + - 在審查周期結束的時候，那些得到ACK回應的補丁將會被加入到最新的穩定版 + 發布中，一個新的穩定版發布就此產生。 + - 安全性補丁將從內核安全小組那裡直接接收到穩定版代碼樹中，而不是通過 + 通常的審查周期。請聯繫內核安全小組以獲得關於這個過程的更多細節。 + +審查委員會： +------------ + - 由一些自願承擔這項任務的內核開發者，和幾個非志願的組成。 + diff --git a/Documentation/translations/zh_TW/process/submit-checklist.rst b/Documentation/translations/zh_TW/process/submit-checklist.rst new file mode 100644 index 000000000000..ff2f89cba83f --- /dev/null +++ b/Documentation/translations/zh_TW/process/submit-checklist.rst @@ -0,0 +1,109 @@ +.. SPDX-License-Identifier: GPL-2.0 + +.. include:: ../disclaimer-zh_TW.rst + +:Original: :ref:`Documentation/process/submit-checklist.rst ` +:Translator: Alex Shi + Hu Haowen + +.. _tw_submitchecklist: + +Linux內核補丁提交清單 +~~~~~~~~~~~~~~~~~~~~~ + +如果開發人員希望看到他們的內核補丁提交更快地被接受，那麼他們應該做一些基本 +的事情。 + +這些都是在 +:ref:`Documentation/translations/zh_TW/process/submitting-patches.rst ` +和其他有關提交Linux內核補丁的文檔中提供的。 + +1) 如果使用工具，則包括定義/聲明該工具的文件。不要依賴於其他頭文件拉入您使用 + 的頭文件。 + +2) 乾淨的編譯： + + a) 使用適用或修改的 ``CONFIG`` 選項 ``=y``、``=m`` 和 ``=n`` 。沒有GCC + 警告/錯誤，沒有連結器警告/錯誤。 + + b) 通過allnoconfig、allmodconfig + + c) 使用 ``O=builddir`` 時可以成功編譯 + +3) 通過使用本地交叉編譯工具或其他一些構建場在多個CPU體系結構上構建。 + +4) PPC64是一種很好的交叉編譯檢查體系結構，因爲它傾向於對64位的數使用無符號 + 長整型。 + +5) 如下所述 :ref:`Documentation/translations/zh_TW/process/coding-style.rst `. + 檢查您的補丁是否爲常規樣式。在提交（ ``scripts/check patch.pl`` ）之前， + 使用補丁樣式檢查器檢查是否有輕微的衝突。您應該能夠處理您的補丁中存在的所有 + 違規行爲。 + +6) 任何新的或修改過的 ``CONFIG`` 選項都不會弄髒配置菜單，並默認爲關閉，除非 + 它們符合 ``Documentation/kbuild/kconfig-language.rst`` 中記錄的異常條件, + 菜單屬性：默認值. + +7) 所有新的 ``kconfig`` 選項都有幫助文本。 + +8) 已仔細審查了相關的 ``Kconfig`` 組合。這很難用測試來糾正——腦力在這裡是有 + 回報的。 + +9) 用 sparse 檢查乾淨。 + +10) 使用 ``make checkstack`` 和 ``make namespacecheck`` 並修復他們發現的任何 + 問題。 + + .. note:: + + ``checkstack`` 並沒有明確指出問題，但是任何一個在堆棧上使用超過512 + 字節的函數都可以進行更改。 + +11) 包括 :ref:`kernel-doc ` 內核文檔以記錄全局內核API。（靜態函數 + 不需要，但也可以。）使用 ``make htmldocs`` 或 ``make pdfdocs`` 檢查 + :ref:`kernel-doc ` 並修復任何問題。 + +12) 通過以下選項同時啓用的測試 ``CONFIG_PREEMPT``, ``CONFIG_DEBUG_PREEMPT``, + ``CONFIG_DEBUG_SLAB``, ``CONFIG_DEBUG_PAGEALLOC``, ``CONFIG_DEBUG_MUTEXES``, + ``CONFIG_DEBUG_SPINLOCK``, ``CONFIG_DEBUG_ATOMIC_SLEEP``, + ``CONFIG_PROVE_RCU`` and ``CONFIG_DEBUG_OBJECTS_RCU_HEAD`` + +13) 已經過構建和運行時測試，包括有或沒有 ``CONFIG_SMP``, ``CONFIG_PREEMPT``. + +14) 如果補丁程序影響IO/磁碟等：使用或不使用 ``CONFIG_LBDAF`` 進行測試。 + +15) 所有代碼路徑都已在啓用所有lockdep功能的情況下運行。 + +16) 所有新的/proc條目都記錄在 ``Documentation/`` + +17) 所有新的內核引導參數都記錄在 + Documentation/admin-guide/kernel-parameters.rst 中。 + +18) 所有新的模塊參數都記錄在 ``MODULE_PARM_DESC()`` + +19) 所有新的用戶空間接口都記錄在 ``Documentation/ABI/`` 中。有關詳細信息， + 請參閱 ``Documentation/ABI/README`` 。更改用戶空間接口的補丁應該抄送 + linux-api@vger.kernel.org。 + +20) 已通過至少注入slab和page分配失敗進行檢查。請參閱 ``Documentation/fault-injection/`` + 如果新代碼是實質性的，那麼添加子系統特定的故障注入可能是合適的。 + +21) 新添加的代碼已經用 ``gcc -W`` 編譯（使用 ``make EXTRA-CFLAGS=-W`` ）。這 + 將產生大量噪聲，但對於查找諸如「警告：有符號和無符號之間的比較」之類的錯誤 + 很有用。 + +22) 在它被合併到-mm補丁集中之後進行測試，以確保它仍然與所有其他排隊的補丁以 + 及VM、VFS和其他子系統中的各種更改一起工作。 + +23) 所有內存屏障例如 ``barrier()``, ``rmb()``, ``wmb()`` 都需要原始碼中的注 + 釋來解釋它們正在執行的操作及其原因的邏輯。 + +24) 如果補丁添加了任何ioctl，那麼也要更新 ``Documentation/userspace-api/ioctl/ioctl-number.rst`` + +25) 如果修改後的原始碼依賴或使用與以下 ``Kconfig`` 符號相關的任何內核API或 + 功能，則在禁用相關 ``Kconfig`` 符號和/或 ``=m`` （如果該選項可用）的情況 + 下測試以下多個構建[並非所有這些都同時存在，只是它們的各種/隨機組合]： + + ``CONFIG_SMP``, ``CONFIG_SYSFS``, ``CONFIG_PROC_FS``, ``CONFIG_INPUT``, ``CONFIG_PCI``, ``CONFIG_BLOCK``, ``CONFIG_PM``, ``CONFIG_MAGIC_SYSRQ``, + ``CONFIG_NET``, ``CONFIG_INET=n`` (但是後者伴隨 ``CONFIG_NET=y``). + diff --git a/Documentation/translations/zh_TW/process/submitting-drivers.rst b/Documentation/translations/zh_TW/process/submitting-drivers.rst new file mode 100644 index 000000000000..2fdd742318ba --- /dev/null +++ b/Documentation/translations/zh_TW/process/submitting-drivers.rst @@ -0,0 +1,164 @@ +.. SPDX-License-Identifier: GPL-2.0 + +.. _tw_submittingdrivers: + +.. include:: ../disclaimer-zh_TW.rst + +:Original: :ref:`Documentation/process/submitting-drivers.rst + ` + +如果想評論或更新本文的內容，請直接聯繫原文檔的維護者。如果你使用英文 +交流有困難的話，也可以向中文版維護者求助。如果本翻譯更新不及時或者翻 +譯存在問題，請聯繫中文版維護者:: + + 中文版維護者： 李陽 Li Yang + 中文版翻譯者： 李陽 Li Yang + 中文版校譯者： 陳琦 Maggie Chen + 王聰 Wang Cong + 張巍 Zhang Wei + 胡皓文 Hu Haowen + +如何向 Linux 內核提交驅動程序 +============================= + +這篇文檔將會解釋如何向不同的內核源碼樹提交設備驅動程序。請注意，如果你感 +興趣的是顯卡驅動程序，你也許應該訪問 XFree86 項目(https://www.xfree86.org/) +和／或 X.org 項目 (https://x.org)。 + +另請參閱 Documentation/translations/zh_TW/process/submitting-patches.rst 文檔。 + + +分配設備號 +---------- + +塊設備和字符設備的主設備號與從設備號是由 Linux 命名編號分配權威 LANANA（ +現在是 Torben Mathiasen）負責分配。申請的網址是 https://www.lanana.org/。 +即使不準備提交到主流內核的設備驅動也需要在這裡分配設備號。有關詳細信息， +請參閱 Documentation/admin-guide/devices.rst。 + +如果你使用的不是已經分配的設備號，那麼當你提交設備驅動的時候，它將會被強 +制分配一個新的設備號，即便這個設備號和你之前發給客戶的截然不同。 + +設備驅動的提交對象 +------------------ + +Linux 2.0: + 此內核源碼樹不接受新的驅動程序。 + +Linux 2.2: + 此內核源碼樹不接受新的驅動程序。 + +Linux 2.4: + 如果所屬的代碼領域在內核的 MAINTAINERS 文件中列有一個總維護者， + 那麼請將驅動程序提交給他。如果此維護者沒有回應或者你找不到恰當的 + 維護者，那麼請聯繫 Willy Tarreau 。 + +Linux 2.6: + 除了遵循和 2.4 版內核同樣的規則外，你還需要在 linux-kernel 郵件 + 列表上跟蹤最新的 API 變化。向 Linux 2.6 內核提交驅動的頂級聯繫人 + 是 Andrew Morton 。 + +決定設備驅動能否被接受的條件 +---------------------------- + +許可： 代碼必須使用 GNU 通用公開許可證 (GPL) 提交給 Linux，但是 + 我們並不要求 GPL 是唯一的許可。你或許會希望同時使用多種 + 許可證發布，如果希望驅動程序可以被其他開源社區（比如BSD） + 使用。請參考 include/linux/module.h 文件中所列出的可被 + 接受共存的許可。 + +版權： 版權所有者必須同意使用 GPL 許可。最好提交者和版權所有者 + 是相同個人或實體。否則，必需列出授權使用 GPL 的版權所有 + 人或實體，以備驗證之需。 + +接口： 如果你的驅動程序使用現成的接口並且和其他同類的驅動程序行 + 爲相似，而不是去發明無謂的新接口，那麼它將會更容易被接受。 + 如果你需要一個 Linux 和 NT 的通用驅動接口，那麼請在用 + 戶空間實現它。 + +代碼： 請使用 Documentation/process/coding-style.rst 中所描述的 Linux 代碼風 + 格。如果你的某些代碼段（例如那些與 Windows 驅動程序包共 + 享的代碼段）需要使用其他格式，而你卻只希望維護一份代碼， + 那麼請將它們很好地區分出來，並且註明原因。 + +可移植性： 請注意，指針並不永遠是 32 位的，不是所有的計算機都使用小 + 尾模式 (little endian) 存儲數據，不是所有的人都擁有浮點 + 單元，不要隨便在你的驅動程序里嵌入 x86 彙編指令。只能在 + x86 上運行的驅動程序一般是不受歡迎的。雖然你可能只有 x86 + 硬體，很難測試驅動程序在其他平台上是否可用，但是確保代碼 + 可以被輕鬆地移植卻是很簡單的。 + +清晰度： 做到所有人都能修補這個驅動程序將會很有好處，因爲這樣你將 + 會直接收到修復的補丁而不是 bug 報告。如果你提交一個試圖 + 隱藏硬體工作機理的驅動程序，那麼它將會被扔進廢紙簍。 + +電源管理： 因爲 Linux 正在被很多行動裝置和桌面系統使用，所以你的驅 + 動程序也很有可能被使用在這些設備上。它應該支持最基本的電 + 源管理，即在需要的情況下實現系統級休眠和喚醒要用到的 + .suspend 和 .resume 函數。你應該檢查你的驅動程序是否能正 + 確地處理休眠與喚醒，如果實在無法確認，請至少把 .suspend + 函數定義成返回 -ENOSYS（功能未實現）錯誤。你還應該嘗試確 + 保你的驅動在什麼都不乾的情況下將耗電降到最低。要獲得驅動 + 程序測試的指導，請參閱 + Documentation/power/drivers-testing.rst。有關驅動程序電 + 源管理問題相對全面的概述，請參閱 + Documentation/driver-api/pm/devices.rst。 + +管理： 如果一個驅動程序的作者還在進行有效的維護，那麼通常除了那 + 些明顯正確且不需要任何檢查的補丁以外，其他所有的補丁都會 + 被轉發給作者。如果你希望成爲驅動程序的聯繫人和更新者，最 + 好在代碼注釋中寫明並且在 MAINTAINERS 文件中加入這個驅動 + 程序的條目。 + +不影響設備驅動能否被接受的條件 +------------------------------ + +供應商： 由硬體供應商來維護驅動程序通常是一件好事。不過，如果源碼 + 樹里已經有其他人提供了可穩定工作的驅動程序，那麼請不要期 + 望「我是供應商」會成爲內核改用你的驅動程序的理由。理想的情 + 況是：供應商與現有驅動程序的作者合作，構建一個統一完美的 + 驅動程序。 + +作者： 驅動程序是由大的 Linux 公司研發還是由你個人編寫，並不影 + 響其是否能被內核接受。沒有人對內核源碼樹享有特權。只要你 + 充分了解內核社區，你就會發現這一點。 + + +資源列表 +-------- + +Linux 內核主源碼樹： + ftp.??.kernel.org:/pub/linux/kernel/... + ?? == 你的國家代碼，例如 "cn"、"us"、"uk"、"fr" 等等 + +Linux 內核郵件列表： + linux-kernel@vger.kernel.org + [可通過向majordomo@vger.kernel.org發郵件來訂閱] + +Linux 設備驅動程序，第三版（探討 2.6.10 版內核）： + https://lwn.net/Kernel/LDD3/ （免費版） + +LWN.net: + 每周內核開發活動摘要 - https://lwn.net/ + + 2.6 版中 API 的變更： + + https://lwn.net/Articles/2.6-kernel-api/ + + 將舊版內核的驅動程序移植到 2.6 版： + + https://lwn.net/Articles/driver-porting/ + +內核新手(KernelNewbies): + 爲新的內核開發者提供文檔和幫助 + https://kernelnewbies.org/ + +Linux USB項目： + http://www.linux-usb.org/ + +寫內核驅動的「不要」（Arjan van de Ven著）: + http://www.fenrus.org/how-to-not-write-a-device-driver-paper.pdf + +內核清潔工 (Kernel Janitor): + https://kernelnewbies.org/KernelJanitors + diff --git a/Documentation/translations/zh_TW/process/submitting-patches.rst b/Documentation/translations/zh_TW/process/submitting-patches.rst new file mode 100644 index 000000000000..cdf0b52e4a98 --- /dev/null +++ b/Documentation/translations/zh_TW/process/submitting-patches.rst @@ -0,0 +1,686 @@ +.. SPDX-License-Identifier: GPL-2.0 + +.. _tw_submittingpatches: + +.. include:: ../disclaimer-zh_TW.rst + +:Original: :ref:`Documentation/process/submitting-patches.rst ` + +譯者:: + + 中文版維護者： 鍾宇 TripleX Chung + 中文版翻譯者： 鍾宇 TripleX Chung + 時奎亮 Alex Shi + 中文版校譯者： 李陽 Li Yang + 王聰 Wang Cong + 胡皓文 Hu Haowen + + +如何讓你的改動進入內核 +====================== + +對於想要將改動提交到 Linux 內核的個人或者公司來說，如果不熟悉「規矩」， +提交的流程會讓人畏懼。本文檔收集了一系列建議，這些建議可以大大的提高你 +的改動被接受的機會. + +以下文檔含有大量簡潔的建議， 具體請見： +:ref:`Documentation/process ` +同樣，:ref:`Documentation/translations/zh_TW/process/submit-checklist.rst ` +給出在提交代碼前需要檢查的項目的列表。如果你在提交一個驅動程序，那麼 +同時閱讀一下: +:ref:`Documentation/process/submitting-drivers.rst ` + +其中許多步驟描述了Git版本控制系統的默認行爲；如果您使用Git來準備補丁， +您將發現它爲您完成的大部分機械工作，儘管您仍然需要準備和記錄一組合理的 +補丁。一般來說，使用git將使您作爲內核開發人員的生活更輕鬆。 + + +0) 獲取當前源碼樹 +----------------- + +如果您沒有一個可以使用當前內核原始碼的存儲庫，請使用git獲取一個。您將要 +從主線存儲庫開始，它可以通過以下方式獲取:: + + git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git + +但是，請注意，您可能不希望直接針對主線樹進行開發。大多數子系統維護人員運 +行自己的樹，並希望看到針對這些樹準備的補丁。請參見MAINTAINERS文件中子系 +統的 **T:** 項以查找該樹，或者簡單地詢問維護者該樹是否未在其中列出。 + +仍然可以通過tarballs下載內核版本（如下一節所述），但這是進行內核開發的 +一種困難的方式。 + +1) "diff -up" +------------- + +使用 "diff -up" 或者 "diff -uprN" 來創建補丁。 + +所有內核的改動，都是以補丁的形式呈現的，補丁由 diff(1) 生成。創建補丁的 +時候，要確認它是以 "unified diff" 格式創建的，這種格式由 diff(1) 的 '-u' +參數生成。而且，請使用 '-p' 參數，那樣會顯示每個改動所在的C函數，使得 +產生的補丁容易讀得多。補丁應該基於內核原始碼樹的根目錄，而不是裡邊的任 +何子目錄。 + +爲一個單獨的文件創建補丁，一般來說這樣做就夠了:: + + SRCTREE=linux + MYFILE=drivers/net/mydriver.c + + cd $SRCTREE + cp $MYFILE $MYFILE.orig + vi $MYFILE # make your change + cd .. + diff -up $SRCTREE/$MYFILE{.orig,} > /tmp/patch + +爲多個文件創建補丁，你可以解開一個沒有修改過的內核原始碼樹，然後和你自 +己的代碼樹之間做 diff 。例如:: + + MYSRC=/devel/linux + + tar xvfz linux-3.19.tar.gz + mv linux-3.19 linux-3.19-vanilla + diff -uprN -X linux-3.19-vanilla/Documentation/dontdiff \ + linux-3.19-vanilla $MYSRC > /tmp/patch + +"dontdiff" 是內核在編譯的時候產生的文件的列表，列表中的文件在 diff(1) +產生的補丁里會被跳過。 + +確定你的補丁里沒有包含任何不屬於這次補丁提交的額外文件。記得在用diff(1) +生成補丁之後，審閱一次補丁，以確保準確。 + +如果你的改動很散亂，你應該研究一下如何將補丁分割成獨立的部分，將改動分 +割成一系列合乎邏輯的步驟。這樣更容易讓其他內核開發者審核，如果你想你的 +補丁被接受，這是很重要的。請參閱： +:ref:`tw_split_changes` + +如果你用 ``git`` , ``git rebase -i`` 可以幫助你這一點。如果你不用 ``git``, +``quilt`` 另外一個流行的選擇。 + +.. _tw_describe_changes: + +2) 描述你的改動 +--------------- + +描述你的問題。無論您的補丁是一行錯誤修復還是5000行新功能，都必須有一個潛在 +的問題激勵您完成這項工作。讓審稿人相信有一個問題值得解決，讓他們讀完第一段 +是有意義的。 + +描述用戶可見的影響。直接崩潰和鎖定是相當有說服力的，但並不是所有的錯誤都那麼 +明目張胆。即使在代碼審查期間發現了這個問題，也要描述一下您認爲它可能對用戶產 +生的影響。請記住，大多數Linux安裝運行的內核來自二級穩定樹或特定於供應商/產品 +的樹，只從上游精選特定的補丁，因此請包含任何可以幫助您將更改定位到下游的內容： +觸發的場景、DMESG的摘錄、崩潰描述、性能回歸、延遲尖峯、鎖定等。 + +量化優化和權衡。如果您聲稱在性能、內存消耗、堆棧占用空間或二進位大小方面有所 +改進，請包括支持它們的數字。但也要描述不明顯的成本。優化通常不是免費的，而是 +在CPU、內存和可讀性之間進行權衡；或者，探索性的工作，在不同的工作負載之間進 +行權衡。請描述優化的預期缺點，以便審閱者可以權衡成本和收益。 + +一旦問題建立起來，就要詳細地描述一下您實際在做什麼。對於審閱者來說，用簡單的 +英語描述代碼的變化是很重要的，以驗證代碼的行爲是否符合您的意願。 + +如果您將補丁描述寫在一個表單中，這個表單可以很容易地作爲「提交日誌」放入Linux +的原始碼管理系統git中，那麼維護人員將非常感謝您。見 :ref:`tw_explicit_in_reply_to`. + +每個補丁只解決一個問題。如果你的描述開始變長，這就表明你可能需要拆分你的補丁。 +請見 :ref:`tw_split_changes` + +提交或重新提交修補程序或修補程序系列時，請包括完整的修補程序說明和理由。不要 +只說這是補丁（系列）的第幾版。不要期望子系統維護人員引用更早的補丁版本或引用 +URL來查找補丁描述並將其放入補丁中。也就是說，補丁（系列）及其描述應該是獨立的。 +這對維護人員和審查人員都有好處。一些評審者可能甚至沒有收到補丁的早期版本。 + +描述你在命令語氣中的變化，例如「make xyzzy do frotz」而不是「[這個補丁]make +xyzzy do frotz」或「[我]changed xyzzy to do frotz」，就好像你在命令代碼庫改變 +它的行爲一樣。 + +如果修補程序修復了一個記錄的bug條目，請按編號和URL引用該bug條目。如果補丁來 +自郵件列表討論，請給出郵件列表存檔的URL；使用帶有 ``Message-ID`` 的 +https://lkml.kernel.org/ 重定向，以確保連結不會過時。 + +但是，在沒有外部資源的情況下，儘量讓你的解釋可理解。除了提供郵件列表存檔或 +bug的URL之外，還要總結需要提交補丁的相關討論要點。 + +如果您想要引用一個特定的提交，不要只引用提交的 SHA-1 ID。還請包括提交的一行 +摘要，以便於審閱者了解它是關於什麼的。例如:: + + Commit e21d2170f36602ae2708 ("video: remove unnecessary + platform_set_drvdata()") removed the unnecessary + platform_set_drvdata(), but left the variable "dev" unused, + delete it. + +您還應該確保至少使用前12位 SHA-1 ID. 內核存儲庫包含*許多*對象，使與較短的ID +發生衝突的可能性很大。記住，即使現在不會與您的六個字符ID發生衝突，這種情況 +可能五年後改變。 + +如果修補程序修復了特定提交中的錯誤，例如，使用 ``git bisct`` ，請使用帶有前 +12個字符SHA-1 ID 的"Fixes:"標記和單行摘要。爲了簡化不要將標記拆分爲多個， +行、標記不受分析腳本「75列換行」規則的限制。例如:: + + Fixes: 54a4f0239f2e ("KVM: MMU: make kvm_mmu_zap_page() return the number of pages it actually freed") + +下列 ``git config`` 設置可以添加讓 ``git log``, ``git show`` 漂亮的顯示格式:: + + [core] + abbrev = 12 + [pretty] + fixes = Fixes: %h (\"%s\") + +.. _tw_split_changes: + +3) 拆分你的改動 +--------------- + +將每個邏輯更改分隔成一個單獨的補丁。 + +例如，如果你的改動里同時有bug修正和性能優化，那麼把這些改動拆分到兩個或 +者更多的補丁文件中。如果你的改動包含對API的修改，並且修改了驅動程序來適 +應這些新的API，那麼把這些修改分成兩個補丁。 + +另一方面，如果你將一個單獨的改動做成多個補丁文件，那麼將它們合併成一個 +單獨的補丁文件。這樣一個邏輯上單獨的改動只被包含在一個補丁文件里。 + +如果有一個補丁依賴另外一個補丁來完成它的改動，那沒問題。簡單的在你的補 +丁描述里指出「這個補丁依賴某補丁」就好了。 + +在將您的更改劃分爲一系列補丁時，要特別注意確保內核在系列中的每個補丁之後 +都能正常構建和運行。使用 ``git bisect`` 來追蹤問題的開發者可能會在任何時 +候分割你的補丁系列；如果你在中間引入錯誤，他們不會感謝你。 + +如果你不能將補丁濃縮成更少的文件，那麼每次大約發送出15個，然後等待審查 +和集成。 + +4) 檢查你的更改風格 +------------------- + +檢查您的補丁是否存在基本樣式衝突，詳細信息可在 +:ref:`Documentation/translations/zh_TW/process/coding-style.rst ` +中找到。如果不這樣做，只會浪費審稿人的時間，並且會導致你的補丁被拒絕，甚至 +可能沒有被閱讀。 + +一個重要的例外是在將代碼從一個文件移動到另一個文件時——在這種情況下，您不應 +該在移動代碼的同一個補丁中修改移動的代碼。這清楚地描述了移動代碼和您的更改 +的行爲。這大大有助於審查實際差異，並允許工具更好地跟蹤代碼本身的歷史。 + +在提交之前，使用補丁樣式檢查程序檢查補丁（scripts/check patch.pl）。不過， +請注意，樣式檢查程序應該被視爲一個指南，而不是作爲人類判斷的替代品。如果您 +的代碼看起來更好，但有違規行爲，那麼最好不要使用它。 + +檢查者報告三個級別： + + - ERROR：很可能出錯的事情 + - WARNING：需要仔細審查的事項 + - CHECK：需要思考的事情 + +您應該能夠判斷您的補丁中存在的所有違規行爲。 + +5) 選擇補丁收件人 +----------------- + +您應該總是在任何補丁上複製相應的子系統維護人員，以獲得他們維護的代碼；查看 +維護人員文件和原始碼修訂歷史記錄，以了解這些維護人員是誰。腳本 +scripts/get_Maintainer.pl在這個步驟中非常有用。如果您找不到正在工作的子系統 +的維護人員，那麼Andrew Morton（akpm@linux-foundation.org）將充當最後的維護 +人員。 + +您通常還應該選擇至少一個郵件列表來接收補丁集的。linux-kernel@vger.kernel.org +作爲最後一個解決辦法的列表，但是這個列表上的體積已經引起了許多開發人員的拒絕。 +在MAINTAINERS文件中查找子系統特定的列表；您的補丁可能會在那裡得到更多的關注。 +不過，請不要發送垃圾郵件到無關的列表。 + +許多與內核相關的列表託管在vger.kernel.org上；您可以在 +http://vger.kernel.org/vger-lists.html 上找到它們的列表。不過，也有與內核相關 +的列表託管在其他地方。 + +不要一次發送超過15個補丁到vger郵件列表！！！！ + +Linus Torvalds 是決定改動能否進入 Linux 內核的最終裁決者。他的 e-mail +地址是 。他收到的 e-mail 很多，所以一般 +的說，最好別給他發 e-mail。 + +如果您有修復可利用安全漏洞的補丁，請將該補丁發送到 security@kernel.org。對於 +嚴重的bug，可以考慮短期暫停以允許分銷商向用戶發布補丁；在這種情況下，顯然不應 +將補丁發送到任何公共列表。 + +修復已發布內核中嚴重錯誤的補丁程序應該指向穩定版維護人員，方法是放這樣的一行:: + + Cc: stable@vger.kernel.org + +進入補丁的簽准區（注意，不是電子郵件收件人）。除了這個文件之外，您還應該閱讀 +:ref:`Documentation/process/stable-kernel-rules.rst ` + +但是，請注意，一些子系統維護人員希望得出他們自己的結論，即哪些補丁應該被放到 +穩定的樹上。尤其是網絡維護人員，不希望看到單個開發人員在補丁中添加像上面這樣 +的行。 + +如果更改影響到用戶和內核接口，請向手冊頁維護人員（如維護人員文件中所列）發送 +手冊頁補丁，或至少發送更改通知，以便一些信息進入手冊頁。還應將用戶空間API +更改複製到 linux-api@vger.kernel.org。 + +對於小的補丁，你也許會CC到搜集瑣碎補丁的郵件列表(Trivial Patch Monkey) +trivial@kernel.org，那裡專門收集瑣碎的補丁。下面這樣的補丁會被看作「瑣碎的」 +補丁： + + - 文檔的拼寫修正。 + - 修正會影響到 grep(1) 的拼寫。 + - 警告信息修正(頻繁的列印無用的警告是不好的。) + - 編譯錯誤修正（代碼邏輯的確是對的，只是編譯有問題。） + - 運行時修正（只要真的修正了錯誤。） + - 移除使用了被廢棄的函數/宏的代碼(例如 check_region。) + - 聯繫方式和文檔修正。 + - 用可移植的代碼替換不可移植的代碼（即使在體系結構相關的代碼中，既然有 + - 人拷貝，只要它是瑣碎的） + - 任何文件的作者/維護者對該文件的改動（例如 patch monkey 在重傳模式下） + +(譯註，關於「瑣碎補丁」的一些說明：因爲原文的這一部分寫得比較簡單，所以不得不 +違例寫一下譯註。"trivial"這個英文單詞的本意是「瑣碎的，不重要的。」但是在這裡 +有稍微有一些變化，例如對一些明顯的NULL指針的修正，屬於運行時修正，會被歸類 +到瑣碎補丁里。雖然NULL指針的修正很重要，但是這樣的修正往往很小而且很容易得到 +檢驗，所以也被歸入瑣碎補丁。瑣碎補丁更精確的歸類應該是 +「simple, localized & easy to verify」，也就是說簡單的，局部的和易於檢驗的。 +trivial@kernel.org郵件列表的目的是針對這樣的補丁，爲提交者提供一個中心，來 +降低提交的門檻。) + +6) 沒有 MIME 編碼，沒有連結，沒有壓縮，沒有附件，只有純文本 +----------------------------------------------------------- + +Linus 和其他的內核開發者需要閱讀和評論你提交的改動。對於內核開發者來說 +，可以「引用」你的改動很重要，使用一般的 e-mail 工具，他們就可以在你的 +代碼的任何位置添加評論。 + +因爲這個原因，所有的提交的補丁都是 e-mail 中「內嵌」的。 + +.. warning:: + 如果你使用剪切-粘貼你的補丁，小心你的編輯器的自動換行功能破壞你的補丁 + +不要將補丁作爲 MIME 編碼的附件，不管是否壓縮。很多流行的 e-mail 軟體不 +是任何時候都將 MIME 編碼的附件當作純文本發送的，這會使得別人無法在你的 +代碼中加評論。另外，MIME 編碼的附件會讓 Linus 多花一點時間來處理，這就 +降低了你的改動被接受的可能性。 + +例外：如果你的郵遞員弄壞了補丁，那麼有人可能會要求你使用mime重新發送補丁 + +請參閱 :ref:`Documentation/translations/zh_TW/process/email-clients.rst ` +以獲取有關配置電子郵件客戶端以使其不受影響地發送修補程序的提示。 + +7) e-mail 的大小 +---------------- + +大的改動對郵件列表不合適，對某些維護者也不合適。如果你的補丁，在不壓縮 +的情況下，超過了300kB，那麼你最好將補丁放在一個能通過 internet 訪問的服 +務器上，然後用指向你的補丁的 URL 替代。但是請注意，如果您的補丁超過了 +300kb，那麼它幾乎肯定需要被破壞。 + +8）回複評審意見 +--------------- + +你的補丁幾乎肯定會得到評審者對補丁改進方法的評論。您必須對這些評論作出 +回應；讓補丁被忽略的一個好辦法就是忽略審閱者的意見。不會導致代碼更改的 +意見或問題幾乎肯定會帶來注釋或變更日誌的改變，以便下一個評審者更好地了解 +正在發生的事情。 + +一定要告訴審稿人你在做什麼改變，並感謝他們的時間。代碼審查是一個累人且 +耗時的過程，審查人員有時會變得暴躁。即使在這種情況下，也要禮貌地回應並 +解決他們指出的問題。 + +9）不要洩氣或不耐煩 +------------------- + +提交更改後，請耐心等待。審閱者是忙碌的人，可能無法立即訪問您的修補程序。 + +曾幾何時，補丁曾在沒有評論的情況下消失在空白中，但開發過程比現在更加順利。 +您應該在一周左右的時間內收到評論；如果沒有收到評論，請確保您已將補丁發送 +到正確的位置。在重新提交或聯繫審閱者之前至少等待一周-在諸如合併窗口之類的 +繁忙時間可能更長。 + +10）主題中包含 PATCH +-------------------- + +由於到linus和linux內核的電子郵件流量很高，通常會在主題行前面加上[PATCH] +前綴. 這使Linus和其他內核開發人員更容易將補丁與其他電子郵件討論區分開。 + +11）簽署你的作品-開發者原始認證 +------------------------------- + +爲了加強對誰做了何事的追蹤，尤其是對那些透過好幾層的維護者的補丁，我們 +建議在發送出去的補丁上加一個 「sign-off」 的過程。 + +"sign-off" 是在補丁的注釋的最後的簡單的一行文字，認證你編寫了它或者其他 +人有權力將它作爲開放原始碼的補丁傳遞。規則很簡單：如果你能認證如下信息: + +開發者來源證書 1.1 +^^^^^^^^^^^^^^^^^^ + +對於本項目的貢獻，我認證如下信息： + + （a）這些貢獻是完全或者部分的由我創建，我有權利以文件中指出 + 的開放原始碼許可證提交它；或者 + （b）這些貢獻基於以前的工作，據我所知，這些以前的工作受恰當的開放 + 原始碼許可證保護，而且，根據許可證，我有權提交修改後的貢獻， + 無論是完全還是部分由我創造，這些貢獻都使用同一個開放原始碼許可證 + （除非我被允許用其它的許可證），正如文件中指出的；或者 + （c）這些貢獻由認證（a），（b）或者（c）的人直接提供給我，而 + 且我沒有修改它。 + （d）我理解並同意這個項目和貢獻是公開的，貢獻的記錄（包括我 + 一起提交的個人記錄，包括 sign-off ）被永久維護並且可以和這個項目 + 或者開放原始碼的許可證同步地再發行。 + +那麼加入這樣一行:: + + Signed-off-by: Random J Developer + +使用你的真名（抱歉，不能使用假名或者匿名。） + +有人在最後加上標籤。現在這些東西會被忽略，但是你可以這樣做，來標記公司 +內部的過程，或者只是指出關於 sign-off 的一些特殊細節。 + +如果您是子系統或分支維護人員，有時需要稍微修改收到的補丁，以便合併它們， +因爲樹和提交者中的代碼不完全相同。如果你嚴格遵守規則（c），你應該要求提交者 +重新發布，但這完全是在浪費時間和精力。規則（b）允許您調整代碼，但是更改一個 +提交者的代碼並讓他認可您的錯誤是非常不禮貌的。要解決此問題，建議在最後一個 +由簽名行和您的行之間添加一行，指示更改的性質。雖然這並不是強制性的，但似乎 +在描述前加上您的郵件和/或姓名（全部用方括號括起來），這足以讓人注意到您對最 +後一分鐘的更改負有責任。例如:: + + Signed-off-by: Random J Developer + [lucky@maintainer.example.org: struct foo moved from foo.c to foo.h] + Signed-off-by: Lucky K Maintainer + +如果您維護一個穩定的分支機構，同時希望對作者進行致謝、跟蹤更改、合併修復並 +保護提交者不受投訴，那麼這種做法尤其有用。請注意，在任何情況下都不能更改作者 +的ID（From 頭），因爲它是出現在更改日誌中的標識。 + +對回合（back-porters）的特別說明：在提交消息的頂部（主題行之後）插入一個補丁 +的起源指示似乎是一種常見且有用的實踐，以便於跟蹤。例如，下面是我們在3.x穩定 +版本中看到的內容:: + + Date: Tue Oct 7 07:26:38 2014 -0400 + + libata: Un-break ATA blacklist + + commit 1c40279960bcd7d52dbdf1d466b20d24b99176c8 upstream. + +還有， 這裡是一個舊版內核中的一個回合補丁:: + + Date: Tue May 13 22:12:27 2008 +0200 + + wireless, airo: waitbusy() won't delay + + [backport of 2.6 commit b7acbdfbd1f277c1eb23f344f899cfa4cd0bf36a] + +12）何時使用Acked-by:，CC:，和Co-Developed by: +---------------------------------------------- + +Singed-off-by: 標記表示簽名者參與了補丁的開發，或者他/她在補丁的傳遞路徑中。 + +如果一個人沒有直接參與補丁的準備或處理，但希望表示並記錄他們對補丁的批准， +那麼他們可以要求在補丁的變更日誌中添加一個 Acked-by: + +Acked-by：通常由受影響代碼的維護者使用，當該維護者既沒有貢獻也沒有轉發補丁時。 + +Acked-by: 不像簽字人那樣正式。這是一個記錄，確認人至少審查了補丁，並表示接受。 +因此，補丁合併有時會手動將Acker的「Yep，looks good to me」轉換爲 Acked-By：（但 +請注意，通常最好要求一個明確的Ack）。 + +Acked-by：不一定表示對整個補丁的確認。例如，如果一個補丁影響多個子系統，並且 +有一個：來自一個子系統維護者，那麼這通常表示只確認影響維護者代碼的部分。這裡 +應該仔細判斷。如有疑問，應參考郵件列表檔案中的原始討論。 + +如果某人有機會對補丁進行評論，但沒有提供此類評論，您可以選擇在補丁中添加 ``Cc:`` +這是唯一一個標籤，它可以在沒有被它命名的人顯式操作的情況下添加，但它應該表明 +這個人是在補丁上抄送的。討論中包含了潛在利益相關方。 + +Co-developed-by: 聲明補丁是由多個開發人員共同創建的；當幾個人在一個補丁上工 +作時，它用於將屬性賦予共同作者（除了 From: 所賦予的作者之外）。因爲 +Co-developed-by: 表示作者身份，所以每個共同開發人：必須緊跟在相關合作作者的 +簽名之後。標準的簽核程序要求：標記的簽核順序應儘可能反映補丁的時間歷史，而不 +管作者是通過 From ：還是由 Co-developed-by: 共同開發的。值得注意的是，最後一 +個簽字人：必須始終是提交補丁的開發人員。 + +注意，當作者也是電子郵件標題「發件人：」行中列出的人時，「From: 」 標記是可選的。 + +作者提交的補丁程序示例:: + + + + Co-developed-by: First Co-Author + Signed-off-by: First Co-Author + Co-developed-by: Second Co-Author + Signed-off-by: Second Co-Author + Signed-off-by: From Author + +合作開發者提交的補丁示例:: + + From: From Author + + + + Co-developed-by: Random Co-Author + Signed-off-by: Random Co-Author + Signed-off-by: From Author + Co-developed-by: Submitting Co-Author + Signed-off-by: Submitting Co-Author + + +13）使用報告人：、測試人：、審核人：、建議人：、修復人： +-------------------------------------------------------- + +Reported-by: 給那些發現錯誤並報告錯誤的人致謝，它希望激勵他們在將來再次幫助 +我們。請注意，如果bug是以私有方式報告的，那麼在使用Reported-by標記之前，請 +先請求權限。 + +Tested-by: 標記表示補丁已由指定的人（在某些環境中）成功測試。這個標籤通知 +維護人員已經執行了一些測試，爲將來的補丁提供了一種定位測試人員的方法，並確 +保測試人員的信譽。 + +Reviewed-by：相反，根據審查人的聲明，表明該補丁已被審查並被認爲是可接受的： + + +審查人的監督聲明 +^^^^^^^^^^^^^^^^ + +通過提供我的 Reviewed-by，我聲明： + + (a) 我已經對這個補丁進行了一次技術審查，以評估它是否適合被包含到 + 主線內核中。 + + (b) 與補丁相關的任何問題、顧慮或問題都已反饋給提交者。我對提交者對 + 我的評論的回應感到滿意。 + + (c) 雖然這一提交可能會改進一些東西，但我相信，此時，（1）對內核 + 進行了有價值的修改，（2）沒有包含爭論中涉及的已知問題。 + + (d) 雖然我已經審查了補丁並認爲它是健全的，但我不會（除非另有明確 + 說明）作出任何保證或保證它將在任何給定情況下實現其規定的目的 + 或正常運行。 + +Reviewed-by 是一種觀點聲明，即補丁是對內核的適當修改，沒有任何遺留的嚴重技術 +問題。任何感興趣的審閱者（完成工作的人）都可以爲一個補丁提供一個 Review-by +標籤。此標籤用於向審閱者提供致謝，並通知維護者已在修補程序上完成的審閱程度。 +Reviewed-by: 當由已知了解主題區域並執行徹底檢查的審閱者提供時，通常會增加 +補丁進入內核的可能性。 + +Suggested-by: 表示補丁的想法是由指定的人提出的，並確保將此想法歸功於指定的 +人。請注意，未經許可，不得添加此標籤，特別是如果該想法未在公共論壇上發布。 +這就是說，如果我們勤快地致謝我們的創意者，他們很有希望在未來得到鼓舞，再次 +幫助我們。 + +Fixes: 指示補丁在以前的提交中修復了一個問題。它可以很容易地確定錯誤的來源， +這有助於檢查錯誤修復。這個標記還幫助穩定內核團隊確定應該接收修復的穩定內核 +版本。這是指示補丁修復的錯誤的首選方法。請參閱 :ref:`tw_describe_changes` +描述您的更改以了解更多詳細信息。 + +.. _tw_the_canonical_patch_format: + +12）標準補丁格式 +---------------- + +本節描述如何格式化補丁本身。請注意，如果您的補丁存儲在 ``Git`` 存儲庫中，則 +可以使用 ``git format-patch`` 進行正確的補丁格式設置。但是，這些工具無法創建 +必要的文本，因此請務必閱讀下面的說明。 + +標準的補丁，標題行是:: + + Subject: [PATCH 001/123] 子系統:一句話概述 + +標準補丁的信體存在如下部分： + + - 一個 "from" 行指出補丁作者。後跟空行（僅當發送修補程序的人不是作者時才需要）。 + + - 解釋的正文，行以75列包裝，這將被複製到永久變更日誌來描述這個補丁。 + + - 一個空行 + + - 上面描述的「Signed-off-by」 行，也將出現在更改日誌中。 + + - 只包含 ``---`` 的標記線。 + + - 任何其他不適合放在變更日誌的注釋。 + + - 實際補丁（ ``diff`` 輸出）。 + +標題行的格式，使得對標題行按字母序排序非常的容易 - 很多 e-mail 客戶端都 +可以支持 - 因爲序列號是用零填充的，所以按數字排序和按字母排序是一樣的。 + +e-mail 標題中的「子系統」標識哪個內核子系統將被打補丁。 + +e-mail 標題中的「一句話概述」扼要的描述 e-mail 中的補丁。「一句話概述」 +不應該是一個文件名。對於一個補丁系列（「補丁系列」指一系列的多個相關補 +丁），不要對每個補丁都使用同樣的「一句話概述」。 + +記住 e-mail 的「一句話概述」會成爲該補丁的全局唯一標識。它會蔓延到 git +的改動記錄里。然後「一句話概述」會被用在開發者的討論里，用來指代這個補 +丁。用戶將希望通過 google 來搜索"一句話概述"來找到那些討論這個補丁的文 +章。當人們在兩三個月後使用諸如 ``gitk`` 或 ``git log --oneline`` 之類 +的工具查看數千個補丁時，也會很快看到它。 + +出於這些原因，概述必須不超過70-75個字符，並且必須描述補丁的更改以及爲 +什麼需要補丁。既要簡潔又要描述性很有挑戰性，但寫得好的概述應該這樣做。 + +概述的前綴可以用方括號括起來：「Subject: [PATCH ...] <概述>」。標記 +不被視爲概述的一部分，而是描述應該如何處理補丁。如果補丁的多個版本已發 +送出來以響應評審（即「v1，v2，v3」）或「rfc」，以指示評審請求，那麼通用標記 +可能包括版本描述符。如果一個補丁系列中有四個補丁，那麼各個補丁可以這樣 +編號：1/4、2/4、3/4、4/4。這可以確保開發人員了解補丁應用的順序，並且他們 +已經查看或應用了補丁系列中的所有補丁。 + +一些標題的例子:: + + Subject: [patch 2/5] ext2: improve scalability of bitmap searching + Subject: [PATCHv2 001/207] x86: fix eflags tracking + +"From" 行是信體裡的最上面一行，具有如下格式： + From: Patch Author + +"From" 行指明在永久改動日誌里，誰會被確認爲作者。如果沒有 "From" 行，那 +麼郵件頭裡的 "From: " 行會被用來決定改動日誌中的作者。 + +說明的主題將會被提交到永久的原始碼改動日誌里，因此對那些早已經不記得和 +這個補丁相關的討論細節的有能力的讀者來說，是有意義的。包括補丁程序定位 +錯誤的（內核日誌消息、OOPS消息等）症狀，對於搜索提交日誌以尋找適用補丁的人 +尤其有用。如果一個補丁修復了一個編譯失敗，那麼可能不需要包含所有編譯失敗； +只要足夠讓搜索補丁的人能夠找到它就行了。與概述一樣，既要簡潔又要描述性。 + +"---" 標記行對於補丁處理工具要找到哪裡是改動日誌信息的結束，是不可缺少 +的。 + +對於 "---" 標記之後的額外註解，一個好的用途就是用來寫 diffstat，用來顯 +示修改了什麼文件和每個文件都增加和刪除了多少行。diffstat 對於比較大的補 +丁特別有用。其餘那些只是和時刻或者開發者相關的註解，不合適放到永久的改 +動日誌里的，也應該放這裡。 +使用 diffstat的選項 "-p 1 -w 70" 這樣文件名就會從內核原始碼樹的目錄開始 +，不會占用太寬的空間（很容易適合80列的寬度，也許會有一些縮進。） + +在後面的參考資料中能看到適當的補丁格式的更多細節。 + +.. _tw_explicit_in_reply_to: + +15) 明確回覆郵件頭(In-Reply-To) +------------------------------- + +手動添加回復補丁的的標題頭(In-Reply_To:) 是有幫助的（例如，使用 ``git send-email`` ） +將補丁與以前的相關討論關聯起來，例如，將bug修復程序連結到電子郵件和bug報告。 +但是，對於多補丁系列，最好避免在回復時使用連結到該系列的舊版本。這樣， +補丁的多個版本就不會成爲電子郵件客戶端中無法管理的引用序列。如果連結有用， +可以使用 https://lkml.kernel.org/ 重定向器（例如，在封面電子郵件文本中） +連結到補丁系列的早期版本。 + +16) 發送git pull請求 +-------------------- + +如果您有一系列補丁，那麼讓維護人員通過git pull操作將它們直接拉入子系統存儲 +庫可能是最方便的。但是，請注意，從開發人員那裡獲取補丁比從郵件列表中獲取補 +丁需要更高的信任度。因此，許多子系統維護人員不願意接受請求，特別是來自新的 +未知開發人員的請求。如果有疑問，您可以在封面郵件中使用pull 請求作爲補丁系列 +正常發布的一個選項，讓維護人員可以選擇使用其中之一。 + +pull 請求的主題行中應該有[Git Pull]。請求本身應該在一行中包含存儲庫名稱和 +感興趣的分支；它應該看起來像:: + + Please pull from + + git://jdelvare.pck.nerim.net/jdelvare-2.6 i2c-for-linus + + to get these changes: + + +pull 請求還應該包含一條整體消息，說明請求中將包含什麼，一個補丁本身的 ``Git shortlog`` +以及一個顯示補丁系列整體效果的 ``diffstat`` 。當然，將所有這些信息收集在一起 +的最簡單方法是讓 ``git`` 使用 ``git request-pull`` 命令爲您完成這些工作。 + +一些維護人員（包括Linus）希望看到來自已簽名提交的請求；這增加了他們對你的 +請求信心。特別是，在沒有簽名標籤的情況下，Linus 不會從像 Github 這樣的公共 +託管站點拉請求。 + +創建此類簽名的第一步是生成一個 GNRPG 密鑰，並由一個或多個核心內核開發人員對 +其進行簽名。這一步對新開發人員來說可能很困難，但沒有辦法繞過它。參加會議是 +找到可以簽署您的密鑰的開發人員的好方法。 + +一旦您在Git 中準備了一個您希望有人拉的補丁系列，就用 ``git tag -s`` 創建一 +個簽名標記。這將創建一個新標記，標識該系列中的最後一次提交，並包含用您的私 +鑰創建的簽名。您還可以將changelog樣式的消息添加到標記中；這是一個描述拉請求 +整體效果的理想位置。 + +如果維護人員將要從中提取的樹不是您正在使用的存儲庫，請不要忘記將已簽名的標記 +顯式推送到公共樹。 + +生成拉請求時，請使用已簽名的標記作爲目標。這樣的命令可以實現:: + + git request-pull master git://my.public.tree/linux.git my-signed-tag + +參考文獻 +-------- + +Andrew Morton, "The perfect patch" (tpp). + + +Jeff Garzik, "Linux kernel patch submission format". + + +Greg Kroah-Hartman, "How to piss off a kernel subsystem maintainer". + + + + + + + + + + + + +NO!!!! No more huge patch bombs to linux-kernel@vger.kernel.org people! + + +Kernel Documentation/process/coding-style.rst: + :ref:`Documentation/translations/zh_TW/process/coding-style.rst ` + +Linus Torvalds's mail on the canonical patch format: + + +Andi Kleen, "On submitting kernel patches" + Some strategies to get difficult or controversial changes in. + + http://halobates.de/on-submitting-patches.pdf + diff --git a/Documentation/translations/zh_TW/process/volatile-considered-harmful.rst b/Documentation/translations/zh_TW/process/volatile-considered-harmful.rst new file mode 100644 index 000000000000..097fe80352cb --- /dev/null +++ b/Documentation/translations/zh_TW/process/volatile-considered-harmful.rst @@ -0,0 +1,110 @@ +.. SPDX-License-Identifier: GPL-2.0 + +.. _tw_volatile_considered_harmful: + +.. include:: ../disclaimer-zh_TW.rst + +:Original: :ref:`Documentation/process/volatile-considered-harmful.rst + ` + +如果想評論或更新本文的內容，請直接聯繫原文檔的維護者。如果你使用英文 +交流有困難的話，也可以向中文版維護者求助。如果本翻譯更新不及時或者翻 +譯存在問題，請聯繫中文版維護者:: + + 英文版維護者： Jonathan Corbet + 中文版維護者： 伍鵬 Bryan Wu + 中文版翻譯者： 伍鵬 Bryan Wu + 中文版校譯者： 張漢輝 Eugene Teo + 楊瑞 Dave Young + 時奎亮 Alex Shi + 胡皓文 Hu Haowen + +爲什麼不應該使用「volatile」類型 +================================ + +C程式設計師通常認爲volatile表示某個變量可以在當前執行的線程之外被改變；因此，在內核 +中用到共享數據結構時，常常會有C程式設計師喜歡使用volatile這類變量。換句話說，他們經 +常會把volatile類型看成某種簡易的原子變量，當然它們不是。在內核中使用volatile幾 +乎總是錯誤的；本文檔將解釋爲什麼這樣。 + +理解volatile的關鍵是知道它的目的是用來消除優化，實際上很少有人真正需要這樣的應 +用。在內核中，程式設計師必須防止意外的並發訪問破壞共享的數據結構，這其實是一個完全 +不同的任務。用來防止意外並發訪問的保護措施，可以更加高效的避免大多數優化相關的 +問題。 + +像volatile一樣，內核提供了很多原語來保證並發訪問時的數據安全（自旋鎖, 互斥量,內 +存屏障等等），同樣可以防止意外的優化。如果可以正確使用這些內核原語，那麼就沒有 +必要再使用volatile。如果仍然必須使用volatile，那麼幾乎可以肯定在代碼的某處有一 +個bug。在正確設計的內核代碼中，volatile能帶來的僅僅是使事情變慢。 + +思考一下這段典型的內核代碼:: + + spin_lock(&the_lock); + do_something_on(&shared_data); + do_something_else_with(&shared_data); + spin_unlock(&the_lock); + +如果所有的代碼都遵循加鎖規則，當持有the_lock的時候，不可能意外的改變shared_data的 +值。任何可能訪問該數據的其他代碼都會在這個鎖上等待。自旋鎖原語跟內存屏障一樣—— 它 +們顯式的用來書寫成這樣 —— 意味著數據訪問不會跨越它們而被優化。所以本來編譯器認爲 +它知道在shared_data裡面將有什麼，但是因爲spin_lock()調用跟內存屏障一樣，會強制編 +譯器忘記它所知道的一切。那麼在訪問這些數據時不會有優化的問題。 + +如果shared_data被聲名爲volatile，鎖操作將仍然是必須的。就算我們知道沒有其他人正在 +使用它，編譯器也將被阻止優化對臨界區內shared_data的訪問。在鎖有效的同時， +shared_data不是volatile的。在處理共享數據的時候，適當的鎖操作可以不再需要 +volatile —— 並且是有潛在危害的。 + +volatile的存儲類型最初是爲那些內存映射的I/O寄存器而定義。在內核里，寄存器訪問也應 +該被鎖保護，但是人們也不希望編譯器「優化」臨界區內的寄存器訪問。內核里I/O的內存訪問 +是通過訪問函數完成的；不贊成通過指針對I/O內存的直接訪問，並且不是在所有體系架構上 +都能工作。那些訪問函數正是爲了防止意外優化而寫的，因此，再說一次，volatile類型不 +是必需的。 + +另一種引起用戶可能使用volatile的情況是當處理器正忙著等待一個變量的值。正確執行一 +個忙等待的方法是:: + + while (my_variable != what_i_want) + cpu_relax(); + +cpu_relax()調用會降低CPU的能量消耗或者讓位於超線程雙處理器；它也作爲內存屏障一樣出 +現，所以，再一次，volatile不是必需的。當然，忙等待一開始就是一種反常規的做法。 + +在內核中，一些稀少的情況下volatile仍然是有意義的： + + - 在一些體系架構的系統上，允許直接的I/0內存訪問，那麼前面提到的訪問函數可以使用 + volatile。基本上，每一個訪問函數調用它自己都是一個小的臨界區域並且保證了按照 + 程式設計師期望的那樣發生訪問操作。 + + - 某些會改變內存的內聯彙編代碼雖然沒有什麼其他明顯的附作用，但是有被GCC刪除的可 + 能性。在彙編聲明中加上volatile關鍵字可以防止這種刪除操作。 + + - Jiffies變量是一種特殊情況，雖然每次引用它的時候都可以有不同的值，但讀jiffies + 變量時不需要任何特殊的加鎖保護。所以jiffies變量可以使用volatile，但是不贊成 + 其他跟jiffies相同類型變量使用volatile。Jiffies被認爲是一種「愚蠢的遺留物" + （Linus的話）因爲解決這個問題比保持現狀要麻煩的多。 + + - 由於某些I/0設備可能會修改連續一致的內存,所以有時,指向連續一致內存的數據結構 + 的指針需要正確的使用volatile。網絡適配器使用的環狀緩存區正是這類情形的一個例 + 子，其中適配器用改變指針來表示哪些描述符已經處理過了。 + +對於大多代碼，上述幾種可以使用volatile的情況都不適用。所以，使用volatile是一種 +bug並且需要對這樣的代碼額外仔細檢查。那些試圖使用volatile的開發人員需要退一步想想 +他們真正想實現的是什麼。 + +非常歡迎刪除volatile變量的補丁 － 只要證明這些補丁完整的考慮了並發問題。 + +注釋 +---- + +[1] https://lwn.net/Articles/233481/ +[2] https://lwn.net/Articles/233482/ + +致謝 +---- + +最初由Randy Dunlap推動並作初步研究 +由Jonathan Corbet撰寫 +參考Satyam Sharma，Johannes Stezenbach，Jesper Juhl，Heikki Orsila， +H. Peter Anvin，Philipp Hahn和Stefan Richter的意見改善了本檔。 + -- cgit v1.2.3 From eaaa23d71ebf0c598eedb81d4a814b0a475273f6 Mon Sep 17 00:00:00 2001 From: Christophe Branchereau Date: Mon, 26 Jul 2021 10:20:33 +0200 Subject: dt-bindings: iio/adc: ingenic: add the JZ4760(B) socs to the sadc Documentation Add both the jz4760 and jz4760b, plus a property to use the internal divider on the b variant and document it. Signed-off-by: Christophe Branchereau Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20210726082033.351533-6-cbranchereau@gmail.com Signed-off-by: Jonathan Cameron --- .../devicetree/bindings/iio/adc/ingenic,adc.yaml | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/iio/adc/ingenic,adc.yaml b/Documentation/devicetree/bindings/iio/adc/ingenic,adc.yaml index 433a3fb55a2e..3eb7aa8822c3 100644 --- a/Documentation/devicetree/bindings/iio/adc/ingenic,adc.yaml +++ b/Documentation/devicetree/bindings/iio/adc/ingenic,adc.yaml @@ -23,6 +23,8 @@ properties: enum: - ingenic,jz4725b-adc - ingenic,jz4740-adc + - ingenic,jz4760-adc + - ingenic,jz4760b-adc - ingenic,jz4770-adc '#io-channel-cells': @@ -43,6 +45,23 @@ properties: interrupts: maxItems: 1 + ingenic,use-internal-divider: + description: + If present, battery voltage is read from the VBAT_IR pin, which has an + internal 1/4 divider. If absent, it is read through the VBAT_ER pin, + which does not have such a divider. + type: boolean + +if: + not: + properties: + compatible: + contains: + const: ingenic,jz4760b-adc +then: + properties: + ingenic,use-internal-divider: false + required: - compatible - '#io-channel-cells' -- cgit v1.2.3 From d1945f6c5bf82e9eb477565f3496396db4f4d6e5 Mon Sep 17 00:00:00 2001 From: Iskren Chernev Date: Fri, 23 Jul 2021 22:23:51 +0300 Subject: dt-bindings: pinctrl: qcom: Add SM6115 pinctrl bindings Add device tree binding Documentation details for Qualcomm SM6115 and SM4250 pinctrl. Signed-off-by: Iskren Chernev Reviewed-by: Bjorn Andersson Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20210723192352.546902-2-iskren.chernev@gmail.com Signed-off-by: Linus Walleij --- .../bindings/pinctrl/qcom,sm6115-pinctrl.yaml | 179 +++++++++++++++++++++ 1 file changed, 179 insertions(+) create mode 100644 Documentation/devicetree/bindings/pinctrl/qcom,sm6115-pinctrl.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sm6115-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sm6115-pinctrl.yaml new file mode 100644 index 000000000000..8fc06f6a3ef4 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/qcom,sm6115-pinctrl.yaml @@ -0,0 +1,179 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pinctrl/qcom,sm6115-pinctrl.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Technologies, Inc. SM6115, SM4250 TLMM block + +maintainers: + - Iskren Chernev + +description: + This binding describes the Top Level Mode Multiplexer block found in the + SM4250/6115 platforms. + +properties: + compatible: + const: qcom,sm6115-tlmm + + reg: + minItems: 3 + maxItems: 3 + + reg-names: + items: + - const: west + - const: south + - const: east + + interrupts: + description: Specifies the TLMM summary IRQ + maxItems: 1 + + interrupt-controller: true + + '#interrupt-cells': + description: + Specifies the PIN numbers and Flags, as defined in defined in + include/dt-bindings/interrupt-controller/irq.h + const: 2 + + gpio-controller: true + + '#gpio-cells': + description: Specifying the pin number and flags, as defined in + include/dt-bindings/gpio/gpio.h + const: 2 + + gpio-ranges: + maxItems: 1 + + wakeup-parent: + maxItems: 1 + +#PIN CONFIGURATION NODES +patternProperties: + '-state$': + oneOf: + - $ref: "#/$defs/qcom-sm6115-tlmm-state" + - patternProperties: + ".*": + $ref: "#/$defs/qcom-sm6115-tlmm-state" + +'$defs': + qcom-sm6115-tlmm-state: + type: object + description: + Pinctrl node's client devices use subnodes for desired pin configuration. + Client device subnodes use below standard properties. + $ref: "qcom,tlmm-common.yaml#/$defs/qcom-tlmm-state" + + properties: + pins: + description: + List of gpio pins affected by the properties specified in this + subnode. + items: + oneOf: + - pattern: "^gpio([0-9]|[1-9][0-9]|10[0-9]|11[0-2])$" + - enum: [ sdc1_rclk, sdc1_clk, sdc1_cmd, sdc1_data, + sdc2_clk, sdc2_cmd, sdc2_data, ufs_reset ] + minItems: 1 + maxItems: 36 + + function: + description: + Specify the alternative function to be configured for the specified + pins. + + enum: [ adsp_ext, agera_pll, atest, cam_mclk, cci_async, cci_i2c, + cci_timer, cri_trng, dac_calib, dbg_out, ddr_bist, ddr_pxi0, + ddr_pxi1, ddr_pxi2, ddr_pxi3, gcc_gp1, gcc_gp2, gcc_gp3, gpio, + gp_pdm0, gp_pdm1, gp_pdm2, gsm0_tx, gsm1_tx, jitter_bist, + mdp_vsync, mdp_vsync_out_0, mdp_vsync_out_1, mpm_pwr, mss_lte, + m_voc, nav_gpio, pa_indicator, pbs, pbs_out, phase_flag, + pll_bist, pll_bypassnl, pll_reset, prng_rosc, qdss_cti, + qdss_gpio, qup0, qup1, qup2, qup3, qup4, qup5, sdc1_tb, + sdc2_tb, sd_write, ssbi_wtr1, tgu, tsense_pwm, uim1_clk, + uim1_data, uim1_present, uim1_reset, uim2_clk, uim2_data, + uim2_present, uim2_reset, usb_phy, vfr_1, vsense_trigger, + wlan1_adc0, elan1_adc1 ] + + drive-strength: + enum: [2, 4, 6, 8, 10, 12, 14, 16] + default: 2 + description: + Selects the drive strength for the specified pins, in mA. + + bias-pull-down: true + + bias-pull-up: true + + bias-disable: true + + output-high: true + + output-low: true + + required: + - pins + + additionalProperties: false + +required: + - compatible + - reg + - reg-names + - interrupts + - interrupt-controller + - '#interrupt-cells' + - gpio-controller + - '#gpio-cells' + - gpio-ranges + +additionalProperties: false + +examples: + - | + #include + tlmm: pinctrl@500000 { + compatible = "qcom,sm6115-tlmm"; + reg = <0x500000 0x400000>, + <0x900000 0x400000>, + <0xd00000 0x400000>; + reg-names = "west", "south", "east"; + interrupts = ; + gpio-controller; + #gpio-cells = <2>; + interrupt-controller; + #interrupt-cells = <2>; + gpio-ranges = <&tlmm 0 0 114>; + + sdc2_on_state: sdc2-on-state { + clk { + pins = "sdc2_clk"; + bias-disable; + drive-strength = <16>; + }; + + cmd { + pins = "sdc2_cmd"; + bias-pull-up; + drive-strength = <10>; + }; + + data { + pins = "sdc2_data"; + bias-pull-up; + drive-strength = <10>; + }; + + sd-cd { + pins = "gpio88"; + function = "gpio"; + bias-pull-up; + drive-strength = <2>; + }; + }; + }; -- cgit v1.2.3 From 9746f5fe70aa16182bcb505265c4800365438585 Mon Sep 17 00:00:00 2001 From: Alistair Francis Date: Sun, 1 Aug 2021 10:47:00 +1000 Subject: drm/panel: Add support for E Ink VB3300-KCA Add support for the 10.3" E Ink panel described at: https://www.eink.com/product.html?type=productdetail&id=7 Signed-off-by: Alistair Francis Acked-by: Rob Herring Reviewed-by: Sam Ravnborg Signed-off-by: Sam Ravnborg Link: https://patchwork.freedesktop.org/patch/msgid/20210801004701.831-1-alistair@alistair23.me --- Documentation/devicetree/bindings/display/panel/panel-simple.yaml | 2 ++ Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ 2 files changed, 4 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml index eda427ddca1b..81bdfb03bcea 100644 --- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml +++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml @@ -138,6 +138,8 @@ properties: # Emerging Display Technology Corp. 5.7" VGA TFT LCD panel with # capacitive touch - edt,etmv570g2dhu + # E Ink VB3300-KCA + - eink,vb3300-kca # Evervision Electronics Co. Ltd. VGG804821 5.0" WVGA TFT LCD Panel - evervision,vgg804821 # Foxlink Group 5" WVGA TFT LCD panel diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index 3c6918dde429..5713e6672ddb 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -339,6 +339,8 @@ patternProperties: description: eGalax_eMPIA Technology Inc "^einfochips,.*": description: Einfochips + "^eink,.*": + description: E Ink Corporation "^elan,.*": description: Elan Microelectronic Corp. "^element14,.*": -- cgit v1.2.3 From f02bc9754a6887bf5e286889265d24ce5e3b1952 Mon Sep 17 00:00:00 2001 From: Daejun Park Date: Mon, 12 Jul 2021 17:58:30 +0900 Subject: scsi: ufs: ufshpb: Introduce Host Performance Buffer feature Implement Host Performance Buffer (HPB) initialization and add function calls to UFS core driver. NAND flash-based storage devices, including UFS, have mechanisms to translate logical addresses of I/O requests to the corresponding physical addresses of the flash storage. In UFS, logical-to-physical-address (L2P) map data, which is required to identify the physical address for the requested I/Os, can only be partially stored in SRAM from NAND flash. Due to this partial loading, accessing the flash address area, where the L2P information for that address is not loaded in the SRAM, can result in serious performance degradation. The basic concept of HPB is to cache L2P mapping entries in host system memory so that both physical block address (PBA) and logical block address (LBA) can be delivered in HPB read command. The HPB read command allows to read data faster than a regular read command in UFS since it provides the physical address (HPB Entry) of the desired logical block in addition to its logical address. The UFS device can access the physical block in NAND directly without searching and uploading L2P mapping table. This improves read performance because the NAND read operation for uploading L2P mapping table is removed. In HPB initialization, the host checks if the UFS device supports HPB feature and retrieves related device capabilities. Then, HPB parameters are configured in the device. Total start-up time of popular applications was measured and the difference observed between HPB being enabled and disabled. Popular applications are 12 game apps and 24 non-game apps. Each test cycle consists of running 36 applications in sequence. We repeated the cycle for observing performance improvement by L2P mapping cache hit in HPB. The following is the test environment: - kernel version: 4.4.0 - RAM: 8GB - UFS 2.1 (64GB) Results: +-------+----------+----------+-------+ | cycle | baseline | with HPB | diff | +-------+----------+----------+-------+ | 1 | 272.4 | 264.9 | -7.5 | | 2 | 250.4 | 248.2 | -2.2 | | 3 | 226.2 | 215.6 | -10.6 | | 4 | 230.6 | 214.8 | -15.8 | | 5 | 232.0 | 218.1 | -13.9 | | 6 | 231.9 | 212.6 | -19.3 | +-------+----------+----------+-------+ We also measured HPB performance using iozone: $ iozone -r 4k -+n -i2 -ecI -t 16 -l 16 -u 16 -s $IO_RANGE/16 -F \ mnt/tmp_1 mnt/tmp_2 mnt/tmp_3 mnt/tmp_4 mnt/tmp_5 mnt/tmp_6 mnt/tmp_7 \ mnt/tmp_8 mnt/tmp_9 mnt/tmp_10 mnt/tmp_11 mnt/tmp_12 mnt/tmp_13 \ mnt/tmp_14 mnt/tmp_15 mnt/tmp_16 Results: +----------+--------+---------+ | IO range | HPB on | HPB off | +----------+--------+---------+ | 1 GB | 294.8 | 300.87 | | 4 GB | 293.51 | 179.35 | | 8 GB | 294.85 | 162.52 | | 16 GB | 293.45 | 156.26 | | 32 GB | 277.4 | 153.25 | +----------+--------+---------+ Link: https://lore.kernel.org/r/20210712085830epcms2p8c1288b7f7a81b044158a18232617b572@epcms2p8 Reported-by: kernel test robot Tested-by: Bean Huo Tested-by: Can Guo Tested-by: Stanley Chu Reviewed-by: Greg Kroah-Hartman Reviewed-by: Bart Van Assche Reviewed-by: Can Guo Reviewed-by: Bean Huo Reviewed-by: Stanley Chu Acked-by: Avri Altman Signed-off-by: Daejun Park Signed-off-by: Martin K. Petersen --- Documentation/ABI/testing/sysfs-driver-ufs | 127 +++++++++++++++++++++++++++++ 1 file changed, 127 insertions(+) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-driver-ufs b/Documentation/ABI/testing/sysfs-driver-ufs index b4a5d55fa19f..4c1a5d28408d 100644 --- a/Documentation/ABI/testing/sysfs-driver-ufs +++ b/Documentation/ABI/testing/sysfs-driver-ufs @@ -1298,3 +1298,130 @@ Description: This node is used to set or display whether UFS WriteBooster is (if the platform supports UFSHCD_CAP_CLK_SCALING). For a platform that doesn't support UFSHCD_CAP_CLK_SCALING, we can disable/enable WriteBooster through this sysfs node. + +What: /sys/bus/platform/drivers/ufshcd/*/device_descriptor/hpb_version +Date: June 2021 +Contact: Daejun Park +Description: This entry shows the HPB specification version. + The full information about the descriptor can be found in the UFS + HPB (Host Performance Booster) Extension specifications. + Example: version 1.2.3 = 0123h + + The file is read only. + +What: /sys/bus/platform/drivers/ufshcd/*/device_descriptor/hpb_control +Date: June 2021 +Contact: Daejun Park +Description: This entry shows an indication of the HPB control mode. + 00h: Host control mode + 01h: Device control mode + + The file is read only. + +What: /sys/bus/platform/drivers/ufshcd/*/geometry_descriptor/hpb_region_size +Date: June 2021 +Contact: Daejun Park +Description: This entry shows the bHPBRegionSize which can be calculated + as in the following (in bytes): + HPB Region size = 512B * 2^bHPBRegionSize + + The file is read only. + +What: /sys/bus/platform/drivers/ufshcd/*/geometry_descriptor/hpb_number_lu +Date: June 2021 +Contact: Daejun Park +Description: This entry shows the maximum number of HPB LU supported by + the device. + 00h: HPB is not supported by the device. + 01h ~ 20h: Maximum number of HPB LU supported by the device + + The file is read only. + +What: /sys/bus/platform/drivers/ufshcd/*/geometry_descriptor/hpb_subregion_size +Date: June 2021 +Contact: Daejun Park +Description: This entry shows the bHPBSubRegionSize, which can be + calculated as in the following (in bytes) and shall be a multiple of + logical block size: + HPB Sub-Region size = 512B x 2^bHPBSubRegionSize + bHPBSubRegionSize shall not exceed bHPBRegionSize. + + The file is read only. + +What: /sys/bus/platform/drivers/ufshcd/*/geometry_descriptor/hpb_max_active_regions +Date: June 2021 +Contact: Daejun Park +Description: This entry shows the maximum number of active HPB regions that + is supported by the device. + + The file is read only. + +What: /sys/class/scsi_device/*/device/unit_descriptor/hpb_lu_max_active_regions +Date: June 2021 +Contact: Daejun Park +Description: This entry shows the maximum number of HPB regions assigned to + the HPB logical unit. + + The file is read only. + +What: /sys/class/scsi_device/*/device/unit_descriptor/hpb_pinned_region_start_offset +Date: June 2021 +Contact: Daejun Park +Description: This entry shows the start offset of HPB pinned region. + + The file is read only. + +What: /sys/class/scsi_device/*/device/unit_descriptor/hpb_number_pinned_regions +Date: June 2021 +Contact: Daejun Park +Description: This entry shows the number of HPB pinned regions assigned to + the HPB logical unit. + + The file is read only. + +What: /sys/class/scsi_device/*/device/hpb_stats/hit_cnt +Date: June 2021 +Contact: Daejun Park +Description: This entry shows the number of reads that changed to HPB read. + + The file is read only. + +What: /sys/class/scsi_device/*/device/hpb_stats/miss_cnt +Date: June 2021 +Contact: Daejun Park +Description: This entry shows the number of reads that cannot be changed to + HPB read. + + The file is read only. + +What: /sys/class/scsi_device/*/device/hpb_stats/rb_noti_cnt +Date: June 2021 +Contact: Daejun Park +Description: This entry shows the number of response UPIUs that has + recommendations for activating sub-regions and/or inactivating region. + + The file is read only. + +What: /sys/class/scsi_device/*/device/hpb_stats/rb_active_cnt +Date: June 2021 +Contact: Daejun Park +Description: This entry shows the number of active sub-regions recommended by + response UPIUs. + + The file is read only. + +What: /sys/class/scsi_device/*/device/hpb_stats/rb_inactive_cnt +Date: June 2021 +Contact: Daejun Park +Description: This entry shows the number of inactive regions recommended by + response UPIUs. + + The file is read only. + +What: /sys/class/scsi_device/*/device/hpb_stats/map_req_cnt +Date: June 2021 +Contact: Daejun Park +Description: This entry shows the number of read buffer commands for + activating sub-regions recommended by response UPIUs. + + The file is read only. -- cgit v1.2.3 From 41d8a9333cc96f5ad4dd7a52786585338257d9f1 Mon Sep 17 00:00:00 2001 From: Daejun Park Date: Mon, 12 Jul 2021 18:00:25 +0900 Subject: scsi: ufs: ufshpb: Add HPB 2.0 support Version 2.0 of HBP supports reads of varying sizes from 4KB to 1MB. A read operation <= 32KB is supported as single HPB read. A read between 36KB and 1MB is supported by a combination of write buffer command and HPB read command to deliver more PPN. The write buffer commands may not be issued immediately due to busy tags. To use HPB read more aggressively, the driver can requeue the write buffer command. The requeue threshold is implemented as timeout and can be modified with requeue_timeout_ms entry in sysfs. [mkp: REQ_OP_DRV_* and blk_rq_is_passthrough()] Link: https://lore.kernel.org/r/20210712090025epcms2p3b3d94f6f1b2cfa394e3d9ba130ca0fa7@epcms2p3 Tested-by: Can Guo Tested-by: Stanley Chu Reviewed-by: Greg Kroah-Hartman Reviewed-by: Can Guo Reviewed-by: Bean Huo Reviewed-by: Stanley Chu Signed-off-by: Daejun Park Signed-off-by: Martin K. Petersen --- Documentation/ABI/testing/sysfs-driver-ufs | 35 ++++++++++++++++++++++++++++++ 1 file changed, 35 insertions(+) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-driver-ufs b/Documentation/ABI/testing/sysfs-driver-ufs index 4c1a5d28408d..929460738651 100644 --- a/Documentation/ABI/testing/sysfs-driver-ufs +++ b/Documentation/ABI/testing/sysfs-driver-ufs @@ -1425,3 +1425,38 @@ Description: This entry shows the number of read buffer commands for activating sub-regions recommended by response UPIUs. The file is read only. + +What: /sys/class/scsi_device/*/device/hpb_params/requeue_timeout_ms +Date: June 2021 +Contact: Daejun Park +Description: This entry shows the requeue timeout threshold for write buffer + command in ms. The value can be changed by writing an integer to + this entry. + +What: /sys/bus/platform/drivers/ufshcd/*/attributes/max_data_size_hpb_single_cmd +Date: June 2021 +Contact: Daejun Park +Description: This entry shows the maximum HPB data size for using a single HPB + command. + + === ======== + 00h 4KB + 01h 8KB + 02h 12KB + ... + FFh 1024KB + === ======== + + The file is read only. + +What: /sys/bus/platform/drivers/ufshcd/*/flags/wb_enable +Date: June 2021 +Contact: Daejun Park +Description: This entry shows the status of HPB. + + == ============================ + 0 HPB is not enabled. + 1 HPB is enabled + == ============================ + + The file is read only. -- cgit v1.2.3 From f95f59a2bb60f917faf516f2f0a679dc4e58f490 Mon Sep 17 00:00:00 2001 From: Avri Altman Date: Mon, 12 Jul 2021 12:50:39 +0300 Subject: scsi: ufs: ufshpb: Make host mode parameters configurable Elaborate some more on the host control mode logic parameters, explaining what they do and how to configure them. Link: https://lore.kernel.org/r/20210712095039.8093-13-avri.altman@wdc.com Reviewed-by: Daejun Park Signed-off-by: Avri Altman Signed-off-by: Martin K. Petersen --- Documentation/ABI/testing/sysfs-driver-ufs | 76 +++++++++++++++++++++++++++++- 1 file changed, 75 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-driver-ufs b/Documentation/ABI/testing/sysfs-driver-ufs index 929460738651..ec3a7149ced5 100644 --- a/Documentation/ABI/testing/sysfs-driver-ufs +++ b/Documentation/ABI/testing/sysfs-driver-ufs @@ -1449,7 +1449,7 @@ Description: This entry shows the maximum HPB data size for using a single HPB The file is read only. -What: /sys/bus/platform/drivers/ufshcd/*/flags/wb_enable +What: /sys/bus/platform/drivers/ufshcd/*/flags/hpb_enable Date: June 2021 Contact: Daejun Park Description: This entry shows the status of HPB. @@ -1460,3 +1460,77 @@ Description: This entry shows the status of HPB. == ============================ The file is read only. + +What: /sys/class/scsi_device/*/device/hpb_param_sysfs/activation_thld +Date: February 2021 +Contact: Avri Altman +Description: In host control mode, reads are the major source of activation + trials. Once this threshold hs met, the region is added to the + "to-be-activated" list. Since we reset the read counter upon + write, this include sending a rb command updating the region + ppn as well. + +What: /sys/class/scsi_device/*/device/hpb_param_sysfs/normalization_factor +Date: February 2021 +Contact: Avri Altman +Description: In host control mode, we think of the regions as "buckets". + Those buckets are being filled with reads, and emptied on write. + We use entries_per_srgn - the amount of blocks in a subregion as + our bucket size. This applies because HPB1.0 only handles + single-block reads. Once the bucket size is crossed, we trigger + a normalization work - not only to avoid overflow, but mainly + because we want to keep those counters normalized, as we are + using those reads as a comparative score, to make various decisions. + The normalization is dividing (shift right) the read counter by + the normalization_factor. If during consecutive normalizations + an active region has exhausted its reads - inactivate it. + +What: /sys/class/scsi_device/*/device/hpb_param_sysfs/eviction_thld_enter +Date: February 2021 +Contact: Avri Altman +Description: Region deactivation is often due to the fact that eviction took + place: A region becomes active at the expense of another. This is + happening when the max-active-regions limit has been crossed. + In host mode, eviction is considered an extreme measure. We + want to verify that the entering region has enough reads, and + the exiting region has much fewer reads. eviction_thld_enter is + the min reads that a region must have in order to be considered + a candidate for evicting another region. + +What: /sys/class/scsi_device/*/device/hpb_param_sysfs/eviction_thld_exit +Date: February 2021 +Contact: Avri Altman +Description: Same as above for the exiting region. A region is considered to + be a candidate for eviction only if it has fewer reads than + eviction_thld_exit. + +What: /sys/class/scsi_device/*/device/hpb_param_sysfs/read_timeout_ms +Date: February 2021 +Contact: Avri Altman +Description: In order not to hang on to "cold" regions, we inactivate + a region that has no READ access for a predefined amount of + time - read_timeout_ms. If read_timeout_ms has expired, and the + region is dirty, it is less likely that we can make any use of + HPB reading it so we inactivate it. Still, deactivation has + its overhead, and we may still benefit from HPB reading this + region if it is clean - see read_timeout_expiries. + +What: /sys/class/scsi_device/*/device/hpb_param_sysfs/read_timeout_expiries +Date: February 2021 +Contact: Avri Altman +Description: If the region read timeout has expired, but the region is clean, + just re-wind its timer for another spin. Do that as long as it + is clean and did not exhaust its read_timeout_expiries threshold. + +What: /sys/class/scsi_device/*/device/hpb_param_sysfs/timeout_polling_interval_ms +Date: February 2021 +Contact: Avri Altman +Description: The frequency with which the delayed worker that checks the + read_timeouts is awakened. + +What: /sys/class/scsi_device/*/device/hpb_param_sysfs/inflight_map_req +Date: February 2021 +Contact: Avri Altman +Description: In host control mode the host is the originator of map requests. + To avoid flooding the device with map requests, use a simple throttling + mechanism that limits the number of inflight map requests. -- cgit v1.2.3 From a39978ed6df1bc0b29bc6820e8878b49e428426b Mon Sep 17 00:00:00 2001 From: Takashi Iwai Date: Thu, 29 Jul 2021 09:44:04 +0200 Subject: ALSA: doc: Add the description of quirk_flags option for snd-usb-audio Just briefly described about the new option. Link: https://lore.kernel.org/r/20210729074404.19728-6-tiwai@suse.de Signed-off-by: Takashi Iwai --- Documentation/sound/alsa-configuration.rst | 26 ++++++++++++++++++++++++-- 1 file changed, 24 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/sound/alsa-configuration.rst b/Documentation/sound/alsa-configuration.rst index b36af65a08ed..f148b58502c0 100644 --- a/Documentation/sound/alsa-configuration.rst +++ b/Documentation/sound/alsa-configuration.rst @@ -2252,6 +2252,25 @@ delayed_register The driver prints a message like "Found post-registration device assignment: 1234abcd:04" for such a device, so that user can notice the need. +quirk_flags + Contains the bit flags for various device specific workarounds. + Applied to the corresponding card index. + * bit 0: Skip reading sample rate for devices + * bit 1: Create Media Controller API entries + * bit 2: Allow alignment on audio sub-slot at transfer + * bit 3: Add length specifier to transfers + * bit 4: Start playback stream at first in implement feedback mode + * bit 5: Skip clock selector setup + * bit 6: Ignore errors from clock source search + * bit 7: Indicates ITF-USB DSD based DACs + * bit 8: Add a delay of 20ms at each control message handling + * bit 9: Add a delay of 1-2ms at each control message handling + * bit 10: Add a delay of 5-6ms at each control message handling + * bit 11: Add a delay of 50ms at each interface setup + * bit 12: Perform sample rate validations at probe + * bit 13: Disable runtime PM autosuspend + * bit 14: Ignore errors for mixer access + * bit 15: Support generic DSD raw U32_BE format This module supports multiple devices, autoprobe and hotplugging. @@ -2261,11 +2280,14 @@ check. NB: ``ignore_ctl_error=1`` may help when you get an error at accessing the mixer element such as URB error -22. This happens on some -buggy USB device or the controller. +buggy USB device or the controller. This workaround corresponds to +the ``quirk_flags`` bit 14, too. -NB: quirk_alias option is provided only for testing / development. +NB: ``quirk_alias`` option is provided only for testing / development. If you want to have a proper support, contact to upstream for adding the matching quirk in the driver code statically. +Ditto for ``quirk_flags``. If a device is known to require specific +workarounds, please report to the upstream. Module snd-usb-caiaq -------------------- -- cgit v1.2.3 From 614e1bb5305e82f968306bcf63be01693ac82a1f Mon Sep 17 00:00:00 2001 From: Andre Przywara Date: Mon, 2 Aug 2021 01:39:42 +0100 Subject: dt-bindings: mfd: axp20x: Add AXP305 compatible (plus optional IRQ) The AXP305 PMIC used on many boards with the H616 SoC seems to be fully compatible to the AXP805 PMIC, so add the proper chain of compatible strings. Also at least on one board (Orangepi Zero2) there is no interrupt line connected to the CPU, so make the "interrupts" property optional. Signed-off-by: Andre Przywara Acked-by: Rob Herring Signed-off-by: Lee Jones --- Documentation/devicetree/bindings/mfd/axp20x.txt | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mfd/axp20x.txt b/Documentation/devicetree/bindings/mfd/axp20x.txt index 4991a6415796..2b53dcc0ea61 100644 --- a/Documentation/devicetree/bindings/mfd/axp20x.txt +++ b/Documentation/devicetree/bindings/mfd/axp20x.txt @@ -26,10 +26,10 @@ Required properties: * "x-powers,axp803" * "x-powers,axp806" * "x-powers,axp805", "x-powers,axp806" + * "x-powers,axp305", "x-powers,axp805", "x-powers,axp806" * "x-powers,axp809" * "x-powers,axp813" - reg: The I2C slave address or RSB hardware address for the AXP chip -- interrupts: SoC NMI / GPIO interrupt connected to the PMIC's IRQ pin - interrupt-controller: The PMIC has its own internal IRQs - #interrupt-cells: Should be set to 1 @@ -43,6 +43,7 @@ more information: AXP20x/LDO3: software-based implementation Optional properties: +- interrupts: SoC NMI / GPIO interrupt connected to the PMIC's IRQ pin - x-powers,dcdc-freq: defines the work frequency of DC-DC in KHz AXP152/20X: range: 750-1875, Default: 1.5 MHz AXP22X/8XX: range: 1800-4050, Default: 3 MHz -- cgit v1.2.3 From a8caaa239c60ad735b92fb2e8147c8c095181afb Mon Sep 17 00:00:00 2001 From: Mark Brown Date: Tue, 20 Jul 2021 21:42:20 +0100 Subject: arm64/sme: Document boot requirements for SME Document our requirements for initialisation of the Scalable Matrix Extension (SME) at kernel start. While we do have the ability to handle mismatched vector lengths we will reject any late CPUs that can't support the minimum set we determine at boot so for clarity we document a requirement that all CPUs make the same vector length available. Signed-off-by: Mark Brown Link: https://lore.kernel.org/r/20210720204220.22951-1-broonie@kernel.org Signed-off-by: Catalin Marinas --- Documentation/arm64/booting.rst | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+) (limited to 'Documentation') diff --git a/Documentation/arm64/booting.rst b/Documentation/arm64/booting.rst index a9192e7a231b..5822d6da9fa6 100644 --- a/Documentation/arm64/booting.rst +++ b/Documentation/arm64/booting.rst @@ -311,6 +311,28 @@ Before jumping into the kernel, the following conditions must be met: - ZCR_EL2.LEN must be initialised to the same value for all CPUs the kernel will execute on. + For CPUs with the Scalable Matrix Extension (FEAT_SME): + + - If EL3 is present: + + - CPTR_EL3.ESM (bit 12) must be initialised to 0b1. + + - SCR_EL3.EnTP2 (bit 41) must be initialised to 0b1. + + - SMCR_EL3.LEN must be initialised to the same value for all CPUs the + kernel will execute on. + + - If the kernel is entered at EL1 and EL2 is present: + + - CPTR_EL2.TSM (bit 12) must be initialised to 0b0. + + - CPTR_EL2.SMEN (bits 25:24) must be initialised to 0b11. + + - SCTLR_EL2.EnTP2 (bit 60) must be initialised to 0b1. + + - SMCR_EL2.LEN must be initialised to the same value for all CPUs the + kernel will execute on. + The requirements described above for CPU mode, caches, MMUs, architected timers, coherency and system registers apply to all CPUs. All CPUs must enter the kernel in the same exception level. Where the values documented -- cgit v1.2.3 From 6e5b47a4f1dde38d42b054cc6d16b6840de08bd2 Mon Sep 17 00:00:00 2001 From: Simon Ser Date: Mon, 2 Aug 2021 07:28:35 +0000 Subject: drm: document drm_mode_get_property It's not obvious what the fields mean and how they should be used. The most important detail is the link to drm_property.flags, which describes how property types work. v2: document enum drm_mode_property_enum, add ref to "Modeset Base Object Abstraction" (Daniel) Signed-off-by: Simon Ser Acked-by: Pekka Paalanen Acked-by: Daniel Vetter Cc: Leandro Ribeiro Link: https://patchwork.freedesktop.org/patch/msgid/20210802072826.500078-1-contact@emersion.fr --- Documentation/gpu/drm-kms.rst | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst index 0cc21f6aaef5..1ef7951ded5e 100644 --- a/Documentation/gpu/drm-kms.rst +++ b/Documentation/gpu/drm-kms.rst @@ -159,6 +159,8 @@ KMS Core Structures and Functions .. kernel-doc:: drivers/gpu/drm/drm_mode_config.c :export: +.. _kms_base_object_abstraction: + Modeset Base Object Abstraction =============================== -- cgit v1.2.3 From 66e0da21728343bd3e75230a53d909e045fb9dd7 Mon Sep 17 00:00:00 2001 From: Jakub Kicinski Date: Sat, 31 Jul 2021 07:40:07 -0700 Subject: docs: operstates: fix typo TVL -> TLV Signed-off-by: Jakub Kicinski Signed-off-by: David S. Miller --- Documentation/networking/operstates.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/networking/operstates.rst b/Documentation/networking/operstates.rst index 9c918f7cb0e8..f6b9cce5b201 100644 --- a/Documentation/networking/operstates.rst +++ b/Documentation/networking/operstates.rst @@ -111,7 +111,7 @@ it as lower layer. Note that for certain kind of soft-devices, which are not managing any real hardware, it is possible to set this bit from userspace. One -should use TVL IFLA_CARRIER to do so. +should use TLV IFLA_CARRIER to do so. netif_carrier_ok() can be used to query that bit. -- cgit v1.2.3 From 7a7b8635b622add64d98cff84bf3ee71eac36237 Mon Sep 17 00:00:00 2001 From: Jakub Kicinski Date: Sat, 31 Jul 2021 07:40:52 -0700 Subject: docs: operstates: document IF_OPER_TESTING IF_OPER_TESTING is in fact used today. Signed-off-by: Jakub Kicinski Reviewed-by: Andrew Lunn Signed-off-by: David S. Miller --- Documentation/networking/operstates.rst | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/networking/operstates.rst b/Documentation/networking/operstates.rst index f6b9cce5b201..1ee2141e8ef1 100644 --- a/Documentation/networking/operstates.rst +++ b/Documentation/networking/operstates.rst @@ -73,7 +73,9 @@ IF_OPER_LOWERLAYERDOWN (3): state (f.e. VLAN). IF_OPER_TESTING (4): - Unused in current kernel. + Interface is in testing mode, for example executing driver self-tests + or media (cable) test. It can't be used for normal traffic until tests + complete. IF_OPER_DORMANT (5): Interface is L1 up, but waiting for an external event, f.e. for a -- cgit v1.2.3 From 13927b31b13f3c6556221eff3487247bd3c7a245 Mon Sep 17 00:00:00 2001 From: Matteo Croce Date: Tue, 13 Jul 2021 01:05:28 +0200 Subject: block: export diskseq in sysfs Add a new sysfs handle to export the new diskseq value. Place it in /block//diskseq and document it. $ grep . /sys/class/block/*/diskseq /sys/class/block/loop0/diskseq:13 /sys/class/block/loop1/diskseq:14 /sys/class/block/loop2/diskseq:5 /sys/class/block/loop3/diskseq:6 /sys/class/block/ram0/diskseq:1 /sys/class/block/ram1/diskseq:2 /sys/class/block/vda/diskseq:7 Reviewed-by: Christoph Hellwig Signed-off-by: Matteo Croce Tested-by: Luca Boccassi Link: https://lore.kernel.org/r/20210712230530.29323-5-mcroce@linux.microsoft.com Signed-off-by: Jens Axboe --- Documentation/ABI/testing/sysfs-block | 12 ++++++++++++ 1 file changed, 12 insertions(+) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-block b/Documentation/ABI/testing/sysfs-block index e34cdeeeb9d4..a0ed87386639 100644 --- a/Documentation/ABI/testing/sysfs-block +++ b/Documentation/ABI/testing/sysfs-block @@ -28,6 +28,18 @@ Description: For more details refer Documentation/admin-guide/iostats.rst +What: /sys/block//diskseq +Date: February 2021 +Contact: Matteo Croce +Description: + The /sys/block//diskseq files reports the disk + sequence number, which is a monotonically increasing + number assigned to every drive. + Some devices, like the loop device, refresh such number + every time the backing file is changed. + The value type is 64 bit unsigned. + + What: /sys/block///stat Date: February 2008 Contact: Jerome Marchand -- cgit v1.2.3 From 1dbd981fcf2a4498bbf66b55b830ca0aadff9476 Mon Sep 17 00:00:00 2001 From: Biju Das Date: Tue, 27 Jul 2021 13:34:50 +0100 Subject: dt-bindings: net: renesas,etheravb: Document Gigabit Ethernet IP Document Gigabit Ethernet IP found on RZ/G2L SoC. Gigabit Ethernet Interface includes Ethernet controller (E-MAC), Internal TCP/IP Offload Engine (TOE) and Dedicated Direct memory access controller (DMAC) for transferring transmitted Ethernet frames to and received Ethernet frames from respective storage areas in the URAM at high speed. Signed-off-by: Biju Das Reviewed-by: Lad Prabhakar Link: https://lore.kernel.org/r/20210727123450.15918-1-biju.das.jz@bp.renesas.com Signed-off-by: Rob Herring --- .../devicetree/bindings/net/renesas,etheravb.yaml | 57 +++++++++++++++++----- 1 file changed, 45 insertions(+), 12 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/renesas,etheravb.yaml b/Documentation/devicetree/bindings/net/renesas,etheravb.yaml index 005868f703a6..5e12a759004f 100644 --- a/Documentation/devicetree/bindings/net/renesas,etheravb.yaml +++ b/Documentation/devicetree/bindings/net/renesas,etheravb.yaml @@ -43,23 +43,20 @@ properties: - renesas,etheravb-r8a779a0 # R-Car V3U - const: renesas,etheravb-rcar-gen3 # R-Car Gen3 and RZ/G2 + - items: + - enum: + - renesas,r9a07g044-gbeth # RZ/G2{L,LC} + - const: renesas,rzg2l-gbeth # RZ/G2L + reg: true interrupts: true interrupt-names: true - clocks: - minItems: 1 - items: - - description: AVB functional clock - - description: Optional TXC reference clock + clocks: true - clock-names: - minItems: 1 - items: - - const: fck - - const: refclk + clock-names: true iommus: maxItems: 1 @@ -145,14 +142,20 @@ allOf: properties: compatible: contains: - const: renesas,etheravb-rcar-gen2 + enum: + - renesas,etheravb-rcar-gen2 + - renesas,rzg2l-gbeth then: properties: interrupts: - maxItems: 1 + minItems: 1 + maxItems: 3 interrupt-names: + minItems: 1 items: - const: mux + - const: int_fil_n + - const: int_arp_ns_n rx-internal-delay-ps: false else: properties: @@ -208,6 +211,36 @@ allOf: tx-internal-delay-ps: const: 2000 + - if: + properties: + compatible: + contains: + const: renesas,rzg2l-gbeth + then: + properties: + clocks: + items: + - description: Main clock + - description: Register access clock + - description: Reference clock for RGMII + clock-names: + items: + - const: axi + - const: chi + - const: refclk + else: + properties: + clocks: + minItems: 1 + items: + - description: AVB functional clock + - description: Optional TXC reference clock + clock-names: + minItems: 1 + items: + - const: fck + - const: refclk + additionalProperties: false examples: -- cgit v1.2.3 From dbe60e5d7f15454ecc9c7d93dce6240fdaa70da9 Mon Sep 17 00:00:00 2001 From: Geert Uytterhoeven Date: Tue, 27 Jul 2021 18:01:05 +0200 Subject: dt-bindings: memory: renesas,rpc-if: Miscellaneous improvements - Fix rejection of legitimate flash subnodes containing multiple compatible values, - Add missing list of required properties. Signed-off-by: Geert Uytterhoeven Link: https://lore.kernel.org/r/d81b59a513c2a5204c8378b4a89cd07f97c46797.1627401508.git.geert+renesas@glider.be Signed-off-by: Rob Herring --- .../bindings/memory-controllers/renesas,rpc-if.yaml | 17 ++++++++++++++--- 1 file changed, 14 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/memory-controllers/renesas,rpc-if.yaml b/Documentation/devicetree/bindings/memory-controllers/renesas,rpc-if.yaml index 990489fdd2ac..d25072c414e4 100644 --- a/Documentation/devicetree/bindings/memory-controllers/renesas,rpc-if.yaml +++ b/Documentation/devicetree/bindings/memory-controllers/renesas,rpc-if.yaml @@ -61,12 +61,23 @@ patternProperties: type: object properties: compatible: - enum: - - cfi-flash - - jedec,spi-nor + contains: + enum: + - cfi-flash + - jedec,spi-nor unevaluatedProperties: false +required: + - compatible + - reg + - reg-names + - clocks + - power-domains + - resets + - '#address-cells' + - '#size-cells' + examples: - | #include -- cgit v1.2.3 From 9c4073782cb17898d740dc618338fb6043e43721 Mon Sep 17 00:00:00 2001 From: Geert Uytterhoeven Date: Tue, 27 Jul 2021 18:10:34 +0200 Subject: dt-bindings: auxdisplay: img-ascii-lcd: Convert to json-schema Convert the Device Tree binding documentation for ASCII LCD displays on Imagination Technologies boards to json-schema. Drop bogus regmap property. Add example. Signed-off-by: Geert Uytterhoeven Link: https://lore.kernel.org/r/6e74aa466d39ddc9abe502e054d04e8cc7b76b40.1627402094.git.geert@linux-m68k.org [robh: add type to 'offset'] Signed-off-by: Rob Herring --- .../bindings/auxdisplay/img,ascii-lcd.yaml | 55 ++++++++++++++++++++++ .../bindings/auxdisplay/img-ascii-lcd.txt | 17 ------- 2 files changed, 55 insertions(+), 17 deletions(-) create mode 100644 Documentation/devicetree/bindings/auxdisplay/img,ascii-lcd.yaml delete mode 100644 Documentation/devicetree/bindings/auxdisplay/img-ascii-lcd.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/auxdisplay/img,ascii-lcd.yaml b/Documentation/devicetree/bindings/auxdisplay/img,ascii-lcd.yaml new file mode 100644 index 000000000000..1899b23de7d1 --- /dev/null +++ b/Documentation/devicetree/bindings/auxdisplay/img,ascii-lcd.yaml @@ -0,0 +1,55 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/auxdisplay/img,ascii-lcd.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: ASCII LCD displays on Imagination Technologies boards + +maintainers: + - Paul Burton + +properties: + compatible: + enum: + - img,boston-lcd + - mti,malta-lcd + - mti,sead3-lcd + + reg: + maxItems: 1 + + offset: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + Offset in bytes to the LCD registers within the system controller + +required: + - compatible + +oneOf: + - required: + - reg + - required: + - offset + +if: + properties: + compatible: + contains: + const: img,boston-lcd +then: + required: + - reg +else: + required: + - offset + +additionalProperties: false + +examples: + - | + lcd: lcd@17fff000 { + compatible = "img,boston-lcd"; + reg = <0x17fff000 0x8>; + }; diff --git a/Documentation/devicetree/bindings/auxdisplay/img-ascii-lcd.txt b/Documentation/devicetree/bindings/auxdisplay/img-ascii-lcd.txt deleted file mode 100644 index b69bb68992fd..000000000000 --- a/Documentation/devicetree/bindings/auxdisplay/img-ascii-lcd.txt +++ /dev/null @@ -1,17 +0,0 @@ -Binding for ASCII LCD displays on Imagination Technologies boards - -Required properties: -- compatible : should be one of: - "img,boston-lcd" - "mti,malta-lcd" - "mti,sead3-lcd" - -Required properties for "img,boston-lcd": -- reg : memory region locating the device registers - -Required properties for "mti,malta-lcd" or "mti,sead3-lcd": -- regmap: phandle of the system controller containing the LCD registers -- offset: offset in bytes to the LCD registers within the system controller - -The layout of the registers & properties of the display are determined -from the compatible string, making this binding somewhat trivial. -- cgit v1.2.3 From 869ab62c2bd734d356e67ebc63ec8f364c452bb6 Mon Sep 17 00:00:00 2001 From: Geert Uytterhoeven Date: Tue, 27 Jul 2021 18:11:41 +0200 Subject: dt-bindings: auxdisplay: arm-charlcd: Convert to json-schema Convert the ARM Versatile Character LCD Device Tree binding documentation to json-schema. Correct compatible value. Document missing properties. Signed-off-by: Geert Uytterhoeven Link: https://lore.kernel.org/r/4a63caa4136e8a31e82c7d75bb6f273498e8cccf.1627402256.git.geert@linux-m68k.org Signed-off-by: Rob Herring --- .../bindings/auxdisplay/arm,versatile-lcd.yaml | 44 ++++++++++++++++++++++ .../devicetree/bindings/auxdisplay/arm-charlcd.txt | 18 --------- 2 files changed, 44 insertions(+), 18 deletions(-) create mode 100644 Documentation/devicetree/bindings/auxdisplay/arm,versatile-lcd.yaml delete mode 100644 Documentation/devicetree/bindings/auxdisplay/arm-charlcd.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/auxdisplay/arm,versatile-lcd.yaml b/Documentation/devicetree/bindings/auxdisplay/arm,versatile-lcd.yaml new file mode 100644 index 000000000000..5d02bd032a85 --- /dev/null +++ b/Documentation/devicetree/bindings/auxdisplay/arm,versatile-lcd.yaml @@ -0,0 +1,44 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/auxdisplay/arm,versatile-lcd.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: ARM Versatile Character LCD + +maintainers: + - Linus Walleij + - Rob Herring + +description: + This binding defines the character LCD interface found on ARM Versatile AB + and PB reference platforms. + +properties: + compatible: + const: arm,versatile-lcd + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + + clock-names: + maxItems: 1 + + interrupts: + maxItems: 1 + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + lcd@10008000 { + compatible = "arm,versatile-lcd"; + reg = <0x10008000 0x1000>; + }; diff --git a/Documentation/devicetree/bindings/auxdisplay/arm-charlcd.txt b/Documentation/devicetree/bindings/auxdisplay/arm-charlcd.txt deleted file mode 100644 index e28e2aac47f1..000000000000 --- a/Documentation/devicetree/bindings/auxdisplay/arm-charlcd.txt +++ /dev/null @@ -1,18 +0,0 @@ -ARM Versatile Character LCD ------------------------------------------------------ -This binding defines the character LCD interface found on ARM Versatile AB -and PB reference platforms. - -Required properties: -- compatible : "arm,versatile-clcd" -- reg : Location and size of character LCD registers - -Optional properties: -- interrupts - single interrupt for character LCD. The character LCD can - operate in polled mode without an interrupt. - -Example: - lcd@10008000 { - compatible = "arm,versatile-lcd"; - reg = <0x10008000 0x1000>; - }; -- cgit v1.2.3 From d08d29c8041b4306d35888eb5b920bb70ae859e3 Mon Sep 17 00:00:00 2001 From: Baisheng Gao Date: Thu, 29 Jul 2021 00:01:26 +0800 Subject: Documentation: fix incorrect macro referencing in mscc-phy-vsc8531.txt Modify LINK_1000_ACTIVITY and LINK_100_ACTIVITY to VSC8531_LINK_1000_ACTIVITY and VSC8531_LINK_100_ACTIVITY respectively in the example of ethernet-phy node according to include/dt-bindings/net/mscc-phy-vsc8531.h. Signed-off-by: Baisheng Gao Link: https://lore.kernel.org/r/1627488086-200263-1-git-send-email-gaobaisheng@bonc.com.cn Signed-off-by: Rob Herring --- Documentation/devicetree/bindings/net/mscc-phy-vsc8531.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/mscc-phy-vsc8531.txt b/Documentation/devicetree/bindings/net/mscc-phy-vsc8531.txt index 87a27d775d48..0a3647fe331b 100644 --- a/Documentation/devicetree/bindings/net/mscc-phy-vsc8531.txt +++ b/Documentation/devicetree/bindings/net/mscc-phy-vsc8531.txt @@ -67,7 +67,7 @@ Example: compatible = "ethernet-phy-id0007.0570"; vsc8531,vddmac = <3300>; vsc8531,edge-slowdown = <7>; - vsc8531,led-0-mode = ; - vsc8531,led-1-mode = ; + vsc8531,led-0-mode = ; + vsc8531,led-1-mode = ; load-save-gpios = <&gpio 10 GPIO_ACTIVE_HIGH>; }; -- cgit v1.2.3 From 85aef2b218c85991479cfbb0c4c1dab84c30fec2 Mon Sep 17 00:00:00 2001 From: Steven Lee Date: Mon, 12 Jul 2021 18:03:08 +0800 Subject: dt-bindings: aspeed-sgpio: Convert txt bindings to yaml. sgpio-aspeed bindings should be converted to yaml format. Signed-off-by: Steven Lee Reviewed-by: Rob Herring Reviewed-by: Linus Walleij Link: https://lore.kernel.org/r/20210712100317.23298-2-steven_lee@aspeedtech.com Signed-off-by: Joel Stanley --- .../devicetree/bindings/gpio/aspeed,sgpio.yaml | 75 ++++++++++++++++++++++ .../devicetree/bindings/gpio/sgpio-aspeed.txt | 46 ------------- 2 files changed, 75 insertions(+), 46 deletions(-) create mode 100644 Documentation/devicetree/bindings/gpio/aspeed,sgpio.yaml delete mode 100644 Documentation/devicetree/bindings/gpio/sgpio-aspeed.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/gpio/aspeed,sgpio.yaml b/Documentation/devicetree/bindings/gpio/aspeed,sgpio.yaml new file mode 100644 index 000000000000..b2ae211411ff --- /dev/null +++ b/Documentation/devicetree/bindings/gpio/aspeed,sgpio.yaml @@ -0,0 +1,75 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/gpio/aspeed,sgpio.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Aspeed SGPIO controller + +maintainers: + - Andrew Jeffery + +description: + This SGPIO controller is for ASPEED AST2500 SoC, it supports up to 80 full + featured Serial GPIOs. Each of the Serial GPIO pins can be programmed to + support the following options + - Support interrupt option for each input port and various interrupt + sensitivity option (level-high, level-low, edge-high, edge-low) + - Support reset tolerance option for each output port + - Directly connected to APB bus and its shift clock is from APB bus clock + divided by a programmable value. + - Co-work with external signal-chained TTL components (74LV165/74LV595) + +properties: + compatible: + enum: + - aspeed,ast2400-sgpio + - aspeed,ast2500-sgpio + + reg: + maxItems: 1 + + gpio-controller: true + + '#gpio-cells': + const: 2 + + interrupts: + maxItems: 1 + + interrupt-controller: true + + clocks: + maxItems: 1 + + ngpios: true + + bus-frequency: true + +required: + - compatible + - reg + - gpio-controller + - '#gpio-cells' + - interrupts + - interrupt-controller + - ngpios + - clocks + - bus-frequency + +additionalProperties: false + +examples: + - | + #include + sgpio: sgpio@1e780200 { + #gpio-cells = <2>; + compatible = "aspeed,ast2500-sgpio"; + gpio-controller; + interrupts = <40>; + reg = <0x1e780200 0x0100>; + clocks = <&syscon ASPEED_CLK_APB>; + interrupt-controller; + ngpios = <80>; + bus-frequency = <12000000>; + }; diff --git a/Documentation/devicetree/bindings/gpio/sgpio-aspeed.txt b/Documentation/devicetree/bindings/gpio/sgpio-aspeed.txt deleted file mode 100644 index be329ea4794f..000000000000 --- a/Documentation/devicetree/bindings/gpio/sgpio-aspeed.txt +++ /dev/null @@ -1,46 +0,0 @@ -Aspeed SGPIO controller Device Tree Bindings --------------------------------------------- - -This SGPIO controller is for ASPEED AST2500 SoC, it supports up to 80 full -featured Serial GPIOs. Each of the Serial GPIO pins can be programmed to -support the following options: -- Support interrupt option for each input port and various interrupt - sensitivity option (level-high, level-low, edge-high, edge-low) -- Support reset tolerance option for each output port -- Directly connected to APB bus and its shift clock is from APB bus clock - divided by a programmable value. -- Co-work with external signal-chained TTL components (74LV165/74LV595) - -Required properties: - -- compatible : Should be one of - "aspeed,ast2400-sgpio", "aspeed,ast2500-sgpio" -- #gpio-cells : Should be 2, see gpio.txt -- reg : Address and length of the register set for the device -- gpio-controller : Marks the device node as a GPIO controller -- interrupts : Interrupt specifier, see interrupt-controller/interrupts.txt -- interrupt-controller : Mark the GPIO controller as an interrupt-controller -- ngpios : number of *hardware* GPIO lines, see gpio.txt. This will expose - 2 software GPIOs per hardware GPIO: one for hardware input, one for hardware - output. Up to 80 pins, must be a multiple of 8. -- clocks : A phandle to the APB clock for SGPM clock division -- bus-frequency : SGPM CLK frequency - -The sgpio and interrupt properties are further described in their respective -bindings documentation: - -- Documentation/devicetree/bindings/gpio/gpio.txt -- Documentation/devicetree/bindings/interrupt-controller/interrupts.txt - - Example: - sgpio: sgpio@1e780200 { - #gpio-cells = <2>; - compatible = "aspeed,ast2500-sgpio"; - gpio-controller; - interrupts = <40>; - reg = <0x1e780200 0x0100>; - clocks = <&syscon ASPEED_CLK_APB>; - interrupt-controller; - ngpios = <8>; - bus-frequency = <12000000>; - }; -- cgit v1.2.3 From 0ffbfcbc273ef3f290c835ad1781c4f9a58d5090 Mon Sep 17 00:00:00 2001 From: Steven Lee Date: Mon, 12 Jul 2021 18:03:09 +0800 Subject: dt-bindings: aspeed-sgpio: Add ast2600 sgpio AST2600 SoC has 2 SGPIO master interfaces one with 128 pins another one with 80 pins. Add ast2600-sgpiom compatibles and update descriptions to introduce the max number of available gpio pins that AST2600 supported. Signed-off-by: Steven Lee Reviewed-by: Linus Walleij Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20210712100317.23298-3-steven_lee@aspeedtech.com Signed-off-by: Joel Stanley --- Documentation/devicetree/bindings/gpio/aspeed,sgpio.yaml | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/gpio/aspeed,sgpio.yaml b/Documentation/devicetree/bindings/gpio/aspeed,sgpio.yaml index b2ae211411ff..46bb121360dc 100644 --- a/Documentation/devicetree/bindings/gpio/aspeed,sgpio.yaml +++ b/Documentation/devicetree/bindings/gpio/aspeed,sgpio.yaml @@ -10,9 +10,10 @@ maintainers: - Andrew Jeffery description: - This SGPIO controller is for ASPEED AST2500 SoC, it supports up to 80 full - featured Serial GPIOs. Each of the Serial GPIO pins can be programmed to - support the following options + This SGPIO controller is for ASPEED AST2400, AST2500 and AST2600 SoC, + AST2600 have two sgpio master one with 128 pins another one with 80 pins, + AST2500/AST2400 have one sgpio master with 80 pins. Each of the Serial + GPIO pins can be programmed to support the following options - Support interrupt option for each input port and various interrupt sensitivity option (level-high, level-low, edge-high, edge-low) - Support reset tolerance option for each output port @@ -25,6 +26,7 @@ properties: enum: - aspeed,ast2400-sgpio - aspeed,ast2500-sgpio + - aspeed,ast2600-sgpiom reg: maxItems: 1 -- cgit v1.2.3 From 52ac8b358b0cb7e91c966225fca61be5d1c984bc Mon Sep 17 00:00:00 2001 From: Paolo Bonzini Date: Thu, 27 May 2021 08:09:15 -0400 Subject: KVM: Block memslot updates across range_start() and range_end() We would like to avoid taking mmu_lock for .invalidate_range_{start,end}() notifications that are unrelated to KVM. Because mmu_notifier_count must be modified while holding mmu_lock for write, and must always be paired across start->end to stay balanced, lock elision must happen in both or none. Therefore, in preparation for this change, this patch prevents memslot updates across range_start() and range_end(). Note, technically flag-only memslot updates could be allowed in parallel, but stalling a memslot update for a relatively short amount of time is not a scalability issue, and this is all more than complex enough. A long note on the locking: a previous version of the patch used an rwsem to block the memslot update while the MMU notifier run, but this resulted in the following deadlock involving the pseudo-lock tagged as "mmu_notifier_invalidate_range_start". ====================================================== WARNING: possible circular locking dependency detected 5.12.0-rc3+ #6 Tainted: G OE ------------------------------------------------------ qemu-system-x86/3069 is trying to acquire lock: ffffffff9c775ca0 (mmu_notifier_invalidate_range_start){+.+.}-{0:0}, at: __mmu_notifier_invalidate_range_end+0x5/0x190 but task is already holding lock: ffffaff7410a9160 (&kvm->mmu_notifier_slots_lock){.+.+}-{3:3}, at: kvm_mmu_notifier_invalidate_range_start+0x36d/0x4f0 [kvm] which lock already depends on the new lock. This corresponds to the following MMU notifier logic: invalidate_range_start take pseudo lock down_read() (*) release pseudo lock invalidate_range_end take pseudo lock (**) up_read() release pseudo lock At point (*) we take the mmu_notifiers_slots_lock inside the pseudo lock; at point (**) we take the pseudo lock inside the mmu_notifiers_slots_lock. This could cause a deadlock (ignoring for a second that the pseudo lock is not a lock): - invalidate_range_start waits on down_read(), because the rwsem is held by install_new_memslots - install_new_memslots waits on down_write(), because the rwsem is held till (another) invalidate_range_end finishes - invalidate_range_end sits waits on the pseudo lock, held by invalidate_range_start. Removing the fairness of the rwsem breaks the cycle (in lockdep terms, it would change the *shared* rwsem readers into *shared recursive* readers), so open-code the wait using a readers count and a spinlock. This also allows handling blockable and non-blockable critical section in the same way. Losing the rwsem fairness does theoretically allow MMU notifiers to block install_new_memslots forever. Note that mm/mmu_notifier.c's own retry scheme in mmu_interval_read_begin also uses wait/wake_up and is likewise not fair. Signed-off-by: Paolo Bonzini --- Documentation/virt/kvm/locking.rst | 6 ++++++ 1 file changed, 6 insertions(+) (limited to 'Documentation') diff --git a/Documentation/virt/kvm/locking.rst b/Documentation/virt/kvm/locking.rst index 35eca377543d..8138201efb09 100644 --- a/Documentation/virt/kvm/locking.rst +++ b/Documentation/virt/kvm/locking.rst @@ -21,6 +21,12 @@ The acquisition orders for mutexes are as follows: can be taken inside a kvm->srcu read-side critical section, while kvm->slots_lock cannot. +- kvm->mn_active_invalidate_count ensures that pairs of + invalidate_range_start() and invalidate_range_end() callbacks + use the same memslots array. kvm->slots_lock and kvm->slots_arch_lock + are taken on the waiting side in install_new_memslots, so MMU notifiers + must not take either kvm->slots_lock or kvm->slots_arch_lock. + On x86: - vcpu->mutex is taken outside kvm->arch.hyperv.hv_lock -- cgit v1.2.3 From ab09511fb69bdd4c4767053d7766f4bb9d6e36ec Mon Sep 17 00:00:00 2001 From: satya priya Date: Fri, 23 Jul 2021 14:01:12 +0530 Subject: dt-bindings: mfd: pm8008: Add gpio-ranges and spmi-gpio compatible Add gpio-ranges and "qcom,spmi-gpio" compatible to match with the parent qcom,pmic-gpio.yaml binding. Signed-off-by: satya priya Reviewed-by: Rob Herring Reviewed-by: Bjorn Andersson Reviewed-by: Guru Das Srinagesh Signed-off-by: Lee Jones --- Documentation/devicetree/bindings/mfd/qcom,pm8008.yaml | 13 ++++++++++--- 1 file changed, 10 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mfd/qcom,pm8008.yaml b/Documentation/devicetree/bindings/mfd/qcom,pm8008.yaml index 779936850ee0..ec3138c1bbfc 100644 --- a/Documentation/devicetree/bindings/mfd/qcom,pm8008.yaml +++ b/Documentation/devicetree/bindings/mfd/qcom,pm8008.yaml @@ -53,7 +53,9 @@ patternProperties: properties: compatible: - const: qcom,pm8008-gpio + items: + - const: qcom,pm8008-gpio + - const: qcom,spmi-gpio reg: description: Peripheral address of one of the two GPIO peripherals. @@ -61,6 +63,9 @@ patternProperties: gpio-controller: true + gpio-ranges: + maxItems: 1 + interrupt-controller: true "#interrupt-cells": @@ -75,6 +80,7 @@ patternProperties: - gpio-controller - interrupt-controller - "#gpio-cells" + - gpio-ranges - "#interrupt-cells" additionalProperties: false @@ -107,10 +113,11 @@ examples: interrupt-parent = <&tlmm>; interrupts = <32 IRQ_TYPE_EDGE_RISING>; - gpio@c000 { - compatible = "qcom,pm8008-gpio"; + pm8008_gpios: gpio@c000 { + compatible = "qcom,pm8008-gpio", "qcom,spmi-gpio"; reg = <0xc000>; gpio-controller; + gpio-ranges = <&pm8008_gpios 0 0 2>; #gpio-cells = <2>; interrupt-controller; #interrupt-cells = <2>; -- cgit v1.2.3 From 3a755cd8b7c601f756cbbf908b84f7cc8c04a02b Mon Sep 17 00:00:00 2001 From: Hangbin Liu Date: Mon, 2 Aug 2021 11:02:19 +0800 Subject: bonding: add new option lacp_active Add an option lacp_active, which is similar with team's runner.active. This option specifies whether to send LACPDU frames periodically. If set on, the LACPDU frames are sent along with the configured lacp_rate setting. If set off, the LACPDU frames acts as "speak when spoken to". Note, the LACPDU state frames still will be sent when init or unbind port. v2: remove module parameter Signed-off-by: Hangbin Liu Signed-off-by: David S. Miller --- Documentation/networking/bonding.rst | 12 ++++++++++++ 1 file changed, 12 insertions(+) (limited to 'Documentation') diff --git a/Documentation/networking/bonding.rst b/Documentation/networking/bonding.rst index 62f2aab8eaec..31cfd7d674a6 100644 --- a/Documentation/networking/bonding.rst +++ b/Documentation/networking/bonding.rst @@ -501,6 +501,18 @@ fail_over_mac This option was added in bonding version 3.2.0. The "follow" policy was added in bonding version 3.3.0. +lacp_active + Option specifying whether to send LACPDU frames periodically. + + off or 0 + LACPDU frames acts as "speak when spoken to". + + on or 1 + LACPDU frames are sent along the configured links + periodically. See lacp_rate for more details. + + The default is on. + lacp_rate Option specifying the rate in which we'll ask our link partner -- cgit v1.2.3 From 72bcad5393a7079706fcfe02d84ed1599716d6a2 Mon Sep 17 00:00:00 2001 From: Arnd Bergmann Date: Tue, 3 Aug 2021 13:40:49 +0200 Subject: wan: remove sbni/granch driver The driver was merged in 1999 and has only ever seen treewide cleanups since then, with no indication whatsoever that anyone has actually had access to hardware for testing the patches. >From the information in the link below, it appears that the hardware is for some leased line system in Russia that has since been discontinued, and useless without any remote end to connect to. As the driver still feels like a Linux-2.2 era artifact today, it appears that the best way forward is to just delete it. Link: https://www.tms.ru/%D0%90%D0%B4%D0%B0%D0%BF%D1%82%D0%B5%D1%80_%D0%B4%D0%BB%D1%8F_%D0%B2%D1%8B%D0%B4%D0%B5%D0%BB%D0%B5%D0%BD%D0%BD%D1%8B%D1%85_%D0%BB%D0%B8%D0%BD%D0%B8%D0%B9_Granch_SBNI12-10 Signed-off-by: Arnd Bergmann Signed-off-by: David S. Miller --- Documentation/admin-guide/kernel-parameters.txt | 2 -- 1 file changed, 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index bdb22006f713..ee0569a040c6 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -4945,8 +4945,6 @@ sa1100ir [NET] See drivers/net/irda/sa1100_ir.c. - sbni= [NET] Granch SBNI12 leased line adapter - sched_verbose [KNL] Enables verbose scheduler debug messages. schedstats= [KNL,X86] Enable or disable scheduled statistics. -- cgit v1.2.3 From 7a062ce31807eb402c38edbec50c1b848b4298f3 Mon Sep 17 00:00:00 2001 From: Yee Lee Date: Tue, 3 Aug 2021 15:08:22 +0800 Subject: arm64/cpufeature: Optionally disable MTE via command-line MTE support needs to be optionally disabled in runtime for HW issue workaround, FW development and some evaluation works on system resource and performance. This patch makes two changes: (1) moves init of tag-allocation bits(ATA/ATA0) to cpu_enable_mte() as not cached in TLB. (2) allows ID_AA64PFR1_EL1.MTE to be overridden on its shadow value by giving "arm64.nomte" on cmdline. When the feature value is off, ATA and TCF will not set and the related functionalities are accordingly suppressed. Suggested-by: Catalin Marinas Suggested-by: Marc Zyngier Suggested-by: Suzuki K Poulose Signed-off-by: Yee Lee Link: https://lore.kernel.org/r/20210803070824.7586-2-yee.lee@mediatek.com Signed-off-by: Catalin Marinas --- 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 bdb22006f713..6f257e39d89e 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -380,6 +380,9 @@ arm64.nopauth [ARM64] Unconditionally disable Pointer Authentication support + arm64.nomte [ARM64] Unconditionally disable Memory Tagging Extension + support + ataflop= [HW,M68k] atarimouse= [HW,MOUSE] Atari Mouse -- cgit v1.2.3 From 4f993264fe2965c344f223d854ccbb549b16ed71 Mon Sep 17 00:00:00 2001 From: Chao Yu Date: Tue, 3 Aug 2021 08:15:43 +0800 Subject: f2fs: introduce discard_unit mount option As James Z reported in bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=213877 [1.] One-line summary of the problem: Mount multiple SMR block devices exceed certain number cause system non-response [2.] Full description of the problem/report: Created some F2FS on SMR devices (mkfs.f2fs -m), then mounted in sequence. Each device is the same Model: HGST HSH721414AL (Size 14TB). Empirically, found that when the amount of SMR device * 1.5Gb > System RAM, the system ran out of memory and hung. No dmesg output. For example, 24 SMR Disk need 24*1.5GB = 36GB. A system with 32G RAM can only mount 21 devices, the 22nd device will be a reproducible cause of system hang. The number of SMR devices with other FS mounted on this system does not interfere with the result above. [3.] Keywords (i.e., modules, networking, kernel): F2FS, SMR, Memory [4.] Kernel information [4.1.] Kernel version (uname -a): Linux 5.13.4-200.fc34.x86_64 #1 SMP Tue Jul 20 20:27:29 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux [4.2.] Kernel .config file: Default Fedora 34 with f2fs-tools-1.14.0-2.fc34.x86_64 [5.] Most recent kernel version which did not have the bug: None [6.] Output of Oops.. message (if applicable) with symbolic information resolved (see Documentation/admin-guide/oops-tracing.rst) None [7.] A small shell script or example program which triggers the problem (if possible) mount /dev/sdX /mnt/0X [8.] Memory consumption With 24 * 14T SMR Block device with F2FS free -g total used free shared buff/cache available Mem: 46 36 0 0 10 10 Swap: 0 0 0 With 3 * 14T SMR Block device with F2FS free -g total used free shared buff/cache available Mem: 7 5 0 0 1 1 Swap: 7 0 7 The root cause is, there are three bitmaps: - cur_valid_map - ckpt_valid_map - discard_map and each of them will cost ~500MB memory, {cur, ckpt}_valid_map are necessary, but discard_map is optional, since this bitmap will only be useful in mountpoint that small discard is enabled. For a blkzoned device such as SMR or ZNS devices, f2fs will only issue discard for a section(zone) when all blocks of that section are invalid, so, for such device, we don't need small discard functionality at all. This patch introduces a new mountoption "discard_unit=block|segment| section" to support issuing discard with different basic unit which is aligned to block, segment or section, so that user can specify "discard_unit=segment" or "discard_unit=section" to disable small discard functionality. Note that this mount option can not be changed by remount() due to related metadata need to be initialized during mount(). In order to save memory, let's use "discard_unit=section" for blkzoned device by default. Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim --- Documentation/filesystems/f2fs.rst | 8 ++++++++ 1 file changed, 8 insertions(+) (limited to 'Documentation') diff --git a/Documentation/filesystems/f2fs.rst b/Documentation/filesystems/f2fs.rst index ff9e7cc97c65..8f251a662542 100644 --- a/Documentation/filesystems/f2fs.rst +++ b/Documentation/filesystems/f2fs.rst @@ -312,6 +312,14 @@ inlinecrypt When possible, encrypt/decrypt the contents of encrypted Documentation/block/inline-encryption.rst. atgc Enable age-threshold garbage collection, it provides high effectiveness and efficiency on background GC. +discard_unit=%s Control discard unit, the argument can be "block", "segment" + and "section", issued discard command's offset/size will be + aligned to the unit, by default, "discard_unit=block" is set, + so that small discard functionality is enabled. + For blkzoned device, "discard_unit=section" will be set by + default, it is helpful for large sized SMR or ZNS devices to + reduce memory cost by getting rid of fs metadata supports small + discard. ======================== ============================================================ Debugfs Entries -- cgit v1.2.3 From 0f6b56ec958d49e2b3dc955cdac6b62702c04b72 Mon Sep 17 00:00:00 2001 From: Daeho Jeong Date: Mon, 2 Aug 2021 21:22:45 -0700 Subject: f2fs: add sysfs node to control ra_pages for fadvise seq file fadvise() allows the user to expand the readahead window to double with POSIX_FADV_SEQUENTIAL, now. But, in some use cases, it is not that sufficient and we need to meet the need in a restricted way. We can control the multiplier value of bdi device readahead between 2 (default) and 256 for POSIX_FADV_SEQUENTIAL advise option. Signed-off-by: Daeho Jeong Reviewed-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 845c4be535b0..73211f77d11e 100644 --- a/Documentation/ABI/testing/sysfs-fs-f2fs +++ b/Documentation/ABI/testing/sysfs-fs-f2fs @@ -507,3 +507,9 @@ Date: July 2021 Contact: "Daeho Jeong" Description: You can control for which gc mode the "gc_reclaimed_segments" node shows. Refer to the description of the modes in "gc_reclaimed_segments". + +What: /sys/fs/f2fs//seq_file_ra_mul +Date: July 2021 +Contact: "Daeho Jeong" +Description: You can control the multiplier value of bdi device readahead window size + between 2 (default) and 256 for POSIX_FADV_SEQUENTIAL advise option. -- cgit v1.2.3 From a0221a0f9ba5820c4a5c0625f965684c6fe76ad7 Mon Sep 17 00:00:00 2001 From: Alex Elder Date: Mon, 2 Aug 2021 18:30:19 -0500 Subject: Revert "Merge branch 'qcom-dts-updates'" This reverts commit b79c6fba6cd7c49a7dbea9999e182f74cca63e19, reversing these changes made to 0ac26271344478ff718329fa9d4ef81d4bcbc43b: commit 6a0eb6c9d934 ("dt-bindings: net: qcom,ipa: make imem interconnect optional") commit f8bd3c82bf7d ("arm64: dts: qcom: sc7280: add IPA information") commit fd0f72c34bd9 ("arm64: dts: qcom: sc7180: define ipa_fw_mem node") I intend for these commits to go through the Qualcomm repository, to avoid conflicting with other activity being merged there. Signed-off-by: Alex Elder Link: https://lore.kernel.org/r/20210802233019.800250-1-elder@linaro.org Signed-off-by: Jakub Kicinski --- Documentation/devicetree/bindings/net/qcom,ipa.yaml | 18 ++++++++---------- 1 file changed, 8 insertions(+), 10 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/qcom,ipa.yaml b/Documentation/devicetree/bindings/net/qcom,ipa.yaml index 4853ab7017bd..ed88ba4b94df 100644 --- a/Documentation/devicetree/bindings/net/qcom,ipa.yaml +++ b/Documentation/devicetree/bindings/net/qcom,ipa.yaml @@ -87,18 +87,16 @@ properties: - const: ipa-setup-ready interconnects: - minItems: 2 items: - - description: Path leading to system memory - - description: Path between the AP and IPA config space - - description: Path leading to internal memory + - description: Interconnect path between IPA and main memory + - description: Interconnect path between IPA and internal memory + - description: Interconnect path between IPA and the AP subsystem interconnect-names: - minItems: 2 items: - const: memory - - const: config - const: imem + - const: config qcom,smem-states: $ref: /schemas/types.yaml#/definitions/phandle-array @@ -209,11 +207,11 @@ examples: interconnects = <&rsc_hlos MASTER_IPA &rsc_hlos SLAVE_EBI1>, - <&rsc_hlos MASTER_APPSS_PROC &rsc_hlos SLAVE_IPA_CFG>, - <&rsc_hlos MASTER_IPA &rsc_hlos SLAVE_IMEM>; + <&rsc_hlos MASTER_IPA &rsc_hlos SLAVE_IMEM>, + <&rsc_hlos MASTER_APPSS_PROC &rsc_hlos SLAVE_IPA_CFG>; interconnect-names = "memory", - "config", - "imem"; + "imem", + "config"; qcom,smem-states = <&ipa_smp2p_out 0>, <&ipa_smp2p_out 1>; -- cgit v1.2.3 From d85165b2381ce2638cfb8c8787a61b97b38251c2 Mon Sep 17 00:00:00 2001 From: Aswath Govindraju Date: Mon, 2 Aug 2021 14:48:22 +0530 Subject: dt-bindings: net: can: Document power-domains property Document power-domains property for adding the Power domain provider. Link: https://lore.kernel.org/r/20210802091822.16407-1-a-govindraju@ti.com Signed-off-by: Aswath Govindraju Acked-by: Rob Herring Signed-off-by: Marc Kleine-Budde --- Documentation/devicetree/bindings/net/can/bosch,m_can.yaml | 6 ++++++ 1 file changed, 6 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/can/bosch,m_can.yaml b/Documentation/devicetree/bindings/net/can/bosch,m_can.yaml index a7b5807c5543..fb547e26c676 100644 --- a/Documentation/devicetree/bindings/net/can/bosch,m_can.yaml +++ b/Documentation/devicetree/bindings/net/can/bosch,m_can.yaml @@ -104,6 +104,12 @@ properties: maximum: 32 maxItems: 1 + power-domains: + description: + Power domain provider node and an args specifier containing + the can device id value. + maxItems: 1 + can-transceiver: $ref: can-transceiver.yaml# -- cgit v1.2.3 From 3fbcc6763bb2b6410b2051c983275cd99ba1b5f2 Mon Sep 17 00:00:00 2001 From: Linus Walleij Date: Sat, 17 Jul 2021 02:05:25 +0200 Subject: bus: ixp4xx: Add DT bindings for the IXP4xx expansion bus This adds device tree bindings for the IXP4xx expansion bus controller. Cc: Marc Zyngier Cc: devicetree@vger.kernel.org Reviewed-by: Rob Herring Signed-off-by: Linus Walleij --- .../bus/intel,ixp4xx-expansion-bus-controller.yaml | 168 +++++++++++++++++++++ 1 file changed, 168 insertions(+) create mode 100644 Documentation/devicetree/bindings/bus/intel,ixp4xx-expansion-bus-controller.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/bus/intel,ixp4xx-expansion-bus-controller.yaml b/Documentation/devicetree/bindings/bus/intel,ixp4xx-expansion-bus-controller.yaml new file mode 100644 index 000000000000..5fb4e7bfa4da --- /dev/null +++ b/Documentation/devicetree/bindings/bus/intel,ixp4xx-expansion-bus-controller.yaml @@ -0,0 +1,168 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/bus/intel,ixp4xx-expansion-bus-controller.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Intel IXP4xx Expansion Bus Controller + +description: | + The IXP4xx expansion bus controller handles access to devices on the + memory-mapped expansion bus on the Intel IXP4xx family of system on chips, + including IXP42x, IXP43x, IXP45x and IXP46x. + +maintainers: + - Linus Walleij + +properties: + $nodename: + pattern: '^bus@[0-9a-f]+$' + + compatible: + items: + - enum: + - intel,ixp42x-expansion-bus-controller + - intel,ixp43x-expansion-bus-controller + - intel,ixp45x-expansion-bus-controller + - intel,ixp46x-expansion-bus-controller + - const: syscon + + reg: + description: Control registers for the expansion bus, these are not + inside the memory range handled by the expansion bus. + maxItems: 1 + + native-endian: + $ref: /schemas/types.yaml#/definitions/flag + description: The IXP4xx has a peculiar MMIO access scheme, as it changes + the access pattern for words (swizzling) on the bus depending on whether + the SoC is running in big-endian or little-endian mode. Thus the + registers must always be accessed using native endianness. + + "#address-cells": + description: | + The first cell is the chip select number. + The second cell is the address offset within the bank. + const: 2 + + "#size-cells": + const: 1 + + ranges: true + dma-ranges: true + +patternProperties: + "^.*@[0-7],[0-9a-f]+$": + description: Devices attached to chip selects are represented as + subnodes. + type: object + + properties: + intel,ixp4xx-eb-t1: + description: Address timing, extend address phase with n cycles. + $ref: /schemas/types.yaml#/definitions/uint32 + maximum: 3 + + intel,ixp4xx-eb-t2: + description: Setup chip select timing, extend setup phase with n cycles. + $ref: /schemas/types.yaml#/definitions/uint32 + maximum: 3 + + intel,ixp4xx-eb-t3: + description: Strobe timing, extend strobe phase with n cycles. + $ref: /schemas/types.yaml#/definitions/uint32 + maximum: 15 + + intel,ixp4xx-eb-t4: + description: Hold timing, extend hold phase with n cycles. + $ref: /schemas/types.yaml#/definitions/uint32 + maximum: 3 + + intel,ixp4xx-eb-t5: + description: Recovery timing, extend recovery phase with n cycles. + $ref: /schemas/types.yaml#/definitions/uint32 + maximum: 15 + + intel,ixp4xx-eb-cycle-type: + description: The type of cycles to use on the expansion bus for this + chip select. 0 = Intel cycles, 1 = Motorola cycles, 2 = HPI cycles. + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1, 2] + + intel,ixp4xx-eb-byte-access-on-halfword: + description: Allow byte read access on half word devices. + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1] + + intel,ixp4xx-eb-hpi-hrdy-pol-high: + description: Set HPI HRDY polarity to active high when using HPI. + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1] + + intel,ixp4xx-eb-mux-address-and-data: + description: Multiplex address and data on the data bus. + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1] + + intel,ixp4xx-eb-ahb-split-transfers: + description: Enable AHB split transfers. + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1] + + intel,ixp4xx-eb-write-enable: + description: Enable write cycles. + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1] + + intel,ixp4xx-eb-byte-access: + description: Expansion bus uses only 8 bits. The default is to use + 16 bits. + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1] + +required: + - compatible + - reg + - native-endian + - "#address-cells" + - "#size-cells" + - ranges + - dma-ranges + +additionalProperties: false + +examples: + - | + #include + bus@50000000 { + compatible = "intel,ixp42x-expansion-bus-controller", "syscon"; + reg = <0xc4000000 0x28>; + native-endian; + #address-cells = <2>; + #size-cells = <1>; + ranges = <0 0x0 0x50000000 0x01000000>, + <1 0x0 0x51000000 0x01000000>; + dma-ranges = <0 0x0 0x50000000 0x01000000>, + <1 0x0 0x51000000 0x01000000>; + flash@0,0 { + compatible = "intel,ixp4xx-flash", "cfi-flash"; + bank-width = <2>; + reg = <0 0x00000000 0x1000000>; + intel,ixp4xx-eb-t3 = <3>; + intel,ixp4xx-eb-cycle-type = <0>; + intel,ixp4xx-eb-byte-access-on-halfword = <1>; + intel,ixp4xx-eb-write-enable = <1>; + intel,ixp4xx-eb-byte-access = <0>; + }; + serial@1,0 { + compatible = "exar,xr16l2551", "ns8250"; + reg = <1 0x00000000 0x10>; + interrupt-parent = <&gpio0>; + interrupts = <4 IRQ_TYPE_LEVEL_LOW>; + clock-frequency = <1843200>; + intel,ixp4xx-eb-t3 = <3>; + intel,ixp4xx-eb-cycle-type = <1>; + intel,ixp4xx-eb-write-enable = <1>; + intel,ixp4xx-eb-byte-access = <1>; + }; + }; -- cgit v1.2.3 From be470496eece679490dda90ebe497493f4c8faf6 Mon Sep 17 00:00:00 2001 From: Linus Walleij Date: Tue, 27 Jul 2021 10:52:10 +0200 Subject: pata: ixp4xx: Add DT bindings This adds device tree bindings for the Intel IXP4xx compact flash card interface. Cc: devicetree@vger.kernel.org Reviewed-by: Rob Herring Signed-off-by: Linus Walleij --- .../bindings/ata/intel,ixp4xx-compact-flash.yaml | 61 ++++++++++++++++++++++ 1 file changed, 61 insertions(+) create mode 100644 Documentation/devicetree/bindings/ata/intel,ixp4xx-compact-flash.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/ata/intel,ixp4xx-compact-flash.yaml b/Documentation/devicetree/bindings/ata/intel,ixp4xx-compact-flash.yaml new file mode 100644 index 000000000000..52e18600ecff --- /dev/null +++ b/Documentation/devicetree/bindings/ata/intel,ixp4xx-compact-flash.yaml @@ -0,0 +1,61 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/ata/intel,ixp4xx-compact-flash.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Intel IXP4xx CompactFlash Card Controller + +maintainers: + - Linus Walleij + +description: | + The IXP4xx network processors have a CompactFlash interface that presents + a CompactFlash card to the system as a true IDE (parallel ATA) device. The + device is always connected to the expansion bus of the IXP4xx SoCs using one + or two chip select areas and address translating logic on the board. The + node must be placed inside a chip select node on the IXP4xx expansion bus. + +properties: + compatible: + const: intel,ixp4xx-compact-flash + + reg: + items: + - description: Command interface registers + - description: Control interface registers + + interrupts: + maxItems: 1 + +required: + - compatible + - reg + - interrupts + +allOf: + - $ref: pata-common.yaml# + +unevaluatedProperties: false + +examples: + - | + #include + + bus@c4000000 { + compatible = "intel,ixp43x-expansion-bus-controller", "syscon"; + reg = <0xc4000000 0x1000>; + native-endian; + #address-cells = <2>; + #size-cells = <1>; + ranges = <0 0x0 0x50000000 0x01000000>, <1 0x0 0x51000000 0x01000000>; + dma-ranges = <0 0x0 0x50000000 0x01000000>, <1 0x0 0x51000000 0x01000000>; + ide@1,0 { + compatible = "intel,ixp4xx-compact-flash"; + reg = <1 0x00000000 0x1000>, <1 0x00040000 0x1000>; + interrupt-parent = <&gpio0>; + interrupts = <12 IRQ_TYPE_EDGE_RISING>; + }; + }; + +... -- cgit v1.2.3 From 396492b4c5f249f616002bb5de787d060d2b2974 Mon Sep 17 00:00:00 2001 From: Jakub Kicinski Date: Tue, 3 Aug 2021 16:14:15 -0700 Subject: docs: networking: netdevsim rules There are aspects of netdevsim which are commonly misunderstood and pointed out in review. Cong suggest we document them. Suggested-by: Cong Wang Signed-off-by: Jakub Kicinski Signed-off-by: David S. Miller --- Documentation/networking/netdev-FAQ.rst | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) (limited to 'Documentation') diff --git a/Documentation/networking/netdev-FAQ.rst b/Documentation/networking/netdev-FAQ.rst index 91b2cf712801..e26532f49760 100644 --- a/Documentation/networking/netdev-FAQ.rst +++ b/Documentation/networking/netdev-FAQ.rst @@ -228,6 +228,23 @@ before posting to the mailing list. The patchwork build bot instance gets overloaded very easily and netdev@vger really doesn't need more traffic if we can help it. +netdevsim is great, can I extend it for my out-of-tree tests? +------------------------------------------------------------- + +No, `netdevsim` is a test vehicle solely for upstream tests. +(Please add your tests under tools/testing/selftests/.) + +We also give no guarantees that `netdevsim` won't change in the future +in a way which would break what would normally be considered uAPI. + +Is netdevsim considered a "user" of an API? +------------------------------------------- + +Linux kernel has a long standing rule that no API should be added unless +it has a real, in-tree user. Mock-ups and tests based on `netdevsim` are +strongly encouraged when adding new APIs, but `netdevsim` in itself +is **not** considered a use case/user. + Any other tips to help ensure my net/net-next patch gets OK'd? -------------------------------------------------------------- Attention to detail. Re-read your own work as if you were the -- cgit v1.2.3 From e9f504f7b585c822b4c7d42bbbf18bbdd0241df4 Mon Sep 17 00:00:00 2001 From: Viktor Prutyanov Date: Mon, 19 Jul 2021 19:05:05 +0200 Subject: media: rc: meson-ir-tx: document device tree bindings This patch adds binding documentation for the IR transmitter available in Amlogic Meson SoCs. Signed-off-by: Viktor Prutyanov Acked-by: Martin Blumenstingl Reviewed-by: Rob Herring Signed-off-by: Sean Young Signed-off-by: Mauro Carvalho Chehab --- .../bindings/media/amlogic,meson-ir-tx.yaml | 60 ++++++++++++++++++++++ 1 file changed, 60 insertions(+) create mode 100644 Documentation/devicetree/bindings/media/amlogic,meson-ir-tx.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/media/amlogic,meson-ir-tx.yaml b/Documentation/devicetree/bindings/media/amlogic,meson-ir-tx.yaml new file mode 100644 index 000000000000..4432fea32650 --- /dev/null +++ b/Documentation/devicetree/bindings/media/amlogic,meson-ir-tx.yaml @@ -0,0 +1,60 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) + +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/media/amlogic,meson-ir-tx.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: Amlogic Meson IR transmitter + +maintainers: + - Viktor Prutyanov + +description: | + Some Amlogic SoCs such as A311D and T950D4 have IR transmitter + (also called blaster) controller onboard. It is capable of + sending IR signals with arbitrary carrier frequency and duty cycle. + +properties: + compatible: + oneOf: + - const: amlogic,meson-ir-tx + - items: + - const: amlogic,meson-g12a-ir-tx + - const: amlogic,meson-ir-tx + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 2 + + clock-names: + items: + - const: sysclk + - const: xtal + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + +additionalProperties: false + +examples: + - | + #include + #include + + ir@ff80014c { + compatible = "amlogic,meson-g12a-ir-tx", "amlogic,meson-ir-tx"; + reg = <0xff80014c 0x10>; + interrupts = <0 198 IRQ_TYPE_EDGE_RISING>; + clocks = <&clkc CLKID_CLK81>, <&xtal>; + clock-names = "sysclk", "xtal"; + }; -- cgit v1.2.3 From 932741d451a57819af4e316f9818ff363ac1f02a Mon Sep 17 00:00:00 2001 From: Martina Krasteva Date: Thu, 27 May 2021 16:21:40 +0200 Subject: media: dt-bindings: media: Add bindings for imx335 - Add dt-bindings documentation for Sony imx335 sensor driver - Add MAINTAINERS entry for Sony imx335 binding documentation Signed-off-by: Martina Krasteva Acked-by: Daniele Alessandrelli Acked-by: Paul J. Murphy Reviewed-by: Rob Herring Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab --- .../devicetree/bindings/media/i2c/sony,imx335.yaml | 91 ++++++++++++++++++++++ 1 file changed, 91 insertions(+) create mode 100644 Documentation/devicetree/bindings/media/i2c/sony,imx335.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/media/i2c/sony,imx335.yaml b/Documentation/devicetree/bindings/media/i2c/sony,imx335.yaml new file mode 100644 index 000000000000..881f79532501 --- /dev/null +++ b/Documentation/devicetree/bindings/media/i2c/sony,imx335.yaml @@ -0,0 +1,91 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +# Copyright (C) 2021 Intel Corporation +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/media/i2c/sony,imx335.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Sony IMX335 Sensor + +maintainers: + - Paul J. Murphy + - Daniele Alessandrelli + +description: + IMX335 sensor is a Sony CMOS active pixel digital image sensor with an active + array size of 2592H x 1944V. It is programmable through I2C interface. The + I2C client address is fixed to 0x1a as per sensor data sheet. Image data is + sent through MIPI CSI-2. + +properties: + compatible: + const: sony,imx335 + reg: + description: I2C address + maxItems: 1 + + assigned-clocks: true + assigned-clock-parents: true + assigned-clock-rates: true + + clocks: + description: Clock frequency from 6 to 27 MHz, 37.125MHz, 74.25MHz + maxItems: 1 + + reset-gpios: + description: Reference to the GPIO connected to the XCLR pin, if any. + maxItems: 1 + + port: + additionalProperties: false + $ref: /schemas/graph.yaml#/properties/port + + properties: + endpoint: + $ref: /schemas/media/video-interfaces.yaml# + unevaluatedProperties: false + + properties: + data-lanes: true + link-frequencies: true + + required: + - data-lanes + - link-frequencies + + required: + - endpoint + +required: + - compatible + - reg + - clocks + - port + +additionalProperties: false + +examples: + - | + i2c0 { + #address-cells = <1>; + #size-cells = <0>; + + camera@1a { + compatible = "sony,imx335"; + reg = <0x1a>; + clocks = <&imx335_clk>; + + assigned-clocks = <&imx335_clk>; + assigned-clock-parents = <&imx335_clk_parent>; + assigned-clock-rates = <24000000>; + + port { + imx335: endpoint { + remote-endpoint = <&cam>; + data-lanes = <1 2 3 4>; + link-frequencies = /bits/ 64 <594000000>; + }; + }; + }; + }; +... -- cgit v1.2.3 From 333b3125d1300e9a06e537295b9eb6042d131492 Mon Sep 17 00:00:00 2001 From: Martina Krasteva Date: Thu, 27 May 2021 16:21:42 +0200 Subject: media: dt-bindings: media: Add bindings for imx412 - Add dt-bindings documentation for Sony imx412 sensor driver - Add MAINTAINERS entry for Sony imx412 binding documentation Signed-off-by: Martina Krasteva Acked-by: Daniele Alessandrelli Acked-by: Paul J. Murphy Reviewed-by: Rob Herring Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab --- .../devicetree/bindings/media/i2c/sony,imx412.yaml | 91 ++++++++++++++++++++++ 1 file changed, 91 insertions(+) create mode 100644 Documentation/devicetree/bindings/media/i2c/sony,imx412.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/media/i2c/sony,imx412.yaml b/Documentation/devicetree/bindings/media/i2c/sony,imx412.yaml new file mode 100644 index 000000000000..1edeabf39e6a --- /dev/null +++ b/Documentation/devicetree/bindings/media/i2c/sony,imx412.yaml @@ -0,0 +1,91 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +# Copyright (C) 2021 Intel Corporation +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/media/i2c/sony,imx412.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Sony IMX412 Sensor + +maintainers: + - Paul J. Murphy + - Daniele Alessandrelli + +description: + IMX412 sensor is a Sony CMOS active pixel digital image sensor with an active + array size of 4072H x 3176V. It is programmable through I2C interface. The + I2C client address is fixed to 0x1a as per sensor data sheet. Image data is + sent through MIPI CSI-2. + +properties: + compatible: + const: sony,imx412 + reg: + description: I2C address + maxItems: 1 + + assigned-clocks: true + assigned-clock-parents: true + assigned-clock-rates: true + + clocks: + description: Clock frequency 6MHz, 12MHz, 18MHz, 24MHz or 27MHz + maxItems: 1 + + reset-gpios: + description: Reference to the GPIO connected to the XCLR pin, if any. + maxItems: 1 + + port: + additionalProperties: false + $ref: /schemas/graph.yaml#/properties/port + + properties: + endpoint: + $ref: /schemas/media/video-interfaces.yaml# + unevaluatedProperties: false + + properties: + data-lanes: true + link-frequencies: true + + required: + - data-lanes + - link-frequencies + + required: + - endpoint + +required: + - compatible + - reg + - clocks + - port + +additionalProperties: false + +examples: + - | + i2c0 { + #address-cells = <1>; + #size-cells = <0>; + + camera@1a { + compatible = "sony,imx412"; + reg = <0x1a>; + clocks = <&imx412_clk>; + + assigned-clocks = <&imx412_clk>; + assigned-clock-parents = <&imx412_clk_parent>; + assigned-clock-rates = <24000000>; + + port { + imx412: endpoint { + remote-endpoint = <&cam>; + data-lanes = <1 2 3 4>; + link-frequencies = /bits/ 64 <600000000>; + }; + }; + }; + }; +... -- cgit v1.2.3 From 4874ea39874731e589dc5b329f5c03965c2a6474 Mon Sep 17 00:00:00 2001 From: Martina Krasteva Date: Thu, 27 May 2021 16:21:44 +0200 Subject: media: dt-bindings: media: Add bindings for ov9282 - Add dt-bindings documentation for OmniVision ov9282 sensor driver - Add MAINTAINERS entry for OmniVision ov9282 binding documentation Signed-off-by: Martina Krasteva Acked-by: Daniele Alessandrelli Acked-by: Paul J. Murphy Reviewed-by: Rob Herring Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab --- .../devicetree/bindings/media/i2c/ovti,ov9282.yaml | 91 ++++++++++++++++++++++ 1 file changed, 91 insertions(+) create mode 100644 Documentation/devicetree/bindings/media/i2c/ovti,ov9282.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov9282.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov9282.yaml new file mode 100644 index 000000000000..ad42992c6da3 --- /dev/null +++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov9282.yaml @@ -0,0 +1,91 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +# Copyright (C) 2021 Intel Corporation +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/media/i2c/ovti,ov9282.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: OmniVision OV9282 Sensor + +maintainers: + - Paul J. Murphy + - Daniele Alessandrelli + +description: + OV9282 sensor is an OmniVision black & white CMOS active pixel digital image + sensor with an active array size of 1296H x 816V. It is programmable through + I2C interface. The I2C client address is fixed to 0x60/0x70 as per sensor data + sheet. Image data is sent through MIPI CSI-2. + +properties: + compatible: + const: ovti,ov9282 + reg: + description: I2C address + maxItems: 1 + + assigned-clocks: true + assigned-clock-parents: true + assigned-clock-rates: true + + clocks: + description: Clock frequency from 6 to 27MHz + maxItems: 1 + + reset-gpios: + description: Reference to the GPIO connected to the XCLR pin, if any. + maxItems: 1 + + port: + additionalProperties: false + $ref: /schemas/graph.yaml#/properties/port + + properties: + endpoint: + $ref: /schemas/media/video-interfaces.yaml# + unevaluatedProperties: false + + properties: + data-lanes: true + link-frequencies: true + + required: + - data-lanes + - link-frequencies + + required: + - endpoint + +required: + - compatible + - reg + - clocks + - port + +additionalProperties: false + +examples: + - | + i2c0 { + #address-cells = <1>; + #size-cells = <0>; + + camera@60 { + compatible = "ovti,ov9282"; + reg = <0x60>; + clocks = <&ov9282_clk>; + + assigned-clocks = <&ov9282_clk>; + assigned-clock-parents = <&ov9282_clk_parent>; + assigned-clock-rates = <24000000>; + + port { + ov9282: endpoint { + remote-endpoint = <&cam>; + data-lanes = <1 2>; + link-frequencies = /bits/ 64 <800000000>; + }; + }; + }; + }; +... -- cgit v1.2.3 From b9a543364299e09ba236c69acb021ebbf7cebf1a Mon Sep 17 00:00:00 2001 From: Sakari Ailus Date: Mon, 1 Feb 2021 10:16:03 +0100 Subject: media: Documentation: media: Improve camera sensor documentation Modernise the documentation to make it more precise and update the use of pixel rate control and various other changes. In particular: - Use non-proportional font for file names, properties as well as controls. - The unit of the HBLANK control is pixels, not lines. - The unit of PIXEL_RATE control is pixels per second, not Hz. - Merge common requirements for CSI-2 and parallel busses. - Include all DT properties needed for assigned clocks. - Fix referencing the link rate control. - SMIA driver's new name is CCS driver. - The PIXEL_RATE control denotes pixel rate on the pixel array on camera sensors. Do not suggest it is used to tell the maximum pixel rate on the bus anymore. - Improve ReST syntax (plain struct and function names). - Remove the suggestion to use s_power() in receiver drivers. - Make MIPI website URL use HTTPS, add Wikipedia links to BT.601 and BT.656. Fixes: e4cf8c58af75 ("media: Documentation: media: Document how to write camera sensor drivers") Signed-off-by: Sakari Ailus Reviewed-by: Jacopo Mondi Reviewed-by: Andrey Konovalov Signed-off-by: Mauro Carvalho Chehab --- Documentation/driver-api/media/camera-sensor.rst | 45 +++----- Documentation/driver-api/media/csi2.rst | 94 ----------------- Documentation/driver-api/media/index.rst | 2 +- Documentation/driver-api/media/tx-rx.rst | 117 +++++++++++++++++++++ .../media/v4l/ext-ctrls-image-process.rst | 2 + 5 files changed, 137 insertions(+), 123 deletions(-) delete mode 100644 Documentation/driver-api/media/csi2.rst create mode 100644 Documentation/driver-api/media/tx-rx.rst (limited to 'Documentation') diff --git a/Documentation/driver-api/media/camera-sensor.rst b/Documentation/driver-api/media/camera-sensor.rst index 7160336aa475..c7d4891bd24e 100644 --- a/Documentation/driver-api/media/camera-sensor.rst +++ b/Documentation/driver-api/media/camera-sensor.rst @@ -3,10 +3,10 @@ Writing camera sensor drivers ============================= -CSI-2 ------ +CSI-2 and parallel (BT.601 and BT.656) busses +--------------------------------------------- -Please see what is written on :ref:`MIPI_CSI_2`. +Please see :ref:`transmitter-receiver`. Handling clocks --------------- @@ -26,15 +26,16 @@ user. ACPI ~~~~ -Read the "clock-frequency" _DSD property to denote the frequency. The driver can -rely on this frequency being used. +Read the ``clock-frequency`` _DSD property to denote the frequency. The driver +can rely on this frequency being used. Devicetree ~~~~~~~~~~ -The currently preferred way to achieve this is using "assigned-clock-rates" -property. See Documentation/devicetree/bindings/clock/clock-bindings.txt for -more information. The driver then gets the frequency using clk_get_rate(). +The currently preferred way to achieve this is using ``assigned-clocks``, +``assigned-clock-parents`` and ``assigned-clock-rates`` properties. See +``Documentation/devicetree/bindings/clock/clock-bindings.txt`` for more +information. The driver then gets the frequency using ``clk_get_rate()``. This approach has the drawback that there's no guarantee that the frequency hasn't been modified directly or indirectly by another driver, or supported by @@ -55,7 +56,7 @@ processing pipeline as one or more sub-devices with different cropping and scaling configurations. The output size of the device is the result of a series of cropping and scaling operations from the device's pixel array's size. -An example of such a driver is the smiapp driver (see drivers/media/i2c/smiapp). +An example of such a driver is the CCS driver (see ``drivers/media/i2c/ccs``). Register list based drivers ~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -67,7 +68,7 @@ level are independent. How a driver picks such configuration is based on the format set on a source pad at the end of the device's internal pipeline. Most sensor drivers are implemented this way, see e.g. -drivers/media/i2c/imx319.c for an example. +``drivers/media/i2c/imx319.c`` for an example. Frame interval configuration ---------------------------- @@ -94,9 +95,10 @@ large variety of devices beyond camera sensors. Devices that have no analogue crop, use the full source image size, i.e. pixel array size. Horizontal and vertical blanking are specified by ``V4L2_CID_HBLANK`` and -``V4L2_CID_VBLANK``, respectively. The unit of these controls are lines. The -pixel rate is specified by ``V4L2_CID_PIXEL_RATE`` in the same sub-device. The -unit of that control is Hz. +``V4L2_CID_VBLANK``, respectively. The unit of the ``V4L2_CID_HBLANK`` control +is pixels and the unit of the ``V4L2_CID_VBLANK`` is lines. The pixel rate in +the sensor's **pixel array** is specified by ``V4L2_CID_PIXEL_RATE`` in the same +sub-device. The unit of that control is pixels per second. Register list based drivers need to implement read-only sub-device nodes for the purpose. Devices that are not register list based need these to configure the @@ -125,14 +127,14 @@ general, the device must be powered on at least when its registers are being accessed and when it is streaming. Existing camera sensor drivers may rely on the old -:c:type:`v4l2_subdev_core_ops`->s_power() callback for bridge or ISP drivers to +struct v4l2_subdev_core_ops->s_power() callback for bridge or ISP drivers to manage their power state. This is however **deprecated**. If you feel you need to begin calling an s_power from an ISP or a bridge driver, instead please add runtime PM support to the sensor driver you are using. Likewise, new drivers should not use s_power. Please see examples in e.g. ``drivers/media/i2c/ov8856.c`` and -``drivers/media/i2c/smiapp/smiapp-core.c``. The two drivers work in both ACPI +``drivers/media/i2c/ccs/ccs-core.c``. The two drivers work in both ACPI and DT based systems. Control framework @@ -149,16 +151,3 @@ used to obtain device's power state after the power state transition: The function returns a non-zero value if it succeeded getting the power count or runtime PM was disabled, in either of which cases the driver may proceed to access the device. - -Controls --------- - -For camera sensors that are connected to a bus where transmitter and receiver -require common configuration set by drivers, such as CSI-2 or parallel (BT.601 -or BT.656) bus, the ``V4L2_CID_LINK_FREQ`` control is mandatory on transmitter -drivers. Receiver drivers can use the ``V4L2_CID_LINK_FREQ`` to query the -frequency used on the bus. - -The transmitter drivers should also implement ``V4L2_CID_PIXEL_RATE`` control in -order to tell the maximum pixel rate to the receiver. This is required on raw -camera sensors. diff --git a/Documentation/driver-api/media/csi2.rst b/Documentation/driver-api/media/csi2.rst deleted file mode 100644 index 11c52b0be8b8..000000000000 --- a/Documentation/driver-api/media/csi2.rst +++ /dev/null @@ -1,94 +0,0 @@ -.. SPDX-License-Identifier: GPL-2.0 - -.. _MIPI_CSI_2: - -MIPI CSI-2 -========== - -CSI-2 is a data bus intended for transferring images from cameras to -the host SoC. It is defined by the `MIPI alliance`_. - -.. _`MIPI alliance`: http://www.mipi.org/ - -Media bus formats ------------------ - -See :ref:`v4l2-mbus-pixelcode` for details on which media bus formats should -be used for CSI-2 interfaces. - -Transmitter drivers -------------------- - -CSI-2 transmitter, such as a sensor or a TV tuner, drivers need to -provide the CSI-2 receiver with information on the CSI-2 bus -configuration. These include the V4L2_CID_LINK_FREQ and -V4L2_CID_PIXEL_RATE controls and -(:c:type:`v4l2_subdev_video_ops`->s_stream() callback). These -interface elements must be present on the sub-device represents the -CSI-2 transmitter. - -The V4L2_CID_LINK_FREQ control is used to tell the receiver driver the -frequency (and not the symbol rate) of the link. The V4L2_CID_PIXEL_RATE -control may be used by the receiver to obtain the pixel rate the transmitter -uses. The :c:type:`v4l2_subdev_video_ops`->s_stream() callback provides an -ability to start and stop the stream. - -The value of the V4L2_CID_PIXEL_RATE is calculated as follows:: - - pixel_rate = link_freq * 2 * nr_of_lanes * 16 / k / bits_per_sample - -where - -.. list-table:: variables in pixel rate calculation - :header-rows: 1 - - * - variable or constant - - description - * - link_freq - - The value of the V4L2_CID_LINK_FREQ integer64 menu item. - * - nr_of_lanes - - Number of data lanes used on the CSI-2 link. This can - be obtained from the OF endpoint configuration. - * - 2 - - Two bits are transferred per clock cycle per lane. - * - bits_per_sample - - Number of bits per sample. - * - k - - 16 for D-PHY and 7 for C-PHY - -The transmitter drivers must, if possible, configure the CSI-2 -transmitter to *LP-11 mode* whenever the transmitter is powered on but -not active, and maintain *LP-11 mode* until stream on. Only at stream -on should the transmitter activate the clock on the clock lane and -transition to *HS mode*. - -Some transmitters do this automatically but some have to be explicitly -programmed to do so, and some are unable to do so altogether due to -hardware constraints. - -Stopping the transmitter -^^^^^^^^^^^^^^^^^^^^^^^^ - -A transmitter stops sending the stream of images as a result of -calling the ``.s_stream()`` callback. Some transmitters may stop the -stream at a frame boundary whereas others stop immediately, -effectively leaving the current frame unfinished. The receiver driver -should not make assumptions either way, but function properly in both -cases. - -Receiver drivers ----------------- - -Before the receiver driver may enable the CSI-2 transmitter by using -the :c:type:`v4l2_subdev_video_ops`->s_stream(), it must have powered -the transmitter up by using the -:c:type:`v4l2_subdev_core_ops`->s_power() callback. This may take -place either indirectly by using :c:func:`v4l2_pipeline_pm_get` or -directly. - -Formats -------- - -The media bus pixel codes document parallel formats. Should the pixel data be -transported over a serial bus, the media bus pixel code that describes a -parallel format that transfers a sample on a single clock cycle is used. diff --git a/Documentation/driver-api/media/index.rst b/Documentation/driver-api/media/index.rst index 813d7db59da7..08e206567408 100644 --- a/Documentation/driver-api/media/index.rst +++ b/Documentation/driver-api/media/index.rst @@ -37,7 +37,7 @@ Documentation/userspace-api/media/index.rst rc-core mc-core cec-core - csi2 + tx-rx camera-sensor drivers/index diff --git a/Documentation/driver-api/media/tx-rx.rst b/Documentation/driver-api/media/tx-rx.rst new file mode 100644 index 000000000000..4c8584e7b6f2 --- /dev/null +++ b/Documentation/driver-api/media/tx-rx.rst @@ -0,0 +1,117 @@ +.. SPDX-License-Identifier: GPL-2.0 + +.. _transmitter-receiver: + +Pixel data transmitter and receiver drivers +=========================================== + +V4L2 supports various devices that transmit and receiver pixel data. Examples of +these devices include a camera sensor, a TV tuner and a parallel or a CSI-2 +receiver in an SoC. + +Bus types +--------- + +The following busses are the most common. This section discusses these two only. + +MIPI CSI-2 +^^^^^^^^^^ + +CSI-2 is a data bus intended for transferring images from cameras to +the host SoC. It is defined by the `MIPI alliance`_. + +.. _`MIPI alliance`: https://www.mipi.org/ + +Parallel +^^^^^^^^ + +`BT.601`_ and `BT.656`_ are the most common parallel busses. + +.. _`BT.601`: https://en.wikipedia.org/wiki/Rec._601 +.. _`BT.656`: https://en.wikipedia.org/wiki/ITU-R_BT.656 + +Transmitter drivers +------------------- + +Transmitter drivers generally need to provide the receiver drivers with the +configuration of the transmitter. What is required depends on the type of the +bus. These are common for both busses. + +Media bus pixel code +^^^^^^^^^^^^^^^^^^^^ + +See :ref:`v4l2-mbus-pixelcode`. + +Link frequency +^^^^^^^^^^^^^^ + +The :ref:`V4L2_CID_LINK_FREQ ` control is used to tell the +receiver the frequency of the bus (i.e. it is not the same as the symbol rate). + +``.s_stream()`` callback +^^^^^^^^^^^^^^^^^^^^^^^^ + +The struct struct v4l2_subdev_video_ops->s_stream() callback is used by the +receiver driver to control the transmitter driver's streaming state. + + +CSI-2 transmitter drivers +------------------------- + +Pixel rate +^^^^^^^^^^ + +The pixel rate on the bus is calculated as follows:: + + pixel_rate = link_freq * 2 * nr_of_lanes * 16 / k / bits_per_sample + +where + +.. list-table:: variables in pixel rate calculation + :header-rows: 1 + + * - variable or constant + - description + * - link_freq + - The value of the ``V4L2_CID_LINK_FREQ`` integer64 menu item. + * - nr_of_lanes + - Number of data lanes used on the CSI-2 link. This can + be obtained from the OF endpoint configuration. + * - 2 + - Data is transferred on both rising and falling edge of the signal. + * - bits_per_sample + - Number of bits per sample. + * - k + - 16 for D-PHY and 7 for C-PHY + +.. note:: + + The pixel rate calculated this way is **not** the same thing as the + pixel rate on the camera sensor's pixel array which is indicated by the + :ref:`V4L2_CID_PIXEL_RATE ` control. + +LP-11 and LP-111 modes +^^^^^^^^^^^^^^^^^^^^^^ + +The transmitter drivers must, if possible, configure the CSI-2 transmitter to +*LP-11 or LP-111 mode* whenever the transmitter is powered on but not active, +and maintain *LP-11 or LP-111 mode* until stream on. Only at stream on should +the transmitter activate the clock on the clock lane and transition to *HS +mode*. + +Some transmitters do this automatically but some have to be explicitly +programmed to do so, and some are unable to do so altogether due to +hardware constraints. + +The receiver thus need to be configured to expect LP-11 or LP-111 mode from the +transmitter before the transmitter driver's ``.s_stream()`` op is called. + +Stopping the transmitter +^^^^^^^^^^^^^^^^^^^^^^^^ + +A transmitter stops sending the stream of images as a result of +calling the ``.s_stream()`` callback. Some transmitters may stop the +stream at a frame boundary whereas others stop immediately, +effectively leaving the current frame unfinished. The receiver driver +should not make assumptions either way, but function properly in both +cases. diff --git a/Documentation/userspace-api/media/v4l/ext-ctrls-image-process.rst b/Documentation/userspace-api/media/v4l/ext-ctrls-image-process.rst index 87698c15c027..37dad2f4df8c 100644 --- a/Documentation/userspace-api/media/v4l/ext-ctrls-image-process.rst +++ b/Documentation/userspace-api/media/v4l/ext-ctrls-image-process.rst @@ -20,6 +20,8 @@ Image Process Control IDs ``V4L2_CID_IMAGE_PROC_CLASS (class)`` The IMAGE_PROC class descriptor. +.. _v4l2-cid-link-freq: + ``V4L2_CID_LINK_FREQ (integer menu)`` Data bus frequency. Together with the media bus pixel code, bus type (clock cycles per sample), the data bus frequency defines the pixel -- cgit v1.2.3 From 6f8f9fdec8e4615a2cf539bbcad400d4b3a39070 Mon Sep 17 00:00:00 2001 From: Sakari Ailus Date: Mon, 8 Feb 2021 11:33:14 +0100 Subject: media: Documentation: media: Fix v4l2-async kerneldoc syntax Fix kerneldoc syntax in v4l2-async. The references were not produced correctly. Signed-off-by: Sakari Ailus Reviewed-by: Jacopo Mondi Signed-off-by: Mauro Carvalho Chehab --- Documentation/driver-api/media/tx-rx.rst | 8 ++++---- Documentation/userspace-api/media/v4l/ext-ctrls-image-process.rst | 2 ++ 2 files changed, 6 insertions(+), 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/driver-api/media/tx-rx.rst b/Documentation/driver-api/media/tx-rx.rst index 4c8584e7b6f2..12d492d25df2 100644 --- a/Documentation/driver-api/media/tx-rx.rst +++ b/Documentation/driver-api/media/tx-rx.rst @@ -5,7 +5,7 @@ Pixel data transmitter and receiver drivers =========================================== -V4L2 supports various devices that transmit and receiver pixel data. Examples of +V4L2 supports various devices that transmit and receive pixel data. Examples of these devices include a camera sensor, a TV tuner and a parallel or a CSI-2 receiver in an SoC. @@ -95,9 +95,9 @@ LP-11 and LP-111 modes The transmitter drivers must, if possible, configure the CSI-2 transmitter to *LP-11 or LP-111 mode* whenever the transmitter is powered on but not active, -and maintain *LP-11 or LP-111 mode* until stream on. Only at stream on should -the transmitter activate the clock on the clock lane and transition to *HS -mode*. +and maintain *LP-11 or LP-111 mode* until stream on. Only at stream on time +should the transmitter activate the clock on the clock lane and transition to +*HS mode*. Some transmitters do this automatically but some have to be explicitly programmed to do so, and some are unable to do so altogether due to diff --git a/Documentation/userspace-api/media/v4l/ext-ctrls-image-process.rst b/Documentation/userspace-api/media/v4l/ext-ctrls-image-process.rst index 37dad2f4df8c..ed65fb594cc8 100644 --- a/Documentation/userspace-api/media/v4l/ext-ctrls-image-process.rst +++ b/Documentation/userspace-api/media/v4l/ext-ctrls-image-process.rst @@ -37,6 +37,8 @@ Image Process Control IDs by selecting the desired horizontal and vertical blanking. The unit of this control is Hz. +.. _v4l2-cid-pixel-rate: + ``V4L2_CID_PIXEL_RATE (64-bit integer)`` Pixel rate in the source pads of the subdev. This control is read-only and its unit is pixels / second. -- cgit v1.2.3 From 8925b53083980057de99599ba8dd2a72b03406a6 Mon Sep 17 00:00:00 2001 From: Sakari Ailus Date: Tue, 22 Jun 2021 12:52:03 +0200 Subject: media: Documentation: v4l: Fix V4L2_CID_PIXEL_RATE documentation The V4L2_CID_PIXEL_RATE is nowadays used to tell pixel sampling rate in the sub-device's pixel array, not the pixel rate over a link (for which it also becomes unfit with the addition of multiplexed streams later on). Fix this. Signed-off-by: Sakari Ailus Reviewed-by: Jacopo Mondi Reviewed-by: Andrey Konovalov Signed-off-by: Mauro Carvalho Chehab --- Documentation/userspace-api/media/v4l/ext-ctrls-image-process.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/userspace-api/media/v4l/ext-ctrls-image-process.rst b/Documentation/userspace-api/media/v4l/ext-ctrls-image-process.rst index ed65fb594cc8..2b5a13dc843f 100644 --- a/Documentation/userspace-api/media/v4l/ext-ctrls-image-process.rst +++ b/Documentation/userspace-api/media/v4l/ext-ctrls-image-process.rst @@ -40,7 +40,7 @@ Image Process Control IDs .. _v4l2-cid-pixel-rate: ``V4L2_CID_PIXEL_RATE (64-bit integer)`` - Pixel rate in the source pads of the subdev. This control is + Pixel sampling rate in the device's pixel array. This control is read-only and its unit is pixels / second. ``V4L2_CID_TEST_PATTERN (menu)`` -- cgit v1.2.3 From e5a466d4bcf962daa8fea589b09a5675bda275a1 Mon Sep 17 00:00:00 2001 From: Sakari Ailus Date: Tue, 22 Jun 2021 13:17:20 +0200 Subject: media: Documentation: v4l: Improve frame rate configuration documentation Improve the documentation of the frame rate configuration so that it can be understood by a regular human being. Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab --- .../media/v4l/ext-ctrls-image-process.rst | 23 ++++++++++------------ 1 file changed, 10 insertions(+), 13 deletions(-) (limited to 'Documentation') diff --git a/Documentation/userspace-api/media/v4l/ext-ctrls-image-process.rst b/Documentation/userspace-api/media/v4l/ext-ctrls-image-process.rst index 2b5a13dc843f..b1c2ab2854af 100644 --- a/Documentation/userspace-api/media/v4l/ext-ctrls-image-process.rst +++ b/Documentation/userspace-api/media/v4l/ext-ctrls-image-process.rst @@ -23,19 +23,7 @@ Image Process Control IDs .. _v4l2-cid-link-freq: ``V4L2_CID_LINK_FREQ (integer menu)`` - Data bus frequency. Together with the media bus pixel code, bus type - (clock cycles per sample), the data bus frequency defines the pixel - rate (``V4L2_CID_PIXEL_RATE``) in the pixel array (or possibly - elsewhere, if the device is not an image sensor). The frame rate can - be calculated from the pixel clock, image width and height and - horizontal and vertical blanking. While the pixel rate control may - be defined elsewhere than in the subdev containing the pixel array, - the frame rate cannot be obtained from that information. This is - because only on the pixel array it can be assumed that the vertical - and horizontal blanking information is exact: no other blanking is - allowed in the pixel array. The selection of frame rate is performed - by selecting the desired horizontal and vertical blanking. The unit - of this control is Hz. + The frequency of the data bus (e.g. parallel or CSI-2). .. _v4l2-cid-pixel-rate: @@ -43,6 +31,15 @@ Image Process Control IDs Pixel sampling rate in the device's pixel array. This control is read-only and its unit is pixels / second. + Some devices use horizontal and vertical balanking to configure the frame + rate. The frame rate can be calculated from the pixel rate, analogue crop + rectangle as well as horizontal and vertical blanking. The pixel rate + control may be present in a different sub-device than the blanking controls + and the analogue crop rectangle configuration. + + The configuration of the frame rate is performed by selecting the desired + horizontal and vertical blanking. The unit of this control is Hz. + ``V4L2_CID_TEST_PATTERN (menu)`` Some capture/display/sensor devices have the capability to generate test pattern images. These hardware specific test patterns can be -- cgit v1.2.3 From 013c35b22e6216b0bde04a1fc3a1a4b599a4e13f Mon Sep 17 00:00:00 2001 From: Sakari Ailus Date: Wed, 23 Jun 2021 14:38:31 +0200 Subject: media: Documentation: v4l: Rework LP-11 documentation, add callbacks Rework LP-11 and LP-111 mode documentation to make it more understandable and useful. This involves adding pre_streamon and post_streamon callbacks that make it possible to explicitly transition the transmitter to either mode. Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab --- Documentation/driver-api/media/tx-rx.rst | 40 ++++++++++++++++++++++---------- 1 file changed, 28 insertions(+), 12 deletions(-) (limited to 'Documentation') diff --git a/Documentation/driver-api/media/tx-rx.rst b/Documentation/driver-api/media/tx-rx.rst index 12d492d25df2..e1e9258dd862 100644 --- a/Documentation/driver-api/media/tx-rx.rst +++ b/Documentation/driver-api/media/tx-rx.rst @@ -93,18 +93,34 @@ where LP-11 and LP-111 modes ^^^^^^^^^^^^^^^^^^^^^^ -The transmitter drivers must, if possible, configure the CSI-2 transmitter to -*LP-11 or LP-111 mode* whenever the transmitter is powered on but not active, -and maintain *LP-11 or LP-111 mode* until stream on. Only at stream on time -should the transmitter activate the clock on the clock lane and transition to -*HS mode*. - -Some transmitters do this automatically but some have to be explicitly -programmed to do so, and some are unable to do so altogether due to -hardware constraints. - -The receiver thus need to be configured to expect LP-11 or LP-111 mode from the -transmitter before the transmitter driver's ``.s_stream()`` op is called. +As part of transitioning to high speed mode, a CSI-2 transmitter typically +briefly sets the bus to LP-11 or LP-111 state, depending on the PHY. This period +may be as short as 100 µs, during which the receiver observes this state and +proceeds its own part of high speed mode transition. + +Most receivers are capable of autonomously handling this once the software has +configured them to do so, but there are receivers which require software +involvement in observing LP-11 or LP-111 state. 100 µs is a brief period to hit +in software, especially when there is no interrupt telling something is +happening. + +One way to address this is to configure the transmitter side explicitly to LP-11 +or LP-111 mode, which requires support from the transmitter hardware. This is +not universally available. Many devices return to this state once streaming is +stopped while the state after power-on is LP-00 or LP-000. + +The ``.pre_streamon()`` callback may be used to prepare a transmitter for +transitioning to streaming state, but not yet start streaming. Similarly, the +``.post_streamoff()`` callback is used to undo what was done by the +``.pre_streamon()`` callback. The caller of ``.pre_streamon()`` is thus required +to call ``.post_streamoff()`` for each successful call of ``.pre_streamon()``. + +In the context of CSI-2, the ``.pre_streamon()`` callback is used to transition +the transmitter to the LP-11 or LP-111 mode. This also requires powering on the +device, so this should be only done when it is needed. + +Receiver drivers that do not need explicit LP-11 or LP-111 mode setup are waived +from calling the two callbacks. Stopping the transmitter ^^^^^^^^^^^^^^^^^^^^^^^^ -- cgit v1.2.3 From e8713c31f8adab67155e245a217d0c7cad05fcf5 Mon Sep 17 00:00:00 2001 From: Laurent Pinchart Date: Mon, 12 Apr 2021 04:32:48 +0200 Subject: media: dt-bindings: media: nxp,imx7-csi: Add i.MX8MM support The i.MX8MM integrates a CSI bridge IP core, as the i.MX7. There seems to be no difference between the two SoCs according to the reference manual, but as documentation may not be accurate, add a compatible string for the i.MX8MM, with a fallback on the compatible i.MX7. Signed-off-by: Laurent Pinchart Reviewed-by: Rob Herring Signed-off-by: Mauro Carvalho Chehab --- Documentation/devicetree/bindings/media/nxp,imx7-csi.yaml | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/media/nxp,imx7-csi.yaml b/Documentation/devicetree/bindings/media/nxp,imx7-csi.yaml index d91575b8ebb9..5922a2795167 100644 --- a/Documentation/devicetree/bindings/media/nxp,imx7-csi.yaml +++ b/Documentation/devicetree/bindings/media/nxp,imx7-csi.yaml @@ -4,7 +4,7 @@ $id: http://devicetree.org/schemas/media/nxp,imx7-csi.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# -title: i.MX7 CMOS Sensor Interface +title: i.MX7 and i.MX8 CSI bridge (CMOS Sensor Interface) maintainers: - Rui Miguel Silva @@ -15,9 +15,13 @@ description: | properties: compatible: - enum: - - fsl,imx7-csi - - fsl,imx6ul-csi + oneOf: + - enum: + - fsl,imx7-csi + - fsl,imx6ul-csi + - items: + - const: fsl,imx8mm-csi + - const: fsl,imx7-csi reg: maxItems: 1 -- cgit v1.2.3 From 37255747ecbd691a0050109e8c2133096f4dab50 Mon Sep 17 00:00:00 2001 From: Martin Kepplinger Date: Wed, 28 Jul 2021 11:12:43 +0200 Subject: media: dt-bindings: media: document the nxp,imx8mq-mipi-csi2 receiver phy and controller The i.MX8MQ SoC integrates a different MIPI CSI receiver as the i.MX8MM so describe the DT bindings for it. Signed-off-by: Martin Kepplinger Reviewed-by: Rob Herring Signed-off-by: Laurent Pinchart Signed-off-by: Mauro Carvalho Chehab --- .../bindings/media/nxp,imx8mq-mipi-csi2.yaml | 174 +++++++++++++++++++++ 1 file changed, 174 insertions(+) create mode 100644 Documentation/devicetree/bindings/media/nxp,imx8mq-mipi-csi2.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/media/nxp,imx8mq-mipi-csi2.yaml b/Documentation/devicetree/bindings/media/nxp,imx8mq-mipi-csi2.yaml new file mode 100644 index 000000000000..9c04fa85ee5c --- /dev/null +++ b/Documentation/devicetree/bindings/media/nxp,imx8mq-mipi-csi2.yaml @@ -0,0 +1,174 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/media/nxp,imx8mq-mipi-csi2.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NXP i.MX8MQ MIPI CSI-2 receiver + +maintainers: + - Martin Kepplinger + +description: |- + This binding covers the CSI-2 RX PHY and host controller included in the + NXP i.MX8MQ SoC. It handles the sensor/image input and process for all the + input imaging devices. + +properties: + compatible: + enum: + - fsl,imx8mq-mipi-csi2 + + reg: + maxItems: 1 + + clocks: + items: + - description: core is the RX Controller Core Clock input. This clock + must be exactly equal to or faster than the receive + byteclock from the RX DPHY. + - description: esc is the Rx Escape Clock. This must be the same escape + clock that the RX DPHY receives. + - description: ui is the pixel clock (phy_ref up to 333Mhz). + See the reference manual for details. + + clock-names: + items: + - const: core + - const: esc + - const: ui + + power-domains: + maxItems: 1 + + resets: + items: + - description: CORE_RESET reset register bit definition + - description: PHY_REF_RESET reset register bit definition + - description: ESC_RESET reset register bit definition + + fsl,mipi-phy-gpr: + description: | + The phandle to the imx8mq syscon iomux-gpr with the register + for setting RX_ENABLE for the mipi receiver. + + The format should be as follows: + + gpr is the phandle to general purpose register node. + req_gpr is the gpr register offset of RX_ENABLE for the mipi phy. + $ref: /schemas/types.yaml#/definitions/phandle-array + items: + items: + - description: The 'gpr' is the phandle to general purpose register node. + - description: The 'req_gpr' is the gpr register offset containing + CSI2_1_RX_ENABLE or CSI2_2_RX_ENABLE respectively. + maximum: 0xff + + interconnects: + maxItems: 1 + + interconnect-names: + const: dram + + ports: + $ref: /schemas/graph.yaml#/properties/ports + + properties: + port@0: + $ref: /schemas/graph.yaml#/$defs/port-base + unevaluatedProperties: false + description: + Input port node, single endpoint describing the CSI-2 transmitter. + + properties: + endpoint: + $ref: video-interfaces.yaml# + unevaluatedProperties: false + + properties: + data-lanes: + items: + minItems: 1 + maxItems: 4 + items: + - const: 1 + - const: 2 + - const: 3 + - const: 4 + + required: + - data-lanes + + port@1: + $ref: /schemas/graph.yaml#/properties/port + description: + Output port node + + required: + - port@0 + - port@1 + +required: + - compatible + - reg + - clocks + - clock-names + - power-domains + - resets + - fsl,mipi-phy-gpr + - ports + +additionalProperties: false + +examples: + - | + #include + #include + #include + + csi@30a70000 { + compatible = "fsl,imx8mq-mipi-csi2"; + reg = <0x30a70000 0x1000>; + clocks = <&clk IMX8MQ_CLK_CSI1_CORE>, + <&clk IMX8MQ_CLK_CSI1_ESC>, + <&clk IMX8MQ_CLK_CSI1_PHY_REF>; + clock-names = "core", "esc", "ui"; + assigned-clocks = <&clk IMX8MQ_CLK_CSI1_CORE>, + <&clk IMX8MQ_CLK_CSI1_PHY_REF>, + <&clk IMX8MQ_CLK_CSI1_ESC>; + assigned-clock-rates = <266000000>, <200000000>, <66000000>; + assigned-clock-parents = <&clk IMX8MQ_SYS1_PLL_266M>, + <&clk IMX8MQ_SYS2_PLL_1000M>, + <&clk IMX8MQ_SYS1_PLL_800M>; + power-domains = <&pgc_mipi_csi1>; + resets = <&src IMX8MQ_RESET_MIPI_CSI1_CORE_RESET>, + <&src IMX8MQ_RESET_MIPI_CSI1_PHY_REF_RESET>, + <&src IMX8MQ_RESET_MIPI_CSI1_ESC_RESET>; + fsl,mipi-phy-gpr = <&iomuxc_gpr 0x88>; + interconnects = <&noc IMX8MQ_ICM_CSI1 &noc IMX8MQ_ICS_DRAM>; + interconnect-names = "dram"; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + + imx8mm_mipi_csi_in: endpoint { + remote-endpoint = <&imx477_out>; + data-lanes = <1 2 3 4>; + }; + }; + + port@1 { + reg = <1>; + + imx8mm_mipi_csi_out: endpoint { + remote-endpoint = <&csi_in>; + }; + }; + }; + }; + +... -- cgit v1.2.3 From ea9f91199ca99dd9b3fba004b7614eed233ba1ac Mon Sep 17 00:00:00 2001 From: Stanimir Varbanov Date: Tue, 22 Jun 2021 13:39:56 +0200 Subject: media: docs: ext-ctrls-codec: Document cyclic intra-refresh zero control value In all drivers _CYCLIC_INTRA_REFRESH_MB default control value is zero which means that the macroblocks will not be intra-refreshed. Document this _CYCLIC_INTRA_REFRESH_MB control behaviour in control description. Acked-by: Hans Verkuil Signed-off-by: Stanimir Varbanov Signed-off-by: Mauro Carvalho Chehab --- Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst index dc096a5562cd..999b2360cef8 100644 --- a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst +++ b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst @@ -1174,7 +1174,9 @@ enum v4l2_mpeg_video_h264_entropy_mode - Cyclic intra macroblock refresh. This is the number of continuous macroblocks refreshed every frame. Each frame a successive set of macroblocks is refreshed until the cycle completes and starts from - the top of the frame. Applicable to H264, H263 and MPEG4 encoder. + the top of the frame. Setting this control to zero means that + macroblocks will not be refreshed. + Applicable to H264, H263 and MPEG4 encoder. ``V4L2_CID_MPEG_VIDEO_FRAME_RC_ENABLE (boolean)`` Frame level rate control enable. If this control is disabled then -- cgit v1.2.3 From 9d5adeecc409365e45cd89657f0392d0dd5c217f Mon Sep 17 00:00:00 2001 From: Stanimir Varbanov Date: Tue, 22 Jun 2021 13:39:57 +0200 Subject: media: v4l2-ctrls: Add intra-refresh period control Add a control to set intra-refresh period. Acked-by: Hans Verkuil Signed-off-by: Stanimir Varbanov Signed-off-by: Mauro Carvalho Chehab --- .../userspace-api/media/v4l/ext-ctrls-codec.rst | 17 ++++++++++++++++- 1 file changed, 16 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst index 999b2360cef8..976d34445a24 100644 --- a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst +++ b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst @@ -1175,9 +1175,24 @@ enum v4l2_mpeg_video_h264_entropy_mode - macroblocks refreshed every frame. Each frame a successive set of macroblocks is refreshed until the cycle completes and starts from the top of the frame. Setting this control to zero means that - macroblocks will not be refreshed. + macroblocks will not be refreshed. Note that this control will not + take effect when ``V4L2_CID_MPEG_VIDEO_INTRA_REFRESH_PERIOD`` control + is set to non zero value. Applicable to H264, H263 and MPEG4 encoder. +``V4L2_CID_MPEG_VIDEO_INTRA_REFRESH_PERIOD (integer)`` + Intra macroblock refresh period. This sets the period to refresh + the whole frame. In other words, this defines the number of frames + for which the whole frame will be intra-refreshed. An example: + setting period to 1 means that the whole frame will be refreshed, + setting period to 2 means that the half of macroblocks will be + intra-refreshed on frameX and the other half of macroblocks + will be refreshed in frameX + 1 and so on. Setting the period to + zero means no period is specified. + Note that if the client sets this control to non zero value the + ``V4L2_CID_MPEG_VIDEO_CYCLIC_INTRA_REFRESH_MB`` control shall be + ignored. Applicable to H264 and HEVC encoders. + ``V4L2_CID_MPEG_VIDEO_FRAME_RC_ENABLE (boolean)`` Frame level rate control enable. If this control is disabled then the quantization parameter for each frame type is constant and set -- cgit v1.2.3 From 55bccf1f93e4bf1b3209cc8648ab53f10f4601a5 Mon Sep 17 00:00:00 2001 From: Peter Zijlstra Date: Thu, 29 Jul 2021 16:17:20 +0200 Subject: Documentation/atomic_t: Document forward progress expectations Add a few words on forward progress; there's been quite a bit of confusion on the subject. Signed-off-by: Peter Zijlstra (Intel) Acked-by: Will Deacon Acked-by: Boqun Feng Link: https://lkml.kernel.org/r/YQK9ziyogxTH0m9H@hirez.programming.kicks-ass.net --- Documentation/atomic_t.txt | 53 ++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 53 insertions(+) (limited to 'Documentation') diff --git a/Documentation/atomic_t.txt b/Documentation/atomic_t.txt index a9c1e2b39b15..0f1ffa03db09 100644 --- a/Documentation/atomic_t.txt +++ b/Documentation/atomic_t.txt @@ -312,3 +312,56 @@ Usage: NB. try_cmpxchg() also generates better code on some platforms (notably x86) where the function more closely matches the hardware instruction. + + +FORWARD PROGRESS +---------------- + +In general strong forward progress is expected of all unconditional atomic +operations -- those in the Arithmetic and Bitwise classes and xchg(). However +a fair amount of code also requires forward progress from the conditional +atomic operations. + +Specifically 'simple' cmpxchg() loops are expected to not starve one another +indefinitely. However, this is not evident on LL/SC architectures, because +while an LL/SC architecure 'can/should/must' provide forward progress +guarantees between competing LL/SC sections, such a guarantee does not +transfer to cmpxchg() implemented using LL/SC. Consider: + + old = atomic_read(&v); + do { + new = func(old); + } while (!atomic_try_cmpxchg(&v, &old, new)); + +which on LL/SC becomes something like: + + old = atomic_read(&v); + do { + new = func(old); + } while (!({ + volatile asm ("1: LL %[oldval], %[v]\n" + " CMP %[oldval], %[old]\n" + " BNE 2f\n" + " SC %[new], %[v]\n" + " BNE 1b\n" + "2:\n" + : [oldval] "=&r" (oldval), [v] "m" (v) + : [old] "r" (old), [new] "r" (new) + : "memory"); + success = (oldval == old); + if (!success) + old = oldval; + success; })); + +However, even the forward branch from the failed compare can cause the LL/SC +to fail on some architectures, let alone whatever the compiler makes of the C +loop body. As a result there is no guarantee what so ever the cacheline +containing @v will stay on the local CPU and progress is made. + +Even native CAS architectures can fail to provide forward progress for their +primitive (See Sparc64 for an example). + +Such implementations are strongly encouraged to add exponential backoff loops +to a failed CAS in order to ensure some progress. Affected architectures are +also strongly encouraged to inspect/audit the atomic fallbacks, refcount_t and +their locking primitives. -- cgit v1.2.3 From 7a6226db072beeb63d4c3aaa844b0676ef7a027f Mon Sep 17 00:00:00 2001 From: Srinivas Pandruvada Date: Tue, 27 Jul 2021 09:22:40 -0700 Subject: ACPI: DPTF: Add new PCH FIVR methods Some additional information is required for updating PCH FIVR values upon WiFi channel changes. New attributes added to the existing sysfs: fivr_switching_freq_mhz : Get the FIVR switching control frequency. Uses ACPI method GFCS. fivr_switching_fault_status: Read the FIVR switching frequency control fault status. Uses ACPI method GFFS. ssc_clock_info : Presents SSC (spread spectrum clock) information for EMI (Electro magnetic interference) control. Use ACPI method GEMI (refer to the description of GEMI method below). GFFS This ACPI method is used to read the FIVR switching frequency control fault status. Bits Description [0:0] Fault status when set to 1 [31:1] Reserved GFCS This ACPI method is used to read the FIVR switching control frequency. Bits Description [11:0] Actual Frequency = value * XTAL_FREQ / 128 [31:12] Reserved GEMI This ACPI method is used to read the programmed register value for EMI (Electro magnetic interference) control. Bits Description [7:0] Sets clock spectrum spread percentage: 0x00=0.2% , 0x3F=10% 1 LSB = 0.1% increase in spread (for settings 0x01 thru 0x1C) 1 LSB = 0.2% increase in spread (for settings 0x1E thru 0x3F) [8] When set to 1, enables spread spectrum clock [9] 0: Triangle mode. FFC frequency walks around the Fcenter in a linear fashion 1: Random walk mode. FFC frequency changes randomly within the SSC (Spread spectrum clock) range [10] 0: No white noise. 1: Add white noise to spread waveform [11] When 1, future writes are ignored. Signed-off-by: Srinivas Pandruvada Signed-off-by: Rafael J. Wysocki --- Documentation/ABI/testing/sysfs-platform-dptf | 40 +++++++++++++++++++++++++++ 1 file changed, 40 insertions(+) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-platform-dptf b/Documentation/ABI/testing/sysfs-platform-dptf index 141834342a4d..53c6b1000320 100644 --- a/Documentation/ABI/testing/sysfs-platform-dptf +++ b/Documentation/ABI/testing/sysfs-platform-dptf @@ -111,3 +111,43 @@ Contact: linux-acpi@vger.kernel.org Description: (RW) The PCH FIVR (Fully Integrated Voltage Regulator) switching frequency in MHz, when FIVR clock is 38.4MHz. + +What: /sys/bus/platform/devices/INTC1045:00/pch_fivr_switch_frequency/fivr_switching_freq_mhz +Date: September, 2021 +KernelVersion: v5.15 +Contact: linux-acpi@vger.kernel.org +Description: + (RO) Get the FIVR switching control frequency in MHz. + +What: /sys/bus/platform/devices/INTC1045:00/pch_fivr_switch_frequency/fivr_switching_fault_status +Date: September, 2021 +KernelVersion: v5.15 +Contact: linux-acpi@vger.kernel.org +Description: + (RO) Read the FIVR switching frequency control fault status. + +What: /sys/bus/platform/devices/INTC1045:00/pch_fivr_switch_frequency/ssc_clock_info +Date: September, 2021 +KernelVersion: v5.15 +Contact: linux-acpi@vger.kernel.org +Description: + (RO) Presents SSC (spread spectrum clock) information for EMI + (Electro magnetic interference) control. This is a bit mask. + Bits Description + [7:0] Sets clock spectrum spread percentage: + 0x00=0.2% , 0x3F=10% + 1 LSB = 0.1% increase in spread (for + settings 0x01 thru 0x1C) + 1 LSB = 0.2% increase in spread (for + settings 0x1E thru 0x3F) + [8] When set to 1, enables spread + spectrum clock + [9] 0: Triangle mode. FFC frequency + walks around the Fcenter in a linear + fashion + 1: Random walk mode. FFC frequency + changes randomly within the SSC + (Spread spectrum clock) range + [10] 0: No white noise. 1: Add white noise + to spread waveform + [11] When 1, future writes are ignored. -- cgit v1.2.3 From f35ef8e4ea0a2b2b35a2c7009fc07b6d80a2b2f3 Mon Sep 17 00:00:00 2001 From: Konrad Dybcio Date: Wed, 28 Jul 2021 23:52:11 +0200 Subject: dt-bindings: remoteproc: qcom: adsp: Add SDM660 ADSP Add a compatible string for SDM660 ADSP. Signed-off-by: Konrad Dybcio Link: https://lore.kernel.org/r/20210728215212.18217-1-konrad.dybcio@somainline.org [bjorn: Use the -pas suffix] Signed-off-by: Bjorn Andersson --- Documentation/devicetree/bindings/remoteproc/qcom,adsp.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,adsp.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,adsp.yaml index c597ccced623..0c112f3264a9 100644 --- a/Documentation/devicetree/bindings/remoteproc/qcom,adsp.yaml +++ b/Documentation/devicetree/bindings/remoteproc/qcom,adsp.yaml @@ -28,6 +28,7 @@ properties: - qcom,sc8180x-adsp-pas - qcom,sc8180x-cdsp-pas - qcom,sc8180x-mpss-pas + - qcom,sdm660-adsp-pas - qcom,sdm845-adsp-pas - qcom,sdm845-cdsp-pas - qcom,sdx55-mpss-pas -- cgit v1.2.3 From 7c54b82b4545386bb576b7c5df5b8d4f95f11a5b Mon Sep 17 00:00:00 2001 From: Konrad Dybcio Date: Thu, 29 Jul 2021 00:25:17 +0200 Subject: arm64: dts: qcom: sdm630: Add TSENS node This will enable temperature reporting for various SoC components. Acked-by: Rob Herring Signed-off-by: AngeloGioacchino Del Regno Signed-off-by: Konrad Dybcio Link: https://lore.kernel.org/r/20210728222542.54269-15-konrad.dybcio@somainline.org Signed-off-by: Bjorn Andersson --- Documentation/devicetree/bindings/thermal/qcom-tsens.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml b/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml index 4a2eaf28e3fd..d3b9e9b600a2 100644 --- a/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml +++ b/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml @@ -48,6 +48,7 @@ properties: - qcom,sc7180-tsens - qcom,sc7280-tsens - qcom,sc8180x-tsens + - qcom,sdm630-tsens - qcom,sdm845-tsens - qcom,sm8150-tsens - qcom,sm8250-tsens -- cgit v1.2.3 From 9f2a5aebb03c19180e3be75ed7263c6ab510b75e Mon Sep 17 00:00:00 2001 From: Drew Fustini Date: Mon, 12 Jul 2021 23:30:18 -0700 Subject: dt-bindings: riscv: add starfive jh7100 bindings Add DT binding documentation for the StarFive JH7100 Soc [1] and the BeagleV Starlight JH7100 board [2]. [1] https://github.com/starfive-tech/beaglev_doc [2] https://github.com/beagleboard/beaglev-starlight Signed-off-by: Drew Fustini Reviewed-by: Rob Herring Reviewed-by: Bin Meng Signed-off-by: Palmer Dabbelt --- .../devicetree/bindings/riscv/starfive.yaml | 27 ++++++++++++++++++++++ 1 file changed, 27 insertions(+) create mode 100644 Documentation/devicetree/bindings/riscv/starfive.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/riscv/starfive.yaml b/Documentation/devicetree/bindings/riscv/starfive.yaml new file mode 100644 index 000000000000..5b36243fd674 --- /dev/null +++ b/Documentation/devicetree/bindings/riscv/starfive.yaml @@ -0,0 +1,27 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/riscv/starfive.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: StarFive SoC-based boards + +maintainers: + - Michael Zhu + - Drew Fustini + +description: + StarFive SoC-based boards + +properties: + $nodename: + const: '/' + compatible: + oneOf: + - items: + - const: beagle,beaglev-starlight-jh7100-r0 + - const: starfive,jh7100 + +additionalProperties: true + +... -- cgit v1.2.3 From a95fc720844154acc79064c222335165fe7cb136 Mon Sep 17 00:00:00 2001 From: Caleb Connolly Date: Thu, 8 Apr 2021 16:21:14 +0000 Subject: dt-bindings: qcom: geni-se: document iommus Document the iommus property for QCOM Geni SE. Signed-off-by: Caleb Connolly Acked-by: Rob Herring Link: https://lore.kernel.org/r/20210408161953.26298-4-caleb@connolly.tech Signed-off-by: Bjorn Andersson --- Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.yaml | 3 +++ 1 file changed, 3 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.yaml index 4663c2bcad50..a776cd37c297 100644 --- a/Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.yaml +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.yaml @@ -51,6 +51,9 @@ properties: interconnect-names: const: qup-core + iommus: + maxItems: 1 + required: - compatible - reg -- cgit v1.2.3 From fed4c105acff35bc6e996b28aee5e91faaf5c192 Mon Sep 17 00:00:00 2001 From: Artjom Vejsel Date: Wed, 4 Aug 2021 03:23:52 +0300 Subject: dt-bindings: Add DT bindings for QiShenglong Gopher 2b panel Add DT bindings for QiShenglong Gopher 2b 4.3" 480(RGB)x272 TFT LCD panel. Signed-off-by: Artjom Vejsel Signed-off-by: Paul Cercueil Link: https://patchwork.freedesktop.org/patch/msgid/20210804002353.76385-3-akawolf0@gmail.com --- Documentation/devicetree/bindings/display/panel/panel-simple.yaml | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml index 81bdfb03bcea..335776c45474 100644 --- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml +++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml @@ -256,6 +256,8 @@ properties: - powertip,ph800480t013-idf02 # QiaoDian XianShi Corporation 4"3 TFT LCD panel - qiaodian,qd43003c0-40 + # Shenzhen QiShenglong Industrialist Co., Ltd. Gopher 2b 4.3" 480(RGB)x272 TFT LCD panel + - qishenglong,gopher2b-lcd # Rocktech Displays Ltd. RK101II01D-CT 10.1" TFT 1280x800 - rocktech,rk101ii01d-ct # Rocktech Display Ltd. RK070ER9427 800(RGB)x480 TFT LCD panel -- cgit v1.2.3 From 7dbdce8062687de103cba58bb2eded922cd41110 Mon Sep 17 00:00:00 2001 From: Dillon Min Date: Sat, 24 Jul 2021 11:44:01 +0800 Subject: dt-bindings: display: panel: Add ilitek ili9341 panel bindings Add documentation for "ilitek,ili9341" panel. Signed-off-by: Dillon Min Reviewed-by: Linus Walleij Reviewed-by: Rob Herring Link: https://lore.kernel.org/lkml/1626853288-31223-2-git-send-email-dillon.minfei@gmail.com/ Signed-off-by: Linus Walleij Link: https://patchwork.freedesktop.org/patch/msgid/1627098243-2742-2-git-send-email-dillon.minfei@gmail.com --- .../bindings/display/panel/ilitek,ili9341.yaml | 78 ++++++++++++++++++++++ 1 file changed, 78 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/panel/ilitek,ili9341.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/panel/ilitek,ili9341.yaml b/Documentation/devicetree/bindings/display/panel/ilitek,ili9341.yaml new file mode 100644 index 000000000000..2ed010f91e2d --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/ilitek,ili9341.yaml @@ -0,0 +1,78 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/panel/ilitek,ili9341.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Ilitek-9341 Display Panel + +maintainers: + - Dillon Min + +description: | + Ilitek ILI9341 TFT panel driver with SPI control bus + This is a driver for 320x240 TFT panels, accepting a rgb input + streams with 16 bits or 18 bits. + +allOf: + - $ref: panel-common.yaml# + +properties: + compatible: + items: + - enum: + # ili9341 240*320 Color on stm32f429-disco board + - st,sf-tc240t-9370-t + - const: ilitek,ili9341 + + reg: true + + dc-gpios: + maxItems: 1 + description: Display data/command selection (D/CX) of this DBI panel + + spi-3wire: true + + spi-max-frequency: + const: 10000000 + + port: true + + vci-supply: + description: Analog voltage supply (2.5 .. 3.3V) + + vddi-supply: + description: Voltage supply for interface logic (1.65 .. 3.3 V) + + vddi-led-supply: + description: Voltage supply for the LED driver (1.65 .. 3.3 V) + +additionalProperties: false + +required: + - compatible + - reg + - dc-gpios + - port + +examples: + - |+ + spi { + #address-cells = <1>; + #size-cells = <0>; + panel: display@0 { + compatible = "st,sf-tc240t-9370-t", + "ilitek,ili9341"; + reg = <0>; + spi-3wire; + spi-max-frequency = <10000000>; + dc-gpios = <&gpiod 13 0>; + port { + panel_in: endpoint { + remote-endpoint = <&display_out>; + }; + }; + }; + }; +... + -- cgit v1.2.3 From 60625667c439e6e1945d464b6eb296d144c5cb2a Mon Sep 17 00:00:00 2001 From: Igor Skalkin Date: Tue, 3 Aug 2021 14:10:22 +0100 Subject: dt-bindings: arm: Add virtio transport for SCMI Document the properties for arm,scmi-virtio compatible nodes. The backing virtio SCMI device is described in patch [1]. While doing that, make shmem property required only for pre-existing mailbox and smc transports, since virtio-scmi does not need it. [1] https://lists.oasis-open.org/archives/virtio-comment/202102/msg00018.html Link: https://lore.kernel.org/r/20210803131024.40280-14-cristian.marussi@arm.com Co-developed-by: Peter Hilber Reviewed-by: Rob Herring Signed-off-by: Igor Skalkin [ Peter: Adapted patch for submission to upstream. ] Signed-off-by: Peter Hilber [ Cristian: converted to yaml format, moved shmen required property. ] Signed-off-by: Cristian Marussi Signed-off-by: Sudeep Holla --- Documentation/devicetree/bindings/firmware/arm,scmi.yaml | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml index cebf6ffe70d5..5c4c6782e052 100644 --- a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml +++ b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml @@ -34,6 +34,10 @@ properties: - description: SCMI compliant firmware with ARM SMC/HVC transport items: - const: arm,scmi-smc + - description: SCMI compliant firmware with SCMI Virtio transport. + The virtio transport only supports a single device. + items: + - const: arm,scmi-virtio interrupts: description: @@ -172,6 +176,7 @@ patternProperties: Each sub-node represents a protocol supported. If the platform supports a dedicated communication channel for a particular protocol, then the corresponding transport properties must be present. + The virtio transport does not support a dedicated communication channel. properties: reg: @@ -195,7 +200,6 @@ patternProperties: required: - compatible - - shmem if: properties: @@ -209,6 +213,7 @@ then: required: - mboxes + - shmem else: if: @@ -219,6 +224,7 @@ else: then: required: - arm,smc-id + - shmem examples: - | -- cgit v1.2.3 From 9c0edd5649a26e380ed2e687a20f7b301a66c746 Mon Sep 17 00:00:00 2001 From: Hu Haowen Date: Thu, 5 Aug 2021 12:01:46 +0800 Subject: docs: usb: fix malformed table The tables are separated with tabs and spaces mixed together, leading to malformation. Changed the characters all into spaces to solve this issue. Signed-off-by: Hu Haowen Link: https://lore.kernel.org/r/20210805040146.121526-1-src.res@email.cn Signed-off-by: Greg Kroah-Hartman --- Documentation/usb/gadget-testing.rst | 84 ++++++++++++++++++------------------ 1 file changed, 42 insertions(+), 42 deletions(-) (limited to 'Documentation') diff --git a/Documentation/usb/gadget-testing.rst b/Documentation/usb/gadget-testing.rst index d6253f1a32a1..c18113077889 100644 --- a/Documentation/usb/gadget-testing.rst +++ b/Documentation/usb/gadget-testing.rst @@ -724,28 +724,28 @@ Function-specific configfs interface The function name to use when creating the function directory is "uac2". The uac2 function provides these attributes in its function directory: - =============== ==================================================== - c_chmask capture channel mask - c_srate capture sampling rate - c_ssize capture sample size (bytes) - c_sync capture synchronization type (async/adaptive) - c_mute_present capture mute control enable - c_volume_present capture volume control enable - c_volume_min capture volume control min value (in 1/256 dB) - c_volume_max capture volume control max value (in 1/256 dB) - c_volume_res capture volume control resolution (in 1/256 dB) - fb_max maximum extra bandwidth in async mode - p_chmask playback channel mask - p_srate playback sampling rate - p_ssize playback sample size (bytes) - p_mute_present playback mute control enable - p_volume_present playback volume control enable - p_volume_min playback volume control min value (in 1/256 dB) - p_volume_max playback volume control max value (in 1/256 dB) - p_volume_res playback volume control resolution (in 1/256 dB) - req_number the number of pre-allocated request for both capture - and playback - =============== ==================================================== + ================ ==================================================== + c_chmask capture channel mask + c_srate capture sampling rate + c_ssize capture sample size (bytes) + c_sync capture synchronization type (async/adaptive) + c_mute_present capture mute control enable + c_volume_present capture volume control enable + c_volume_min capture volume control min value (in 1/256 dB) + c_volume_max capture volume control max value (in 1/256 dB) + c_volume_res capture volume control resolution (in 1/256 dB) + fb_max maximum extra bandwidth in async mode + p_chmask playback channel mask + p_srate playback sampling rate + p_ssize playback sample size (bytes) + p_mute_present playback mute control enable + p_volume_present playback volume control enable + p_volume_min playback volume control min value (in 1/256 dB) + p_volume_max playback volume control max value (in 1/256 dB) + p_volume_res playback volume control resolution (in 1/256 dB) + req_number the number of pre-allocated request for both capture + and playback + ================ ==================================================== The attributes have sane default values. @@ -914,26 +914,26 @@ Function-specific configfs interface The function name to use when creating the function directory is "uac1". The uac1 function provides these attributes in its function directory: - ========== ==================================================== - c_chmask capture channel mask - c_srate capture sampling rate - c_ssize capture sample size (bytes) - c_mute_present capture mute control enable - c_volume_present capture volume control enable - c_volume_min capture volume control min value (in 1/256 dB) - c_volume_max capture volume control max value (in 1/256 dB) - c_volume_res capture volume control resolution (in 1/256 dB) - p_chmask playback channel mask - p_srate playback sampling rate - p_ssize playback sample size (bytes) - p_mute_present playback mute control enable - p_volume_present playback volume control enable - p_volume_min playback volume control min value (in 1/256 dB) - p_volume_max playback volume control max value (in 1/256 dB) - p_volume_res playback volume control resolution (in 1/256 dB) - req_number the number of pre-allocated request for both capture - and playback - ========== ==================================================== + ================ ==================================================== + c_chmask capture channel mask + c_srate capture sampling rate + c_ssize capture sample size (bytes) + c_mute_present capture mute control enable + c_volume_present capture volume control enable + c_volume_min capture volume control min value (in 1/256 dB) + c_volume_max capture volume control max value (in 1/256 dB) + c_volume_res capture volume control resolution (in 1/256 dB) + p_chmask playback channel mask + p_srate playback sampling rate + p_ssize playback sample size (bytes) + p_mute_present playback mute control enable + p_volume_present playback volume control enable + p_volume_min playback volume control min value (in 1/256 dB) + p_volume_max playback volume control max value (in 1/256 dB) + p_volume_res playback volume control resolution (in 1/256 dB) + req_number the number of pre-allocated request for both capture + and playback + ================ ==================================================== The attributes have sane default values. -- cgit v1.2.3 From 177cd475e1f12d256c9bf7de274fef7bea30cddb Mon Sep 17 00:00:00 2001 From: Biju Das Date: Tue, 27 Jul 2021 19:55:26 +0100 Subject: dt-bindings: usb: renesas,usbhs: Document RZ/G2L bindings Document RZ/G2L (R9A07G044L) SoC bindings. Signed-off-by: Biju Das Reviewed-by: Lad Prabhakar Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20210727185527.19907-6-biju.das.jz@bp.renesas.com Signed-off-by: Greg Kroah-Hartman --- .../devicetree/bindings/usb/renesas,usbhs.yaml | 26 ++++++++++++++++++++-- 1 file changed, 24 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/usb/renesas,usbhs.yaml b/Documentation/devicetree/bindings/usb/renesas,usbhs.yaml index ad73339ffe1d..012fe80a7611 100644 --- a/Documentation/devicetree/bindings/usb/renesas,usbhs.yaml +++ b/Documentation/devicetree/bindings/usb/renesas,usbhs.yaml @@ -17,7 +17,9 @@ properties: - const: renesas,rza1-usbhs - items: - - const: renesas,usbhs-r7s9210 # RZ/A2 + - enum: + - renesas,usbhs-r7s9210 # RZ/A2 + - renesas,usbhs-r9a07g044 # RZ/G2{L,LC} - const: renesas,rza2-usbhs - items: @@ -59,7 +61,8 @@ properties: - description: USB 2.0 clock selector interrupts: - maxItems: 1 + minItems: 1 + maxItems: 4 renesas,buswait: $ref: /schemas/types.yaml#/definitions/uint32 @@ -108,6 +111,25 @@ required: - clocks - interrupts +allOf: + - if: + properties: + compatible: + contains: + const: renesas,usbhs-r9a07g044 + then: + properties: + interrupts: + items: + - description: U2P_IXL_INT + - description: U2P_INT_DMA[0] + - description: U2P_INT_DMA[1] + - description: U2P_INT_DMAERR + else: + properties: + interrupts: + maxItems: 1 + additionalProperties: false examples: -- cgit v1.2.3 From 1a191ddcc76f810654e52aab5a36c399d82e26a0 Mon Sep 17 00:00:00 2001 From: Tony Lindgren Date: Tue, 27 Jul 2021 13:35:32 +0300 Subject: dt-bindings: serial: 8250: Update for standard overrun-throttle property In some cases we want to specify overrun-throttle like other 8250 drivers are doing. Cc: devicetree@vger.kernel.org Cc: Rob Herring Cc: Vignesh Raghavendra Acked-by: Rob Herring Signed-off-by: Tony Lindgren Link: https://lore.kernel.org/r/20210727103533.51547-1-tony@atomide.com Signed-off-by: Greg Kroah-Hartman --- Documentation/devicetree/bindings/serial/8250_omap.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/serial/8250_omap.yaml b/Documentation/devicetree/bindings/serial/8250_omap.yaml index 1c826fcf5828..ab0c0feed8f0 100644 --- a/Documentation/devicetree/bindings/serial/8250_omap.yaml +++ b/Documentation/devicetree/bindings/serial/8250_omap.yaml @@ -79,6 +79,7 @@ properties: power-domains: true clock-frequency: true current-speed: true + overrun-throttle-ms: true required: - compatible -- cgit v1.2.3 From f9d8f4b3131cc84d3faf3210d9c22947fc53691d Mon Sep 17 00:00:00 2001 From: Sebastian Reichel Date: Mon, 2 Aug 2021 19:23:07 +0200 Subject: dt-bindings: misc: ge-achc: Convert to DT schema format Convert the binding to DT schema format. Also update the binding to fix shortcomings * Add "nxp,kinetis-k20" fallback compatible * add programming SPI interface and reset GPIO * add main clock * add voltage supplies * drop spi-max-frequency from required properties, driver will setup max. frequency Reviewed-by: Rob Herring Signed-off-by: Sebastian Reichel Link: https://lore.kernel.org/r/20210802172309.164365-2-sebastian.reichel@collabora.com Signed-off-by: Greg Kroah-Hartman --- Documentation/devicetree/bindings/misc/ge-achc.txt | 26 --------- .../devicetree/bindings/misc/ge-achc.yaml | 65 ++++++++++++++++++++++ 2 files changed, 65 insertions(+), 26 deletions(-) delete mode 100644 Documentation/devicetree/bindings/misc/ge-achc.txt create mode 100644 Documentation/devicetree/bindings/misc/ge-achc.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/misc/ge-achc.txt b/Documentation/devicetree/bindings/misc/ge-achc.txt deleted file mode 100644 index 77df94d7a32f..000000000000 --- a/Documentation/devicetree/bindings/misc/ge-achc.txt +++ /dev/null @@ -1,26 +0,0 @@ -* 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>; -}; diff --git a/Documentation/devicetree/bindings/misc/ge-achc.yaml b/Documentation/devicetree/bindings/misc/ge-achc.yaml new file mode 100644 index 000000000000..ff07aa62ed57 --- /dev/null +++ b/Documentation/devicetree/bindings/misc/ge-achc.yaml @@ -0,0 +1,65 @@ +# SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause +# Copyright (C) 2021 GE Inc. +# Copyright (C) 2021 Collabora Ltd. +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/misc/ge-achc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: GE Healthcare USB Management Controller + +description: | + A device which handles data acquisition from compatible USB based peripherals. + SPI is used for device management. + + Note: This device does not expose the peripherals as USB devices. + +maintainers: + - Sebastian Reichel + +properties: + compatible: + items: + - const: ge,achc + - const: nxp,kinetis-k20 + + clocks: + maxItems: 1 + + vdd-supply: + description: Digital power supply regulator on VDD pin + + vdda-supply: + description: Analog power supply regulator on VDDA pin + + reg: + items: + - description: Control interface + - description: Firmware programming interface + + reset-gpios: + description: GPIO used for hardware reset. + maxItems: 1 + +required: + - compatible + - clocks + - reg + - reset-gpios + +additionalProperties: false + +examples: + - | + #include + spi { + #address-cells = <1>; + #size-cells = <0>; + + spi@1 { + compatible = "ge,achc", "nxp,kinetis-k20"; + reg = <1>, <0>; + clocks = <&achc_24M>; + reset-gpios = <&gpio3 6 GPIO_ACTIVE_LOW>; + }; + }; -- cgit v1.2.3 From 0f920277dc22cb794f0572ee5d3423388453435d Mon Sep 17 00:00:00 2001 From: Sebastian Reichel Date: Mon, 2 Aug 2021 19:23:09 +0200 Subject: misc: gehc-achc: new driver General Electric Healthcare's PPD has a secondary processor from NXP's Kinetis K20 series. That device has two SPI chip selects: The main interface's behaviour depends on the loaded firmware and is currently unused. The secondary interface can be used to update the firmware using EzPort protocol. This is implemented by this driver using the kernel's firmware API. The firmware is being flashed into non-volatile flash memory, so it is enough to flash it once and not on every boot. Flashing will wear the flash memory (it has a life time of at least 10k programming cycles). At the same time only occasional FW updates are expected (like e.g. a BIOS update). Thus the firmware update is triggered via sysfs instead of doing it in the driver's probe routine like many other drivers. Signed-off-by: Sebastian Reichel Link: https://lore.kernel.org/r/20210802172309.164365-4-sebastian.reichel@collabora.com Signed-off-by: Greg Kroah-Hartman --- Documentation/ABI/testing/sysfs-driver-ge-achc | 15 +++++++++++++++ 1 file changed, 15 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-driver-ge-achc (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-driver-ge-achc b/Documentation/ABI/testing/sysfs-driver-ge-achc new file mode 100644 index 000000000000..a9e7a079190c --- /dev/null +++ b/Documentation/ABI/testing/sysfs-driver-ge-achc @@ -0,0 +1,15 @@ +What: /sys/bus/spi//update_firmware +Date: Jul 2021 +Contact: sebastian.reichel@collabora.com +Description: Write 1 to this file to update the ACHC microcontroller + firmware via the EzPort interface. For this the kernel + will load "achc.bin" via the firmware API (so usually + from /lib/firmware). The write will block until the FW + has either been flashed successfully or an error occured. + +What: /sys/bus/spi//reset +Date: Jul 2021 +Contact: sebastian.reichel@collabora.com +Description: This file represents the microcontroller's reset line. + 1 means the reset line is asserted, 0 means it's not + asserted. The file is read and writable. -- cgit v1.2.3 From e9dd2f7204edbc8ae6842f87a187ade04e381809 Mon Sep 17 00:00:00 2001 From: Vinod Koul Date: Mon, 8 Mar 2021 11:38:14 +0530 Subject: dt-bindings: arm: qcom: Document alcatel,idol347 board Document the alcatel,idol347 board. It was missing leading to warning: arch/arm64/boot/dts/qcom/msm8916-alcatel-idol347.dt.yaml: /: compatible: 'oneOf' conditional failed, one must be fixed: Additional items are not allowed ('qcom,msm8916' was unexpected) Signed-off-by: Vinod Koul Link: https://lore.kernel.org/r/20210308060826.3074234-7-vkoul@kernel.org Signed-off-by: Bjorn Andersson --- Documentation/devicetree/bindings/arm/qcom.yaml | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml index 9720b00c41d2..32a33de72ec7 100644 --- a/Documentation/devicetree/bindings/arm/qcom.yaml +++ b/Documentation/devicetree/bindings/arm/qcom.yaml @@ -129,6 +129,8 @@ properties: - const: qcom,msm8974 - items: + - enum: + - alcatel,idol347 - const: qcom,msm8916-mtp/1 - const: qcom,msm8916-mtp - const: qcom,msm8916 -- cgit v1.2.3 From 14fec168bf8c654b3c849a98b5ad2195682e8b7a Mon Sep 17 00:00:00 2001 From: Rajendra Nayak Date: Wed, 4 Aug 2021 18:33:18 +0530 Subject: dt-bindings: arm: qcom: Document qcom,sc7280-idp2 board Document the qcom,sc7280-idp2 board based off sc7280 SoC, The board is also known as piglin in the Chrome OS builds, so document the google,piglin compatible as well. Signed-off-by: Rajendra Nayak Reviewed-by: Stephen Boyd Link: https://lore.kernel.org/r/1628082199-17002-2-git-send-email-rnayak@codeaurora.org Signed-off-by: Bjorn Andersson --- Documentation/devicetree/bindings/arm/qcom.yaml | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml index 32a33de72ec7..c0c01be63b24 100644 --- a/Documentation/devicetree/bindings/arm/qcom.yaml +++ b/Documentation/devicetree/bindings/arm/qcom.yaml @@ -183,6 +183,8 @@ properties: - items: - enum: - qcom,sc7280-idp + - qcom,sc7280-idp2 + - google,piglin - google,senor - const: qcom,sc7280 -- cgit v1.2.3 From ce5db043d2e8811f30de3ebb5d9e6bd8a33596c4 Mon Sep 17 00:00:00 2001 From: Hsin-Yi Wang Date: Tue, 22 Jun 2021 11:07:43 +0800 Subject: dt-bindings: mediatek: Add optional mediatek,gce-events property This property is used by gce clients. Signed-off-by: Hsin-Yi Wang Acked-by: Rob Herring Link: https://lore.kernel.org/r/20210622030741.2120393-2-hsinyi@chromium.org Signed-off-by: Matthias Brugger --- Documentation/devicetree/bindings/mailbox/mtk-gce.txt | 15 +++++++++++++++ 1 file changed, 15 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mailbox/mtk-gce.txt b/Documentation/devicetree/bindings/mailbox/mtk-gce.txt index 7771ecaac586..2ef7ff67cb2b 100644 --- a/Documentation/devicetree/bindings/mailbox/mtk-gce.txt +++ b/Documentation/devicetree/bindings/mailbox/mtk-gce.txt @@ -35,6 +35,10 @@ Optional properties for a client device: start_offset: the start offset of register address that GCE can access. size: the total size of register address that GCE can access. +Optional properties for a client mutex node: +- mediatek,gce-events: GCE events used by clients. The event numbers are + defined in 'dt-bindings/gce/-gce.h'. + Some vaules of properties are defined in 'dt-bindings/gce/mt8173-gce.h', 'dt-binding/gce/mt8183-gce.h' or 'dt-bindings/gce/mt6779-gce.h'. Such as sub-system ids, thread priority, event ids. @@ -62,3 +66,14 @@ Example for a client device: <&gce SUBSYS_1401XXXX 0x2000 0x100>; ... }; + +Example for a client mutex node: + mutex: mutex@14020000 { + compatible = "mediatek,mt8173-disp-mutex"; + reg = <0 0x14020000 0 0x1000>; + interrupts = ; + power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>; + clocks = <&mmsys CLK_MM_MUTEX_32K>; + mediatek,gce-events = , + ; + }; -- cgit v1.2.3 From 00555272dcdae71e96de08c924c4fef6b47d7e5b Mon Sep 17 00:00:00 2001 From: Vladimir Lypak Date: Thu, 5 Aug 2021 17:19:29 +0000 Subject: dt-bindings: clock: qcom-rpmcc: Add compatible for MSM8953 SoC Add compatible for MSM8953 SoC. Signed-off-by: Vladimir Lypak Signed-off-by: Sireesh Kodali Link: https://lore.kernel.org/r/c662hoLme5MIdelk5BVPsVgN77IqTLS0KwYwpauJiDs@cp3-web-047.plabs.ch 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 0e92747e53da..bffd2acdbb66 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-msm8226", "qcom,rpmcc" "qcom,rpmcc-msm8916", "qcom,rpmcc" "qcom,rpmcc-msm8936", "qcom,rpmcc" + "qcom,rpmcc-msm8953", "qcom,rpmcc" "qcom,rpmcc-msm8974", "qcom,rpmcc" "qcom,rpmcc-msm8976", "qcom,rpmcc" "qcom,rpmcc-apq8064", "qcom,rpmcc" -- cgit v1.2.3 From c45e13fa3851e825c279c2cb0b7f6961f36f1095 Mon Sep 17 00:00:00 2001 From: Konrad Dybcio Date: Fri, 6 Aug 2021 00:23:59 +0200 Subject: dt-bindings: clock: qcom: rpmcc: Document MDM9607 compatible Add the dt-binding for the RPM Clock Controller on the MDM9607 SoC. Signed-off-by: Konrad Dybcio Link: https://lore.kernel.org/r/20210805222400.39027-1-konrad.dybcio@somainline.org 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 bffd2acdbb66..a4877881f1d8 100644 --- a/Documentation/devicetree/bindings/clock/qcom,rpmcc.txt +++ b/Documentation/devicetree/bindings/clock/qcom,rpmcc.txt @@ -10,6 +10,7 @@ Required properties : - compatible : shall contain only one of the following. The generic compatible "qcom,rpmcc" should be also included. + "qcom,rpmcc-mdm9607", "qcom,rpmcc" "qcom,rpmcc-msm8660", "qcom,rpmcc" "qcom,rpmcc-apq8060", "qcom,rpmcc" "qcom,rpmcc-msm8226", "qcom,rpmcc" -- cgit v1.2.3 From 945cb3a105aef63af1354e0fbe10a0d1ca7a32c2 Mon Sep 17 00:00:00 2001 From: Bjorn Andersson Date: Wed, 21 Jul 2021 15:53:29 -0700 Subject: clk: qcom: gpucc-sm8150: Add SC8180x support The GPU clock controller found in SC8180x is a variant of the same block found in SM8150, but with one additional clock frequency for the gmu_clk_src clock. Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20210721225329.3035779-1-bjorn.andersson@linaro.org Acked-by: Rob Herring Signed-off-by: Stephen Boyd --- Documentation/devicetree/bindings/clock/qcom,gpucc.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/qcom,gpucc.yaml b/Documentation/devicetree/bindings/clock/qcom,gpucc.yaml index ecfe21284073..46dff46d5760 100644 --- a/Documentation/devicetree/bindings/clock/qcom,gpucc.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,gpucc.yaml @@ -26,6 +26,7 @@ properties: - qcom,sdm845-gpucc - qcom,sc7180-gpucc - qcom,sc7280-gpucc + - qcom,sc8180x-gpucc - qcom,sm8150-gpucc - qcom,sm8250-gpucc -- cgit v1.2.3 From f9a6a326f66dfb7d62cef79c6755cc773e5fb8ad Mon Sep 17 00:00:00 2001 From: Shawn Guo Date: Sun, 4 Jul 2021 10:40:31 +0800 Subject: dt-bindings: clock: Update qcom,a53pll bindings for MSM8939 support Update qcom,a53pll bindings for MSM8939 support: - Add optional operating-points-v2 property - Add MSM8939 specific compatible Signed-off-by: Shawn Guo Link: https://lore.kernel.org/r/20210704024032.11559-4-shawn.guo@linaro.org Acked-by: Rob Herring Signed-off-by: Stephen Boyd --- Documentation/devicetree/bindings/clock/qcom,a53pll.yaml | 3 +++ 1 file changed, 3 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/qcom,a53pll.yaml b/Documentation/devicetree/bindings/clock/qcom,a53pll.yaml index db3d0ea6bc7a..fbd758470b88 100644 --- a/Documentation/devicetree/bindings/clock/qcom,a53pll.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,a53pll.yaml @@ -18,6 +18,7 @@ properties: enum: - qcom,ipq6018-a53pll - qcom,msm8916-a53pll + - qcom,msm8939-a53pll reg: maxItems: 1 @@ -33,6 +34,8 @@ properties: items: - const: xo + operating-points-v2: true + required: - compatible - reg -- cgit v1.2.3 From 88d8175ad8badc74d0d53308dbbbf65b1eb0cebb Mon Sep 17 00:00:00 2001 From: Dong Aisheng Date: Thu, 15 Jul 2021 16:25:33 +0800 Subject: dt-bindings: phy: imx8mq-usb-phy: convert to json schema Convert to jason schema. Cc: Kishon Vijay Abraham I Cc: Vinod Koul Cc: Rob Herring Cc: Li Jun Cc: linux-phy@lists.infradead.org Signed-off-by: Dong Aisheng Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20210715082536.1882077-5-aisheng.dong@nxp.com Signed-off-by: Vinod Koul --- .../devicetree/bindings/phy/fsl,imx8mq-usb-phy.txt | 20 -------- .../bindings/phy/fsl,imx8mq-usb-phy.yaml | 53 ++++++++++++++++++++++ 2 files changed, 53 insertions(+), 20 deletions(-) delete mode 100644 Documentation/devicetree/bindings/phy/fsl,imx8mq-usb-phy.txt create mode 100644 Documentation/devicetree/bindings/phy/fsl,imx8mq-usb-phy.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/phy/fsl,imx8mq-usb-phy.txt b/Documentation/devicetree/bindings/phy/fsl,imx8mq-usb-phy.txt deleted file mode 100644 index 7c70f2ad9942..000000000000 --- a/Documentation/devicetree/bindings/phy/fsl,imx8mq-usb-phy.txt +++ /dev/null @@ -1,20 +0,0 @@ -* Freescale i.MX8MQ USB3 PHY binding - -Required properties: -- compatible: Should be "fsl,imx8mq-usb-phy" or "fsl,imx8mp-usb-phy" -- #phys-cells: must be 0 (see phy-bindings.txt in this directory) -- reg: The base address and length of the registers -- clocks: phandles to the clocks for each clock listed in clock-names -- clock-names: must contain "phy" - -Optional properties: -- vbus-supply: A phandle to the regulator for USB VBUS. - -Example: - usb3_phy0: phy@381f0040 { - compatible = "fsl,imx8mq-usb-phy"; - reg = <0x381f0040 0x40>; - clocks = <&clk IMX8MQ_CLK_USB1_PHY_ROOT>; - clock-names = "phy"; - #phy-cells = <0>; - }; diff --git a/Documentation/devicetree/bindings/phy/fsl,imx8mq-usb-phy.yaml b/Documentation/devicetree/bindings/phy/fsl,imx8mq-usb-phy.yaml new file mode 100644 index 000000000000..2936f3510a6a --- /dev/null +++ b/Documentation/devicetree/bindings/phy/fsl,imx8mq-usb-phy.yaml @@ -0,0 +1,53 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/phy/fsl,imx8mq-usb-phy.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Freescale i.MX8MQ USB3 PHY binding + +maintainers: + - Li Jun + +properties: + compatible: + enum: + - fsl,imx8mq-usb-phy + - fsl,imx8mp-usb-phy + + reg: + maxItems: 1 + + "#phy-cells": + const: 0 + + clocks: + maxItems: 1 + + clock-names: + items: + - const: phy + + vbus-supply: + description: + A phandle to the regulator for USB VBUS. + +required: + - compatible + - reg + - "#phy-cells" + - clocks + - clock-names + +additionalProperties: false + +examples: + - | + #include + usb3_phy0: phy@381f0040 { + compatible = "fsl,imx8mq-usb-phy"; + reg = <0x381f0040 0x40>; + clocks = <&clk IMX8MQ_CLK_USB1_PHY_ROOT>; + clock-names = "phy"; + #phy-cells = <0>; + }; -- cgit v1.2.3 From c52c90dbcb8c2676dab22cb21c0f0c5da527dfd3 Mon Sep 17 00:00:00 2001 From: Chunfeng Yun Date: Fri, 23 Jul 2021 16:22:40 +0800 Subject: dt-bindings: phy: mediatek: tphy: add support hardware version 3 The PHYA architecture is updated, and doesn't support slew rate calibration anymore on 7nm or advanced process, add a new version number to support it. Due to the FreqMeter bank is not used but reserved, it's backward with v2 until now. For mt8195, no function changes when use generic v2 or v3 compatible, but prefer to use v3's compatible, it will not waste the time to calibrate the slew rate, and also correspond with hardware version. Acked-by: Rob Herring Signed-off-by: Chunfeng Yun Link: https://lore.kernel.org/r/1627028562-23584-1-git-send-email-chunfeng.yun@mediatek.com Signed-off-by: Vinod Koul --- Documentation/devicetree/bindings/phy/mediatek,tphy.yaml | 14 +++++++++----- 1 file changed, 9 insertions(+), 5 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/phy/mediatek,tphy.yaml b/Documentation/devicetree/bindings/phy/mediatek,tphy.yaml index ef9d9d4e6875..838852cb8527 100644 --- a/Documentation/devicetree/bindings/phy/mediatek,tphy.yaml +++ b/Documentation/devicetree/bindings/phy/mediatek,tphy.yaml @@ -15,7 +15,7 @@ description: | controllers on MediaTek SoCs, includes USB2.0, USB3.0, PCIe and SATA. Layout differences of banks between T-PHY V1 (mt8173/mt2701) and - T-PHY V2 (mt2712) when works on USB mode: + T-PHY V2 (mt2712) / V3 (mt8195) when works on USB mode: ----------------------------------- Version 1: port offset bank @@ -34,7 +34,7 @@ description: | u2 port2 0x1800 U2PHY_COM ... - Version 2: + Version 2/3: port offset bank u2 port0 0x0000 MISC 0x0100 FMREG @@ -59,7 +59,8 @@ description: | SPLLC shared by u3 ports and FMREG shared by u2 ports on V1 are put back into each port; a new bank MISC for u2 ports and CHIP for u3 ports are - added on V2. + added on V2; the FMREG bank for slew rate calibration is not used anymore + and reserved on V3; properties: $nodename: @@ -79,8 +80,11 @@ properties: - mediatek,mt2712-tphy - mediatek,mt7629-tphy - mediatek,mt8183-tphy - - mediatek,mt8195-tphy - const: mediatek,generic-tphy-v2 + - items: + - enum: + - mediatek,mt8195-tphy + - const: mediatek,generic-tphy-v3 - const: mediatek,mt2701-u3phy deprecated: true - const: mediatek,mt2712-u3phy @@ -91,7 +95,7 @@ properties: description: Register shared by multiple ports, exclude port's private register. It is needed for T-PHY V1, such as mt2701 and mt8173, but not for - T-PHY V2, such as mt2712. + T-PHY V2/V3, such as mt2712. maxItems: 1 "#address-cells": -- cgit v1.2.3 From 1a00d130596f863243b1a0aa527dd66ecee70065 Mon Sep 17 00:00:00 2001 From: Bjorn Andersson Date: Wed, 21 Jul 2021 15:56:29 -0700 Subject: dt-bindings: phy: qcom,qmp-usb3-dp: Add support for sc8180x The SC8180x has two instances of the QMP USB/DP combo PHYs, add a compatible for these. Signed-off-by: Bjorn Andersson Acked-by: Rob Herring Link: https://lore.kernel.org/r/20210721225630.3035861-1-bjorn.andersson@linaro.org Signed-off-by: Vinod Koul --- Documentation/devicetree/bindings/phy/qcom,qmp-usb3-dp-phy.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/phy/qcom,qmp-usb3-dp-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,qmp-usb3-dp-phy.yaml index 217aa6c91893..1d49cc3d4eae 100644 --- a/Documentation/devicetree/bindings/phy/qcom,qmp-usb3-dp-phy.yaml +++ b/Documentation/devicetree/bindings/phy/qcom,qmp-usb3-dp-phy.yaml @@ -14,6 +14,7 @@ properties: compatible: enum: - qcom,sc7180-qmp-usb3-dp-phy + - qcom,sc8180x-qmp-usb3-dp-phy - qcom,sdm845-qmp-usb3-dp-phy - qcom,sm8250-qmp-usb3-dp-phy reg: -- cgit v1.2.3 From b70ee49c98d0e550b324afe869d3d17fec6190f5 Mon Sep 17 00:00:00 2001 From: Kishon Vijay Abraham I Date: Fri, 23 Jul 2021 19:26:05 +0530 Subject: dt-bindings: phy: Convert AM654 SERDES bindings to YAML Convert SERDES dt-bindings for TI's AM654 SoC to YAML binding. Signed-off-by: Kishon Vijay Abraham I Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20210723135605.23572-1-kishon@ti.com Signed-off-by: Vinod Koul --- .../bindings/phy/ti,phy-am654-serdes.txt | 82 ---------------- .../bindings/phy/ti,phy-am654-serdes.yaml | 103 +++++++++++++++++++++ 2 files changed, 103 insertions(+), 82 deletions(-) delete mode 100644 Documentation/devicetree/bindings/phy/ti,phy-am654-serdes.txt create mode 100644 Documentation/devicetree/bindings/phy/ti,phy-am654-serdes.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/phy/ti,phy-am654-serdes.txt b/Documentation/devicetree/bindings/phy/ti,phy-am654-serdes.txt deleted file mode 100644 index 64b286d2d398..000000000000 --- a/Documentation/devicetree/bindings/phy/ti,phy-am654-serdes.txt +++ /dev/null @@ -1,82 +0,0 @@ -TI AM654 SERDES - -Required properties: - - compatible: Should be "ti,phy-am654-serdes" - - reg : Address and length of the register set for the device. - - #phy-cells: determine the number of cells that should be given in the - phandle while referencing this phy. Should be "2". The 1st cell - corresponds to the phy type (should be one of the types specified in - include/dt-bindings/phy/phy.h) and the 2nd cell should be the serdes - lane function. - If SERDES0 is referenced 2nd cell should be: - 0 - USB3 - 1 - PCIe0 Lane0 - 2 - ICSS2 SGMII Lane0 - If SERDES1 is referenced 2nd cell should be: - 0 - PCIe1 Lane0 - 1 - PCIe0 Lane1 - 2 - ICSS2 SGMII Lane1 - - power-domains: As documented by the generic PM domain bindings in - Documentation/devicetree/bindings/power/power_domain.txt. - - clocks: List of clock-specifiers representing the input to the SERDES. - Should have 3 items representing the left input clock, external - reference clock and right input clock in that order. - - clock-output-names: List of clock names for each of the clock outputs of - SERDES. Should have 3 items for CMU reference clock, - left output clock and right output clock in that order. - - assigned-clocks: As defined in - Documentation/devicetree/bindings/clock/clock-bindings.txt - - assigned-clock-parents: As defined in - Documentation/devicetree/bindings/clock/clock-bindings.txt - - #clock-cells: Should be <1> to choose between the 3 output clocks. - Defined in Documentation/devicetree/bindings/clock/clock-bindings.txt - - The following macros are defined in dt-bindings/phy/phy-am654-serdes.h - for selecting the correct reference clock. This can be used while - specifying the clocks created by SERDES. - => AM654_SERDES_CMU_REFCLK - => AM654_SERDES_LO_REFCLK - => AM654_SERDES_RO_REFCLK - - - mux-controls: Phandle to the multiplexer that is used to select the lane - function. See #phy-cells above to see the multiplex values. - -Example: - -Example for SERDES0 is given below. It has 3 clock inputs; -left input reference clock as indicated by <&k3_clks 153 4>, external -reference clock as indicated by <&k3_clks 153 1> and right input -reference clock as indicated by <&serdes1 AM654_SERDES_LO_REFCLK>. (The -right input of SERDES0 is connected to the left output of SERDES1). - -SERDES0 registers 3 clock outputs as indicated in clock-output-names. The -first refers to the CMU reference clock, second refers to the left output -reference clock and the third refers to the right output reference clock. - -The assigned-clocks and assigned-clock-parents is used here to set the -parent of left input reference clock to MAINHSDIV_CLKOUT4 and parent of -CMU reference clock to left input reference clock. - -serdes0: serdes@900000 { - compatible = "ti,phy-am654-serdes"; - reg = <0x0 0x900000 0x0 0x2000>; - reg-names = "serdes"; - #phy-cells = <2>; - power-domains = <&k3_pds 153>; - clocks = <&k3_clks 153 4>, <&k3_clks 153 1>, - <&serdes1 AM654_SERDES_LO_REFCLK>; - clock-output-names = "serdes0_cmu_refclk", "serdes0_lo_refclk", - "serdes0_ro_refclk"; - assigned-clocks = <&k3_clks 153 4>, <&serdes0 AM654_SERDES_CMU_REFCLK>; - assigned-clock-parents = <&k3_clks 153 8>, <&k3_clks 153 4>; - ti,serdes-clk = <&serdes0_clk>; - mux-controls = <&serdes_mux 0>; - #clock-cells = <1>; -}; - -Example for PCIe consumer node using the SERDES PHY specifier is given below. -&pcie0_rc { - num-lanes = <2>; - phys = <&serdes0 PHY_TYPE_PCIE 1>, <&serdes1 PHY_TYPE_PCIE 1>; - phy-names = "pcie-phy0", "pcie-phy1"; -}; diff --git a/Documentation/devicetree/bindings/phy/ti,phy-am654-serdes.yaml b/Documentation/devicetree/bindings/phy/ti,phy-am654-serdes.yaml new file mode 100644 index 000000000000..62dcb84c08aa --- /dev/null +++ b/Documentation/devicetree/bindings/phy/ti,phy-am654-serdes.yaml @@ -0,0 +1,103 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/phy/ti,phy-am654-serdes.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: TI AM654 SERDES binding + +description: + This binding describes the TI AM654 SERDES. AM654 SERDES can be configured + to be used with either PCIe or USB or SGMII. + +maintainers: + - Kishon Vijay Abraham I + +properties: + compatible: + enum: + - ti,phy-am654-serdes + + reg: + maxItems: 1 + + reg-names: + items: + - const: serdes + + power-domains: + maxItems: 1 + + clocks: + maxItems: 3 + description: + Three input clocks referring to left input reference clock, refclk and right input reference + clock. + + assigned-clocks: + $ref: "/schemas/types.yaml#/definitions/phandle-array" + assigned-clock-parents: + $ref: "/schemas/types.yaml#/definitions/phandle-array" + + '#phy-cells': + const: 2 + description: + The 1st cell corresponds to the phy type (should be one of the types specified in + include/dt-bindings/phy/phy.h) and the 2nd cell should be the serdes lane function. + + ti,serdes-clk: + description: Phandle to the SYSCON entry required for configuring SERDES clock selection. + $ref: /schemas/types.yaml#/definitions/phandle + + '#clock-cells': + const: 1 + + mux-controls: + maxItems: 1 + description: Phandle to the SYSCON entry required for configuring SERDES lane function. + + clock-output-names: + oneOf: + - description: Clock output names for SERDES 0 + items: + - const: serdes0_cmu_refclk + - const: serdes0_lo_refclk + - const: serdes0_ro_refclk + - description: Clock output names for SERDES 1 + items: + - const: serdes1_cmu_refclk + - const: serdes1_lo_refclk + - const: serdes1_ro_refclk + +required: + - compatible + - reg + - power-domains + - clocks + - assigned-clocks + - assigned-clock-parents + - ti,serdes-clk + - mux-controls + - clock-output-names + +additionalProperties: false + +examples: + - | + #include + + serdes0: serdes@900000 { + compatible = "ti,phy-am654-serdes"; + reg = <0x900000 0x2000>; + reg-names = "serdes"; + #phy-cells = <2>; + power-domains = <&k3_pds 153>; + clocks = <&k3_clks 153 4>, <&k3_clks 153 1>, + <&serdes1 AM654_SERDES_LO_REFCLK>; + clock-output-names = "serdes0_cmu_refclk", "serdes0_lo_refclk", "serdes0_ro_refclk"; + assigned-clocks = <&k3_clks 153 4>, <&serdes0 AM654_SERDES_CMU_REFCLK>; + assigned-clock-parents = <&k3_clks 153 8>, <&k3_clks 153 4>; + ti,serdes-clk = <&serdes0_clk>; + mux-controls = <&serdes_mux 0>; + #clock-cells = <1>; + }; -- cgit v1.2.3 From 5711af410c28d2b9c99a91e8e6fe9ba6520771f0 Mon Sep 17 00:00:00 2001 From: Biju Das Date: Tue, 27 Jul 2021 19:55:23 +0100 Subject: dt-bindings: phy: renesas,usb2-phy: Document RZ/G2L phy bindings Document USB phy bindings for RZ/G2L SoC. RZ/G2L USB2.0 phy uses line ctrl register for OTG_ID pin changes. It uses a different OTG-BC interrupt bit for device recognition. Apart from this, the PHY reset is controlled by USBPHY control IP and Document reset is a required property. Signed-off-by: Biju Das Reviewed-by: Lad Prabhakar Reviewed-by: Yoshihiro Shimoda Acked-by: Rob Herring Link: https://lore.kernel.org/r/20210727185527.19907-3-biju.das.jz@bp.renesas.com Signed-off-by: Vinod Koul --- .../devicetree/bindings/phy/renesas,usb2-phy.yaml | 15 +++++++++++++++ 1 file changed, 15 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/phy/renesas,usb2-phy.yaml b/Documentation/devicetree/bindings/phy/renesas,usb2-phy.yaml index d5dc5a3cdceb..3a6e1165419c 100644 --- a/Documentation/devicetree/bindings/phy/renesas,usb2-phy.yaml +++ b/Documentation/devicetree/bindings/phy/renesas,usb2-phy.yaml @@ -30,6 +30,11 @@ properties: - renesas,usb2-phy-r8a77995 # R-Car D3 - const: renesas,rcar-gen3-usb2-phy + - items: + - enum: + - renesas,usb2-phy-r9a07g044 # RZ/G2{L,LC} + - const: renesas,rzg2l-usb2-phy # RZ/G2L family + reg: maxItems: 1 @@ -91,6 +96,16 @@ required: - clocks - '#phy-cells' +allOf: + - if: + properties: + compatible: + contains: + const: renesas,rzg2l-usb2-phy + then: + required: + - resets + additionalProperties: false examples: -- cgit v1.2.3 From 2433ab638f10b6ca94416df501bc8cb24589c6a8 Mon Sep 17 00:00:00 2001 From: Baruch Siach Date: Wed, 4 Aug 2021 17:05:05 +0300 Subject: dt-bindings: phy: qcom,qmp: Add IPQ6018 USB3 PHY Add compatible string for USB3 PHY in Qualcomm IPQ6018 SoC. Signed-off-by: Baruch Siach Link: https://lore.kernel.org/r/3d86f45004fe2fcbae0a2cd197df81a1fd076a1e.1628085910.git.baruch@tkos.co.il Signed-off-by: Vinod Koul --- Documentation/devicetree/bindings/phy/qcom,qmp-phy.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/phy/qcom,qmp-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,qmp-phy.yaml index 242560ff52a4..47d99001d2dd 100644 --- a/Documentation/devicetree/bindings/phy/qcom,qmp-phy.yaml +++ b/Documentation/devicetree/bindings/phy/qcom,qmp-phy.yaml @@ -18,6 +18,7 @@ properties: compatible: enum: - qcom,ipq6018-qmp-pcie-phy + - qcom,ipq6018-qmp-usb3-phy - qcom,ipq8074-qmp-pcie-phy - qcom,ipq8074-qmp-usb3-phy - qcom,msm8996-qmp-pcie-phy -- cgit v1.2.3 From cca5644c05220df7e9f9d973fa57060cf4b0ddb5 Mon Sep 17 00:00:00 2001 From: Rajendra Nayak Date: Fri, 6 Aug 2021 09:59:44 +0100 Subject: dt-bindings: nvmem: qfprom: Add optional power-domains property qfprom devices on some SoCs need to vote on the performance state of a power-domain, so add the power-domains optional property to the bindings Reviewed-by: Douglas Anderson Acked-by: Rob Herring Signed-off-by: Rajendra Nayak Signed-off-by: Srinivas Kandagatla Link: https://lore.kernel.org/r/20210806085947.22682-2-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman --- Documentation/devicetree/bindings/nvmem/qcom,qfprom.yaml | 3 +++ 1 file changed, 3 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/nvmem/qcom,qfprom.yaml b/Documentation/devicetree/bindings/nvmem/qcom,qfprom.yaml index 861b205016b1..dede8892ee01 100644 --- a/Documentation/devicetree/bindings/nvmem/qcom,qfprom.yaml +++ b/Documentation/devicetree/bindings/nvmem/qcom,qfprom.yaml @@ -51,6 +51,9 @@ properties: vcc-supply: description: Our power supply. + power-domains: + maxItems: 1 + # Needed if any child nodes are present. "#address-cells": const: 1 -- cgit v1.2.3 From 4592ee7f525c4683ec9e290381601fdee50ae110 Mon Sep 17 00:00:00 2001 From: Florian Westphal Date: Wed, 4 Aug 2021 15:02:15 +0200 Subject: netfilter: conntrack: remove offload_pickup sysctl again These two sysctls were added because the hardcoded defaults (2 minutes, tcp, 30 seconds, udp) turned out to be too low for some setups. They appeared in 5.14-rc1 so it should be fine to remove it again. Marcelo convinced me that there should be no difference between a flow that was offloaded vs. a flow that was not wrt. timeout handling. Thus the default is changed to those for TCP established and UDP stream, 5 days and 120 seconds, respectively. Marcelo also suggested to account for the timeout value used for the offloading, this avoids increase beyond the value in the conntrack-sysctl and will also instantly expire the conntrack entry with altered sysctls. Example: nf_conntrack_udp_timeout_stream=60 nf_flowtable_udp_timeout=60 This will remove offloaded udp flows after one minute, rather than two. An earlier version of this patch also cleared the ASSURED bit to allow nf_conntrack to evict the entry via early_drop (i.e., table full). However, it looks like we can safely assume that connection timed out via HW is still in established state, so this isn't needed. Quoting Oz: [..] the hardware sends all packets with a set FIN flags to sw. [..] Connections that are aged in hardware are expected to be in the established state. In case it turns out that back-to-sw-path transition can occur for 'dodgy' connections too (e.g., one side disappeared while software-path would have been in RETRANS timeout), we can adjust this later. Cc: Oz Shlomo Cc: Paul Blakey Suggested-by: Marcelo Ricardo Leitner Signed-off-by: Florian Westphal Reviewed-by: Marcelo Ricardo Leitner Reviewed-by: Oz Shlomo Signed-off-by: Pablo Neira Ayuso --- Documentation/networking/nf_conntrack-sysctl.rst | 10 ---------- 1 file changed, 10 deletions(-) (limited to 'Documentation') diff --git a/Documentation/networking/nf_conntrack-sysctl.rst b/Documentation/networking/nf_conntrack-sysctl.rst index d31ed6c1cb0d..024d784157c8 100644 --- a/Documentation/networking/nf_conntrack-sysctl.rst +++ b/Documentation/networking/nf_conntrack-sysctl.rst @@ -191,19 +191,9 @@ nf_flowtable_tcp_timeout - INTEGER (seconds) TCP connections may be offloaded from nf conntrack to nf flow table. Once aged, the connection is returned to nf conntrack with tcp pickup timeout. -nf_flowtable_tcp_pickup - INTEGER (seconds) - default 120 - - TCP connection timeout after being aged from nf flow table offload. - nf_flowtable_udp_timeout - INTEGER (seconds) default 30 Control offload timeout for udp connections. UDP connections may be offloaded from nf conntrack to nf flow table. Once aged, the connection is returned to nf conntrack with udp pickup timeout. - -nf_flowtable_udp_pickup - INTEGER (seconds) - default 30 - - UDP connection timeout after being aged from nf flow table offload. -- cgit v1.2.3 From 5161a55c069f53d88da49274cbef6e3c74eadea9 Mon Sep 17 00:00:00 2001 From: Ben Widawsky Date: Mon, 2 Aug 2021 10:29:38 -0700 Subject: cxl: Move cxl_core to new directory CXL core is growing, and it's already arguably unmanageable. To support future growth, move core functionality to a new directory and rename the file to represent just bus support. Future work will remove non-bus functionality. Note that mem.h is renamed to cxlmem.h to avoid a namespace collision with the global ARCH=um mem.h header. Reported-by: kernel test robot Signed-off-by: Ben Widawsky Reviewed-by: Jonathan Cameron Link: https://lore.kernel.org/r/162792537866.368511.8915631504621088321.stgit@dwillia2-desk3.amr.corp.intel.com Signed-off-by: Dan Williams --- Documentation/driver-api/cxl/memory-devices.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/driver-api/cxl/memory-devices.rst b/Documentation/driver-api/cxl/memory-devices.rst index 487ce4f41d77..a86e2c7c551a 100644 --- a/Documentation/driver-api/cxl/memory-devices.rst +++ b/Documentation/driver-api/cxl/memory-devices.rst @@ -36,7 +36,7 @@ CXL Core .. kernel-doc:: drivers/cxl/cxl.h :internal: -.. kernel-doc:: drivers/cxl/core.c +.. kernel-doc:: drivers/cxl/core/bus.c :doc: cxl core External Interfaces -- cgit v1.2.3 From 06737cd0d216be1cf6e8052e4fca0d391298f184 Mon Sep 17 00:00:00 2001 From: Dan Williams Date: Mon, 2 Aug 2021 10:29:49 -0700 Subject: cxl/core: Move pmem functionality Refactor the pmem / nvdimm-bridge functionality from core/bus.c to core/pmem.c. Introduce drivers/core/core.h to communicate data structures and helpers between the core bus and other functionality that registers devices on the bus. Signed-off-by: Ben Widawsky Reviewed-by: Jonathan Cameron Link: https://lore.kernel.org/r/162792538899.368511.3881663908293411300.stgit@dwillia2-desk3.amr.corp.intel.com Signed-off-by: Dan Williams --- Documentation/driver-api/cxl/memory-devices.rst | 3 +++ 1 file changed, 3 insertions(+) (limited to 'Documentation') diff --git a/Documentation/driver-api/cxl/memory-devices.rst b/Documentation/driver-api/cxl/memory-devices.rst index a86e2c7c551a..e65c0ba82229 100644 --- a/Documentation/driver-api/cxl/memory-devices.rst +++ b/Documentation/driver-api/cxl/memory-devices.rst @@ -39,6 +39,9 @@ CXL Core .. kernel-doc:: drivers/cxl/core/bus.c :doc: cxl core +.. kernel-doc:: drivers/cxl/core/pmem.c + :internal: + External Interfaces =================== -- cgit v1.2.3 From 0f06157e0135f5563efbc9aadbd93ba3d9322cab Mon Sep 17 00:00:00 2001 From: Dan Williams Date: Tue, 3 Aug 2021 07:25:38 -0700 Subject: cxl/core: Move register mapping infrastructure The register mapping infrastructure is large enough to move to its own compilation unit. This also cleans up an unnecessary include of core/bus.c. Reported-by: kernel test robot Signed-off-by: Ben Widawsky Reviewed-by: Jonathan Cameron Link: https://lore.kernel.org/r/162800068975.665205.12895551621746585289.stgit@dwillia2-desk3.amr.corp.intel.com Signed-off-by: Dan Williams --- Documentation/driver-api/cxl/memory-devices.rst | 3 +++ 1 file changed, 3 insertions(+) (limited to 'Documentation') diff --git a/Documentation/driver-api/cxl/memory-devices.rst b/Documentation/driver-api/cxl/memory-devices.rst index e65c0ba82229..46847d8c70a0 100644 --- a/Documentation/driver-api/cxl/memory-devices.rst +++ b/Documentation/driver-api/cxl/memory-devices.rst @@ -42,6 +42,9 @@ CXL Core .. kernel-doc:: drivers/cxl/core/pmem.c :internal: +.. kernel-doc:: drivers/cxl/core/regs.c + :internal: + External Interfaces =================== -- cgit v1.2.3 From e759e1b95836ec59dbadd8b7e8a7762a3c96798a Mon Sep 17 00:00:00 2001 From: Nikita Travkin Date: Tue, 27 Jul 2021 22:03:44 +0500 Subject: dt-bindings: power: supply: max17042: Document max77849-battery max77849 is a combined fuel-gauge, charger and MUIC device. Add it to the bindings documentation. Signed-off-by: Nikita Travkin Acked-by: Rob Herring Signed-off-by: Sebastian Reichel --- Documentation/devicetree/bindings/power/supply/maxim,max17042.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/power/supply/maxim,max17042.yaml b/Documentation/devicetree/bindings/power/supply/maxim,max17042.yaml index c70f05ea6d27..42ebf87d300b 100644 --- a/Documentation/devicetree/bindings/power/supply/maxim,max17042.yaml +++ b/Documentation/devicetree/bindings/power/supply/maxim,max17042.yaml @@ -19,6 +19,7 @@ properties: - maxim,max17047 - maxim,max17050 - maxim,max17055 + - maxim,max77849-battery reg: maxItems: 1 -- cgit v1.2.3 From 83abf9e150f36c6e03644c0608c5f60cd9661a6c Mon Sep 17 00:00:00 2001 From: Maxime Ripard Date: Wed, 21 Jul 2021 16:03:58 +0200 Subject: dt-bindings: power: supply: axp20x: Add AXP803 compatible The AXP803 compatible was introduced recently with a fallback to the AXP813, but it was never documented. Cc: Chen-Yu Tsai Cc: linux-pm@vger.kernel.org Cc: Sebastian Reichel Signed-off-by: Maxime Ripard Reviewed-by: Rob Herring Reviewed-by: Chen-Yu Tsai Signed-off-by: Sebastian Reichel --- .../power/supply/x-powers,axp20x-ac-power-supply.yaml | 11 +++++++---- .../power/supply/x-powers,axp20x-battery-power-supply.yaml | 11 +++++++---- .../power/supply/x-powers,axp20x-usb-power-supply.yaml | 14 +++++++++----- 3 files changed, 23 insertions(+), 13 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/power/supply/x-powers,axp20x-ac-power-supply.yaml b/Documentation/devicetree/bindings/power/supply/x-powers,axp20x-ac-power-supply.yaml index dcda6660b8ed..de6a23aee977 100644 --- a/Documentation/devicetree/bindings/power/supply/x-powers,axp20x-ac-power-supply.yaml +++ b/Documentation/devicetree/bindings/power/supply/x-powers,axp20x-ac-power-supply.yaml @@ -21,10 +21,13 @@ allOf: properties: compatible: - enum: - - x-powers,axp202-ac-power-supply - - x-powers,axp221-ac-power-supply - - x-powers,axp813-ac-power-supply + oneOf: + - const: x-powers,axp202-ac-power-supply + - const: x-powers,axp221-ac-power-supply + - items: + - const: x-powers,axp803-ac-power-supply + - const: x-powers,axp813-ac-power-supply + - const: x-powers,axp813-ac-power-supply required: - compatible diff --git a/Documentation/devicetree/bindings/power/supply/x-powers,axp20x-battery-power-supply.yaml b/Documentation/devicetree/bindings/power/supply/x-powers,axp20x-battery-power-supply.yaml index 86e8a713d4e2..d1f0df123a5a 100644 --- a/Documentation/devicetree/bindings/power/supply/x-powers,axp20x-battery-power-supply.yaml +++ b/Documentation/devicetree/bindings/power/supply/x-powers,axp20x-battery-power-supply.yaml @@ -19,10 +19,13 @@ allOf: properties: compatible: - enum: - - x-powers,axp209-battery-power-supply - - x-powers,axp221-battery-power-supply - - x-powers,axp813-battery-power-supply + oneOf: + - const: x-powers,axp202-battery-power-supply + - const: x-powers,axp221-battery-power-supply + - items: + - const: x-powers,axp803-battery-power-supply + - const: x-powers,axp813-battery-power-supply + - const: x-powers,axp813-battery-power-supply required: - compatible diff --git a/Documentation/devicetree/bindings/power/supply/x-powers,axp20x-usb-power-supply.yaml b/Documentation/devicetree/bindings/power/supply/x-powers,axp20x-usb-power-supply.yaml index 61f1b320c157..0c371b55c9e1 100644 --- a/Documentation/devicetree/bindings/power/supply/x-powers,axp20x-usb-power-supply.yaml +++ b/Documentation/devicetree/bindings/power/supply/x-powers,axp20x-usb-power-supply.yaml @@ -20,11 +20,15 @@ allOf: properties: compatible: - enum: - - x-powers,axp202-usb-power-supply - - x-powers,axp221-usb-power-supply - - x-powers,axp223-usb-power-supply - - x-powers,axp813-usb-power-supply + oneOf: + - enum: + - x-powers,axp202-usb-power-supply + - x-powers,axp221-usb-power-supply + - x-powers,axp223-usb-power-supply + - x-powers,axp813-usb-power-supply + - items: + - const: x-powers,axp803-usb-power-supply + - const: x-powers,axp813-usb-power-supply required: -- cgit v1.2.3 From cc2712f24e032f2bebf4355207638bf15ca676b5 Mon Sep 17 00:00:00 2001 From: Maxime Ripard Date: Wed, 21 Jul 2021 16:03:59 +0200 Subject: dt-bindings: power: supply: axp20x-battery: Add AXP209 compatible The AXP209 compatible was used in Device Trees and the driver, but it was never documented. Cc: Chen-Yu Tsai Cc: linux-pm@vger.kernel.org Cc: Sebastian Reichel Signed-off-by: Maxime Ripard Reviewed-by: Rob Herring Signed-off-by: Sebastian Reichel --- .../bindings/power/supply/x-powers,axp20x-battery-power-supply.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/power/supply/x-powers,axp20x-battery-power-supply.yaml b/Documentation/devicetree/bindings/power/supply/x-powers,axp20x-battery-power-supply.yaml index d1f0df123a5a..d055428ae39f 100644 --- a/Documentation/devicetree/bindings/power/supply/x-powers,axp20x-battery-power-supply.yaml +++ b/Documentation/devicetree/bindings/power/supply/x-powers,axp20x-battery-power-supply.yaml @@ -21,6 +21,7 @@ properties: compatible: oneOf: - const: x-powers,axp202-battery-power-supply + - const: x-powers,axp209-battery-power-supply - const: x-powers,axp221-battery-power-supply - items: - const: x-powers,axp803-battery-power-supply -- cgit v1.2.3 From 7c4a22339e7ce7b6ed473a8e682da622c3a774ee Mon Sep 17 00:00:00 2001 From: Randy Dunlap Date: Sun, 1 Aug 2021 18:50:37 -0700 Subject: libbpf, doc: Eliminate warnings in libbpf_naming_convention Use "code-block: none" instead of "c" for non-C-language code blocks. Removes these warnings: lnx-514-rc4/Documentation/bpf/libbpf/libbpf_naming_convention.rst:111: WARNING: Could not lex literal_block as "c". Highlighting skipped. lnx-514-rc4/Documentation/bpf/libbpf/libbpf_naming_convention.rst:124: WARNING: Could not lex literal_block as "c". Highlighting skipped. Fixes: f42cfb469f9b ("bpf: Add documentation for libbpf including API autogen") Signed-off-by: Randy Dunlap Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20210802015037.787-1-rdunlap@infradead.org --- Documentation/bpf/libbpf/libbpf_naming_convention.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/bpf/libbpf/libbpf_naming_convention.rst b/Documentation/bpf/libbpf/libbpf_naming_convention.rst index 3de1d51e41da..6bf9c5ac7576 100644 --- a/Documentation/bpf/libbpf/libbpf_naming_convention.rst +++ b/Documentation/bpf/libbpf/libbpf_naming_convention.rst @@ -108,7 +108,7 @@ This bump in ABI version is at most once per kernel development cycle. For example, if current state of ``libbpf.map`` is: -.. code-block:: c +.. code-block:: none LIBBPF_0.0.1 { global: @@ -121,7 +121,7 @@ For example, if current state of ``libbpf.map`` is: , and a new symbol ``bpf_func_c`` is being introduced, then ``libbpf.map`` should be changed like this: -.. code-block:: c +.. code-block:: none LIBBPF_0.0.1 { global: -- cgit v1.2.3 From 58890a4bfaa7921033235c9158c300c6a244429e Mon Sep 17 00:00:00 2001 From: Jonathan Marek Date: Thu, 17 Jun 2021 10:43:33 -0400 Subject: dt-bindings: msm: dsi: add missing 7nm bindings These got lost when going from .txt to .yaml bindings, add them back. Signed-off-by: Jonathan Marek Fixes: 8fc939e72ff8 ("dt-bindings: msm: dsi: add yaml schemas for DSI PHY bindings") Link: https://lore.kernel.org/r/20210617144349.28448-2-jonathan@marek.ca Reviewed-by: Rob Herring Signed-off-by: Dmitry Baryshkov Signed-off-by: Rob Clark --- .../bindings/display/msm/dsi-phy-7nm.yaml | 66 ++++++++++++++++++++++ 1 file changed, 66 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/msm/dsi-phy-7nm.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/msm/dsi-phy-7nm.yaml b/Documentation/devicetree/bindings/display/msm/dsi-phy-7nm.yaml new file mode 100644 index 000000000000..c0077ca7e9e7 --- /dev/null +++ b/Documentation/devicetree/bindings/display/msm/dsi-phy-7nm.yaml @@ -0,0 +1,66 @@ +# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/msm/dsi-phy-7nm.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Display DSI 7nm PHY + +maintainers: + - Jonathan Marek + +allOf: + - $ref: dsi-phy-common.yaml# + +properties: + compatible: + oneOf: + - const: qcom,dsi-phy-7nm + - const: qcom,dsi-phy-7nm-8150 + + reg: + items: + - description: dsi phy register set + - description: dsi phy lane register set + - description: dsi pll register set + + reg-names: + items: + - const: dsi_phy + - const: dsi_phy_lane + - const: dsi_pll + + vdds-supply: + description: | + Connected to VDD_A_DSI_PLL_0P9 pin (or VDDA_DSI{0,1}_PLL_0P9 for sm8150) + +required: + - compatible + - reg + - reg-names + - vdds-supply + +unevaluatedProperties: false + +examples: + - | + #include + #include + + dsi-phy@ae94400 { + compatible = "qcom,dsi-phy-7nm"; + reg = <0x0ae94400 0x200>, + <0x0ae94600 0x280>, + <0x0ae94900 0x260>; + reg-names = "dsi_phy", + "dsi_phy_lane", + "dsi_pll"; + + #clock-cells = <1>; + #phy-cells = <0>; + + vdds-supply = <&vreg_l5a_0p88>; + clocks = <&dispcc DISP_CC_MDSS_AHB_CLK>, + <&rpmhcc RPMH_CXO_CLK>; + clock-names = "iface", "ref"; + }; -- cgit v1.2.3 From bb5b94f5bbe75470912b70fb08880fc5273aa62d Mon Sep 17 00:00:00 2001 From: Jonathan Marek Date: Thu, 17 Jun 2021 10:43:34 -0400 Subject: dt-bindings: msm: dsi: document phy-type property for 7nm dsi phy Document a new phy-type property which will be used to determine whether the phy should operate in D-PHY or C-PHY mode. Signed-off-by: Jonathan Marek Reviewed-by: Laurent Pinchart Link: https://lore.kernel.org/r/20210617144349.28448-3-jonathan@marek.ca Acked-by: Rob Herring Signed-off-by: Dmitry Baryshkov Signed-off-by: Rob Clark --- Documentation/devicetree/bindings/display/msm/dsi-phy-7nm.yaml | 5 +++++ 1 file changed, 5 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/msm/dsi-phy-7nm.yaml b/Documentation/devicetree/bindings/display/msm/dsi-phy-7nm.yaml index c0077ca7e9e7..70809d1cac54 100644 --- a/Documentation/devicetree/bindings/display/msm/dsi-phy-7nm.yaml +++ b/Documentation/devicetree/bindings/display/msm/dsi-phy-7nm.yaml @@ -34,6 +34,11 @@ properties: description: | Connected to VDD_A_DSI_PLL_0P9 pin (or VDDA_DSI{0,1}_PLL_0P9 for sm8150) + phy-type: + description: D-PHY (default) or C-PHY mode + enum: [ 10, 11 ] + default: 10 + required: - compatible - reg -- cgit v1.2.3 From 9a152785e233c3d62e82ada3cadabe01b75d4758 Mon Sep 17 00:00:00 2001 From: Rajeev Nandan Date: Tue, 22 Jun 2021 18:12:26 +0530 Subject: dt-bindings: msm/dsi: Add sc7280 7nm dsi phy The SC7280 SoC uses the 7nm (V4.1) DSI PHY driver. Signed-off-by: Rajeev Nandan Link: https://lore.kernel.org/r/1624365748-24224-2-git-send-email-rajeevny@codeaurora.org Acked-by: Rob Herring Reviewed-by: Stephen Boyd Signed-off-by: Dmitry Baryshkov Signed-off-by: Rob Clark --- Documentation/devicetree/bindings/display/msm/dsi-phy-7nm.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/msm/dsi-phy-7nm.yaml b/Documentation/devicetree/bindings/display/msm/dsi-phy-7nm.yaml index 70809d1cac54..4265399bb154 100644 --- a/Documentation/devicetree/bindings/display/msm/dsi-phy-7nm.yaml +++ b/Documentation/devicetree/bindings/display/msm/dsi-phy-7nm.yaml @@ -17,6 +17,7 @@ properties: oneOf: - const: qcom,dsi-phy-7nm - const: qcom,dsi-phy-7nm-8150 + - const: qcom,sc7280-dsi-phy-7nm reg: items: -- cgit v1.2.3 From 061a9aeab07feb698e7c732bb66494a109bbecbf Mon Sep 17 00:00:00 2001 From: Dmitry Baryshkov Date: Sat, 10 Jul 2021 00:07:22 +0300 Subject: dt-bindings: display: msm: dsi-controller-main: restore assigned-clocks Restore the assgined-clocks and assigned-clock-parents properties that were lost during the txt -> YAML conversion. Signed-off-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20210709210729.953114-2-dmitry.baryshkov@linaro.org Signed-off-by: Dmitry Baryshkov Signed-off-by: Rob Clark --- .../bindings/display/msm/dsi-controller-main.yaml | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml b/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml index 76348b71f736..760eec6b0db1 100644 --- a/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml +++ b/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml @@ -64,6 +64,18 @@ properties: Indicates if the DSI controller is driving a panel which needs 2 DSI links. + assigned-clocks: + minItems: 2 + maxItems: 2 + description: | + Parents of "byte" and "pixel" for the given platform. + + assigned-clock-parents: + minItems: 2 + maxItems: 2 + description: | + The Byte clock and Pixel clock PLL outputs provided by a DSI PHY block. + power-domains: maxItems: 1 @@ -119,6 +131,8 @@ required: - clock-names - phys - phy-names + - assigned-clocks + - assigned-clock-parents - power-domains - operating-points-v2 - ports @@ -159,6 +173,9 @@ examples: phys = <&dsi0_phy>; phy-names = "dsi"; + assigned-clocks = <&dispcc DISP_CC_MDSS_BYTE0_CLK_SRC>, <&dispcc DISP_CC_MDSS_PCLK0_CLK_SRC>; + assigned-clock-parents = <&dsi_phy 0>, <&dsi_phy 1>; + power-domains = <&rpmhpd SC7180_CX>; operating-points-v2 = <&dsi_opp_table>; -- cgit v1.2.3 From 3722c105ecd1129bba593a9599b8c513c0129536 Mon Sep 17 00:00:00 2001 From: Andreas Klinger Date: Wed, 4 Aug 2021 17:45:50 +0200 Subject: dt-bindings: iio: chemical: Add trivial DT binding for sgp40 Add devicetree binding for Sensirion sgp40 gas sensor to trivial devices. Acked-by: Rob Herring Signed-off-by: Andreas Klinger Link: https://lore.kernel.org/r/20210804154549.GA3223@arbad Signed-off-by: Jonathan Cameron --- Documentation/devicetree/bindings/trivial-devices.yaml | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/trivial-devices.yaml b/Documentation/devicetree/bindings/trivial-devices.yaml index 919a4bf03a5a..be313b6b4f81 100644 --- a/Documentation/devicetree/bindings/trivial-devices.yaml +++ b/Documentation/devicetree/bindings/trivial-devices.yaml @@ -269,6 +269,8 @@ properties: - sensirion,sgpc3 # Sensirion multi-pixel gas sensor with I2C interface - sensirion,sgp30 + # Sensirion gas sensor with I2C interface + - sensirion,sgp40 # Sensortek 3 axis accelerometer - sensortek,stk8312 # Sensortek 3 axis accelerometer -- cgit v1.2.3 From 1081b9d97152e6aa28a1868ec8e0587b2b8fb2ae Mon Sep 17 00:00:00 2001 From: Andreas Klinger Date: Wed, 4 Aug 2021 17:46:42 +0200 Subject: iio: chemical: Add driver support for sgp40 sgp40 is a gas sensor used for measuring the air quality. This driver is reading the raw resistance value which can be passed to an userspace algorithm for further calculation. The raw value is also used to calculate an estimated absolute voc index in the range from 0 to 500. For this purpose the raw_mean value of the resistance for which the index value is 250 might be set up as a calibration step. This can be done with in_resistance_calibbias. Compensation of relative humidity and temperature is supported and can be used by writing to output values of out_humidityrelative_raw and out_temp_raw. There is a predecesor sensor type (sgp30) already existing. This driver module was not extended because the new sensor is quite different in its i2c telegrams. Signed-off-by: Andreas Klinger Reported-by: kernel test robot Link: https://lore.kernel.org/r/20210804154641.GA3237@arbad Signed-off-by: Jonathan Cameron --- .../ABI/testing/sysfs-bus-iio-chemical-sgp40 | 31 ++++++++++++++++++++++ 1 file changed, 31 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-bus-iio-chemical-sgp40 (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-bus-iio-chemical-sgp40 b/Documentation/ABI/testing/sysfs-bus-iio-chemical-sgp40 new file mode 100644 index 000000000000..469a7c00fad4 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-bus-iio-chemical-sgp40 @@ -0,0 +1,31 @@ +What: /sys/bus/iio/devices/iio:deviceX/out_temp_raw +Date: August 2021 +KernelVersion: 5.15 +Contact: Andreas Klinger +Description: + Set the temperature. This value is sent to the sensor for + temperature compensation. + Default value: 25000 (25 °C) + +What: /sys/bus/iio/devices/iio:deviceX/out_humidityrelative_raw +Date: August 2021 +KernelVersion: 5.15 +Contact: Andreas Klinger +Description: + Set the relative humidity. This value is sent to the sensor for + humidity compensation. + Default value: 50000 (50 % relative humidity) + +What: /sys/bus/iio/devices/iio:deviceX/in_resistance_calibbias +Date: August 2021 +KernelVersion: 5.15 +Contact: Andreas Klinger +Description: + Set the bias value for the resistance which is used for + calculation of in_concentration_input as follows: + + x = (in_resistance_raw - in_resistance_calibbias) * 0.65 + + in_concentration_input = 500 / (1 + e^x) + + Default value: 30000 -- cgit v1.2.3 From a5dfc572eeee7bbba6749814ce39e9fda139c531 Mon Sep 17 00:00:00 2001 From: Siddharth Manthan Date: Wed, 28 Jul 2021 16:30:47 +0530 Subject: dt-bindings: Add bindings for Capella cm3323 Ambient Light Sensor Update trivial-devices.yaml with Capella cm3323 Ambient Light Sensor description. Signed-off-by: Siddharth Manthan Acked-by: Rob Herring Link: https://lore.kernel.org/r/20210728110048.14593-1-siddharth.manthan@gmail.com Signed-off-by: Jonathan Cameron --- Documentation/devicetree/bindings/trivial-devices.yaml | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/trivial-devices.yaml b/Documentation/devicetree/bindings/trivial-devices.yaml index be313b6b4f81..02a30e779fb3 100644 --- a/Documentation/devicetree/bindings/trivial-devices.yaml +++ b/Documentation/devicetree/bindings/trivial-devices.yaml @@ -61,6 +61,8 @@ properties: - capella,cm32181 # CM3232: Ambient Light Sensor - capella,cm3232 + # CM3323: Ambient Light Sensor + - capella,cm3323 # High-Precision Digital Thermometer - dallas,ds1631 # Total-Elapsed-Time Recorder with Alarm -- cgit v1.2.3 From 84c31a0466c12110af72d56c1dcc40759e848c55 Mon Sep 17 00:00:00 2001 From: Stephan Gerhold Date: Mon, 2 Aug 2021 17:56:54 +0200 Subject: dt-bindings: iio: accel: bma255: Add interrupt-names The binding already allows specifying both interrupt pins, but there is currently no way to describe a board where (for whatever reason) only INT2 is connected. Make it possible to use "interrupt-names" to make it explicit which interrupt pin is meant in the interrupts. Reviewed-by: Linus Walleij Signed-off-by: Stephan Gerhold Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20210802155657.102766-2-stephan@gerhold.net Signed-off-by: Jonathan Cameron --- .../devicetree/bindings/iio/accel/bosch,bma255.yaml | 16 +++++++++++++--- 1 file changed, 13 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/iio/accel/bosch,bma255.yaml b/Documentation/devicetree/bindings/iio/accel/bosch,bma255.yaml index 5b35856b1942..253b2051d0b1 100644 --- a/Documentation/devicetree/bindings/iio/accel/bosch,bma255.yaml +++ b/Documentation/devicetree/bindings/iio/accel/bosch,bma255.yaml @@ -45,9 +45,18 @@ properties: minItems: 1 maxItems: 2 description: | - The first interrupt listed must be the one connected to the INT1 pin, - the second (optional) interrupt listed must be the one connected to the - INT2 pin (if available). The type should be IRQ_TYPE_EDGE_RISING. + Without interrupt-names, the first interrupt listed must be the one + connected to the INT1 pin, the second (optional) interrupt listed must be + the one connected to the INT2 pin (if available). The type should be + IRQ_TYPE_EDGE_RISING. + + interrupt-names: + minItems: 1 + maxItems: 2 + items: + enum: + - INT1 + - INT2 mount-matrix: description: an optional 3x3 mounting rotation matrix. @@ -73,6 +82,7 @@ examples: vddio-supply = <&vddio>; vdd-supply = <&vdd>; interrupts = <57 IRQ_TYPE_EDGE_RISING>; + interrupt-names = "INT1"; }; }; - | -- cgit v1.2.3 From 02104141f3fa08c0b8d3924e0db4744212ed5b9a Mon Sep 17 00:00:00 2001 From: Stephan Gerhold Date: Mon, 2 Aug 2021 17:56:55 +0200 Subject: dt-bindings: iio: accel: bma255: Add bosch,bmc156_accel BMC156 is very smilar to BMC150, but it has only one accelerometer interrupt pin. It would make sense if only INT1 was exposed but someone at Bosch decided to only have an INT2 pin. In this case, it does not make sense if the first interrupt pin is treated as INT1 (since that pin does not exist). Add a note to the bindings that the first interrupt pin is treated as INT2 for BMC156. Reviewed-by: Linus Walleij Reviewed-by: Rob Herring Signed-off-by: Stephan Gerhold Link: https://lore.kernel.org/r/20210802155657.102766-3-stephan@gerhold.net Signed-off-by: Jonathan Cameron --- .../devicetree/bindings/iio/accel/bosch,bma255.yaml | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/iio/accel/bosch,bma255.yaml b/Documentation/devicetree/bindings/iio/accel/bosch,bma255.yaml index 253b2051d0b1..478e75ae0885 100644 --- a/Documentation/devicetree/bindings/iio/accel/bosch,bma255.yaml +++ b/Documentation/devicetree/bindings/iio/accel/bosch,bma255.yaml @@ -26,6 +26,7 @@ properties: - bosch,bma255 - bosch,bma280 - bosch,bmc150_accel + - bosch,bmc156_accel - bosch,bmi055_accel # bma180 driver in Linux @@ -50,6 +51,9 @@ properties: the one connected to the INT2 pin (if available). The type should be IRQ_TYPE_EDGE_RISING. + BMC156 does not have an INT1 pin, therefore the first interrupt pin is + always treated as INT2. + interrupt-names: minItems: 1 maxItems: 2 @@ -85,6 +89,20 @@ examples: interrupt-names = "INT1"; }; }; + - | + #include + i2c { + #address-cells = <1>; + #size-cells = <0>; + accelerometer@10 { + compatible = "bosch,bmc156_accel"; + reg = <0x10>; + vddio-supply = <&vddio>; + vdd-supply = <&vdd>; + interrupts = <116 IRQ_TYPE_EDGE_RISING>; + interrupt-names = "INT2"; + }; + }; - | # include spi { -- cgit v1.2.3 From 71d41c09f1fad1b3b4a26658655922944b56f6e7 Mon Sep 17 00:00:00 2001 From: Sven Eckelmann Date: Sun, 13 Jun 2021 16:37:47 +0200 Subject: batman-adv: Move IRC channel to hackint.org Due to recent developments around the Freenode.org IRC network, the opinions about the usage of this service shifted dramatically. The majority of the still active users of the #batman channel prefers a move to the hackint.org network. Signed-off-by: Sven Eckelmann --- Documentation/networking/batman-adv.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/networking/batman-adv.rst b/Documentation/networking/batman-adv.rst index 74821d29a22f..b85563ea3682 100644 --- a/Documentation/networking/batman-adv.rst +++ b/Documentation/networking/batman-adv.rst @@ -157,7 +157,7 @@ Contact Please send us comments, experiences, questions, anything :) IRC: - #batman on irc.freenode.org + #batadv on ircs://irc.hackint.org/ Mailing-list: b.a.t.m.a.n@open-mesh.org (optional subscription at https://lists.open-mesh.org/mailman3/postorius/lists/b.a.t.m.a.n.lists.open-mesh.org/) -- cgit v1.2.3 From d81274f8fd8616724a86be0b9bab92f0f52651ef Mon Sep 17 00:00:00 2001 From: Georgi Djakov Date: Fri, 23 Jul 2021 12:42:42 -0700 Subject: dt-bindings: interconnect: Add Qualcomm SC8180x DT bindings Add compatibles and port definitions for the SC8180x RPMH interconnect providers. Signed-off-by: Georgi Djakov [bjorn: Split defines from driver patch and added binding update] Signed-off-by: Bjorn Andersson Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20210723194243.3675795-1-bjorn.andersson@linaro.org Signed-off-by: Georgi Djakov --- Documentation/devicetree/bindings/interconnect/qcom,rpmh.yaml | 11 +++++++++++ 1 file changed, 11 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/interconnect/qcom,rpmh.yaml b/Documentation/devicetree/bindings/interconnect/qcom,rpmh.yaml index 5accc0d113be..3fd1a134162d 100644 --- a/Documentation/devicetree/bindings/interconnect/qcom,rpmh.yaml +++ b/Documentation/devicetree/bindings/interconnect/qcom,rpmh.yaml @@ -49,6 +49,17 @@ properties: - qcom,sc7280-mmss-noc - qcom,sc7280-nsp-noc - qcom,sc7280-system-noc + - qcom,sc8180x-aggre1-noc + - qcom,sc8180x-aggre2-noc + - qcom,sc8180x-camnoc-virt + - qcom,sc8180x-compute-noc + - qcom,sc8180x-config-noc + - qcom,sc8180x-dc-noc + - qcom,sc8180x-gem-noc + - qcom,sc8180x-ipa-virt + - qcom,sc8180x-mc-virt + - qcom,sc8180x-mmss-noc + - qcom,sc8180x-system-noc - qcom,sdm845-aggre1-noc - qcom,sdm845-aggre2-noc - qcom,sdm845-config-noc -- cgit v1.2.3 From 13fa44c0b6bfbbf15e17ca90b4ae378ca072417d Mon Sep 17 00:00:00 2001 From: Bjorn Andersson Date: Sat, 24 Jul 2021 19:58:33 -0700 Subject: dt-bindings: interconnect: Add SC8180x to OSM L3 DT binding The Qualcomm SC8180x has an OSM L3, add compatible for this. Signed-off-by: Bjorn Andersson Acked-by: Rob Herring Link: https://lore.kernel.org/r/20210725025834.3941777-1-bjorn.andersson@linaro.org Signed-off-by: Georgi Djakov --- Documentation/devicetree/bindings/interconnect/qcom,osm-l3.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/interconnect/qcom,osm-l3.yaml b/Documentation/devicetree/bindings/interconnect/qcom,osm-l3.yaml index d6a95c3cb26f..e701524ee811 100644 --- a/Documentation/devicetree/bindings/interconnect/qcom,osm-l3.yaml +++ b/Documentation/devicetree/bindings/interconnect/qcom,osm-l3.yaml @@ -18,6 +18,7 @@ properties: compatible: enum: - qcom,sc7180-osm-l3 + - qcom,sc8180x-osm-l3 - qcom,sdm845-osm-l3 - qcom,sm8150-osm-l3 - qcom,sm8250-epss-l3 -- cgit v1.2.3 From 8867c4b39361a2c12d4a4b3343e2b4cf3b32a50e Mon Sep 17 00:00:00 2001 From: Fabien Parent Date: Fri, 23 Oct 2020 15:31:27 +0200 Subject: dt-bindings: display: mediatek: dsi: add documentation for MT8167 SoC Add binding documentation for the MT8167 SoC. Signed-off-by: Fabien Parent Signed-off-by: Chun-Kuang Hu --- Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt b/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt index 8238a86686be..d30428b9fb33 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt @@ -7,7 +7,7 @@ channel output. Required properties: - compatible: "mediatek,-dsi" -- the supported chips are mt2701, mt7623, mt8173 and mt8183. +- the supported chips are mt2701, mt7623, mt8167, mt8173 and mt8183. - reg: Physical base address and length of the controller's registers - interrupts: The interrupt signal from the function block. - clocks: device clocks -- cgit v1.2.3 From 064478e4877c76b0c1fd1155934f226f1561aab3 Mon Sep 17 00:00:00 2001 From: Jack Yu Date: Mon, 9 Aug 2021 10:27:14 +0000 Subject: ASoC: dt-bindings: rt1015p: add new compatible id Add new compatible ID for rt1015p in dt-bindings document. Signed-off-by: Jack Yu Link: https://lore.kernel.org/r/ce9e2f298f0c4fc59f756c39736a297a@realtek.com Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/sound/realtek,rt1015p.yaml | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/realtek,rt1015p.yaml b/Documentation/devicetree/bindings/sound/realtek,rt1015p.yaml index 644b68edf3e1..8fcb5f79a1b5 100644 --- a/Documentation/devicetree/bindings/sound/realtek,rt1015p.yaml +++ b/Documentation/devicetree/bindings/sound/realtek,rt1015p.yaml @@ -15,7 +15,9 @@ description: | properties: compatible: - const: realtek,rt1015p + oneOf: + const: realtek,rt1015p + const: realtek,rt1019p sdb-gpios: description: -- cgit v1.2.3 From 06252e9ce05b94b587e522667b85848a30197b15 Mon Sep 17 00:00:00 2001 From: Gao Xiang Date: Thu, 5 Aug 2021 08:36:00 +0800 Subject: erofs: dax support for non-tailpacking regular file DAX is quite useful for some VM use cases in order to save guest memory extremely with minimal lightweight EROFS. In order to prepare for such use cases, add preliminary dax support for non-tailpacking regular files for now. Tested with the DRAM-emulated PMEM and the EROFS image generated by "mkfs.erofs -Enoinline_data enwik9.fsdax.img enwik9" Link: https://lore.kernel.org/r/20210805003601.183063-3-hsiangkao@linux.alibaba.com Cc: nvdimm@lists.linux.dev Cc: linux-fsdevel@vger.kernel.org Reviewed-by: Chao Yu Signed-off-by: Gao Xiang --- Documentation/filesystems/erofs.rst | 3 +++ 1 file changed, 3 insertions(+) (limited to 'Documentation') diff --git a/Documentation/filesystems/erofs.rst b/Documentation/filesystems/erofs.rst index 832839fcf4c3..868e3972227f 100644 --- a/Documentation/filesystems/erofs.rst +++ b/Documentation/filesystems/erofs.rst @@ -84,6 +84,9 @@ cache_strategy=%s Select a strategy for cached decompression from now on: It still does in-place I/O decompression for the rest compressed physical clusters. ========== ============================================= +dax={always,never} Use direct access (no page cache). See + Documentation/filesystems/dax.rst. +dax A legacy option which is an alias for ``dax=always``. =================== ========================================================= On-disk details -- cgit v1.2.3 From e08831baa032e62786d88b68e26c54389e2486b6 Mon Sep 17 00:00:00 2001 From: Nick Desaulniers Date: Mon, 2 Aug 2021 11:39:10 -0700 Subject: Documentation/llvm: update CROSS_COMPILE inferencing As noted by Masahiro, document how we can generally infer CROSS_COMPILE (and the more specific details about --target and --prefix) based on ARCH. Change use of env vars to command line parameters. Suggested-by: Masahiro Yamada Reviewed-by: Fangrui Song Signed-off-by: Nick Desaulniers Reviewed-by: Nathan Chancellor Signed-off-by: Masahiro Yamada --- Documentation/kbuild/llvm.rst | 19 ++++++++++++++++++- 1 file changed, 18 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/kbuild/llvm.rst b/Documentation/kbuild/llvm.rst index b18401d2ba82..f8a360958f4c 100644 --- a/Documentation/kbuild/llvm.rst +++ b/Documentation/kbuild/llvm.rst @@ -38,7 +38,7 @@ Cross Compiling A single Clang compiler binary will typically contain all supported backends, which can help simplify cross compiling. :: - ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- make CC=clang + make ARCH=arm64 CC=clang CROSS_COMPILE=aarch64-linux-gnu- ``CROSS_COMPILE`` is not used to prefix the Clang compiler binary, instead ``CROSS_COMPILE`` is used to set a command line flag: ``--target=``. For @@ -63,6 +63,23 @@ They can be enabled individually. The full list of the parameters: :: Currently, the integrated assembler is disabled by default. You can pass ``LLVM_IAS=1`` to enable it. +Omitting CROSS_COMPILE +---------------------- + +As explained above, ``CROSS_COMPILE`` is used to set ``--target=``. + +Unless ``LLVM_IAS=1`` is specified, ``CROSS_COMPILE`` is also used to derive +``--prefix=`` to search for the GNU assembler and linker. + +If ``CROSS_COMPILE`` is not specified, the ``--target=`` is inferred +from ``ARCH``. + +That means if you use only LLVM tools, ``CROSS_COMPILE`` becomes unnecessary. + +For example, to cross-compile the arm64 kernel:: + + make ARCH=arm64 LLVM=1 LLVM_IAS=1 + Supported Architectures ----------------------- -- cgit v1.2.3 From f12b034afeb3a977bbb1c6584dedc0f3dc666f14 Mon Sep 17 00:00:00 2001 From: Nick Desaulniers Date: Fri, 6 Aug 2021 10:27:01 -0700 Subject: scripts/Makefile.clang: default to LLVM_IAS=1 LLVM_IAS=1 controls enabling clang's integrated assembler via -integrated-as. This was an explicit opt in until we could enable assembler support in Clang for more architecures. Now we have support and CI coverage of LLVM_IAS=1 for all architecures except a few more bugs affecting s390 and powerpc. This commit flips the default from opt in via LLVM_IAS=1 to opt out via LLVM_IAS=0. CI systems or developers that were previously doing builds with CC=clang or LLVM=1 without explicitly setting LLVM_IAS must now explicitly opt out via LLVM_IAS=0, otherwise they will be implicitly opted-in. This finally shortens the command line invocation when cross compiling with LLVM to simply: $ make ARCH=arm64 LLVM=1 Signed-off-by: Nick Desaulniers Reviewed-by: Nathan Chancellor Signed-off-by: Masahiro Yamada --- Documentation/kbuild/llvm.rst | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) (limited to 'Documentation') diff --git a/Documentation/kbuild/llvm.rst b/Documentation/kbuild/llvm.rst index f8a360958f4c..e87ed5479963 100644 --- a/Documentation/kbuild/llvm.rst +++ b/Documentation/kbuild/llvm.rst @@ -60,17 +60,14 @@ They can be enabled individually. The full list of the parameters: :: OBJCOPY=llvm-objcopy OBJDUMP=llvm-objdump READELF=llvm-readelf \ HOSTCC=clang HOSTCXX=clang++ HOSTAR=llvm-ar HOSTLD=ld.lld -Currently, the integrated assembler is disabled by default. You can pass -``LLVM_IAS=1`` to enable it. +The integrated assembler is enabled by default. You can pass ``LLVM_IAS=0`` to +disable it. Omitting CROSS_COMPILE ---------------------- As explained above, ``CROSS_COMPILE`` is used to set ``--target=``. -Unless ``LLVM_IAS=1`` is specified, ``CROSS_COMPILE`` is also used to derive -``--prefix=`` to search for the GNU assembler and linker. - If ``CROSS_COMPILE`` is not specified, the ``--target=`` is inferred from ``ARCH``. @@ -78,7 +75,12 @@ That means if you use only LLVM tools, ``CROSS_COMPILE`` becomes unnecessary. For example, to cross-compile the arm64 kernel:: - make ARCH=arm64 LLVM=1 LLVM_IAS=1 + make ARCH=arm64 LLVM=1 + +If ``LLVM_IAS=0`` is specified, ``CROSS_COMPILE`` is also used to derive +``--prefix=`` to search for the GNU assembler and linker. :: + + make ARCH=arm64 LLVM=1 LLVM_IAS=0 CROSS_COMPILE=aarch64-linux-gnu- Supported Architectures ----------------------- -- cgit v1.2.3 From 7958f88aa6636f1927513c887a00e83168f12e35 Mon Sep 17 00:00:00 2001 From: Lad Prabhakar Date: Tue, 27 Jul 2021 12:23:25 +0100 Subject: dt-bindings: pinctrl: renesas: Add DT bindings for RZ/G2L pinctrl Add device tree binding documentation and header file for Renesas RZ/G2L pinctrl. Signed-off-by: Lad Prabhakar Reviewed-by: Biju Das Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20210727112328.18809-2-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Geert Uytterhoeven --- .../bindings/pinctrl/renesas,rzg2l-pinctrl.yaml | 155 +++++++++++++++++++++ 1 file changed, 155 insertions(+) create mode 100644 Documentation/devicetree/bindings/pinctrl/renesas,rzg2l-pinctrl.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pinctrl/renesas,rzg2l-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/renesas,rzg2l-pinctrl.yaml new file mode 100644 index 000000000000..ef68dabcf4dc --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/renesas,rzg2l-pinctrl.yaml @@ -0,0 +1,155 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pinctrl/renesas,rzg2l-pinctrl.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Renesas RZ/G2L combined Pin and GPIO controller + +maintainers: + - Geert Uytterhoeven + - Lad Prabhakar + +description: + The Renesas SoCs of the RZ/G2L series feature a combined Pin and GPIO + controller. + Pin multiplexing and GPIO configuration is performed on a per-pin basis. + Each port features up to 8 pins, each of them configurable for GPIO function + (port mode) or in alternate function mode. + Up to 8 different alternate function modes exist for each single pin. + +properties: + compatible: + enum: + - renesas,r9a07g044-pinctrl # RZ/G2{L,LC} + + reg: + maxItems: 1 + + gpio-controller: true + + '#gpio-cells': + const: 2 + description: + The first cell contains the global GPIO port index, constructed using the + RZG2L_GPIO() helper macro in and the + second cell represents consumer flag as mentioned in ../gpio/gpio.txt + E.g. "RZG2L_GPIO(39, 1)" for P39_1. + + gpio-ranges: + maxItems: 1 + + clocks: + maxItems: 1 + + power-domains: + maxItems: 1 + + resets: + items: + - description: GPIO_RSTN signal + - description: GPIO_PORT_RESETN signal + - description: GPIO_SPARE_RESETN signal + +additionalProperties: + anyOf: + - type: object + allOf: + - $ref: pincfg-node.yaml# + - $ref: pinmux-node.yaml# + + description: + Pin controller client devices use pin configuration subnodes (children + and grandchildren) for desired pin configuration. + Client device subnodes use below standard properties. + + properties: + phandle: true + pinmux: + description: + Values are constructed from GPIO port number, pin number, and + alternate function configuration number using the RZG2L_PORT_PINMUX() + helper macro in . + pins: true + drive-strength: + enum: [ 2, 4, 8, 12 ] + power-source: + enum: [ 1800, 2500, 3300 ] + slew-rate: true + gpio-hog: true + gpios: true + input-enable: true + output-high: true + output-low: true + line-name: true + + - type: object + properties: + phandle: true + + additionalProperties: + $ref: "#/additionalProperties/anyOf/0" + +required: + - compatible + - reg + - gpio-controller + - '#gpio-cells' + - gpio-ranges + - clocks + - power-domains + - resets + +examples: + - | + #include + #include + + pinctrl: pinctrl@11030000 { + compatible = "renesas,r9a07g044-pinctrl"; + reg = <0x11030000 0x10000>; + + gpio-controller; + #gpio-cells = <2>; + gpio-ranges = <&pinctrl 0 0 392>; + clocks = <&cpg CPG_MOD R9A07G044_GPIO_HCLK>; + resets = <&cpg R9A07G044_GPIO_RSTN>, + <&cpg R9A07G044_GPIO_PORT_RESETN>, + <&cpg R9A07G044_GPIO_SPARE_RESETN>; + power-domains = <&cpg>; + + scif0_pins: serial0 { + pinmux = , /* Tx */ + ; /* Rx */ + }; + + i2c1_pins: i2c1 { + pins = "RIIC1_SDA", "RIIC1_SCL"; + input-enable; + }; + + sd1-pwr-en-hog { + gpio-hog; + gpios = ; + output-high; + line-name = "sd1_pwr_en"; + }; + + sdhi1_pins: sd1 { + sd1_mux { + pinmux = , /* CD */ + ; /* WP */ + power-source = <3300>; + }; + + sd1_data { + pins = "SD1_DATA0", "SD1_DATA1", "SD1_DATA2", "SD1_DATA3"; + power-source = <3300>; + }; + + sd1_ctrl { + pins = "SD1_CLK", "SD1_CMD"; + power-source = <3300>; + }; + }; + }; -- cgit v1.2.3 From eb7ab747efd600382bc2e9406ea1fc2a867e9804 Mon Sep 17 00:00:00 2001 From: Jack Yu Date: Tue, 10 Aug 2021 10:08:34 +0800 Subject: ASoC: dt-bindings: rt1015p: fix syntax error in dts-binding document Fix syntax error in dts-binding document. Signed-off-by: Jack Yu Fixes: 064478e4877c ("ASoC: dt-bindings: rt1015p: add new compatible id") Link: https://lore.kernel.org/r/20210810020834.32414-1-jack.yu@realtek.com Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/sound/realtek,rt1015p.yaml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/realtek,rt1015p.yaml b/Documentation/devicetree/bindings/sound/realtek,rt1015p.yaml index 8fcb5f79a1b5..f31d3c4d0192 100644 --- a/Documentation/devicetree/bindings/sound/realtek,rt1015p.yaml +++ b/Documentation/devicetree/bindings/sound/realtek,rt1015p.yaml @@ -16,8 +16,8 @@ description: | properties: compatible: oneOf: - const: realtek,rt1015p - const: realtek,rt1019p + - const: realtek,rt1015p + - const: realtek,rt1019p sdb-gpios: description: -- cgit v1.2.3 From 182700f258531c75846cb0f070e847e8b4c457b2 Mon Sep 17 00:00:00 2001 From: Bjorn Andersson Date: Mon, 28 Jun 2021 17:38:51 -0700 Subject: pinctrl: qcom: spmi-gpio: Add pmc8180 & pmc8180c The SC8180x platform comes with PMC8180 and PMC8180c, add support for the GPIO controller in these PMICs. Signed-off-by: Bjorn Andersson Acked-by: Rob Herring Link: https://lore.kernel.org/r/20210629003851.1787673-1-bjorn.andersson@linaro.org Signed-off-by: Linus Walleij --- Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.txt | 4 ++++ 1 file changed, 4 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 261a1d114253..48cc82d075e2 100644 --- a/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.txt +++ b/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.txt @@ -30,6 +30,8 @@ PMIC's from Qualcomm. "qcom,pm8994-gpio" "qcom,pm8998-gpio" "qcom,pma8084-gpio" + "qcom,pmc8180-gpio" + "qcom,pmc8180c-gpio" "qcom,pmi8950-gpio" "qcom,pmi8994-gpio" "qcom,pmi8998-gpio" @@ -122,6 +124,8 @@ to specify in a pin configuration subnode: gpio1-gpio22 for pm8994 gpio1-gpio26 for pm8998 gpio1-gpio22 for pma8084 + gpio1-gpio10 for pmc8180 + gpio1-gpio12 for pmc8180c gpio1-gpio2 for pmi8950 gpio1-gpio10 for pmi8994 gpio1-gpio4 for pmk8350 -- cgit v1.2.3 From 510fc3487b09ad4a921e18c60de7e3c634eb6e4e Mon Sep 17 00:00:00 2001 From: Alexandre Torgue Date: Fri, 23 Jul 2021 15:28:04 +0200 Subject: dt-bindings: pinctrl: stm32: add new compatible for STM32MP135 SoC New compatible to manage ball out and pin muxing of STM32MP135 SoC. Signed-off-by: Alexandre Torgue Acked-by: Rob Herring Acked-by: Arnd Bergmann --- Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.yaml index 72877544ca78..dfee6d38a701 100644 --- a/Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.yaml @@ -24,6 +24,7 @@ properties: - st,stm32f746-pinctrl - st,stm32f769-pinctrl - st,stm32h743-pinctrl + - st,stm32mp135-pinctrl - st,stm32mp157-pinctrl - st,stm32mp157-z-pinctrl -- cgit v1.2.3 From e3a35d03407cb3ef9488835aa861e07b45638d0b Mon Sep 17 00:00:00 2001 From: Mikulas Patocka Date: Tue, 27 Jul 2021 09:42:21 -0400 Subject: dm writecache: add event counters Add 10 counters for various events (hit, miss, etc) and export them in the status line (accessed from userspace with "dmsetup status"). Also add a message "clear_stats" that resets these counters. Signed-off-by: Mikulas Patocka Signed-off-by: Mike Snitzer --- Documentation/admin-guide/device-mapper/writecache.rst | 16 ++++++++++++++-- 1 file changed, 14 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/admin-guide/device-mapper/writecache.rst b/Documentation/admin-guide/device-mapper/writecache.rst index 65427d8dfca6..10429779a91a 100644 --- a/Documentation/admin-guide/device-mapper/writecache.rst +++ b/Documentation/admin-guide/device-mapper/writecache.rst @@ -78,13 +78,23 @@ Status: 2. the number of blocks 3. the number of free blocks 4. the number of blocks under writeback +5. the number of read requests +6. the number of read requests that hit the cache +7. the number of write requests +8. the number of write requests that hit uncommitted block +9. the number of write requests that hit committed block +10. the number of write requests that bypass the cache +11. the number of write requests that are allocated in the cache +12. the number of write requests that are blocked on the freelist +13. the number of flush requests +14. the number of discard requests Messages: flush - flush the cache device. The message returns successfully + Flush the cache device. The message returns successfully if the cache device was flushed without an error flush_on_suspend - flush the cache device on next suspend. Use this message + Flush the cache device on next suspend. Use this message when you are going to remove the cache device. The proper sequence for removing the cache device is: @@ -98,3 +108,5 @@ Messages: 6. the cache device is now inactive and it can be deleted cleaner See above "cleaner" constructor documentation. + clear_stats + Clear the statistics that are reported on the status line -- cgit v1.2.3 From 00d43995f0dd7a25961b87f953474d34043d4d4e Mon Sep 17 00:00:00 2001 From: Tushar Sugandhi Date: Mon, 12 Jul 2021 17:49:04 -0700 Subject: dm: add documentation for IMA measurement support To interpret various DM target measurement data in IMA logs, a separate documentation page is needed under Documentation/admin-guide/device-mapper. Add documentation to help system administrators and attestation client/server component owners to interpret the measurement data generated by various DM targets, on various device/table state changes. Signed-off-by: Tushar Sugandhi Signed-off-by: Mike Snitzer --- Documentation/admin-guide/device-mapper/dm-ima.rst | 306 +++++++++++++++++++++ Documentation/admin-guide/device-mapper/index.rst | 1 + 2 files changed, 307 insertions(+) create mode 100644 Documentation/admin-guide/device-mapper/dm-ima.rst (limited to 'Documentation') diff --git a/Documentation/admin-guide/device-mapper/dm-ima.rst b/Documentation/admin-guide/device-mapper/dm-ima.rst new file mode 100644 index 000000000000..41894112ff26 --- /dev/null +++ b/Documentation/admin-guide/device-mapper/dm-ima.rst @@ -0,0 +1,306 @@ +====== +dm-ima +====== + +For a given system, various external services/infrastructure tools +(including the attestation service) interact with it - both during the +setup and during rest of the system run-time. They share sensitive data +and/or execute critical workload on that system. The external services +may want to verify the current run-time state of the relevant kernel +subsystems before fully trusting the system with business-critical +data/workload. + +Device mapper plays a critical role on a given system by providing +various important functionalities to the block devices using various +target types like crypt, verity, integrity etc. Each of these target +types’ functionalities can be configured with various attributes. +The attributes chosen to configure these target types can significantly +impact the security profile of the block device, and in-turn, of the +system itself. For instance, the type of encryption algorithm and the +key size determines the strength of encryption for a given block device. + +Therefore, verifying the current state of various block devices as well +as their various target attributes is crucial for external services before +fully trusting the system with business-critical data/workload. + +IMA kernel subsystem provides the necessary functionality for +device mapper to measure the state and configuration of +various block devices - + - BY device mapper itself, from within the kernel, + - in a tamper resistant way, + - and re-measured - triggered on state/configuration change. + +Setting the IMA Policy: +======================= +For IMA to measure the data on a given system, the IMA policy on the +system needs to be updated to have following line, and the system needs +to be restarted for the measurements to take effect. + +/etc/ima/ima-policy + measure func=CRITICAL_DATA label=device-mapper template=ima-buf + +The measurements will be reflected in the IMA logs, which are located at: + +/sys/kernel/security/integrity/ima/ascii_runtime_measurements +/sys/kernel/security/integrity/ima/binary_runtime_measurements + +Then IMA ASCII measurement log has the following format: +PCR TEMPLATE_DIGEST TEMPLATE ALG:EVENT_DIGEST EVENT_NAME EVENT_DATA + +PCR := Platform Configuration Register, in which the values are registered. + This is applicable if TPM chip is in use. +TEMPLATE_DIGEST := Template digest of the IMA record. +TEMPLATE := Template that registered the integrity value (e.g. ima-buf). +ALG:EVENT_DIGEST = Algorithm to compute event digest, followed by digest of event data +EVENT_NAME := Description of the event (e.g. 'table_load'). +EVENT_DATA := The event data to be measured. + +The DM target data measured by IMA subsystem can alternatively +be queried from userspace by setting DM_IMA_MEASUREMENT_FLAG with +DM_TABLE_STATUS_CMD. + +Supported Device States: +======================== +Following device state changes will trigger IMA measurements. +01. Table load +02. Device resume +03. Device remove +04. Table clear +05. Device rename + +01. Table load: +--------------- +When a new table is loaded in a device's inactive table slot, +the device information and target specific details from the +targets in the table are measured. + +For instance, if a linear device is created with the following table entries, +# dmsetup create linear1 +0 2 linear /dev/loop0 512 +2 2 linear /dev/loop0 512 +4 2 linear /dev/loop0 512 +6 2 linear /dev/loop0 512 + +Then IMA ASCII measurement log will have an entry with: +EVENT_NAME := table_load +EVENT_DATA := [device_data];[target_data_row_1];[target_data_row_2];...[target_data_row_n]; + +E.g. +(converted from ASCII to text for readability) +10 a8c5ff755561c7a28146389d1514c318592af49a ima-buf sha256:4d73481ecce5eadba8ab084640d85bb9ca899af4d0a122989252a76efadc5b72 +table_load +name=linear1,uuid=,major=253,minor=0,minor_count=1,num_targets=4; +target_index=0,target_begin=0,target_len=2,target_name=linear,target_version=1.4.0,device_name=7:0,start=512; +target_index=1,target_begin=2,target_len=2,target_name=linear,target_version=1.4.0,device_name=7:0,start=512; +target_index=2,target_begin=4,target_len=2,target_name=linear,target_version=1.4.0,device_name=7:0,start=512; +target_index=3,target_begin=6,target_len=2,target_name=linear,target_version=1.4.0,device_name=7:0,start=512; + +02. Device resume: +------------------ +When a suspended device is resumed, the device information and a sha256 hash of the +data from previous load of an active table are measured. + +For instance, if a linear device is resumed with the following command, +#dmsetup resume linear1 + +Then IMA ASCII measurement log will have an entry with: +EVENT_NAME := device_resume +EVENT_DATA := [device_data];active_table_hash=(sha256hash([device_data];[target_data_row_1];...[target_data_row_n]); + current_device_capacity=; + +E.g. +(converted from ASCII to text for readability) +10 56c00cc062ffc24ccd9ac2d67d194af3282b934e ima-buf sha256:e7d12c03b958b4e0e53e7363a06376be88d98a1ac191fdbd3baf5e4b77f329b6 +device_resume +name=linear1,uuid=,major=253,minor=0,minor_count=1,num_targets=4; +active_table_hash=4d73481ecce5eadba8ab084640d85bb9ca899af4d0a122989252a76efadc5b72;current_device_capacity=8; + +03. Device remove: +------------------ +When a device is removed, the device information and a sha256 hash of the +data from an active and inactive table are measured. + +For instance, if a linear device is removed with the following command, +# dmsetup remove linear1 + +Then IMA ASCII measurement log will have an entry with: +EVENT_NAME := device_remove +EVENT_DATA := [device_active_metadata];[device_inactive_metadata]; + [active_table_hash=(sha256hash([device_active_metadata];[active_table_row_1];...[active_table_row_n]), + [inactive_table_hash=(sha256hash([device_inactive_metadata];[inactive_table_row_1];...[inactive_table_row_n]), + remove_all=[y|n];current_device_capacity=; + +E.g +(converted from ASCII to text for readability) +10 499812b621b705061c4514d643894483e16d2619 ima-buf sha256:c3f26b02f09bf5b464925589454bdd4d354077ce430fd1e75c9e96ce29cd1cad +device_remove +device_active_metadata=name=linear1,uuid=,major=253,minor=0,minor_count=1,num_targets=4; +device_inactive_metadata=name=linear1,uuid=,major=253,minor=0,minor_count=1,num_targets=2; +active_table_hash=4d73481ecce5eadba8ab084640d85bb9ca899af4d0a122989252a76efadc5b72, +inactive_table_hash=5596cc857b0e887fd0c5d58dc6382513284596b07f09fd37efae2da224bd521d,remove_all=n; +current_device_capacity=8; + + +04. Table clear: +---------------- +When an inactive table is cleared from the device, the device information and a sha256 hash of the +data from an inactive table are measured. + +For instance, if a linear device's inactive table is cleared with the following command, + +# dmsetup clear linear1 + +Then IMA ASCII measurement log will have an entry with: +EVENT_NAME := table_clear +EVENT_DATA := [device_data];inactive_table_hash=(sha256hash([device_data];[inactive_table_row_1];...[inactive_table_row_n]); +current_device_capacity=; + +E.g. +(converted from ASCII to text for readability) +10 9c11e284d792875352d51c09f6643c96649484be ima-buf sha256:84b22b364ea4d8264fa33c38635c18ef448fa9077731fa7e5f969b1da2003ea4 +table_clear +name=linear1,uuid=,major=253,minor=0,minor_count=1,num_targets=2; +inactive_table_hash=5596cc857b0e887fd0c5d58dc6382513284596b07f09fd37efae2da224bd521d;current_device_capacity=0; + + +05. Device rename: +------------------ +When an device's NAME or UUID is changed, the device information and the new NAME and UUID +are measured. + +For instance, if a linear device's name is changed with the following command, + +#dmsetup rename linear1 linear=2 +Then IMA ASCII measurement log will have an entry with: +EVENT_NAME := device_rename +EVENT_DATA := [current_device_data];new_name=;new_uuid=;current_device_capacity=; + +E.g 1: +#dmsetup rename linear1 --setuuid 1234-5678 + +IMA Log entry: +(converted from ASCII to text for readability) +10 7380ef4d1349fe1ebd74affa54e9fcc960e3cbf5 ima-buf sha256:9759e36a17a967ea43c1bf3455279395a40bd0401105ec5ad8edb9a52054efc7 +device_rename +name=linear1,uuid=,major=253,minor=0,minor_count=1,num_targets=1;new_name=linear1,new_uuid=1234-5678;current_device_capacity=2; + +E.g 2: +# dmsetup rename linear1 linear=2 +10 092c8266fc36e44f74c59f123ecfe15310f249f4 ima-buf sha256:4cf8b85c81fa6fedaeb602b05019124dbbb0605dce58fcdeea56887a8a3874cd +device_rename +name=linear1,uuid=1234-5678,major=253,minor=0,minor_count=1,num_targets=1;new_name=linear\=2,new_uuid=1234-5678;current_device_capacity=2; + + +Supported targets: +================== +Following targets are supported to measure their data using IMA. + +01. cache +02. crypt +03. integrity +04. linear +05. mirror +06. multipath +07. raid +08. snapshot +09. striped +10. verity + +01. cache +--------- +<> + +02. crypt +--------- +When a crypt target is loaded, then IMA ASCII measurement log will have an entry +similar to the following, depicting what crypt attributes are measured in EVENT_DATA. + +(converted from ASCII to text for readability) +10 fe3b80a35b155bd282df778e2625066c05fc068c ima-buf sha256:2d86ce9d6f16a4a97607318aa123ae816e0ceadefeea7903abf7f782f2cb78ad +table_load +name=test-crypt,uuid=,major=253,minor=0,minor_count=1,num_targets=1; +target_index=0,target_begin=0,target_len=1953125,target_name=crypt,target_version=1.23.0, +allow_discards=y,same_cpu=n,submit_from_crypt_cpus=n,no_read_workqueue=n,no_write_workqueue=n, +iv_large_sectors=n,cipher_string=aes-xts-plain64,key_size=32,key_parts=1,key_extra_size=0,key_mac_size=0; + +03. integrity +------------- +<> + + +04. linear +---------- +When a linear target is loaded, then IMA ASCII measurement log will have an entry +similar to the following, depicting what linear attributes are measured in EVENT_DATA. + +(converted from ASCII to text for readability) +10 a8c5ff755561c7a28146389d1514c318592af49a ima-buf sha256:4d73481ecce5eadba8ab084640d85bb9ca899af4d0a122989252a76efadc5b72 +table_load +name=linear1,uuid=,major=253,minor=0,minor_count=1,num_targets=4; +target_index=0,target_begin=0,target_len=2,target_name=linear,target_version=1.4.0,device_name=7:0,start=512; +target_index=1,target_begin=2,target_len=2,target_name=linear,target_version=1.4.0,device_name=7:0,start=512; +target_index=2,target_begin=4,target_len=2,target_name=linear,target_version=1.4.0,device_name=7:0,start=512; +target_index=3,target_begin=6,target_len=2,target_name=linear,target_version=1.4.0,device_name=7:0,start=512; + +05. mirror +---------- +When a mirror target is loaded, then IMA ASCII measurement log will have an entry +similar to the following, depicting what mirror attributes are measured in EVENT_DATA. + +(converted from ASCII to text for readability) +10 90ff9113a00c367df823595dc347425ce3bfc50a ima-buf sha256:8da0678ed3bf616533573d9e61e5342f2bd16cb0b3145a08262641a743806c2e +table_load +name=test-mirror,uuid=,major=253,minor=4,minor_count=1,num_targets=1; +target_index=0,target_begin=0,target_len=1953125,target_name=mirror,target_version=1.14.0, +nr_mirrors=2,mirror_device_0=253:2,mirror_device_0_status=A,mirror_device_1=253:3,mirror_device_1_status=A, +handle_errors=y,keep_log=n,log_type_status=; + +06. multipath +------------- +<> + +07. raid +-------- +When a raid target is loaded, then IMA ASCII measurement log will have an entry +similar to the following, depicting what raid attributes are measured in EVENT_DATA. + +(converted from ASCII to text for readability) +10 76cb30d0cd0fe099966f20f5c82e3a2ac29b21a0 ima-buf sha256:52250f20b27376fcfb348bdfa1e1cf5acfd6646e0f3ad1a72952cffd9f818753 +table_load +name=test-raid1,uuid=,major=253,minor=2,minor_count=1,num_targets=1; +target_index=0,target_begin=0,target_len=1953125,target_name=raid,target_version=1.15.1, +raid_type=raid1,raid_disks=2,raid_state=idle,raid_device_0_status=A,raid_device_1_status=A; + +08. snapshot +------------ +<> + +09. striped +----------- +When a linear target is loaded, then IMA ASCII measurement log will have an entry +similar to the following, depicting what linear attributes are measured in EVENT_DATA. + +(converted from ASCII to text for readability) +10 7bd94fa8f799169b9f12d97b9dbdce4dc5509233 ima-buf sha256:0d148eda69887f7833f1a6042767b54359cd23b64fa941b9e1856879eee1f778 +table_load +name=test-raid0,uuid=,major=253,minor=8,minor_count=1,num_targets=1; +target_index=0,target_begin=0,target_len=7812096,target_name=striped,target_version=1.6.0,stripes=4,chunk_size=128, +stripe_0_device_name=253:1,stripe_0_physical_start=0,stripe_0_status=A, +stripe_1_device_name=253:3,stripe_1_physical_start=0,stripe_1_status=A, +stripe_2_device_name=253:5,stripe_2_physical_start=0,stripe_2_status=A, +stripe_3_device_name=253:7,stripe_3_physical_start=0,stripe_3_status=A; + +10. verity +---------- +When a verity target is loaded, then IMA ASCII measurement log will have an entry +similar to the following, depicting what verity attributes are measured in EVENT_DATA. + +(converted from ASCII to text for readability) +10 fced5f575b140fc0efac302c88a635174cd663da ima-buf sha256:021370c1cc93929460b06922c606334fb1d7ea5ecf04f2384f3157a446894283 +table_load +name=test-verity,uuid=,major=253,minor=2,minor_count=1,num_targets=1; +target_index=0,target_begin=0,target_len=1953120,target_name=verity,target_version=1.8.0,hash_failed=V, +verity_version=1,data_device_name=253:1,hash_device_name=253:0,verity_algorithm=sha256, +root_digest=29cb87e60ce7b12b443ba6008266f3e41e93e403d7f298f8e3f316b29ff89c5e, +salt=e48da609055204e89ae53b655ca2216dd983cf3cb829f34f63a297d106d53e2d, +ignore_zero_blocks=n,check_at_most_once=n; diff --git a/Documentation/admin-guide/device-mapper/index.rst b/Documentation/admin-guide/device-mapper/index.rst index 6cf8adc86fa8..cde52cc09645 100644 --- a/Documentation/admin-guide/device-mapper/index.rst +++ b/Documentation/admin-guide/device-mapper/index.rst @@ -13,6 +13,7 @@ Device Mapper dm-dust dm-ebs dm-flakey + dm-ima dm-init dm-integrity dm-io -- cgit v1.2.3 From 3f12cc4bb0a4d7b542af43b6f1b7175f13015629 Mon Sep 17 00:00:00 2001 From: Hu Haowen Date: Wed, 28 Jul 2021 23:53:46 +0800 Subject: Documentation: i2c: add i2c-sysfs into index Append i2c-sysfs to toctree in order to get rid of building warnings. Fixes: 31df7195b100 ("Documentation: i2c: Add doc for I2C sysfs") Signed-off-by: Hu Haowen Signed-off-by: Wolfram Sang --- Documentation/i2c/index.rst | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/i2c/index.rst b/Documentation/i2c/index.rst index 8b76217e370a..6270f1fd7d4e 100644 --- a/Documentation/i2c/index.rst +++ b/Documentation/i2c/index.rst @@ -17,6 +17,7 @@ Introduction busses/index i2c-topology muxes/i2c-mux-gpio + i2c-sysfs Writing device drivers ====================== -- cgit v1.2.3 From 2a65927edb27a6cd277f4744b59064df839e984f Mon Sep 17 00:00:00 2001 From: Suman Anna Date: Mon, 9 Aug 2021 11:27:21 -0500 Subject: dt-bindings: soc: ti: pruss: Update bindings for K3 AM64x SoCs The K3 AM64x SoCs also have the Gigabit Ethernet capable PRU-ICSS IP that is present on existing K3 AM65x and J721E SoCs (ICSSG). The IP is similar to the ones used on K3 J721E or AM65x SR2.0 SoCs. Update the PRUSS bindings for these ICSSG instances. Signed-off-by: Suman Anna Reviewed-by: Grygorii Strashko Acked-by: Rob Herring Signed-off-by: Santosh Shilimkar --- Documentation/devicetree/bindings/soc/ti/ti,pruss.yaml | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/soc/ti/ti,pruss.yaml b/Documentation/devicetree/bindings/soc/ti/ti,pruss.yaml index 9790617af1bc..47d7fd24bc56 100644 --- a/Documentation/devicetree/bindings/soc/ti/ti,pruss.yaml +++ b/Documentation/devicetree/bindings/soc/ti/ti,pruss.yaml @@ -68,6 +68,7 @@ properties: - ti,k2g-pruss # for 66AK2G SoC family - ti,am654-icssg # for K3 AM65x SoC family - ti,j721e-icssg # for K3 J721E SoC family + - ti,am642-icssg # for K3 AM64x SoC family reg: maxItems: 1 @@ -231,8 +232,8 @@ patternProperties: description: | Industrial Ethernet Peripheral to manage/generate Industrial Ethernet functions such as time stamping. Each PRUSS has either 1 IEP (on AM335x, - AM437x, AM57xx & 66AK2G SoCs) or 2 IEPs (on K3 AM65x & J721E SoCs ). IEP - is used for creating PTP clocks and generating PPS signals. + AM437x, AM57xx & 66AK2G SoCs) or 2 IEPs (on K3 AM65x, J721E & AM64x SoCs). + IEP is used for creating PTP clocks and generating PPS signals. type: object @@ -331,6 +332,7 @@ if: - ti,k2g-pruss - ti,am654-icssg - ti,j721e-icssg + - ti,am642-icssg then: required: - power-domains -- cgit v1.2.3 From 62e8ce8506f5a998796dbdd93363fbed3342d379 Mon Sep 17 00:00:00 2001 From: Suman Anna Date: Mon, 9 Aug 2021 11:27:55 -0500 Subject: dt-bindings: soc: ti: pruss: Add dma-coherent property Update the PRUSS schema file to include the dma-coherent property that indicates the coherency of the IP. The PRUSS IPs on 66AK2G SoCs do use this property. The new added dma-coherent property is a required property _only_ for 66AK2G SoCs and is not required/applicable for other SoCs, so the binding is backward compatible for other SoCs. This update is being done before the corresponding dts nodes can be added for 66AK2G SoCs. Signed-off-by: Suman Anna Reviewed-by: Grygorii Strashko Reviewed-by: Rob Herring Signed-off-by: Santosh Shilimkar --- .../devicetree/bindings/soc/ti/ti,pruss.yaml | 37 +++++++++++++++------- 1 file changed, 25 insertions(+), 12 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/soc/ti/ti,pruss.yaml b/Documentation/devicetree/bindings/soc/ti/ti,pruss.yaml index 47d7fd24bc56..9d128b9e7deb 100644 --- a/Documentation/devicetree/bindings/soc/ti/ti,pruss.yaml +++ b/Documentation/devicetree/bindings/soc/ti/ti,pruss.yaml @@ -85,6 +85,8 @@ properties: dma-ranges: maxItems: 1 + dma-coherent: true + power-domains: description: | This property is as per sci-pm-domain.txt. @@ -324,18 +326,29 @@ additionalProperties: false # - interrupt-controller # - pru -if: - properties: - compatible: - contains: - enum: - - ti,k2g-pruss - - ti,am654-icssg - - ti,j721e-icssg - - ti,am642-icssg -then: - required: - - power-domains +allOf: + - if: + properties: + compatible: + contains: + enum: + - ti,k2g-pruss + - ti,am654-icssg + - ti,j721e-icssg + - ti,am642-icssg + then: + required: + - power-domains + + - if: + properties: + compatible: + contains: + enum: + - ti,k2g-pruss + then: + required: + - dma-coherent examples: - | -- cgit v1.2.3 From bbd33911cf3312dbba9149f544bebf796cd58d58 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=E5=91=A8=E7=90=B0=E6=9D=B0=20=28Zhou=20Yanjie=29?= Date: Sat, 24 Jul 2021 14:36:43 +0800 Subject: dt-bindings: pinctrl: Add bindings for Ingenic X2100. MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Add the pinctrl bindings for the X2100 SoC from Ingenic. Signed-off-by: 周琰杰 (Zhou Yanjie) Acked-by: Rob Herring Link: https://lore.kernel.org/r/1627108604-91304-4-git-send-email-zhouyanjie@wanyeetech.com Signed-off-by: Linus Walleij --- Documentation/devicetree/bindings/pinctrl/ingenic,pinctrl.yaml | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pinctrl/ingenic,pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/ingenic,pinctrl.yaml index a4846d78111c..a12d0ceb7637 100644 --- a/Documentation/devicetree/bindings/pinctrl/ingenic,pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/ingenic,pinctrl.yaml @@ -19,10 +19,10 @@ description: > pin within that GPIO port. For example PA0 is the first pin in GPIO port A, and PB31 is the last pin in GPIO port B. The JZ4730, the JZ4740, the JZ4725B, the X1000 and the X1830 contains 4 GPIO ports, PA to PD, for a total of 128 - pins. The X2000 contains 5 GPIO ports, PA to PE, for a total of 160 pins. - The JZ4750, the JZ4755 the JZ4760, the JZ4770 and the JZ4780 contains 6 GPIO - ports, PA to PF, for a total of 192 pins. The JZ4775 contains 7 GPIO ports, - PA to PG, for a total of 224 pins. + pins. The X2000 and the X2100 contains 5 GPIO ports, PA to PE, for a total of + 160 pins. The JZ4750, the JZ4755 the JZ4760, the JZ4770 and the JZ4780 contains + 6 GPIO ports, PA to PF, for a total of 192 pins. The JZ4775 contains 7 GPIO + ports, PA to PG, for a total of 224 pins. maintainers: - Paul Cercueil @@ -47,6 +47,7 @@ properties: - ingenic,x1500-pinctrl - ingenic,x1830-pinctrl - ingenic,x2000-pinctrl + - ingenic,x2100-pinctrl - items: - const: ingenic,jz4760b-pinctrl - const: ingenic,jz4760-pinctrl @@ -85,6 +86,7 @@ patternProperties: - ingenic,x1500-gpio - ingenic,x1830-gpio - ingenic,x2000-gpio + - ingenic,x2100-gpio reg: items: -- cgit v1.2.3 From b9ffc18c6388c0c62dbcfb486525825c0ca504f8 Mon Sep 17 00:00:00 2001 From: Hsin-Yi Wang Date: Wed, 4 Aug 2021 12:40:34 +0800 Subject: dt-bindings: mediatek: convert pinctrl to yaml Convert mt65xx, mt6796, mt7622, mt8183 bindings to yaml. Signed-off-by: Hsin-Yi Wang Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20210804044033.3047296-3-hsinyi@chromium.org Signed-off-by: Linus Walleij --- .../bindings/pinctrl/mediatek,mt65xx-pinctrl.yaml | 206 +++++++++ .../bindings/pinctrl/mediatek,mt6797-pinctrl.yaml | 173 ++++++++ .../bindings/pinctrl/mediatek,mt7622-pinctrl.yaml | 373 ++++++++++++++++ .../bindings/pinctrl/mediatek,mt8183-pinctrl.yaml | 228 ++++++++++ .../devicetree/bindings/pinctrl/pinctrl-mt65xx.txt | 156 ------- .../devicetree/bindings/pinctrl/pinctrl-mt6797.txt | 83 ---- .../devicetree/bindings/pinctrl/pinctrl-mt7622.txt | 490 --------------------- .../devicetree/bindings/pinctrl/pinctrl-mt8183.txt | 132 ------ 8 files changed, 980 insertions(+), 861 deletions(-) create mode 100644 Documentation/devicetree/bindings/pinctrl/mediatek,mt65xx-pinctrl.yaml create mode 100644 Documentation/devicetree/bindings/pinctrl/mediatek,mt6797-pinctrl.yaml create mode 100644 Documentation/devicetree/bindings/pinctrl/mediatek,mt7622-pinctrl.yaml create mode 100644 Documentation/devicetree/bindings/pinctrl/mediatek,mt8183-pinctrl.yaml delete mode 100644 Documentation/devicetree/bindings/pinctrl/pinctrl-mt65xx.txt delete mode 100644 Documentation/devicetree/bindings/pinctrl/pinctrl-mt6797.txt delete mode 100644 Documentation/devicetree/bindings/pinctrl/pinctrl-mt7622.txt delete mode 100644 Documentation/devicetree/bindings/pinctrl/pinctrl-mt8183.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pinctrl/mediatek,mt65xx-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/mediatek,mt65xx-pinctrl.yaml new file mode 100644 index 000000000000..f8e6e138dc13 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/mediatek,mt65xx-pinctrl.yaml @@ -0,0 +1,206 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pinctrl/mediatek,mt65xx-pinctrl.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Mediatek MT65xx Pin Controller Device Tree Bindings + +maintainers: + - Sean Wang + +description: |+ + The Mediatek's Pin controller is used to control SoC pins. + +properties: + compatible: + enum: + - mediatek,mt2701-pinctrl + - mediatek,mt2712-pinctrl + - mediatek,mt6397-pinctrl + - mediatek,mt7623-pinctrl + - mediatek,mt8127-pinctrl + - mediatek,mt8135-pinctrl + - mediatek,mt8167-pinctrl + - mediatek,mt8173-pinctrl + - mediatek,mt8516-pinctrl + + reg: + maxItems: 1 + + pins-are-numbered: + $ref: /schemas/types.yaml#/definitions/flag + description: | + Specify the subnodes are using numbered pinmux to specify pins. + + gpio-controller: true + + "#gpio-cells": + const: 2 + description: | + Number of cells in GPIO specifier. Since the generic GPIO + binding is used, the amount of cells must be specified as 2. See the below + mentioned gpio binding representation for description of particular cells. + + mediatek,pctl-regmap: + $ref: /schemas/types.yaml#/definitions/phandle-array + minItems: 1 + maxItems: 2 + description: | + Should be phandles of the syscfg node. + + interrupt-controller: true + + interrupts: + minItems: 1 + maxItems: 3 + + "#interrupt-cells": + const: 2 + +required: + - compatible + - pins-are-numbered + - gpio-controller + - "#gpio-cells" + +patternProperties: + '-[0-9]+$': + type: object + additionalProperties: false + patternProperties: + 'pins': + type: object + additionalProperties: false + description: | + A pinctrl node should contain at least one subnodes representing the + pinctrl groups available on the machine. Each subnode will list the + pins it needs, and how they should be configured, with regard to muxer + configuration, pullups, drive strength, input enable/disable and input + schmitt. + $ref: "/schemas/pinctrl/pincfg-node.yaml" + + properties: + pinmux: + description: + integer array, represents gpio pin number and mux setting. + Supported pin number and mux varies for different SoCs, and are + defined as macros in -pinfunc.h directly. + + bias-disable: true + + bias-pull-up: + description: | + Besides generic pinconfig options, it can be used as the pull up + settings for 2 pull resistors, R0 and R1. User can configure those + special pins. Some macros have been defined for this usage, such + as MTK_PUPD_SET_R1R0_00. See dt-bindings/pinctrl/mt65xx.h for + valid arguments. + + bias-pull-down: true + + input-enable: true + + input-disable: true + + output-low: true + + output-high: true + + input-schmitt-enable: true + + input-schmitt-disable: true + + drive-strength: + description: | + Can support some arguments, such as MTK_DRIVE_4mA, MTK_DRIVE_6mA, + etc. See dt-bindings/pinctrl/mt65xx.h for valid arguments. + + required: + - pinmux + +additionalProperties: false + +examples: + - | + #include + #include + #include + + soc { + #address-cells = <2>; + #size-cells = <2>; + + syscfg_pctl_a: syscfg-pctl-a@10005000 { + compatible = "mediatek,mt8135-pctl-a-syscfg", "syscon"; + reg = <0 0x10005000 0 0x1000>; + }; + + syscfg_pctl_b: syscfg-pctl-b@1020c020 { + compatible = "mediatek,mt8135-pctl-b-syscfg", "syscon"; + reg = <0 0x1020C020 0 0x1000>; + }; + + pinctrl@1c20800 { + compatible = "mediatek,mt8135-pinctrl"; + reg = <0 0x1000B000 0 0x1000>; + mediatek,pctl-regmap = <&syscfg_pctl_a>, <&syscfg_pctl_b>; + pins-are-numbered; + gpio-controller; + #gpio-cells = <2>; + interrupt-controller; + #interrupt-cells = <2>; + interrupts = , + , + ; + + i2c0_pins_a: i2c0-0 { + pins1 { + pinmux = , + ; + bias-disable; + }; + }; + + i2c1_pins_a: i2c1-0 { + pins { + pinmux = , + ; + bias-pull-up = ; + }; + }; + + i2c2_pins_a: i2c2-0 { + pins1 { + pinmux = ; + bias-pull-down; + }; + + pins2 { + pinmux = ; + bias-pull-up; + }; + }; + + i2c3_pins_a: i2c3-0 { + pins1 { + pinmux = , + ; + bias-pull-up = ; + }; + + pins2 { + pinmux = , + ; + output-low; + bias-pull-up = ; + }; + + pins3 { + pinmux = , + ; + drive-strength = <32>; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/pinctrl/mediatek,mt6797-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/mediatek,mt6797-pinctrl.yaml new file mode 100644 index 000000000000..76a6df75ed9c --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/mediatek,mt6797-pinctrl.yaml @@ -0,0 +1,173 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pinctrl/mediatek,mt6797-pinctrl.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Mediatek MT6797 Pin Controller Device Tree Bindings + +maintainers: + - Sean Wang + +description: |+ + The MediaTek's MT6797 Pin controller is used to control SoC pins. + +properties: + compatible: + const: mediatek,mt6797-pinctrl + + reg: + minItems: 5 + maxItems: 5 + + reg-names: + items: + - const: gpio + - const: iocfgl + - const: iocfgb + - const: iocfgr + - const: iocfgt + + gpio-controller: true + + "#gpio-cells": + const: 2 + description: | + Number of cells in GPIO specifier. Since the generic GPIO + binding is used, the amount of cells must be specified as 2. See the below + mentioned gpio binding representation for description of particular cells. + + interrupt-controller: true + + interrupts: + maxItems: 1 + + "#interrupt-cells": + const: 2 + +required: + - compatible + - reg + - reg-names + - gpio-controller + - "#gpio-cells" + +patternProperties: + '-[0-9]+$': + type: object + additionalProperties: false + patternProperties: + 'pins': + type: object + additionalProperties: false + description: | + A pinctrl node should contain at least one subnodes representing the + pinctrl groups available on the machine. Each subnode will list the + pins it needs, and how they should be configured, with regard to muxer + configuration, pullups, drive strength, input enable/disable and input + schmitt. + $ref: "/schemas/pinctrl/pincfg-node.yaml" + + properties: + pinmux: + description: + integer array, represents gpio pin number and mux setting. + Supported pin number and mux varies for different SoCs, and are + defined as macros in -pinfunc.h directly. + + bias-disable: true + + bias-pull-up: true + + bias-pull-down: true + + input-enable: true + + input-disable: true + + output-enable: true + + output-low: true + + output-high: true + + input-schmitt-enable: true + + input-schmitt-disable: true + + drive-strength: + enum: [2, 4, 8, 12, 16] + + slew-rate: + enum: [0, 1] + + mediatek,pull-up-adv: + description: | + Pull up setings for 2 pull resistors, R0 and R1. User can + configure those special pins. Valid arguments are described as below: + 0: (R1, R0) = (0, 0) which means R1 disabled and R0 disabled. + 1: (R1, R0) = (0, 1) which means R1 disabled and R0 enabled. + 2: (R1, R0) = (1, 0) which means R1 enabled and R0 disabled. + 3: (R1, R0) = (1, 1) which means R1 enabled and R0 enabled. + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1, 2, 3] + + mediatek,pull-down-adv: + description: | + Pull down settings for 2 pull resistors, R0 and R1. User can + configure those special pins. Valid arguments are described as below: + 0: (R1, R0) = (0, 0) which means R1 disabled and R0 disabled. + 1: (R1, R0) = (0, 1) which means R1 disabled and R0 enabled. + 2: (R1, R0) = (1, 0) which means R1 enabled and R0 disabled. + 3: (R1, R0) = (1, 1) which means R1 enabled and R0 enabled. + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1, 2, 3] + + mediatek,tdsel: + description: | + An integer describing the steps for output level shifter duty + cycle when asserted (high pulse width adjustment). Valid arguments + are from 0 to 15. + $ref: /schemas/types.yaml#/definitions/uint32 + + mediatek,rdsel: + description: | + An integer describing the steps for input level shifter duty cycle + when asserted (high pulse width adjustment). Valid arguments are + from 0 to 63. + $ref: /schemas/types.yaml#/definitions/uint32 + + required: + - pinmux + +additionalProperties: false + +examples: + - | + #include + #include + #include + + soc { + #address-cells = <2>; + #size-cells = <2>; + + pio: pinctrl@10005000 { + compatible = "mediatek,mt6797-pinctrl"; + reg = <0 0x10005000 0 0x1000>, + <0 0x10002000 0 0x400>, + <0 0x10002400 0 0x400>, + <0 0x10002800 0 0x400>, + <0 0x10002C00 0 0x400>; + reg-names = "gpio", "iocfgl", "iocfgb", "iocfgr", "iocfgt"; + gpio-controller; + #gpio-cells = <2>; + + uart_pins_a: uart-0 { + pins1 { + pinmux = , + ; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/pinctrl/mediatek,mt7622-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/mediatek,mt7622-pinctrl.yaml new file mode 100644 index 000000000000..0feecd376c69 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/mediatek,mt7622-pinctrl.yaml @@ -0,0 +1,373 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pinctrl/mediatek,mt7622-pinctrl.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Mediatek MT7622 Pin Controller Device Tree Bindings + +maintainers: + - Sean Wang + +description: |+ + The MediaTek's MT7622 Pin controller is used to control SoC pins. + +properties: + compatible: + enum: + - mediatek,mt7622-pinctrl + - mediatek,mt7629-pinctrl + + reg: + maxItems: 1 + + reg-names: + items: + - const: eint + + gpio-controller: true + + "#gpio-cells": + const: 2 + description: | + Number of cells in GPIO specifier. Since the generic GPIO + binding is used, the amount of cells must be specified as 2. See the below + mentioned gpio binding representation for description of particular cells. + + interrupt-controller: true + + interrupts: + maxItems: 1 + + "#interrupt-cells": + const: 2 + +required: + - compatible + - reg + - gpio-controller + - "#gpio-cells" + +if: + required: + - interrupt-controller +then: + required: + - reg-names + - interrupts + - "#interrupt-cells" + +patternProperties: + '-[0-9]+$': + type: object + additionalProperties: false + patternProperties: + 'mux': + type: object + additionalProperties: false + description: | + pinmux configuration nodes. + $ref: "/schemas/pinctrl/pinmux-node.yaml" + properties: + function: + description: | + A string containing the name of the function to mux to the group. + enum: [emmc, eth, i2c, i2s, ir, led, flash, pcie, pmic, pwm, sd, + spi, tdm, uart, watchdog, wifi] + + groups: + description: | + An array of strings. Each string contains the name of a group. + + drive-strength: + enum: [4, 8, 12, 16] + + required: + - groups + - function + + allOf: + - if: + properties: + function: + const: emmc + then: + properties: + groups: + enum: [emmc, emmc_rst] + - if: + properties: + function: + const: eth + then: + properties: + groups: + enum: [esw, esw_p0_p1, esw_p2_p3_p4, rgmii_via_esw, + rgmii_via_gmac1, rgmii_via_gmac2, mdc_mdio] + - if: + properties: + function: + const: i2c + then: + properties: + groups: + enum: [i2c0, i2c_0, i2c_1, i2c1_0, i2c1_1, i2c1_2, i2c2_0, + i2c2_1, i2c2_2] + - if: + properties: + function: + const: i2s + then: + properties: + groups: + enum: [i2s_in_mclk_bclk_ws, i2s1_in_data, i2s2_in_data, + i2s3_in_data, i2s4_in_data, i2s_out_mclk_bclk_ws, + i2s1_out_data, i2s2_out_data, i2s3_out_data, + i2s4_out_data] + - if: + properties: + function: + const: ir + then: + properties: + groups: + enum: [ir_0_tx, ir_1_tx, ir_2_tx, ir_0_rx, ir_1_rx, ir_2_rx] + - if: + properties: + function: + const: led + then: + properties: + groups: + enum: [ephy_leds, ephy0_led, ephy1_led, ephy2_led, ephy3_led, + ephy4_led, wled, wf2g_led, wf5g_led] + - if: + properties: + function: + const: flash + then: + properties: + groups: + enum: [par_nand, snfi, spi_nor] + - if: + properties: + function: + const: pcie + then: + properties: + groups: + enum: [pcie0_0_waken, pcie0_1_waken, pcie1_0_waken, + pcie0_0_clkreq, pcie0_1_clkreq, pcie1_0_clkreq, + pcie0_pad_perst, pcie1_pad_perst, pcie_pereset, + pcie_wake, pcie_clkreq] + - if: + properties: + function: + const: pmic + then: + properties: + groups: + enum: [pmic_bus] + - if: + properties: + function: + const: pwm + then: + properties: + groups: + enum: [pwm_ch1_0, pwm_ch1_1, pwm_ch1_2, pwm_ch2_0, pwm_ch2_1, + pwm_ch2_2, pwm_ch3_0, pwm_ch3_1, pwm_ch3_2, pwm_ch4_0, + pwm_ch4_1, pwm_ch4_2, pwm_ch4_3, pwm_ch5_0, pwm_ch5_1, + pwm_ch5_2, pwm_ch6_0, pwm_ch6_1, pwm_ch6_2, pwm_ch6_3, + pwm_ch7_0, pwm_0, pwm_1] + - if: + properties: + function: + const: sd + then: + properties: + groups: + enum: [sd_0, sd_1] + - if: + properties: + function: + const: spi + then: + properties: + groups: + enum: [spic0_0, spic0_1, spic1_0, spic1_1, spic2_0_wp_hold, + spic2_0, spi_0, spi_1, spi_wp, spi_hold] + - if: + properties: + function: + const: tdm + then: + properties: + groups: + enum: [tdm_0_out_mclk_bclk_ws, tdm_0_in_mclk_bclk_ws, + tdm_0_out_data, tdm_0_in_data, tdm_1_out_mclk_bclk_ws, + tdm_1_in_mclk_bclk_ws, tdm_1_out_data, tdm_1_in_data] + - if: + properties: + function: + const: uart + then: + properties: + groups: + enum: [uart0_0_tx_rx, uart1_0_tx_rx, uart1_0_rts_cts, + uart1_1_tx_rx, uart1_1_rts_cts, uart2_0_tx_rx, + uart2_0_rts_cts, uart2_1_tx_rx, uart2_1_rts_cts, + uart2_2_tx_rx, uart2_2_rts_cts, uart2_3_tx_rx, + uart3_0_tx_rx, uart3_1_tx_rx, uart3_1_rts_cts, + uart4_0_tx_rx, uart4_1_tx_rx, uart4_1_rts_cts, + uart4_2_tx_rx, uart4_2_rts_cts, uart0_txd_rxd, + uart1_0_txd_rxd, uart1_0_cts_rts, uart1_1_txd_rxd, + uart1_1_cts_rts, uart2_0_txd_rxd, uart2_0_cts_rts, + uart2_1_txd_rxd, uart2_1_cts_rts] + - if: + properties: + function: + const: watchdog + then: + properties: + groups: + enum: [watchdog] + - if: + properties: + function: + const: wifi + then: + properties: + groups: + enum: [wf0_2g, wf0_5g] + + 'conf': + type: object + additionalProperties: false + description: | + pinconf configuration nodes. + $ref: "/schemas/pinctrl/pincfg-node.yaml" + + properties: + groups: + description: | + An array of strings. Each string contains the name of a group. + Valid values are the same as the pinmux node. + + pins: + description: | + An array of strings. Each string contains the name of a pin. + enum: [GPIO_A, I2S1_IN, I2S1_OUT, I2S_BCLK, I2S_WS, I2S_MCLK, TXD0, + RXD0, SPI_WP, SPI_HOLD, SPI_CLK, SPI_MOSI, SPI_MISO, SPI_CS, + I2C_SDA, I2C_SCL, I2S2_IN, I2S3_IN, I2S4_IN, I2S2_OUT, + I2S3_OUT, I2S4_OUT, GPIO_B, MDC, MDIO, G2_TXD0, G2_TXD1, + G2_TXD2, G2_TXD3, G2_TXEN, G2_TXC, G2_RXD0, G2_RXD1, G2_RXD2, + G2_RXD3, G2_RXDV, G2_RXC, NCEB, NWEB, NREB, NDL4, NDL5, NDL6, + NDL7, NRB, NCLE, NALE, NDL0, NDL1, NDL2, NDL3, MDI_TP_P0, + MDI_TN_P0, MDI_RP_P0, MDI_RN_P0, MDI_TP_P1, MDI_TN_P1, + MDI_RP_P1, MDI_RN_P1, MDI_RP_P2, MDI_RN_P2, MDI_TP_P2, + MDI_TN_P2, MDI_TP_P3, MDI_TN_P3, MDI_RP_P3, MDI_RN_P3, + MDI_RP_P4, MDI_RN_P4, MDI_TP_P4, MDI_TN_P4, PMIC_SCL, + PMIC_SDA, SPIC1_CLK, SPIC1_MOSI, SPIC1_MISO, SPIC1_CS, + GPIO_D, WATCHDOG, RTS3_N, CTS3_N, TXD3, RXD3, PERST0_N, + PERST1_N, WLED_N, EPHY_LED0_N, AUXIN0, AUXIN1, AUXIN2, + AUXIN3, TXD4, RXD4, RTS4_N, CST4_N, PWM1, PWM2, PWM3, PWM4, + PWM5, PWM6, PWM7, GPIO_E, TOP_5G_CLK, TOP_5G_DATA, + WF0_5G_HB0, WF0_5G_HB1, WF0_5G_HB2, WF0_5G_HB3, WF0_5G_HB4, + WF0_5G_HB5, WF0_5G_HB6, XO_REQ, TOP_RST_N, SYS_WATCHDOG, + EPHY_LED0_N_JTDO, EPHY_LED1_N_JTDI, EPHY_LED2_N_JTMS, + EPHY_LED3_N_JTCLK, EPHY_LED4_N_JTRST_N, WF2G_LED_N, + WF5G_LED_N, GPIO_9, GPIO_10, GPIO_11, GPIO_12, UART1_TXD, + UART1_RXD, UART1_CTS, UART1_RTS, UART2_TXD, UART2_RXD, + UART2_CTS, UART2_RTS, SMI_MDC, SMI_MDIO, PCIE_PERESET_N, + PWM_0, GPIO_0, GPIO_1, GPIO_2, GPIO_3, GPIO_4, GPIO_5, + GPIO_6, GPIO_7, GPIO_8, UART0_TXD, UART0_RXD, TOP_2G_CLK, + TOP_2G_DATA, WF0_2G_HB0, WF0_2G_HB1, WF0_2G_HB2, WF0_2G_HB3, + WF0_2G_HB4, WF0_2G_HB5, WF0_2G_HB6] + + bias-disable: true + + bias-pull-up: true + + bias-pull-down: true + + input-enable: true + + input-disable: true + + output-enable: true + + output-low: true + + output-high: true + + input-schmitt-enable: true + + input-schmitt-disable: true + + drive-strength: + enum: [4, 8, 12, 16] + + slew-rate: + enum: [0, 1] + + mediatek,tdsel: + description: | + An integer describing the steps for output level shifter duty + cycle when asserted (high pulse width adjustment). Valid arguments + are from 0 to 15. + $ref: /schemas/types.yaml#/definitions/uint32 + + mediatek,rdsel: + description: | + An integer describing the steps for input level shifter duty cycle + when asserted (high pulse width adjustment). Valid arguments are + from 0 to 63. + $ref: /schemas/types.yaml#/definitions/uint32 + + required: + - pins + +additionalProperties: false + +examples: + - | + #include + #include + + soc { + #address-cells = <2>; + #size-cells = <2>; + + pio: pinctrl@10211000 { + compatible = "mediatek,mt7622-pinctrl"; + reg = <0 0x10211000 0 0x1000>; + gpio-controller; + #gpio-cells = <2>; + + pinctrl_eth_default: eth-0 { + mux-mdio { + groups = "mdc_mdio"; + function = "eth"; + drive-strength = <12>; + }; + + mux-gmac2 { + groups = "rgmii_via_gmac2"; + function = "eth"; + drive-strength = <12>; + }; + + mux-esw { + groups = "esw"; + function = "eth"; + drive-strength = <8>; + }; + + conf-mdio { + pins = "MDC"; + bias-pull-up; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/pinctrl/mediatek,mt8183-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/mediatek,mt8183-pinctrl.yaml new file mode 100644 index 000000000000..cc1509e9b981 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/mediatek,mt8183-pinctrl.yaml @@ -0,0 +1,228 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pinctrl/mediatek,mt8183-pinctrl.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Mediatek MT8183 Pin Controller Device Tree Bindings + +maintainers: + - Sean Wang + +description: |+ + The MediaTek's MT8183 Pin controller is used to control SoC pins. + +properties: + compatible: + const: mediatek,mt8183-pinctrl + + reg: + minItems: 10 + maxItems: 10 + + reg-names: + items: + - const: iocfg0 + - const: iocfg1 + - const: iocfg2 + - const: iocfg3 + - const: iocfg4 + - const: iocfg5 + - const: iocfg6 + - const: iocfg7 + - const: iocfg8 + - const: eint + + gpio-controller: true + + "#gpio-cells": + const: 2 + description: | + Number of cells in GPIO specifier. Since the generic GPIO + binding is used, the amount of cells must be specified as 2. See the below + mentioned gpio binding representation for description of particular cells. + + gpio-ranges: + minItems: 1 + maxItems: 5 + description: | + GPIO valid number range. + + interrupt-controller: true + + interrupts: + maxItems: 1 + + "#interrupt-cells": + const: 2 + +required: + - compatible + - reg + - gpio-controller + - "#gpio-cells" + - gpio-ranges + +patternProperties: + '-[0-9]+$': + type: object + additionalProperties: false + patternProperties: + 'pins': + type: object + additionalProperties: false + description: | + A pinctrl node should contain at least one subnodes representing the + pinctrl groups available on the machine. Each subnode will list the + pins it needs, and how they should be configured, with regard to muxer + configuration, pullups, drive strength, input enable/disable and input + schmitt. + $ref: "/schemas/pinctrl/pincfg-node.yaml" + + properties: + pinmux: + description: + integer array, represents gpio pin number and mux setting. + Supported pin number and mux varies for different SoCs, and are + defined as macros in -pinfunc.h directly. + + bias-disable: true + + bias-pull-up: true + + bias-pull-down: true + + input-enable: true + + input-disable: true + + output-low: true + + output-high: true + + input-schmitt-enable: true + + input-schmitt-disable: true + + drive-strength: + enum: [2, 4, 6, 8, 10, 12, 14, 16] + + mediatek,drive-strength-adv: + description: | + Describe the specific driving setup property. + For I2C pins, the existing generic driving setup can only support + 2/4/6/8/10/12/14/16mA driving. But in specific driving setup, they + can support 0.125/0.25/0.5/1mA adjustment. If we enable specific + driving setup, the existing generic setup will be disabled. + The specific driving setup is controlled by E1E0EN. + When E1=0/E0=0, the strength is 0.125mA. + When E1=0/E0=1, the strength is 0.25mA. + When E1=1/E0=0, the strength is 0.5mA. + When E1=1/E0=1, the strength is 1mA. + EN is used to enable or disable the specific driving setup. + Valid arguments are described as below: + 0: (E1, E0, EN) = (0, 0, 0) + 1: (E1, E0, EN) = (0, 0, 1) + 2: (E1, E0, EN) = (0, 1, 0) + 3: (E1, E0, EN) = (0, 1, 1) + 4: (E1, E0, EN) = (1, 0, 0) + 5: (E1, E0, EN) = (1, 0, 1) + 6: (E1, E0, EN) = (1, 1, 0) + 7: (E1, E0, EN) = (1, 1, 1) + So the valid arguments are from 0 to 7. + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1, 2, 3, 4, 5, 6, 7] + + mediatek,pull-up-adv: + description: | + Pull up setings for 2 pull resistors, R0 and R1. User can + configure those special pins. Valid arguments are described as below: + 0: (R1, R0) = (0, 0) which means R1 disabled and R0 disabled. + 1: (R1, R0) = (0, 1) which means R1 disabled and R0 enabled. + 2: (R1, R0) = (1, 0) which means R1 enabled and R0 disabled. + 3: (R1, R0) = (1, 1) which means R1 enabled and R0 enabled. + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1, 2, 3] + + mediatek,pull-down-adv: + description: | + Pull down settings for 2 pull resistors, R0 and R1. User can + configure those special pins. Valid arguments are described as below: + 0: (R1, R0) = (0, 0) which means R1 disabled and R0 disabled. + 1: (R1, R0) = (0, 1) which means R1 disabled and R0 enabled. + 2: (R1, R0) = (1, 0) which means R1 enabled and R0 disabled. + 3: (R1, R0) = (1, 1) which means R1 enabled and R0 enabled. + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1, 2, 3] + + mediatek,tdsel: + description: | + An integer describing the steps for output level shifter duty + cycle when asserted (high pulse width adjustment). Valid arguments + are from 0 to 15. + $ref: /schemas/types.yaml#/definitions/uint32 + + mediatek,rdsel: + description: | + An integer describing the steps for input level shifter duty cycle + when asserted (high pulse width adjustment). Valid arguments are + from 0 to 63. + $ref: /schemas/types.yaml#/definitions/uint32 + + required: + - pinmux + +additionalProperties: false + +examples: + - | + #include + #include + #include + + soc { + #address-cells = <2>; + #size-cells = <2>; + + pio: pinctrl@10005000 { + compatible = "mediatek,mt8183-pinctrl"; + reg = <0 0x10005000 0 0x1000>, + <0 0x11f20000 0 0x1000>, + <0 0x11e80000 0 0x1000>, + <0 0x11e70000 0 0x1000>, + <0 0x11e90000 0 0x1000>, + <0 0x11d30000 0 0x1000>, + <0 0x11d20000 0 0x1000>, + <0 0x11c50000 0 0x1000>, + <0 0x11f30000 0 0x1000>, + <0 0x1000b000 0 0x1000>; + reg-names = "iocfg0", "iocfg1", "iocfg2", + "iocfg3", "iocfg4", "iocfg5", + "iocfg6", "iocfg7", "iocfg8", + "eint"; + gpio-controller; + #gpio-cells = <2>; + gpio-ranges = <&pio 0 0 192>; + interrupt-controller; + interrupts = ; + #interrupt-cells = <2>; + + i2c0_pins_a: i2c-0 { + pins1 { + pinmux = , + ; + mediatek,pull-up-adv = <3>; + mediatek,drive-strength-adv = <7>; + }; + }; + + i2c1_pins_a: i2c-1 { + pins { + pinmux = , + ; + mediatek,pull-down-adv = <2>; + mediatek,drive-strength-adv = <4>; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-mt65xx.txt b/Documentation/devicetree/bindings/pinctrl/pinctrl-mt65xx.txt deleted file mode 100644 index 5fe2c26c28bf..000000000000 --- a/Documentation/devicetree/bindings/pinctrl/pinctrl-mt65xx.txt +++ /dev/null @@ -1,156 +0,0 @@ -* Mediatek MT65XX Pin Controller - -The Mediatek's Pin controller is used to control SoC pins. - -Required properties: -- compatible: value should be one of the following. - "mediatek,mt2701-pinctrl", compatible with mt2701 pinctrl. - "mediatek,mt2712-pinctrl", compatible with mt2712 pinctrl. - "mediatek,mt6397-pinctrl", compatible with mt6397 pinctrl. - "mediatek,mt7623-pinctrl", compatible with mt7623 pinctrl. - "mediatek,mt8127-pinctrl", compatible with mt8127 pinctrl. - "mediatek,mt8135-pinctrl", compatible with mt8135 pinctrl. - "mediatek,mt8167-pinctrl", compatible with mt8167 pinctrl. - "mediatek,mt8173-pinctrl", compatible with mt8173 pinctrl. - "mediatek,mt8365-pinctrl", compatible with mt8365 pinctrl. - "mediatek,mt8516-pinctrl", compatible with mt8516 pinctrl. -- pins-are-numbered: Specify the subnodes are using numbered pinmux to - specify pins. -- gpio-controller : Marks the device node as a gpio controller. -- #gpio-cells: number of cells in GPIO specifier. Since the generic GPIO - binding is used, the amount of cells must be specified as 2. See the below - mentioned gpio binding representation for description of particular cells. - - Eg: <&pio 6 0> - <[phandle of the gpio controller node] - [line number within the gpio controller] - [flags]> - - Values for gpio specifier: - - Line number: is a value between 0 to 202. - - Flags: bit field of flags, as defined in . - Only the following flags are supported: - 0 - GPIO_ACTIVE_HIGH - 1 - GPIO_ACTIVE_LOW - -Optional properties: -- mediatek,pctl-regmap: Should be a phandle of the syscfg node. -- reg: physicall address base for EINT registers -- interrupt-controller: Marks the device node as an interrupt controller -- #interrupt-cells: Should be two. -- interrupts : The interrupt outputs from the controller. - -Please refer to pinctrl-bindings.txt in this directory for details of the -common pinctrl bindings used by client devices. - -Subnode format -A pinctrl node should contain at least one subnodes representing the -pinctrl groups available on the machine. Each subnode will list the -pins it needs, and how they should be configured, with regard to muxer -configuration, pullups, drive strength, input enable/disable and input schmitt. - - node { - pinmux = ; - GENERIC_PINCONFIG; - }; - -Required properties: -- pinmux: integer array, represents gpio pin number and mux setting. - Supported pin number and mux varies for different SoCs, and are defined - as macros in boot/dts/-pinfunc.h directly. - -Optional properties: -- GENERIC_PINCONFIG: is the generic pinconfig options to use, bias-disable, - bias-pull-down, bias-pull-up, input-enable, input-disable, output-low, output-high, - input-schmitt-enable, input-schmitt-disable and drive-strength are valid. - - Some special pins have extra pull up strength, there are R0 and R1 pull-up - resistors available, but for user, it's only need to set R1R0 as 00, 01, 10 or 11. - So when config bias-pull-up, it support arguments for those special pins. - Some macros have been defined for this usage, such as MTK_PUPD_SET_R1R0_00. - See dt-bindings/pinctrl/mt65xx.h. - - When config drive-strength, it can support some arguments, such as - MTK_DRIVE_4mA, MTK_DRIVE_6mA, etc. See dt-bindings/pinctrl/mt65xx.h. - -Examples: - -#include "mt8135-pinfunc.h" - -... -{ - syscfg_pctl_a: syscfg-pctl-a@10005000 { - compatible = "mediatek,mt8135-pctl-a-syscfg", "syscon"; - reg = <0 0x10005000 0 0x1000>; - }; - - syscfg_pctl_b: syscfg-pctl-b@1020c020 { - compatible = "mediatek,mt8135-pctl-b-syscfg", "syscon"; - reg = <0 0x1020C020 0 0x1000>; - }; - - pinctrl@1c20800 { - compatible = "mediatek,mt8135-pinctrl"; - reg = <0 0x1000B000 0 0x1000>; - mediatek,pctl-regmap = <&syscfg_pctl_a>, <&syscfg_pctl_b>; - pins-are-numbered; - gpio-controller; - #gpio-cells = <2>; - interrupt-controller; - #interrupt-cells = <2>; - interrupts = , - , - ; - - i2c0_pins_a: i2c0@0 { - pins1 { - pinmux = , - ; - bias-disable; - }; - }; - - i2c1_pins_a: i2c1@0 { - pins { - pinmux = , - ; - bias-pull-up = <55>; - }; - }; - - i2c2_pins_a: i2c2@0 { - pins1 { - pinmux = ; - bias-pull-down; - }; - - pins2 { - pinmux = ; - bias-pull-up; - }; - }; - - i2c3_pins_a: i2c3@0 { - pins1 { - pinmux = , - ; - bias-pull-up = <55>; - }; - - pins2 { - pinmux = , - ; - output-low; - bias-pull-up = <55>; - }; - - pins3 { - pinmux = , - ; - drive-strength = <32>; - }; - }; - - ... - } -}; diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-mt6797.txt b/Documentation/devicetree/bindings/pinctrl/pinctrl-mt6797.txt deleted file mode 100644 index bd83401e6179..000000000000 --- a/Documentation/devicetree/bindings/pinctrl/pinctrl-mt6797.txt +++ /dev/null @@ -1,83 +0,0 @@ -* MediaTek MT6797 Pin Controller - -The MediaTek's MT6797 Pin controller is used to control SoC pins. - -Required properties: -- compatible: Value should be one of the following. - "mediatek,mt6797-pinctrl", compatible with mt6797 pinctrl. -- reg: Should contain address and size for gpio, iocfgl, iocfgb, - iocfgr and iocfgt register bases. -- reg-names: An array of strings describing the "reg" entries. Must - contain "gpio", "iocfgl", "iocfgb", "iocfgr", "iocfgt". -- gpio-controller: Marks the device node as a gpio controller. -- #gpio-cells: Should be two. The first cell is the gpio pin number - and the second cell is used for optional parameters. - -Optional properties: -- interrupt-controller: Marks the device node as an interrupt controller. -- #interrupt-cells: Should be two. -- interrupts : The interrupt outputs from the controller. - -Please refer to pinctrl-bindings.txt in this directory for details of the -common pinctrl bindings used by client devices. - -Subnode format -A pinctrl node should contain at least one subnodes representing the -pinctrl groups available on the machine. Each subnode will list the -pins it needs, and how they should be configured, with regard to muxer -configuration, pullups, drive strength, input enable/disable and input schmitt. - - node { - pinmux = ; - GENERIC_PINCONFIG; - }; - -Required properties: -- pinmux: Integer array, represents gpio pin number and mux setting. - Supported pin number and mux varies for different SoCs, and are defined - as macros in dt-bindings/pinctrl/-pinfunc.h directly. - -Optional properties: -- GENERIC_PINCONFIG: is the generic pinconfig options to use, bias-disable, - bias-pull, bias-pull-down, input-enable, input-schmitt-enable, - input-schmitt-disable, output-enable output-low, output-high, - drive-strength, and slew-rate are valid. - - Valid arguments for 'slew-rate' are '0' for no slew rate controlled and - '1' for slower slew rate respectively. Valid arguments for 'drive-strength' - is limited, such as 2, 4, 8, 12, or 16 in mA. - - Some optional vendor properties as defined are valid to specify in a - pinconf subnode: - - mediatek,tdsel: An integer describing the steps for output level shifter - duty cycle when asserted (high pulse width adjustment). Valid arguments - are from 0 to 15. - - mediatek,rdsel: An integer describing the steps for input level shifter - duty cycle when asserted (high pulse width adjustment). Valid arguments - are from 0 to 63. - - mediatek,pull-up-adv: An integer describing the code R1R0 as 0, 1, 2 - or 3 for the advanced pull-up resistors. - - mediatek,pull-down-adv: An integer describing the code R1R0 as 0, 1, 2, - or 3 for the advanced pull-down resistors. - -Examples: - - pio: pinctrl@10005000 { - compatible = "mediatek,mt6797-pinctrl"; - reg = <0 0x10005000 0 0x1000>, - <0 0x10002000 0 0x400>, - <0 0x10002400 0 0x400>, - <0 0x10002800 0 0x400>, - <0 0x10002C00 0 0x400>; - reg-names = "gpio", "iocfgl", "iocfgb", - "iocfgr", "iocfgt"; - gpio-controller; - #gpio-cells = <2>; - - uart1_pins_a: uart1 { - pins1 { - pinmux = , - ; - }; - }; - }; diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-mt7622.txt b/Documentation/devicetree/bindings/pinctrl/pinctrl-mt7622.txt deleted file mode 100644 index 7a7aca1ed705..000000000000 --- a/Documentation/devicetree/bindings/pinctrl/pinctrl-mt7622.txt +++ /dev/null @@ -1,490 +0,0 @@ -== MediaTek MT7622 pinctrl controller == - -Required properties for the root node: - - compatible: Should be one of the following - "mediatek,mt7622-pinctrl" for MT7622 SoC - "mediatek,mt7629-pinctrl" for MT7629 SoC - - reg: offset and length of the pinctrl space - - - gpio-controller: Marks the device node as a GPIO controller. - - #gpio-cells: Should be two. The first cell is the pin number and the - second is the GPIO flags. - -Optional properties: -- interrupt-controller : Marks the device node as an interrupt controller - -If the property interrupt-controller is defined, following property is required -- reg-names: A string describing the "reg" entries. Must contain "eint". -- interrupts : The interrupt output from the controller. -- #interrupt-cells: Should be two. - -Please refer to pinctrl-bindings.txt in this directory for details of the -common pinctrl bindings used by client devices, including the meaning of the -phrase "pin configuration node". - -MT7622 pin configuration nodes act as a container for an arbitrary number of -subnodes. Each of these subnodes represents some desired configuration for a -pin, a group, or a list of pins or groups. This configuration can include the -mux function to select on those pin(s)/group(s), and various pin configuration -parameters, such as pull-up, slew rate, etc. - -We support 2 types of configuration nodes. Those nodes can be either pinmux -nodes or pinconf nodes. Each configuration node can consist of multiple nodes -describing the pinmux and pinconf options. - -The name of each subnode doesn't matter as long as it is unique; all subnodes -should be enumerated and processed purely based on their content. - -== pinmux nodes content == - -The following generic properties as defined in pinctrl-bindings.txt are valid -to specify in a pinmux subnode: - -Required properties are: - - groups: An array of strings. Each string contains the name of a group. - Valid values for these names are listed below. - - function: A string containing the name of the function to mux to the - group. Valid values for function names are listed below. - -== pinconf nodes content == - -The following generic properties as defined in pinctrl-bindings.txt are valid -to specify in a pinconf subnode: - -Required properties are: - - pins: An array of strings. Each string contains the name of a pin. - Valid values for these names are listed below. - - groups: An array of strings. Each string contains the name of a group. - Valid values for these names are listed below. - -Optional properies are: - bias-disable, bias-pull, bias-pull-down, input-enable, - input-schmitt-enable, input-schmitt-disable, output-enable - output-low, output-high, drive-strength, slew-rate - - Valid arguments for 'slew-rate' are '0' for no slew rate controlled and '1' for - slower slew rate respectively. - Valid arguments for 'drive-strength', 4, 8, 12, or 16 in mA. - -The following specific properties as defined are valid to specify in a pinconf -subnode: - -Optional properties are: - - mediatek,tdsel: An integer describing the steps for output level shifter duty - cycle when asserted (high pulse width adjustment). Valid arguments are from 0 - to 15. - - mediatek,rdsel: An integer describing the steps for input level shifter duty - cycle when asserted (high pulse width adjustment). Valid arguments are from 0 - to 63. - -== Valid values for pins, function and groups on MT7622 == - -Valid values for pins are: -pins can be referenced via the pin names as the below table shown and the -related physical number is also put ahead of those names which helps cross -references to pins between groups to know whether pins assignment conflict -happens among devices try to acquire those available pins. - - Pin #: Valid values for pins - ----------------------------- - PIN 0: "GPIO_A" - PIN 1: "I2S1_IN" - PIN 2: "I2S1_OUT" - PIN 3: "I2S_BCLK" - PIN 4: "I2S_WS" - PIN 5: "I2S_MCLK" - PIN 6: "TXD0" - PIN 7: "RXD0" - PIN 8: "SPI_WP" - PIN 9: "SPI_HOLD" - PIN 10: "SPI_CLK" - PIN 11: "SPI_MOSI" - PIN 12: "SPI_MISO" - PIN 13: "SPI_CS" - PIN 14: "I2C_SDA" - PIN 15: "I2C_SCL" - PIN 16: "I2S2_IN" - PIN 17: "I2S3_IN" - PIN 18: "I2S4_IN" - PIN 19: "I2S2_OUT" - PIN 20: "I2S3_OUT" - PIN 21: "I2S4_OUT" - PIN 22: "GPIO_B" - PIN 23: "MDC" - PIN 24: "MDIO" - PIN 25: "G2_TXD0" - PIN 26: "G2_TXD1" - PIN 27: "G2_TXD2" - PIN 28: "G2_TXD3" - PIN 29: "G2_TXEN" - PIN 30: "G2_TXC" - PIN 31: "G2_RXD0" - PIN 32: "G2_RXD1" - PIN 33: "G2_RXD2" - PIN 34: "G2_RXD3" - PIN 35: "G2_RXDV" - PIN 36: "G2_RXC" - PIN 37: "NCEB" - PIN 38: "NWEB" - PIN 39: "NREB" - PIN 40: "NDL4" - PIN 41: "NDL5" - PIN 42: "NDL6" - PIN 43: "NDL7" - PIN 44: "NRB" - PIN 45: "NCLE" - PIN 46: "NALE" - PIN 47: "NDL0" - PIN 48: "NDL1" - PIN 49: "NDL2" - PIN 50: "NDL3" - PIN 51: "MDI_TP_P0" - PIN 52: "MDI_TN_P0" - PIN 53: "MDI_RP_P0" - PIN 54: "MDI_RN_P0" - PIN 55: "MDI_TP_P1" - PIN 56: "MDI_TN_P1" - PIN 57: "MDI_RP_P1" - PIN 58: "MDI_RN_P1" - PIN 59: "MDI_RP_P2" - PIN 60: "MDI_RN_P2" - PIN 61: "MDI_TP_P2" - PIN 62: "MDI_TN_P2" - PIN 63: "MDI_TP_P3" - PIN 64: "MDI_TN_P3" - PIN 65: "MDI_RP_P3" - PIN 66: "MDI_RN_P3" - PIN 67: "MDI_RP_P4" - PIN 68: "MDI_RN_P4" - PIN 69: "MDI_TP_P4" - PIN 70: "MDI_TN_P4" - PIN 71: "PMIC_SCL" - PIN 72: "PMIC_SDA" - PIN 73: "SPIC1_CLK" - PIN 74: "SPIC1_MOSI" - PIN 75: "SPIC1_MISO" - PIN 76: "SPIC1_CS" - PIN 77: "GPIO_D" - PIN 78: "WATCHDOG" - PIN 79: "RTS3_N" - PIN 80: "CTS3_N" - PIN 81: "TXD3" - PIN 82: "RXD3" - PIN 83: "PERST0_N" - PIN 84: "PERST1_N" - PIN 85: "WLED_N" - PIN 86: "EPHY_LED0_N" - PIN 87: "AUXIN0" - PIN 88: "AUXIN1" - PIN 89: "AUXIN2" - PIN 90: "AUXIN3" - PIN 91: "TXD4" - PIN 92: "RXD4" - PIN 93: "RTS4_N" - PIN 94: "CST4_N" - PIN 95: "PWM1" - PIN 96: "PWM2" - PIN 97: "PWM3" - PIN 98: "PWM4" - PIN 99: "PWM5" - PIN 100: "PWM6" - PIN 101: "PWM7" - PIN 102: "GPIO_E" - -Valid values for function are: - "emmc", "eth", "i2c", "i2s", "ir", "led", "flash", "pcie", - "pmic", "pwm", "sd", "spi", "tdm", "uart", "watchdog" - -Valid values for groups are: -additional data is put followingly with valid value allowing us to know which -applicable function and which relevant pins (in pin#) are able applied for that -group. - - Valid value function pins (in pin#) - ------------------------------------------------------------------------- - "emmc" "emmc" 40, 41, 42, 43, 44, 45, - 47, 48, 49, 50 - "emmc_rst" "emmc" 37 - "esw" "eth" 51, 52, 53, 54, 55, 56, - 57, 58, 59, 60, 61, 62, - 63, 64, 65, 66, 67, 68, - 69, 70 - "esw_p0_p1" "eth" 51, 52, 53, 54, 55, 56, - 57, 58 - "esw_p2_p3_p4" "eth" 59, 60, 61, 62, 63, 64, - 65, 66, 67, 68, 69, 70 - "rgmii_via_esw" "eth" 59, 60, 61, 62, 63, 64, - 65, 66, 67, 68, 69, 70 - "rgmii_via_gmac1" "eth" 59, 60, 61, 62, 63, 64, - 65, 66, 67, 68, 69, 70 - "rgmii_via_gmac2" "eth" 25, 26, 27, 28, 29, 30, - 31, 32, 33, 34, 35, 36 - "mdc_mdio" "eth" 23, 24 - "i2c0" "i2c" 14, 15 - "i2c1_0" "i2c" 55, 56 - "i2c1_1" "i2c" 73, 74 - "i2c1_2" "i2c" 87, 88 - "i2c2_0" "i2c" 57, 58 - "i2c2_1" "i2c" 75, 76 - "i2c2_2" "i2c" 89, 90 - "i2s_in_mclk_bclk_ws" "i2s" 3, 4, 5 - "i2s1_in_data" "i2s" 1 - "i2s2_in_data" "i2s" 16 - "i2s3_in_data" "i2s" 17 - "i2s4_in_data" "i2s" 18 - "i2s_out_mclk_bclk_ws" "i2s" 3, 4, 5 - "i2s1_out_data" "i2s" 2 - "i2s2_out_data" "i2s" 19 - "i2s3_out_data" "i2s" 20 - "i2s4_out_data" "i2s" 21 - "ir_0_tx" "ir" 16 - "ir_1_tx" "ir" 59 - "ir_2_tx" "ir" 99 - "ir_0_rx" "ir" 17 - "ir_1_rx" "ir" 60 - "ir_2_rx" "ir" 100 - "ephy_leds" "led" 86, 91, 92, 93, 94 - "ephy0_led" "led" 86 - "ephy1_led" "led" 91 - "ephy2_led" "led" 92 - "ephy3_led" "led" 93 - "ephy4_led" "led" 94 - "wled" "led" 85 - "par_nand" "flash" 37, 38, 39, 40, 41, 42, - 43, 44, 45, 46, 47, 48, - 49, 50 - "snfi" "flash" 8, 9, 10, 11, 12, 13 - "spi_nor" "flash" 8, 9, 10, 11, 12, 13 - "pcie0_0_waken" "pcie" 14 - "pcie0_1_waken" "pcie" 79 - "pcie1_0_waken" "pcie" 14 - "pcie0_0_clkreq" "pcie" 15 - "pcie0_1_clkreq" "pcie" 80 - "pcie1_0_clkreq" "pcie" 15 - "pcie0_pad_perst" "pcie" 83 - "pcie1_pad_perst" "pcie" 84 - "pmic_bus" "pmic" 71, 72 - "pwm_ch1_0" "pwm" 51 - "pwm_ch1_1" "pwm" 73 - "pwm_ch1_2" "pwm" 95 - "pwm_ch2_0" "pwm" 52 - "pwm_ch2_1" "pwm" 74 - "pwm_ch2_2" "pwm" 96 - "pwm_ch3_0" "pwm" 53 - "pwm_ch3_1" "pwm" 75 - "pwm_ch3_2" "pwm" 97 - "pwm_ch4_0" "pwm" 54 - "pwm_ch4_1" "pwm" 67 - "pwm_ch4_2" "pwm" 76 - "pwm_ch4_3" "pwm" 98 - "pwm_ch5_0" "pwm" 68 - "pwm_ch5_1" "pwm" 77 - "pwm_ch5_2" "pwm" 99 - "pwm_ch6_0" "pwm" 69 - "pwm_ch6_1" "pwm" 78 - "pwm_ch6_2" "pwm" 81 - "pwm_ch6_3" "pwm" 100 - "pwm_ch7_0" "pwm" 70 - "pwm_ch7_1" "pwm" 82 - "pwm_ch7_2" "pwm" 101 - "sd_0" "sd" 16, 17, 18, 19, 20, 21 - "sd_1" "sd" 25, 26, 27, 28, 29, 30 - "spic0_0" "spi" 63, 64, 65, 66 - "spic0_1" "spi" 79, 80, 81, 82 - "spic1_0" "spi" 67, 68, 69, 70 - "spic1_1" "spi" 73, 74, 75, 76 - "spic2_0_wp_hold" "spi" 8, 9 - "spic2_0" "spi" 10, 11, 12, 13 - "tdm_0_out_mclk_bclk_ws" "tdm" 8, 9, 10 - "tdm_0_in_mclk_bclk_ws" "tdm" 11, 12, 13 - "tdm_0_out_data" "tdm" 20 - "tdm_0_in_data" "tdm" 21 - "tdm_1_out_mclk_bclk_ws" "tdm" 57, 58, 59 - "tdm_1_in_mclk_bclk_ws" "tdm" 60, 61, 62 - "tdm_1_out_data" "tdm" 55 - "tdm_1_in_data" "tdm" 56 - "uart0_0_tx_rx" "uart" 6, 7 - "uart1_0_tx_rx" "uart" 55, 56 - "uart1_0_rts_cts" "uart" 57, 58 - "uart1_1_tx_rx" "uart" 73, 74 - "uart1_1_rts_cts" "uart" 75, 76 - "uart2_0_tx_rx" "uart" 3, 4 - "uart2_0_rts_cts" "uart" 1, 2 - "uart2_1_tx_rx" "uart" 51, 52 - "uart2_1_rts_cts" "uart" 53, 54 - "uart2_2_tx_rx" "uart" 59, 60 - "uart2_2_rts_cts" "uart" 61, 62 - "uart2_3_tx_rx" "uart" 95, 96 - "uart3_0_tx_rx" "uart" 57, 58 - "uart3_1_tx_rx" "uart" 81, 82 - "uart3_1_rts_cts" "uart" 79, 80 - "uart4_0_tx_rx" "uart" 61, 62 - "uart4_1_tx_rx" "uart" 91, 92 - "uart4_1_rts_cts" "uart" 93, 94 - "uart4_2_tx_rx" "uart" 97, 98 - "uart4_2_rts_cts" "uart" 95, 96 - "watchdog" "watchdog" 78 - - -== Valid values for pins, function and groups on MT7629 == - - Pin #: Valid values for pins - ----------------------------- - PIN 0: "TOP_5G_CLK" - PIN 1: "TOP_5G_DATA" - PIN 2: "WF0_5G_HB0" - PIN 3: "WF0_5G_HB1" - PIN 4: "WF0_5G_HB2" - PIN 5: "WF0_5G_HB3" - PIN 6: "WF0_5G_HB4" - PIN 7: "WF0_5G_HB5" - PIN 8: "WF0_5G_HB6" - PIN 9: "XO_REQ" - PIN 10: "TOP_RST_N" - PIN 11: "SYS_WATCHDOG" - PIN 12: "EPHY_LED0_N_JTDO" - PIN 13: "EPHY_LED1_N_JTDI" - PIN 14: "EPHY_LED2_N_JTMS" - PIN 15: "EPHY_LED3_N_JTCLK" - PIN 16: "EPHY_LED4_N_JTRST_N" - PIN 17: "WF2G_LED_N" - PIN 18: "WF5G_LED_N" - PIN 19: "I2C_SDA" - PIN 20: "I2C_SCL" - PIN 21: "GPIO_9" - PIN 22: "GPIO_10" - PIN 23: "GPIO_11" - PIN 24: "GPIO_12" - PIN 25: "UART1_TXD" - PIN 26: "UART1_RXD" - PIN 27: "UART1_CTS" - PIN 28: "UART1_RTS" - PIN 29: "UART2_TXD" - PIN 30: "UART2_RXD" - PIN 31: "UART2_CTS" - PIN 32: "UART2_RTS" - PIN 33: "MDI_TP_P1" - PIN 34: "MDI_TN_P1" - PIN 35: "MDI_RP_P1" - PIN 36: "MDI_RN_P1" - PIN 37: "MDI_RP_P2" - PIN 38: "MDI_RN_P2" - PIN 39: "MDI_TP_P2" - PIN 40: "MDI_TN_P2" - PIN 41: "MDI_TP_P3" - PIN 42: "MDI_TN_P3" - PIN 43: "MDI_RP_P3" - PIN 44: "MDI_RN_P3" - PIN 45: "MDI_RP_P4" - PIN 46: "MDI_RN_P4" - PIN 47: "MDI_TP_P4" - PIN 48: "MDI_TN_P4" - PIN 49: "SMI_MDC" - PIN 50: "SMI_MDIO" - PIN 51: "PCIE_PERESET_N" - PIN 52: "PWM_0" - PIN 53: "GPIO_0" - PIN 54: "GPIO_1" - PIN 55: "GPIO_2" - PIN 56: "GPIO_3" - PIN 57: "GPIO_4" - PIN 58: "GPIO_5" - PIN 59: "GPIO_6" - PIN 60: "GPIO_7" - PIN 61: "GPIO_8" - PIN 62: "SPI_CLK" - PIN 63: "SPI_CS" - PIN 64: "SPI_MOSI" - PIN 65: "SPI_MISO" - PIN 66: "SPI_WP" - PIN 67: "SPI_HOLD" - PIN 68: "UART0_TXD" - PIN 69: "UART0_RXD" - PIN 70: "TOP_2G_CLK" - PIN 71: "TOP_2G_DATA" - PIN 72: "WF0_2G_HB0" - PIN 73: "WF0_2G_HB1" - PIN 74: "WF0_2G_HB2" - PIN 75: "WF0_2G_HB3" - PIN 76: "WF0_2G_HB4" - PIN 77: "WF0_2G_HB5" - PIN 78: "WF0_2G_HB6" - -Valid values for function are: - "eth", "i2c", "led", "flash", "pcie", "pwm", "spi", "uart", - "watchdog", "wifi" - -Valid values for groups are: - Valid value function pins (in pin#) - ---------------------------------------------------------------- - "mdc_mdio" "eth" 23, 24 - "i2c_0" "i2c" 19, 20 - "i2c_1" "i2c" 53, 54 - "ephy_leds" "led" 12, 13, 14, 15, 16, - 17, 18 - "ephy0_led" "led" 12 - "ephy1_led" "led" 13 - "ephy2_led" "led" 14 - "ephy3_led" "led" 15 - "ephy4_led" "led" 16 - "wf2g_led" "led" 17 - "wf5g_led" "led" 18 - "snfi" "flash" 62, 63, 64, 65, 66, 67 - "spi_nor" "flash" 62, 63, 64, 65, 66, 67 - "pcie_pereset" "pcie" 51 - "pcie_wake" "pcie" 55 - "pcie_clkreq" "pcie" 56 - "pwm_0" "pwm" 52 - "pwm_1" "pwm" 61 - "spi_0" "spi" 21, 22, 23, 24 - "spi_1" "spi" 62, 63, 64, 65 - "spi_wp" "spi" 66 - "spi_hold" "spi" 67 - "uart0_txd_rxd" "uart" 68, 69 - "uart1_0_txd_rxd" "uart" 25, 26 - "uart1_0_cts_rts" "uart" 27, 28 - "uart1_1_txd_rxd" "uart" 53, 54 - "uart1_1_cts_rts" "uart" 55, 56 - "uart2_0_txd_rxd" "uart" 29, 30 - "uart2_0_cts_rts" "uart" 31, 32 - "uart2_1_txd_rxd" "uart" 57, 58 - "uart2_1_cts_rts" "uart" 59, 60 - "watchdog" "watchdog" 11 - "wf0_2g" "wifi" 70, 71, 72, 73, 74, - 75, 76, 77, 78 - "wf0_5g" "wifi" 0, 1, 2, 3, 4, 5, 6, - 7, 8, 9, 10 - -Example: - - pio: pinctrl@10211000 { - compatible = "mediatek,mt7622-pinctrl"; - reg = <0 0x10211000 0 0x1000>; - gpio-controller; - #gpio-cells = <2>; - - pinctrl_eth_default: eth-default { - mux-mdio { - groups = "mdc_mdio"; - function = "eth"; - drive-strength = <12>; - }; - - mux-gmac2 { - groups = "gmac2"; - function = "eth"; - drive-strength = <12>; - }; - - mux-esw { - groups = "esw"; - function = "eth"; - drive-strength = <8>; - }; - - conf-mdio { - pins = "MDC"; - bias-pull-up; - }; - }; - }; diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-mt8183.txt b/Documentation/devicetree/bindings/pinctrl/pinctrl-mt8183.txt deleted file mode 100644 index eccbe3f55d3f..000000000000 --- a/Documentation/devicetree/bindings/pinctrl/pinctrl-mt8183.txt +++ /dev/null @@ -1,132 +0,0 @@ -* Mediatek MT8183 Pin Controller - -The Mediatek's Pin controller is used to control SoC pins. - -Required properties: -- compatible: value should be one of the following. - "mediatek,mt8183-pinctrl", compatible with mt8183 pinctrl. -- gpio-controller : Marks the device node as a gpio controller. -- #gpio-cells: number of cells in GPIO specifier. Since the generic GPIO - binding is used, the amount of cells must be specified as 2. See the below - mentioned gpio binding representation for description of particular cells. -- gpio-ranges : gpio valid number range. -- reg: physical address base for gpio base registers. There are 10 GPIO - physical address base in mt8183. - -Optional properties: -- reg-names: gpio base register names. There are 10 gpio base register - names in mt8183. They are "iocfg0", "iocfg1", "iocfg2", "iocfg3", "iocfg4", - "iocfg5", "iocfg6", "iocfg7", "iocfg8", "eint". -- interrupt-controller: Marks the device node as an interrupt controller -- #interrupt-cells: Should be two. -- interrupts : The interrupt outputs to sysirq. - -Please refer to pinctrl-bindings.txt in this directory for details of the -common pinctrl bindings used by client devices. - -Subnode format -A pinctrl node should contain at least one subnodes representing the -pinctrl groups available on the machine. Each subnode will list the -pins it needs, and how they should be configured, with regard to muxer -configuration, pullups, drive strength, input enable/disable and input schmitt. - - node { - pinmux = ; - GENERIC_PINCONFIG; - }; - -Required properties: -- pinmux: integer array, represents gpio pin number and mux setting. - Supported pin number and mux varies for different SoCs, and are defined - as macros in boot/dts/-pinfunc.h directly. - -Optional properties: -- GENERIC_PINCONFIG: is the generic pinconfig options to use, bias-disable, - bias-pull-down, bias-pull-up, input-enable, input-disable, output-low, - output-high, input-schmitt-enable, input-schmitt-disable - and drive-strength are valid. - - Some special pins have extra pull up strength, there are R0 and R1 pull-up - resistors available, but for user, it's only need to set R1R0 as 00, 01, - 10 or 11. So It needs config "mediatek,pull-up-adv" or - "mediatek,pull-down-adv" to support arguments for those special pins. - Valid arguments are from 0 to 3. - - mediatek,tdsel: An integer describing the steps for output level shifter - duty cycle when asserted (high pulse width adjustment). Valid arguments - are from 0 to 15. - mediatek,rdsel: An integer describing the steps for input level shifter - duty cycle when asserted (high pulse width adjustment). Valid arguments - are from 0 to 63. - - When config drive-strength, it can support some arguments, such as - MTK_DRIVE_4mA, MTK_DRIVE_6mA, etc. See dt-bindings/pinctrl/mt65xx.h. - It can only support 2/4/6/8/10/12/14/16mA in mt8183. - For I2C pins, there are existing generic driving setup and the specific - driving setup. I2C pins can only support 2/4/6/8/10/12/14/16mA driving - adjustment in generic driving setup. But in specific driving setup, - they can support 0.125/0.25/0.5/1mA adjustment. If we enable specific - driving setup for I2C pins, the existing generic driving setup will be - disabled. For some special features, we need the I2C pins specific - driving setup. The specific driving setup is controlled by E1E0EN. - So we need add extra vendor driving preperty instead of - the generic driving property. - We can add "mediatek,drive-strength-adv = ;" to describe the specific - driving setup property. "XXX" means the value of E1E0EN. EN is 0 or 1. - It is used to enable or disable the specific driving setup. - E1E0 is used to describe the detail strength specification of the I2C pin. - When E1=0/E0=0, the strength is 0.125mA. - When E1=0/E0=1, the strength is 0.25mA. - When E1=1/E0=0, the strength is 0.5mA. - When E1=1/E0=1, the strength is 1mA. - So the valid arguments of "mediatek,drive-strength-adv" are from 0 to 7. - -Examples: - -#include "mt8183-pinfunc.h" - -... -{ - pio: pinctrl@10005000 { - compatible = "mediatek,mt8183-pinctrl"; - reg = <0 0x10005000 0 0x1000>, - <0 0x11f20000 0 0x1000>, - <0 0x11e80000 0 0x1000>, - <0 0x11e70000 0 0x1000>, - <0 0x11e90000 0 0x1000>, - <0 0x11d30000 0 0x1000>, - <0 0x11d20000 0 0x1000>, - <0 0x11c50000 0 0x1000>, - <0 0x11f30000 0 0x1000>, - <0 0x1000b000 0 0x1000>; - reg-names = "iocfg0", "iocfg1", "iocfg2", - "iocfg3", "iocfg4", "iocfg5", - "iocfg6", "iocfg7", "iocfg8", - "eint"; - gpio-controller; - #gpio-cells = <2>; - gpio-ranges = <&pio 0 0 192>; - interrupt-controller; - interrupts = ; - #interrupt-cells = <2>; - - i2c0_pins_a: i2c0 { - pins1 { - pinmux = , - ; - mediatek,pull-up-adv = <3>; - mediatek,drive-strength-adv = <7>; - }; - }; - - i2c1_pins_a: i2c1 { - pins { - pinmux = , - ; - mediatek,pull-down-adv = <2>; - mediatek,drive-strength-adv = <4>; - }; - }; - ... - }; -}; -- cgit v1.2.3 From 936c985478716b228f42f47c075d4ea10dfa98bb Mon Sep 17 00:00:00 2001 From: Chen-Yu Tsai Date: Mon, 26 Jul 2021 19:19:41 +0800 Subject: dt-bindings: pinctrl: mt8195: Use real world values for drive-strength arguments The original binding submission for MT8195 pinctrl described the possible drive strength values in micro-amps in its description, but then proceeded to list register values in its device tree binding constraints. However, the macros used with the Mediatek pinctrl bindings directly specify the drive strength in micro-amps, instead of hardware register values. The current driver implementation in Linux does convert the value from micro-amps to hardware register values. This implementation is also used with MT7622 and MT8183, which use real world values in their device trees. Given the above, it was likely an oversight to use the raw register values in the binding. Correct the values in the binding. Also drop the description since the binding combined with its parent, pinctrl/pincfg.yaml, the binding is now self-describing. Fixes: 7f7663899d94 ("dt-bindings: pinctrl: mt8195: add pinctrl file and binding document") Signed-off-by: Chen-Yu Tsai Acked-by: Rob Herring Link: https://lore.kernel.org/r/20210726111941.1447057-1-wenst@chromium.org Signed-off-by: Linus Walleij --- Documentation/devicetree/bindings/pinctrl/pinctrl-mt8195.yaml | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-mt8195.yaml b/Documentation/devicetree/bindings/pinctrl/pinctrl-mt8195.yaml index 2f12ec59eee5..e17a399e0904 100644 --- a/Documentation/devicetree/bindings/pinctrl/pinctrl-mt8195.yaml +++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-mt8195.yaml @@ -80,10 +80,7 @@ patternProperties: as macros in dt-bindings/pinctrl/-pinfunc.h directly. drive-strength: - description: | - It can support some arguments which is from 0 to 7. It can only support - 2/4/6/8/10/12/14/16mA in mt8195. - enum: [0, 1, 2, 3, 4, 5, 6, 7] + enum: [2, 4, 6, 8, 10, 12, 14, 16] bias-pull-down: true -- cgit v1.2.3 From 328fb93a84686d8884b9b7ce1107ae0a46c194f7 Mon Sep 17 00:00:00 2001 From: satya priya Date: Mon, 2 Aug 2021 18:51:03 +0530 Subject: dt-bindings: pinctrl: qcom-pmic-gpio: Convert qcom pmic gpio bindings to YAML Convert Qualcomm PMIC GPIO bindings from .txt to .yaml format. Signed-off-by: satya priya Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/1627910464-19363-3-git-send-email-skakit@codeaurora.org Signed-off-by: Linus Walleij --- .../devicetree/bindings/pinctrl/qcom,pmic-gpio.txt | 294 --------------------- .../bindings/pinctrl/qcom,pmic-gpio.yaml | 259 ++++++++++++++++++ 2 files changed, 259 insertions(+), 294 deletions(-) delete mode 100644 Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.txt create mode 100644 Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.txt b/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.txt deleted file mode 100644 index 48cc82d075e2..000000000000 --- a/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.txt +++ /dev/null @@ -1,294 +0,0 @@ -Qualcomm PMIC GPIO block - -This binding describes the GPIO block(s) found in the 8xxx series of -PMIC's from Qualcomm. - -- compatible: - Usage: required - Value type: - Definition: must be one of: - "qcom,pm660-gpio" - "qcom,pm660l-gpio" - "qcom,pm6150-gpio" - "qcom,pm6150l-gpio" - "qcom,pm7325-gpio" - "qcom,pm8005-gpio" - "qcom,pm8008-gpio" - "qcom,pm8018-gpio" - "qcom,pm8038-gpio" - "qcom,pm8058-gpio" - "qcom,pm8150-gpio" - "qcom,pm8150b-gpio" - "qcom,pm8350-gpio" - "qcom,pm8350b-gpio" - "qcom,pm8350c-gpio" - "qcom,pm8916-gpio" - "qcom,pm8917-gpio" - "qcom,pm8921-gpio" - "qcom,pm8941-gpio" - "qcom,pm8950-gpio" - "qcom,pm8994-gpio" - "qcom,pm8998-gpio" - "qcom,pma8084-gpio" - "qcom,pmc8180-gpio" - "qcom,pmc8180c-gpio" - "qcom,pmi8950-gpio" - "qcom,pmi8994-gpio" - "qcom,pmi8998-gpio" - "qcom,pmk8350-gpio" - "qcom,pmm8155au-gpio" - "qcom,pmr735a-gpio" - "qcom,pmr735b-gpio" - "qcom,pms405-gpio" - "qcom,pmx55-gpio" - - And must contain either "qcom,spmi-gpio" or "qcom,ssbi-gpio" - if the device is on an spmi bus or an ssbi bus respectively - -- reg: - Usage: required - Value type: - Definition: Register base of the GPIO block and length. - -- interrupts: - Usage: required - Value type: - Definition: Must contain an array of encoded interrupt specifiers for - each available GPIO - -- gpio-controller: - Usage: required - Value type: - Definition: Mark the device node as a GPIO controller - -- #gpio-cells: - Usage: required - Value type: - Definition: Must be 2; - the first cell will be used to define gpio number and the - second denotes the flags for this gpio - -Please refer to ../gpio/gpio.txt and ../interrupt-controller/interrupts.txt for -a general description of GPIO and interrupt bindings. - -Please refer to pinctrl-bindings.txt in this directory for details of the -common pinctrl bindings used by client devices, including the meaning of the -phrase "pin configuration node". - -The pin configuration nodes act as a container for an arbitrary number of -subnodes. Each of these subnodes represents some desired configuration for a -pin or a list of pins. This configuration can include the -mux function to select on those pin(s), and various pin configuration -parameters, as listed below. - - -SUBNODES: - -The name of each subnode is not important; all subnodes should be enumerated -and processed purely based on their content. - -Each subnode only affects those parameters that are explicitly listed. In -other words, a subnode that lists a mux function but no pin configuration -parameters implies no information about any pin configuration parameters. -Similarly, a pin subnode that describes a pullup parameter implies no -information about e.g. the mux function. - -The following generic properties as defined in pinctrl-bindings.txt are valid -to specify in a pin configuration subnode: - -- pins: - Usage: required - Value type: - Definition: List of gpio pins affected by the properties specified in - this subnode. Valid pins are: - gpio1-gpio10 for pm6150 - gpio1-gpio12 for pm6150l - gpio1-gpio10 for pm7325 - gpio1-gpio4 for pm8005 - gpio1-gpio2 for pm8008 - gpio1-gpio6 for pm8018 - gpio1-gpio12 for pm8038 - gpio1-gpio40 for pm8058 - gpio1-gpio10 for pm8150 (holes on gpio2, gpio5, gpio7 - and gpio8) - gpio1-gpio12 for pm8150b (holes on gpio3, gpio4, gpio7) - gpio1-gpio12 for pm8150l (hole on gpio7) - gpio1-gpio10 for pm8350 - gpio1-gpio8 for pm8350b - gpio1-gpio9 for pm8350c - gpio1-gpio4 for pm8916 - gpio1-gpio38 for pm8917 - gpio1-gpio44 for pm8921 - gpio1-gpio36 for pm8941 - gpio1-gpio8 for pm8950 (hole on gpio3) - gpio1-gpio22 for pm8994 - gpio1-gpio26 for pm8998 - gpio1-gpio22 for pma8084 - gpio1-gpio10 for pmc8180 - gpio1-gpio12 for pmc8180c - gpio1-gpio2 for pmi8950 - gpio1-gpio10 for pmi8994 - gpio1-gpio4 for pmk8350 - gpio1-gpio10 for pmm8155au - gpio1-gpio4 for pmr735a - gpio1-gpio4 for pmr735b - gpio1-gpio12 for pms405 (holes on gpio1, gpio9 and gpio10) - gpio1-gpio11 for pmx55 (holes on gpio3, gpio7, gpio10 - and gpio11) - -- function: - Usage: required - Value type: - Definition: Specify the alternative function to be configured for the - specified pins. Valid values are: - "normal", - "paired", - "func1", - "func2", - "dtest1", - "dtest2", - "dtest3", - "dtest4", - And following values are supported by LV/MV GPIO subtypes: - "func3", - "func4" - -- bias-disable: - Usage: optional - Value type: - Definition: The specified pins should be configured as no pull. - -- bias-pull-down: - Usage: optional - Value type: - Definition: The specified pins should be configured as pull down. - -- bias-pull-up: - Usage: optional - Value type: - Definition: The specified pins should be configured as pull up. - -- qcom,pull-up-strength: - Usage: optional - Value type: - Definition: Specifies the strength to use for pull up, if selected. - Valid values are; as defined in - : - 1: 30uA (PMIC_GPIO_PULL_UP_30) - 2: 1.5uA (PMIC_GPIO_PULL_UP_1P5) - 3: 31.5uA (PMIC_GPIO_PULL_UP_31P5) - 4: 1.5uA + 30uA boost (PMIC_GPIO_PULL_UP_1P5_30) - If this property is omitted 30uA strength will be used if - pull up is selected - -- bias-high-impedance: - Usage: optional - Value type: - Definition: The specified pins will put in high-Z mode and disabled. - -- input-enable: - Usage: optional - Value type: - Definition: The specified pins are put in input mode. - -- output-high: - Usage: optional - Value type: - Definition: The specified pins are configured in output mode, driven - high. - -- output-low: - Usage: optional - Value type: - Definition: The specified pins are configured in output mode, driven - low. - -- power-source: - Usage: optional - Value type: - Definition: Selects the power source for the specified pins. Valid - power sources are defined per chip in - - -- qcom,drive-strength: - Usage: optional - Value type: - Definition: Selects the drive strength for the specified pins. Value - drive strengths are: - 0: no (PMIC_GPIO_STRENGTH_NO) - 1: high (PMIC_GPIO_STRENGTH_HIGH) 0.9mA @ 1.8V - 1.9mA @ 2.6V - 2: medium (PMIC_GPIO_STRENGTH_MED) 0.6mA @ 1.8V - 1.25mA @ 2.6V - 3: low (PMIC_GPIO_STRENGTH_LOW) 0.15mA @ 1.8V - 0.3mA @ 2.6V - as defined in - -- drive-push-pull: - Usage: optional - Value type: - Definition: The specified pins are configured in push-pull mode. - -- drive-open-drain: - Usage: optional - Value type: - Definition: The specified pins are configured in open-drain mode. - -- drive-open-source: - Usage: optional - Value type: - Definition: The specified pins are configured in open-source mode. - -- qcom,analog-pass: - Usage: optional - Value type: - Definition: The specified pins are configured in analog-pass-through mode. - -- qcom,atest: - Usage: optional - Value type: - Definition: Selects ATEST rail to route to GPIO when it's configured - in analog-pass-through mode. - Valid values are 1-4 corresponding to ATEST1 to ATEST4. - -- qcom,dtest-buffer: - Usage: optional - Value type: - Definition: Selects DTEST rail to route to GPIO when it's configured - as digital input. - Valid values are 1-4 corresponding to DTEST1 to DTEST4. - -Example: - - pm8921_gpio: gpio@150 { - compatible = "qcom,pm8921-gpio", "qcom,ssbi-gpio"; - reg = <0x150 0x160>; - interrupts = <192 1>, <193 1>, <194 1>, - <195 1>, <196 1>, <197 1>, - <198 1>, <199 1>, <200 1>, - <201 1>, <202 1>, <203 1>, - <204 1>, <205 1>, <206 1>, - <207 1>, <208 1>, <209 1>, - <210 1>, <211 1>, <212 1>, - <213 1>, <214 1>, <215 1>, - <216 1>, <217 1>, <218 1>, - <219 1>, <220 1>, <221 1>, - <222 1>, <223 1>, <224 1>, - <225 1>, <226 1>, <227 1>, - <228 1>, <229 1>, <230 1>, - <231 1>, <232 1>, <233 1>, - <234 1>, <235 1>; - - gpio-controller; - #gpio-cells = <2>; - - pm8921_gpio_keys: gpio-keys { - volume-keys { - pins = "gpio20", "gpio21"; - function = "normal"; - - input-enable; - bias-pull-up; - drive-push-pull; - qcom,drive-strength = ; - power-source = ; - }; - }; - }; diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.yaml new file mode 100644 index 000000000000..7a0d2d8e1c86 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.yaml @@ -0,0 +1,259 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pinctrl/qcom,pmic-gpio.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm PMIC GPIO block + +maintainers: + - Bjorn Andersson + +description: + This binding describes the GPIO block(s) found in the 8xxx series of + PMIC's from Qualcomm. + +properties: + compatible: + items: + - enum: + - qcom,pm660-gpio + - qcom,pm660l-gpio + - qcom,pm6150-gpio + - qcom,pm6150l-gpio + - qcom,pm7325-gpio + - qcom,pm8005-gpio + - qcom,pm8008-gpio + - qcom,pm8018-gpio + - qcom,pm8038-gpio + - qcom,pm8058-gpio + - qcom,pm8150-gpio + - qcom,pm8150b-gpio + - qcom,pm8350-gpio + - qcom,pm8350b-gpio + - qcom,pm8350c-gpio + - qcom,pm8916-gpio + - qcom,pm8917-gpio + - qcom,pm8921-gpio + - qcom,pm8941-gpio + - qcom,pm8950-gpio + - qcom,pm8994-gpio + - qcom,pm8998-gpio + - qcom,pma8084-gpio + - qcom,pmi8950-gpio + - qcom,pmi8994-gpio + - qcom,pmi8998-gpio + - qcom,pmk8350-gpio + - qcom,pmr735a-gpio + - qcom,pmr735b-gpio + - qcom,pms405-gpio + - qcom,pmx55-gpio + + - enum: + - qcom,spmi-gpio + - qcom,ssbi-gpio + + reg: + maxItems: 1 + + interrupts: + minItems: 1 + maxItems: 44 + description: + Must contain an array of encoded interrupt specifiers for + each available GPIO + + '#interrupt-cells': + const: 2 + + interrupt-controller: true + + gpio-controller: true + + gpio-ranges: + maxItems: 1 + + '#gpio-cells': + const: 2 + description: + The first cell will be used to define gpio number and the + second denotes the flags for this gpio + +additionalProperties: false + +required: + - compatible + - reg + - gpio-controller + - '#gpio-cells' + - gpio-ranges + +patternProperties: + '-state$': + oneOf: + - $ref: "#/$defs/qcom-pmic-gpio-state" + - patternProperties: + ".*": + $ref: "#/$defs/qcom-pmic-gpio-state" + +$defs: + qcom-pmic-gpio-state: + type: object + allOf: + - $ref: "pinmux-node.yaml" + - $ref: "pincfg-node.yaml" + properties: + pins: + description: + List of gpio pins affected by the properties specified in + this subnode. Valid pins are + - gpio1-gpio10 for pm6150 + - gpio1-gpio12 for pm6150l + - gpio1-gpio10 for pm7325 + - gpio1-gpio4 for pm8005 + - gpio1-gpio2 for pm8008 + - gpio1-gpio6 for pm8018 + - gpio1-gpio12 for pm8038 + - gpio1-gpio40 for pm8058 + - gpio1-gpio10 for pm8150 (holes on gpio2, gpio5, + gpio7 and gpio8) + - gpio1-gpio12 for pm8150b (holes on gpio3, gpio4 + and gpio7) + - gpio1-gpio12 for pm8150l (hole on gpio7) + - gpio1-gpio4 for pm8916 + - gpio1-gpio10 for pm8350 + - gpio1-gpio8 for pm8350b + - gpio1-gpio9 for pm8350c + - gpio1-gpio38 for pm8917 + - gpio1-gpio44 for pm8921 + - gpio1-gpio36 for pm8941 + - gpio1-gpio8 for pm8950 (hole on gpio3) + - gpio1-gpio22 for pm8994 + - gpio1-gpio26 for pm8998 + - gpio1-gpio22 for pma8084 + - gpio1-gpio2 for pmi8950 + - gpio1-gpio10 for pmi8994 + - gpio1-gpio4 for pmk8350 + - gpio1-gpio4 for pmr735a + - gpio1-gpio4 for pmr735b + - gpio1-gpio12 for pms405 (holes on gpio1, gpio9 + and gpio10) + - gpio1-gpio11 for pmx55 (holes on gpio3, gpio7, gpio10 + and gpio11) + + items: + pattern: "^gpio([0-9]+)$" + + function: + items: + - enum: + - normal + - paired + - func1 + - func2 + - dtest1 + - dtest2 + - dtest3 + - dtest4 + - func3 # supported by LV/MV GPIO subtypes + - func4 # supported by LV/MV GPIO subtypes + + bias-disable: true + bias-pull-down: true + bias-pull-up: true + + qcom,pull-up-strength: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + Specifies the strength to use for pull up, if selected. + Valid values are defined in + + If this property is omitted 30uA strength will be used + if pull up is selected + enum: [0, 1, 2, 3] + + bias-high-impedance: true + input-enable: true + output-high: true + output-low: true + power-source: true + + qcom,drive-strength: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + Selects the drive strength for the specified pins + Valid drive strength values are defined in + + enum: [0, 1, 2, 3] + + drive-push-pull: true + drive-open-drain: true + drive-open-source: true + + qcom,analog-pass: + $ref: /schemas/types.yaml#/definitions/flag + description: + The specified pins are configured in + analog-pass-through mode. + + qcom,atest: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + Selects ATEST rail to route to GPIO when it's + configured in analog-pass-through mode. + enum: [1, 2, 3, 4] + + qcom,dtest-buffer: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + Selects DTEST rail to route to GPIO when it's + configured as digital input. + enum: [1, 2, 3, 4] + + required: + - pins + - function + + additionalProperties: false + +examples: + - | + #include + + pm8921_gpio: gpio@150 { + compatible = "qcom,pm8921-gpio", "qcom,ssbi-gpio"; + reg = <0x150 0x160>; + interrupts = <192 1>, <193 1>, <194 1>, + <195 1>, <196 1>, <197 1>, + <198 1>, <199 1>, <200 1>, + <201 1>, <202 1>, <203 1>, + <204 1>, <205 1>, <206 1>, + <207 1>, <208 1>, <209 1>, + <210 1>, <211 1>, <212 1>, + <213 1>, <214 1>, <215 1>, + <216 1>, <217 1>, <218 1>, + <219 1>, <220 1>, <221 1>, + <222 1>, <223 1>, <224 1>, + <225 1>, <226 1>, <227 1>, + <228 1>, <229 1>, <230 1>, + <231 1>, <232 1>, <233 1>, + <234 1>, <235 1>; + + gpio-controller; + gpio-ranges = <&pm8921_gpio 0 0 44>; + #gpio-cells = <2>; + + pm8921_gpio_keys: gpio-keys-state { + volume-keys { + pins = "gpio20", "gpio21"; + function = "normal"; + + input-enable; + bias-pull-up; + drive-push-pull; + qcom,drive-strength = ; + power-source = ; + }; + }; + }; +... -- cgit v1.2.3 From f03f5c75f5dddda2a615a9640f4385138e0ba43b Mon Sep 17 00:00:00 2001 From: satya priya Date: Mon, 2 Aug 2021 18:51:04 +0530 Subject: dt-bindings: pinctrl: qcom-pmic-gpio: Remove the interrupts property Remove the interrupts property as we no longer specify it. Signed-off-by: satya priya Acked-by: Rob Herring Reviewed-by: Bjorn Andersson Link: https://lore.kernel.org/r/1627910464-19363-4-git-send-email-skakit@codeaurora.org Signed-off-by: Linus Walleij --- .../bindings/pinctrl/qcom,pmic-gpio.yaml | 28 ++++------------------ 1 file changed, 4 insertions(+), 24 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.yaml index 7a0d2d8e1c86..9bd01db37dcd 100644 --- a/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.yaml +++ b/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.yaml @@ -56,18 +56,11 @@ properties: reg: maxItems: 1 - interrupts: - minItems: 1 - maxItems: 44 - description: - Must contain an array of encoded interrupt specifiers for - each available GPIO + interrupt-controller: true '#interrupt-cells': const: 2 - interrupt-controller: true - gpio-controller: true gpio-ranges: @@ -87,6 +80,7 @@ required: - gpio-controller - '#gpio-cells' - gpio-ranges + - interrupt-controller patternProperties: '-state$': @@ -223,22 +217,8 @@ examples: pm8921_gpio: gpio@150 { compatible = "qcom,pm8921-gpio", "qcom,ssbi-gpio"; reg = <0x150 0x160>; - interrupts = <192 1>, <193 1>, <194 1>, - <195 1>, <196 1>, <197 1>, - <198 1>, <199 1>, <200 1>, - <201 1>, <202 1>, <203 1>, - <204 1>, <205 1>, <206 1>, - <207 1>, <208 1>, <209 1>, - <210 1>, <211 1>, <212 1>, - <213 1>, <214 1>, <215 1>, - <216 1>, <217 1>, <218 1>, - <219 1>, <220 1>, <221 1>, - <222 1>, <223 1>, <224 1>, - <225 1>, <226 1>, <227 1>, - <228 1>, <229 1>, <230 1>, - <231 1>, <232 1>, <233 1>, - <234 1>, <235 1>; - + interrupt-controller; + #interrupt-cells = <2>; gpio-controller; gpio-ranges = <&pm8921_gpio 0 0 44>; #gpio-cells = <2>; -- cgit v1.2.3 From d2083893e4ade786498ba7f5f6ab77913c67ab83 Mon Sep 17 00:00:00 2001 From: Lakshmi Sowjanya D Date: Fri, 6 Aug 2021 19:55:26 +0530 Subject: dt-bindings: pinctrl: Add bindings for Intel Keembay pinctrl driver Add Device Tree bindings documentation for Intel Keem Bay SoC's pin controller. Add entry for INTEL Keem Bay pinctrl driver in MAINTAINERS file Co-developed-by: Vineetha G. Jaya Kumaran Signed-off-by: Vineetha G. Jaya Kumaran Co-developed-by: Vijayakannan Ayyathurai Signed-off-by: Vijayakannan Ayyathurai Signed-off-by: Lakshmi Sowjanya D Acked-by: Mark Gross Reviewed-by: Linus Walleij Link: https://lore.kernel.org/r/20210806142527.29113-2-lakshmi.sowjanya.d@intel.com Signed-off-by: Linus Walleij --- .../bindings/pinctrl/intel,pinctrl-keembay.yaml | 135 +++++++++++++++++++++ 1 file changed, 135 insertions(+) create mode 100644 Documentation/devicetree/bindings/pinctrl/intel,pinctrl-keembay.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pinctrl/intel,pinctrl-keembay.yaml b/Documentation/devicetree/bindings/pinctrl/intel,pinctrl-keembay.yaml new file mode 100644 index 000000000000..5e99d79499b4 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/intel,pinctrl-keembay.yaml @@ -0,0 +1,135 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pinctrl/intel,pinctrl-keembay.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Intel Keem Bay pin controller Device Tree Bindings + +maintainers: + - Lakshmi Sowjanya D + +description: | + Intel Keem Bay SoC integrates a pin controller which enables control + of pin directions, input/output values and configuration + for a total of 80 pins. + +properties: + compatible: + const: intel,keembay-pinctrl + + reg: + maxItems: 2 + + gpio-controller: true + + '#gpio-cells': + const: 2 + + ngpios: + description: The number of GPIOs exposed. + const: 80 + + interrupts: + description: + Specifies the interrupt lines to be used by the controller. + Each interrupt line is shared by upto 4 GPIO lines. + maxItems: 8 + + interrupt-controller: true + + '#interrupt-cells': + const: 2 + +patternProperties: + '^gpio@[0-9a-f]*$': + type: object + + description: + Child nodes can be specified to contain pin configuration information, + which can then be utilized by pinctrl client devices. + The following properties are supported. + + properties: + pins: + description: | + The name(s) of the pins to be configured in the child node. + Supported pin names are "GPIO0" up to "GPIO79". + + bias-disable: true + + bias-pull-down: true + + bias-pull-up: true + + drive-strength: + description: IO pads drive strength in milli Ampere. + enum: [2, 4, 8, 12] + + bias-bus-hold: + type: boolean + + input-schmitt-enable: + type: boolean + + slew-rate: + description: GPIO slew rate control. + 0 - Fast(~100MHz) + 1 - Slow(~50MHz) + enum: [0, 1] + +additionalProperties: false + +required: + - compatible + - reg + - gpio-controller + - ngpios + - '#gpio-cells' + - interrupts + - interrupt-controller + - '#interrupt-cells' + +examples: + - | + #include + #include + // Example 1 + gpio@0 { + compatible = "intel,keembay-pinctrl"; + reg = <0x600b0000 0x88>, + <0x600b0190 0x1ac>; + gpio-controller; + ngpios = <0x50>; + #gpio-cells = <0x2>; + interrupts = , + , + , + , + , + , + , + ; + interrupt-controller; + #interrupt-cells = <2>; + }; + + // Example 2 + gpio@1 { + compatible = "intel,keembay-pinctrl"; + reg = <0x600c0000 0x88>, + <0x600c0190 0x1ac>; + gpio-controller; + ngpios = <0x50>; + #gpio-cells = <0x2>; + interrupts = , + , + , + , + , + , + , + ; + interrupt-controller; + #interrupt-cells = <2>; + }; -- cgit v1.2.3 From ad19607a90b29eef044660aba92a2a2d63b1e977 Mon Sep 17 00:00:00 2001 From: Christian Brauner Date: Tue, 27 Jul 2021 12:44:16 +0200 Subject: doc: give a more thorough id handling explanation Currently there's no document explaining how idmappings work at all. Add a document that gives an introduction and also goes into a bit more detail for more advanced use-cases. Link: https://lore.kernel.org/r/20210727104416.828293-1-brauner@kernel.org Cc: Seth Forshee Cc: Christoph Hellwig Cc: Aleksa Sarai Cc: linux-fsdevel@vger.kernel.org Signed-off-by: Christian Brauner --- Documentation/filesystems/idmappings.rst | 1026 ++++++++++++++++++++++++++++++ Documentation/filesystems/index.rst | 1 + 2 files changed, 1027 insertions(+) create mode 100644 Documentation/filesystems/idmappings.rst (limited to 'Documentation') diff --git a/Documentation/filesystems/idmappings.rst b/Documentation/filesystems/idmappings.rst new file mode 100644 index 000000000000..1229a75ec75d --- /dev/null +++ b/Documentation/filesystems/idmappings.rst @@ -0,0 +1,1026 @@ +.. SPDX-License-Identifier: GPL-2.0 + +Idmappings +========== + +Most filesystem developers will have encountered idmappings. They are used when +reading from or writing ownership to disk, reporting ownership to userspace, or +for permission checking. This document is aimed at filesystem developers that +want to know how idmappings work. + +Formal notes +------------ + +An idmapping is essentially a translation of a range of ids into another or the +same range of ids. The notational convention for idmappings that is widely used +in userspace is:: + + u:k:r + +``u`` indicates the first element in the upper idmapset ``U`` and ``k`` +indicates the first element in the lower idmapset ``K``. The ``r`` parameter +indicates the range of the idmapping, i.e. how many ids are mapped. From now +on, we will always prefix ids with ``u`` or ``k`` to make it clear whether +we're talking about an id in the upper or lower idmapset. + +To see what this looks like in practice, let's take the following idmapping:: + + u22:k10000:r3 + +and write down the mappings it will generate:: + + u22 -> k10000 + u23 -> k10001 + u24 -> k10002 + +From a mathematical viewpoint ``U`` and ``K`` are well-ordered sets and an +idmapping is an order isomorphism from ``U`` into ``K``. So ``U`` and ``K`` are +order isomorphic. In fact, ``U`` and ``K`` are always well-ordered subsets of +the set of all possible ids useable on a given system. + +Looking at this mathematically briefly will help us highlight some properties +that make it easier to understand how we can translate between idmappings. For +example, we know that the inverse idmapping is an order isomorphism as well:: + + k10000 -> u22 + k10001 -> u23 + k10002 -> u24 + +Given that we are dealing with order isomorphisms plus the fact that we're +dealing with subsets we can embedd idmappings into each other, i.e. we can +sensibly translate between different idmappings. For example, assume we've been +given the three idmappings:: + + 1. u0:k10000:r10000 + 2. u0:k20000:r10000 + 3. u0:k30000:r10000 + +and id ``k11000`` which has been generated by the first idmapping by mapping +``u1000`` from the upper idmapset down to ``k11000`` in the lower idmapset. + +Because we're dealing with order isomorphic subsets it is meaningful to ask +what id ``k11000`` corresponds to in the second or third idmapping. The +straightfoward algorithm to use is to apply the inverse of the first idmapping, +mapping ``k11000`` up to ``u1000``. Afterwards, we can map ``u1000`` down using +either the second idmapping mapping or third idmapping mapping. The second +idmapping would map ``u1000`` down to ``21000``. The third idmapping would map +``u1000`` down to ``u31000``. + +If we were given the same task for the following three idmappings:: + + 1. u0:k10000:r10000 + 2. u0:k20000:r200 + 3. u0:k30000:r300 + +we would fail to translate as the sets aren't order isomorphic over the full +range of the first idmapping anymore (However they are order isomorphic over +the full range of the second idmapping.). Neither the second or third idmapping +contain ``u1000`` in the upper idmapset ``U``. This is equivalent to not having +an id mapped. We can simply say that ``u1000`` is unmapped in the second and +third idmapping. The kernel will report unmapped ids as the overflowuid +``(uid_t)-1`` or overflowgid ``(gid_t)-1`` to userspace. + +The algorithm to calculate what a given id maps to is pretty simple. First, we +need to verify that the range can contain our target id. We will skip this step +for simplicity. After that if we want to know what ``id`` maps to we can do +simple calculations: + +- If we want to map from left to right:: + + u:k:r + id - u + k = n + +- If we want to map from right to left:: + + u:k:r + id - k + u = n + +Instead of "left to right" we can also say "down" and instead of "right to +left" we can also say "up". Obviously mapping down and up invert each other. + +To see whether the simple formulas above work, consider the following two +idmappings:: + + 1. u0:k20000:r10000 + 2. u500:k30000:r10000 + +Assume we are given ``k21000`` in the lower idmapset of the first idmapping. We +want to know what id this was mapped from in the upper idmapset of the first +idmapping. So we're mapping up in the first idmapping:: + + id - k + u = n + k21000 - k20000 + u0 = u1000 + +Now assume we are given the id ``u1100`` in the upper idmapset of the second +idmapping and we want to know what this id maps down to in the lower idmapset +of the second idmapping. This means we're mapping down in the second +idmapping:: + + id - u + k = n + u1100 - u500 + k30000 = k30600 + +General notes +------------- + +In the context of the kernel an idmapping can be interpreted as mapping a range +of userspace ids into a range of kernel ids:: + + userspace-id:kernel-id:range + +A userspace id is always an element in the upper idmapset of an idmapping of +type ``uid_t`` or ``gid_t`` and a kernel id is always an element in the lower +idmapset of an idmapping of type ``kuid_t`` or ``kgid_t``. From now on +"userspace id" will be used to refer to the well known ``uid_t`` and ``gid_t`` +types and "kernel id" will be used to refer to ``kuid_t`` and ``kgid_t``. + +The kernel is mostly concerned with kernel ids. They are used when performing +permission checks and are stored in an inode's ``i_uid`` and ``i_gid`` field. +A userspace id on the other hand is an id that is reported to userspace by the +kernel, or is passed by userspace to the kernel, or a raw device id that is +written or read from disk. + +Note that we are only concerned with idmappings as the kernel stores them not +how userspace would specify them. + +For the rest of this document we will prefix all userspace ids with ``u`` and +all kernel ids with ``k``. Ranges of idmappings will be prefixed with ``r``. So +an idmapping will be written as ``u0:k10000:r10000``. + +For example, the id ``u1000`` is an id in the upper idmapset or "userspace +idmapset" starting with ``u1000``. And it is mapped to ``k11000`` which is a +kernel id in the lower idmapset or "kernel idmapset" starting with ``k10000``. + +A kernel id is always created by an idmapping. Such idmappings are associated +with user namespaces. Since we mainly care about how idmappings work we're not +going to be concerned with how idmappings are created nor how they are used +outside of the filesystem context. This is best left to an explanation of user +namespaces. + +The initial user namespace is special. It always has an idmapping of the +following form:: + + u0:k0:r4294967295 + +which is an identity idmapping over the full range of ids available on this +system. + +Other user namespaces usually have non-identity idmappings such as:: + + u0:k10000:r10000 + +When a process creates or wants to change ownership of a file, or when the +ownership of a file is read from disk by a filesystem, the userspace id is +immediately translated into a kernel id according to the idmapping associated +with the relevant user namespace. + +For instance, consider a file that is stored on disk by a filesystem as being +owned by ``u1000``: + +- If a filesystem were to be mounted in the initial user namespaces (as most + filesystems are) then the initial idmapping will be used. As we saw this is + simply the identity idmapping. This would mean id ``u1000`` read from disk + would be mapped to id ``k1000``. So an inode's ``i_uid`` and ``i_gid`` field + would contain ``k1000``. + +- If a filesystem were to be mounted with an idmapping of ``u0:k10000:r10000`` + then ``u1000`` read from disk would be mapped to ``k11000``. So an inode's + ``i_uid`` and ``i_gid`` would contain ``k11000``. + +Translation algorithms +---------------------- + +We've already seen briefly that it is possible to translate between different +idmappings. We'll now take a closer look how that works. + +Crossmapping +~~~~~~~~~~~~ + +This translation algorithm is used by the kernel in quite a few places. For +example, it is used when reporting back the ownership of a file to userspace +via the ``stat()`` system call family. + +If we've been given ``k11000`` from one idmapping we can map that id up in +another idmapping. In order for this to work both idmappings need to contain +the same kernel id in their kernel idmapsets. For example, consider the +following idmappings:: + + 1. u0:k10000:r10000 + 2. u20000:k10000:r10000 + +and we are mapping ``u1000`` down to ``k11000`` in the first idmapping . We can +then translate ``k11000`` into a userspace id in the second idmapping using the +kernel idmapset of the second idmapping:: + + /* Map the kernel id up into a userspace id in the second idmapping. */ + from_kuid(u20000:k10000:r10000, k11000) = u21000 + +Note, how we can get back to the kernel id in the first idmapping by inverting +the algorithm:: + + /* Map the userspace id down into a kernel id in the second idmapping. */ + make_kuid(u20000:k10000:r10000, u21000) = k11000 + + /* Map the kernel id up into a userspace id in the first idmapping. */ + from_kuid(u0:k10000:r10000, k11000) = u1000 + +This algorithm allows us to answer the question what userspace id a given +kernel id corresponds to in a given idmapping. In order to be able to answer +this question both idmappings need to contain the same kernel id in their +respective kernel idmapsets. + +For example, when the kernel reads a raw userspace id from disk it maps it down +into a kernel id according to the idmapping associated with the filesystem. +Let's assume the filesystem was mounted with an idmapping of +``u0:k20000:r10000`` and it reads a file owned by ``u1000`` from disk. This +means ``u1000`` will be mapped to ``k21000`` which is what will be stored in +the inode's ``i_uid`` and ``i_gid`` field. + +When someone in userspace calls ``stat()`` or a related function to get +ownership information about the file the kernel can't simply map the id back up +according to the filesystem's idmapping as this would give the wrong owner if +the caller is using an idmapping. + +So the kernel will map the id back up in the idmapping of the caller. Let's +assume the caller has the slighly unconventional idmapping +``u3000:k20000:r10000`` then ``k21000`` would map back up to ``u4000``. +Consequently the user would see that this file is owned by ``u4000``. + +Remapping +~~~~~~~~~ + +It is possible to translate a kernel id from one idmapping to another one via +the userspace idmapset of the two idmappings. This is equivalent to remapping +a kernel id. + +Let's look at an example. We are given the following two idmappings:: + + 1. u0:k10000:r10000 + 2. u0:k20000:r10000 + +and we are given ``k11000`` in the first idmapping. In order to translate this +kernel id in the first idmapping into a kernel id in the second idmapping we +need to perform two steps: + +1. Map the kernel id up into a userspace id in the first idmapping:: + + /* Map the kernel id up into a userspace id in the first idmapping. */ + from_kuid(u0:k10000:r10000, k11000) = u1000 + +2. Map the userspace id down into a kernel id in the second idmapping:: + + /* Map the userspace id down into a kernel id in the second idmapping. */ + make_kuid(u0:k20000:r10000, u1000) = k21000 + +As you can see we used the userspace idmapset in both idmappings to translate +the kernel id in one idmapping to a kernel id in another idmapping. + +This allows us to answer the question what kernel id we would need to use to +get the same userspace id in another idmapping. In order to be able to answer +this question both idmappings need to contain the same userspace id in their +respective userspace idmapsets. + +Note, how we can easily get back to the kernel id in the first idmapping by +inverting the algorithm: + +1. Map the kernel id up into a userspace id in the second idmapping:: + + /* Map the kernel id up into a userspace id in the second idmapping. */ + from_kuid(u0:k20000:r10000, k21000) = u1000 + +2. Map the userspace id down into a kernel id in the first idmapping:: + + /* Map the userspace id down into a kernel id in the first idmapping. */ + make_kuid(u0:k10000:r10000, u1000) = k11000 + +Another way to look at this translation is to treat it as inverting one +idmapping and applying another idmapping if both idmappings have the relevant +userspace id mapped. This will come in handy when working with idmapped mounts. + +Invalid translations +~~~~~~~~~~~~~~~~~~~~ + +It is never valid to use an id in the kernel idmapset of one idmapping as the +id in the userspace idmapset of another or the same idmapping. While the kernel +idmapset always indicates an idmapset in the kernel id space the userspace +idmapset indicates a userspace id. So the following translations are forbidden:: + + /* Map the userspace id down into a kernel id in the first idmapping. */ + make_kuid(u0:k10000:r10000, u1000) = k11000 + + /* INVALID: Map the kernel id down into a kernel id in the second idmapping. */ + make_kuid(u10000:k20000:r10000, k110000) = k21000 + ~~~~~~~ + +and equally wrong:: + + /* Map the kernel id up into a userspace id in the first idmapping. */ + from_kuid(u0:k10000:r10000, k11000) = u1000 + + /* INVALID: Map the userspace id up into a userspace id in the second idmapping. */ + from_kuid(u20000:k0:r10000, u1000) = k21000 + ~~~~~ + +Idmappings when creating filesystem objects +------------------------------------------- + +The concepts of mapping an id down or mapping an id up are expressed in the two +kernel functions filesystem developers are rather familiar with and which we've +already used in this document:: + + /* Map the userspace id down into a kernel id. */ + make_kuid(idmapping, uid) + + /* Map the kernel id up into a userspace id. */ + from_kuid(idmapping, kuid) + +We will take an abbreviated look into how idmappings figure into creating +filesystem objects. For simplicity we will only look at what happens when the +VFS has already completed path lookup right before it calls into the filesystem +itself. So we're concerned with what happens when e.g. ``vfs_mkdir()`` is +called. We will also assume that the directory we're creating filesystem +objects in is readable and writable for everyone. + +When creating a filesystem object the caller will look at the caller's +filesystem ids. These are just regular ``uid_t`` and ``gid_t`` userspace ids +but they are exclusively used when determining file ownership which is why they +are called "filesystem ids". They are usually identical to the uid and gid of +the caller but can differ. We will just assume they are always identical to not +get lost in too many details. + +When the caller enters the kernel two things happen: + +1. Map the caller's userspace ids down into kernel ids in the caller's + idmapping. + (To be precise, the kernel will simply look at the kernel ids stashed in the + credentials of the current task but for our education we'll pretend this + translation happens just in time.) +2. Verify that the caller's kernel ids can be mapped up to userspace ids in the + filesystem's idmapping. + +The second step is important as regular filesystem will ultimately need to map +the kernel id back up into a userspace id when writing to disk. +So with the second step the kernel guarantees that a valid userspace id can be +written to disk. If it can't the kernel will refuse the creation request to not +even remotely risk filesystem corruption. + +The astute reader will have realized that this is simply a varation of the +crossmapping algorithm we mentioned above in a previous section. First, the +kernel maps the caller's userspace id down into a kernel id according to the +caller's idmapping and then maps that kernel id up according to the +filesystem's idmapping. + +Example 1 +~~~~~~~~~ + +:: + + caller id: u1000 + caller idmapping: u0:k0:r4294967295 + filesystem idmapping: u0:k0:r4294967295 + +Both the caller and the filesystem use the identity idmapping: + +1. Map the caller's userspace ids into kernel ids in the caller's idmapping:: + + make_kuid(u0:k0:r4294967295, u1000) = k1000 + +2. Verify that the caller's kernel ids can be mapped to userspace ids in the + filesystem's idmapping. + + For this second step the kernel will call the function + ``fsuidgid_has_mapping()`` which ultimately boils down to calling + ``from_kuid()``:: + + from_kuid(u0:k0:r4294967295, k1000) = u1000 + +In this example both idmappings are the same so there's nothing exciting going +on. Ultimately the userspace id that lands on disk will be ``u1000``. + +Example 2 +~~~~~~~~~ + +:: + + caller id: u1000 + caller idmapping: u0:k10000:r10000 + filesystem idmapping: u0:k20000:r10000 + +1. Map the caller's userspace ids down into kernel ids in the caller's + idmapping:: + + make_kuid(u0:k10000:r10000, u1000) = k11000 + +2. Verify that the caller's kernel ids can be mapped up to userspace ids in the + filesystem's idmapping:: + + from_kuid(u0:k20000:r10000, k11000) = u-1 + +It's immediately clear that while the caller's userspace id could be +successfully mapped down into kernel ids in the caller's idmapping the kernel +ids could not be mapped up according to the filesystem's idmapping. So the +kernel will deny this creation request. + +Note that while this example is less common, because most filesystem can't be +mounted with non-initial idmappings this is a general problem as we can see in +the next examples. + +Example 3 +~~~~~~~~~ + +:: + + caller id: u1000 + caller idmapping: u0:k10000:r10000 + filesystem idmapping: u0:k0:r4294967295 + +1. Map the caller's userspace ids down into kernel ids in the caller's + idmapping:: + + make_kuid(u0:k10000:r10000, u1000) = k11000 + +2. Verify that the caller's kernel ids can be mapped up to userspace ids in the + filesystem's idmapping:: + + from_kuid(u0:k0:r4294967295, k11000) = u11000 + +We can see that the translation always succeeds. The userspace id that the +filesystem will ultimately put to disk will always be identical to the value of +the kernel id that was created in the caller's idmapping. This has mainly two +consequences. + +First, that we can't allow a caller to ultimately write to disk with another +userspace id. We could only do this if we were to mount the whole fileystem +with the caller's or another idmapping. But that solution is limited to a few +filesystems and not very flexible. But this is a use-case that is pretty +important in containerized workloads. + +Second, the caller will usually not be able to create any files or access +directories that have stricter permissions because none of the filesystem's +kernel ids map up into valid userspace ids in the caller's idmapping + +1. Map raw userspace ids down to kernel ids in the filesystem's idmapping:: + + make_kuid(u0:k0:r4294967295, u1000) = k1000 + +2. Map kernel ids up to userspace ids in the caller's idmapping:: + + from_kuid(u0:k10000:r10000, k1000) = u-1 + +Example 4 +~~~~~~~~~ + +:: + + file id: u1000 + caller idmapping: u0:k10000:r10000 + filesystem idmapping: u0:k0:r4294967295 + +In order to report ownership to userspace the kernel uses the crossmapping +algorithm introduced in a previous section: + +1. Map the userspace id on disk down into a kernel id in the filesystem's + idmapping:: + + make_kuid(u0:k0:r4294967295, u1000) = k1000 + +2. Map the kernel id up into a userspace id in the caller's idmapping:: + + from_kuid(u0:k10000:r10000, k1000) = u-1 + +The crossmapping algorithm fails in this case because the kernel id in the +filesystem idmapping cannot be mapped up to a userspace id in the caller's +idmapping. Thus, the kernel will report the ownership of this file as the +overflowid. + +Example 5 +~~~~~~~~~ + +:: + + file id: u1000 + caller idmapping: u0:k10000:r10000 + filesystem idmapping: u0:k20000:r10000 + +In order to report ownership to userspace the kernel uses the crossmapping +algorithm introduced in a previous section: + +1. Map the userspace id on disk down into a kernel id in the filesystem's + idmapping:: + + make_kuid(u0:k20000:r10000, u1000) = k21000 + +2. Map the kernel id up into a userspace id in the caller's idmapping:: + + from_kuid(u0:k10000:r10000, k21000) = u-1 + +Again, the crossmapping algorithm fails in this case because the kernel id in +the filesystem idmapping cannot be mapped to a userspace id in the caller's +idmapping. Thus, the kernel will report the ownership of this file as the +overflowid. + +Note how in the last two examples things would be simple if the caller would be +using the initial idmapping. For a filesystem mounted with the initial +idmapping it would be trivial. So we only consider a filesystem with an +idmapping of ``u0:k20000:r10000``: + +1. Map the userspace id on disk down into a kernel id in the filesystem's + idmapping:: + + make_kuid(u0:k20000:r10000, u1000) = k21000 + +2. Map the kernel id up into a userspace id in the caller's idmapping:: + + from_kuid(u0:k0:r4294967295, k21000) = u21000 + +Idmappings on idmapped mounts +----------------------------- + +The examples we've seen in the previous section where the caller's idmapping +and the filesystem's idmapping are incompatible causes various issues for +workloads. For a more complex but common example, consider two containers +started on the host. To completely prevent the two containers from affecting +each other, an administrator may often use different non-overlapping idmappings +for the two containers:: + + container1 idmapping: u0:k10000:r10000 + container2 idmapping: u0:k20000:r10000 + filesystem idmapping: u0:k30000:r10000 + +An administrator wanting to provide easy read-write access to the following set +of files:: + + dir id: u0 + dir/file1 id: u1000 + dir/file2 id: u2000 + +to both containers currently can't. + +Of course the administrator has the option to recursively change ownership via +``chown()``. For example, they could change ownership so that ``dir`` and all +files below it can be crossmapped from the filesystem's into the container's +idmapping. Let's assume they change ownership so it is compatible with the +first container's idmapping:: + + dir id: u10000 + dir/file1 id: u11000 + dir/file2 id: u12000 + +This would still leave ``dir`` rather useless to the second container. In fact, +``dir`` and all files below it would continue to appear owned by the overflowid +for the second container. + +Or consider another increasingly popular example. Some service managers such as +systemd implement a concept called "portable home directories". A user may want +to use their home directories on different machines where they are assigned +different login userspace ids. Most users will have ``u1000`` as the login id +on their machine at home and all files in their home directory will usually be +owned by ``u1000``. At uni or at work they may have another login id such as +``u1125``. This makes it rather difficult to interact with their home directory +on their work machine. + +In both cases changing ownership recursively has grave implications. The most +obvious one is that ownership is changed globally and permanently. In the home +directory case this change in ownership would even need to happen everytime the +user switches from their home to their work machine. For really large sets of +files this becomes increasingly costly. + +If the user is lucky, they are dealing with a filesystem that is mountable +inside user namespaces. But this would also change ownership globally and the +change in ownership is tied to the lifetime of the filesystem mount, i.e. the +superblock. The only way to change ownership is to completely unmount the +filesystem and mount it again in another user namespace. This is usually +impossible because it would mean that all users currently accessing the +filesystem can't anymore. And it means that ``dir`` still can't be shared +between two containers with different idmappings. +But usually the user doesn't even have this option since most filesystems +aren't mountable inside containers. And not having them mountable might be +desirable as it doesn't require the filesystem to deal with malicious +filesystem images. + +But the usecases mentioned above and more can be handled by idmapped mounts. +They allow to expose the same set of dentries with different ownership at +different mounts. This is achieved by marking the mounts with a user namespace +through the ``mount_setattr()`` system call. The idmapping associated with it +is then used to translate from the caller's idmapping to the filesystem's +idmapping and vica versa using the remapping algorithm we introduced above. + +Idmapped mounts make it possible to change ownership in a temporary and +localized way. The ownership changes are restricted to a specific mount and the +ownership changes are tied to the lifetime of the mount. All other users and +locations where the filesystem is exposed are unaffected. + +Filesystems that support idmapped mounts don't have any real reason to support +being mountable inside user namespaces. A filesystem could be exposed +completely under an idmapped mount to get the same effect. This has the +advantage that filesystems can leave the creation of the superblock to +privileged users in the initial user namespace. + +However, it is perfectly possible to combine idmapped mounts with filesystems +mountable inside user namespaces. We will touch on this further below. + +Remapping helpers +~~~~~~~~~~~~~~~~~ + +Idmapping functions were added that translate between idmappings. They make use +of the remapping algorithm we've introduced earlier. We're going to look at +two: + +- ``i_uid_into_mnt()`` and ``i_gid_into_mnt()`` + + The ``i_*id_into_mnt()`` functions translate filesystem's kernel ids into + kernel ids in the mount's idmapping:: + + /* Map the filesystem's kernel id up into a userspace id in the filesystem's idmapping. */ + from_kuid(filesystem, kid) = uid + + /* Map the filesystem's userspace id down ito a kernel id in the mount's idmapping. */ + make_kuid(mount, uid) = kuid + +- ``mapped_fsuid()`` and ``mapped_fsgid()`` + + The ``mapped_fs*id()`` functions translate the caller's kernel ids into + kernel ids in the filesystem's idmapping. This translation is achieved by + remapping the caller's kernel ids using the mount's idmapping:: + + /* Map the caller's kernel id up into a userspace id in the mount's idmapping. */ + from_kuid(mount, kid) = uid + + /* Map the mount's userspace id down into a kernel id in the filesystem's idmapping. */ + make_kuid(filesystem, uid) = kuid + +Note that these two functions invert each other. Consider the following +idmappings:: + + caller idmapping: u0:k10000:r10000 + filesystem idmapping: u0:k20000:r10000 + mount idmapping: u0:k10000:r10000 + +Assume a file owned by ``u1000`` is read from disk. The filesystem maps this id +to ``k21000`` according to it's idmapping. This is what is stored in the +inode's ``i_uid`` and ``i_gid`` fields. + +When the caller queries the ownership of this file via ``stat()`` the kernel +would usually simply use the crossmapping algorithm and map the filesystem's +kernel id up to a userspace id in the caller's idmapping. + +But when the caller is accessing the file on an idmapped mount the kernel will +first call ``i_uid_into_mnt()`` thereby translating the filesystem's kernel id +into a kernel id in the mount's idmapping:: + + i_uid_into_mnt(k21000): + /* Map the filesystem's kernel id up into a userspace id. */ + from_kuid(u0:k20000:r10000, k21000) = u1000 + + /* Map the filesystem's userspace id down ito a kernel id in the mount's idmapping. */ + make_kuid(u0:k10000:r10000, u1000) = k11000 + +Finally, when the kernel reports the owner to the caller it will turn the +kernel id in the mount's idmapping into a userspace id in the caller's +idmapping:: + + from_kuid(u0:k10000:r10000, k11000) = u1000 + +We can test whether this algorithm really works by verifying what happens when +we create a new file. Let's say the user is creating a file with ``u1000``. + +The kernel maps this to ``k11000`` in the caller's idmapping. Usually the +kernel would now apply the crossmapping, verifying that ``k11000`` can be +mapped to a userspace id in the filesystem's idmapping. Since ``k11000`` can't +be mapped up in the filesystem's idmapping directly this creation request +fails. + +But when the caller is accessing the file on an idmapped mount the kernel will +first call ``mapped_fs*id()`` thereby translating the caller's kernel id into +a kernel id according to the mount's idmapping:: + + mapped_fsuid(k11000): + /* Map the caller's kernel id up into a userspace id in the mount's idmapping. */ + from_kuid(u0:k10000:r10000, k11000) = u1000 + + /* Map the mount's userspace id down into a kernel id in the filesystem's idmapping. */ + make_kuid(u0:k20000:r10000, u1000) = k21000 + +When finally writing to disk the kernel will then map ``k21000`` up into a +userspace id in the filesystem's idmapping:: + + from_kuid(u0:k20000:r10000, k21000) = u1000 + +As we can see, we end up with an invertible and therefore information +preserving algorithm. A file created from ``u1000`` on an idmapped mount will +also be reported as being owned by ``u1000`` and vica versa. + +Let's now briefly reconsider the failing examples from earlier in the context +of idmapped mounts. + +Example 2 reconsidered +~~~~~~~~~~~~~~~~~~~~~~ + +:: + + caller id: u1000 + caller idmapping: u0:k10000:r10000 + filesystem idmapping: u0:k20000:r10000 + mount idmapping: u0:k10000:r10000 + +When the caller is using a non-initial idmapping the common case is to attach +the same idmapping to the mount. We now perform three steps: + +1. Map the caller's userspace ids into kernel ids in the caller's idmapping:: + + make_kuid(u0:k10000:r10000, u1000) = k11000 + +2. Translate the caller's kernel id into a kernel id in the filesystem's + idmapping:: + + mapped_fsuid(k11000): + /* Map the kernel id up into a userspace id in the mount's idmapping. */ + from_kuid(u0:k10000:r10000, k11000) = u1000 + + /* Map the userspace id down into a kernel id in the filesystem's idmapping. */ + make_kuid(u0:k20000:r10000, u1000) = k21000 + +2. Verify that the caller's kernel ids can be mapped to userspace ids in the + filesystem's idmapping:: + + from_kuid(u0:k20000:r10000, k21000) = u1000 + +So the ownership that lands on disk will be ``u1000``. + +Example 3 reconsidered +~~~~~~~~~~~~~~~~~~~~~~ + +:: + + caller id: u1000 + caller idmapping: u0:k10000:r10000 + filesystem idmapping: u0:k0:r4294967295 + mount idmapping: u0:k10000:r10000 + +The same translation algorithm works with the third example. + +1. Map the caller's userspace ids into kernel ids in the caller's idmapping:: + + make_kuid(u0:k10000:r10000, u1000) = k11000 + +2. Translate the caller's kernel id into a kernel id in the filesystem's + idmapping:: + + mapped_fsuid(k11000): + /* Map the kernel id up into a userspace id in the mount's idmapping. */ + from_kuid(u0:k10000:r10000, k11000) = u1000 + + /* Map the userspace id down into a kernel id in the filesystem's idmapping. */ + make_kuid(u0:k0:r4294967295, u1000) = k1000 + +2. Verify that the caller's kernel ids can be mapped to userspace ids in the + filesystem's idmapping:: + + from_kuid(u0:k0:r4294967295, k21000) = u1000 + +So the ownership that lands on disk will be ``u1000``. + +Example 4 reconsidered +~~~~~~~~~~~~~~~~~~~~~~ + +:: + + file id: u1000 + caller idmapping: u0:k10000:r10000 + filesystem idmapping: u0:k0:r4294967295 + mount idmapping: u0:k10000:r10000 + +In order to report ownership to userspace the kernel now does three steps using +the translation algorithm we introduced earlier: + +1. Map the userspace id on disk down into a kernel id in the filesystem's + idmapping:: + + make_kuid(u0:k0:r4294967295, u1000) = k1000 + +2. Translate the kernel id into a kernel id in the mount's idmapping:: + + i_uid_into_mnt(k1000): + /* Map the kernel id up into a userspace id in the filesystem's idmapping. */ + from_kuid(u0:k0:r4294967295, k1000) = u1000 + + /* Map the userspace id down into a kernel id in the mounts's idmapping. */ + make_kuid(u0:k10000:r10000, u1000) = k11000 + +3. Map the kernel id up into a userspace id in the caller's idmapping:: + + from_kuid(u0:k10000:r10000, k11000) = u1000 + +Earlier, the caller's kernel id couldn't be crossmapped in the filesystems's +idmapping. With the idmapped mount in place it now can be crossmapped into the +filesystem's idmapping via the mount's idmapping. The file will now be created +with ``u1000`` according to the mount's idmapping. + +Example 5 reconsidered +~~~~~~~~~~~~~~~~~~~~~~ + +:: + + file id: u1000 + caller idmapping: u0:k10000:r10000 + filesystem idmapping: u0:k20000:r10000 + mount idmapping: u0:k10000:r10000 + +Again, in order to report ownership to userspace the kernel now does three +steps using the translation algorithm we introduced earlier: + +1. Map the userspace id on disk down into a kernel id in the filesystem's + idmapping:: + + make_kuid(u0:k20000:r10000, u1000) = k21000 + +2. Translate the kernel id into a kernel id in the mount's idmapping:: + + i_uid_into_mnt(k21000): + /* Map the kernel id up into a userspace id in the filesystem's idmapping. */ + from_kuid(u0:k20000:r10000, k21000) = u1000 + + /* Map the userspace id down into a kernel id in the mounts's idmapping. */ + make_kuid(u0:k10000:r10000, u1000) = k11000 + +3. Map the kernel id up into a userspace id in the caller's idmapping:: + + from_kuid(u0:k10000:r10000, k11000) = u1000 + +Earlier, the file's kernel id couldn't be crossmapped in the filesystems's +idmapping. With the idmapped mount in place it now can be crossmapped into the +filesystem's idmapping via the mount's idmapping. The file is now owned by +``u1000`` according to the mount's idmapping. + +Changing ownership on a home directory +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +We've seen above how idmapped mounts can be used to translate between +idmappings when either the caller, the filesystem or both uses a non-initial +idmapping. A wide range of usecases exist when the caller is using +a non-initial idmapping. This mostly happens in the context of containerized +workloads. The consequence is as we have seen that for both, filesystem's +mounted with the initial idmapping and filesystems mounted with non-initial +idmappings, access to the filesystem isn't working because the kernel ids can't +be crossmapped between the caller's and the filesystem's idmapping. + +As we've seen above idmapped mounts provide a solution to this by remapping the +caller's or filesystem's idmapping according to the mount's idmapping. + +Aside from containerized workloads, idmapped mounts have the advantage that +they also work when both the caller and the filesystem use the initial +idmapping which means users on the host can change the ownership of directories +and files on a per-mount basis. + +Consider our previous example where a user has their home directory on portable +storage. At home they have id ``u1000`` and all files in their home directory +are owned by ``u1000`` whereas at uni or work they have login id ``u1125``. + +Taking their home directory with them becomes problematic. They can't easily +access their files, they might not be able to write to disk without applying +lax permissions or ACLs and even if they can, they will end up with an annoying +mix of files and directories owned by ``u1000`` and ``u1125``. + +Idmapped mounts allow to solve this problem. A user can create an idmapped +mount for their home directory on their work computer or their computer at home +depending on what ownership they would prefer to end up on the portable storage +itself. + +Let's assume they want all files on disk to belong to ``u1000``. When the user +plugs in their portable storage at their work station they can setup a job that +creates an idmapped mount with the minimal idmapping ``u1000:k1125:r1``. So now +when they create a file the kernel performs the following steps we already know +from above::: + + caller id: u1125 + caller idmapping: u0:k0:r4294967295 + filesystem idmapping: u0:k0:r4294967295 + mount idmapping: u1000:k1125:r1 + +1. Map the caller's userspace ids into kernel ids in the caller's idmapping:: + + make_kuid(u0:k0:r4294967295, u1125) = k1125 + +2. Translate the caller's kernel id into a kernel id in the filesystem's + idmapping:: + + mapped_fsuid(k1125): + /* Map the kernel id up into a userspace id in the mount's idmapping. */ + from_kuid(u1000:k1125:r1, k1125) = u1000 + + /* Map the userspace id down into a kernel id in the filesystem's idmapping. */ + make_kuid(u0:k0:r4294967295, u1000) = k1000 + +2. Verify that the caller's kernel ids can be mapped to userspace ids in the + filesystem's idmapping:: + + from_kuid(u0:k0:r4294967295, k1000) = u1000 + +So ultimately the file will be created with ``u1000`` on disk. + +Now let's briefly look at what ownership the caller with id ``u1125`` will see +on their work computer: + +:: + + file id: u1000 + caller idmapping: u0:k0:r4294967295 + filesystem idmapping: u0:k0:r4294967295 + mount idmapping: u1000:k1125:r1 + +1. Map the userspace id on disk down into a kernel id in the filesystem's + idmapping:: + + make_kuid(u0:k0:r4294967295, u1000) = k1000 + +2. Translate the kernel id into a kernel id in the mount's idmapping:: + + i_uid_into_mnt(k1000): + /* Map the kernel id up into a userspace id in the filesystem's idmapping. */ + from_kuid(u0:k0:r4294967295, k1000) = u1000 + + /* Map the userspace id down into a kernel id in the mounts's idmapping. */ + make_kuid(u1000:k1125:r1, u1000) = k1125 + +3. Map the kernel id up into a userspace id in the caller's idmapping:: + + from_kuid(u0:k0:r4294967295, k1125) = u1125 + +So ultimately the caller will be reported that the file belongs to ``u1125`` +which is the caller's userspace id on their workstation in our example. + +The raw userspace id that is put on disk is ``u1000`` so when the user takes +their home directory back to their home computer where they are assigned +``u1000`` using the initial idmapping and mount the filesystem with the initial +idmapping they will see all those files owned by ``u1000``. + +Shortcircuting +-------------- + +Currently, the implementation of idmapped mounts enforces that the filesystem +is mounted with the initial idmapping. The reason is simply that none of the +filesystems that we targeted were mountable with a non-initial idmapping. But +that might change soon enough. As we've seen above, thanks to the properties of +idmappings the translation works for both filesystems mounted with the initial +idmapping and filesystem with non-initial idmappings. + +Based on this current restriction to filesystem mounted with the initial +idmapping two noticeable shortcuts have been taken: + +1. We always stash a reference to the initial user namespace in ``struct + vfsmount``. Idmapped mounts are thus mounts that have a non-initial user + namespace attached to them. + + In order to support idmapped mounts this needs to be changed. Instead of + stashing the initial user namespace the user namespace the filesystem was + mounted with must be stashed. An idmapped mount is then any mount that has + a different user namespace attached then the filesystem was mounted with. + This has no user-visible consequences. + +2. The translation algorithms in ``mapped_fs*id()`` and ``i_*id_into_mnt()`` + are simplified. + + Let's consider ``mapped_fs*id()`` first. This function translates the + caller's kernel id into a kernel id in the filesystem's idmapping via + a mount's idmapping. The full algorithm is:: + + mapped_fsuid(kid): + /* Map the kernel id up into a userspace id in the mount's idmapping. */ + from_kuid(mount-idmapping, kid) = uid + + /* Map the userspace id down into a kernel id in the filesystem's idmapping. */ + make_kuid(filesystem-idmapping, uid) = kuid + + We know that the filesystem is always mounted with the initial idmapping as + we enforce this in ``mount_setattr()``. So this can be shortened to:: + + mapped_fsuid(kid): + /* Map the kernel id up into a userspace id in the mount's idmapping. */ + from_kuid(mount-idmapping, kid) = uid + + /* Map the userspace id down into a kernel id in the filesystem's idmapping. */ + KUIDT_INIT(uid) = kuid + + Similarly, for ``i_*id_into_mnt()`` which translated the filesystem's kernel + id into a mount's kernel id:: + + i_uid_into_mnt(kid): + /* Map the kernel id up into a userspace id in the filesystem's idmapping. */ + from_kuid(filesystem-idmapping, kid) = uid + + /* Map the userspace id down into a kernel id in the mounts's idmapping. */ + make_kuid(mount-idmapping, uid) = kuid + + Again, we know that the filesystem is always mounted with the initial + idmapping as we enforce this in ``mount_setattr()``. So this can be + shortened to:: + + i_uid_into_mnt(kid): + /* Map the kernel id up into a userspace id in the filesystem's idmapping. */ + __kuid_val(kid) = uid + + /* Map the userspace id down into a kernel id in the mounts's idmapping. */ + make_kuid(mount-idmapping, uid) = kuid + +Handling filesystems mounted with non-initial idmappings requires that the +translation functions be converted to their full form. They can still be +shortcircuited on non-idmapped mounts. This has no user-visible consequences. diff --git a/Documentation/filesystems/index.rst b/Documentation/filesystems/index.rst index 246af51b277a..f97ea4b18523 100644 --- a/Documentation/filesystems/index.rst +++ b/Documentation/filesystems/index.rst @@ -34,6 +34,7 @@ algorithms work. quota seq_file sharedsubtree + idmappings automount-support -- cgit v1.2.3 From f13a5ad88186c142b4f6060fb06f0f8fb1674915 Mon Sep 17 00:00:00 2001 From: Parav Pandit Date: Tue, 10 Aug 2021 16:24:15 +0300 Subject: devlink: Add new "enable_eth" generic device param Add new device generic parameter to enable/disable creation of Ethernet auxiliary device and associated device functionality in the devlink instance. User who prefers to disable such functionality can disable it using below example. $ devlink dev param set pci/0000:06:00.0 \ name enable_eth value false cmode driverinit $ devlink dev reload pci/0000:06:00.0 At this point devlink instance do not create auxiliary device for the Ethernet functionality. Signed-off-by: Parav Pandit Reviewed-by: Jiri Pirko Reviewed-by: Leon Romanovsky Signed-off-by: David S. Miller --- Documentation/networking/devlink/devlink-params.rst | 4 ++++ 1 file changed, 4 insertions(+) (limited to 'Documentation') diff --git a/Documentation/networking/devlink/devlink-params.rst b/Documentation/networking/devlink/devlink-params.rst index 54c9f107c4b0..219c1272f2d6 100644 --- a/Documentation/networking/devlink/devlink-params.rst +++ b/Documentation/networking/devlink/devlink-params.rst @@ -97,6 +97,10 @@ own name. * - ``enable_roce`` - Boolean - Enable handling of RoCE traffic in the device. + * - ``enable_eth`` + - Boolean + - When enabled, the device driver will instantiate Ethernet specific + auxiliary device of the devlink device. * - ``internal_err_reset`` - Boolean - When enabled, the device driver will reset the device on internal -- cgit v1.2.3 From 8ddaabee3c7994854841a9b097fd94538126c12c Mon Sep 17 00:00:00 2001 From: Parav Pandit Date: Tue, 10 Aug 2021 16:24:16 +0300 Subject: devlink: Add new "enable_rdma" generic device param Add new device generic parameter to enable/disable creation of RDMA auxiliary device and associated device functionality in the devlink instance. User who prefers to disable such functionality can disable it using below example. $ devlink dev param set pci/0000:06:00.0 \ name enable_rdma value false cmode driverinit $ devlink dev reload pci/0000:06:00.0 At this point devlink instance do not create auxiliary device for the RDMA functionality. Signed-off-by: Parav Pandit Reviewed-by: Jiri Pirko Reviewed-by: Leon Romanovsky Signed-off-by: David S. Miller --- Documentation/networking/devlink/devlink-params.rst | 4 ++++ 1 file changed, 4 insertions(+) (limited to 'Documentation') diff --git a/Documentation/networking/devlink/devlink-params.rst b/Documentation/networking/devlink/devlink-params.rst index 219c1272f2d6..a49da0b049b6 100644 --- a/Documentation/networking/devlink/devlink-params.rst +++ b/Documentation/networking/devlink/devlink-params.rst @@ -101,6 +101,10 @@ own name. - Boolean - When enabled, the device driver will instantiate Ethernet specific auxiliary device of the devlink device. + * - ``enable_rdma`` + - Boolean + - When enabled, the device driver will instantiate RDMA specific + auxiliary device of the devlink device. * - ``internal_err_reset`` - Boolean - When enabled, the device driver will reset the device on internal -- cgit v1.2.3 From 076b2a9dbb28e8b3d9a264a8bca664794255d448 Mon Sep 17 00:00:00 2001 From: Parav Pandit Date: Tue, 10 Aug 2021 16:24:17 +0300 Subject: devlink: Add new "enable_vnet" generic device param Add new device generic parameter to enable/disable creation of VDPA net auxiliary device and associated device functionality in the devlink instance. User who prefers to disable such functionality can disable it using below example. $ devlink dev param set pci/0000:06:00.0 \ name enable_vnet value false cmode driverinit $ devlink dev reload pci/0000:06:00.0 At this point devlink instance do not create auxiliary device for the VDPA net functionality. Signed-off-by: Parav Pandit Reviewed-by: Jiri Pirko Reviewed-by: Leon Romanovsky Signed-off-by: David S. Miller --- Documentation/networking/devlink/devlink-params.rst | 4 ++++ 1 file changed, 4 insertions(+) (limited to 'Documentation') diff --git a/Documentation/networking/devlink/devlink-params.rst b/Documentation/networking/devlink/devlink-params.rst index a49da0b049b6..4878907e9232 100644 --- a/Documentation/networking/devlink/devlink-params.rst +++ b/Documentation/networking/devlink/devlink-params.rst @@ -105,6 +105,10 @@ own name. - Boolean - When enabled, the device driver will instantiate RDMA specific auxiliary device of the devlink device. + * - ``enable_vnet`` + - Boolean + - When enabled, the device driver will instantiate VDPA networking + specific auxiliary device of the devlink device. * - ``internal_err_reset`` - Boolean - When enabled, the device driver will reset the device on internal -- cgit v1.2.3 From ae03c3771b8cbbed3802ad1153d896c32015c520 Mon Sep 17 00:00:00 2001 From: Max Gurtovoy Date: Thu, 5 Aug 2021 22:18:59 -0300 Subject: vfio: Introduce a vfio_uninit_group_dev() API call This pairs with vfio_init_group_dev() and allows undoing any state that is stored in the vfio_device unrelated to registration. Add appropriately placed calls to all the drivers. The following patch will use this to add pre-registration state for the device set. Signed-off-by: Max Gurtovoy Reviewed-by: Cornelia Huck Reviewed-by: Christoph Hellwig Signed-off-by: Jason Gunthorpe Link: https://lore.kernel.org/r/3-v4-9ea22c5e6afb+1adf-vfio_reflck_jgg@nvidia.com Signed-off-by: Alex Williamson --- Documentation/driver-api/vfio.rst | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/driver-api/vfio.rst b/Documentation/driver-api/vfio.rst index 606eed8823ce..c663b6f97825 100644 --- a/Documentation/driver-api/vfio.rst +++ b/Documentation/driver-api/vfio.rst @@ -255,11 +255,13 @@ vfio_unregister_group_dev() respectively:: void vfio_init_group_dev(struct vfio_device *device, struct device *dev, const struct vfio_device_ops *ops); + void vfio_uninit_group_dev(struct vfio_device *device); int vfio_register_group_dev(struct vfio_device *device); void vfio_unregister_group_dev(struct vfio_device *device); The driver should embed the vfio_device in its own structure and call -vfio_init_group_dev() to pre-configure it before going to registration. +vfio_init_group_dev() to pre-configure it before going to registration +and call vfio_uninit_group_dev() after completing the un-registration. vfio_register_group_dev() indicates to the core to begin tracking the iommu_group of the specified dev and register the dev as owned by a VFIO bus driver. Once vfio_register_group_dev() returns it is possible for userspace to -- cgit v1.2.3 From ffd5caa26f6afde0c1e3ed126806607748a83c6e Mon Sep 17 00:00:00 2001 From: Daniel Vetter Date: Tue, 10 Aug 2021 16:27:48 +0200 Subject: drm/doc/rfc: drop lmem uapi section We still have quite a bit more work to do with overall reworking of the ttm-based dg1 code, but the uapi stuff is now finalized with the latest pull. So remove that. This also fixes kerneldoc build warnings because we've included the same headers in two places, resulting in sphinx complaining about duplicated symbols. This regression has been created when we moved the uapi definitions to the real include/uapi/ folder in 727ecd99a4c9 ("drm/doc/rfc: drop the i915_gem_lmem.h header") v2: Fix a few references that I missed, the htmldocs build took forever. Acked-by: Jason Ekstrand Acked-by: Maarten Lankhorst Tested-by Stephen Rothwell (v1) References: https://lore.kernel.org/dri-devel/20210603193242.1ce99344@canb.auug.org.au/ Reported-by: Stephen Rothwell Cc: Stephen Rothwell Fixes: 727ecd99a4c9 ("drm/doc/rfc: drop the i915_gem_lmem.h header") Cc: Matthew Auld Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20210810142748.1983271-1-daniel.vetter@ffwll.ch (cherry picked from commit dae2d28832968751f7731336b560a4a84a197b76) Signed-off-by: Rodrigo Vivi --- Documentation/gpu/rfc/i915_gem_lmem.rst | 109 -------------------------------- 1 file changed, 109 deletions(-) (limited to 'Documentation') diff --git a/Documentation/gpu/rfc/i915_gem_lmem.rst b/Documentation/gpu/rfc/i915_gem_lmem.rst index 675ba8620d66..b421a3c1806e 100644 --- a/Documentation/gpu/rfc/i915_gem_lmem.rst +++ b/Documentation/gpu/rfc/i915_gem_lmem.rst @@ -18,114 +18,5 @@ real, with all the uAPI bits is: * Route shmem backend over to TTM SYSTEM for discrete * TTM purgeable object support * Move i915 buddy allocator over to TTM - * MMAP ioctl mode(see `I915 MMAP`_) - * SET/GET ioctl caching(see `I915 SET/GET CACHING`_) * Send RFC(with mesa-dev on cc) for final sign off on the uAPI * Add pciid for DG1 and turn on uAPI for real - -New object placement and region query uAPI -========================================== -Starting from DG1 we need to give userspace the ability to allocate buffers from -device local-memory. Currently the driver supports gem_create, which can place -buffers in system memory via shmem, and the usual assortment of other -interfaces, like dumb buffers and userptr. - -To support this new capability, while also providing a uAPI which will work -beyond just DG1, we propose to offer three new bits of uAPI: - -DRM_I915_QUERY_MEMORY_REGIONS ------------------------------ -New query ID which allows userspace to discover the list of supported memory -regions(like system-memory and local-memory) for a given device. We identify -each region with a class and instance pair, which should be unique. The class -here would be DEVICE or SYSTEM, and the instance would be zero, on platforms -like DG1. - -Side note: The class/instance design is borrowed from our existing engine uAPI, -where we describe every physical engine in terms of its class, and the -particular instance, since we can have more than one per class. - -In the future we also want to expose more information which can further -describe the capabilities of a region. - -.. kernel-doc:: include/uapi/drm/i915_drm.h - :functions: drm_i915_gem_memory_class drm_i915_gem_memory_class_instance drm_i915_memory_region_info drm_i915_query_memory_regions - -GEM_CREATE_EXT --------------- -New ioctl which is basically just gem_create but now allows userspace to provide -a chain of possible extensions. Note that if we don't provide any extensions and -set flags=0 then we get the exact same behaviour as gem_create. - -Side note: We also need to support PXP[1] in the near future, which is also -applicable to integrated platforms, and adds its own gem_create_ext extension, -which basically lets userspace mark a buffer as "protected". - -.. kernel-doc:: include/uapi/drm/i915_drm.h - :functions: drm_i915_gem_create_ext - -I915_GEM_CREATE_EXT_MEMORY_REGIONS ----------------------------------- -Implemented as an extension for gem_create_ext, we would now allow userspace to -optionally provide an immutable list of preferred placements at creation time, -in priority order, for a given buffer object. For the placements we expect -them each to use the class/instance encoding, as per the output of the regions -query. Having the list in priority order will be useful in the future when -placing an object, say during eviction. - -.. kernel-doc:: include/uapi/drm/i915_drm.h - :functions: drm_i915_gem_create_ext_memory_regions - -One fair criticism here is that this seems a little over-engineered[2]. If we -just consider DG1 then yes, a simple gem_create.flags or something is totally -all that's needed to tell the kernel to allocate the buffer in local-memory or -whatever. However looking to the future we need uAPI which can also support -upcoming Xe HP multi-tile architecture in a sane way, where there can be -multiple local-memory instances for a given device, and so using both class and -instance in our uAPI to describe regions is desirable, although specifically -for DG1 it's uninteresting, since we only have a single local-memory instance. - -Existing uAPI issues -==================== -Some potential issues we still need to resolve. - -I915 MMAP ---------- -In i915 there are multiple ways to MMAP GEM object, including mapping the same -object using different mapping types(WC vs WB), i.e multiple active mmaps per -object. TTM expects one MMAP at most for the lifetime of the object. If it -turns out that we have to backpedal here, there might be some potential -userspace fallout. - -I915 SET/GET CACHING --------------------- -In i915 we have set/get_caching ioctl. TTM doesn't let us to change this, but -DG1 doesn't support non-snooped pcie transactions, so we can just always -allocate as WB for smem-only buffers. If/when our hw gains support for -non-snooped pcie transactions then we must fix this mode at allocation time as -a new GEM extension. - -This is related to the mmap problem, because in general (meaning, when we're -not running on intel cpus) the cpu mmap must not, ever, be inconsistent with -allocation mode. - -Possible idea is to let the kernel picks the mmap mode for userspace from the -following table: - -smem-only: WB. Userspace does not need to call clflush. - -smem+lmem: We only ever allow a single mode, so simply allocate this as uncached -memory, and always give userspace a WC mapping. GPU still does snooped access -here(assuming we can't turn it off like on DG1), which is a bit inefficient. - -lmem only: always WC - -This means on discrete you only get a single mmap mode, all others must be -rejected. That's probably going to be a new default mode or something like -that. - -Links -===== -[1] https://patchwork.freedesktop.org/series/86798/ - -[2] https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5599#note_553791 -- cgit v1.2.3 From 162a5284faf41b2441b8f686f9ac4771c7a8f669 Mon Sep 17 00:00:00 2001 From: Paul Gortmaker Date: Sun, 30 May 2021 12:24:45 -0400 Subject: x86/reboot: Document the "reboot=pci" option It is mentioned in the top level non-arch specific file but it was overlooked here for x86. Signed-off-by: Paul Gortmaker Signed-off-by: Thomas Gleixner Link: https://lore.kernel.org/r/20210530162447.996461-2-paul.gortmaker@windriver.com --- Documentation/x86/x86_64/boot-options.rst | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/x86/x86_64/boot-options.rst b/Documentation/x86/x86_64/boot-options.rst index 5f62b3b86357..482f3b29f99a 100644 --- a/Documentation/x86/x86_64/boot-options.rst +++ b/Documentation/x86/x86_64/boot-options.rst @@ -126,7 +126,7 @@ Idle loop Rebooting ========= - reboot=b[ios] | t[riple] | k[bd] | a[cpi] | e[fi] [, [w]arm | [c]old] + reboot=b[ios] | t[riple] | k[bd] | a[cpi] | e[fi] | p[ci] [, [w]arm | [c]old] bios Use the CPU reboot vector for warm reset warm @@ -145,6 +145,8 @@ Rebooting Use efi reset_system runtime service. If EFI is not configured or the EFI reset does not work, the reboot path attempts the reset using the keyboard controller. + pci + Use a write to the PCI config space register 0xcf9 to trigger reboot. Using warm reset will be much faster especially on big memory systems because the BIOS will not go through the memory check. -- cgit v1.2.3 From 12febc181886f0658ce3413f554203c255d338dd Mon Sep 17 00:00:00 2001 From: Paul Gortmaker Date: Sun, 30 May 2021 12:24:46 -0400 Subject: x86/reboot: Document how to override DMI platform quirks commit 5955633e91bf ("x86/reboot: Skip DMI checks if reboot set by user") made it so that it's not required to recompile the kernel in order to bypass broken reboot quirks compiled into an image: * This variable is used privately to keep track of whether or not * reboot_type is still set to its default value (i.e., reboot= hasn't * been set on the command line). This is needed so that we can * suppress DMI scanning for reboot quirks. Without it, it's * impossible to override a faulty reboot quirk without recompiling. However, at the time it was not eally documented outside the source code, and so this information isn't really available to the average user out there. The change is a little white lie and invented "reboot=default" since it is easy to remember, and documents well. The truth is that any random string that is *not* a currently accepted string will work. Since that doesn't document well for non-coders, and since it's unknown what the future additions might be, lay claim on "default" since that is exactly what it achieves. Signed-off-by: Paul Gortmaker Signed-off-by: Thomas Gleixner Link: https://lore.kernel.org/r/20210530162447.996461-3-paul.gortmaker@windriver.com --- Documentation/admin-guide/kernel-parameters.txt | 2 +- Documentation/x86/x86_64/boot-options.rst | 7 +++++++ 2 files changed, 8 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index bdb22006f713..34c8dd54518e 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -4777,7 +4777,7 @@ reboot= [KNL] Format (x86 or x86_64): - [w[arm] | c[old] | h[ard] | s[oft] | g[pio]] \ + [w[arm] | c[old] | h[ard] | s[oft] | g[pio]] | d[efault] \ [[,]s[mp]#### \ [[,]b[ios] | a[cpi] | k[bd] | t[riple] | e[fi] | p[ci]] \ [[,]f[orce] diff --git a/Documentation/x86/x86_64/boot-options.rst b/Documentation/x86/x86_64/boot-options.rst index 482f3b29f99a..ccb7e86bf8d9 100644 --- a/Documentation/x86/x86_64/boot-options.rst +++ b/Documentation/x86/x86_64/boot-options.rst @@ -157,6 +157,13 @@ Rebooting Don't stop other CPUs on reboot. This can make reboot more reliable in some cases. + reboot=default + There are some built-in platform specific "quirks" - you may see: + "reboot: series board detected. Selecting for reboots." + In the case where you think the quirk is in error (e.g. you have + newer BIOS, or newer board) using this option will ignore the built-in + quirk table, and use the generic default reboot actions. + Non Executable Mappings ======================= -- cgit v1.2.3 From 991007ba6ccad588504cbd1eadf19fbf15c67ace Mon Sep 17 00:00:00 2001 From: Marc Zyngier Date: Sat, 24 Jul 2021 12:40:23 +0100 Subject: Documentation: Update irq_domain.rst with new lookup APIs Catch up with the recent irqdomain updates, and document {generic_,}handle_domain_irq(), irq_resolve_mapping() as well as the deprecation of some of the older APIs. Signed-off-by: Marc Zyngier --- Documentation/core-api/irq/irq-domain.rst | 28 +++++++++++++++++++++++++--- 1 file changed, 25 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/core-api/irq/irq-domain.rst b/Documentation/core-api/irq/irq-domain.rst index 53283b3729a1..6979b4af2c1f 100644 --- a/Documentation/core-api/irq/irq-domain.rst +++ b/Documentation/core-api/irq/irq-domain.rst @@ -55,8 +55,24 @@ exist then it will allocate a new Linux irq_desc, associate it with the hwirq, and call the .map() callback so the driver can perform any required hardware setup. -When an interrupt is received, irq_find_mapping() function should -be used to find the Linux IRQ number from the hwirq number. +Once a mapping has been established, it can be retrieved or used via a +variety of methods: + +- irq_resolve_mapping() returns a pointer to the irq_desc structure + for a given domain and hwirq number, and NULL if there was no + mapping. +- irq_find_mapping() returns a Linux IRQ number for a given domain and + hwirq number, and 0 if there was no mapping +- irq_linear_revmap() is now identical to irq_find_mapping(), and is + deprecated +- generic_handle_domain_irq() handles an interrupt described by a + domain and a hwirq number +- handle_domain_irq() does the same thing for root interrupt + controllers and deals with the set_irq_reg()/irq_enter() sequences + that most architecture requires + +Note that irq domain lookups must happen in contexts that are +compatible with a RCU read-side critical section. The irq_create_mapping() function must be called *atleast once* before any call to irq_find_mapping(), lest the descriptor will not @@ -137,7 +153,9 @@ required. Calling irq_create_direct_mapping() will allocate a Linux IRQ number and call the .map() callback so that driver can program the Linux IRQ number into the hardware. -Most drivers cannot use this mapping. +Most drivers cannot use this mapping, and it is now gated on the +CONFIG_IRQ_DOMAIN_NOMAP option. Please refrain from introducing new +users of this API. Legacy ------ @@ -157,6 +175,10 @@ for IRQ numbers that are passed to struct device registrations. In that case the Linux IRQ numbers cannot be dynamically assigned and the legacy mapping should be used. +As the name implies, the *_legacy() functions are deprecated and only +exist to ease the support of ancient platforms. No new users should be +added. + The legacy map assumes a contiguous range of IRQ numbers has already been allocated for the controller and that the IRQ number can be calculated by adding a fixed offset to the hwirq number, and -- cgit v1.2.3 From 112dfa5ca16cc95dd6ceef7387a5f0f8a808da56 Mon Sep 17 00:00:00 2001 From: Geert Uytterhoeven Date: Wed, 14 Jul 2021 15:20:00 +0200 Subject: dt-bindings: i2c: renesas,riic: Add interrupt-names The Renesas RZ/A and RZ/G2L I2C Bus Interface has no less than 8 interrupts. Hence document the "interrupt-names" property, to make it easier to review the interrupt mappings in DTS files. Note that this property cannot be made required yet, as the RIIC nodes in all DTS files lack the property. Signed-off-by: Geert Uytterhoeven Reviewed-by: Rob Herring Reviewed-by: Wolfram Sang Link: https://lore.kernel.org/r/a81d0e14e395f297666e8c3a8ce3e292d2606a65.1626267422.git.geert+renesas@glider.be --- .../devicetree/bindings/i2c/renesas,riic.yaml | 29 ++++++++++++++++------ 1 file changed, 21 insertions(+), 8 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/i2c/renesas,riic.yaml b/Documentation/devicetree/bindings/i2c/renesas,riic.yaml index 52d92ec7ec0b..70f998f00630 100644 --- a/Documentation/devicetree/bindings/i2c/renesas,riic.yaml +++ b/Documentation/devicetree/bindings/i2c/renesas,riic.yaml @@ -27,14 +27,25 @@ properties: interrupts: items: - - description: Transmit End Interrupt (TEI) - - description: Receive Data Full Interrupt (RI) - - description: Transmit Data Empty Interrupt (TI) - - description: Stop Condition Detection Interrupt (SPI) - - description: Start Condition Detection Interrupt (STI) - - description: NACK Reception Interrupt (NAKI) - - description: Arbitration-Lost Interrupt (ALI) - - description: Timeout Interrupt (TMOI) + - description: Transmit End Interrupt + - description: Receive Data Full Interrupt + - description: Transmit Data Empty Interrupt + - description: Stop Condition Detection Interrupt + - description: Start Condition Detection Interrupt + - description: NACK Reception Interrupt + - description: Arbitration-Lost Interrupt + - description: Timeout Interrupt + + interrupt-names: + items: + - const: tei + - const: ri + - const: ti + - const: spi + - const: sti + - const: naki + - const: ali + - const: tmoi clock-frequency: description: @@ -85,6 +96,8 @@ examples: , , ; + interrupt-names = "tei", "ri", "ti", "spi", "sti", "naki", "ali", + "tmoi"; clocks = <&mstp9_clks R7S72100_CLK_I2C0>; clock-frequency = <100000>; power-domains = <&cpg_clocks>; -- cgit v1.2.3 From 13bf92e6dec0e2be1ef0c7dd483f2d8b34eaa905 Mon Sep 17 00:00:00 2001 From: Geert Uytterhoeven Date: Wed, 14 Jul 2021 15:20:03 +0200 Subject: dt-bindings: i2c: renesas,riic: Make interrupt-names required Now the I2C device nodes in all DTS files have gained "interrupt-names" properties, the "interrupt-names" property can be made required. Signed-off-by: Geert Uytterhoeven Acked-by: Rob Herring Reviewed-by: Wolfram Sang Link: https://lore.kernel.org/r/da8d1973dcd419d8d9c8c662ee614952f3a6969e.1626267422.git.geert+renesas@glider.be --- Documentation/devicetree/bindings/i2c/renesas,riic.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/i2c/renesas,riic.yaml b/Documentation/devicetree/bindings/i2c/renesas,riic.yaml index 70f998f00630..402fd125e010 100644 --- a/Documentation/devicetree/bindings/i2c/renesas,riic.yaml +++ b/Documentation/devicetree/bindings/i2c/renesas,riic.yaml @@ -62,6 +62,7 @@ required: - compatible - reg - interrupts + - interrupt-names - clocks - clock-frequency - power-domains -- cgit v1.2.3 From 9d9cafb45c71c9fe302234807fae8f743056f88a Mon Sep 17 00:00:00 2001 From: Sven Peter Date: Tue, 3 Aug 2021 14:16:50 +0200 Subject: dt-bindings: iommu: add DART iommu bindings DART (Device Address Resolution Table) is the iommu found on Apple ARM SoCs such as the M1. Reviewed-by: Rob Herring Reviewed-by: Alyssa Rosenzweig Signed-off-by: Sven Peter Link: https://lore.kernel.org/r/20210803121651.61594-3-sven@svenpeter.dev Signed-off-by: Joerg Roedel --- .../devicetree/bindings/iommu/apple,dart.yaml | 81 ++++++++++++++++++++++ 1 file changed, 81 insertions(+) create mode 100644 Documentation/devicetree/bindings/iommu/apple,dart.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/iommu/apple,dart.yaml b/Documentation/devicetree/bindings/iommu/apple,dart.yaml new file mode 100644 index 000000000000..94aa9e9afa59 --- /dev/null +++ b/Documentation/devicetree/bindings/iommu/apple,dart.yaml @@ -0,0 +1,81 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iommu/apple,dart.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Apple DART IOMMU + +maintainers: + - Sven Peter + +description: |+ + Apple SoCs may contain an implementation of their Device Address + Resolution Table which provides a mandatory layer of address + translations for various masters. + + Each DART instance is capable of handling up to 16 different streams + with individual pagetables and page-level read/write protection flags. + + This DART IOMMU also raises interrupts in response to various + fault conditions. + +properties: + compatible: + const: apple,t8103-dart + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + description: + Reference to the gate clock phandle if required for this IOMMU. + Optional since not all IOMMUs are attached to a clock gate. + + '#iommu-cells': + const: 1 + description: + Has to be one. The single cell describes the stream id emitted by + a master to the IOMMU. + +required: + - compatible + - reg + - '#iommu-cells' + - interrupts + +additionalProperties: false + +examples: + - |+ + dart1: iommu@82f80000 { + compatible = "apple,t8103-dart"; + reg = <0x82f80000 0x4000>; + interrupts = <1 781 4>; + #iommu-cells = <1>; + }; + + master1 { + iommus = <&dart1 0>; + }; + + - |+ + dart2a: iommu@82f00000 { + compatible = "apple,t8103-dart"; + reg = <0x82f00000 0x4000>; + interrupts = <1 781 4>; + #iommu-cells = <1>; + }; + dart2b: iommu@82f80000 { + compatible = "apple,t8103-dart"; + reg = <0x82f80000 0x4000>; + interrupts = <1 781 4>; + #iommu-cells = <1>; + }; + + master2 { + iommus = <&dart2a 0>, <&dart2b 1>; + }; -- cgit v1.2.3 From 900a486ac73dfdf9b1629e7e4df6eacc92da7578 Mon Sep 17 00:00:00 2001 From: Thierry Reding Date: Thu, 12 Aug 2021 14:26:15 +0200 Subject: dt-bindings: tegra: Document NVIDIA Jetson TX2 NX developer kit The Jetson TX2 NX Developer Kit is the same form factor as Jetson Nano, but uses the more powerful Tegra186 SoC for added performance. Signed-off-by: Thierry Reding --- Documentation/devicetree/bindings/arm/tegra.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/tegra.yaml b/Documentation/devicetree/bindings/arm/tegra.yaml index b9f75e20fef5..b962fa6d649c 100644 --- a/Documentation/devicetree/bindings/arm/tegra.yaml +++ b/Documentation/devicetree/bindings/arm/tegra.yaml @@ -111,6 +111,7 @@ properties: - items: - enum: - nvidia,p2771-0000 + - nvidia,p3509-0000+p3636-0001 - const: nvidia,tegra186 - items: - enum: -- cgit v1.2.3 From 8ce1162a396068d8e69a88f35562ef3f29d4ab4e Mon Sep 17 00:00:00 2001 From: Yanteng Si Date: Fri, 6 Aug 2021 09:26:39 +0800 Subject: docs/zh_CN: add virt index translation Add virt to .../zh_CN/index and translate it into Chinese. Signed-off-by: Yanteng Si Reviewed-by: Alex Shi Link: https://lore.kernel.org/r/b28d3a530fe0c3635e7be2462fd14a4ae18f0220.1628212777.git.siyanteng@loongson.cn Signed-off-by: Jonathan Corbet --- Documentation/translations/zh_CN/index.rst | 2 +- Documentation/translations/zh_CN/virt/index.rst | 37 +++++++++++++++++++++++++ 2 files changed, 38 insertions(+), 1 deletion(-) create mode 100644 Documentation/translations/zh_CN/virt/index.rst (limited to 'Documentation') diff --git a/Documentation/translations/zh_CN/index.rst b/Documentation/translations/zh_CN/index.rst index e0d51a167032..c311c8741e6f 100644 --- a/Documentation/translations/zh_CN/index.rst +++ b/Documentation/translations/zh_CN/index.rst @@ -102,6 +102,7 @@ TODOList: iio/index sound/index filesystems/index + virt/index TODOList: @@ -127,7 +128,6 @@ TODOList: * spi/index * w1/index * watchdog/index -* virt/index * input/index * hwmon/index * gpu/index diff --git a/Documentation/translations/zh_CN/virt/index.rst b/Documentation/translations/zh_CN/virt/index.rst new file mode 100644 index 000000000000..9e5df5b5de15 --- /dev/null +++ b/Documentation/translations/zh_CN/virt/index.rst @@ -0,0 +1,37 @@ +.. SPDX-License-Identifier: GPL-2.0 +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/virt/index.rst + +:翻译: + + 司延腾 Yanteng Si + +:校译: + + 时奎亮 Alex Shi + +.. _cn_virt_index: + +=============== +Linux虚拟化支持 +=============== + +.. toctree:: + :maxdepth: 2 + +TODOLIST: + + kvm/index + uml/user_mode_linux_howto_v2 + paravirt_ops + guest-halt-polling + ne_overview + acrn/index + +.. only:: html and subproject + + Indices + ======= + + * :ref:`genindex` -- cgit v1.2.3 From ccb00ddc88cf3953249cd9595df174ff863b18bd Mon Sep 17 00:00:00 2001 From: Yanteng Si Date: Fri, 6 Aug 2021 09:26:40 +0800 Subject: docs/zh_CN: add virt paravirt_ops translation Translate Documentation/virt/paravirt_ops.rst into Chinese. Signed-off-by: Yanteng Si Reviewed-by: Alex Shi Link: https://lore.kernel.org/r/abba361233e2a58999ef5d31c20f24370d7724f2.1628212777.git.siyanteng@loongson.cn Signed-off-by: Jonathan Corbet --- Documentation/translations/zh_CN/virt/index.rst | 3 +- .../translations/zh_CN/virt/paravirt_ops.rst | 41 ++++++++++++++++++++++ 2 files changed, 43 insertions(+), 1 deletion(-) create mode 100644 Documentation/translations/zh_CN/virt/paravirt_ops.rst (limited to 'Documentation') diff --git a/Documentation/translations/zh_CN/virt/index.rst b/Documentation/translations/zh_CN/virt/index.rst index 9e5df5b5de15..b9b23bb88ffa 100644 --- a/Documentation/translations/zh_CN/virt/index.rst +++ b/Documentation/translations/zh_CN/virt/index.rst @@ -20,11 +20,12 @@ Linux虚拟化支持 .. toctree:: :maxdepth: 2 + paravirt_ops + TODOLIST: kvm/index uml/user_mode_linux_howto_v2 - paravirt_ops guest-halt-polling ne_overview acrn/index diff --git a/Documentation/translations/zh_CN/virt/paravirt_ops.rst b/Documentation/translations/zh_CN/virt/paravirt_ops.rst new file mode 100644 index 000000000000..06b122bc915d --- /dev/null +++ b/Documentation/translations/zh_CN/virt/paravirt_ops.rst @@ -0,0 +1,41 @@ +.. SPDX-License-Identifier: GPL-2.0 +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/virt/paravirt_ops.rst + +:翻译: + + 司延腾 Yanteng Si + +:校译: + + 陈飞杨 Feiyang Chen + 时奎亮 Alex Shi + +.. _cn_virt_paravirt_ops: + +============ +半虚拟化操作 +============ + +Linux提供了对不同管理程序虚拟化技术的支持。历史上，为了支持不同的虚拟机超级管理器 +（hypervisor，下文简称超级管理器），需要不同的二进制内核，这个限制已经被pv_ops移 +除了。Linux pv_ops是一个虚拟化API，它能够支持不同的管理程序。它允许每个管理程序 +优先于关键操作，并允许单一的内核二进制文件在所有支持的执行环境中运行，包括本机——没 +有任何管理程序。 + +pv_ops提供了一组函数指针，代表了与低级关键指令和各领域高级功能相对应的操作。 +pv-ops允许在运行时进行优化，在启动时对低级关键操作进行二进制修补。 + +pv_ops操作被分为三类: + +- 简单的间接调用 + 这些操作对应于高水平的函数，众所周知，间接调用的开销并不十分重要。 + +- 间接调用，允许用二进制补丁进行优化 + 通常情况下，这些操作对应于低级别的关键指令。它们被频繁地调用，并且是对性能关 + 键。开销是非常重要的。 + +- 一套用于手写汇编代码的宏程序 + 手写的汇编代码（.S文件）也需要半虚拟化，因为它们包括敏感指令或其中的一些代 + 码路径对性能非常关键。 -- cgit v1.2.3 From 9c987b10fefa6472e49be3f0c6f5b9d9309c42bf Mon Sep 17 00:00:00 2001 From: Yanteng Si Date: Fri, 6 Aug 2021 09:26:41 +0800 Subject: docs/zh_CN: add virt guest-halt-polling translation Translate Documentation/virt/guest-halt-polling.rst into Chinese. Signed-off-by: Yanteng Si Reviewed-by: Alex Shi Link: https://lore.kernel.org/r/658e255eff55bfdadc1576107bf367a2e80b881a.1628212777.git.siyanteng@loongson.cn Signed-off-by: Jonathan Corbet --- .../translations/zh_CN/virt/guest-halt-polling.rst | 87 ++++++++++++++++++++++ Documentation/translations/zh_CN/virt/index.rst | 2 +- 2 files changed, 88 insertions(+), 1 deletion(-) create mode 100644 Documentation/translations/zh_CN/virt/guest-halt-polling.rst (limited to 'Documentation') diff --git a/Documentation/translations/zh_CN/virt/guest-halt-polling.rst b/Documentation/translations/zh_CN/virt/guest-halt-polling.rst new file mode 100644 index 000000000000..b798d1cf0b48 --- /dev/null +++ b/Documentation/translations/zh_CN/virt/guest-halt-polling.rst @@ -0,0 +1,87 @@ +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/virt/guest-halt-polling.rst + +:翻译: + + 司延腾 Yanteng Si + +:校译: + + 时奎亮 Alex Shi + +.. _cn_virt_guest-halt-polling: + +======================================== +客户机停机轮询机制（Guest halt polling） +======================================== + +cpuidle_haltpoll驱动，与haltpoll管理器一起，允许客户机vcpus在停机前轮询 +一定的时间。 + +这为物理机侧的轮询提供了以下好处: + + 1) 在执行轮询时，POLL标志被设置，这允许远程vCPU在执行唤醒时避免发送 + IPI（以及处理IPI的相关成本）。 + + 2) 可以避免虚拟机退出的成本。 + +客户机侧轮询的缺点是，即使在物理机中的其他可运行任务中也会进行轮询。 + +其基本逻辑如下。一个全局值，即guest_halt_poll_ns，是由用户配置的，表示允 +许轮询的最大时间量。这个值是固定的。 + +每个vcpu都有一个可调整的guest_halt_poll_ns（"per-cpu guest_halt_poll_ns"）， +它由算法响应事件进行调整（解释如下）。 + +模块参数 +======== + +haltpoll管理器有5个可调整的模块参数: + +1) guest_halt_poll_ns: + +轮询停机前执行的最大时间，以纳秒为单位。 + +默认值: 200000 + +2) guest_halt_poll_shrink: + +当唤醒事件发生在全局的guest_halt_poll_ns之后，用于缩减每个CPU的guest_halt_poll_ns +的划分系数。 + +默认值: 2 + +3) guest_halt_poll_grow: + +当事件发生在per-cpu guest_halt_poll_ns之后但在global guest_halt_poll_ns之前， +用于增长per-cpu guest_halt_poll_ns的乘法系数。 + +默认值: 2 + +4) guest_halt_poll_grow_start: + +在系统空闲的情况下，每个cpu guest_halt_poll_ns最终达到零。这个值设置了增长时的 +初始每cpu guest_halt_poll_ns。这个值可以从10000开始增加，以避免在最初的增长阶 +段出现失误。: + +10k, 20k, 40k, ... (例如，假设guest_halt_poll_grow=2). + +默认值: 50000 + +5) guest_halt_poll_allow_shrink: + +允许缩减的Bool参数。设置为N以避免它（一旦达到全局的guest_halt_poll_ns值，每CPU的 +guest_halt_poll_ns将保持高位）。 + +默认值: Y + +模块参数可以从Debugfs文件中设置，在:: + + /sys/module/haltpoll/parameters/ + +进一步说明 +========== + +- 在设置guest_halt_poll_ns参数时应该小心，因为一个大的值有可能使几乎是完全空闲机 + 器上的cpu使用率达到100%。 diff --git a/Documentation/translations/zh_CN/virt/index.rst b/Documentation/translations/zh_CN/virt/index.rst index b9b23bb88ffa..b94f6a3c2257 100644 --- a/Documentation/translations/zh_CN/virt/index.rst +++ b/Documentation/translations/zh_CN/virt/index.rst @@ -21,12 +21,12 @@ Linux虚拟化支持 :maxdepth: 2 paravirt_ops + guest-halt-polling TODOLIST: kvm/index uml/user_mode_linux_howto_v2 - guest-halt-polling ne_overview acrn/index -- cgit v1.2.3 From e636a91584ad198f222f68a4ad61e27633976596 Mon Sep 17 00:00:00 2001 From: Yanteng Si Date: Fri, 6 Aug 2021 09:26:42 +0800 Subject: docs/zh_CN: add virt ne_overview translation Translate Documentation/virt/ne_overview.rst into Chinese. Signed-off-by: Yanteng Si Reviewed-by: Alex Shi Link: https://lore.kernel.org/r/a6e1a2275a397d77957be30d1acdfeda9dc836f4.1628212777.git.siyanteng@loongson.cn Signed-off-by: Jonathan Corbet --- Documentation/translations/zh_CN/virt/index.rst | 2 +- .../translations/zh_CN/virt/ne_overview.rst | 88 ++++++++++++++++++++++ 2 files changed, 89 insertions(+), 1 deletion(-) create mode 100644 Documentation/translations/zh_CN/virt/ne_overview.rst (limited to 'Documentation') diff --git a/Documentation/translations/zh_CN/virt/index.rst b/Documentation/translations/zh_CN/virt/index.rst index b94f6a3c2257..8e7713163962 100644 --- a/Documentation/translations/zh_CN/virt/index.rst +++ b/Documentation/translations/zh_CN/virt/index.rst @@ -22,12 +22,12 @@ Linux虚拟化支持 paravirt_ops guest-halt-polling + ne_overview TODOLIST: kvm/index uml/user_mode_linux_howto_v2 - ne_overview acrn/index .. only:: html and subproject diff --git a/Documentation/translations/zh_CN/virt/ne_overview.rst b/Documentation/translations/zh_CN/virt/ne_overview.rst new file mode 100644 index 000000000000..2455b371abea --- /dev/null +++ b/Documentation/translations/zh_CN/virt/ne_overview.rst @@ -0,0 +1,88 @@ +.. SPDX-License-Identifier: GPL-2.0 +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/virt/ne_overview.rst + +:翻译: + + 司延腾 Yanteng Si + +:校译: + + 时奎亮 Alex Shi + +.. _cn_virt_ne_overview: + +============== +Nitro Enclaves +============== + +概述 +==== + +Nitro Enclaves（NE）是亚马逊弹性计算云（EC2）的一项新功能，允许客户在EC2实 +例中划分出孤立的计算环境[1]。 + +例如，一个处理敏感数据并在虚拟机中运行的应用程序，可以与在同一虚拟机中运行的 +其他应用程序分开。然后，这个应用程序在一个独立于主虚拟机的虚拟机中运行，即 +enclave。 + +一个enclave与催生它的虚拟机一起运行。这种设置符合低延迟应用的需要。为enclave +分配的资源，如内存和CPU，是从主虚拟机中分割出来的。每个enclave都被映射到一 +个运行在主虚拟机中的进程，该进程通过一个ioctl接口与NE驱动进行通信。 + +在这个意义上，有两个组成部分。 + +1. 一个enclave抽象进程——一个运行在主虚拟机客体中的用户空间进程，它使用NE驱动 +提供的ioctl接口来生成一个enclave虚拟机（这就是下面的2）。 + +有一个NE模拟的PCI设备暴露给主虚拟机。这个新的PCI设备的驱动被包含在NE驱动中。 + +ioctl逻辑被映射到PCI设备命令，例如，NE_START_ENCLAVE ioctl映射到一个enclave +启动PCI命令。然后，PCI设备命令被翻译成在管理程序方面采取的行动；也就是在运 +行主虚拟机的主机上运行的Nitro管理程序。Nitro管理程序是基于KVM核心技术的。 + +2. enclave本身——一个运行在与催生它的主虚拟机相同的主机上的虚拟机。内存和CPU +从主虚拟机中分割出来，专门用于enclave虚拟机。enclave没有连接持久性存储。 + +从主虚拟机中分割出来并给enclave的内存区域需要对齐2 MiB/1 GiB物理连续的内存 +区域（或这个大小的倍数，如8 MiB）。该内存可以通过使用hugetlbfs从用户空间分 +配[2][3]。一个enclave的内存大小需要至少64 MiB。enclave内存和CPU需要来自同 +一个NUMA节点。 + +一个enclave在专用的核心上运行。CPU 0及其同级别的CPU需要保持对主虚拟机的可用 +性。CPU池必须由具有管理能力的用户为NE目的进行设置。关于CPU池的格式，请看内核 +文档[4]中的cpu list部分。 + +enclave通过本地通信通道与主虚拟机进行通信，使用virtio-vsock[5]。主虚拟机有 +virtio-pci vsock模拟设备，而飞地虚拟机有virtio-mmio vsock模拟设备。vsock +设备使用eventfd作为信令。enclave虚拟机看到通常的接口——本地APIC和IOAPIC——从 +virtio-vsock设备获得中断。virtio-mmio设备被放置在典型的4 GiB以下的内存中。 + +在enclave中运行的应用程序需要和将在enclave虚拟机中运行的操作系统（如内核、 +ramdisk、init）一起被打包到enclave镜像中。enclave虚拟机有自己的内核并遵循标 +准的Linux启动协议[6]。 + +内核bzImage、内核命令行、ramdisk（s）是enclave镜像格式（EIF）的一部分；另外 +还有一个EIF头，包括元数据，如magic number、eif版本、镜像大小和CRC。 + +哈希值是为整个enclave镜像（EIF）、内核和ramdisk（s）计算的。例如，这被用来检 +查在enclave虚拟机中加载的enclave镜像是否是打算运行的那个。 + +这些加密测量包括在由Nitro超级管理器成的签名证明文件中，并进一步用来证明enclave +的身份；KMS是NE集成的服务的一个例子，它检查证明文件。 + +enclave镜像（EIF）被加载到enclave内存中，偏移量为8 MiB。enclave中的初始进程 +连接到主虚拟机的vsock CID和一个预定义的端口--9000，以发送一个心跳值--0xb7。这 +个机制用于在主虚拟机中检查enclave是否已经启动。主虚拟机的CID是3。 + +如果enclave虚拟机崩溃或优雅地退出，NE驱动会收到一个中断事件。这个事件会通过轮询 +通知机制进一步发送到运行在主虚拟机中的用户空间enclave进程。然后，用户空间enclave +进程就可以退出了。 + +[1] https://aws.amazon.com/ec2/nitro/nitro-enclaves/ +[2] https://www.kernel.org/doc/html/latest/admin-guide/mm/hugetlbpage.html +[3] https://lwn.net/Articles/807108/ +[4] https://www.kernel.org/doc/html/latest/admin-guide/kernel-parameters.html +[5] https://man7.org/linux/man-pages/man7/vsock.7.html +[6] https://www.kernel.org/doc/html/latest/x86/boot.html -- cgit v1.2.3 From 8dda2eac96844aac6ed25eb490b061b16eaf2e64 Mon Sep 17 00:00:00 2001 From: Yanteng Si Date: Fri, 6 Aug 2021 09:26:43 +0800 Subject: docs/zh_CN: add virt acrn index translation Translate Documentation/virt/acrn/index.rst into Chinese. Signed-off-by: Yanteng Si Reviewed-by: Alex Shi Link: https://lore.kernel.org/r/17a0dac5ecc5bdcc98160bdb028c6876ca38a6bc.1628212777.git.siyanteng@loongson.cn Signed-off-by: Jonathan Corbet --- .../translations/zh_CN/virt/acrn/index.rst | 27 ++++++++++++++++++++++ Documentation/translations/zh_CN/virt/index.rst | 2 +- 2 files changed, 28 insertions(+), 1 deletion(-) create mode 100644 Documentation/translations/zh_CN/virt/acrn/index.rst (limited to 'Documentation') diff --git a/Documentation/translations/zh_CN/virt/acrn/index.rst b/Documentation/translations/zh_CN/virt/acrn/index.rst new file mode 100644 index 000000000000..6061e790ee83 --- /dev/null +++ b/Documentation/translations/zh_CN/virt/acrn/index.rst @@ -0,0 +1,27 @@ +.. SPDX-License-Identifier: GPL-2.0 +.. include:: ../../disclaimer-zh_CN.rst + +:Original: Documentation/virt/acrn/index.rst + +:翻译: + + 司延腾 Yanteng Si + +:校译: + + 时奎亮 Alex Shi + +.. _cn_virt_acrn_index: + +============== +ACRN超级管理器 +============== + +.. toctree:: + :maxdepth: 1 + +TODOLIST: + + introduction + io-request + cpuid diff --git a/Documentation/translations/zh_CN/virt/index.rst b/Documentation/translations/zh_CN/virt/index.rst index 8e7713163962..f8dd13681341 100644 --- a/Documentation/translations/zh_CN/virt/index.rst +++ b/Documentation/translations/zh_CN/virt/index.rst @@ -23,12 +23,12 @@ Linux虚拟化支持 paravirt_ops guest-halt-polling ne_overview + acrn/index TODOLIST: kvm/index uml/user_mode_linux_howto_v2 - acrn/index .. only:: html and subproject -- cgit v1.2.3 From ab03e49f13ca8be59c20d8e59c4a4bf1b6410a99 Mon Sep 17 00:00:00 2001 From: Yanteng Si Date: Fri, 6 Aug 2021 09:26:44 +0800 Subject: docs/zh_CN: add virt acrn introduction translation Translate Documentation/virt/acrn/introduction.rst into Chinese. Signed-off-by: Yanteng Si Reviewed-by: Alex Shi Link: https://lore.kernel.org/r/667a6eb64820d2234d12a0c5dd5b642af16c0d99.1628212777.git.siyanteng@loongson.cn Signed-off-by: Jonathan Corbet --- .../translations/zh_CN/virt/acrn/index.rst | 4 +- .../translations/zh_CN/virt/acrn/introduction.rst | 52 ++++++++++++++++++++++ 2 files changed, 55 insertions(+), 1 deletion(-) create mode 100644 Documentation/translations/zh_CN/virt/acrn/introduction.rst (limited to 'Documentation') diff --git a/Documentation/translations/zh_CN/virt/acrn/index.rst b/Documentation/translations/zh_CN/virt/acrn/index.rst index 6061e790ee83..b8f502033455 100644 --- a/Documentation/translations/zh_CN/virt/acrn/index.rst +++ b/Documentation/translations/zh_CN/virt/acrn/index.rst @@ -20,8 +20,10 @@ ACRN超级管理器 .. toctree:: :maxdepth: 1 + introduction + TODOLIST: - introduction + io-request cpuid diff --git a/Documentation/translations/zh_CN/virt/acrn/introduction.rst b/Documentation/translations/zh_CN/virt/acrn/introduction.rst new file mode 100644 index 000000000000..7182415cb087 --- /dev/null +++ b/Documentation/translations/zh_CN/virt/acrn/introduction.rst @@ -0,0 +1,52 @@ +.. SPDX-License-Identifier: GPL-2.0 +.. include:: ../../disclaimer-zh_CN.rst + +:Original: Documentation/virt/acrn/introduction.rst + +:翻译: + + 司延腾 Yanteng Si + +:校译: + + 时奎亮 Alex Shi + +.. _cn_virt_acrn_introduction: + +ACRN超级管理器介绍 +================== + +ACRN超级管理器是一个第一类超级管理器，直接在裸机硬件上运行。它有一个特权管理虚拟机，称为服 +务虚拟机，用于管理用户虚拟机和进行I/O仿真。 + +ACRN用户空间是一个运行在服务虚拟机中的应用程序，它根据命令行配置为用户虚拟机仿真设备。 +ACRN管理程序服务模块（HSM）是服务虚拟机中的一个内核模块，为ACRN用户空间提供管理程序服 +务。 + +下图展示了该架构。 + +:: + + 服务端VM 用户端VM + +----------------------------+ | +------------------+ + | +--------------+ | | | | + | |ACRN用户空间 | | | | | + | +--------------+ | | | | + |-----------------ioctl------| | | | ... + |内核空间 +----------+ | | | | + | | HSM | | | | 驱动 | + | +----------+ | | | | + +--------------------|-------+ | +------------------+ + +---------------------hypercall----------------------------------------+ + | ACRN超级管理器 | + +----------------------------------------------------------------------+ + | 硬件 | + +----------------------------------------------------------------------+ + +ACRN用户空间为用户虚拟机分配内存，配置和初始化用户虚拟机使用的设备，加载虚拟引导程序， +初始化虚拟CPU状态，处理来自用户虚拟机的I/O请求访问。它使用ioctls来与HSM通信。HSM通过 +与ACRN超级管理器的hypercalls进行交互来实现管理服务。HSM向用户空间输出一个char设备接口 +（/dev/acrn_hsm）。 + +ACRN超级管理器是开源的，任何人都可以贡献。源码库在 +https://github.com/projectacrn/acrn-hypervisor。 -- cgit v1.2.3 From f63c6894f6453e6eedb5f04a1f3d222773abd427 Mon Sep 17 00:00:00 2001 From: Yanteng Si Date: Fri, 6 Aug 2021 09:26:45 +0800 Subject: docs/zh_CN: add virt acrn io-request translation Translate Documentation/virt/acrn/io-request.rst into Chinese. Signed-off-by: Yanteng Si Reviewed-by: Alex Shi Link: https://lore.kernel.org/r/291079265a8b0555de4d624d7d11fc5ac37a9422.1628212777.git.siyanteng@loongson.cn Signed-off-by: Jonathan Corbet --- .../translations/zh_CN/virt/acrn/index.rst | 3 +- .../translations/zh_CN/virt/acrn/io-request.rst | 99 ++++++++++++++++++++++ 2 files changed, 101 insertions(+), 1 deletion(-) create mode 100644 Documentation/translations/zh_CN/virt/acrn/io-request.rst (limited to 'Documentation') diff --git a/Documentation/translations/zh_CN/virt/acrn/index.rst b/Documentation/translations/zh_CN/virt/acrn/index.rst index b8f502033455..b53976e20a34 100644 --- a/Documentation/translations/zh_CN/virt/acrn/index.rst +++ b/Documentation/translations/zh_CN/virt/acrn/index.rst @@ -21,9 +21,10 @@ ACRN超级管理器 :maxdepth: 1 introduction + io-request TODOLIST: - io-request + cpuid diff --git a/Documentation/translations/zh_CN/virt/acrn/io-request.rst b/Documentation/translations/zh_CN/virt/acrn/io-request.rst new file mode 100644 index 000000000000..4b4e7186d9a5 --- /dev/null +++ b/Documentation/translations/zh_CN/virt/acrn/io-request.rst @@ -0,0 +1,99 @@ +.. SPDX-License-Identifier: GPL-2.0 +.. include:: ../../disclaimer-zh_CN.rst + +:Original: Documentation/virt/acrn/io-request.rst + +:翻译: + + 司延腾 Yanteng Si + +:校译: + + 时奎亮 Alex Shi + +.. _cn_virt_acrn_io-request: + +I/O请求处理 +=========== + +客户虚拟机的I/O请求由超级管理器构建，由ACRN超级管理器服务模块分发到与I/O请求的地址范 +围相对应的I/O客户端。I/O请求处理的细节将在以下章节描述。 + +1. I/O请求 +---------- + +对于每个客户虚拟机，有一个共享的4KB字节的内存区域，用于超级管理器和服务虚拟机之间的 +I/O请求通信。一个I/O请求是一个256字节的结构体缓冲区，它是 "acrn_io_request" 结构 +体，当客户虚拟机中发生被困的I/O访问时，由超级管理器的I/O处理器填充。服务虚拟机中的 +ACRN用户空间首先分配一个4KB字节的页面，并将缓冲区的GPA（客户物理地址）传递给管理平 +台。缓冲区被用作16个I/O请求槽的数组，每个I/O请求槽为256字节。这个数组是按vCPU ID +索引的。 + +2. I/O客户端 +------------ + +一个I/O客户端负责处理客户虚拟机的I/O请求，其访问的GPA在一定范围内。每个客户虚拟机 +可以关联多个I/O客户端。每个客户虚拟机都有一个特殊的客户端，称为默认客户端，负责处理 +所有不在其他客户端范围内的I/O请求。ACRN用户空间充当每个客户虚拟机的默认客户端。 + +下面的图示显示了I/O请求共享缓冲区、I/O请求和I/O客户端之间的关系。 + +:: + + +------------------------------------------------------+ + | 服务VM | + |+--------------------------------------------------+ | + || +----------------------------------------+ | | + || | 共享页 ACRN用户空间 | | | + || | +-----------------+ +------------+ | | | + || +----+->| acrn_io_request |<-+ 默认 | | | | + || | | | +-----------------+ | I/O客户端 | | | | + || | | | | ... | +------------+ | | | + || | | | +-----------------+ | | | + || | +-|--------------------------------------+ | | + ||---|----|-----------------------------------------| | + || | | 内核 | | + || | | +----------------------+ | | + || | | | +-------------+ HSM | | | + || | +--------------+ | | | | + || | | | I/O客户端 | | | | + || | | | | | | | + || | | +-------------+ | | | + || | +----------------------+ | | + |+---|----------------------------------------------+ | + +----|-------------------------------------------------+ + | + +----|-------------------------------------------------+ + | +-+-----------+ | + | | I/O处理 | ACRN超级管理器 | + | +-------------+ | + +------------------------------------------------------+ + +3. I/O请求状态转换 +------------------ + +一个ACRN I/O请求的状态转换如下。 + +:: + + FREE -> PENDING -> PROCESSING -> COMPLETE -> FREE -> ... + +- FREE: 这个I/O请求槽是空的 +- PENDING: 在这个槽位上有一个有效的I/O请求正在等待 +- PROCESSING: 正在处理I/O请求 +- COMPLETE: 该I/O请求已被处理 + +处于COMPLETE或FREE状态的I/O请求是由超级管理器拥有的。HSM和ACRN用户空间负责处理其 +他的。 + +4. I/O请求的处理流程 +-------------------- + +a. 当客户虚拟机中发生被陷入的I/O访问时，超级管理器的I/O处理程序将把I/O请求填充为 + PENDING状态。 +b. 超级管理器向服务虚拟机发出一个向上调用，这是一个通知中断。 +c. upcall处理程序会安排一个工作者来调度I/O请求。 +d. 工作者寻找PENDING I/O请求，根据I/O访问的地址将其分配给不同的注册客户，将其 + 状态更新为PROCESSING，并通知相应的客户进行处理。 +e. 被通知的客户端处理指定的I/O请求。 +f. HSM将I/O请求状态更新为COMPLETE，并通过hypercalls通知超级管理器完成。 -- cgit v1.2.3 From 3bf5548d8e9602ee01b9f39f3127b5933e9e8be0 Mon Sep 17 00:00:00 2001 From: Yanteng Si Date: Fri, 6 Aug 2021 09:26:46 +0800 Subject: docs/zh_CN: add virt acrn cpuid translation Translate Documentation/virt/acrn/cpuid.rst into Chinese. Signed-off-by: Yanteng Si Reviewed-by: Alex Shi Link: https://lore.kernel.org/r/35730828bc65d3912ba27382d5d70ddacee7d8a5.1628212777.git.siyanteng@loongson.cn Signed-off-by: Jonathan Corbet --- .../translations/zh_CN/virt/acrn/cpuid.rst | 56 ++++++++++++++++++++++ .../translations/zh_CN/virt/acrn/index.rst | 5 -- 2 files changed, 56 insertions(+), 5 deletions(-) create mode 100644 Documentation/translations/zh_CN/virt/acrn/cpuid.rst (limited to 'Documentation') diff --git a/Documentation/translations/zh_CN/virt/acrn/cpuid.rst b/Documentation/translations/zh_CN/virt/acrn/cpuid.rst new file mode 100644 index 000000000000..6f7be545611b --- /dev/null +++ b/Documentation/translations/zh_CN/virt/acrn/cpuid.rst @@ -0,0 +1,56 @@ +.. SPDX-License-Identifier: GPL-2.0 +.. include:: ../../disclaimer-zh_CN.rst + +:Original: Documentation/virt/acrn/cpuid.rst + +:翻译: + + 司延腾 Yanteng Si + +:校译: + + 时奎亮 Alex Shi + +.. _cn_virt_acrn_cpuid: + +============== +ACRN CPUID位域 +============== + +在ACRN超级管理器上运行的客户虚拟机可以使用CPUID检查其一些功能。 + +ACRN的cpuid函数是: + +函数: 0x40000000 + +返回:: + + eax = 0x40000010 + ebx = 0x4e524341 + ecx = 0x4e524341 + edx = 0x4e524341 + +注意，ebx，ecx和edx中的这个值对应于字符串“ACRNACRNACRN”。eax中的值对应于这个叶子 +中存在的最大cpuid函数，如果将来有更多的函数加入，将被更新。 + +函数: define ACRN_CPUID_FEATURES (0x40000001) + +返回:: + + ebx, ecx, edx + eax = an OR'ed group of (1 << flag) + +其中 ``flag`` 的定义如下: + +================================= =========== ================================ +标志 值 描述 +================================= =========== ================================ +ACRN_FEATURE_PRIVILEGED_VM 0 客户虚拟机是一个有特权的虚拟机 +================================= =========== ================================ + +函数: 0x40000010 + +返回:: + + ebx, ecx, edx + eax = (Virtual) TSC frequency in kHz. diff --git a/Documentation/translations/zh_CN/virt/acrn/index.rst b/Documentation/translations/zh_CN/virt/acrn/index.rst index b53976e20a34..34605d87f103 100644 --- a/Documentation/translations/zh_CN/virt/acrn/index.rst +++ b/Documentation/translations/zh_CN/virt/acrn/index.rst @@ -22,9 +22,4 @@ ACRN超级管理器 introduction io-request - -TODOLIST: - - - cpuid -- cgit v1.2.3 From f4e60d9f1ba5fa40544ab967513e450fa44656d0 Mon Sep 17 00:00:00 2001 From: Yanteng Si Date: Fri, 6 Aug 2021 10:58:48 +0800 Subject: docs/zh_CN: add infiniband index translation Translate Documentation/infiniband/index.rst into Chinese. Signed-off-by: Yanteng Si Reviewed-by: Alex Shi Reviewed-by: Puyu Wang Link: https://lore.kernel.org/r/e3bca9e59f410fe62489e36c5b9a3fab78bc1421.1628218477.git.siyanteng@loongson.cn Signed-off-by: Jonathan Corbet --- Documentation/translations/zh_CN/index.rst | 2 +- .../translations/zh_CN/infiniband/index.rst | 40 ++++++++++++++++++++++ 2 files changed, 41 insertions(+), 1 deletion(-) create mode 100644 Documentation/translations/zh_CN/infiniband/index.rst (limited to 'Documentation') diff --git a/Documentation/translations/zh_CN/index.rst b/Documentation/translations/zh_CN/index.rst index c311c8741e6f..1b6a07c04c79 100644 --- a/Documentation/translations/zh_CN/index.rst +++ b/Documentation/translations/zh_CN/index.rst @@ -103,6 +103,7 @@ TODOList: sound/index filesystems/index virt/index + infiniband/index TODOList: @@ -117,7 +118,6 @@ TODOList: * hid/index * i2c/index * isdn/index -* infiniband/index * leds/index * netlabel/index * networking/index diff --git a/Documentation/translations/zh_CN/infiniband/index.rst b/Documentation/translations/zh_CN/infiniband/index.rst new file mode 100644 index 000000000000..ebb1e20b7df4 --- /dev/null +++ b/Documentation/translations/zh_CN/infiniband/index.rst @@ -0,0 +1,40 @@ +.. SPDX-License-Identifier: GPL-2.0 + +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/infiniband/index.rst + +:翻译: + + 司延腾 Yanteng Si + +:校译: + + 王普宇 Puyu Wang + 时奎亮 Alex Shi + +.. _cn_infiniband_index: + +========== +infiniband +========== + +.. toctree:: + :maxdepth: 1 + +TODOLIST: + + core_locking + ipoib + opa_vnic + sysfs + tag_matching + user_mad + user_verbs + +.. only:: subproject and html + + Indices + ======= + + * :ref:`genindex` -- cgit v1.2.3 From 312356129e5836bb6ae4780340325e1f46fda1e7 Mon Sep 17 00:00:00 2001 From: Yanteng Si Date: Fri, 6 Aug 2021 10:58:49 +0800 Subject: docs/zh_CN: add infiniband core_locking translation Translate Documentation/infiniband/core_locking.rst into Chinese. Signed-off-by: Yanteng Si Reviewed-by: Alex Shi Reviewed-by: Puyu Wang Link: https://lore.kernel.org/r/d035d79b2936be762bc001b3a53831f34f72cbb7.1628218477.git.siyanteng@loongson.cn Signed-off-by: Jonathan Corbet --- .../translations/zh_CN/infiniband/core_locking.rst | 115 +++++++++++++++++++++ .../translations/zh_CN/infiniband/index.rst | 3 +- 2 files changed, 117 insertions(+), 1 deletion(-) create mode 100644 Documentation/translations/zh_CN/infiniband/core_locking.rst (limited to 'Documentation') diff --git a/Documentation/translations/zh_CN/infiniband/core_locking.rst b/Documentation/translations/zh_CN/infiniband/core_locking.rst new file mode 100644 index 000000000000..42f08038d44b --- /dev/null +++ b/Documentation/translations/zh_CN/infiniband/core_locking.rst @@ -0,0 +1,115 @@ + +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/infiniband/core_locking.rst + +:翻译: + + 司延腾 Yanteng Si + +:校译: + + 王普宇 Puyu Wang + 时奎亮 Alex Shi + +.. _cn_infiniband_core_locking: + +================== +infiniband中间层锁 +================== + + 本指南试图明确infiniband中间层的锁假设。它描述了对位于中间层以下的低 + 级驱动程序和使用中间层的上层协议的要求。 + +睡眠和中断环境 +============== + + 除了以下异常情况，ib_device结构体中所有方法的低级驱动实现都可以睡眠。 + 这些异常情况是列表中的任意的方法: + + - create_ah + - modify_ah + - query_ah + - destroy_ah + - post_send + - post_recv + - poll_cq + - req_notify_cq + + 他们可能不可以睡眠，而且必须可以从任何上下文中调用。 + + 向上层协议使用者输出的相应函数: + + - rdma_create_ah + - rdma_modify_ah + - rdma_query_ah + - rdma_destroy_ah + - ib_post_send + - ib_post_recv + - ib_req_notify_cq + + 因此，在任何情况下都可以安全调用（它们）。 + + 此外，该函数 + + - ib_dispatch_event + + 被底层驱动用来通过中间层调度异步事件的“A”，也可以从任何上下文中安全调 + 用。 + +可重入性 +-------- + + 由低级驱动程序导出的ib_device结构体中的所有方法必须是完全可重入的。 + 即使使用同一对象的多个函数调用被同时运行，低级驱动程序也需要执行所有 + 必要的同步以保持一致性。 + + IB中间层不执行任何函数调用的序列化。 + + 因为低级驱动程序是可重入的，所以不要求上层协议使用者任何顺序执行。然 + 而，为了得到合理的结果，可能需要一些顺序。例如，一个使用者可以在多个 + CPU上同时安全地调用ib_poll_cq()。然而，不同的ib_poll_cq()调用之间 + 的工作完成信息的顺序没有被定义。 + +回调 +---- + + 低级驱动程序不得直接从与ib_device方法调用相同的调用链中执行回调。例 + 如，低级驱动程序不允许从post_send方法直接调用使用者的完成事件处理程 + 序。相反，低级驱动程序应该推迟这个回调，例如，调度一个tasklet来执行 + 这个回调。 + + 低层驱动负责确保同一CQ的多个完成事件处理程序不被同时调用。驱动程序必 + 须保证一个给定的CQ的事件处理程序在同一时间只有一个在运行。换句话说， + 以下情况是不允许的:: + + CPU1 CPU2 + + low-level driver -> + consumer CQ event callback: + /* ... */ + ib_req_notify_cq(cq, ...); + low-level driver -> + /* ... */ consumer CQ event callback: + /* ... */ + return from CQ event handler + + 完成事件和异步事件回调的运行环境没有被定义。 根据低级别的驱动程序，它可能是 + 进程上下文、softirq上下文或中断上下文。上层协议使用者可能不会在回调中睡眠。 + +热插拔 +------ + + 当一个低级驱动程序调用ib_register_device()时，它宣布一个设备已经 + 准备好供使用者使用，所有的初始化必须在这个调用之前完成。设备必须保 + 持可用，直到驱动对ib_unregister_device()的调用返回。 + + 低级驱动程序必须从进程上下文调用ib_register_device()和 + ib_unregister_device()。如果使用者在这些调用中回调到驱动程序，它 + 不能持有任何可能导致死锁的semaphores。 + + 一旦其结构体ib_client的add方法被调用，上层协议使用者就可以开始使用 + 一个IB设备。使用者必须在从移除方法返回之前完成所有的清理工作并释放 + 与设备相关的所有资源。 + + 使用者被允许在其添加和删除方法中睡眠。 diff --git a/Documentation/translations/zh_CN/infiniband/index.rst b/Documentation/translations/zh_CN/infiniband/index.rst index ebb1e20b7df4..cc00f31c77d0 100644 --- a/Documentation/translations/zh_CN/infiniband/index.rst +++ b/Documentation/translations/zh_CN/infiniband/index.rst @@ -22,9 +22,10 @@ infiniband .. toctree:: :maxdepth: 1 + core_locking + TODOLIST: - core_locking ipoib opa_vnic sysfs -- cgit v1.2.3 From 88e37e3d4443d56e674a97a2d717935c23767adf Mon Sep 17 00:00:00 2001 From: Yanteng Si Date: Fri, 6 Aug 2021 10:58:50 +0800 Subject: docs/zh_CN: add infiniband ipoib translation Translate Documentation/infiniband/ipoib.rst into Chinese. Signed-off-by: Yanteng Si Reviewed-by: Alex Shi Reviewed-by: Puyu Wang Link: https://lore.kernel.org/r/2d71cfe6b11568d9d9c665e829eaf680c249c94a.1628218477.git.siyanteng@loongson.cn Signed-off-by: Jonathan Corbet --- .../translations/zh_CN/infiniband/index.rst | 2 +- .../translations/zh_CN/infiniband/ipoib.rst | 111 +++++++++++++++++++++ 2 files changed, 112 insertions(+), 1 deletion(-) create mode 100644 Documentation/translations/zh_CN/infiniband/ipoib.rst (limited to 'Documentation') diff --git a/Documentation/translations/zh_CN/infiniband/index.rst b/Documentation/translations/zh_CN/infiniband/index.rst index cc00f31c77d0..da5e2821f767 100644 --- a/Documentation/translations/zh_CN/infiniband/index.rst +++ b/Documentation/translations/zh_CN/infiniband/index.rst @@ -23,10 +23,10 @@ infiniband :maxdepth: 1 core_locking + ipoib TODOLIST: - ipoib opa_vnic sysfs tag_matching diff --git a/Documentation/translations/zh_CN/infiniband/ipoib.rst b/Documentation/translations/zh_CN/infiniband/ipoib.rst new file mode 100644 index 000000000000..56517ea5fe9d --- /dev/null +++ b/Documentation/translations/zh_CN/infiniband/ipoib.rst @@ -0,0 +1,111 @@ +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/infiniband/ipoib.rst + +:翻译: + + 司延腾 Yanteng Si + +:校译: + + 王普宇 Puyu Wang + 时奎亮 Alex Shi + +.. _cn_infiniband_ipoib: + +========================= +infiniband上的IP（IPoIB） +========================= + + ib_ipoib驱动是IETF ipoib工作组发布的RFC 4391和4392所规定的 + infiniband上IP协议的一个实现。它是一个“本地”实现，即把接口类型设置为 + ARPHRD_INFINIBAND，硬件地址长度为20（早期的专有实现向内核伪装为以太网 + 接口）。 + +分区和P_Keys +============ + + 当IPoIB驱动被加载时，它会使用索引为0的P_Key给每个端口创建一个接口。要用 + 不同的P_Key创建一个接口，将所需的P_Key写入主接口的 + /sys/class/net//create_child文件里面。比如说:: + + echo 0x8001 > /sys/class/net/ib0/create_child + + 这将用P_Key 0x8001创建一个名为ib0.8001的接口。要删除一个子接口，使用 + ``delete_child`` 文件:: + + echo 0x8001 > /sys/class/net/ib0/delete_child + + 任何接口的P_Key都由“pkey”文件给出，而子接口的主接口在“parent”中。 + + 子接口的创建/删除也可以使用IPoIB的rtnl_link_ops来完成，使用两种 + 方式创建的子接口的行为是一样的。 + +数据报与连接模式 +================ + + IPoIB驱动支持两种操作模式：数据报和连接。模式是通过接口的 + /sys/class/net//mode文件设置和读取的。 + + 在数据报模式下，使用IB UD（不可靠数据报）传输，因此接口MTU等于IB L2 MTU + 减去IPoIB封装头（4字节）。例如，在一个典型的具有2K MTU的IB结构中，IPoIB + MTU将是2048 - 4 = 2044字节。 + + 在连接模式下，使用IB RC（可靠的连接）传输。连接模式利用IB传输的连接特性， + 允许MTU达到最大的IP包大小64K，这减少了处理大型UDP数据包、TCP段等所需的 + IP包数量，提高了大型信息的性能。 + + 在连接模式下，接口的UD QP仍被用于组播和与不支持连接模式的对等体的通信。 + 在这种情况下，ICMP PMTU数据包的RX仿真被用来使网络堆栈对这些邻居使用较 + 小的UD MTU。 + +无状态卸载 +========== + + 如果IB HW支持IPoIB无状态卸载，IPoIB会向网络堆栈广播TCP/IP校验和/或大量 + 传送（LSO）负载转移能力。 + + 大量传送（LSO）负载转移也已实现，可以使用ethtool调用打开/关闭。目前，LRO + 只支持具有校验和卸载能力的设备。 + + 无状态卸载只在数据报模式下支持。 + +中断管理 +======== + + 如果底层IB设备支持CQ事件管理，可以使用ethtool来设置中断缓解参数，从而减少 + 处理中断产生的开销。IPoIB的主要代码路径不使用TX完成信号的事件，所以只支持 + RX管理。 + +调试信息 +======== + + 通过将CONFIG_INFINIBAND_IPOIB_DEBUG设置为“y”来编译IPoIB驱动，跟踪信 + 息被编译到驱动中。通过将模块参数debug_level和mcast_debug_level设置为1来 + 打开它们。这些参数可以在运行时通过/sys/module/ib_ipoib/的文件来控制。 + + CONFIG_INFINIBAND_IPOIB_DEBUG也启用debugfs虚拟文件系统中的文件。通过挂 + 载这个文件系统，例如用:: + + mount -t debugfs none /sys/kernel/debug + + 可以从/sys/kernel/debug/ipoib/ib0_mcg等文件中获得关于多播组的统计数据。 + + 这个选项对性能的影响可以忽略不计，所以在正常运行时，在debug_level设置为 + 0的情况下启用这个选项是安全的。 + + CONFIG_INFINIBAND_IPOIB_DEBUG_DATA当data_debug_level设置为1时，可以 + 在数据路径中启用更多的调试输出。 然而，即使禁用输出，启用这个配置选项也 + 会影响性能，因为它在快速路径中增加了测试。 + +引用 +==== + + 在InfiniBand上传输IP（IPoIB）（RFC 4391）。 + http://ietf.org/rfc/rfc4391.txt + + infiniband上的IP:上的IP架构（RFC 4392）。 + http://ietf.org/rfc/rfc4392.txt + + infiniband上的IP: 连接模式 (RFC 4755) + http://ietf.org/rfc/rfc4755.txt -- cgit v1.2.3 From e7c640961a2efa93979128645172db7ce26a8d87 Mon Sep 17 00:00:00 2001 From: Yanteng Si Date: Fri, 6 Aug 2021 10:58:51 +0800 Subject: docs/zh_CN: add infiniband opa_vnic translation Translate Documentation/infiniband/opa_vnic.rst into Chinese. Signed-off-by: Yanteng Si Reviewed-by: Alex Shi Reviewed-by: Puyu Wang Link: https://lore.kernel.org/r/828550a6fb7fded8172c123c37d4c643d2593e53.1628218477.git.siyanteng@loongson.cn Signed-off-by: Jonathan Corbet --- .../translations/zh_CN/infiniband/index.rst | 2 +- .../translations/zh_CN/infiniband/opa_vnic.rst | 156 +++++++++++++++++++++ 2 files changed, 157 insertions(+), 1 deletion(-) create mode 100644 Documentation/translations/zh_CN/infiniband/opa_vnic.rst (limited to 'Documentation') diff --git a/Documentation/translations/zh_CN/infiniband/index.rst b/Documentation/translations/zh_CN/infiniband/index.rst index da5e2821f767..a933e3c6981d 100644 --- a/Documentation/translations/zh_CN/infiniband/index.rst +++ b/Documentation/translations/zh_CN/infiniband/index.rst @@ -24,10 +24,10 @@ infiniband core_locking ipoib + opa_vnic TODOLIST: - opa_vnic sysfs tag_matching user_mad diff --git a/Documentation/translations/zh_CN/infiniband/opa_vnic.rst b/Documentation/translations/zh_CN/infiniband/opa_vnic.rst new file mode 100644 index 000000000000..12b147fbf792 --- /dev/null +++ b/Documentation/translations/zh_CN/infiniband/opa_vnic.rst @@ -0,0 +1,156 @@ +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/infiniband/opa_vnic.rst + +:翻译: + + 司延腾 Yanteng Si + +:校译: + + 王普宇 Puyu Wang + 时奎亮 Alex Shi + +.. _cn_infiniband_opa_vnic: + +============================================= +英特尔全路径（OPA）虚拟网络接口控制器（VNIC） +============================================= + +英特尔全路径（OPA）虚拟网络接口控制器（VNIC）功能通过封装HFI节点之间的以 +太网数据包，支持Omni-Path结构上的以太网功能。 + +体系结构 +======== + +Omni-Path封装的以太网数据包的交换模式涉及Omni-Path结构拓扑上覆盖的一个或 +多个虚拟以太网交换机。Omni-Path结构上的HFI节点的一个子集被允许在特定的虚 +拟以太网交换机上交换封装的以太网数据包。虚拟以太网交换机是通过配置结构上的 +HFI节点实现的逻辑抽象，用于生成和处理报头。在最简单的配置中，整个结构的所有 +HFI节点通过一个虚拟以太网交换机交换封装的以太网数据包。一个虚拟以太网交换机， +实际上是一个独立的以太网网络。该配置由以太网管理器（EM）执行，它是可信的结 +构管理器（FM）应用程序的一部分。HFI节点可以有多个VNIC，每个连接到不同的虚 +拟以太网交换机。下图介绍了两个虚拟以太网交换机与两个HFI节点的情况:: + + +-------------------+ + | 子网/ | + | 以太网 | + | 管理 | + +-------------------+ + / / + / / + / / + / / + +-----------------------------+ +------------------------------+ + | 虚拟以太网切换 | | 虚拟以太网切换 | + | +---------+ +---------+ | | +---------+ +---------+ | + | | VPORT | | VPORT | | | | VPORT | | VPORT | | + +--+---------+----+---------+-+ +-+---------+----+---------+---+ + | \ / | + | \ / | + | \/ | + | / \ | + | / \ | + +-----------+------------+ +-----------+------------+ + | VNIC | VNIC | | VNIC | VNIC | + +-----------+------------+ +-----------+------------+ + | HFI | | HFI | + +------------------------+ +------------------------+ + + +Omni-Path封装的以太网数据包格式如下所述。 + +==================== ================================ +位 域 +==================== ================================ +Quad Word 0: +0-19 SLID (低20位) +20-30 长度 (以四字为单位) +31 BECN 位 +32-51 DLID (低20位) +52-56 SC (服务级别) +57-59 RC (路由控制) +60 FECN 位 +61-62 L2 (=10, 16B 格式) +63 LT (=1, 链路传输头 Flit) + +Quad Word 1: +0-7 L4 type (=0x78 ETHERNET) +8-11 SLID[23:20] +12-15 DLID[23:20] +16-31 PKEY +32-47 熵 +48-63 保留 + +Quad Word 2: +0-15 保留 +16-31 L4 头 +32-63 以太网数据包 + +Quad Words 3 to N-1: +0-63 以太网数据包 (pad拓展) + +Quad Word N (last): +0-23 以太网数据包 (pad拓展) +24-55 ICRC +56-61 尾 +62-63 LT (=01, 链路传输尾 Flit) +==================== ================================ + +以太网数据包在传输端被填充，以确保VNIC OPA数据包是四字对齐的。“尾”字段 +包含填充的字节数。在接收端，“尾”字段被读取，在将数据包向上传递到网络堆 +栈之前，填充物被移除（与ICRC、尾和OPA头一起）。 + +L4头字段包含VNIC端口所属的虚拟以太网交换机ID。在接收端，该字段用于将收 +到的VNIC数据包去多路复用到不同的VNIC端口。 + +驱动设计 +======== + +英特尔OPA VNIC的软件设计如下图所示。OPA VNIC功能有一个依赖于硬件的部分 +和一个独立于硬件的部分。 + +对IB设备分配和释放RDMA netdev设备的支持已经被加入。RDMA netdev支持与 +网络堆栈的对接，从而创建标准的网络接口。OPA_VNIC是一个RDMA netdev设备 +类型。 + +依赖于HW的VNIC功能是HFI1驱动的一部分。它实现了分配和释放OPA_VNIC RDMA +netdev的动作。它涉及VNIC功能的HW资源分配/管理。它与网络堆栈接口并实现所 +需的net_device_ops功能。它在传输路径中期待Omni-Path封装的以太网数据包， +并提供对它们的HW访问。在将数据包向上传递到网络堆栈之前，它把Omni-Path头 +从接收的数据包中剥离。它还实现了RDMA netdev控制操作。 + +OPA VNIC模块实现了独立于硬件的VNIC功能。它由两部分组成。VNIC以太网管理 +代理（VEMA）作为一个IB客户端向IB核心注册，并与IB MAD栈接口。它与以太网 +管理器（EM）和VNIC netdev交换管理信息。VNIC netdev部分分配和释放OPA_VNIC +RDMA netdev设备。它在需要时覆盖由依赖HW的VNIC驱动设置的net_device_ops函数， +以适应任何控制操作。它还处理以太网数据包的封装，在传输路径中使用Omni-Path头。 +对于每个VNIC接口，封装所需的信息是由EM通过VEMA MAD接口配置的。它还通过调用 +RDMA netdev控制操作将任何控制信息传递给依赖于HW的驱动程序:: + + +-------------------+ +----------------------+ + | | | Linux | + | IB MAD | | 网络 | + | | | 栈 | + +-------------------+ +----------------------+ + | | | + | | | + +----------------------------+ | + | | | + | OPA VNIC 模块 | | + | (OPA VNIC RDMA Netdev | | + | & EMA 函数) | | + | | | + +----------------------------+ | + | | + | | + +------------------+ | + | IB 核心 | | + +------------------+ | + | | + | | + +--------------------------------------------+ + | | + | HFI1 驱动和 VNIC 支持 | + | | + +--------------------------------------------+ -- cgit v1.2.3 From ccbad6a5216bd45a725feeafab4c05744538e0c9 Mon Sep 17 00:00:00 2001 From: Yanteng Si Date: Fri, 6 Aug 2021 10:58:52 +0800 Subject: docs/zh_CN: add infiniband sysfs translation Translate Documentation/infiniband/sysfs.rst into Chinese. Signed-off-by: Yanteng Si Reviewed-by: Alex Shi Reviewed-by: Puyu Wang Link: https://lore.kernel.org/r/dbd542628b71160f7bddd33a76cb77b127a9b826.1628218477.git.siyanteng@loongson.cn Signed-off-by: Jonathan Corbet --- .../translations/zh_CN/infiniband/index.rst | 2 +- .../translations/zh_CN/infiniband/sysfs.rst | 21 +++++++++++++++++++++ 2 files changed, 22 insertions(+), 1 deletion(-) create mode 100644 Documentation/translations/zh_CN/infiniband/sysfs.rst (limited to 'Documentation') diff --git a/Documentation/translations/zh_CN/infiniband/index.rst b/Documentation/translations/zh_CN/infiniband/index.rst index a933e3c6981d..1d208d50b0c2 100644 --- a/Documentation/translations/zh_CN/infiniband/index.rst +++ b/Documentation/translations/zh_CN/infiniband/index.rst @@ -25,10 +25,10 @@ infiniband core_locking ipoib opa_vnic + sysfs TODOLIST: - sysfs tag_matching user_mad user_verbs diff --git a/Documentation/translations/zh_CN/infiniband/sysfs.rst b/Documentation/translations/zh_CN/infiniband/sysfs.rst new file mode 100644 index 000000000000..e9a48b0b2ba6 --- /dev/null +++ b/Documentation/translations/zh_CN/infiniband/sysfs.rst @@ -0,0 +1,21 @@ +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/infiniband/sysfs.rst + +:翻译: + + 司延腾 Yanteng Si + +:校译: + + 王普宇 Puyu Wang + 时奎亮 Alex Shi + +.. _cn_infiniband_sysfs: + +========= +Sysfs文件 +========= + +sysfs接口已移至 +Documentation/ABI/stable/sysfs-class-infiniband. -- cgit v1.2.3 From cc420b883b1fa69990d6b44ebc91831066eb6bf3 Mon Sep 17 00:00:00 2001 From: Yanteng Si Date: Fri, 6 Aug 2021 10:58:53 +0800 Subject: docs/zh_CN: add infiniband tag_matching translation Translate Documentation/infiniband/tag_matching.rst into Chinese. Signed-off-by: Yanteng Si Reviewed-by: Alex Shi Reviewed-by: Puyu Wang Link: https://lore.kernel.org/r/eaed122a0e5d0e3312cf5a495022a9d0be42a831.1628218477.git.siyanteng@loongson.cn Signed-off-by: Jonathan Corbet --- .../translations/zh_CN/infiniband/index.rst | 2 +- .../translations/zh_CN/infiniband/tag_matching.rst | 63 ++++++++++++++++++++++ 2 files changed, 64 insertions(+), 1 deletion(-) create mode 100644 Documentation/translations/zh_CN/infiniband/tag_matching.rst (limited to 'Documentation') diff --git a/Documentation/translations/zh_CN/infiniband/index.rst b/Documentation/translations/zh_CN/infiniband/index.rst index 1d208d50b0c2..c273088b8686 100644 --- a/Documentation/translations/zh_CN/infiniband/index.rst +++ b/Documentation/translations/zh_CN/infiniband/index.rst @@ -26,10 +26,10 @@ infiniband ipoib opa_vnic sysfs + tag_matching TODOLIST: - tag_matching user_mad user_verbs diff --git a/Documentation/translations/zh_CN/infiniband/tag_matching.rst b/Documentation/translations/zh_CN/infiniband/tag_matching.rst new file mode 100644 index 000000000000..19b99587b862 --- /dev/null +++ b/Documentation/translations/zh_CN/infiniband/tag_matching.rst @@ -0,0 +1,63 @@ +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/infiniband/tag_matching.rst + +:翻译: + + 司延腾 Yanteng Si + +:校译: + + 王普宇 Puyu Wang + 时奎亮 Alex Shi + +.. _cn_infiniband_tag_matching: + +============ +标签匹配逻辑 +============ + +MPI标准定义了一套规则，称为标签匹配，用于将源发送操作与目的接收匹配。以下参数必 +须与以下源和目的参数相匹配: + +* 沟通者 +* 用户标签--通配符(wild card)可由接收方指定 +* 来源等级--通配符可由接收方指定 +* 目的地等级 – wild + +排序规则要求，当一对以上的发送和接收消息信封可能匹配时，包括最早发布-发送和最早 +发布-接收的一对是必须用来满足匹配操作的一对。然而，这并不意味着标签是按照它们被 +创建的顺序消耗的，例如，如果早期的标签不能用来满足匹配规则，那么后来生成的标签 +可能被消耗。 + +当消息从发送方发送到接收方时，通信库可能试图在相应的匹配接收被发布之后或之前处 +理该操作。如果匹配的接收被发布，这就是一个预期的消息，否则就被称为一个意外的消 +息。实现时经常为这两种不同的匹配实例使用不同的匹配方案。 + +为了减少MPI库的内存占用，MPI实现通常使用两种不同的协议来实现这一目的: + +1. Eager协议--当发送方处理完发送时，完整的信息就会被发送。在send_cq中会收到 +一个完成发送的通知，通知缓冲区可以被重新使用。 + +2. Rendezvous协议--发送方在第一次通知接收方时发送标签匹配头，也许还有一部分 +数据。当相应的缓冲区被发布时，响应者将使用头中的信息，直接向匹配的缓冲区发起 +RDMA读取操作。为了使缓冲区得到重用，需要收到一个fin消息。 + +标签匹配的实现 +============== + +使用的匹配对象有两种类型，即发布的接收列表和意外消息列表。应用程序通过调用发布 +的接收列表中的MPI接收例程发布接收缓冲区，并使用MPI发送例程发布发送消息。发布的 +接收列表的头部可以由硬件来维护，而软件则要对这个列表进行跟踪。 + +当发送开始并到达接收端时，如果没有为这个到达的消息预先发布接收，它将被传递给软 +件并被放在意外（unexpect）消息列表中。否则，将对该匹配进行处理，包括交会处理， +如果合适的话，将数据传送到指定的接收缓冲区。这允许接收方MPI标签匹配与计算重叠。 + +当一个接收信息被发布时，通信库将首先检查软件的意外信息列表，以寻找一个匹配的接 +收信息。如果找到一个匹配的，数据就会被送到用户缓冲区，使用一个软件控制的协议。 +UCX的实现根据数据大小，使用急切或交会协议。如果没有找到匹配，整个预置的接收列 +表由硬件维护，并且有空间在这个列表中增加一个预置的接收，这个接收被传递给硬件。 +软件要对这个列表进行跟踪，以帮助处理MPI取消操作。此外，由于硬件和软件在标签匹 +配操作方面预计不会紧密同步，这个影子列表被用来检测预先发布的接收被传递到硬件的 +情况，因为匹配的意外消息正在从硬件传递到软件。 -- cgit v1.2.3 From 0265e6ee2c5868a3efb7e9b49ccbdb51fd1c7f27 Mon Sep 17 00:00:00 2001 From: Yanteng Si Date: Fri, 6 Aug 2021 10:58:54 +0800 Subject: docs/zh_CN: add infiniband user_mad translation Translate Documentation/infiniband/user_mad.rst into Chinese. Signed-off-by: Yanteng Si Reviewed-by: Alex Shi Reviewed-by: Puyu Wang Link: https://lore.kernel.org/r/8859ef2b40b380d7db7548f2e6a2d6fd5397062d.1628218477.git.siyanteng@loongson.cn Signed-off-by: Jonathan Corbet --- .../translations/zh_CN/infiniband/index.rst | 2 +- .../translations/zh_CN/infiniband/user_mad.rst | 164 +++++++++++++++++++++ 2 files changed, 165 insertions(+), 1 deletion(-) create mode 100644 Documentation/translations/zh_CN/infiniband/user_mad.rst (limited to 'Documentation') diff --git a/Documentation/translations/zh_CN/infiniband/index.rst b/Documentation/translations/zh_CN/infiniband/index.rst index c273088b8686..55645171a675 100644 --- a/Documentation/translations/zh_CN/infiniband/index.rst +++ b/Documentation/translations/zh_CN/infiniband/index.rst @@ -27,10 +27,10 @@ infiniband opa_vnic sysfs tag_matching + user_mad TODOLIST: - user_mad user_verbs .. only:: subproject and html diff --git a/Documentation/translations/zh_CN/infiniband/user_mad.rst b/Documentation/translations/zh_CN/infiniband/user_mad.rst new file mode 100644 index 000000000000..d9ab2edfb559 --- /dev/null +++ b/Documentation/translations/zh_CN/infiniband/user_mad.rst @@ -0,0 +1,164 @@ +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/infiniband/user_mad.rst + +:翻译: + + 司延腾 Yanteng Si + +:校译: + + 王普宇 Puyu Wang + 时奎亮 Alex Shi + +.. _cn_infiniband_user_mad: + +=============== +用户空间MAD访问 +=============== + +设备文件 +======== + + 每个InfiniBand设备的每个端口都有一个“umad”设备和一个“issm”设备连接。 + 例如，一个双端口的HCA将有两个umad设备和两个issm设备，而一个交换机将 + 有每个类型的一个设备（对于交换机端口0）。 + +创建MAD代理 +=========== + + 一个MAD代理可以通过填写一个结构体ib_user_mad_reg_req来创建，然后在 + 适当的设备文件的文件描述符上调用IB_USER_MAD_REGISTER_AGENT ioctl。 + 如果注册请求成功，结构体中会返回一个32位的ID。比如说:: + + struct ib_user_mad_reg_req req = { /* ... */ }; + ret = ioctl(fd, IB_USER_MAD_REGISTER_AGENT, (char *) &req); + if (!ret) + my_agent = req.id; + else + perror("agent register"); + + 代理可以通过IB_USER_MAD_UNREGISTER_AGENT ioctl取消注册。另外，所有 + 通过文件描述符注册的代理在描述符关闭时将被取消注册。 + + 2014 + 现在提供了一个新的注册IOctl，允许在注册时提供额外的字段。这个注册 + 调用的用户隐含了对pkey_index的使用（见下文）。现在提供了一个新的 + 注册IOctl，允许在注册时提供额外的字段。这个注册调用的用户隐含了对 + pkey_index的使用（见下文）。 + +接收MADs +======== + + 使用read()接收MAD。现在接收端支持RMPP。传给read()的缓冲区必须至少是 + 一个struct ib_user_mad + 256字节。比如说: + + 如果传递的缓冲区不足以容纳收到的MAD（RMPP），errno被设置为ENOSPC，需 + 要的缓冲区长度被设置在mad.length中。 + + 正常MAD(非RMPP)的读取示例:: + + struct ib_user_mad *mad; + mad = malloc(sizeof *mad + 256); + ret = read(fd, mad, sizeof *mad + 256); + if (ret != sizeof mad + 256) { + perror("read"); + free(mad); + } + + RMPP读取示例:: + + struct ib_user_mad *mad; + mad = malloc(sizeof *mad + 256); + ret = read(fd, mad, sizeof *mad + 256); + if (ret == -ENOSPC)) { + length = mad.length; + free(mad); + mad = malloc(sizeof *mad + length); + ret = read(fd, mad, sizeof *mad + length); + } + if (ret < 0) { + perror("read"); + free(mad); + } + + 除了实际的MAD内容外，其他结构体ib_user_mad字段将被填入收到的MAD的信 + 息。例如，远程LID将在mad.lid中。 + + 如果发送超时，将产生一个接收，mad.status设置为ETIMEDOUT。否则，当一个 + MAD被成功接收后，mad.status将是0。 + + poll()/select()可以用来等待一个MAD可以被读取。 + + poll()/select()可以用来等待，直到可以读取一个MAD。 + +发送MADs +======== + + MADs是用write()发送的。发送的代理ID应该填入MAD的id字段，目的地LID应该 + 填入lid字段，以此类推。发送端确实支持RMPP，所以可以发送任意长度的MAD。 + 比如说:: + + struct ib_user_mad *mad; + + mad = malloc(sizeof *mad + mad_length); + + /* fill in mad->data */ + + mad->hdr.id = my_agent; /* req.id from agent registration */ + mad->hdr.lid = my_dest; /* in network byte order... */ + /* etc. */ + + ret = write(fd, &mad, sizeof *mad + mad_length); + if (ret != sizeof *mad + mad_length) + perror("write"); + +交换IDs +======= + + umad设备的用户可以在发送的MAD中使用交换ID字段的低32位（也就是网络字节顺序中 + 最小有效的一半字段）来匹配请求/响应对。上面的32位是保留给内核使用的，在发送 + MAD之前会被改写。 + +P_Key索引处理 +============= + + 旧的ib_umad接口不允许为发送的MAD设置P_Key索引，也没有提供获取接收的MAD的 + P_Key索引的方法。一个带有pkey_index成员的struct ib_user_mad_hdr的新布局已 + 经被定义；然而，为了保持与旧的应用程序的二进制兼容性，除非在文件描述符被用于 + 其他用途之前调用IB_USER_MAD_ENABLE_PKEY或IB_USER_MAD_REGISTER_AGENT2 ioctl + 之一，否则不会使用这种新布局。 + + 在2008年9月，IB_USER_MAD_ABI_VERSION将被增加到6，默认使用新的ib_user_mad_hdr + 结构布局，并且IB_USER_MAD_ENABLE_PKEY ioctl将被删除。 + +设置IsSM功能位 +============== + + 要为一个端口设置IsSM功能位，只需打开相应的issm设备文件。如果IsSM位已经被设置，那 + 么打开调用将阻塞，直到该位被清除（或者如果O_NONBLOCK标志被传递给open()，则立即返 + 回，errno设置为EAGAIN）。当issm文件被关闭时，IsSM位将被清除。在issm文件上不能进 + 行任何读、写或其他操作。 + +/dev文件 +======== + +为了用 udev自动创建相应的字符设备文件，一个类似:: + + KERNEL=="umad*", NAME="infiniband/%k" + KERNEL=="issm*", NAME="infiniband/%k" + + 的规则可以被使用。它将创建节点的名字:: + + /dev/infiniband/umad0 + /dev/infiniband/issm0 + + 为第一个端口，以此类推。与这些设备相关的infiniband设备和端口可以从以下文件中确定:: + + /sys/class/infiniband_mad/umad0/ibdev + /sys/class/infiniband_mad/umad0/port + + 和:: + + /sys/class/infiniband_mad/issm0/ibdev + /sys/class/infiniband_mad/issm0/port -- cgit v1.2.3 From 4d488433dc4071fd55fa1d65f16f81dd149c9cda Mon Sep 17 00:00:00 2001 From: Yanteng Si Date: Fri, 6 Aug 2021 10:58:55 +0800 Subject: docs/zh_CN: add infiniband user_verbs translation Translate Documentation/infiniband/user_verbs.rst into Chinese. Signed-off-by: Yanteng Si Reviewed-by: Alex Shi Reviewed-by: Puyu Wang Link: https://lore.kernel.org/r/b7c1577cf9758943bff933c46200c7dff1e1c6e0.1628218477.git.siyanteng@loongson.cn Signed-off-by: Jonathan Corbet --- .../translations/zh_CN/infiniband/index.rst | 3 +- .../translations/zh_CN/infiniband/user_verbs.rst | 72 ++++++++++++++++++++++ 2 files changed, 73 insertions(+), 2 deletions(-) create mode 100644 Documentation/translations/zh_CN/infiniband/user_verbs.rst (limited to 'Documentation') diff --git a/Documentation/translations/zh_CN/infiniband/index.rst b/Documentation/translations/zh_CN/infiniband/index.rst index 55645171a675..5634cc48379f 100644 --- a/Documentation/translations/zh_CN/infiniband/index.rst +++ b/Documentation/translations/zh_CN/infiniband/index.rst @@ -28,10 +28,9 @@ infiniband sysfs tag_matching user_mad + user_verbs -TODOLIST: - user_verbs .. only:: subproject and html diff --git a/Documentation/translations/zh_CN/infiniband/user_verbs.rst b/Documentation/translations/zh_CN/infiniband/user_verbs.rst new file mode 100644 index 000000000000..970bc1a4e396 --- /dev/null +++ b/Documentation/translations/zh_CN/infiniband/user_verbs.rst @@ -0,0 +1,72 @@ +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/infiniband/user_verbs.rst + +:翻译: + + 司延腾 Yanteng Si + +:校译: + + 王普宇 Puyu Wang + 时奎亮 Alex Shi + +.. _cn_infiniband_user_verbs: + +================= +用户空间verbs访问 +================= + + ib_uverbs模块，通过启用CONFIG_INFINIBAND_USER_VERBS构建，使用户空间 + 通过“verbs”直接访问IB硬件，如InfiniBand架构规范第11章所述。 + + 要使用verbs，需要libibverbs库，可从https://github.com/linux-rdma/rdma-core。 + libibverbs包含一个独立于设备的API，用于使用ib_uverbs接口。libibverbs + 还需要为你的InfiniBand硬件提供适当的独立于设备的内核和用户空间驱动。例如， + 要使用Mellanox HCA，你需要安装ib_mthca内核模块和libmthca用户空间驱动。 + +用户-内核通信 +============= + + 用户空间通过/dev/infiniband/uverbsN字符设备与内核进行慢速路径、资源管理 + 操作的通信。快速路径操作通常是通过直接写入硬件寄存器mmap()到用户空间来完成 + 的，没有系统调用或上下文切换到内核。 + + 命令是通过在这些设备文件上的write()s发送给内核的。ABI在 + drivers/infiniband/include/ib_user_verbs.h中定义。需要内核响应的命令的结 + 构包含一个64位字段，用来传递一个指向输出缓冲区的指针。状态作为write()系统调 + 用的返回值被返回到用户空间。 + +资源管理 +======== + + 由于所有IB资源的创建和销毁都是通过文件描述符传递的命令完成的，所以内核可以跟 + 踪那些被附加到给定用户空间上下文的资源。ib_uverbs模块维护着idr表，用来在 + 内核指针和不透明的用户空间句柄之间进行转换，这样内核指针就不会暴露给用户空间， + 而用户空间也无法欺骗内核去跟踪一个假的指针。 + + 这也允许内核在一个进程退出时进行清理，并防止一个进程触及另一个进程的资源。 + +内存固定 +======== + + 直接的用户空间I/O要求与作为潜在I/O目标的内存区域保持在同一物理地址上。ib_uverbs + 模块通过get_user_pages()和put_page()调用来管理内存区域的固定和解除固定。它还核 + 算进程的pinned_vm中被固定的内存量，并检查非特权进程是否超过其RLIMIT_MEMLOCK限制。 + + 被多次固定的页面在每次被固定时都会被计数，所以pinned_vm的值可能会高估一个进程所 + 固定的页面数量。 + +/dev文件 +======== + + 要想用udev自动创建适当的字符设备文件，可以采用如下规则:: + + KERNEL=="uverbs*", NAME="infiniband/%k" + + 可以使用。 这将创建设备节点，名为:: + + /dev/infiniband/uverbs0 + + 等等。由于InfiniBand的用户空间verbs对于非特权进程来说应该是安全的，因此在udev规 + 则中加入适当的MODE或GROUP可能是有用的。 -- cgit v1.2.3 From 27f373cb5c9805d1e921ec9c5faf738ecf3fd989 Mon Sep 17 00:00:00 2001 From: Jisheng Zhang Date: Thu, 5 Aug 2021 00:27:39 +0800 Subject: Documentation/features/vm: riscv supports THP now After commit e88b333142e4 ("riscv: mm: add THP support on 64-bit"), riscv can support THP. Signed-off-by: Jisheng Zhang Link: https://lore.kernel.org/r/20210805002739.23f44d2d@xhacker Signed-off-by: Jonathan Corbet --- Documentation/features/vm/THP/arch-support.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/features/vm/THP/arch-support.txt b/Documentation/features/vm/THP/arch-support.txt index e8238cb2a4da..7dbd6967b37e 100644 --- a/Documentation/features/vm/THP/arch-support.txt +++ b/Documentation/features/vm/THP/arch-support.txt @@ -22,7 +22,7 @@ | openrisc: | .. | | parisc: | TODO | | powerpc: | ok | - | riscv: | TODO | + | riscv: | ok | | s390: | ok | | sh: | .. | | sparc: | ok | -- cgit v1.2.3 From 191cf329f109df86d93f7782c3289b50bca15260 Mon Sep 17 00:00:00 2001 From: Federico Vaga Date: Sat, 31 Jul 2021 10:55:13 +0200 Subject: doc: align Italian translation Translation for the following patches commit 0ca0d55526d3 ("docs/core-api: Consistent code style") commit 9912d0bb9dee ("docs: process: submitting-patches.rst: avoid using ReST :doc:`foo` markup") commit 6349469a4f3c ("Documentation/submitting-patches: Document RESEND tag on patches") commit dbbe7c962c3a ("docs: networking: drop special stable handling") commit 7f3f7bfbbe02 ("docs: kernel-hacking: hacking.rst: avoid using ReST :doc:`foo` markup") commit 6ab0493dfc62 ("deprecated.rst: Include details on "no_hash_pointers" ") commit 77167b966b7e ("docs: submitting-patches: clarify the role of LKML ") Signed-off-by: Federico Vaga Link: https://lore.kernel.org/r/20210731085513.11820-1-federico.vaga@vaga.pv.it Signed-off-by: Jonathan Corbet --- .../it_IT/core-api/symbol-namespaces.rst | 26 +++++----- .../translations/it_IT/kernel-hacking/hacking.rst | 4 +- .../translations/it_IT/process/deprecated.rst | 8 +-- .../it_IT/process/stable-kernel-rules.rst | 6 --- .../it_IT/process/submitting-patches.rst | 57 ++++++++++++---------- 5 files changed, 51 insertions(+), 50 deletions(-) (limited to 'Documentation') diff --git a/Documentation/translations/it_IT/core-api/symbol-namespaces.rst b/Documentation/translations/it_IT/core-api/symbol-namespaces.rst index aa851a57a4b0..42f5d04e38ec 100644 --- a/Documentation/translations/it_IT/core-api/symbol-namespaces.rst +++ b/Documentation/translations/it_IT/core-api/symbol-namespaces.rst @@ -42,15 +42,15 @@ nomi: EXPORT_SYMBOL_NS() ed EXPORT_SYMBOL_NS_GPL(). Queste macro richiedono un argomento aggiuntivo: lo spazio dei nomi. Tenete presente che per via dell'espansione delle macro questo argomento deve essere un simbolo di preprocessore. Per esempio per esportare il -simbolo `usb_stor_suspend` nello spazio dei nomi `USB_STORAGE` usate:: +simbolo ``usb_stor_suspend`` nello spazio dei nomi ``USB_STORAGE`` usate:: EXPORT_SYMBOL_NS(usb_stor_suspend, USB_STORAGE); Di conseguenza, nella tabella dei simboli del kernel ci sarà una voce -rappresentata dalla struttura `kernel_symbol` che avrà il campo -`namespace` (spazio dei nomi) impostato. Un simbolo esportato senza uno spazio -dei nomi avrà questo campo impostato a `NULL`. Non esiste uno spazio dei nomi -di base. Il programma `modpost` e il codice in kernel/module.c usano lo spazio +rappresentata dalla struttura ``kernel_symbol`` che avrà il campo +``namespace`` (spazio dei nomi) impostato. Un simbolo esportato senza uno spazio +dei nomi avrà questo campo impostato a ``NULL``. Non esiste uno spazio dei nomi +di base. Il programma ``modpost`` e il codice in kernel/module.c usano lo spazio dei nomi, rispettivamente, durante la compilazione e durante il caricamento di un modulo. @@ -65,7 +65,7 @@ ed EXPORT_SYMBOL_GPL() che non specificano esplicitamente uno spazio dei nomi. Ci sono molti modi per specificare questo simbolo di preprocessore e il loro uso dipende dalle preferenze del manutentore di un sottosistema. La prima -possibilità è quella di definire il simbolo nel `Makefile` del sottosistema. +possibilità è quella di definire il simbolo nel ``Makefile`` del sottosistema. Per esempio per esportare tutti i simboli definiti in usb-common nello spazio dei nomi USB_COMMON, si può aggiungere la seguente linea in drivers/usb/common/Makefile:: @@ -97,7 +97,7 @@ USB_STORAGE usando la seguente dichiarazione:: MODULE_IMPORT_NS(USB_STORAGE); -Questo creerà un'etichetta `modinfo` per ogni spazio dei nomi +Questo creerà un'etichetta ``modinfo`` per ogni spazio dei nomi importato. Un risvolto di questo fatto è che gli spazi dei nomi importati da un modulo possono essere ispezionati tramite modinfo:: @@ -116,7 +116,7 @@ mancanti. 4. Caricare moduli che usano simboli provenienti da spazi dei nomi ================================================================== -Quando un modulo viene caricato (per esempio usando `insmod`), il kernel +Quando un modulo viene caricato (per esempio usando ``insmod``), il kernel verificherà la disponibilità di ogni simbolo usato e se lo spazio dei nomi che potrebbe contenerli è stato importato. Il comportamento di base del kernel è di rifiutarsi di caricare quei moduli che non importano tutti gli spazi dei @@ -144,22 +144,22 @@ Lo scenario tipico di chi scrive un modulo potrebbe essere:: - scrivere codice che dipende da un simbolo appartenente ad uno spazio dei nomi non importato - - eseguire `make` + - eseguire ``make`` - aver notato un avviso da modpost che parla di un'importazione mancante - - eseguire `make nsdeps` per aggiungere import nel posto giusto + - eseguire ``make nsdeps`` per aggiungere import nel posto giusto Per i manutentori di sottosistemi che vogliono aggiungere uno spazio dei nomi, -l'approccio è simile. Di nuovo, eseguendo `make nsdeps` aggiungerà le +l'approccio è simile. Di nuovo, eseguendo ``make nsdeps`` aggiungerà le importazioni mancanti nei moduli inclusi nel kernel:: - spostare o aggiungere simboli ad uno spazio dei nomi (per esempio usando EXPORT_SYMBOL_NS()) - - eseguire `make` (preferibilmente con allmodconfig per coprire tutti + - eseguire ``make`` (preferibilmente con allmodconfig per coprire tutti i moduli del kernel) - aver notato un avviso da modpost che parla di un'importazione mancante - - eseguire `make nsdeps` per aggiungere import nel posto giusto + - eseguire ``make nsdeps`` per aggiungere import nel posto giusto Potete anche eseguire nsdeps per moduli esterni. Solitamente si usa così:: diff --git a/Documentation/translations/it_IT/kernel-hacking/hacking.rst b/Documentation/translations/it_IT/kernel-hacking/hacking.rst index f6beb385b4ac..b4ea00f1b583 100644 --- a/Documentation/translations/it_IT/kernel-hacking/hacking.rst +++ b/Documentation/translations/it_IT/kernel-hacking/hacking.rst @@ -634,7 +634,7 @@ Definita in ``include/linux/export.h`` Questa è una variate di `EXPORT_SYMBOL()` che permette di specificare uno spazio dei nomi. Lo spazio dei nomi è documentato in -:doc:`../core-api/symbol-namespaces` +Documentation/translations/it_IT/core-api/symbol-namespaces.rst. :c:func:`EXPORT_SYMBOL_NS_GPL()` -------------------------------- @@ -643,7 +643,7 @@ Definita in ``include/linux/export.h`` Questa è una variate di `EXPORT_SYMBOL_GPL()` che permette di specificare uno spazio dei nomi. Lo spazio dei nomi è documentato in -:doc:`../core-api/symbol-namespaces` +Documentation/translations/it_IT/core-api/symbol-namespaces.rst. Procedure e convenzioni ======================= diff --git a/Documentation/translations/it_IT/process/deprecated.rst b/Documentation/translations/it_IT/process/deprecated.rst index 07c79d4bafca..987f45ee1804 100644 --- a/Documentation/translations/it_IT/process/deprecated.rst +++ b/Documentation/translations/it_IT/process/deprecated.rst @@ -183,9 +183,11 @@ di Linus: affrontare il giudizio di Linus, allora forse potrai usare "%px", assicurandosi anche di averne il permesso. -Infine, sappi che un cambio in favore di "%p" con hash `non verrà -accettato -`_. +Potete disabilitare temporaneamente l'hashing di "%p" nel caso in cui questa +funzionalità vi sia d'ostacolo durante una sessione di debug. Per farlo +aggiungete l'opzione di debug "`no_hash_pointers +`_" alla +riga di comando del kernel. Vettori a dimensione variabile (VLA) ------------------------------------ diff --git a/Documentation/translations/it_IT/process/stable-kernel-rules.rst b/Documentation/translations/it_IT/process/stable-kernel-rules.rst index 283d62541c4f..83f48afe48b9 100644 --- a/Documentation/translations/it_IT/process/stable-kernel-rules.rst +++ b/Documentation/translations/it_IT/process/stable-kernel-rules.rst @@ -41,12 +41,6 @@ Regole sul tipo di patch che vengono o non vengono accettate nei sorgenti Procedura per sottomettere patch per i sorgenti -stable ------------------------------------------------------- - - Se la patch contiene modifiche a dei file nelle cartelle net/ o drivers/net, - allora seguite le linee guida descritte in - :ref:`Documentation/translations/it_IT/networking/netdev-FAQ.rst `; - ma solo dopo aver verificato al seguente indirizzo che la patch non sia - già in coda: - https://patchwork.kernel.org/bundle/netdev/stable/?state=* - Una patch di sicurezza non dovrebbero essere gestite (solamente) dal processo di revisione -stable, ma dovrebbe seguire le procedure descritte in :ref:`Documentation/translations/it_IT/admin-guide/security-bugs.rst `. diff --git a/Documentation/translations/it_IT/process/submitting-patches.rst b/Documentation/translations/it_IT/process/submitting-patches.rst index ded95048b9a8..458d9d24b9c0 100644 --- a/Documentation/translations/it_IT/process/submitting-patches.rst +++ b/Documentation/translations/it_IT/process/submitting-patches.rst @@ -14,14 +14,15 @@ una certa familiarità col "sistema". Questo testo è una raccolta di suggerimenti che aumenteranno significativamente le probabilità di vedere le vostre patch accettate. -Questo documento contiene un vasto numero di suggerimenti concisi. Per -maggiori dettagli su come funziona il processo di sviluppo del kernel leggete -:doc:`development-process`. -Leggete anche :doc:`submit-checklist` per una lista di punti da -verificare prima di inviare del codice. Se state inviando un driver, -allora leggete anche :doc:`submitting-drivers`; per delle patch +Questo documento contiene un vasto numero di suggerimenti concisi. Per maggiori +dettagli su come funziona il processo di sviluppo del kernel leggete +Documentation/translations/it_IT/process/development-process.rst. Leggete anche +Documentation/translations/it_IT/process/submit-checklist.rst per una lista di +punti da verificare prima di inviare del codice. Se state inviando un driver, +allora leggete anche +Documentation/translations/it_IT/process/submitting-drivers.rst; per delle patch relative alle associazioni per Device Tree leggete -:doc:`submitting-patches`. +Documentation/translations/it_IT/process/submitting-patches.rst. Questa documentazione assume che sappiate usare ``git`` per preparare le patch. Se non siete pratici di ``git``, allora è bene che lo impariate; @@ -193,7 +194,7 @@ ed integrate. --------------------------------------------- Controllate che la vostra patch non violi lo stile del codice, maggiori -dettagli sono disponibili in :ref:`Documentation/translations/it_IT/process/coding-style.rst `. +dettagli sono disponibili in Documentation/translations/it_IT/process/coding-style.rst. Non farlo porta semplicemente a una perdita di tempo da parte dei revisori e voi vedrete la vostra patch rifiutata, probabilmente senza nemmeno essere stata letta. @@ -230,13 +231,13 @@ scripts/get_maintainer.pl può esservi d'aiuto. Se non riuscite a trovare un manutentore per il sottosistema su cui state lavorando, allora Andrew Morton (akpm@linux-foundation.org) sarà la vostra ultima possibilità. -Normalmente, dovreste anche scegliere una lista di discussione a cui inviare -la vostra serie di patch. La lista di discussione linux-kernel@vger.kernel.org -è proprio l'ultima spiaggia, il volume di email su questa lista fa si che -diversi sviluppatori non la seguano. Guardate nel file MAINTAINERS per trovare -la lista di discussione dedicata ad un sottosistema; probabilmente lì la vostra -patch riceverà molta più attenzione. Tuttavia, per favore, non spammate le -liste di discussione che non sono interessate al vostro lavoro. +Normalmente, dovreste anche scegliere una lista di discussione a cui inviare la +vostra serie di patch. La lista di discussione linux-kernel@vger.kernel.org +dovrebbe essere usata per inviare tutte le patch, ma il traffico è tale per cui +diversi sviluppatori la trascurano. Guardate nel file MAINTAINERS per trovare la +lista di discussione dedicata ad un sottosistema; probabilmente lì la vostra +patch riceverà molta più attenzione. Tuttavia, per favore, non spammate le liste +di discussione che non sono interessate al vostro lavoro. Molte delle liste di discussione relative al kernel vengono ospitate su vger.kernel.org; potete trovare un loro elenco alla pagina @@ -257,7 +258,7 @@ embargo potrebbe essere preso in considerazione per dare il tempo alle distribuzioni di prendere la patch e renderla disponibile ai loro utenti; in questo caso, ovviamente, la patch non dovrebbe essere inviata su alcuna lista di discussione pubblica. Leggete anche -:doc:`/admin-guide/security-bugs`. +Documentation/admin-guide/security-bugs.rst. Patch che correggono bachi importanti su un kernel già rilasciato, dovrebbero essere inviate ai manutentori dei kernel stabili aggiungendo la seguente riga:: @@ -266,12 +267,7 @@ essere inviate ai manutentori dei kernel stabili aggiungendo la seguente riga:: nella vostra patch, nell'area dedicata alle firme (notate, NON come destinatario delle e-mail). In aggiunta a questo file, dovreste leggere anche -:ref:`Documentation/translations/it_IT/process/stable-kernel-rules.rst ` - -Tuttavia, notate, che alcuni manutentori di sottosistema preferiscono avere -l'ultima parola su quali patch dovrebbero essere aggiunte ai kernel stabili. -La rete di manutentori, in particolare, non vorrebbe vedere i singoli -sviluppatori aggiungere alle loro patch delle righe come quella sopracitata. +Documentation/translations/it_IT/process/stable-kernel-rules.rst. Se le modifiche hanno effetti sull'interfaccia con lo spazio utente, per favore inviate una patch per le pagine man ai manutentori di suddette pagine (elencati @@ -330,7 +326,7 @@ così la possibilità che il vostro allegato-MIME venga accettato. Eccezione: se il vostro servizio di posta storpia le patch, allora qualcuno potrebbe chiedervi di rinviarle come allegato MIME. -Leggete :doc:`/translations/it_IT/process/email-clients` +Leggete Documentation/translations/it_IT/process/email-clients.rst per dei suggerimenti sulla configurazione del programmi di posta elettronica per l'invio di patch intatte. @@ -351,7 +347,7 @@ richiede molto tempo, e a volte i revisori diventano burberi. Tuttavia, anche in questo caso, rispondete con educazione e concentratevi sul problema che hanno evidenziato. -Leggete :doc:`/translations/it_IT/process/email-clients` per +Leggete Documentation/translations/it_IT/process/email-clients.rst per le raccomandazioni sui programmi di posta elettronica e l'etichetta da usare sulle liste di discussione. @@ -369,6 +365,16 @@ aver inviato le patch correttamente. Aspettate almeno una settimana prima di rinviare le modifiche o sollecitare i revisori - probabilmente anche di più durante la finestra d'integrazione. +Potete anche rinviare la patch, o la serie di patch, dopo un paio di settimane +aggiungendo la parola "RESEND" nel titolo:: + + [PATCH Vx RESEND] sub/sys: Condensed patch summary + +Ma non aggiungete "RESEND" quando state sottomettendo una versione modificata +della vostra patch, o serie di patch - "RESEND" si applica solo alla +sottomissione di patch, o serie di patch, che non hanno subito modifiche +dall'ultima volta che sono state inviate. + Aggiungete PATCH nell'oggetto ----------------------------- @@ -795,8 +801,7 @@ Greg Kroah-Hartman, "Come scocciare un manutentore di un sottosistema" No!!!! Basta gigantesche bombe patch alle persone sulla lista linux-kernel@vger.kernel.org! -Kernel Documentation/translations/it_IT/process/coding-style.rst: - :ref:`Documentation/translations/it_IT/process/coding-style.rst ` +Kernel Documentation/translations/it_IT/process/coding-style.rst. E-mail di Linus Torvalds sul formato canonico di una patch: -- cgit v1.2.3 From 4f3791c3fe277446191f4d0857bd04baf5e6d9bd Mon Sep 17 00:00:00 2001 From: Yang Yang Date: Sat, 31 Jul 2021 01:45:03 -0700 Subject: docs/zh_CN: Add zh_CN/accounting/psi.rst Add translation zh_CN/accounting/psi.rst and zh_CN/accounting/index.rst. Signed-off-by: Yang Yang Reviewed-by: Yanteng Si Link: https://lore.kernel.org/r/20210731084502.571451-1-yang.yang29@zte.com.cn Signed-off-by: Jonathan Corbet --- .../translations/zh_CN/accounting/index.rst | 25 ++++ .../translations/zh_CN/accounting/psi.rst | 155 +++++++++++++++++++++ Documentation/translations/zh_CN/index.rst | 2 +- 3 files changed, 181 insertions(+), 1 deletion(-) create mode 100644 Documentation/translations/zh_CN/accounting/index.rst create mode 100644 Documentation/translations/zh_CN/accounting/psi.rst (limited to 'Documentation') diff --git a/Documentation/translations/zh_CN/accounting/index.rst b/Documentation/translations/zh_CN/accounting/index.rst new file mode 100644 index 000000000000..362e907b41f9 --- /dev/null +++ b/Documentation/translations/zh_CN/accounting/index.rst @@ -0,0 +1,25 @@ +.. SPDX-License-Identifier: GPL-2.0 + +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/accounting/index.rst +:Translator: Yang Yang + +.. _cn_accounting_index.rst: + + +==== +计数 +==== + +.. toctree:: + :maxdepth: 1 + + psi + +Todolist: + + cgroupstats + delay-accounting + taskstats + taskstats-struct diff --git a/Documentation/translations/zh_CN/accounting/psi.rst b/Documentation/translations/zh_CN/accounting/psi.rst new file mode 100644 index 000000000000..a0ddb7bd257c --- /dev/null +++ b/Documentation/translations/zh_CN/accounting/psi.rst @@ -0,0 +1,155 @@ +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/accounting/psi.rst +:Translator: Yang Yang + +.. _cn_psi.rst: + + +================= +PSI——压力阻塞信息 +================= + +:日期: April, 2018 +:作者: Johannes Weiner + +当CPU、memory或IO设备处于竞争状态，业务负载会遭受时延毛刺、吞吐量降低， +及面临OOM的风险。 + +如果没有一种准确的方法度量系统竞争程度，则有两种后果：一种是用户过于节制， +未充分利用系统资源；另一种是过度使用，经常性面临业务中断的风险。 + +psi特性能够识别和量化资源竞争导致的业务中断，及其对复杂负载乃至整个系统在 +时间上的影响。 + +准确度量因资源不足造成的生产力损失，有助于用户基于硬件调整业务负载，或基 +于业务负载配置硬件。 + +psi能够实时的提供相关信息，因此系统可基于psi实现动态的负载管理。如实施 +卸载、迁移、策略性的停止或杀死低优先级或可重启的批处理任务。 + +psi帮助用户实现硬件资源利用率的最大化。同时无需牺牲业务负载健康度，也无需 +面临OOM等造成业务中断的风险。 + +压力接口 +======== + +压力信息可通过/proc/pressure/ --cpu、memory、io文件分别获取。 + +CPU相关信息格式如下： + + some avg10=0.00 avg60=0.00 avg300=0.00 total=0 + +内存和IO相关信息如下： + + some avg10=0.00 avg60=0.00 avg300=0.00 total=0 + full avg10=0.00 avg60=0.00 avg300=0.00 total=0 + +some行代表至少有一个任务阻塞于特定资源的时间占比。 + +full行代表所有非idle任务同时阻塞于特定资源的时间占比。在这种状态下CPU资源 +完全被浪费，相对于正常运行，业务负载由于耗费更多时间等待而受到严重影响。 + +由于此情况严重影响系统性能，因此清楚的识别本情况并与some行所代表的情况区分开， +将有助于分析及提升系统性能。这就是full独立于some行的原因。 + +avg代表阻塞时间占比（百分比），为最近10秒、60秒、300秒内的均值。这样我们 +既可观察到短期事件的影响，也可看到中等及长时间内的趋势。total代表总阻塞 +时间（单位微秒），可用于观察时延毛刺，这种毛刺可能在均值中无法体现。 + +监控压力门限 +============ + +用户可注册触发器，通过poll()监控资源压力是否超过门限。 + +触发器定义：指定时间窗口期内累积阻塞时间的最大值。比如可定义500ms内积累 +100ms阻塞，即触发一次唤醒事件。 + +触发器注册方法：用户打开代表特定资源的psi接口文件，写入门限、时间窗口的值。 +所打开的文件描述符用于等待事件，可使用select()、poll()、epoll()。 +写入信息的格式如下： + +