From d0ac5722dae5f4302bb4ef6df10d0afa718df80b Mon Sep 17 00:00:00 2001 From: Maxime Ripard Date: Thu, 14 Dec 2023 11:09:16 +0100 Subject: drm/todo: Add entry to rename drm_atomic_state The name of the structure drm_atomic_state is confusing. Let's add an entry to our todo list to rename it. Reviewed-by: Daniel Vetter Link: https://lore.kernel.org/r/20231214100917.277842-5-mripard@kernel.org Signed-off-by: Maxime Ripard --- Documentation/gpu/todo.rst | 23 +++++++++++++++++++++++ 1 file changed, 23 insertions(+) (limited to 'Documentation') diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst index 41a264bf84ce..fb9ad120b141 100644 --- a/Documentation/gpu/todo.rst +++ b/Documentation/gpu/todo.rst @@ -120,6 +120,29 @@ Contact: Daniel Vetter, respective driver maintainers Level: Advanced +Rename drm_atomic_state +----------------------- + +The KMS framework uses two slightly different definitions for the ``state`` +concept. For a given object (plane, CRTC, encoder, etc., so +``drm_$OBJECT_state``), the state is the entire state of that object. However, +at the device level, ``drm_atomic_state`` refers to a state update for a +limited number of objects. + +The state isn't the entire device state, but only the full state of some +objects in that device. This is confusing to newcomers, and +``drm_atomic_state`` should be renamed to something clearer like +``drm_atomic_commit``. + +In addition to renaming the structure itself, it would also imply renaming some +related functions (``drm_atomic_state_alloc``, ``drm_atomic_state_get``, +``drm_atomic_state_put``, ``drm_atomic_state_init``, +``__drm_atomic_state_free``, etc.). + +Contact: Maxime Ripard + +Level: Advanced + Fallout from atomic KMS ----------------------- -- cgit v1.2.3 From 021a81e7ac8f579b049e5bc76efabd9e67bd627c Mon Sep 17 00:00:00 2001 From: Raphael Gallais-Pou Date: Thu, 21 Dec 2023 13:43:32 +0100 Subject: dt-bindings: panel: lvds: Append edt,etml0700z9ndha in panel-lvds List EDT ETML0700Z9NDHA in the LVDS panel enumeration. Signed-off-by: Raphael Gallais-Pou Acked-by: Rob Herring Link: https://lore.kernel.org/r/20231221124339.420119-2-raphael.gallais-pou@foss.st.com Signed-off-by: Neil Armstrong Link: https://patchwork.freedesktop.org/patch/msgid/20231221124339.420119-2-raphael.gallais-pou@foss.st.com --- Documentation/devicetree/bindings/display/panel/panel-lvds.yaml | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/panel/panel-lvds.yaml b/Documentation/devicetree/bindings/display/panel/panel-lvds.yaml index 9f1016551e0b..3fb24393529c 100644 --- a/Documentation/devicetree/bindings/display/panel/panel-lvds.yaml +++ b/Documentation/devicetree/bindings/display/panel/panel-lvds.yaml @@ -42,6 +42,8 @@ properties: - auo,b101ew05 # Chunghwa Picture Tubes Ltd. 7" WXGA (800x1280) TFT LCD LVDS panel - chunghwa,claa070wp03xg + # EDT ETML0700Z9NDHA 7.0" WSVGA (1024x600) color TFT LCD LVDS panel + - edt,etml0700z9ndha # HannStar Display Corp. HSD101PWW2 10.1" WXGA (1280x800) LVDS panel - hannstar,hsd101pww2 # Hydis Technologies 7" WXGA (800x1280) TFT LCD LVDS panel -- cgit v1.2.3 From a72aa8985c41ec241263b802857d84f4c90a8694 Mon Sep 17 00:00:00 2001 From: Javier Martinez Canillas Date: Fri, 29 Dec 2023 12:20:18 +0100 Subject: dt-bindings: display: ssd1307fb: Add vendor prefix to width and height The commit 591825fba8a2 ("dt-bindings: display: ssd1307fb: Remove default width and height values") used the wrong properties for width and height, instead of the correct "solomon,width" and "solomon,height" properties. Fix this by adding the vendor prefix to the width and height properties. Fixes: 591825fba8a2 ("dt-bindings: display: ssd1307fb: Remove default width and height values") Reported-by: Conor Dooley Closes: https://lore.kernel.org/dri-devel/20231218-example-envision-b41ca8efa251@spud/ Signed-off-by: Javier Martinez Canillas Acked-by: Rob Herring Link: https://patchwork.freedesktop.org/patch/msgid/20231229112026.2797483-2-javierm@redhat.com --- .../bindings/display/solomon,ssd1307fb.yaml | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml b/Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml index 3afbb52d1b7f..153ff86fb405 100644 --- a/Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml +++ b/Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml @@ -131,9 +131,9 @@ allOf: const: sinowealth,sh1106 then: properties: - width: + solomon,width: default: 132 - height: + solomon,height: default: 64 solomon,dclk-div: default: 1 @@ -149,9 +149,9 @@ allOf: - solomon,ssd1305 then: properties: - width: + solomon,width: default: 132 - height: + solomon,height: default: 64 solomon,dclk-div: default: 1 @@ -167,9 +167,9 @@ allOf: - solomon,ssd1306 then: properties: - width: + solomon,width: default: 128 - height: + solomon,height: default: 64 solomon,dclk-div: default: 1 @@ -185,9 +185,9 @@ allOf: - solomon,ssd1307 then: properties: - width: + solomon,width: default: 128 - height: + solomon,height: default: 39 solomon,dclk-div: default: 2 @@ -205,9 +205,9 @@ allOf: - solomon,ssd1309 then: properties: - width: + solomon,width: default: 128 - height: + solomon,height: default: 64 solomon,dclk-div: default: 1 -- cgit v1.2.3 From 95ea83829e5f406b15175eb445b89000c2558168 Mon Sep 17 00:00:00 2001 From: Javier Martinez Canillas Date: Fri, 29 Dec 2023 12:20:19 +0100 Subject: dt-bindings: display: ssd132x: Add vendor prefix to width and height Commit 2d23e7d6bacb ("dt-bindings: display: Add SSD132x OLED controllers") used the wrong properties for width and height, instead of the correct "solomon,width" and "solomon,height" properties. Fix this by adding the vendor prefix to the width and height properties. Fixes: 2d23e7d6bacb ("dt-bindings: display: Add SSD132x OLED controllers") Reported-by: Conor Dooley Closes: https://lore.kernel.org/dri-devel/20231218-example-envision-b41ca8efa251@spud/ Signed-off-by: Javier Martinez Canillas Acked-by: Rob Herring Link: https://patchwork.freedesktop.org/patch/msgid/20231229112026.2797483-3-javierm@redhat.com --- .../devicetree/bindings/display/solomon,ssd132x.yaml | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/solomon,ssd132x.yaml b/Documentation/devicetree/bindings/display/solomon,ssd132x.yaml index 37975ee61c5a..dd7939989cf4 100644 --- a/Documentation/devicetree/bindings/display/solomon,ssd132x.yaml +++ b/Documentation/devicetree/bindings/display/solomon,ssd132x.yaml @@ -30,9 +30,9 @@ allOf: const: solomon,ssd1322 then: properties: - width: + solomon,width: default: 480 - height: + solomon,height: default: 128 - if: @@ -42,9 +42,9 @@ allOf: const: solomon,ssd1325 then: properties: - width: + solomon,width: default: 128 - height: + solomon,height: default: 80 - if: @@ -54,9 +54,9 @@ allOf: const: solomon,ssd1327 then: properties: - width: + solomon,width: default: 128 - height: + solomon,height: default: 128 unevaluatedProperties: false -- cgit v1.2.3 From e06b7373cfb96b73d05712fbd15b6d6a78ce9b9d Mon Sep 17 00:00:00 2001 From: Javier Martinez Canillas Date: Fri, 29 Dec 2023 12:20:20 +0100 Subject: dt-bindings: display: Add SSD133x OLED controllers Add a Device Tree binding schema for the OLED panels based on the Solomon SSD133x family of controllers. Signed-off-by: Javier Martinez Canillas Reviewed-by: Rob Herring Link: https://patchwork.freedesktop.org/patch/msgid/20231229112026.2797483-4-javierm@redhat.com --- .../bindings/display/solomon,ssd133x.yaml | 45 ++++++++++++++++++++++ 1 file changed, 45 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/solomon,ssd133x.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/solomon,ssd133x.yaml b/Documentation/devicetree/bindings/display/solomon,ssd133x.yaml new file mode 100644 index 000000000000..b7780038a34b --- /dev/null +++ b/Documentation/devicetree/bindings/display/solomon,ssd133x.yaml @@ -0,0 +1,45 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/solomon,ssd133x.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Solomon SSD133x OLED Display Controllers + +maintainers: + - Javier Martinez Canillas + +allOf: + - $ref: solomon,ssd-common.yaml# + +properties: + compatible: + enum: + - solomon,ssd1331 + + solomon,width: + default: 96 + + solomon,height: + default: 64 + +required: + - compatible + - reg + +unevaluatedProperties: false + +examples: + - | + spi { + #address-cells = <1>; + #size-cells = <0>; + + oled@0 { + compatible = "solomon,ssd1331"; + reg = <0x0>; + reset-gpios = <&gpio2 7>; + dc-gpios = <&gpio2 8>; + spi-max-frequency = <10000000>; + }; + }; -- cgit v1.2.3 From 9676bee4afb188230d591b9cd015c3ab442f578f Mon Sep 17 00:00:00 2001 From: Dario Binacchi Date: Mon, 8 Jan 2024 21:15:50 +0100 Subject: dt-bindings: nt35510: add compatible for FRIDA FRD400B25025-A-CTK The patch adds the FRIDA FRD400B25025-A-CTK panel, which belongs to the Novatek NT35510-based panel family. Signed-off-by: Dario Binacchi Acked-by: Krzysztof Kozlowski Reviewed-by: Linus Walleij Signed-off-by: Linus Walleij Link: https://patchwork.freedesktop.org/patch/msgid/20240108201618.2798649-6-dario.binacchi@amarulasolutions.com --- Documentation/devicetree/bindings/display/panel/novatek,nt35510.yaml | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/panel/novatek,nt35510.yaml b/Documentation/devicetree/bindings/display/panel/novatek,nt35510.yaml index bc92928c805b..a4afaff483b7 100644 --- a/Documentation/devicetree/bindings/display/panel/novatek,nt35510.yaml +++ b/Documentation/devicetree/bindings/display/panel/novatek,nt35510.yaml @@ -15,7 +15,9 @@ allOf: properties: compatible: items: - - const: hydis,hva40wv1 + - enum: + - frida,frd400b25025 + - hydis,hva40wv1 - const: novatek,nt35510 description: This indicates the panel manufacturer of the panel that is in turn using the NT35510 panel driver. The compatible -- cgit v1.2.3 From d11dc7aa98e5ef20642d08a00b02e3d2220ebfd9 Mon Sep 17 00:00:00 2001 From: Rodrigo Vivi Date: Wed, 10 Jan 2024 14:04:27 -0500 Subject: drm/doc/rfc: Remove Xe's pre-merge plan MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The last TODO item here that was not marked as done was the display portion, which came along with the pull-request. So, now that Xe is part of drm-next and it includes the display portion, let's entirely kill this RFC here. Cc: Lucas De Marchi Cc: Thomas Hellström Cc: Oded Gabbay Signed-off-by: Rodrigo Vivi Link: https://patchwork.freedesktop.org/patch/msgid/20240110190427.63095-1-rodrigo.vivi@intel.com Acked-by: Lucas De Marchi --- Documentation/gpu/rfc/xe.rst | 234 ------------------------------------------- 1 file changed, 234 deletions(-) delete mode 100644 Documentation/gpu/rfc/xe.rst (limited to 'Documentation') diff --git a/Documentation/gpu/rfc/xe.rst b/Documentation/gpu/rfc/xe.rst deleted file mode 100644 index 97cf87578f97..000000000000 --- a/Documentation/gpu/rfc/xe.rst +++ /dev/null @@ -1,234 +0,0 @@ -========================== -Xe – Merge Acceptance Plan -========================== -Xe is a new driver for Intel GPUs that supports both integrated and -discrete platforms starting with Tiger Lake (first Intel Xe Architecture). - -This document aims to establish a merge plan for the Xe, by writing down clear -pre-merge goals, in order to avoid unnecessary delays. - -Xe – Overview -============= -The main motivation of Xe is to have a fresh base to work from that is -unencumbered by older platforms, whilst also taking the opportunity to -rearchitect our driver to increase sharing across the drm subsystem, both -leveraging and allowing us to contribute more towards other shared components -like TTM and drm/scheduler. - -This is also an opportunity to start from the beginning with a clean uAPI that is -extensible by design and already aligned with the modern userspace needs. For -this reason, the memory model is solely based on GPU Virtual Address space -bind/unbind (‘VM_BIND’) of GEM buffer objects (BOs) and execution only supporting -explicit synchronization. With persistent mapping across the execution, the -userspace does not need to provide a list of all required mappings during each -submission. - -The new driver leverages a lot from i915. As for display, the intent is to share -the display code with the i915 driver so that there is maximum reuse there. - -As for the power management area, the goal is to have a much-simplified support -for the system suspend states (S-states), PCI device suspend states (D-states), -GPU/Render suspend states (R-states) and frequency management. It should leverage -as much as possible all the existent PCI-subsystem infrastructure (pm and -runtime_pm) and underlying firmware components such PCODE and GuC for the power -states and frequency decisions. - -Repository: - -https://gitlab.freedesktop.org/drm/xe/kernel (branch drm-xe-next) - -Xe – Platforms -============== -Currently, Xe is already functional and has experimental support for multiple -platforms starting from Tiger Lake, with initial support in userspace implemented -in Mesa (for Iris and Anv, our OpenGL and Vulkan drivers), as well as in NEO -(for OpenCL and Level0). - -During a transition period, platforms will be supported by both Xe and i915. -However, the force_probe mechanism existent in both drivers will allow only one -official and by-default probe at a given time. - -For instance, in order to probe a DG2 which PCI ID is 0x5690 by Xe instead of -i915, the following set of parameters need to be used: - -``` -i915.force_probe=!5690 xe.force_probe=5690 -``` - -In both drivers, the ‘.require_force_probe’ protection forces the user to use the -force_probe parameter while the driver is under development. This protection is -only removed when the support for the platform and the uAPI are stable. Stability -which needs to be demonstrated by CI results. - -In order to avoid user space regressions, i915 will continue to support all the -current platforms that are already out of this protection. Xe support will be -forever experimental and dependent on the usage of force_probe for these -platforms. - -When the time comes for Xe, the protection will be lifted on Xe and kept in i915. - -Xe – Pre-Merge Goals - Work-in-Progress -======================================= - -Display integration with i915 ------------------------------ -In order to share the display code with the i915 driver so that there is maximum -reuse, the i915/display/ code is built twice, once for i915.ko and then for -xe.ko. Currently, the i915/display code in Xe tree is polluted with many 'ifdefs' -depending on the build target. The goal is to refactor both Xe and i915/display -code simultaneously in order to get a clean result before they land upstream, so -that display can already be part of the initial pull request towards drm-next. - -However, display code should not gate the acceptance of Xe in upstream. Xe -patches will be refactored in a way that display code can be removed, if needed, -from the first pull request of Xe towards drm-next. The expectation is that when -both drivers are part of the drm-tip, the introduction of cleaner patches will be -easier and speed up. - -Xe – uAPI high level overview -============================= - -...Warning: To be done in follow up patches after/when/where the main consensus in various items are individually reached. - -Xe – Pre-Merge Goals - Completed -================================ - -Drm_exec --------- -Helper to make dma_resv locking for a big number of buffers is getting removed in -the drm_exec series proposed in https://patchwork.freedesktop.org/patch/524376/ -If that happens, Xe needs to change and incorporate the changes in the driver. -The goal is to engage with the Community to understand if the best approach is to -move that to the drivers that are using it or if we should keep the helpers in -place waiting for Xe to get merged. - -This item ties into the GPUVA, VM_BIND, and even long-running compute support. - -As a key measurable result, we need to have a community consensus documented in -this document and the Xe driver prepared for the changes, if necessary. - -Userptr integration and vm_bind -------------------------------- -Different drivers implement different ways of dealing with execution of userptr. -With multiple drivers currently introducing support to VM_BIND, the goal is to -aim for a DRM consensus on what’s the best way to have that support. To some -extent this is already getting addressed itself with the GPUVA where likely the -userptr will be a GPUVA with a NULL GEM call VM bind directly on the userptr. -However, there are more aspects around the rules for that and the usage of -mmu_notifiers, locking and other aspects. - -This task here has the goal of introducing a documentation of the basic rules. - -The documentation *needs* to first live in this document (API session below) and -then moved to another more specific document or at Xe level or at DRM level. - -Documentation should include: - - * The userptr part of the VM_BIND api. - - * Locking, including the page-faulting case. - - * O(1) complexity under VM_BIND. - -The document is now included in the drm documentation :doc:`here `. - -Some parts of userptr like mmu_notifiers should become GPUVA or DRM helpers when -the second driver supporting VM_BIND+userptr appears. Details to be defined when -the time comes. - -The DRM GPUVM helpers do not yet include the userptr parts, but discussions -about implementing them are ongoing. - -ASYNC VM_BIND -------------- -Although having a common DRM level IOCTL for VM_BIND is not a requirement to get -Xe merged, it is mandatory to have a consensus with other drivers and Mesa. -It needs to be clear how to handle async VM_BIND and interactions with userspace -memory fences. Ideally with helper support so people don't get it wrong in all -possible ways. - -As a key measurable result, the benefits of ASYNC VM_BIND and a discussion of -various flavors, error handling and sample API suggestions are documented in -:doc:`The ASYNC VM_BIND document `. - -Drm_scheduler -------------- -Xe primarily uses Firmware based scheduling (GuC FW). However, it will use -drm_scheduler as the scheduler ‘frontend’ for userspace submission in order to -resolve syncobj and dma-buf implicit sync dependencies. However, drm_scheduler is -not yet prepared to handle the 1-to-1 relationship between drm_gpu_scheduler and -drm_sched_entity. - -Deeper changes to drm_scheduler should *not* be required to get Xe accepted, but -some consensus needs to be reached between Xe and other community drivers that -could also benefit from this work, for coupling FW based/assisted submission such -as the ARM’s new Mali GPU driver, and others. - -As a key measurable result, the patch series introducing Xe itself shall not -depend on any other patch touching drm_scheduler itself that was not yet merged -through drm-misc. This, by itself, already includes the reach of an agreement for -uniform 1 to 1 relationship implementation / usage across drivers. - -Long running compute: minimal data structure/scaffolding --------------------------------------------------------- -The generic scheduler code needs to include the handling of endless compute -contexts, with the minimal scaffolding for preempt-ctx fences (probably on the -drm_sched_entity) and making sure drm_scheduler can cope with the lack of job -completion fence. - -The goal is to achieve a consensus ahead of Xe initial pull-request, ideally with -this minimal drm/scheduler work, if needed, merged to drm-misc in a way that any -drm driver, including Xe, could re-use and add their own individual needs on top -in a next stage. However, this should not block the initial merge. - -Dev_coredump ------------- - -Xe needs to align with other drivers on the way that the error states are -dumped, avoiding a Xe only error_state solution. The goal is to use devcoredump -infrastructure to report error states, since it produces a standardized way -by exposing a virtual and temporary /sys/class/devcoredump device. - -As the key measurable result, Xe driver needs to provide GPU snapshots captured -at hang time through devcoredump, but without depending on any core modification -of devcoredump infrastructure itself. - -Later, when we are in-tree, the goal is to collaborate with devcoredump -infrastructure with overall possible improvements, like multiple file support -for better organization of the dumps, snapshot support, dmesg extra print, -and whatever may make sense and help the overall infrastructure. - -DRM_VM_BIND ------------ -Nouveau, and Xe are all implementing ‘VM_BIND’ and new ‘Exec’ uAPIs in order to -fulfill the needs of the modern uAPI. Xe merge should *not* be blocked on the -development of a common new drm_infrastructure. However, the Xe team needs to -engage with the community to explore the options of a common API. - -As a key measurable result, the DRM_VM_BIND needs to be documented in this file -below, or this entire block deleted if the consensus is for independent drivers -vm_bind ioctls. - -Although having a common DRM level IOCTL for VM_BIND is not a requirement to get -Xe merged, it is mandatory to enforce the overall locking scheme for all major -structs and list (so vm and vma). So, a consensus is needed, and possibly some -common helpers. If helpers are needed, they should be also documented in this -document. - -GPU VA ------- -Two main goals of Xe are meeting together here: - -1) Have an uAPI that aligns with modern UMD needs. - -2) Early upstream engagement. - -RedHat engineers working on Nouveau proposed a new DRM feature to handle keeping -track of GPU virtual address mappings. This is still not merged upstream, but -this aligns very well with our goals and with our VM_BIND. The engagement with -upstream and the port of Xe towards GPUVA is already ongoing. - -As a key measurable result, Xe needs to be aligned with the GPU VA and working in -our tree. Missing Nouveau patches should *not* block Xe and any needed GPUVA -related patch should be independent and present on dri-devel or acked by -maintainers to go along with the first Xe pull request towards drm-next. -- cgit v1.2.3 From baae3a0b10c499d4228514a701602f6fd2a8d6b4 Mon Sep 17 00:00:00 2001 From: Manuel Traut Date: Tue, 2 Jan 2024 17:15:44 +0100 Subject: dt-bindings: display: panel: Add BOE TH101MB31IG002-28A panel Add bindings for the BOE TH101MB31IG002-28A LCD panel. It is used e.g. in the Pine64 PineTab2 and PineTab-V. Signed-off-by: Manuel Traut Reviewed-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20240102-pinetab2-v3-1-cb1aa69f8c30@mecka.net Signed-off-by: Neil Armstrong Link: https://patchwork.freedesktop.org/patch/msgid/20240102-pinetab2-v3-1-cb1aa69f8c30@mecka.net --- .../display/panel/boe,th101mb31ig002-28a.yaml | 58 ++++++++++++++++++++++ 1 file changed, 58 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/panel/boe,th101mb31ig002-28a.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/panel/boe,th101mb31ig002-28a.yaml b/Documentation/devicetree/bindings/display/panel/boe,th101mb31ig002-28a.yaml new file mode 100644 index 000000000000..32df26cbfeed --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/boe,th101mb31ig002-28a.yaml @@ -0,0 +1,58 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/panel/boe,th101mb31ig002-28a.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: BOE TH101MB31IG002-28A WXGA DSI Display Panel + +maintainers: + - Manuel Traut + +allOf: + - $ref: panel-common.yaml# + +properties: + compatible: + enum: + # BOE TH101MB31IG002-28A 10.1" WXGA TFT LCD panel + - boe,th101mb31ig002-28a + + reg: true + backlight: true + enable-gpios: true + power-supply: true + port: true + rotation: true + +required: + - compatible + - reg + - enable-gpios + - power-supply + +additionalProperties: false + +examples: + - | + #include + + dsi { + #address-cells = <1>; + #size-cells = <0>; + panel@0 { + compatible = "boe,th101mb31ig002-28a"; + reg = <0>; + backlight = <&backlight_lcd0>; + enable-gpios = <&gpio 45 GPIO_ACTIVE_HIGH>; + rotation = <90>; + power-supply = <&vcc_3v3>; + port { + panel_in_dsi: endpoint { + remote-endpoint = <&dsi_out_con>; + }; + }; + }; + }; + +... -- cgit v1.2.3 From 30cc664f0962ed1e62d9009a34bf04b48e1a5a4a Mon Sep 17 00:00:00 2001 From: Ritesh Kumar Date: Mon, 8 Jan 2024 15:29:01 +0530 Subject: dt-bindings: display: panel: Add Novatek NT36672E LCD DSI Document Novatek NT36672E FHD+ LCD DSI panel. Signed-off-by: Ritesh Kumar Reviewed-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20240108095902.22725-2-quic_riteshk@quicinc.com Signed-off-by: Neil Armstrong Link: https://patchwork.freedesktop.org/patch/msgid/20240108095902.22725-2-quic_riteshk@quicinc.com --- .../bindings/display/panel/novatek,nt36672e.yaml | 66 ++++++++++++++++++++++ 1 file changed, 66 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/panel/novatek,nt36672e.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/panel/novatek,nt36672e.yaml b/Documentation/devicetree/bindings/display/panel/novatek,nt36672e.yaml new file mode 100644 index 000000000000..dc4672f3d01d --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/novatek,nt36672e.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/panel/novatek,nt36672e.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Novatek NT36672E LCD DSI Panel + +maintainers: + - Ritesh Kumar + +allOf: + - $ref: panel-common.yaml# + +properties: + compatible: + const: novatek,nt36672e + + reg: + maxItems: 1 + description: DSI virtual channel + + vddi-supply: true + avdd-supply: true + avee-supply: true + port: true + reset-gpios: true + backlight: true + +required: + - compatible + - reg + - vddi-supply + - avdd-supply + - avee-supply + - reset-gpios + - port + +additionalProperties: false + +examples: + - | + #include + dsi { + #address-cells = <1>; + #size-cells = <0>; + panel@0 { + compatible = "novatek,nt36672e"; + reg = <0>; + + reset-gpios = <&tlmm 44 GPIO_ACTIVE_HIGH>; + + vddi-supply = <&vreg_l8c_1p8>; + avdd-supply = <&disp_avdd>; + avee-supply = <&disp_avee>; + + backlight = <&pwm_backlight>; + + port { + panel0_in: endpoint { + remote-endpoint = <&dsi0_out>; + }; + }; + }; + }; +... -- cgit v1.2.3 From a7983eefb64241f0acc89433dd4f930f2c58ef16 Mon Sep 17 00:00:00 2001 From: Randy Dunlap Date: Thu, 11 Jan 2024 21:17:31 -0800 Subject: drm/doc: internals: remove section on PCI legacy support The functions that were described in this section of drm-internals.rst were removed in NOV-2023, along with all of the kernel-doc comments in the source file. This now causes a docs build warning, so remove that section of the documentation also. drivers/gpu/drm/drm_pci.c:1: warning: no structured comments found Fixes: 2504c7ec728b ("drm: Remove source code for non-KMS drivers") Signed-off-by: Randy Dunlap Cc: Thomas Zimmermann Cc: David Airlie Cc: Daniel Vetter Cc: dri-devel@lists.freedesktop.org Cc: Jonathan Corbet Cc: linux-doc@vger.kernel.org Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20240112051731.15722-1-rdunlap@infradead.org --- Documentation/gpu/drm-internals.rst | 12 ------------ 1 file changed, 12 deletions(-) (limited to 'Documentation') diff --git a/Documentation/gpu/drm-internals.rst b/Documentation/gpu/drm-internals.rst index 5fd20a306718..335de7fcddee 100644 --- a/Documentation/gpu/drm-internals.rst +++ b/Documentation/gpu/drm-internals.rst @@ -153,18 +153,6 @@ Managed Resources .. kernel-doc:: include/drm/drm_managed.h :internal: -Bus-specific Device Registration and PCI Support ------------------------------------------------- - -A number of functions are provided to help with device registration. The -functions deal with PCI and platform devices respectively and are only -provided for historical reasons. These are all deprecated and shouldn't -be used in new drivers. Besides that there's a few helpers for pci -drivers. - -.. kernel-doc:: drivers/gpu/drm/drm_pci.c - :export: - Open/Close, File Operations and IOCTLs ====================================== -- cgit v1.2.3 From 286c4dcf6cc6784fdc6dffe599bc81b038746800 Mon Sep 17 00:00:00 2001 From: Thomas Zimmermann Date: Mon, 15 Jan 2024 12:38:56 +0100 Subject: Documentation/gpu: Reference articles on Linux graphics stack Add two articles on LWN about the Linux graphics stack to DRM's list of external references. The articles document the graphics output as a whole, including the kernel side. Signed-off-by: Thomas Zimmermann Reviewed-by: Simon Ser Reviewed-by: Javier Martinez Canillas Link: https://patchwork.freedesktop.org/patch/msgid/20240115113908.25897-1-tzimmermann@suse.de --- Documentation/gpu/introduction.rst | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/gpu/introduction.rst b/Documentation/gpu/introduction.rst index f05eccd2c07c..b7c0baf97dbe 100644 --- a/Documentation/gpu/introduction.rst +++ b/Documentation/gpu/introduction.rst @@ -164,6 +164,8 @@ Conference talks Slides and articles ------------------- +* `The Linux graphics stack in a nutshell, part 1 `_ - Thomas Zimmermann (2023) +* `The Linux graphics stack in a nutshell, part 2 `_ - Thomas Zimmermann (2023) * `Understanding the Linux Graphics Stack `_ - Bootlin (2022) * `DRM KMS overview `_ - STMicroelectronics (2021) * `Linux graphic stack `_ - Nathan Gauër (2017) -- cgit v1.2.3 From 70a46e1fda3b3584da01fe072bc959003ebbd8a9 Mon Sep 17 00:00:00 2001 From: Rodrigo Vivi Date: Tue, 16 Jan 2024 17:03:31 -0500 Subject: drm/doc/rfc: Removing missing reference to xe.rst The file has already been deleted as the tasks were completed. However the index reference was missed behind. fixes a doc build warning: Documentation/gpu/rfc/index.rst:35: WARNING: toctree contains reference to nonexisting document 'gpu/rfc/xe' Fixes: d11dc7aa98e5 ("drm/doc/rfc: Remove Xe's pre-merge plan") Cc: Lucas De Marchi Signed-off-by: Rodrigo Vivi Reviewed-by: Matthew Auld Link: https://patchwork.freedesktop.org/patch/msgid/20240116220331.145607-1-rodrigo.vivi@intel.com --- Documentation/gpu/rfc/index.rst | 4 ---- 1 file changed, 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/gpu/rfc/index.rst b/Documentation/gpu/rfc/index.rst index e4f7b005138d..476719771eef 100644 --- a/Documentation/gpu/rfc/index.rst +++ b/Documentation/gpu/rfc/index.rst @@ -31,7 +31,3 @@ host such documentation: .. toctree:: i915_vm_bind.rst - -.. toctree:: - - xe.rst -- cgit v1.2.3 From 8bafa2f2eab86db491f9b5010825c3ca8a4127c3 Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Mon, 15 Jan 2024 19:20:57 +0100 Subject: dt-bindings: input: silead,gsl1680: do not override firmware-name $ref dtschema package defines firmware-name as string-array, so individual bindings should not make it a string but instead just narrow the number of expected firmware file names. Signed-off-by: Krzysztof Kozlowski Acked-by: Conor Dooley Link: https://lore.kernel.org/r/20240115182057.1610195-1-krzysztof.kozlowski@linaro.org Signed-off-by: Dmitry Torokhov --- Documentation/devicetree/bindings/input/touchscreen/silead,gsl1680.yaml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/input/touchscreen/silead,gsl1680.yaml b/Documentation/devicetree/bindings/input/touchscreen/silead,gsl1680.yaml index 95b554be25b4..5381a96f4949 100644 --- a/Documentation/devicetree/bindings/input/touchscreen/silead,gsl1680.yaml +++ b/Documentation/devicetree/bindings/input/touchscreen/silead,gsl1680.yaml @@ -31,7 +31,7 @@ properties: maxItems: 1 firmware-name: - $ref: /schemas/types.yaml#/definitions/string + maxItems: 1 description: > File basename for board specific firmware -- cgit v1.2.3 From d259f137461b9067ff46a10922e66a6e9fc38e12 Mon Sep 17 00:00:00 2001 From: Luca Ceresoli Date: Tue, 2 Jan 2024 09:19:34 +0100 Subject: dt-bindings: input: touchscreen: goodix: clarify irq-gpios misleading text The irq-gpios description misleading, apparently saying that driving the IRQ GPIO resets the device, which is even more puzzling as there is a reset GPIO as well. In reality the IRQ pin can be driven during the reset sequence to configure the client address, as it becomes clear after checking both the datasheet and the driver code. Improve the text to clarify that. Also rephrase to remove reference to the driver, which is not appropriate in the bindings. Signed-off-by: Luca Ceresoli Acked-by: Rob Herring Reviewed-by: Jeff LaBundy Link: https://lore.kernel.org/r/20240102081934.11293-1-luca.ceresoli@bootlin.com Signed-off-by: Dmitry Torokhov --- Documentation/devicetree/bindings/input/touchscreen/goodix.yaml | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/input/touchscreen/goodix.yaml b/Documentation/devicetree/bindings/input/touchscreen/goodix.yaml index 3d016b87c8df..2a2d86cfd104 100644 --- a/Documentation/devicetree/bindings/input/touchscreen/goodix.yaml +++ b/Documentation/devicetree/bindings/input/touchscreen/goodix.yaml @@ -37,8 +37,9 @@ properties: maxItems: 1 irq-gpios: - description: GPIO pin used for IRQ. The driver uses the interrupt gpio pin - as output to reset the device. + description: GPIO pin used for IRQ input. Additionally, this line is + sampled by the device on reset deassertion to select the I2C client + address, thus it can be driven by the host during the reset sequence. maxItems: 1 reset-gpios: -- cgit v1.2.3 From 52523f70fdf9b2cb0bfd1999eba4aa3a30b04fa6 Mon Sep 17 00:00:00 2001 From: Chancel Liu Date: Fri, 12 Jan 2024 14:43:29 +0900 Subject: ASoC: dt-bindings: fsl,sai: Add compatible string for i.MX95 platform Add compatible string "fsl,imx95-sai" for i.MX95 platform. Signed-off-by: Chancel Liu Acked-by: Krzysztof Kozlowski Link: https://msgid.link/r/20240112054331.3244104-2-chancel.liu@nxp.com Reviewed-by: Daniel Baluta Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/sound/fsl,sai.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/fsl,sai.yaml b/Documentation/devicetree/bindings/sound/fsl,sai.yaml index 088c26b001cc..d81c8fe1893e 100644 --- a/Documentation/devicetree/bindings/sound/fsl,sai.yaml +++ b/Documentation/devicetree/bindings/sound/fsl,sai.yaml @@ -39,6 +39,7 @@ properties: - fsl,imx8qm-sai - fsl,imx8ulp-sai - fsl,imx93-sai + - fsl,imx95-sai - fsl,vf610-sai reg: -- cgit v1.2.3 From 20d2719937cf439602566a8f041d3208274abc01 Mon Sep 17 00:00:00 2001 From: Chancel Liu Date: Fri, 12 Jan 2024 14:43:31 +0900 Subject: ASoC: dt-bindings: fsl,micfil: Add compatible string for i.MX95 platform Add compatible string "fsl,imx95-micfil" for i.MX95 platform. Signed-off-by: Chancel Liu Reviewed-by: Krzysztof Kozlowski Link: https://msgid.link/r/20240112054331.3244104-4-chancel.liu@nxp.com Reviewed-by: Daniel Baluta Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/sound/fsl,micfil.yaml | 14 ++++++++++---- 1 file changed, 10 insertions(+), 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/fsl,micfil.yaml b/Documentation/devicetree/bindings/sound/fsl,micfil.yaml index b7e605835639..c1e9803fc113 100644 --- a/Documentation/devicetree/bindings/sound/fsl,micfil.yaml +++ b/Documentation/devicetree/bindings/sound/fsl,micfil.yaml @@ -15,10 +15,16 @@ description: | properties: compatible: - enum: - - fsl,imx8mm-micfil - - fsl,imx8mp-micfil - - fsl,imx93-micfil + oneOf: + - items: + - enum: + - fsl,imx95-micfil + - const: fsl,imx93-micfil + + - enum: + - fsl,imx8mm-micfil + - fsl,imx8mp-micfil + - fsl,imx93-micfil reg: maxItems: 1 -- cgit v1.2.3 From 166ee0b3bfbb3611579c77fc84e44cd27a0099ef Mon Sep 17 00:00:00 2001 From: Neil Armstrong Date: Tue, 19 Dec 2023 13:45:34 +0100 Subject: ASoC: dt-bindings: qcom,wcd938x: move out common properties Move out common properties from qcom,wcd938x bindings in preparation of adding Qualcomm WCD939x bindings sharing most of the properties. Reviewed-by: Krzysztof Kozlowski Signed-off-by: Neil Armstrong Link: https://msgid.link/r/20231219-topic-sm8650-upstream-wcd939x-codec-v4-1-1c3bbff2d7ab@linaro.org Signed-off-by: Mark Brown --- .../devicetree/bindings/sound/qcom,wcd938x.yaml | 81 +----------------- .../bindings/sound/qcom,wcd93xx-common.yaml | 95 ++++++++++++++++++++++ 2 files changed, 96 insertions(+), 80 deletions(-) create mode 100644 Documentation/devicetree/bindings/sound/qcom,wcd93xx-common.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/qcom,wcd938x.yaml b/Documentation/devicetree/bindings/sound/qcom,wcd938x.yaml index adbfa67f88ed..cf6c3787adfe 100644 --- a/Documentation/devicetree/bindings/sound/qcom,wcd938x.yaml +++ b/Documentation/devicetree/bindings/sound/qcom,wcd938x.yaml @@ -15,6 +15,7 @@ description: | allOf: - $ref: dai-common.yaml# + - $ref: qcom,wcd93xx-common.yaml# properties: compatible: @@ -22,92 +23,12 @@ properties: - qcom,wcd9380-codec - qcom,wcd9385-codec - reset-gpios: - description: GPIO spec for reset line to use - maxItems: 1 - us-euro-gpios: description: GPIO spec for swapping gnd and mic segments 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 - - vdd-mic-bias-supply: - description: A reference to the 3.8V mic bias 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" unevaluatedProperties: false diff --git a/Documentation/devicetree/bindings/sound/qcom,wcd93xx-common.yaml b/Documentation/devicetree/bindings/sound/qcom,wcd93xx-common.yaml new file mode 100644 index 000000000000..f78ba148ad25 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/qcom,wcd93xx-common.yaml @@ -0,0 +1,95 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/qcom,wcd93xx-common.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Common properties for Qualcomm WCD93xx Audio Codec + +maintainers: + - Srinivas Kandagatla + +properties: + 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 + + vdd-mic-bias-supply: + description: A reference to the 3.8V mic bias 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: + - reset-gpios + - qcom,tx-device + - qcom,rx-device + - qcom,micbias1-microvolt + - qcom,micbias2-microvolt + - qcom,micbias3-microvolt + - qcom,micbias4-microvolt + - "#sound-dai-cells" + +additionalProperties: true -- cgit v1.2.3 From edf647d1335fd55c81cdb8cc8cbf1da7d97739df Mon Sep 17 00:00:00 2001 From: Neil Armstrong Date: Tue, 19 Dec 2023 13:45:35 +0100 Subject: ASoC: dt-bindings: document WCD939x Audio Codec Document the Qualcomm WCD9390/WCD9395 Audio Codec and the Soundwire devices than can be found on Qualcomm SM8650 based platforms. The Qualcomm WCD9390/WCD9395 Audio Codec communicates with the host SoC over 2 Soundwire links to provide: - 4 ADC inputs for up to 5 Analog Microphones - 4 DMIC inputs for up to 8 Digital Microphones - 4 Microphone BIAS - Stereo Headphone output - Mono EAR output - MBHC engine for Headset Detection The WCD9390/WCD9395 IC has separate I2C subsystem for USB-C DP Altmode/Audio Accessory mode Mux which is not documented here but requires port/endpoint graph and properties to handle Altmode/Audio Accessory switch and orientation. Reviewed-by: Krzysztof Kozlowski Signed-off-by: Neil Armstrong Link: https://msgid.link/r/20231219-topic-sm8650-upstream-wcd939x-codec-v4-2-1c3bbff2d7ab@linaro.org Signed-off-by: Mark Brown --- .../bindings/sound/qcom,wcd939x-sdw.yaml | 69 ++++++++++++++++ .../devicetree/bindings/sound/qcom,wcd939x.yaml | 96 ++++++++++++++++++++++ 2 files changed, 165 insertions(+) create mode 100644 Documentation/devicetree/bindings/sound/qcom,wcd939x-sdw.yaml create mode 100644 Documentation/devicetree/bindings/sound/qcom,wcd939x.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/qcom,wcd939x-sdw.yaml b/Documentation/devicetree/bindings/sound/qcom,wcd939x-sdw.yaml new file mode 100644 index 000000000000..67ed7701b5d6 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/qcom,wcd939x-sdw.yaml @@ -0,0 +1,69 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/qcom,wcd939x-sdw.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm SoundWire devices on WCD9390/WCD9395 + +maintainers: + - Srinivas Kandagatla + +description: | + Qualcomm WCD9390/WCD9395 Codec is a standalone Hi-Fi audio codec IC. + It has RX and TX Soundwire devices. This bindings is for the devices. + +properties: + compatible: + const: sdw20217010e00 + + reg: + maxItems: 1 + + qcom,tx-port-mapping: + description: | + Specifies static port mapping between device and host tx ports. + In the order of the device port index. + $ref: /schemas/types.yaml#/definitions/uint32-array + minItems: 4 + maxItems: 4 + + qcom,rx-port-mapping: + description: | + Specifies static port mapping between device and host rx ports. + In the order of device port index. + $ref: /schemas/types.yaml#/definitions/uint32-array + minItems: 6 + maxItems: 6 + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + soundwire@3210000 { + #address-cells = <2>; + #size-cells = <0>; + reg = <0x03210000 0x2000>; + wcd938x_rx: codec@0,4 { + compatible = "sdw20217010e00"; + reg = <0 4>; + qcom,rx-port-mapping = <1 2 3 4 5 6>; + }; + }; + + soundwire@3230000 { + #address-cells = <2>; + #size-cells = <0>; + reg = <0x03230000 0x2000>; + wcd938x_tx: codec@0,3 { + compatible = "sdw20217010e00"; + reg = <0 3>; + qcom,tx-port-mapping = <2 3 4 5>; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/sound/qcom,wcd939x.yaml b/Documentation/devicetree/bindings/sound/qcom,wcd939x.yaml new file mode 100644 index 000000000000..6e76f6a8634f --- /dev/null +++ b/Documentation/devicetree/bindings/sound/qcom,wcd939x.yaml @@ -0,0 +1,96 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/qcom,wcd939x.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm WCD9380/WCD9385 Audio Codec + +maintainers: + - Srinivas Kandagatla + +description: | + Qualcomm WCD9390/WCD9395 Codec is a standalone Hi-Fi audio codec IC. + It has RX and TX Soundwire devices. + The WCD9390/WCD9395 IC has a functionally separate USB-C Mux subsystem + accessible over an I2C interface. + The Audio Headphone and Microphone data path between the Codec and the USB-C Mux + subsystems are external to the IC, thus requiring DT port-endpoint graph description + to handle USB-C altmode & orientation switching for Audio Accessory Mode. + +allOf: + - $ref: dai-common.yaml# + - $ref: qcom,wcd93xx-common.yaml# + +properties: + compatible: + oneOf: + - const: qcom,wcd9390-codec + - items: + - const: qcom,wcd9395-codec + - const: qcom,wcd9390-codec + + mode-switch: + description: Flag the port as possible handler of altmode switching + type: boolean + + orientation-switch: + description: Flag the port as possible handler of orientation switching + type: boolean + + port: + $ref: /schemas/graph.yaml#/properties/port + description: + A port node to link the WCD939x Codec node to USB MUX subsystems for the + purpose of handling altmode muxing and orientation switching to detect and + enable Audio Accessory Mode. + +required: + - compatible + +unevaluatedProperties: false + +examples: + - | + #include + codec { + compatible = "qcom,wcd9390-codec"; + reset-gpios = <&tlmm 32 IRQ_TYPE_NONE>; + #sound-dai-cells = <1>; + qcom,tx-device = <&wcd939x_tx>; + qcom,rx-device = <&wcd939x_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>; + wcd939x_rx: codec@0,4 { + compatible = "sdw20217010e00"; + reg = <0 4>; + qcom,rx-port-mapping = <1 2 3 4 5 6>; + }; + }; + + soundwire@3230000 { + #address-cells = <2>; + #size-cells = <0>; + reg = <0x03230000 0x2000>; + wcd938x_tx: codec@0,3 { + compatible = "sdw20217010e00"; + reg = <0 3>; + qcom,tx-port-mapping = <2 3 4 5>; + }; + }; + +... -- cgit v1.2.3 From 059870e53aa06831f1ccdc5e9cf29f933cdf284e Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Mon, 15 Jan 2024 19:20:17 +0100 Subject: ASoC: dt-bindings: Do not override firmware-name $ref dtschema package defines firmware-name as string-array, so individual bindings should not make it a string but instead just narrow the number of expected firmware file names. Signed-off-by: Krzysztof Kozlowski Link: https://msgid.link/r/20240115182017.1610055-1-krzysztof.kozlowski@linaro.org Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/sound/fsl,easrc.yaml | 4 ++-- Documentation/devicetree/bindings/sound/infineon,peb2466.yaml | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/fsl,easrc.yaml b/Documentation/devicetree/bindings/sound/fsl,easrc.yaml index a680d7aff237..0782f3f9947f 100644 --- a/Documentation/devicetree/bindings/sound/fsl,easrc.yaml +++ b/Documentation/devicetree/bindings/sound/fsl,easrc.yaml @@ -51,8 +51,8 @@ properties: - const: ctx3_tx firmware-name: - $ref: /schemas/types.yaml#/definitions/string - const: imx/easrc/easrc-imx8mn.bin + items: + - const: imx/easrc/easrc-imx8mn.bin description: The coefficient table for the filters fsl,asrc-rate: diff --git a/Documentation/devicetree/bindings/sound/infineon,peb2466.yaml b/Documentation/devicetree/bindings/sound/infineon,peb2466.yaml index 66993d378aaf..5e11ce2c13ac 100644 --- a/Documentation/devicetree/bindings/sound/infineon,peb2466.yaml +++ b/Documentation/devicetree/bindings/sound/infineon,peb2466.yaml @@ -51,7 +51,7 @@ properties: maxItems: 1 firmware-name: - $ref: /schemas/types.yaml#/definitions/string + maxItems: 1 description: Filters coefficients file to load. If this property is omitted, internal filters are disabled. -- cgit v1.2.3 From a6ffa02ba7a28fe1bba06eacb224554d89a1cd4d Mon Sep 17 00:00:00 2001 From: André Apitzsch Date: Thu, 4 Jan 2024 23:40:40 +0100 Subject: dt-bindings: regulator: Convert ti,tps65132 to YAML MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Convert TI TPS65132 bindings from .txt to .yaml format. Signed-off-by: André Apitzsch Reviewed-by: Krzysztof Kozlowski Link: https://msgid.link/r/20240104-tps65132-v2-1-6c77fe2f4787@apitzsch.eu Signed-off-by: Mark Brown --- .../devicetree/bindings/regulator/ti,tps65132.yaml | 84 ++++++++++++++++++++++ .../bindings/regulator/tps65132-regulator.txt | 46 ------------ 2 files changed, 84 insertions(+), 46 deletions(-) create mode 100644 Documentation/devicetree/bindings/regulator/ti,tps65132.yaml delete mode 100644 Documentation/devicetree/bindings/regulator/tps65132-regulator.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/regulator/ti,tps65132.yaml b/Documentation/devicetree/bindings/regulator/ti,tps65132.yaml new file mode 100644 index 000000000000..6a6d1a3d6fa7 --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/ti,tps65132.yaml @@ -0,0 +1,84 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/regulator/ti,tps65132.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: TI TPS65132 Dual Output Power Regulators + +maintainers: + - devicetree@vger.kernel.org + +description: | + The TPS65132 is designed to supply positive/negative driven applications. + + Datasheet is available at: + https://www.ti.com/lit/gpn/tps65132 + +properties: + compatible: + enum: + - ti,tps65132 + + reg: + maxItems: 1 + +patternProperties: + "^out[pn]$": + type: object + $ref: regulator.yaml# + unevaluatedProperties: false + description: + Properties for single regulator. + + properties: + enable-gpios: + maxItems: 1 + description: + GPIO specifier to enable the GPIO control (on/off) for regulator. + + active-discharge-gpios: + maxItems: 1 + description: + GPIO specifier to actively discharge the delay mechanism. + + ti,active-discharge-time-us: + description: Regulator active discharge time in microseconds. + + dependencies: + active-discharge-gpios: [ 'ti,active-discharge-time-us' ] + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + #include + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + regulator@3e { + compatible = "ti,tps65132"; + reg = <0x3e>; + + outp { + regulator-name = "outp"; + regulator-boot-on; + regulator-always-on; + enable-gpios = <&gpio 23 GPIO_ACTIVE_HIGH>; + }; + + outn { + regulator-name = "outn"; + regulator-boot-on; + regulator-always-on; + regulator-active-discharge = <0>; + enable-gpios = <&gpio 40 GPIO_ACTIVE_HIGH>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/regulator/tps65132-regulator.txt b/Documentation/devicetree/bindings/regulator/tps65132-regulator.txt deleted file mode 100644 index 3a3505520c69..000000000000 --- a/Documentation/devicetree/bindings/regulator/tps65132-regulator.txt +++ /dev/null @@ -1,46 +0,0 @@ -TPS65132 regulators - -Required properties: -- compatible: "ti,tps65132" -- reg: I2C slave address - -Optional Subnode: -Device supports two regulators OUTP and OUTN. A sub node within the - device node describe the properties of these regulators. The sub-node - names must be as follows: - -For regulator outp, the sub node name should be "outp". - -For regulator outn, the sub node name should be "outn". - --enable-gpios:(active high, output) Regulators are controlled by the input pins. - If it is connected to GPIO through host system then provide the - gpio number as per gpio.txt. --active-discharge-gpios: (active high, output) Some configurations use delay mechanisms - on the enable pin, to keep the regulator enabled for some time after - the enable signal goes low. This GPIO is used to actively discharge - the delay mechanism. Requires specification of ti,active-discharge-time-us --ti,active-discharge-time-us: how long the active discharge gpio should be - asserted for during active discharge, in microseconds. - -Each regulator is defined using the standard binding for regulators. - -Example: - - tps65132@3e { - compatible = "ti,tps65132"; - reg = <0x3e>; - - outp { - regulator-name = "outp"; - regulator-boot-on; - regulator-always-on; - enable-gpios = <&gpio 23 0>; - }; - - outn { - regulator-name = "outn"; - regulator-boot-on; - regulator-always-on; - regulator-active-discharge = <0>; - enable-gpios = <&gpio 40 0>; - }; - }; -- cgit v1.2.3 From 0707496ff4e416ea08c90053fd5fde5811b11b22 Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Wed, 17 Jan 2024 17:06:39 +0100 Subject: soundwire: stream: add missing const to Documentation Commit 21f4c443731f ("soundwire: stream: constify sdw_port_config when adding devices") added const to sdw_port_config argument, but forgot documentation. Fixes: 21f4c443731f ("soundwire: stream: constify sdw_port_config when adding devices") Signed-off-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20240117160639.1327266-1-krzysztof.kozlowski@linaro.org Signed-off-by: Vinod Koul --- Documentation/driver-api/soundwire/stream.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/driver-api/soundwire/stream.rst b/Documentation/driver-api/soundwire/stream.rst index b432a2de45d3..2a794484f62c 100644 --- a/Documentation/driver-api/soundwire/stream.rst +++ b/Documentation/driver-api/soundwire/stream.rst @@ -324,12 +324,12 @@ framework, this stream state is linked to .hw_params() operation. int sdw_stream_add_master(struct sdw_bus * bus, struct sdw_stream_config * stream_config, - struct sdw_ports_config * ports_config, + const struct sdw_ports_config * ports_config, struct sdw_stream_runtime * stream); int sdw_stream_add_slave(struct sdw_slave * slave, struct sdw_stream_config * stream_config, - struct sdw_ports_config * ports_config, + const struct sdw_ports_config * ports_config, struct sdw_stream_runtime * stream); -- cgit v1.2.3 From f1868165d2d737a85dfce18e1bfada86d0ed4f92 Mon Sep 17 00:00:00 2001 From: Xiongwei Song Date: Fri, 15 Dec 2023 11:41:47 +0800 Subject: Documentation: kernel-parameters: remove noaliencache Since slab allocator has already been removed. There is no users of the noaliencache parameter, so let's remove it. Suggested-by: Hyeonggon Yoo <42.hyeyoo@gmail.com> Reviewed-by: Kees Cook Reviewed-by: Vlastimil Babka Signed-off-by: Xiongwei Song Signed-off-by: Vlastimil Babka --- Documentation/admin-guide/kernel-parameters.txt | 4 ---- 1 file changed, 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index 31b3a25680d0..89c67c2403fc 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -3753,10 +3753,6 @@ no5lvl [X86-64,RISCV] Disable 5-level paging mode. Forces kernel to use 4-level paging instead. - noaliencache [MM, NUMA, SLAB] Disables the allocation of alien - caches in the slab allocator. Saves per-node memory, - but will impact performance. - noalign [KNL,ARM] noaltinstr [S390] Disables alternative instructions patching -- cgit v1.2.3 From 671776b32b26d0cb625bf834170e982fda712cab Mon Sep 17 00:00:00 2001 From: Xiongwei Song Date: Fri, 15 Dec 2023 11:41:48 +0800 Subject: mm/slub: unify all sl[au]b parameters with "slab_$param" Since the SLAB allocator has been removed, so we can clean up the sl[au]b_$params. With only one slab allocator left, it's better to use the generic "slab" term instead of "slub" which is an implementation detail, which is pointed out by Vlastimil Babka. For more information please see [1]. Hence, we are going to use "slab_$param" as the primary prefix. This patch is changing the following slab parameters - slub_max_order - slub_min_order - slub_min_objects - slub_debug to - slab_max_order - slab_min_order - slab_min_objects - slab_debug as the primary slab parameters for all references of them in docs and comments. But this patch won't change variables and functions inside slub as we will have wider slub/slab change. Meanwhile, "slub_$params" can also be passed by command line, which is to keep backward compatibility. Also mark all "slub_$params" as legacy. Remove the separate descriptions for slub_[no]merge, append legacy tip for them at the end of descriptions of slab_[no]merge. [1] https://lore.kernel.org/linux-mm/7512b350-4317-21a0-fab3-4101bc4d8f7a@suse.cz/ Signed-off-by: Xiongwei Song Reviewed-by: Vlastimil Babka Signed-off-by: Vlastimil Babka --- Documentation/admin-guide/kernel-parameters.txt | 71 +++++++++++-------------- drivers/misc/lkdtm/heap.c | 2 +- mm/Kconfig.debug | 6 +-- mm/slab.h | 2 +- mm/slab_common.c | 4 +- mm/slub.c | 41 +++++++------- 6 files changed, 62 insertions(+), 64 deletions(-) (limited to 'Documentation') diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index 89c67c2403fc..aefd68cec2e9 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -5891,65 +5891,58 @@ simeth= [IA-64] simscsi= - slram= [HW,MTD] - - slab_merge [MM] - Enable merging of slabs with similar size when the - kernel is built without CONFIG_SLAB_MERGE_DEFAULT. - - slab_nomerge [MM] - Disable merging of slabs with similar size. May be - necessary if there is some reason to distinguish - allocs to different slabs, especially in hardened - environments where the risk of heap overflows and - layout control by attackers can usually be - frustrated by disabling merging. This will reduce - most of the exposure of a heap attack to a single - cache (risks via metadata attacks are mostly - unchanged). Debug options disable merging on their - own. - For more information see Documentation/mm/slub.rst. - - slab_max_order= [MM, SLAB] - Determines the maximum allowed order for slabs. - A high setting may cause OOMs due to memory - fragmentation. Defaults to 1 for systems with - more than 32MB of RAM, 0 otherwise. - - slub_debug[=options[,slabs][;[options[,slabs]]...] [MM, SLUB] - Enabling slub_debug allows one to determine the + slab_debug[=options[,slabs][;[options[,slabs]]...] [MM] + Enabling slab_debug allows one to determine the culprit if slab objects become corrupted. Enabling - slub_debug can create guard zones around objects and + slab_debug can create guard zones around objects and may poison objects when not in use. Also tracks the last alloc / free. For more information see Documentation/mm/slub.rst. + (slub_debug legacy name also accepted for now) - slub_max_order= [MM, SLUB] + slab_max_order= [MM] Determines the maximum allowed order for slabs. A high setting may cause OOMs due to memory fragmentation. For more information see Documentation/mm/slub.rst. + (slub_max_order legacy name also accepted for now) + + slab_merge [MM] + Enable merging of slabs with similar size when the + kernel is built without CONFIG_SLAB_MERGE_DEFAULT. + (slub_merge legacy name also accepted for now) - slub_min_objects= [MM, SLUB] + slab_min_objects= [MM] The minimum number of objects per slab. SLUB will - increase the slab order up to slub_max_order to + increase the slab order up to slab_max_order to generate a sufficiently large slab able to contain the number of objects indicated. The higher the number of objects the smaller the overhead of tracking slabs and the less frequently locks need to be acquired. For more information see Documentation/mm/slub.rst. + (slub_min_objects legacy name also accepted for now) - slub_min_order= [MM, SLUB] + slab_min_order= [MM] Determines the minimum page order for slabs. Must be - lower than slub_max_order. - For more information see Documentation/mm/slub.rst. + lower or equal to slab_max_order. For more information see + Documentation/mm/slub.rst. + (slub_min_order legacy name also accepted for now) - slub_merge [MM, SLUB] - Same with slab_merge. + slab_nomerge [MM] + Disable merging of slabs with similar size. May be + necessary if there is some reason to distinguish + allocs to different slabs, especially in hardened + environments where the risk of heap overflows and + layout control by attackers can usually be + frustrated by disabling merging. This will reduce + most of the exposure of a heap attack to a single + cache (risks via metadata attacks are mostly + unchanged). Debug options disable merging on their + own. + For more information see Documentation/mm/slub.rst. + (slub_nomerge legacy name also accepted for now) - slub_nomerge [MM, SLUB] - Same with slab_nomerge. This is supported for legacy. - See slab_nomerge for more information. + slram= [HW,MTD] smart2= [HW] Format: [,[,...,]] diff --git a/drivers/misc/lkdtm/heap.c b/drivers/misc/lkdtm/heap.c index 4f467d3972a6..b1b316f99703 100644 --- a/drivers/misc/lkdtm/heap.c +++ b/drivers/misc/lkdtm/heap.c @@ -48,7 +48,7 @@ static void lkdtm_VMALLOC_LINEAR_OVERFLOW(void) * correctly. * * This should get caught by either memory tagging, KASan, or by using - * CONFIG_SLUB_DEBUG=y and slub_debug=ZF (or CONFIG_SLUB_DEBUG_ON=y). + * CONFIG_SLUB_DEBUG=y and slab_debug=ZF (or CONFIG_SLUB_DEBUG_ON=y). */ static void lkdtm_SLAB_LINEAR_OVERFLOW(void) { diff --git a/mm/Kconfig.debug b/mm/Kconfig.debug index 321ab379994f..afc72fde0f03 100644 --- a/mm/Kconfig.debug +++ b/mm/Kconfig.debug @@ -64,11 +64,11 @@ config SLUB_DEBUG_ON help Boot with debugging on by default. SLUB boots by default with the runtime debug capabilities switched off. Enabling this is - equivalent to specifying the "slub_debug" parameter on boot. + equivalent to specifying the "slab_debug" parameter on boot. There is no support for more fine grained debug control like - possible with slub_debug=xxx. SLUB debugging may be switched + possible with slab_debug=xxx. SLUB debugging may be switched off in a kernel built with CONFIG_SLUB_DEBUG_ON by specifying - "slub_debug=-". + "slab_debug=-". config PAGE_OWNER bool "Track page owner" diff --git a/mm/slab.h b/mm/slab.h index 54deeb0428c6..f7df6d701c5b 100644 --- a/mm/slab.h +++ b/mm/slab.h @@ -528,7 +528,7 @@ static inline bool __slub_debug_enabled(void) #endif /* - * Returns true if any of the specified slub_debug flags is enabled for the + * Returns true if any of the specified slab_debug flags is enabled for the * cache. Use only for flags parsed by setup_slub_debug() as it also enables * the static key. */ diff --git a/mm/slab_common.c b/mm/slab_common.c index 238293b1dbe1..230ef7cc3467 100644 --- a/mm/slab_common.c +++ b/mm/slab_common.c @@ -282,7 +282,7 @@ kmem_cache_create_usercopy(const char *name, #ifdef CONFIG_SLUB_DEBUG /* - * If no slub_debug was enabled globally, the static key is not yet + * If no slab_debug was enabled globally, the static key is not yet * enabled by setup_slub_debug(). Enable it if the cache is being * created with any of the debugging flags passed explicitly. * It's also possible that this is the first cache created with @@ -766,7 +766,7 @@ EXPORT_SYMBOL(kmalloc_size_roundup); } /* - * kmalloc_info[] is to make slub_debug=,kmalloc-xx option work at boot time. + * kmalloc_info[] is to make slab_debug=,kmalloc-xx option work at boot time. * kmalloc_index() supports up to 2^21=2MB, so the final entry of the table is * kmalloc-2M. */ diff --git a/mm/slub.c b/mm/slub.c index 2ef88bbf56a3..e66bc888d23b 100644 --- a/mm/slub.c +++ b/mm/slub.c @@ -295,7 +295,7 @@ static inline bool kmem_cache_has_cpu_partial(struct kmem_cache *s) /* * Debugging flags that require metadata to be stored in the slab. These get - * disabled when slub_debug=O is used and a cache's min order increases with + * disabled when slab_debug=O is used and a cache's min order increases with * metadata. */ #define DEBUG_METADATA_FLAGS (SLAB_RED_ZONE | SLAB_POISON | SLAB_STORE_USER) @@ -1616,7 +1616,7 @@ static inline int free_consistency_checks(struct kmem_cache *s, } /* - * Parse a block of slub_debug options. Blocks are delimited by ';' + * Parse a block of slab_debug options. Blocks are delimited by ';' * * @str: start of block * @flags: returns parsed flags, or DEBUG_DEFAULT_FLAGS if none specified @@ -1677,7 +1677,7 @@ parse_slub_debug_flags(char *str, slab_flags_t *flags, char **slabs, bool init) break; default: if (init) - pr_err("slub_debug option '%c' unknown. skipped\n", *str); + pr_err("slab_debug option '%c' unknown. skipped\n", *str); } } check_slabs: @@ -1736,7 +1736,7 @@ static int __init setup_slub_debug(char *str) /* * For backwards compatibility, a single list of flags with list of * slabs means debugging is only changed for those slabs, so the global - * slub_debug should be unchanged (0 or DEBUG_DEFAULT_FLAGS, depending + * slab_debug should be unchanged (0 or DEBUG_DEFAULT_FLAGS, depending * on CONFIG_SLUB_DEBUG_ON). We can extended that to multiple lists as * long as there is no option specifying flags without a slab list. */ @@ -1760,7 +1760,8 @@ out: return 1; } -__setup("slub_debug", setup_slub_debug); +__setup("slab_debug", setup_slub_debug); +__setup_param("slub_debug", slub_debug, setup_slub_debug, 0); /* * kmem_cache_flags - apply debugging options to the cache @@ -1770,7 +1771,7 @@ __setup("slub_debug", setup_slub_debug); * * Debug option(s) are applied to @flags. In addition to the debug * option(s), if a slab name (or multiple) is specified i.e. - * slub_debug=,, ... + * slab_debug=,, ... * then only the select slabs will receive the debug option(s). */ slab_flags_t kmem_cache_flags(unsigned int object_size, @@ -3263,7 +3264,7 @@ slab_out_of_memory(struct kmem_cache *s, gfp_t gfpflags, int nid) oo_order(s->min)); if (oo_order(s->min) > get_order(s->object_size)) - pr_warn(" %s debugging increased min order, use slub_debug=O to disable.\n", + pr_warn(" %s debugging increased min order, use slab_debug=O to disable.\n", s->name); for_each_kmem_cache_node(s, node, n) { @@ -3792,11 +3793,11 @@ void slab_post_alloc_hook(struct kmem_cache *s, struct obj_cgroup *objcg, zero_size = orig_size; /* - * When slub_debug is enabled, avoid memory initialization integrated + * When slab_debug is enabled, avoid memory initialization integrated * into KASAN and instead zero out the memory via the memset below with * the proper size. Otherwise, KASAN might overwrite SLUB redzones and * cause false-positive reports. This does not lead to a performance - * penalty on production builds, as slub_debug is not intended to be + * penalty on production builds, as slab_debug is not intended to be * enabled there. */ if (__slub_debug_enabled()) @@ -4702,8 +4703,8 @@ static unsigned int slub_min_objects; * activity on the partial lists which requires taking the list_lock. This is * less a concern for large slabs though which are rarely used. * - * slub_max_order specifies the order where we begin to stop considering the - * number of objects in a slab as critical. If we reach slub_max_order then + * slab_max_order specifies the order where we begin to stop considering the + * number of objects in a slab as critical. If we reach slab_max_order then * we try to keep the page order as low as possible. So we accept more waste * of space in favor of a small page order. * @@ -4770,14 +4771,14 @@ static inline int calculate_order(unsigned int size) * and backing off gradually. * * We start with accepting at most 1/16 waste and try to find the - * smallest order from min_objects-derived/slub_min_order up to - * slub_max_order that will satisfy the constraint. Note that increasing + * smallest order from min_objects-derived/slab_min_order up to + * slab_max_order that will satisfy the constraint. Note that increasing * the order can only result in same or less fractional waste, not more. * * If that fails, we increase the acceptable fraction of waste and try * again. The last iteration with fraction of 1/2 would effectively * accept any waste and give us the order determined by min_objects, as - * long as at least single object fits within slub_max_order. + * long as at least single object fits within slab_max_order. */ for (unsigned int fraction = 16; fraction > 1; fraction /= 2) { order = calc_slab_order(size, min_order, slub_max_order, @@ -4787,7 +4788,7 @@ static inline int calculate_order(unsigned int size) } /* - * Doh this slab cannot be placed using slub_max_order. + * Doh this slab cannot be placed using slab_max_order. */ order = get_order(size); if (order <= MAX_PAGE_ORDER) @@ -5313,7 +5314,9 @@ static int __init setup_slub_min_order(char *str) return 1; } -__setup("slub_min_order=", setup_slub_min_order); +__setup("slab_min_order=", setup_slub_min_order); +__setup_param("slub_min_order=", slub_min_order, setup_slub_min_order, 0); + static int __init setup_slub_max_order(char *str) { @@ -5326,7 +5329,8 @@ static int __init setup_slub_max_order(char *str) return 1; } -__setup("slub_max_order=", setup_slub_max_order); +__setup("slab_max_order=", setup_slub_max_order); +__setup_param("slub_max_order=", slub_max_order, setup_slub_max_order, 0); static int __init setup_slub_min_objects(char *str) { @@ -5335,7 +5339,8 @@ static int __init setup_slub_min_objects(char *str) return 1; } -__setup("slub_min_objects=", setup_slub_min_objects); +__setup("slab_min_objects=", setup_slub_min_objects); +__setup_param("slub_min_objects=", slub_min_objects, setup_slub_min_objects, 0); #ifdef CONFIG_HARDENED_USERCOPY /* -- cgit v1.2.3 From cb109a9d607056915d6a0dc8e1ebfc5854c72d92 Mon Sep 17 00:00:00 2001 From: Xiongwei Song Date: Fri, 15 Dec 2023 11:41:49 +0800 Subject: mm/slub: replace slub_$params with slab_$params in slub.rst We've unified slab parameters with "slab_$params", then we can use slab_$params in Documentation/mm/slub.rst. Signed-off-by: Xiongwei Song Reviewed-by: Vlastimil Babka Signed-off-by: Vlastimil Babka --- Documentation/mm/slub.rst | 60 +++++++++++++++++++++++------------------------ 1 file changed, 30 insertions(+), 30 deletions(-) (limited to 'Documentation') diff --git a/Documentation/mm/slub.rst b/Documentation/mm/slub.rst index be75971532f5..6579a55b7852 100644 --- a/Documentation/mm/slub.rst +++ b/Documentation/mm/slub.rst @@ -9,7 +9,7 @@ SLUB can enable debugging only for selected slabs in order to avoid an impact on overall system performance which may make a bug more difficult to find. -In order to switch debugging on one can add an option ``slub_debug`` +In order to switch debugging on one can add an option ``slab_debug`` to the kernel command line. That will enable full debugging for all slabs. @@ -26,16 +26,16 @@ be enabled on the command line. F.e. no tracking information will be available without debugging on and validation can only partially be performed if debugging was not switched on. -Some more sophisticated uses of slub_debug: +Some more sophisticated uses of slab_debug: ------------------------------------------- -Parameters may be given to ``slub_debug``. If none is specified then full +Parameters may be given to ``slab_debug``. If none is specified then full debugging is enabled. Format: -slub_debug= +slab_debug= Enable options for all slabs -slub_debug=,,,... +slab_debug=,,,... Enable options only for select slabs (no spaces after a comma) @@ -60,23 +60,23 @@ Possible debug options are:: F.e. in order to boot just with sanity checks and red zoning one would specify:: - slub_debug=FZ + slab_debug=FZ Trying to find an issue in the dentry cache? Try:: - slub_debug=,dentry + slab_debug=,dentry to only enable debugging on the dentry cache. You may use an asterisk at the end of the slab name, in order to cover all slabs with the same prefix. For example, here's how you can poison the dentry cache as well as all kmalloc slabs:: - slub_debug=P,kmalloc-*,dentry + slab_debug=P,kmalloc-*,dentry Red zoning and tracking may realign the slab. We can just apply sanity checks to the dentry cache with:: - slub_debug=F,dentry + slab_debug=F,dentry Debugging options may require the minimum possible slab order to increase as a result of storing the metadata (for example, caches with PAGE_SIZE object @@ -84,20 +84,20 @@ sizes). This has a higher liklihood of resulting in slab allocation errors in low memory situations or if there's high fragmentation of memory. To switch off debugging for such caches by default, use:: - slub_debug=O + slab_debug=O You can apply different options to different list of slab names, using blocks of options. This will enable red zoning for dentry and user tracking for kmalloc. All other slabs will not get any debugging enabled:: - slub_debug=Z,dentry;U,kmalloc-* + slab_debug=Z,dentry;U,kmalloc-* You can also enable options (e.g. sanity checks and poisoning) for all caches except some that are deemed too performance critical and don't need to be debugged by specifying global debug options followed by a list of slab names with "-" as options:: - slub_debug=FZ;-,zs_handle,zspage + slab_debug=FZ;-,zs_handle,zspage The state of each debug option for a slab can be found in the respective files under:: @@ -105,7 +105,7 @@ under:: /sys/kernel/slab// If the file contains 1, the option is enabled, 0 means disabled. The debug -options from the ``slub_debug`` parameter translate to the following files:: +options from the ``slab_debug`` parameter translate to the following files:: F sanity_checks Z red_zone @@ -129,7 +129,7 @@ in order to reduce overhead and increase cache hotness of objects. Slab validation =============== -SLUB can validate all object if the kernel was booted with slub_debug. In +SLUB can validate all object if the kernel was booted with slab_debug. In order to do so you must have the ``slabinfo`` tool. Then you can do :: @@ -150,29 +150,29 @@ list_lock once in a while to deal with partial slabs. That overhead is governed by the order of the allocation for each slab. The allocations can be influenced by kernel parameters: -.. slub_min_objects=x (default 4) -.. slub_min_order=x (default 0) -.. slub_max_order=x (default 3 (PAGE_ALLOC_COSTLY_ORDER)) +.. slab_min_objects=x (default 4) +.. slab_min_order=x (default 0) +.. slab_max_order=x (default 3 (PAGE_ALLOC_COSTLY_ORDER)) -``slub_min_objects`` +``slab_min_objects`` allows to specify how many objects must at least fit into one slab in order for the allocation order to be acceptable. In general slub will be able to perform this number of allocations on a slab without consulting centralized resources (list_lock) where contention may occur. -``slub_min_order`` +``slab_min_order`` specifies a minimum order of slabs. A similar effect like - ``slub_min_objects``. + ``slab_min_objects``. -``slub_max_order`` - specified the order at which ``slub_min_objects`` should no +``slab_max_order`` + specified the order at which ``slab_min_objects`` should no longer be checked. This is useful to avoid SLUB trying to - generate super large order pages to fit ``slub_min_objects`` + generate super large order pages to fit ``slab_min_objects`` of a slab cache with large object sizes into one high order page. Setting command line parameter ``debug_guardpage_minorder=N`` (N > 0), forces setting - ``slub_max_order`` to 0, what cause minimum possible order of + ``slab_max_order`` to 0, what cause minimum possible order of slabs allocation. SLUB Debug output @@ -219,7 +219,7 @@ Here is a sample of slub debug output:: FIX kmalloc-8: Restoring Redzone 0xc90f6d28-0xc90f6d2b=0xcc If SLUB encounters a corrupted object (full detection requires the kernel -to be booted with slub_debug) then the following output will be dumped +to be booted with slab_debug) then the following output will be dumped into the syslog: 1. Description of the problem encountered @@ -239,7 +239,7 @@ into the syslog: pid= (Object allocation / free information is only available if SLAB_STORE_USER is - set for the slab. slub_debug sets that option) + set for the slab. slab_debug sets that option) 2. The object contents if an object was involved. @@ -262,7 +262,7 @@ into the syslog: the object boundary. (Redzone information is only available if SLAB_RED_ZONE is set. - slub_debug sets that option) + slab_debug sets that option) Padding
: Unused data to fill up the space in order to get the next object @@ -296,7 +296,7 @@ Emergency operations Minimal debugging (sanity checks alone) can be enabled by booting with:: - slub_debug=F + slab_debug=F This will be generally be enough to enable the resiliency features of slub which will keep the system running even if a bad kernel component will @@ -311,13 +311,13 @@ and enabling debugging only for that cache I.e.:: - slub_debug=F,dentry + slab_debug=F,dentry If the corruption occurs by writing after the end of the object then it may be advisable to enable a Redzone to avoid corrupting the beginning of other objects:: - slub_debug=FZ,dentry + slab_debug=FZ,dentry Extended slabinfo mode and plotting =================================== -- cgit v1.2.3 From 98d3b6d98f8013d4e96f40d8d4b22d4da0d3f699 Mon Sep 17 00:00:00 2001 From: Xiongwei Song Date: Fri, 15 Dec 2023 11:41:50 +0800 Subject: mm/slub: make the description of slab_min_objects helpful in doc There is no a value assigned to slab_min_objects by default, it always is 0 that is initialized by compiler if no assigned value by command line. min_objects is calculated based on processor numbers in calculate_order(). For more details, see commit 9b2cd506e5f2 ("slub: Calculate min_objects based on number of processors.") Signed-off-by: Xiongwei Song Reviewed-by: Vlastimil Babka Signed-off-by: Vlastimil Babka --- Documentation/mm/slub.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/mm/slub.rst b/Documentation/mm/slub.rst index 6579a55b7852..b517ee28a955 100644 --- a/Documentation/mm/slub.rst +++ b/Documentation/mm/slub.rst @@ -150,7 +150,7 @@ list_lock once in a while to deal with partial slabs. That overhead is governed by the order of the allocation for each slab. The allocations can be influenced by kernel parameters: -.. slab_min_objects=x (default 4) +.. slab_min_objects=x (default: automatically scaled by number of cpus) .. slab_min_order=x (default 0) .. slab_max_order=x (default 3 (PAGE_ALLOC_COSTLY_ORDER)) -- cgit v1.2.3 From 32a0a0da530eab78d755474270bf53274b93a1e6 Mon Sep 17 00:00:00 2001 From: Kent Gibson Date: Mon, 15 Jan 2024 08:48:39 +0800 Subject: Documentation: gpio: add chardev userspace API documentation Add documentation for the GPIO character device userspace API. Added to the userspace-api book, but also provide a link from the admin-guide book, as historically the GPIO documentation has been there. Signed-off-by: Kent Gibson Reviewed-by: Linus Walleij Signed-off-by: Bartosz Golaszewski --- Documentation/admin-guide/gpio/index.rst | 1 + Documentation/userspace-api/gpio/chardev.rst | 116 +++++++++++++++++++++ Documentation/userspace-api/gpio/error-codes.rst | 78 ++++++++++++++ .../userspace-api/gpio/gpio-get-chipinfo-ioctl.rst | 41 ++++++++ .../gpio/gpio-get-lineinfo-unwatch-ioctl.rst | 49 +++++++++ .../userspace-api/gpio/gpio-v2-get-line-ioctl.rst | 101 ++++++++++++++++++ .../gpio/gpio-v2-get-lineinfo-ioctl.rst | 50 +++++++++ .../gpio/gpio-v2-get-lineinfo-watch-ioctl.rst | 67 ++++++++++++ .../userspace-api/gpio/gpio-v2-line-event-read.rst | 83 +++++++++++++++ .../gpio/gpio-v2-line-get-values-ioctl.rst | 51 +++++++++ .../gpio/gpio-v2-line-set-config-ioctl.rst | 57 ++++++++++ .../gpio/gpio-v2-line-set-values-ioctl.rst | 47 +++++++++ .../gpio/gpio-v2-lineinfo-changed-read.rst | 81 ++++++++++++++ Documentation/userspace-api/gpio/index.rst | 17 +++ Documentation/userspace-api/index.rst | 1 + 15 files changed, 840 insertions(+) create mode 100644 Documentation/userspace-api/gpio/chardev.rst create mode 100644 Documentation/userspace-api/gpio/error-codes.rst create mode 100644 Documentation/userspace-api/gpio/gpio-get-chipinfo-ioctl.rst create mode 100644 Documentation/userspace-api/gpio/gpio-get-lineinfo-unwatch-ioctl.rst create mode 100644 Documentation/userspace-api/gpio/gpio-v2-get-line-ioctl.rst create mode 100644 Documentation/userspace-api/gpio/gpio-v2-get-lineinfo-ioctl.rst create mode 100644 Documentation/userspace-api/gpio/gpio-v2-get-lineinfo-watch-ioctl.rst create mode 100644 Documentation/userspace-api/gpio/gpio-v2-line-event-read.rst create mode 100644 Documentation/userspace-api/gpio/gpio-v2-line-get-values-ioctl.rst create mode 100644 Documentation/userspace-api/gpio/gpio-v2-line-set-config-ioctl.rst create mode 100644 Documentation/userspace-api/gpio/gpio-v2-line-set-values-ioctl.rst create mode 100644 Documentation/userspace-api/gpio/gpio-v2-lineinfo-changed-read.rst create mode 100644 Documentation/userspace-api/gpio/index.rst (limited to 'Documentation') diff --git a/Documentation/admin-guide/gpio/index.rst b/Documentation/admin-guide/gpio/index.rst index f6861ca16ffe..b40f0a2a6822 100644 --- a/Documentation/admin-guide/gpio/index.rst +++ b/Documentation/admin-guide/gpio/index.rst @@ -7,6 +7,7 @@ gpio .. toctree:: :maxdepth: 1 + Character Device Userspace API <../../userspace-api/gpio/chardev> gpio-aggregator sysfs gpio-mockup diff --git a/Documentation/userspace-api/gpio/chardev.rst b/Documentation/userspace-api/gpio/chardev.rst new file mode 100644 index 000000000000..c58dd9771ac9 --- /dev/null +++ b/Documentation/userspace-api/gpio/chardev.rst @@ -0,0 +1,116 @@ +.. SPDX-License-Identifier: GPL-2.0 + +=================================== +GPIO Character Device Userspace API +=================================== + +This is latest version (v2) of the character device API, as defined in +``include/uapi/linux/gpio.h.`` + +First added in 5.10. + +.. note:: + Do NOT abuse userspace APIs to control hardware that has proper kernel + drivers. There may already be a driver for your use case, and an existing + kernel driver is sure to provide a superior solution to bitbashing + from userspace. + + Read Documentation/driver-api/gpio/drivers-on-gpio.rst to avoid reinventing + kernel wheels in userspace. + + Similarly, for multi-function lines there may be other subsystems, such as + Documentation/spi/index.rst, Documentation/i2c/index.rst, + Documentation/driver-api/pwm.rst, Documentation/w1/index.rst etc, that + provide suitable drivers and APIs for your hardware. + +Basic examples using the character device API can be found in ``tools/gpio/*``. + +The API is based around two major objects, the :ref:`gpio-v2-chip` and the +:ref:`gpio-v2-line-request`. + +.. _gpio-v2-chip: + +Chip +==== + +The Chip represents a single GPIO chip and is exposed to userspace using device +files of the form ``/dev/gpiochipX``. + +Each chip supports a number of GPIO lines, +:c:type:`chip.lines`. Lines on the chip are identified by an +``offset`` in the range from 0 to ``chip.lines - 1``, i.e. `[0,chip.lines)`. + +Lines are requested from the chip using gpio-v2-get-line-ioctl.rst +and the resulting line request is used to access the GPIO chip's lines or +monitor the lines for edge events. + +Within this documentation, the file descriptor returned by calling `open()` +on the GPIO device file is referred to as ``chip_fd``. + +Operations +---------- + +The following operations may be performed on the chip: + +.. toctree:: + :titlesonly: + + Get Line + Get Chip Info + Get Line Info + Watch Line Info + Unwatch Line Info + Read Line Info Changed Events + +.. _gpio-v2-line-request: + +Line Request +============ + +Line requests are created by gpio-v2-get-line-ioctl.rst and provide +access to a set of requested lines. The line request is exposed to userspace +via the anonymous file descriptor returned in +:c:type:`request.fd` by gpio-v2-get-line-ioctl.rst. + +Within this documentation, the line request file descriptor is referred to +as ``req_fd``. + +Operations +---------- + +The following operations may be performed on the line request: + +.. toctree:: + :titlesonly: + + Get Line Values + Set Line Values + Read Line Edge Events + Reconfigure Lines + +Types +===== + +This section contains the structs and enums that are referenced by the API v2, +as defined in ``include/uapi/linux/gpio.h``. + +.. kernel-doc:: include/uapi/linux/gpio.h + :identifiers: + gpio_v2_line_attr_id + gpio_v2_line_attribute + gpio_v2_line_changed_type + gpio_v2_line_config + gpio_v2_line_config_attribute + gpio_v2_line_event + gpio_v2_line_event_id + gpio_v2_line_flag + gpio_v2_line_info + gpio_v2_line_info_changed + gpio_v2_line_request + gpio_v2_line_values + gpiochip_info + +.. toctree:: + :hidden: + + error-codes diff --git a/Documentation/userspace-api/gpio/error-codes.rst b/Documentation/userspace-api/gpio/error-codes.rst new file mode 100644 index 000000000000..edf01f2cf9d2 --- /dev/null +++ b/Documentation/userspace-api/gpio/error-codes.rst @@ -0,0 +1,78 @@ +.. SPDX-License-Identifier: GPL-2.0 + +.. _gpio_errors: + +******************* +GPIO Error Codes +******************* + +.. _gpio-errors: + +.. tabularcolumns:: |p{2.5cm}|p{15.0cm}| + +.. flat-table:: Common GPIO error codes + :header-rows: 0 + :stub-columns: 0 + :widths: 1 16 + + - - ``EAGAIN`` (aka ``EWOULDBLOCK``) + + - The device was opened in non-blocking mode and a read can't + be performed as there is no data available. + + - - ``EBADF`` + + - The file descriptor is not valid. + + - - ``EBUSY`` + + - The ioctl can't be handled because the device is busy. Typically + returned when an ioctl attempts something that would require the + usage of a resource that was already allocated. The ioctl must not + be retried without performing another action to fix the problem + first. + + - - ``EFAULT`` + + - There was a failure while copying data from/to userspace, probably + caused by an invalid pointer reference. + + - - ``EINVAL`` + + - One or more of the ioctl parameters are invalid or out of the + allowed range. This is a widely used error code. + + - - ``ENODEV`` + + - Device not found or was removed. + + - - ``ENOMEM`` + + - There's not enough memory to handle the desired operation. + + - - ``EPERM`` + + - Permission denied. Typically returned in response to an attempt + to perform an action incompatible with the current line + configuration. + + - - ``EIO`` + + - I/O error. Typically returned when there are problems communicating + with a hardware device or requesting features that hardware does not + support. This could indicate broken or flaky hardware. + It's a 'Something is wrong, I give up!' type of error. + + - - ``ENXIO`` + + - No device corresponding to this device special file exists. + +.. note:: + + #. This list is not exhaustive; ioctls may return other error codes. + Since errors may have side effects such as a driver reset, + applications should abort on unexpected errors, or otherwise + assume that the device is in a bad state. + + #. Request-specific error codes are listed in the individual + requests descriptions. diff --git a/Documentation/userspace-api/gpio/gpio-get-chipinfo-ioctl.rst b/Documentation/userspace-api/gpio/gpio-get-chipinfo-ioctl.rst new file mode 100644 index 000000000000..05f07fdefe2f --- /dev/null +++ b/Documentation/userspace-api/gpio/gpio-get-chipinfo-ioctl.rst @@ -0,0 +1,41 @@ +.. SPDX-License-Identifier: GPL-2.0 + +.. _GPIO_GET_CHIPINFO_IOCTL: + +*********************** +GPIO_GET_CHIPINFO_IOCTL +*********************** + +Name +==== + +GPIO_GET_CHIPINFO_IOCTL - Get the publicly available information for a chip. + +Synopsis +======== + +.. c:macro:: GPIO_GET_CHIPINFO_IOCTL + +``int ioctl(int chip_fd, GPIO_GET_CHIPINFO_IOCTL, struct gpiochip_info *info)`` + +Arguments +========= + +``chip_fd`` + The file descriptor of the GPIO character device returned by `open()`. + +``info`` + The :c:type:`chip_info` to be populated. + +Description +=========== + +Gets the publicly available information for a particular GPIO chip. + +Return Value +============ + +On success 0 and ``info`` is populated with the chip info. + +On error -1 and the ``errno`` variable is set appropriately. +Common error codes are described in error-codes.rst. diff --git a/Documentation/userspace-api/gpio/gpio-get-lineinfo-unwatch-ioctl.rst b/Documentation/userspace-api/gpio/gpio-get-lineinfo-unwatch-ioctl.rst new file mode 100644 index 000000000000..2fec6f12e3bf --- /dev/null +++ b/Documentation/userspace-api/gpio/gpio-get-lineinfo-unwatch-ioctl.rst @@ -0,0 +1,49 @@ +.. SPDX-License-Identifier: GPL-2.0 + +.. _GPIO_GET_LINEINFO_UNWATCH_IOCTL: + +******************************* +GPIO_GET_LINEINFO_UNWATCH_IOCTL +******************************* + +Name +==== + +GPIO_GET_LINEINFO_UNWATCH_IOCTL - Disable watching a line for changes to its +requested state and configuration information. + +Synopsis +======== + +.. c:macro:: GPIO_GET_LINEINFO_UNWATCH_IOCTL + +``int ioctl(int chip_fd, GPIO_GET_LINEINFO_UNWATCH_IOCTL, u32 *offset)`` + +Arguments +========= + +``chip_fd`` + The file descriptor of the GPIO character device returned by `open()`. + +``offset`` + The offset of the line to no longer watch. + +Description +=========== + +Remove the line from the list of lines being watched on this ``chip_fd``. + +This is the opposite of gpio-v2-get-lineinfo-watch-ioctl.rst (v2) and +gpio-get-lineinfo-watch-ioctl.rst (v1). + +Unwatching a line that is not watched is an error (**EBUSY**). + +First added in 5.7. + +Return Value +============ + +On success 0. + +On error -1 and the ``errno`` variable is set appropriately. +Common error codes are described in error-codes.rst. diff --git a/Documentation/userspace-api/gpio/gpio-v2-get-line-ioctl.rst b/Documentation/userspace-api/gpio/gpio-v2-get-line-ioctl.rst new file mode 100644 index 000000000000..d76e614c8343 --- /dev/null +++ b/Documentation/userspace-api/gpio/gpio-v2-get-line-ioctl.rst @@ -0,0 +1,101 @@ +.. SPDX-License-Identifier: GPL-2.0 + +.. _GPIO_V2_GET_LINE_IOCTL: + +********************** +GPIO_V2_GET_LINE_IOCTL +********************** + +Name +==== + +GPIO_V2_GET_LINE_IOCTL - Request a line or lines from the kernel. + +Synopsis +======== + +.. c:macro:: GPIO_V2_GET_LINE_IOCTL + +``int ioctl(int chip_fd, GPIO_V2_GET_LINE_IOCTL, struct gpio_v2_line_request *request)`` + +Arguments +========= + +``chip_fd`` + The file descriptor of the GPIO character device returned by `open()`. + +``request`` + The :c:type:`line_request` specifying the lines + to request and their configuration. + +Description +=========== + +On success, the requesting process is granted exclusive access to the line +value, write access to the line configuration, and may receive events when +edges are detected on the line, all of which are described in more detail in +:ref:`gpio-v2-line-request`. + +A number of lines may be requested in the one line request, and request +operations are performed on the requested lines by the kernel as atomically +as possible. e.g. gpio-v2-line-get-values-ioctl.rst will read all the +requested lines at once. + +The state of a line, including the value of output lines, is guaranteed to +remain as requested until the returned file descriptor is closed. Once the +file descriptor is closed, the state of the line becomes uncontrolled from +the userspace perspective, and may revert to its default state. + +Requesting a line already in use is an error (**EBUSY**). + +Closing the ``chip_fd`` has no effect on existing line requests. + +.. _gpio-v2-get-line-config-rules: + +Configuration Rules +------------------- + +For any given requested line, the following configuration rules apply: + +The direction flags, ``GPIO_V2_LINE_FLAG_INPUT`` and +``GPIO_V2_LINE_FLAG_OUTPUT``, cannot be combined. If neither are set then +the only other flag that may be set is ``GPIO_V2_LINE_FLAG_ACTIVE_LOW`` +and the line is requested "as-is" to allow reading of the line value +without altering the electrical configuration. + +The drive flags, ``GPIO_V2_LINE_FLAG_OPEN_xxx``, require the +``GPIO_V2_LINE_FLAG_OUTPUT`` to be set. +Only one drive flag may be set. +If none are set then the line is assumed push-pull. + +Only one bias flag, ``GPIO_V2_LINE_FLAG_BIAS_xxx``, may be set, and it +requires a direction flag to also be set. +If no bias flags are set then the bias configuration is not changed. + +The edge flags, ``GPIO_V2_LINE_FLAG_EDGE_xxx``, require +``GPIO_V2_LINE_FLAG_INPUT`` to be set and may be combined to detect both rising +and falling edges. + +Only one event clock flag, ``GPIO_V2_LINE_FLAG_EVENT_CLOCK_xxx``, may be set. +If none are set then the event clock defaults to ``CLOCK_MONOTONIC``. +The ``GPIO_V2_LINE_FLAG_EVENT_CLOCK_HTE`` flag requires supporting hardware +and a kernel with ``CONFIG_HTE`` set. Requesting HTE from a device that +doesn't support it is an error (**EOPNOTSUP**). + +The :c:type:`debounce_period_us` attribute may only +be applied to lines with ``GPIO_V2_LINE_FLAG_INPUT`` set. When set, debounce +applies to both the values returned by gpio-v2-line-get-values-ioctl.rst and +the edges returned by gpio-v2-line-event-read.rst. If not +supported directly by hardware, the debouncing is performed in software by the +kernel. + +Requesting an invalid configuration is an error (**EINVAL**). + +Return Value +============ + +On success 0 and the :c:type:`request.fd` contains the +file descriptor for the request. + +On error -1 and the ``errno`` variable is set appropriately. +Common error codes are described in error-codes.rst. diff --git a/Documentation/userspace-api/gpio/gpio-v2-get-lineinfo-ioctl.rst b/Documentation/userspace-api/gpio/gpio-v2-get-lineinfo-ioctl.rst new file mode 100644 index 000000000000..bc4d8df887d4 --- /dev/null +++ b/Documentation/userspace-api/gpio/gpio-v2-get-lineinfo-ioctl.rst @@ -0,0 +1,50 @@ +.. SPDX-License-Identifier: GPL-2.0 + +.. _GPIO_V2_GET_LINEINFO_IOCTL: + +************************** +GPIO_V2_GET_LINEINFO_IOCTL +************************** + +Name +==== + +GPIO_V2_GET_LINEINFO_IOCTL - Get the publicly available information for a line. + +Synopsis +======== + +.. c:macro:: GPIO_V2_GET_LINEINFO_IOCTL + +``int ioctl(int chip_fd, GPIO_V2_GET_LINEINFO_IOCTL, struct gpio_v2_line_info *info)`` + +Arguments +========= + +``chip_fd`` + The file descriptor of the GPIO character device returned by `open()`. + +``info`` + The :c:type:`line_info` to be populated, with the + ``offset`` field set to indicate the line to be collected. + +Description +=========== + +Get the publicly available information for a line. + +This information is available independent of whether the line is in use. + +.. note:: + The line info does not include the line value. + + The line must be requested using gpio-v2-get-line-ioctl.rst to access its + value. + +Return Value +============ + +On success 0 and ``info`` is populated with the chip info. + +On error -1 and the ``errno`` variable is set appropriately. +Common error codes are described in error-codes.rst. diff --git a/Documentation/userspace-api/gpio/gpio-v2-get-lineinfo-watch-ioctl.rst b/Documentation/userspace-api/gpio/gpio-v2-get-lineinfo-watch-ioctl.rst new file mode 100644 index 000000000000..938ff85a9322 --- /dev/null +++ b/Documentation/userspace-api/gpio/gpio-v2-get-lineinfo-watch-ioctl.rst @@ -0,0 +1,67 @@ +.. SPDX-License-Identifier: GPL-2.0 + +.. _GPIO_V2_GET_LINEINFO_WATCH_IOCTL: + +******************************** +GPIO_V2_GET_LINEINFO_WATCH_IOCTL +******************************** + +Name +==== + +GPIO_V2_GET_LINEINFO_WATCH_IOCTL - Enable watching a line for changes to its +request state and configuration information. + +Synopsis +======== + +.. c:macro:: GPIO_V2_GET_LINEINFO_WATCH_IOCTL + +``int ioctl(int chip_fd, GPIO_V2_GET_LINEINFO_WATCH_IOCTL, struct gpio_v2_line_info *info)`` + +Arguments +========= + +``chip_fd`` + The file descriptor of the GPIO character device returned by `open()`. + +``info`` + The :c:type:`line_info` struct to be populated, with + the ``offset`` set to indicate the line to watch + +Description +=========== + +Enable watching a line for changes to its request state and configuration +information. Changes to line info include a line being requested, released +or reconfigured. + +.. note:: + Watching line info is not generally required, and would typically only be + used by a system monitoring component. + + The line info does NOT include the line value. + The line must be requested using gpio-v2-get-line-ioctl.rst to access + its value, and the line request can monitor a line for events using + gpio-v2-line-event-read.rst. + +By default all lines are unwatched when the GPIO chip is opened. + +Multiple lines may be watched simultaneously by adding a watch for each. + +Once a watch is set, any changes to line info will generate events which can be +read from the ``chip_fd`` as described in +gpio-v2-lineinfo-changed-read.rst. + +Adding a watch to a line that is already watched is an error (**EBUSY**). + +Watches are specific to the ``chip_fd`` and are independent of watches +on the same GPIO chip opened with a separate call to `open()`. + +Return Value +============ + +On success 0 and ``info`` is populated with the current line info. + +On error -1 and the ``errno`` variable is set appropriately. +Common error codes are described in error-codes.rst. diff --git a/Documentation/userspace-api/gpio/gpio-v2-line-event-read.rst b/Documentation/userspace-api/gpio/gpio-v2-line-event-read.rst new file mode 100644 index 000000000000..6513c23fb7ca --- /dev/null +++ b/Documentation/userspace-api/gpio/gpio-v2-line-event-read.rst @@ -0,0 +1,83 @@ +.. SPDX-License-Identifier: GPL-2.0 + +.. _GPIO_V2_LINE_EVENT_READ: + +*********************** +GPIO_V2_LINE_EVENT_READ +*********************** + +Name +==== + +GPIO_V2_LINE_EVENT_READ - Read edge detection events for lines from a request. + +Synopsis +======== + +``int read(int req_fd, void *buf, size_t count)`` + +Arguments +========= + +``req_fd`` + The file descriptor of the GPIO character device, as returned in the + :c:type:`request.fd` by gpio-v2-get-line-ioctl.rst. + +``buf`` + The buffer to contain the :c:type:`events`. + +``count`` + The number of bytes available in ``buf``, which must be at + least the size of a :c:type:`gpio_v2_line_event`. + +Description +=========== + +Read edge detection events for lines from a request. + +Edge detection must be enabled for the input line using either +``GPIO_V2_LINE_FLAG_EDGE_RISING`` or ``GPIO_V2_LINE_FLAG_EDGE_FALLING``, or +both. Edge events are then generated whenever edge interrupts are detected on +the input line. + +The kernel captures and timestamps edge events as close as possible to their +occurrence and stores them in a buffer from where they can be read by +userspace at its convenience using `read()`. + +Events read from the buffer are always in the same order that they were +detected by the kernel, including when multiple lines are being monitored by +the one request. + +The size of the kernel event buffer is fixed at the time of line request +creation, and can be influenced by the +:c:type:`request.event_buffer_size`. +The default size is 16 times the number of lines requested. + +The buffer may overflow if bursts of events occur quicker than they are read +by userspace. If an overflow occurs then the oldest buffered event is +discarded. Overflow can be detected from userspace by monitoring the event +sequence numbers. + +To minimize the number of calls required to copy events from the kernel to +userspace, `read()` supports copying multiple events. The number of events +copied is the lower of the number available in the kernel buffer and the +number that will fit in the userspace buffer (``buf``). + +Changing the edge detection flags using gpio-v2-line-set-config-ioctl.rst +does not remove or modify the events already contained in the kernel event +buffer. + +The `read()` will block if no event is available and the ``req_fd`` has not +been set **O_NONBLOCK**. + +The presence of an event can be tested for by checking that the ``req_fd`` is +readable using `poll()` or an equivalent. + +Return Value +============ + +On success the number of bytes read, which will be a multiple of the size of a +:c:type:`gpio_v2_line_event` event. + +On error -1 and the ``errno`` variable is set appropriately. +Common error codes are described in error-codes.rst. diff --git a/Documentation/userspace-api/gpio/gpio-v2-line-get-values-ioctl.rst b/Documentation/userspace-api/gpio/gpio-v2-line-get-values-ioctl.rst new file mode 100644 index 000000000000..e4e74a1926d8 --- /dev/null +++ b/Documentation/userspace-api/gpio/gpio-v2-line-get-values-ioctl.rst @@ -0,0 +1,51 @@ +.. SPDX-License-Identifier: GPL-2.0 + +.. _GPIO_V2_LINE_GET_VALUES_IOCTL: + +***************************** +GPIO_V2_LINE_GET_VALUES_IOCTL +***************************** + +Name +==== + +GPIO_V2_LINE_GET_VALUES_IOCTL - Get the values of requested lines. + +Synopsis +======== + +.. c:macro:: GPIO_V2_LINE_GET_VALUES_IOCTL + +``int ioctl(int req_fd, GPIO_V2_LINE_GET_VALUES_IOCTL, struct gpio_v2_line_values *values)`` + +Arguments +========= + +``req_fd`` + The file descriptor of the GPIO character device, as returned in the + :c:type:`request.fd` by gpio-v2-get-line-ioctl.rst. + +``values`` + The :c:type:`line_values` to get with the ``mask`` set + to indicate the subset of requested lines to get. + +Description +=========== + +Get the values of requested lines. + +The values of both input and output lines may be read. + +For output lines, the value returned is driver and configuration dependent and +may be either the output buffer (the last requested value set) or the input +buffer (the actual level of the line), and depending on the hardware and +configuration these may differ. + +Return Value +============ + +On success 0 and the corresponding :c:type:`values.bits` +contain the value read. + +On error -1 and the ``errno`` variable is set appropriately. +Common error codes are described in error-codes.rst. diff --git a/Documentation/userspace-api/gpio/gpio-v2-line-set-config-ioctl.rst b/Documentation/userspace-api/gpio/gpio-v2-line-set-config-ioctl.rst new file mode 100644 index 000000000000..126c2626ba6b --- /dev/null +++ b/Documentation/userspace-api/gpio/gpio-v2-line-set-config-ioctl.rst @@ -0,0 +1,57 @@ +.. SPDX-License-Identifier: GPL-2.0 + +.. _GPIO_V2_LINE_SET_CONFIG_IOCTL: + +***************************** +GPIO_V2_LINE_SET_CONFIG_IOCTL +***************************** + +Name +==== + +GPIO_V2_LINE_SET_CONFIG_IOCTL - Update the configuration of previously requested lines. + +Synopsis +======== + +.. c:macro:: GPIO_V2_LINE_SET_CONFIG_IOCTL + +``int ioctl(int req_fd, GPIO_V2_LINE_SET_CONFIG_IOCTL, struct gpio_v2_line_config *config)`` + +Arguments +========= + +``req_fd`` + The file descriptor of the GPIO character device, as returned in the + :c:type:`request.fd` by gpio-v2-get-line-ioctl.rst. + +``config`` + The new :c:type:`configuration` to apply to the + requested lines. + +Description +=========== + +Update the configuration of previously requested lines, without releasing the +line or introducing potential glitches. + +The new configuration must specify the configuration of all requested lines. + +The same :ref:`gpio-v2-get-line-config-rules` that apply when requesting the lines +also apply when updating the line configuration. + +The motivating use case for this command is changing direction of +bi-directional lines between input and output, but it may also be used to +dynamically control edge detection, or more generally move lines seamlessly +from one configuration state to another. + +To only change the value of output lines, use +gpio-v2-line-set-values-ioctl.rst. + +Return Value +============ + +On success 0. + +On error -1 and the ``errno`` variable is set appropriately. +Common error codes are described in error-codes.rst. diff --git a/Documentation/userspace-api/gpio/gpio-v2-line-set-values-ioctl.rst b/Documentation/userspace-api/gpio/gpio-v2-line-set-values-ioctl.rst new file mode 100644 index 000000000000..6d2d1886950b --- /dev/null +++ b/Documentation/userspace-api/gpio/gpio-v2-line-set-values-ioctl.rst @@ -0,0 +1,47 @@ +.. SPDX-License-Identifier: GPL-2.0 + +.. _GPIO_V2_LINE_SET_VALUES_IOCTL: + +***************************** +GPIO_V2_LINE_SET_VALUES_IOCTL +***************************** + +Name +==== + +GPIO_V2_LINE_SET_VALUES_IOCTL - Set the values of requested output lines. + +Synopsis +======== + +.. c:macro:: GPIO_V2_LINE_SET_VALUES_IOCTL + +``int ioctl(int req_fd, GPIO_V2_LINE_SET_VALUES_IOCTL, struct gpio_v2_line_values *values)`` + +Arguments +========= + +``req_fd`` + The file descriptor of the GPIO character device, as returned in the + :c:type:`request.fd` by gpio-v2-get-line-ioctl.rst. + +``values`` + The :c:type:`line_values` to set with the ``mask`` set + to indicate the subset of requested lines to set and ``bits`` set to + indicate the new value. + +Description +=========== + +Set the values of requested output lines. + +Only the values of output lines may be set. +Attempting to set the value of an input line is an error (**EPERM**). + +Return Value +============ + +On success 0. + +On error -1 and the ``errno`` variable is set appropriately. +Common error codes are described in error-codes.rst. diff --git a/Documentation/userspace-api/gpio/gpio-v2-lineinfo-changed-read.rst b/Documentation/userspace-api/gpio/gpio-v2-lineinfo-changed-read.rst new file mode 100644 index 000000000000..24ad325e7253 --- /dev/null +++ b/Documentation/userspace-api/gpio/gpio-v2-lineinfo-changed-read.rst @@ -0,0 +1,81 @@ +.. SPDX-License-Identifier: GPL-2.0 + +.. _GPIO_V2_LINEINFO_CHANGED_READ: + +***************************** +GPIO_V2_LINEINFO_CHANGED_READ +***************************** + +Name +==== + +GPIO_V2_LINEINFO_CHANGED_READ - Read line info changed events for watched +lines from the chip. + +Synopsis +======== + +``int read(int chip_fd, void *buf, size_t count)`` + +Arguments +========= + +``chip_fd`` + The file descriptor of the GPIO character device returned by `open()`. + +``buf`` + The buffer to contain the :c:type:`events`. + +``count`` + The number of bytes available in ``buf``, which must be at least the size + of a :c:type:`gpio_v2_line_info_changed` event. + +Description +=========== + +Read line info changed events for watched lines from the chip. + +.. note:: + Monitoring line info changes is not generally required, and would typically + only be performed by a system monitoring component. + + These events relate to changes in a line's request state or configuration, + not its value. Use gpio-v2-line-event-read.rst to receive events when a + line changes value. + +A line must be watched using gpio-v2-get-lineinfo-watch-ioctl.rst to generate +info changed events. Subsequently, a request, release, or reconfiguration +of the line will generate an info changed event. + +The kernel timestamps events when they occur and stores them in a buffer +from where they can be read by userspace at its convenience using `read()`. + +The size of the kernel event buffer is fixed at 32 events per ``chip_fd``. + +The buffer may overflow if bursts of events occur quicker than they are read +by userspace. If an overflow occurs then the most recent event is discarded. +Overflow cannot be detected from userspace. + +Events read from the buffer are always in the same order that they were +detected by the kernel, including when multiple lines are being monitored by +the one ``chip_fd``. + +To minimize the number of calls required to copy events from the kernel to +userspace, `read()` supports copying multiple events. The number of events +copied is the lower of the number available in the kernel buffer and the +number that will fit in the userspace buffer (``buf``). + +A `read()` will block if no event is available and the ``chip_fd`` has not +been set **O_NONBLOCK**. + +The presence of an event can be tested for by checking that the ``chip_fd`` is +readable using `poll()` or an equivalent. + +Return Value +============ + +On success the number of bytes read, which will be a multiple of the size +of a :c:type:`gpio_v2_line_info_changed` event. + +On error -1 and the ``errno`` variable is set appropriately. +Common error codes are described in error-codes.rst. diff --git a/Documentation/userspace-api/gpio/index.rst b/Documentation/userspace-api/gpio/index.rst new file mode 100644 index 000000000000..072b9fa18aea --- /dev/null +++ b/Documentation/userspace-api/gpio/index.rst @@ -0,0 +1,17 @@ +.. SPDX-License-Identifier: GPL-2.0 + +==== +GPIO +==== + +.. toctree:: + :maxdepth: 1 + + Character Device Userspace API + +.. only:: subproject and html + + Indices + ======= + + * :ref:`genindex` diff --git a/Documentation/userspace-api/index.rst b/Documentation/userspace-api/index.rst index 09f61bd2ac2e..ee58d92c53c7 100644 --- a/Documentation/userspace-api/index.rst +++ b/Documentation/userspace-api/index.rst @@ -22,6 +22,7 @@ place where this information is gathered. dma-buf-alloc-exchange ebpf/index ELF + gpio/index ioctl/index iommu iommufd -- cgit v1.2.3 From c27cdd7a3010b4e0b9248c86c120335585afd085 Mon Sep 17 00:00:00 2001 From: Kent Gibson Date: Mon, 15 Jan 2024 08:48:40 +0800 Subject: Documentation: ABI: update gpio-cdev to reference chardev.rst Update the gpio-cdev interface document to refer to the new chardev.rst. Signed-off-by: Kent Gibson Signed-off-by: Bartosz Golaszewski --- Documentation/ABI/testing/gpio-cdev | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/gpio-cdev b/Documentation/ABI/testing/gpio-cdev index 66bdcd188b6c..c9689b2a6fed 100644 --- a/Documentation/ABI/testing/gpio-cdev +++ b/Documentation/ABI/testing/gpio-cdev @@ -6,8 +6,9 @@ Description: The character device files /dev/gpiochip* are the interface between GPIO chips and userspace. - The ioctl(2)-based ABI is defined and documented in - [include/uapi]. + The ioctl(2)-based ABI is defined in + [include/uapi] and documented in + Documentation/userspace-api/gpio/chardev.rst. The following file operations are supported: @@ -17,8 +18,8 @@ Description: ioctl(2) Initiate various actions. - See the inline documentation in [include/uapi] - for descriptions of all ioctls. + See Documentation/userspace-api/gpio/chardev.rst + for a description of all ioctls. close(2) Stops and free up the I/O contexts that was associated -- cgit v1.2.3 From f1fc93d9e551ccf9e75d19ec53bfbdbc0b10da52 Mon Sep 17 00:00:00 2001 From: Kent Gibson Date: Mon, 15 Jan 2024 08:48:41 +0800 Subject: Documentation: ABI: update sysfs-gpio to reference gpio-cdev Update the sysfs-gpio interface document to refer to the gpio-cdev interface that obsoletes it. Signed-off-by: Kent Gibson Signed-off-by: Bartosz Golaszewski --- Documentation/ABI/obsolete/sysfs-gpio | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/ABI/obsolete/sysfs-gpio b/Documentation/ABI/obsolete/sysfs-gpio index b8b0fd341c17..da1345d854b4 100644 --- a/Documentation/ABI/obsolete/sysfs-gpio +++ b/Documentation/ABI/obsolete/sysfs-gpio @@ -28,5 +28,5 @@ Description: /label ... (r/o) descriptive, not necessarily unique /ngpio ... (r/o) number of GPIOs; numbered N to N + (ngpio - 1) - This ABI is deprecated and will be removed after 2020. It is - replaced with the GPIO character device. + This ABI is obsoleted by Documentation/ABI/testing/gpio-cdev and will be + removed after 2020. -- cgit v1.2.3 From 5054626a9b801ff17aafa298d2d8f6a23ca84298 Mon Sep 17 00:00:00 2001 From: Kent Gibson Date: Mon, 15 Jan 2024 08:48:42 +0800 Subject: Documentation: gpio: move sysfs into an obsolete section The GPIO sysfs API is long obsolete, so highlight this even further by moving it into an obsolete APIs section in both the admin-guide and userspace-api books. Signed-off-by: Kent Gibson Signed-off-by: Bartosz Golaszewski --- Documentation/admin-guide/gpio/index.rst | 2 +- Documentation/admin-guide/gpio/obsolete.rst | 11 ++ Documentation/admin-guide/gpio/sysfs.rst | 167 -------------------------- Documentation/userspace-api/gpio/index.rst | 1 + Documentation/userspace-api/gpio/obsolete.rst | 10 ++ Documentation/userspace-api/gpio/sysfs.rst | 167 ++++++++++++++++++++++++++ 6 files changed, 190 insertions(+), 168 deletions(-) create mode 100644 Documentation/admin-guide/gpio/obsolete.rst delete mode 100644 Documentation/admin-guide/gpio/sysfs.rst create mode 100644 Documentation/userspace-api/gpio/obsolete.rst create mode 100644 Documentation/userspace-api/gpio/sysfs.rst (limited to 'Documentation') diff --git a/Documentation/admin-guide/gpio/index.rst b/Documentation/admin-guide/gpio/index.rst index b40f0a2a6822..3ac3aa15fa8b 100644 --- a/Documentation/admin-guide/gpio/index.rst +++ b/Documentation/admin-guide/gpio/index.rst @@ -9,9 +9,9 @@ gpio Character Device Userspace API <../../userspace-api/gpio/chardev> gpio-aggregator - sysfs gpio-mockup gpio-sim + Obsolete APIs .. only:: subproject and html diff --git a/Documentation/admin-guide/gpio/obsolete.rst b/Documentation/admin-guide/gpio/obsolete.rst new file mode 100644 index 000000000000..dbf88f13c680 --- /dev/null +++ b/Documentation/admin-guide/gpio/obsolete.rst @@ -0,0 +1,11 @@ +.. SPDX-License-Identifier: GPL-2.0 + +================== +Obsolete GPIO APIs +================== + +.. toctree:: + :maxdepth: 1 + + Sysfs Interface <../../userspace-api/gpio/sysfs> + diff --git a/Documentation/admin-guide/gpio/sysfs.rst b/Documentation/admin-guide/gpio/sysfs.rst deleted file mode 100644 index 35171d15f78d..000000000000 --- a/Documentation/admin-guide/gpio/sysfs.rst +++ /dev/null @@ -1,167 +0,0 @@ -GPIO Sysfs Interface for Userspace -================================== - -.. warning:: - - THIS ABI IS DEPRECATED, THE ABI DOCUMENTATION HAS BEEN MOVED TO - Documentation/ABI/obsolete/sysfs-gpio AND NEW USERSPACE CONSUMERS - ARE SUPPOSED TO USE THE CHARACTER DEVICE ABI. THIS OLD SYSFS ABI WILL - NOT BE DEVELOPED (NO NEW FEATURES), IT WILL JUST BE MAINTAINED. - -Refer to the examples in tools/gpio/* for an introduction to the new -character device ABI. Also see the userspace header in -include/uapi/linux/gpio.h - -The deprecated sysfs ABI ------------------------- -Platforms which use the "gpiolib" implementors framework may choose to -configure a sysfs user interface to GPIOs. This is different from the -debugfs interface, since it provides control over GPIO direction and -value instead of just showing a gpio state summary. Plus, it could be -present on production systems without debugging support. - -Given appropriate hardware documentation for the system, userspace could -know for example that GPIO #23 controls the write protect line used to -protect boot loader segments in flash memory. System upgrade procedures -may need to temporarily remove that protection, first importing a GPIO, -then changing its output state, then updating the code before re-enabling -the write protection. In normal use, GPIO #23 would never be touched, -and the kernel would have no need to know about it. - -Again depending on appropriate hardware documentation, on some systems -userspace GPIO can be used to determine system configuration data that -standard kernels won't know about. And for some tasks, simple userspace -GPIO drivers could be all that the system really needs. - -DO NOT ABUSE SYSFS TO CONTROL HARDWARE THAT HAS PROPER KERNEL DRIVERS. -PLEASE READ THE DOCUMENT AT Documentation/driver-api/gpio/drivers-on-gpio.rst -TO AVOID REINVENTING KERNEL WHEELS IN USERSPACE. I MEAN IT. REALLY. - -Paths in Sysfs --------------- -There are three kinds of entries in /sys/class/gpio: - - - Control interfaces used to get userspace control over GPIOs; - - - GPIOs themselves; and - - - GPIO controllers ("gpio_chip" instances). - -That's in addition to standard files including the "device" symlink. - -The control interfaces are write-only: - - /sys/class/gpio/ - - "export" ... - Userspace may ask the kernel to export control of - a GPIO to userspace by writing its number to this file. - - Example: "echo 19 > export" will create a "gpio19" node - for GPIO #19, if that's not requested by kernel code. - - "unexport" ... - Reverses the effect of exporting to userspace. - - Example: "echo 19 > unexport" will remove a "gpio19" - node exported using the "export" file. - -GPIO signals have paths like /sys/class/gpio/gpio42/ (for GPIO #42) -and have the following read/write attributes: - - /sys/class/gpio/gpioN/ - - "direction" ... - reads as either "in" or "out". This value may - normally be written. Writing as "out" defaults to - initializing the value as low. To ensure glitch free - operation, values "low" and "high" may be written to - configure the GPIO as an output with that initial value. - - Note that this attribute *will not exist* if the kernel - doesn't support changing the direction of a GPIO, or - it was exported by kernel code that didn't explicitly - allow userspace to reconfigure this GPIO's direction. - - "value" ... - reads as either 0 (low) or 1 (high). If the GPIO - is configured as an output, this value may be written; - any nonzero value is treated as high. - - If the pin can be configured as interrupt-generating interrupt - and if it has been configured to generate interrupts (see the - description of "edge"), you can poll(2) on that file and - poll(2) will return whenever the interrupt was triggered. If - you use poll(2), set the events POLLPRI and POLLERR. If you - use select(2), set the file descriptor in exceptfds. After - poll(2) returns, either lseek(2) to the beginning of the sysfs - file and read the new value or close the file and re-open it - to read the value. - - "edge" ... - reads as either "none", "rising", "falling", or - "both". Write these strings to select the signal edge(s) - that will make poll(2) on the "value" file return. - - This file exists only if the pin can be configured as an - interrupt generating input pin. - - "active_low" ... - reads as either 0 (false) or 1 (true). Write - any nonzero value to invert the value attribute both - for reading and writing. Existing and subsequent - poll(2) support configuration via the edge attribute - for "rising" and "falling" edges will follow this - setting. - -GPIO controllers have paths like /sys/class/gpio/gpiochip42/ (for the -controller implementing GPIOs starting at #42) and have the following -read-only attributes: - - /sys/class/gpio/gpiochipN/ - - "base" ... - same as N, the first GPIO managed by this chip - - "label" ... - provided for diagnostics (not always unique) - - "ngpio" ... - how many GPIOs this manages (N to N + ngpio - 1) - -Board documentation should in most cases cover what GPIOs are used for -what purposes. However, those numbers are not always stable; GPIOs on -a daughtercard might be different depending on the base board being used, -or other cards in the stack. In such cases, you may need to use the -gpiochip nodes (possibly in conjunction with schematics) to determine -the correct GPIO number to use for a given signal. - - -Exporting from Kernel code --------------------------- -Kernel code can explicitly manage exports of GPIOs which have already been -requested using gpio_request():: - - /* export the GPIO to userspace */ - int gpiod_export(struct gpio_desc *desc, bool direction_may_change); - - /* reverse gpiod_export() */ - void gpiod_unexport(struct gpio_desc *desc); - - /* create a sysfs link to an exported GPIO node */ - int gpiod_export_link(struct device *dev, const char *name, - struct gpio_desc *desc); - -After a kernel driver requests a GPIO, it may only be made available in -the sysfs interface by gpiod_export(). The driver can control whether the -signal direction may change. This helps drivers prevent userspace code -from accidentally clobbering important system state. - -This explicit exporting can help with debugging (by making some kinds -of experiments easier), or can provide an always-there interface that's -suitable for documenting as part of a board support package. - -After the GPIO has been exported, gpiod_export_link() allows creating -symlinks from elsewhere in sysfs to the GPIO sysfs node. Drivers can -use this to provide the interface under their own device in sysfs with -a descriptive name. diff --git a/Documentation/userspace-api/gpio/index.rst b/Documentation/userspace-api/gpio/index.rst index 072b9fa18aea..f258de4ef370 100644 --- a/Documentation/userspace-api/gpio/index.rst +++ b/Documentation/userspace-api/gpio/index.rst @@ -8,6 +8,7 @@ GPIO :maxdepth: 1 Character Device Userspace API + Obsolete Userspace APIs .. only:: subproject and html diff --git a/Documentation/userspace-api/gpio/obsolete.rst b/Documentation/userspace-api/gpio/obsolete.rst new file mode 100644 index 000000000000..c27bd6014a3d --- /dev/null +++ b/Documentation/userspace-api/gpio/obsolete.rst @@ -0,0 +1,10 @@ +.. SPDX-License-Identifier: GPL-2.0 + +============================ +Obsolete GPIO Userspace APIs +============================ + +.. toctree:: + :maxdepth: 1 + + Sysfs Interface diff --git a/Documentation/userspace-api/gpio/sysfs.rst b/Documentation/userspace-api/gpio/sysfs.rst new file mode 100644 index 000000000000..35171d15f78d --- /dev/null +++ b/Documentation/userspace-api/gpio/sysfs.rst @@ -0,0 +1,167 @@ +GPIO Sysfs Interface for Userspace +================================== + +.. warning:: + + THIS ABI IS DEPRECATED, THE ABI DOCUMENTATION HAS BEEN MOVED TO + Documentation/ABI/obsolete/sysfs-gpio AND NEW USERSPACE CONSUMERS + ARE SUPPOSED TO USE THE CHARACTER DEVICE ABI. THIS OLD SYSFS ABI WILL + NOT BE DEVELOPED (NO NEW FEATURES), IT WILL JUST BE MAINTAINED. + +Refer to the examples in tools/gpio/* for an introduction to the new +character device ABI. Also see the userspace header in +include/uapi/linux/gpio.h + +The deprecated sysfs ABI +------------------------ +Platforms which use the "gpiolib" implementors framework may choose to +configure a sysfs user interface to GPIOs. This is different from the +debugfs interface, since it provides control over GPIO direction and +value instead of just showing a gpio state summary. Plus, it could be +present on production systems without debugging support. + +Given appropriate hardware documentation for the system, userspace could +know for example that GPIO #23 controls the write protect line used to +protect boot loader segments in flash memory. System upgrade procedures +may need to temporarily remove that protection, first importing a GPIO, +then changing its output state, then updating the code before re-enabling +the write protection. In normal use, GPIO #23 would never be touched, +and the kernel would have no need to know about it. + +Again depending on appropriate hardware documentation, on some systems +userspace GPIO can be used to determine system configuration data that +standard kernels won't know about. And for some tasks, simple userspace +GPIO drivers could be all that the system really needs. + +DO NOT ABUSE SYSFS TO CONTROL HARDWARE THAT HAS PROPER KERNEL DRIVERS. +PLEASE READ THE DOCUMENT AT Documentation/driver-api/gpio/drivers-on-gpio.rst +TO AVOID REINVENTING KERNEL WHEELS IN USERSPACE. I MEAN IT. REALLY. + +Paths in Sysfs +-------------- +There are three kinds of entries in /sys/class/gpio: + + - Control interfaces used to get userspace control over GPIOs; + + - GPIOs themselves; and + + - GPIO controllers ("gpio_chip" instances). + +That's in addition to standard files including the "device" symlink. + +The control interfaces are write-only: + + /sys/class/gpio/ + + "export" ... + Userspace may ask the kernel to export control of + a GPIO to userspace by writing its number to this file. + + Example: "echo 19 > export" will create a "gpio19" node + for GPIO #19, if that's not requested by kernel code. + + "unexport" ... + Reverses the effect of exporting to userspace. + + Example: "echo 19 > unexport" will remove a "gpio19" + node exported using the "export" file. + +GPIO signals have paths like /sys/class/gpio/gpio42/ (for GPIO #42) +and have the following read/write attributes: + + /sys/class/gpio/gpioN/ + + "direction" ... + reads as either "in" or "out". This value may + normally be written. Writing as "out" defaults to + initializing the value as low. To ensure glitch free + operation, values "low" and "high" may be written to + configure the GPIO as an output with that initial value. + + Note that this attribute *will not exist* if the kernel + doesn't support changing the direction of a GPIO, or + it was exported by kernel code that didn't explicitly + allow userspace to reconfigure this GPIO's direction. + + "value" ... + reads as either 0 (low) or 1 (high). If the GPIO + is configured as an output, this value may be written; + any nonzero value is treated as high. + + If the pin can be configured as interrupt-generating interrupt + and if it has been configured to generate interrupts (see the + description of "edge"), you can poll(2) on that file and + poll(2) will return whenever the interrupt was triggered. If + you use poll(2), set the events POLLPRI and POLLERR. If you + use select(2), set the file descriptor in exceptfds. After + poll(2) returns, either lseek(2) to the beginning of the sysfs + file and read the new value or close the file and re-open it + to read the value. + + "edge" ... + reads as either "none", "rising", "falling", or + "both". Write these strings to select the signal edge(s) + that will make poll(2) on the "value" file return. + + This file exists only if the pin can be configured as an + interrupt generating input pin. + + "active_low" ... + reads as either 0 (false) or 1 (true). Write + any nonzero value to invert the value attribute both + for reading and writing. Existing and subsequent + poll(2) support configuration via the edge attribute + for "rising" and "falling" edges will follow this + setting. + +GPIO controllers have paths like /sys/class/gpio/gpiochip42/ (for the +controller implementing GPIOs starting at #42) and have the following +read-only attributes: + + /sys/class/gpio/gpiochipN/ + + "base" ... + same as N, the first GPIO managed by this chip + + "label" ... + provided for diagnostics (not always unique) + + "ngpio" ... + how many GPIOs this manages (N to N + ngpio - 1) + +Board documentation should in most cases cover what GPIOs are used for +what purposes. However, those numbers are not always stable; GPIOs on +a daughtercard might be different depending on the base board being used, +or other cards in the stack. In such cases, you may need to use the +gpiochip nodes (possibly in conjunction with schematics) to determine +the correct GPIO number to use for a given signal. + + +Exporting from Kernel code +-------------------------- +Kernel code can explicitly manage exports of GPIOs which have already been +requested using gpio_request():: + + /* export the GPIO to userspace */ + int gpiod_export(struct gpio_desc *desc, bool direction_may_change); + + /* reverse gpiod_export() */ + void gpiod_unexport(struct gpio_desc *desc); + + /* create a sysfs link to an exported GPIO node */ + int gpiod_export_link(struct device *dev, const char *name, + struct gpio_desc *desc); + +After a kernel driver requests a GPIO, it may only be made available in +the sysfs interface by gpiod_export(). The driver can control whether the +signal direction may change. This helps drivers prevent userspace code +from accidentally clobbering important system state. + +This explicit exporting can help with debugging (by making some kinds +of experiments easier), or can provide an always-there interface that's +suitable for documenting as part of a board support package. + +After the GPIO has been exported, gpiod_export_link() allows creating +symlinks from elsewhere in sysfs to the GPIO sysfs node. Drivers can +use this to provide the interface under their own device in sysfs with +a descriptive name. -- cgit v1.2.3 From e10b641753837e267462b64f8cb395ab1e625027 Mon Sep 17 00:00:00 2001 From: Kent Gibson Date: Mon, 15 Jan 2024 08:48:43 +0800 Subject: Documentation: gpio: update sysfs documentation to reference new chardev doc Update GPIO sysfs interface documentation to reference the new chardev document rather than gpio.h. Signed-off-by: Kent Gibson Signed-off-by: Bartosz Golaszewski --- Documentation/userspace-api/gpio/sysfs.rst | 27 +++++++++++++++------------ 1 file changed, 15 insertions(+), 12 deletions(-) (limited to 'Documentation') diff --git a/Documentation/userspace-api/gpio/sysfs.rst b/Documentation/userspace-api/gpio/sysfs.rst index 35171d15f78d..e12037a0f2b4 100644 --- a/Documentation/userspace-api/gpio/sysfs.rst +++ b/Documentation/userspace-api/gpio/sysfs.rst @@ -2,18 +2,18 @@ GPIO Sysfs Interface for Userspace ================================== .. warning:: + This API is obsoleted by the chardev.rst and the ABI documentation has + been moved to Documentation/ABI/obsolete/sysfs-gpio. - THIS ABI IS DEPRECATED, THE ABI DOCUMENTATION HAS BEEN MOVED TO - Documentation/ABI/obsolete/sysfs-gpio AND NEW USERSPACE CONSUMERS - ARE SUPPOSED TO USE THE CHARACTER DEVICE ABI. THIS OLD SYSFS ABI WILL - NOT BE DEVELOPED (NO NEW FEATURES), IT WILL JUST BE MAINTAINED. + New developments should use the chardev.rst, and existing developments are + encouraged to migrate as soon as possible, as this API will be removed + in the future. -Refer to the examples in tools/gpio/* for an introduction to the new -character device ABI. Also see the userspace header in -include/uapi/linux/gpio.h + This interface will continue to be maintained for the migration period, + but new features will only be added to the new API. -The deprecated sysfs ABI ------------------------- +The obsolete sysfs ABI +---------------------- Platforms which use the "gpiolib" implementors framework may choose to configure a sysfs user interface to GPIOs. This is different from the debugfs interface, since it provides control over GPIO direction and @@ -33,9 +33,12 @@ userspace GPIO can be used to determine system configuration data that standard kernels won't know about. And for some tasks, simple userspace GPIO drivers could be all that the system really needs. -DO NOT ABUSE SYSFS TO CONTROL HARDWARE THAT HAS PROPER KERNEL DRIVERS. -PLEASE READ THE DOCUMENT AT Documentation/driver-api/gpio/drivers-on-gpio.rst -TO AVOID REINVENTING KERNEL WHEELS IN USERSPACE. I MEAN IT. REALLY. +.. note:: + Do NOT abuse sysfs to control hardware that has proper kernel drivers. + Please read Documentation/driver-api/gpio/drivers-on-gpio.rst + to avoid reinventing kernel wheels in userspace. + + I MEAN IT. REALLY. Paths in Sysfs -------------- -- cgit v1.2.3 From 16b2bb7fe5e4a0757608e844902fdf05617f51f8 Mon Sep 17 00:00:00 2001 From: Kent Gibson Date: Mon, 15 Jan 2024 08:48:44 +0800 Subject: Documentation: gpio: add chardev v1 userspace API documentation Add documentation for v1 of the GPIO character device userspace API to the obsolete section of both the admin-guide and userspace-api books. Signed-off-by: Kent Gibson Signed-off-by: Bartosz Golaszewski --- Documentation/admin-guide/gpio/obsolete.rst | 1 + Documentation/userspace-api/gpio/chardev_v1.rst | 131 +++++++++++++++++++++ .../gpio/gpio-get-lineevent-ioctl.rst | 78 ++++++++++++ .../gpio/gpio-get-linehandle-ioctl.rst | 86 ++++++++++++++ .../userspace-api/gpio/gpio-get-lineinfo-ioctl.rst | 54 +++++++++ .../gpio/gpio-get-lineinfo-unwatch-ioctl.rst | 2 +- .../gpio/gpio-get-lineinfo-watch-ioctl.rst | 74 ++++++++++++ .../gpio/gpio-handle-get-line-values-ioctl.rst | 56 +++++++++ .../gpio/gpio-handle-set-config-ioctl.rst | 62 ++++++++++ .../gpio/gpio-handle-set-line-values-ioctl.rst | 48 ++++++++ .../gpio/gpio-lineevent-data-read.rst | 84 +++++++++++++ .../gpio/gpio-lineinfo-changed-read.rst | 87 ++++++++++++++ Documentation/userspace-api/gpio/obsolete.rst | 1 + 13 files changed, 763 insertions(+), 1 deletion(-) create mode 100644 Documentation/userspace-api/gpio/chardev_v1.rst create mode 100644 Documentation/userspace-api/gpio/gpio-get-lineevent-ioctl.rst create mode 100644 Documentation/userspace-api/gpio/gpio-get-linehandle-ioctl.rst create mode 100644 Documentation/userspace-api/gpio/gpio-get-lineinfo-ioctl.rst create mode 100644 Documentation/userspace-api/gpio/gpio-get-lineinfo-watch-ioctl.rst create mode 100644 Documentation/userspace-api/gpio/gpio-handle-get-line-values-ioctl.rst create mode 100644 Documentation/userspace-api/gpio/gpio-handle-set-config-ioctl.rst create mode 100644 Documentation/userspace-api/gpio/gpio-handle-set-line-values-ioctl.rst create mode 100644 Documentation/userspace-api/gpio/gpio-lineevent-data-read.rst create mode 100644 Documentation/userspace-api/gpio/gpio-lineinfo-changed-read.rst (limited to 'Documentation') diff --git a/Documentation/admin-guide/gpio/obsolete.rst b/Documentation/admin-guide/gpio/obsolete.rst index dbf88f13c680..5926e5440207 100644 --- a/Documentation/admin-guide/gpio/obsolete.rst +++ b/Documentation/admin-guide/gpio/obsolete.rst @@ -7,5 +7,6 @@ Obsolete GPIO APIs .. toctree:: :maxdepth: 1 + Character Device Userspace API (v1) <../../userspace-api/gpio/chardev_v1> Sysfs Interface <../../userspace-api/gpio/sysfs> diff --git a/Documentation/userspace-api/gpio/chardev_v1.rst b/Documentation/userspace-api/gpio/chardev_v1.rst new file mode 100644 index 000000000000..67124b1d0487 --- /dev/null +++ b/Documentation/userspace-api/gpio/chardev_v1.rst @@ -0,0 +1,131 @@ +.. SPDX-License-Identifier: GPL-2.0 + +======================================== +GPIO Character Device Userspace API (v1) +======================================== + +.. warning:: + This API is obsoleted by chardev.rst (v2). + + New developments should use the v2 API, and existing developments are + encouraged to migrate as soon as possible, as this API will be removed + in the future. The v2 API is a functional superset of the v1 API so any + v1 call can be directly translated to a v2 equivalent. + + This interface will continue to be maintained for the migration period, + but new features will only be added to the new API. + +First added in 4.8. + +The API is based around three major objects, the :ref:`gpio-v1-chip`, the +:ref:`gpio-v1-line-handle`, and the :ref:`gpio-v1-line-event`. + +Where "line event" is used in this document it refers to the request that can +monitor a line for edge events, not the edge events themselves. + +.. _gpio-v1-chip: + +Chip +==== + +The Chip represents a single GPIO chip and is exposed to userspace using device +files of the form ``/dev/gpiochipX``. + +Each chip supports a number of GPIO lines, +:c:type:`chip.lines`. Lines on the chip are identified by an +``offset`` in the range from 0 to ``chip.lines - 1``, i.e. `[0,chip.lines)`. + +Lines are requested from the chip using either gpio-get-linehandle-ioctl.rst +and the resulting line handle is used to access the GPIO chip's lines, or +gpio-get-lineevent-ioctl.rst and the resulting line event is used to monitor +a GPIO line for edge events. + +Within this documentation, the file descriptor returned by calling `open()` +on the GPIO device file is referred to as ``chip_fd``. + +Operations +---------- + +The following operations may be performed on the chip: + +.. toctree:: + :titlesonly: + + Get Line Handle + Get Line Event + Get Chip Info + Get Line Info + Watch Line Info + Unwatch Line Info + Read Line Info Changed Events + +.. _gpio-v1-line-handle: + +Line Handle +=========== + +Line handles are created by gpio-get-linehandle-ioctl.rst and provide +access to a set of requested lines. The line handle is exposed to userspace +via the anonymous file descriptor returned in +:c:type:`request.fd` by gpio-get-linehandle-ioctl.rst. + +Within this documentation, the line handle file descriptor is referred to +as ``handle_fd``. + +Operations +---------- + +The following operations may be performed on the line handle: + +.. toctree:: + :titlesonly: + + Get Line Values + Set Line Values + Reconfigure Lines + +.. _gpio-v1-line-event: + +Line Event +========== + +Line events are created by gpio-get-lineevent-ioctl.rst and provide +access to a requested line. The line event is exposed to userspace +via the anonymous file descriptor returned in +:c:type:`request.fd` by gpio-get-lineevent-ioctl.rst. + +Within this documentation, the line event file descriptor is referred to +as ``event_fd``. + +Operations +---------- + +The following operations may be performed on the line event: + +.. toctree:: + :titlesonly: + + Get Line Value + Read Line Edge Events + +Types +===== + +This section contains the structs that are referenced by the ABI v1. + +The :c:type:`struct gpiochip_info` is common to ABI v1 and v2. + +.. kernel-doc:: include/uapi/linux/gpio.h + :identifiers: + gpioevent_data + gpioevent_request + gpiohandle_config + gpiohandle_data + gpiohandle_request + gpioline_info + gpioline_info_changed + +.. toctree:: + :hidden: + + error-codes diff --git a/Documentation/userspace-api/gpio/gpio-get-lineevent-ioctl.rst b/Documentation/userspace-api/gpio/gpio-get-lineevent-ioctl.rst new file mode 100644 index 000000000000..7d0b932925c6 --- /dev/null +++ b/Documentation/userspace-api/gpio/gpio-get-lineevent-ioctl.rst @@ -0,0 +1,78 @@ +.. SPDX-License-Identifier: GPL-2.0 + +.. _GPIO_GET_LINEEVENT_IOCTL: + +************************ +GPIO_GET_LINEEVENT_IOCTL +************************ + +.. warning:: + This ioctl is part of chardev_v1.rst and is obsoleted by + gpio-v2-get-line-ioctl.rst. + +Name +==== + +GPIO_GET_LINEEVENT_IOCTL - Request a line with edge detection from the kernel. + +Synopsis +======== + +.. c:macro:: GPIO_GET_LINEEVENT_IOCTL + +``int ioctl(int chip_fd, GPIO_GET_LINEEVENT_IOCTL, struct gpioevent_request *request)`` + +Arguments +========= + +``chip_fd`` + The file descriptor of the GPIO character device returned by `open()`. + +``request`` + The :c:type:`event_request` specifying the line + to request and its configuration. + +Description +=========== + +Request a line with edge detection from the kernel. + +On success, the requesting process is granted exclusive access to the line +value and may receive events when edges are detected on the line, as +described in gpio-lineevent-data-read.rst. + +The state of a line is guaranteed to remain as requested until the returned +file descriptor is closed. Once the file descriptor is closed, the state of +the line becomes uncontrolled from the userspace perspective, and may revert +to its default state. + +Requesting a line already in use is an error (**EBUSY**). + +Closing the ``chip_fd`` has no effect on existing line events. + +Configuration Rules +------------------- + +The following configuration rules apply: + +The line event is requested as an input, so no flags specific to output lines, +``GPIOHANDLE_REQUEST_OUTPUT``, ``GPIOHANDLE_REQUEST_OPEN_DRAIN``, or +``GPIOHANDLE_REQUEST_OPEN_SOURCE``, may be set. + +Only one bias flag, ``GPIOHANDLE_REQUEST_BIAS_xxx``, may be set. +If no bias flags are set then the bias configuration is not changed. + +The edge flags, ``GPIOEVENT_REQUEST_RISING_EDGE`` and +``GPIOEVENT_REQUEST_FALLING_EDGE``, may be combined to detect both rising +and falling edges. + +Requesting an invalid configuration is an error (**EINVAL**). + +Return Value +============ + +On success 0 and the :c:type:`request.fd` contains the file +descriptor for the request. + +On error -1 and the ``errno`` variable is set appropriately. +Common error codes are described in error-codes.rst. diff --git a/Documentation/userspace-api/gpio/gpio-get-linehandle-ioctl.rst b/Documentation/userspace-api/gpio/gpio-get-linehandle-ioctl.rst new file mode 100644 index 000000000000..c8256afe306e --- /dev/null +++ b/Documentation/userspace-api/gpio/gpio-get-linehandle-ioctl.rst @@ -0,0 +1,86 @@ +.. SPDX-License-Identifier: GPL-2.0 + +.. _GPIO_GET_LINEHANDLE_IOCTL: + +************************* +GPIO_GET_LINEHANDLE_IOCTL +************************* + +.. warning:: + This ioctl is part of chardev_v1.rst and is obsoleted by + gpio-v2-get-line-ioctl.rst. + +Name +==== + +GPIO_GET_LINEHANDLE_IOCTL - Request a line or lines from the kernel. + +Synopsis +======== + +.. c:macro:: GPIO_GET_LINEHANDLE_IOCTL + +``int ioctl(int chip_fd, GPIO_GET_LINEHANDLE_IOCTL, struct gpiohandle_request *request)`` + +Arguments +========= + +``chip_fd`` + The file descriptor of the GPIO character device returned by `open()`. + +``request`` + The :c:type:`handle_request` specifying the lines to + request and their configuration. + +Description +=========== + +Request a line or lines from the kernel. + +While multiple lines may be requested, the same configuration applies to all +lines in the request. + +On success, the requesting process is granted exclusive access to the line +value and write access to the line configuration. + +The state of a line, including the value of output lines, is guaranteed to +remain as requested until the returned file descriptor is closed. Once the +file descriptor is closed, the state of the line becomes uncontrolled from +the userspace perspective, and may revert to its default state. + +Requesting a line already in use is an error (**EBUSY**). + +Closing the ``chip_fd`` has no effect on existing line handles. + +.. _gpio-get-linehandle-config-rules: + +Configuration Rules +------------------- + +The following configuration rules apply: + +The direction flags, ``GPIOHANDLE_REQUEST_INPUT`` and +``GPIOHANDLE_REQUEST_OUTPUT``, cannot be combined. If neither are set then the +only other flag that may be set is ``GPIOHANDLE_REQUEST_ACTIVE_LOW`` and the +line is requested "as-is" to allow reading of the line value without altering +the electrical configuration. + +The drive flags, ``GPIOHANDLE_REQUEST_OPEN_xxx``, require the +``GPIOHANDLE_REQUEST_OUTPUT`` to be set. +Only one drive flag may be set. +If none are set then the line is assumed push-pull. + +Only one bias flag, ``GPIOHANDLE_REQUEST_BIAS_xxx``, may be set, and +it requires a direction flag to also be set. +If no bias flags are set then the bias configuration is not changed. + +Requesting an invalid configuration is an error (**EINVAL**). + +Return Value +============ + +On success 0 and the :c:type:`request.fd` contains the +file descriptor for the request. + +On error -1 and the ``errno`` variable is set appropriately. +Common error codes are described in error-codes.rst. diff --git a/Documentation/userspace-api/gpio/gpio-get-lineinfo-ioctl.rst b/Documentation/userspace-api/gpio/gpio-get-lineinfo-ioctl.rst new file mode 100644 index 000000000000..c895b8910b25 --- /dev/null +++ b/Documentation/userspace-api/gpio/gpio-get-lineinfo-ioctl.rst @@ -0,0 +1,54 @@ +.. SPDX-License-Identifier: GPL-2.0 + +.. _GPIO_GET_LINEINFO_IOCTL: + +*********************** +GPIO_GET_LINEINFO_IOCTL +*********************** + +.. warning:: + This ioctl is part of chardev_v1.rst and is obsoleted by + gpio-v2-get-lineinfo-ioctl.rst. + +Name +==== + +GPIO_GET_LINEINFO_IOCTL - Get the publicly available information for a line. + +Synopsis +======== + +.. c:macro:: GPIO_GET_LINEINFO_IOCTL + +``int ioctl(int chip_fd, GPIO_GET_LINEINFO_IOCTL, struct gpioline_info *info)`` + +Arguments +========= + +``chip_fd`` + The file descriptor of the GPIO character device returned by `open()`. + +``info`` + The :c:type:`line_info` to be populated, with the + ``offset`` field set to indicate the line to be collected. + +Description +=========== + +Get the publicly available information for a line. + +This information is available independent of whether the line is in use. + +.. note:: + The line info does not include the line value. + + The line must be requested using gpio-get-linehandle-ioctl.rst or + gpio-get-lineevent-ioctl.rst to access its value. + +Return Value +============ + +On success 0 and ``info`` is populated with the chip info. + +On error -1 and the ``errno`` variable is set appropriately. +Common error codes are described in error-codes.rst. diff --git a/Documentation/userspace-api/gpio/gpio-get-lineinfo-unwatch-ioctl.rst b/Documentation/userspace-api/gpio/gpio-get-lineinfo-unwatch-ioctl.rst index 2fec6f12e3bf..a82d0161daf8 100644 --- a/Documentation/userspace-api/gpio/gpio-get-lineinfo-unwatch-ioctl.rst +++ b/Documentation/userspace-api/gpio/gpio-get-lineinfo-unwatch-ioctl.rst @@ -33,7 +33,7 @@ Description Remove the line from the list of lines being watched on this ``chip_fd``. -This is the opposite of gpio-v2-get-lineinfo-watch-ioctl.rst (v2) and +This is the reverse of gpio-v2-get-lineinfo-watch-ioctl.rst (v2) and gpio-get-lineinfo-watch-ioctl.rst (v1). Unwatching a line that is not watched is an error (**EBUSY**). diff --git a/Documentation/userspace-api/gpio/gpio-get-lineinfo-watch-ioctl.rst b/Documentation/userspace-api/gpio/gpio-get-lineinfo-watch-ioctl.rst new file mode 100644 index 000000000000..f5c92b69a496 --- /dev/null +++ b/Documentation/userspace-api/gpio/gpio-get-lineinfo-watch-ioctl.rst @@ -0,0 +1,74 @@ +.. SPDX-License-Identifier: GPL-2.0 + +.. _GPIO_GET_LINEINFO_WATCH_IOCTL: + +***************************** +GPIO_GET_LINEINFO_WATCH_IOCTL +***************************** + +.. warning:: + This ioctl is part of chardev_v1.rst and is obsoleted by + gpio-v2-get-lineinfo-watch-ioctl.rst. + +Name +==== + +GPIO_GET_LINEINFO_WATCH_IOCTL - Enable watching a line for changes to its +request state and configuration information. + +Synopsis +======== + +.. c:macro:: GPIO_GET_LINEINFO_WATCH_IOCTL + +``int ioctl(int chip_fd, GPIO_GET_LINEINFO_WATCH_IOCTL, struct gpioline_info *info)`` + +Arguments +========= + +``chip_fd`` + The file descriptor of the GPIO character device returned by `open()`. + +``info`` + The :c:type:`line_info` struct to be populated, with + the ``offset`` set to indicate the line to watch + +Description +=========== + +Enable watching a line for changes to its request state and configuration +information. Changes to line info include a line being requested, released +or reconfigured. + +.. note:: + Watching line info is not generally required, and would typically only be + used by a system monitoring component. + + The line info does NOT include the line value. + + The line must be requested using gpio-get-linehandle-ioctl.rst or + gpio-get-lineevent-ioctl.rst to access its value, and the line event can + monitor a line for events using gpio-lineevent-data-read.rst. + +By default all lines are unwatched when the GPIO chip is opened. + +Multiple lines may be watched simultaneously by adding a watch for each. + +Once a watch is set, any changes to line info will generate events which can be +read from the ``chip_fd`` as described in +gpio-lineinfo-changed-read.rst. + +Adding a watch to a line that is already watched is an error (**EBUSY**). + +Watches are specific to the ``chip_fd`` and are independent of watches +on the same GPIO chip opened with a separate call to `open()`. + +First added in 5.7. + +Return Value +============ + +On success 0 and ``info`` is populated with the current line info. + +On error -1 and the ``errno`` variable is set appropriately. +Common error codes are described in error-codes.rst. diff --git a/Documentation/userspace-api/gpio/gpio-handle-get-line-values-ioctl.rst b/Documentation/userspace-api/gpio/gpio-handle-get-line-values-ioctl.rst new file mode 100644 index 000000000000..25263b8f0588 --- /dev/null +++ b/Documentation/userspace-api/gpio/gpio-handle-get-line-values-ioctl.rst @@ -0,0 +1,56 @@ +.. SPDX-License-Identifier: GPL-2.0 + +.. _GPIOHANDLE_GET_LINE_VALUES_IOCTL: + +******************************** +GPIOHANDLE_GET_LINE_VALUES_IOCTL +******************************** +.. warning:: + This ioctl is part of chardev_v1.rst and is obsoleted by + gpio-v2-line-get-values-ioctl.rst. + +Name +==== + +GPIOHANDLE_GET_LINE_VALUES_IOCTL - Get the values of all requested lines. + +Synopsis +======== + +.. c:macro:: GPIOHANDLE_GET_LINE_VALUES_IOCTL + +``int ioctl(int handle_fd, GPIOHANDLE_GET_LINE_VALUES_IOCTL, struct gpiohandle_data *values)`` + +Arguments +========= + +``handle_fd`` + The file descriptor of the GPIO character device, as returned in the + :c:type:`request.fd` by gpio-get-linehandle-ioctl.rst. + +``values`` + The :c:type:`line_values` to be populated. + +Description +=========== + +Get the values of all requested lines. + +The values of both input and output lines may be read. + +For output lines, the value returned is driver and configuration dependent and +may be either the output buffer (the last requested value set) or the input +buffer (the actual level of the line), and depending on the hardware and +configuration these may differ. + +This ioctl can also be used to read the line value for line events, +substituting the ``event_fd`` for the ``handle_fd``. As there is only +one line requested in that case, only the one value is returned in ``values``. + +Return Value +============ + +On success 0 and ``values`` populated with the values read. + +On error -1 and the ``errno`` variable is set appropriately. +Common error codes are described in error-codes.rst. diff --git a/Documentation/userspace-api/gpio/gpio-handle-set-config-ioctl.rst b/Documentation/userspace-api/gpio/gpio-handle-set-config-ioctl.rst new file mode 100644 index 000000000000..8f1e748dccc8 --- /dev/null +++ b/Documentation/userspace-api/gpio/gpio-handle-set-config-ioctl.rst @@ -0,0 +1,62 @@ +.. SPDX-License-Identifier: GPL-2.0 + +.. _GPIOHANDLE_SET_CONFIG_IOCTL: + +*************************** +GPIOHANDLE_SET_CONFIG_IOCTL +*************************** + +.. warning:: + This ioctl is part of chardev_v1.rst and is obsoleted by + gpio-v2-line-set-config-ioctl.rst. + +Name +==== + +GPIOHANDLE_SET_CONFIG_IOCTL - Update the configuration of previously requested lines. + +Synopsis +======== + +.. c:macro:: GPIOHANDLE_SET_CONFIG_IOCTL + +``int ioctl(int handle_fd, GPIOHANDLE_SET_CONFIG_IOCTL, struct gpiohandle_config *config)`` + +Arguments +========= + +``handle_fd`` + The file descriptor of the GPIO character device, as returned in the + :c:type:`request.fd` by gpio-get-linehandle-ioctl.rst. + +``config`` + The new :c:type:`configuration` to apply to the + requested lines. + +Description +=========== + +Update the configuration of previously requested lines, without releasing the +line or introducing potential glitches. + +The configuration applies to all requested lines. + +The same :ref:`gpio-get-linehandle-config-rules` that apply when requesting the +lines also apply when updating the line configuration. + +The motivating use case for this command is changing direction of +bi-directional lines between input and output, but it may be used more +generally move lines seamlessly from one configuration state to another. + +To only change the value of output lines, use +gpio-handle-set-line-values-ioctl.rst. + +First added in 5.5. + +Return Value +============ + +On success 0. + +On error -1 and the ``errno`` variable is set appropriately. +Common error codes are described in error-codes.rst. diff --git a/Documentation/userspace-api/gpio/gpio-handle-set-line-values-ioctl.rst b/Documentation/userspace-api/gpio/gpio-handle-set-line-values-ioctl.rst new file mode 100644 index 000000000000..0aa05e623a6c --- /dev/null +++ b/Documentation/userspace-api/gpio/gpio-handle-set-line-values-ioctl.rst @@ -0,0 +1,48 @@ +.. SPDX-License-Identifier: GPL-2.0 + +.. _GPIO_HANDLE_SET_LINE_VALUES_IOCTL: + +********************************* +GPIO_HANDLE_SET_LINE_VALUES_IOCTL +********************************* +.. warning:: + This ioctl is part of chardev_v1.rst and is obsoleted by + gpio-v2-line-set-values-ioctl.rst. + +Name +==== + +GPIO_HANDLE_SET_LINE_VALUES_IOCTL - Set the values of all requested output lines. + +Synopsis +======== + +.. c:macro:: GPIO_HANDLE_SET_LINE_VALUES_IOCTL + +``int ioctl(int handle_fd, GPIO_HANDLE_SET_LINE_VALUES_IOCTL, struct gpiohandle_data *values)`` + +Arguments +========= + +``handle_fd`` + The file descriptor of the GPIO character device, as returned in the + :c:type:`request.fd` by gpio-get-linehandle-ioctl.rst. + +``values`` + The :c:type:`line_values` to set. + +Description +=========== + +Set the values of all requested output lines. + +Only the values of output lines may be set. +Attempting to set the value of input lines is an error (**EPERM**). + +Return Value +============ + +On success 0. + +On error -1 and the ``errno`` variable is set appropriately. +Common error codes are described in error-codes.rst. diff --git a/Documentation/userspace-api/gpio/gpio-lineevent-data-read.rst b/Documentation/userspace-api/gpio/gpio-lineevent-data-read.rst new file mode 100644 index 000000000000..68b8d4f9f604 --- /dev/null +++ b/Documentation/userspace-api/gpio/gpio-lineevent-data-read.rst @@ -0,0 +1,84 @@ +.. SPDX-License-Identifier: GPL-2.0 + +.. _GPIO_LINEEVENT_DATA_READ: + +************************ +GPIO_LINEEVENT_DATA_READ +************************ + +.. warning:: + This ioctl is part of chardev_v1.rst and is obsoleted by + gpio-v2-line-event-read.rst. + +Name +==== + +GPIO_LINEEVENT_DATA_READ - Read edge detection events from a line event. + +Synopsis +======== + +``int read(int event_fd, void *buf, size_t count)`` + +Arguments +========= + +``event_fd`` + The file descriptor of the GPIO character device, as returned in the + :c:type:`request.fd` by gpio-get-lineevent-ioctl.rst. + +``buf`` + The buffer to contain the :c:type:`events`. + +``count`` + The number of bytes available in ``buf``, which must be at + least the size of a :c:type:`gpioevent_data`. + +Description +=========== + +Read edge detection events for a line from a line event. + +Edge detection must be enabled for the input line using either +``GPIOEVENT_REQUEST_RISING_EDGE`` or ``GPIOEVENT_REQUEST_FALLING_EDGE``, or +both. Edge events are then generated whenever edge interrupts are detected on +the input line. + +The kernel captures and timestamps edge events as close as possible to their +occurrence and stores them in a buffer from where they can be read by +userspace at its convenience using `read()`. + +The source of the clock for :c:type:`event.timestamp` is +``CLOCK_MONOTONIC``, except for kernels earlier than Linux 5.7 when it was +``CLOCK_REALTIME``. There is no indication in the :c:type:`gpioevent_data` +as to which clock source is used, it must be determined from either the kernel +version or sanity checks on the timestamp itself. + +Events read from the buffer are always in the same order that they were +detected by the kernel. + +The size of the kernel event buffer is fixed at 16 events. + +The buffer may overflow if bursts of events occur quicker than they are read +by userspace. If an overflow occurs then the most recent event is discarded. +Overflow cannot be detected from userspace. + +To minimize the number of calls required to copy events from the kernel to +userspace, `read()` supports copying multiple events. The number of events +copied is the lower of the number available in the kernel buffer and the +number that will fit in the userspace buffer (``buf``). + +The `read()` will block if no event is available and the ``event_fd`` has not +been set **O_NONBLOCK**. + +The presence of an event can be tested for by checking that the ``event_fd`` is +readable using `poll()` or an equivalent. + +Return Value +============ + +On success the number of bytes read, which will be a multiple of the size of +a :c:type:`gpio_lineevent_data` event. + +On error -1 and the ``errno`` variable is set appropriately. +Common error codes are described in error-codes.rst. diff --git a/Documentation/userspace-api/gpio/gpio-lineinfo-changed-read.rst b/Documentation/userspace-api/gpio/gpio-lineinfo-changed-read.rst new file mode 100644 index 000000000000..c4f5e1787a9d --- /dev/null +++ b/Documentation/userspace-api/gpio/gpio-lineinfo-changed-read.rst @@ -0,0 +1,87 @@ +.. SPDX-License-Identifier: GPL-2.0 + +.. _GPIO_LINEINFO_CHANGED_READ: + +************************** +GPIO_LINEINFO_CHANGED_READ +************************** + +.. warning:: + This ioctl is part of chardev_v1.rst and is obsoleted by + gpio-v2-lineinfo-changed-read.rst. + +Name +==== + +GPIO_LINEINFO_CHANGED_READ - Read line info change events for watched lines +from the chip. + +Synopsis +======== + +``int read(int chip_fd, void *buf, size_t count)`` + +Arguments +========= + +``chip_fd`` + The file descriptor of the GPIO character device returned by `open()`. + +``buf`` + The buffer to contain the :c:type:`events`. + +``count`` + The number of bytes available in ``buf``, which must be at least the size + of a :c:type:`gpioline_info_changed` event. + +Description +=========== + +Read line info change events for watched lines from the chip. + +.. note:: + Monitoring line info changes is not generally required, and would typically + only be performed by a system monitoring component. + + These events relate to changes in a line's request state or configuration, + not its value. Use gpio-lineevent-data-read.rst to receive events when a + line changes value. + +A line must be watched using gpio-get-lineinfo-watch-ioctl.rst to generate +info changed events. Subsequently, a request, release, or reconfiguration +of the line will generate an info changed event. + +The kernel timestamps events when they occur and stores them in a buffer +from where they can be read by userspace at its convenience using `read()`. + +The size of the kernel event buffer is fixed at 32 events per ``chip_fd``. + +The buffer may overflow if bursts of events occur quicker than they are read +by userspace. If an overflow occurs then the most recent event is discarded. +Overflow cannot be detected from userspace. + +Events read from the buffer are always in the same order that they were +detected by the kernel, including when multiple lines are being monitored by +the one ``chip_fd``. + +To minimize the number of calls required to copy events from the kernel to +userspace, `read()` supports copying multiple events. The number of events +copied is the lower of the number available in the kernel buffer and the +number that will fit in the userspace buffer (``buf``). + +A `read()` will block if no event is available and the ``chip_fd`` has not +been set **O_NONBLOCK**. + +The presence of an event can be tested for by checking that the ``chip_fd`` is +readable using `poll()` or an equivalent. + +First added in 5.7. + +Return Value +============ + +On success the number of bytes read, which will be a multiple of the size of +a :c:type:`gpioline_info_changed` event. + +On error -1 and the ``errno`` variable is set appropriately. +Common error codes are described in error-codes.rst. diff --git a/Documentation/userspace-api/gpio/obsolete.rst b/Documentation/userspace-api/gpio/obsolete.rst index c27bd6014a3d..c42538b44ec8 100644 --- a/Documentation/userspace-api/gpio/obsolete.rst +++ b/Documentation/userspace-api/gpio/obsolete.rst @@ -7,4 +7,5 @@ Obsolete GPIO Userspace APIs .. toctree:: :maxdepth: 1 + Character Device Userspace API (v1) Sysfs Interface -- cgit v1.2.3 From f1ccbe9aaea6488c4ef71f8f51ac2a620993acde Mon Sep 17 00:00:00 2001 From: Kent Gibson Date: Mon, 15 Jan 2024 08:48:45 +0800 Subject: Documentation: gpio: capitalize GPIO in index title Capitalise the title of the GPIO documentation page to match other subsystems. Signed-off-by: Kent Gibson Signed-off-by: Bartosz Golaszewski --- Documentation/admin-guide/gpio/index.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/admin-guide/gpio/index.rst b/Documentation/admin-guide/gpio/index.rst index 3ac3aa15fa8b..3f6d5a76702b 100644 --- a/Documentation/admin-guide/gpio/index.rst +++ b/Documentation/admin-guide/gpio/index.rst @@ -1,7 +1,7 @@ .. SPDX-License-Identifier: GPL-2.0 ==== -gpio +GPIO ==== .. toctree:: -- cgit v1.2.3 From c3d336cae79728f8ed6711c5a6179cdc66802e89 Mon Sep 17 00:00:00 2001 From: Kent Gibson Date: Mon, 15 Jan 2024 08:48:46 +0800 Subject: Documentation: gpio: document gpio-mockup as obsoleted by gpio-sim Update the gpio-mockup documentation to note that is has been obsoleted by the gpio-sim. Signed-off-by: Kent Gibson Signed-off-by: Bartosz Golaszewski --- Documentation/admin-guide/gpio/gpio-mockup.rst | 8 ++++++++ 1 file changed, 8 insertions(+) (limited to 'Documentation') diff --git a/Documentation/admin-guide/gpio/gpio-mockup.rst b/Documentation/admin-guide/gpio/gpio-mockup.rst index 493071da1738..d6e7438a7550 100644 --- a/Documentation/admin-guide/gpio/gpio-mockup.rst +++ b/Documentation/admin-guide/gpio/gpio-mockup.rst @@ -3,6 +3,14 @@ GPIO Testing Driver =================== +.. note:: + + This module has been obsoleted by the more flexible gpio-sim.rst. + New developments should use that API and existing developments are + encouraged to migrate as soon as possible. + This module will continue to be maintained but no new features will be + added. + The GPIO Testing Driver (gpio-mockup) provides a way to create simulated GPIO chips for testing purposes. The lines exposed by these chips can be accessed using the standard GPIO character device interface as well as manipulated -- cgit v1.2.3 From c055f7ed9744a5bae69a592eca84e22837736b92 Mon Sep 17 00:00:00 2001 From: Kent Gibson Date: Mon, 15 Jan 2024 08:48:47 +0800 Subject: Documentation: gpio: move gpio-mockup into obsolete section The gpio-mockup has been obsoleted by the gpio-sim, so relocate its documentation into the obsolete section of the admin-guide book. Signed-off-by: Kent Gibson Signed-off-by: Bartosz Golaszewski --- Documentation/admin-guide/gpio/index.rst | 1 - Documentation/admin-guide/gpio/obsolete.rst | 1 + 2 files changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/admin-guide/gpio/index.rst b/Documentation/admin-guide/gpio/index.rst index 3f6d5a76702b..460afd29617e 100644 --- a/Documentation/admin-guide/gpio/index.rst +++ b/Documentation/admin-guide/gpio/index.rst @@ -9,7 +9,6 @@ GPIO Character Device Userspace API <../../userspace-api/gpio/chardev> gpio-aggregator - gpio-mockup gpio-sim Obsolete APIs diff --git a/Documentation/admin-guide/gpio/obsolete.rst b/Documentation/admin-guide/gpio/obsolete.rst index 5926e5440207..5adbff02d61f 100644 --- a/Documentation/admin-guide/gpio/obsolete.rst +++ b/Documentation/admin-guide/gpio/obsolete.rst @@ -9,4 +9,5 @@ Obsolete GPIO APIs Character Device Userspace API (v1) <../../userspace-api/gpio/chardev_v1> Sysfs Interface <../../userspace-api/gpio/sysfs> + Mockup Testing Module -- cgit v1.2.3 From a0f80b86ff53c2bb99662008269096ecb45d7288 Mon Sep 17 00:00:00 2001 From: Tudor Ambarus Date: Fri, 19 Jan 2024 11:11:26 +0000 Subject: dt-bindings: i2c: exynos5: add google,gs101-hsi2c compatible Add google,gs101-hsi2c dedicated compatible for representing I2C of Google GS101 SoC. Acked-by: Wolfram Sang Acked-by: Rob Herring Reviewed-by: Sam Protsenko Reviewed-by: Peter Griffin Signed-off-by: Tudor Ambarus Link: https://lore.kernel.org/r/20240119111132.1290455-3-tudor.ambarus@linaro.org Signed-off-by: Krzysztof Kozlowski --- Documentation/devicetree/bindings/i2c/i2c-exynos5.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/i2c/i2c-exynos5.yaml b/Documentation/devicetree/bindings/i2c/i2c-exynos5.yaml index df9c57bca2a8..cc8bba5537b9 100644 --- a/Documentation/devicetree/bindings/i2c/i2c-exynos5.yaml +++ b/Documentation/devicetree/bindings/i2c/i2c-exynos5.yaml @@ -33,6 +33,7 @@ properties: - const: samsung,exynos7-hsi2c - items: - enum: + - google,gs101-hsi2c - samsung,exynos850-hsi2c - const: samsung,exynosautov9-hsi2c - const: samsung,exynos5-hsi2c # Exynos5250 and Exynos5420 -- cgit v1.2.3 From f253c9a1aa3360bd6d61407dbfc6ca002855caa3 Mon Sep 17 00:00:00 2001 From: Peter Griffin Date: Fri, 22 Dec 2023 16:53:53 +0000 Subject: dt-bindings: timer: exynos4210-mct: Add google,gs101-mct compatible Add dedicated google,gs101-mct compatible to the dt-schema for representing mct timer of the Google Tensor gs101 SoC. Signed-off-by: Peter Griffin Reviewed-by: Krzysztof Kozlowski Reviewed-by: Sam Protsenko Signed-off-by: Daniel Lezcano Link: https://lore.kernel.org/r/20231222165355.1462740-2-peter.griffin@linaro.org --- Documentation/devicetree/bindings/timer/samsung,exynos4210-mct.yaml | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/timer/samsung,exynos4210-mct.yaml b/Documentation/devicetree/bindings/timer/samsung,exynos4210-mct.yaml index 829bd2227f7c..774b7992a0ca 100644 --- a/Documentation/devicetree/bindings/timer/samsung,exynos4210-mct.yaml +++ b/Documentation/devicetree/bindings/timer/samsung,exynos4210-mct.yaml @@ -26,6 +26,7 @@ properties: - items: - enum: - axis,artpec8-mct + - google,gs101-mct - samsung,exynos3250-mct - samsung,exynos5250-mct - samsung,exynos5260-mct @@ -127,6 +128,7 @@ allOf: contains: enum: - axis,artpec8-mct + - google,gs101-mct - samsung,exynos5260-mct - samsung,exynos5420-mct - samsung,exynos5433-mct -- cgit v1.2.3 From 8e312baaccd296267b41848e362740099157968e Mon Sep 17 00:00:00 2001 From: Jay Buddhabhatti Date: Tue, 16 Jan 2024 17:28:46 +0530 Subject: dt-bindings: firmware: versal: add versal-net compatible string Add dt-binding documentation for Versal NET platforms. Versal Net is a new AMD/Xilinx SoC. The SoC and its architecture is based on the Versal ACAP device. The Versal Net device includes more security features in the platform management controller (PMC) and increases the number of CPUs in the application processing unit (APU) and the real-time processing unit (RPU). Signed-off-by: Jay Buddhabhatti Signed-off-by: Radhey Shyam Pandey Acked-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/1705406326-2947516-1-git-send-email-radhey.shyam.pandey@amd.com Signed-off-by: Michal Simek --- .../devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.yaml | 6 ++++++ 1 file changed, 6 insertions(+) (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 index 8e584857ddd4..cd9fbbb62552 100644 --- a/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.yaml +++ b/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.yaml @@ -26,6 +26,12 @@ properties: - description: For implementations complying for Versal. const: xlnx,versal-firmware + - description: For implementations complying for Versal NET. + items: + - enum: + - xlnx,versal-net-firmware + - const: xlnx,versal-firmware + method: description: | The method of calling the PM-API firmware layer. -- cgit v1.2.3 From 93b7a95f6dd97d76dcdc2dbcf1a2e1be826fd38b Mon Sep 17 00:00:00 2001 From: Michal Simek Date: Tue, 19 Dec 2023 15:31:25 +0100 Subject: dt-bindings: firmware: xilinx: Fix versal-fpga node name Based on commit 83a368a3fc8a ("docs: dt-bindings: add DTS Coding Style document") using underscore ('_') in node name is not recommended that's why switch to dash ('-'). Acked-by: Xu Yilun Acked-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/6779af2f9cc21c912f10cf310388d99b980800b2.1702996281.git.michal.simek@amd.com Signed-off-by: Michal Simek --- .../devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.yaml | 4 ++-- Documentation/devicetree/bindings/fpga/xlnx,versal-fpga.yaml | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) (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 index cd9fbbb62552..5a44e4f74379 100644 --- a/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.yaml +++ b/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.yaml @@ -47,7 +47,7 @@ properties: "#power-domain-cells": const: 1 - versal_fpga: + versal-fpga: $ref: /schemas/fpga/xlnx,versal-fpga.yaml# description: Compatible of the FPGA device. type: object @@ -90,7 +90,7 @@ examples: compatible = "xlnx,versal-firmware"; method = "smc"; - versal_fpga: versal_fpga { + versal_fpga: versal-fpga { compatible = "xlnx,versal-fpga"; }; diff --git a/Documentation/devicetree/bindings/fpga/xlnx,versal-fpga.yaml b/Documentation/devicetree/bindings/fpga/xlnx,versal-fpga.yaml index 26f18834caa3..80833462f620 100644 --- a/Documentation/devicetree/bindings/fpga/xlnx,versal-fpga.yaml +++ b/Documentation/devicetree/bindings/fpga/xlnx,versal-fpga.yaml @@ -26,7 +26,7 @@ additionalProperties: false examples: - | - versal_fpga: versal_fpga { + versal_fpga: versal-fpga { compatible = "xlnx,versal-fpga"; }; -- cgit v1.2.3 From 6f9c4e691f43119ef41321ba61fd4874700c74dd Mon Sep 17 00:00:00 2001 From: Michal Simek Date: Thu, 21 Dec 2023 13:27:54 +0100 Subject: dt-bindings: firmware: xilinx: Describe missing child nodes Firmware node has more than fpga, aes and clock child nodes but also power, reset, gpio, pinctrl and pcap which are not described yet. All of them have binding in separate files but there is missing connection to firmware node that's why describe it. Reviewed-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/1d7988cfadf3554d11f0779f96a670b4fd86ce5a.1703161663.git.michal.simek@amd.com Signed-off-by: Michal Simek --- .../firmware/xilinx/xlnx,zynqmp-firmware.yaml | 50 ++++++++++++++++++++++ 1 file changed, 50 insertions(+) (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 index 5a44e4f74379..9eaa74d0503c 100644 --- a/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.yaml +++ b/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.yaml @@ -47,6 +47,37 @@ properties: "#power-domain-cells": const: 1 + gpio: + $ref: /schemas/gpio/xlnx,zynqmp-gpio-modepin.yaml# + description: The gpio node describes connect to PS_MODE pins via firmware + interface. + type: object + + pcap: + $ref: /schemas/fpga/xlnx,zynqmp-pcap-fpga.yaml + description: The ZynqMP SoC uses the PCAP (Processor Configuration Port) to + configure the Programmable Logic (PL). The configuration uses the + firmware interface. + type: object + + pinctrl: + $ref: /schemas/pinctrl/xlnx,zynqmp-pinctrl.yaml# + description: The pinctrl node provides access to pinconfig and pincontrol + functionality available in firmware. + type: object + + power-management: + $ref: /schemas/power/reset/xlnx,zynqmp-power.yaml# + description: The zynqmp-power node describes the power management + configurations. It will control remote suspend/shutdown interfaces. + type: object + + reset-controller: + $ref: /schemas/reset/xlnx,zynqmp-reset.yaml# + description: The reset-controller node describes connection to the reset + functionality via firmware interface. + type: object + versal-fpga: $ref: /schemas/fpga/xlnx,versal-fpga.yaml# description: Compatible of the FPGA device. @@ -79,7 +110,26 @@ examples: firmware { zynqmp_firmware: zynqmp-firmware { #power-domain-cells = <1>; + gpio { + compatible = "xlnx,zynqmp-gpio-modepin"; + gpio-controller; + #gpio-cells = <2>; + }; + pcap { + compatible = "xlnx,zynqmp-pcap-fpga"; + }; + pinctrl { + compatible = "xlnx,zynqmp-pinctrl"; }; + power-management { + compatible = "xlnx,zynqmp-power"; + interrupts = <0 35 4>; + }; + reset-controller { + compatible = "xlnx,zynqmp-reset"; + #reset-cells = <1>; + }; + }; }; sata { -- cgit v1.2.3 From e83e3c55e46ebc86f2b52e5e0b5654e0596d2a14 Mon Sep 17 00:00:00 2001 From: Michal Simek Date: Thu, 21 Dec 2023 13:27:55 +0100 Subject: dt-bindings: firmware: xilinx: Sort node names (clock-controller) Nodes should be sorted that's why move clock-controller to the top of list. Acked-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/ccb6bd5f4d1d28983c73497ada596e893fece499.1703161663.git.michal.simek@amd.com Signed-off-by: Michal Simek --- .../bindings/firmware/xilinx/xlnx,zynqmp-firmware.yaml | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) (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 index 9eaa74d0503c..7586fbff7ad6 100644 --- a/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.yaml +++ b/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.yaml @@ -47,6 +47,15 @@ properties: "#power-domain-cells": const: 1 + 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 + gpio: $ref: /schemas/gpio/xlnx,zynqmp-gpio-modepin.yaml# description: The gpio node describes connect to PS_MODE pins via firmware @@ -90,15 +99,6 @@ properties: 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 -- cgit v1.2.3 From 9f8bbb531a17c5afcc3a02d92f64194819178254 Mon Sep 17 00:00:00 2001 From: Rob Herring Date: Tue, 28 Nov 2023 16:10:08 -0600 Subject: dt-bindings: Turn on undocumented compatible checks The undocumented compatibles in the examples are down to just a few left. Turn on the warning by default. The increased visibility should get the remaining warnings fixed. Reviewed-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20231128221008.4050638-2-robh@kernel.org Signed-off-by: Rob Herring --- Documentation/devicetree/bindings/Makefile | 3 --- 1 file changed, 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/Makefile b/Documentation/devicetree/bindings/Makefile index 2323fd5b7cda..7653ac50e3b1 100644 --- a/Documentation/devicetree/bindings/Makefile +++ b/Documentation/devicetree/bindings/Makefile @@ -61,9 +61,6 @@ override DTC_FLAGS := \ -Wno-unique_unit_address \ -Wunique_unit_address_if_enabled -# Disable undocumented compatible checks until warning free -override DT_CHECKER_FLAGS ?= - $(obj)/processed-schema.json: $(DT_DOCS) $(src)/.yamllint check_dtschema_version FORCE $(call if_changed_rule,chkdt) -- cgit v1.2.3 From ed3648d264c7f95c7ae0a13d98da0da2018a5bbd Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Mon, 8 Jan 2024 09:37:49 +0100 Subject: docs: dt: submitting-patches: drop outdated points to TXT format New bindings in TXT format are not accepted and DT schema format expects all compatibles to be explicitly defined, thus guidance about "wildcard " is not correct anymore. Drop that paragraph and update one more place which still mentions TXT files. Signed-off-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20240108083750.16350-1-krzysztof.kozlowski@linaro.org Signed-off-by: Rob Herring --- .../devicetree/bindings/submitting-patches.rst | 18 ++++-------------- 1 file changed, 4 insertions(+), 14 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/submitting-patches.rst b/Documentation/devicetree/bindings/submitting-patches.rst index 36a17b250ccc..b460ebffee42 100644 --- a/Documentation/devicetree/bindings/submitting-patches.rst +++ b/Documentation/devicetree/bindings/submitting-patches.rst @@ -42,28 +42,18 @@ I. For patch submitters the code implementing the binding. 6) Any compatible strings used in a chip or board DTS file must be - previously documented in the corresponding DT binding text file + previously documented in the corresponding DT binding file in Documentation/devicetree/bindings. This rule applies even if the Linux device driver does not yet match on the compatible string. [ checkpatch will emit warnings if this step is not followed as of commit bff5da4335256513497cc8c79f9a9d1665e09864 ("checkpatch: add DT compatible string documentation checks"). ] - 7) The wildcard "" may be used in compatible strings, as in - the following example: - - - compatible: Must contain '"nvidia,-pcie", - "nvidia,tegra20-pcie"' where is tegra30, tegra132, ... - - As in the above example, the known values of "" should be - documented if it is used. - - 8) If a documented compatible string is not yet matched by the + 7) If a documented compatible string is not yet matched by the driver, the documentation should also include a compatible - string that is matched by the driver (as in the "nvidia,tegra20-pcie" - example above). + string that is matched by the driver. - 9) Bindings are actively used by multiple projects other than the Linux + 8) Bindings are actively used by multiple projects other than the Linux Kernel, extra care and consideration may need to be taken when making changes to existing bindings. -- cgit v1.2.3 From 9c08be64059e562b2ddcfe884ab35610117e6371 Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Mon, 8 Jan 2024 09:37:50 +0100 Subject: docs: dt: submitting-patches: add commit subject prefix in reversed format ASoC, media, regulators and SPI subsystems prefer commits starting with subsystem name (e.g. "spi: dt-bindings:"), so document this to avoid confusing contributors. Cc: Mark Brown Cc: Mauro Carvalho Chehab Signed-off-by: Krzysztof Kozlowski Reviewed-by: Mark Brown Link: https://lore.kernel.org/r/20240108083750.16350-2-krzysztof.kozlowski@linaro.org Signed-off-by: Rob Herring --- Documentation/devicetree/bindings/submitting-patches.rst | 5 +++++ 1 file changed, 5 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/submitting-patches.rst b/Documentation/devicetree/bindings/submitting-patches.rst index b460ebffee42..a64f21a5f299 100644 --- a/Documentation/devicetree/bindings/submitting-patches.rst +++ b/Documentation/devicetree/bindings/submitting-patches.rst @@ -15,6 +15,11 @@ I. For patch submitters "dt-bindings: : ..." + Few subsystems, like ASoC, media, regulators and SPI, expect reverse order + of the prefixes:: + + ": dt-bindings: ..." + The 80 characters of the subject are precious. It is recommended to not use "Documentation" or "doc" because that is implied. All bindings are docs. Repeating "binding" again should also be avoided. -- cgit v1.2.3 From 3b8435db840cde070fa78a777fa20b098b9abc87 Mon Sep 17 00:00:00 2001 From: Ninad Palsule Date: Tue, 16 Jan 2024 12:37:33 -0600 Subject: dt-bindings: Add DPS310 as trivial device Infineon DPS310 is a barometric pressure and temperature sensor. Acked-by: Krzysztof Kozlowski Signed-off-by: Ninad Palsule Link: https://lore.kernel.org/r/20240116183734.3944028-3-ninad@linux.ibm.com Signed-off-by: Rob Herring --- 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 79dcd92c4a43..5b52950e6bfc 100644 --- a/Documentation/devicetree/bindings/trivial-devices.yaml +++ b/Documentation/devicetree/bindings/trivial-devices.yaml @@ -137,6 +137,8 @@ properties: - ibm,cffps1 # IBM Common Form Factor Power Supply Versions 2 - ibm,cffps2 + # Infineon barometric pressure and temperature sensor + - infineon,dps310 # Infineon IR36021 digital POL buck controller - infineon,ir36021 # Infineon IR38060 Voltage Regulator -- cgit v1.2.3 From 2529085831b01fcd02ff58ab4e2596d3b31bcf80 Mon Sep 17 00:00:00 2001 From: William Qiu Date: Fri, 22 Dec 2023 17:45:45 +0800 Subject: dt-bindings: pwm: Add bindings for OpenCores PWM Controller MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Add bindings for OpenCores PWM Controller. Signed-off-by: William Qiu Reviewed-by: Hal Feng Reviewed-by: Conor Dooley Reviewed-by: Uwe Kleine-König Acked-by: Uwe Kleine-König Signed-off-by: Conor Dooley --- .../devicetree/bindings/pwm/opencores,pwm.yaml | 55 ++++++++++++++++++++++ 1 file changed, 55 insertions(+) create mode 100644 Documentation/devicetree/bindings/pwm/opencores,pwm.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pwm/opencores,pwm.yaml b/Documentation/devicetree/bindings/pwm/opencores,pwm.yaml new file mode 100644 index 000000000000..0b85dd861dfd --- /dev/null +++ b/Documentation/devicetree/bindings/pwm/opencores,pwm.yaml @@ -0,0 +1,55 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pwm/opencores,pwm.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: OpenCores PWM controller + +maintainers: + - William Qiu + +description: + The OpenCores PTC ip core contains a PWM controller. When operating in PWM + mode, the PTC core generates binary signal with user-programmable low and + high periods. All PTC counters and registers are 32-bit. + +allOf: + - $ref: pwm.yaml# + +properties: + compatible: + items: + - enum: + - starfive,jh7100-pwm + - starfive,jh7110-pwm + - const: opencores,pwm-v1 + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + + resets: + maxItems: 1 + + "#pwm-cells": + const: 3 + +required: + - compatible + - reg + - clocks + +additionalProperties: false + +examples: + - | + pwm@12490000 { + compatible = "starfive,jh7110-pwm", "opencores,pwm-v1"; + reg = <0x12490000 0x10000>; + clocks = <&clkgen 181>; + resets = <&rstgen 109>; + #pwm-cells = <3>; + }; -- cgit v1.2.3 From b4d971656407a888df111c8334e46f35cee0368d Mon Sep 17 00:00:00 2001 From: Javier Carrasco Date: Wed, 3 Jan 2024 13:08:52 +0100 Subject: dt-bindings: iio: light: as73211: add support for as7331 This device has the same properties and I2C addresses as the as73211. The only difference between them is the photodiodes they use internally, which in this case is irrelevant for the bindings. Acked-by: Conor Dooley Signed-off-by: Javier Carrasco Signed-off-by: Jonathan Cameron --- Documentation/devicetree/bindings/iio/light/ams,as73211.yaml | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/iio/light/ams,as73211.yaml b/Documentation/devicetree/bindings/iio/light/ams,as73211.yaml index 0e8cd02759b3..062a038aa0ff 100644 --- a/Documentation/devicetree/bindings/iio/light/ams,as73211.yaml +++ b/Documentation/devicetree/bindings/iio/light/ams,as73211.yaml @@ -4,19 +4,22 @@ $id: http://devicetree.org/schemas/iio/light/ams,as73211.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# -title: AMS AS73211 JENCOLOR(R) Digital XYZ Sensor +title: AMS AS73211 JENCOLOR(R) Digital XYZ Sensor and AMS AS7331 UV Sensor maintainers: - Christian Eggers description: | - XYZ True Color Sensor with I2C Interface + AMS AS73211 XYZ True Color Sensor with I2C Interface https://ams.com/documents/20143/36005/AS73211_DS000556_3-01.pdf/a65474c0-b302-c2fd-e30a-c98df87616df + AMS AS7331 UVA, UVB and UVC Sensor with I2C Interface + https://ams.com/documents/20143/9106314/AS7331_DS001047_4-00.pdf properties: compatible: enum: - ams,as73211 + - ams,as7331 reg: description: -- cgit v1.2.3 From 7b34e1e330298cc47985de2e71498ec71f933931 Mon Sep 17 00:00:00 2001 From: Petre Rodan Date: Fri, 29 Dec 2023 11:24:29 +0200 Subject: dt-bindings: iio: pressure: honeywell,mprls0025pa.yaml improvements Define enum inside the honeywell,transfer-function property block. Set the correct irq edge in the example block. Based on the datasheet, in table 13 on page 11: "End-of-conversion indicator: This pin is set high when a measurement and calculation have been completed and the data is ready to be clocked out" Add description on End-of-conversion interrupt. Acked-by: Krzysztof Kozlowski Co-developed-by: Andreas Klinger Signed-off-by: Andreas Klinger Signed-off-by: Petre Rodan Link: https://lore.kernel.org/r/20231229092445.30180-2-petre.rodan@subdimension.ro Signed-off-by: Jonathan Cameron --- .../devicetree/bindings/iio/pressure/honeywell,mprls0025pa.yaml | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/iio/pressure/honeywell,mprls0025pa.yaml b/Documentation/devicetree/bindings/iio/pressure/honeywell,mprls0025pa.yaml index d9e903fbfd99..84ced4e5a7da 100644 --- a/Documentation/devicetree/bindings/iio/pressure/honeywell,mprls0025pa.yaml +++ b/Documentation/devicetree/bindings/iio/pressure/honeywell,mprls0025pa.yaml @@ -42,6 +42,10 @@ properties: maxItems: 1 interrupts: + description: + Optional interrupt for indicating End-of-conversion. + If not present, the driver loops for a while until the received status + byte indicates correct measurement. maxItems: 1 reset-gpios: @@ -65,6 +69,7 @@ properties: 1 - A, 10% to 90% of 2^24 (1677722 .. 15099494) 2 - B, 2.5% to 22.5% of 2^24 (419430 .. 3774874) 3 - C, 20% to 80% of 2^24 (3355443 .. 13421773) + enum: [1, 2, 3] $ref: /schemas/types.yaml#/definitions/uint32 vdd-supply: @@ -93,7 +98,7 @@ examples: reg = <0x18>; reset-gpios = <&gpio3 19 GPIO_ACTIVE_HIGH>; interrupt-parent = <&gpio3>; - interrupts = <21 IRQ_TYPE_EDGE_FALLING>; + interrupts = <21 IRQ_TYPE_EDGE_RISING>; honeywell,pmin-pascal = <0>; honeywell,pmax-pascal = <172369>; honeywell,transfer-function = <1>; -- cgit v1.2.3 From 0181749d4e0e8f11403f9441b1aa1880f42c2226 Mon Sep 17 00:00:00 2001 From: Petre Rodan Date: Fri, 29 Dec 2023 11:24:30 +0200 Subject: dt-bindings: iio: pressure: honeywell,mprls0025pa.yaml add pressure-triplet Change order of properties in order for the end user to hopefully ignore pmin-pascal and pmax-pascal which are superseded by pressure-triplet. Add pressure-triplet property which automatically initializes pmin-pascal and pmax-pascal inside the driver. Rework honeywell,pmXX-pascal requirements based on feedback from Jonathan and Conor. Co-developed-by: Andreas Klinger Signed-off-by: Andreas Klinger Signed-off-by: Petre Rodan Reviewed-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20231229092445.30180-3-petre.rodan@subdimension.ro Signed-off-by: Jonathan Cameron --- .../iio/pressure/honeywell,mprls0025pa.yaml | 64 ++++++++++++++++------ 1 file changed, 46 insertions(+), 18 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/iio/pressure/honeywell,mprls0025pa.yaml b/Documentation/devicetree/bindings/iio/pressure/honeywell,mprls0025pa.yaml index 84ced4e5a7da..6643e51c481d 100644 --- a/Documentation/devicetree/bindings/iio/pressure/honeywell,mprls0025pa.yaml +++ b/Documentation/devicetree/bindings/iio/pressure/honeywell,mprls0025pa.yaml @@ -19,14 +19,17 @@ description: | calls them "mpr series". All of them have the identical programming model and differ in the pressure range, unit and transfer function. - To support different models one need to specify the pressure range as well as - the transfer function. Pressure range needs to be converted from its unit to - pascal. + To support different models one need to specify its pressure triplet as well + as the transfer function. + + For custom silicon chips not covered by the Honeywell MPR series datasheet, + the pressure values can be specified manually via honeywell,pmin-pascal and + honeywell,pmax-pascal. + The minimal range value stands for the minimum pressure and the maximum value + also for the maximum pressure with linear relation inside the range. The transfer function defines the ranges of numerical values delivered by the - sensor. The minimal range value stands for the minimum pressure and the - maximum value also for the maximum pressure with linear relation inside the - range. + sensor. Specifications about the devices can be found at: https://prod-edam.honeywell.com/content/dam/honeywell-edam/sps/siot/en-us/ @@ -54,14 +57,6 @@ properties: If not present the device is not reset during the probe. maxItems: 1 - honeywell,pmin-pascal: - description: - Minimum pressure value the sensor can measure in pascal. - - honeywell,pmax-pascal: - description: - Maximum pressure value the sensor can measure in pascal. - honeywell,transfer-function: description: | Transfer function which defines the range of valid values delivered by the @@ -72,17 +67,50 @@ properties: enum: [1, 2, 3] $ref: /schemas/types.yaml#/definitions/uint32 + honeywell,pressure-triplet: + description: | + Case-sensitive five character string that defines pressure range, unit + and type as part of the device nomenclature. In the unlikely case of a + custom chip, unset and provide pmin-pascal and pmax-pascal instead. + enum: [0001BA, 01.6BA, 02.5BA, 0060MG, 0100MG, 0160MG, 0250MG, 0400MG, + 0600MG, 0001BG, 01.6BG, 02.5BG, 0100KA, 0160KA, 0250KA, 0006KG, + 0010KG, 0016KG, 0025KG, 0040KG, 0060KG, 0100KG, 0160KG, 0250KG, + 0015PA, 0025PA, 0030PA, 0001PG, 0005PG, 0015PG, 0030PG, 0300YG] + $ref: /schemas/types.yaml#/definitions/string + + honeywell,pmin-pascal: + description: + Minimum pressure value the sensor can measure in pascal. + + honeywell,pmax-pascal: + description: + Maximum pressure value the sensor can measure in pascal. + vdd-supply: description: provide VDD power to the sensor. required: - compatible - reg - - honeywell,pmin-pascal - - honeywell,pmax-pascal - honeywell,transfer-function - vdd-supply +oneOf: + - required: + - honeywell,pressure-triplet + - required: + - honeywell,pmin-pascal + - honeywell,pmax-pascal + +allOf: + - if: + required: + - honeywell,pressure-triplet + then: + properties: + honeywell,pmin-pascal: false + honeywell,pmax-pascal: false + additionalProperties: false examples: @@ -99,8 +127,8 @@ examples: reset-gpios = <&gpio3 19 GPIO_ACTIVE_HIGH>; interrupt-parent = <&gpio3>; interrupts = <21 IRQ_TYPE_EDGE_RISING>; - honeywell,pmin-pascal = <0>; - honeywell,pmax-pascal = <172369>; + + honeywell,pressure-triplet = "0025PA"; honeywell,transfer-function = <1>; vdd-supply = <&vcc_3v3>; }; -- cgit v1.2.3 From f088491661012c444f8754d3c46a4aa780ff8ae4 Mon Sep 17 00:00:00 2001 From: Petre Rodan Date: Fri, 29 Dec 2023 11:24:31 +0200 Subject: dt-bindings: iio: pressure: honeywell,mprls0025pa.yaml add spi bus Add spi based example. Add spi-max-frequency property required by chip specifications. Add additional maintainer. Co-developed-by: Andreas Klinger Signed-off-by: Andreas Klinger Signed-off-by: Petre Rodan Reviewed-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20231229092445.30180-4-petre.rodan@subdimension.ro Signed-off-by: Jonathan Cameron --- .../iio/pressure/honeywell,mprls0025pa.yaml | 27 ++++++++++++++++++++-- 1 file changed, 25 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/iio/pressure/honeywell,mprls0025pa.yaml b/Documentation/devicetree/bindings/iio/pressure/honeywell,mprls0025pa.yaml index 6643e51c481d..6994b30015bd 100644 --- a/Documentation/devicetree/bindings/iio/pressure/honeywell,mprls0025pa.yaml +++ b/Documentation/devicetree/bindings/iio/pressure/honeywell,mprls0025pa.yaml @@ -8,12 +8,12 @@ title: Honeywell mprls0025pa pressure sensor maintainers: - Andreas Klinger + - Petre Rodan description: | Honeywell pressure sensor of model mprls0025pa. - This sensor has an I2C and SPI interface. Only the I2C interface is - implemented. + This sensor has an I2C and SPI interface. There are many models with different pressure ranges available. The vendor calls them "mpr series". All of them have the identical programming model and @@ -86,6 +86,9 @@ properties: description: Maximum pressure value the sensor can measure in pascal. + spi-max-frequency: + maximum: 800000 + vdd-supply: description: provide VDD power to the sensor. @@ -103,6 +106,7 @@ oneOf: - honeywell,pmax-pascal allOf: + - $ref: /schemas/spi/spi-peripheral-props.yaml - if: required: - honeywell,pressure-triplet @@ -133,3 +137,22 @@ examples: vdd-supply = <&vcc_3v3>; }; }; + - | + spi { + #address-cells = <1>; + #size-cells = <0>; + + pressure@0 { + compatible = "honeywell,mprls0025pa"; + reg = <0>; + spi-max-frequency = <800000>; + reset-gpios = <&gpio1 28 GPIO_ACTIVE_HIGH>; + interrupt-parent = <&gpio0>; + interrupts = <30 IRQ_TYPE_EDGE_RISING>; + + honeywell,pressure-triplet = "0015PA"; + honeywell,transfer-function = <1>; + vdd-supply = <&vcc_3v3>; + }; + }; +... -- cgit v1.2.3 From 7084f0de2322d85f9802710b008da5c9e5e75222 Mon Sep 17 00:00:00 2001 From: Alexander Stein Date: Tue, 19 Dec 2023 13:29:56 +0100 Subject: ASoC: dt-bindings: fsl-sai: Add power-domains Some SoC like i.MX8QXP use a power-domain for this IP, so add it to the supported properties. Signed-off-by: Alexander Stein Acked-by: Krzysztof Kozlowski Link: https://msgid.link/r/20231219122957.3358149-1-alexander.stein@ew.tq-group.com Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/sound/fsl,sai.yaml | 3 +++ 1 file changed, 3 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/fsl,sai.yaml b/Documentation/devicetree/bindings/sound/fsl,sai.yaml index d81c8fe1893e..af95342f9700 100644 --- a/Documentation/devicetree/bindings/sound/fsl,sai.yaml +++ b/Documentation/devicetree/bindings/sound/fsl,sai.yaml @@ -76,6 +76,9 @@ properties: - const: pll11k minItems: 4 + power-domains: + maxItems: 1 + dmas: items: - description: DMA controller phandle and request line for RX -- cgit v1.2.3 From b6ea4284c7e756fab5f78f0129acdb74b35d759f Mon Sep 17 00:00:00 2001 From: Alexander Stein Date: Tue, 19 Dec 2023 13:29:57 +0100 Subject: ASoC: dt-bindings: fsl-sai: Support Rx-only SAI On SoC like i.MX8QXP some SAI IP cores support only Rx path. Allow specifying only an Rx DMA channel, while omitting the Tx one. Signed-off-by: Alexander Stein Acked-by: Krzysztof Kozlowski Link: https://msgid.link/r/20231219122957.3358149-2-alexander.stein@ew.tq-group.com Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/sound/fsl,sai.yaml | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/fsl,sai.yaml b/Documentation/devicetree/bindings/sound/fsl,sai.yaml index af95342f9700..2456d958adee 100644 --- a/Documentation/devicetree/bindings/sound/fsl,sai.yaml +++ b/Documentation/devicetree/bindings/sound/fsl,sai.yaml @@ -80,11 +80,13 @@ properties: maxItems: 1 dmas: + minItems: 1 items: - description: DMA controller phandle and request line for RX - description: DMA controller phandle and request line for TX dma-names: + minItems: 1 items: - const: rx - const: tx -- cgit v1.2.3 From 6685d552a0cc3a86e10dbe6d98e1b51717a27a63 Mon Sep 17 00:00:00 2001 From: Peng Fan Date: Mon, 22 Jan 2024 17:15:09 +0800 Subject: dt-bindings: spi: fsl-lpspi: support i.MX95 LPSPI Add i.MX95 LPSPI compatible string, same as i.MX93 compatible with i.MX7ULP Signed-off-by: Peng Fan Acked-by: Conor Dooley Link: https://msgid.link/r/20240122091510.2077498-1-peng.fan@oss.nxp.com Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/spi/spi-fsl-lpspi.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/spi/spi-fsl-lpspi.yaml b/Documentation/devicetree/bindings/spi/spi-fsl-lpspi.yaml index 727c5346b8ce..2ff174244795 100644 --- a/Documentation/devicetree/bindings/spi/spi-fsl-lpspi.yaml +++ b/Documentation/devicetree/bindings/spi/spi-fsl-lpspi.yaml @@ -22,6 +22,7 @@ properties: - enum: - fsl,imx8ulp-spi - fsl,imx93-spi + - fsl,imx95-spi - const: fsl,imx7ulp-spi reg: maxItems: 1 -- cgit v1.2.3 From 18ab9e9e8889ecba23a5e8b7f8924f09284e33d8 Mon Sep 17 00:00:00 2001 From: Peng Fan Date: Mon, 22 Jan 2024 17:15:10 +0800 Subject: dt-bindings: spi: nxp-fspi: support i.MX93 and i.MX95 Add i.MX93/95 flexspi compatible strings, which are compatible with i.MX8MM Signed-off-by: Peng Fan Acked-by: Han Xu Acked-by: Conor Dooley Link: https://msgid.link/r/20240122091510.2077498-2-peng.fan@oss.nxp.com Signed-off-by: Mark Brown --- .../devicetree/bindings/spi/spi-nxp-fspi.yaml | 18 ++++++++++++------ 1 file changed, 12 insertions(+), 6 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/spi/spi-nxp-fspi.yaml b/Documentation/devicetree/bindings/spi/spi-nxp-fspi.yaml index 7fd591145480..4a5f41bde00f 100644 --- a/Documentation/devicetree/bindings/spi/spi-nxp-fspi.yaml +++ b/Documentation/devicetree/bindings/spi/spi-nxp-fspi.yaml @@ -15,12 +15,18 @@ allOf: properties: compatible: - enum: - - nxp,imx8dxl-fspi - - nxp,imx8mm-fspi - - nxp,imx8mp-fspi - - nxp,imx8qxp-fspi - - nxp,lx2160a-fspi + oneOf: + - enum: + - nxp,imx8dxl-fspi + - nxp,imx8mm-fspi + - nxp,imx8mp-fspi + - nxp,imx8qxp-fspi + - nxp,lx2160a-fspi + - items: + - enum: + - nxp,imx93-fspi + - nxp,imx95-fspi + - const: nxp,imx8mm-fspi reg: items: -- cgit v1.2.3 From af5b3a595954bdf5a7fb92bd6594fccd241f77b2 Mon Sep 17 00:00:00 2001 From: Konrad Dybcio Date: Sat, 30 Dec 2023 01:05:02 +0100 Subject: dt-bindings: clock: gcc-sc8180x: Add the missing CX power domain The GCC block is (mostly) powered by the VDD_CX rail. Allow specifying it in power-domains. Signed-off-by: Konrad Dybcio Acked-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20231230-topic-8180_more_fixes-v1-1-93b5c107ed43@linaro.org Signed-off-by: Bjorn Andersson --- Documentation/devicetree/bindings/clock/qcom,gcc-sc8180x.yaml | 7 +++++++ 1 file changed, 7 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-sc8180x.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-sc8180x.yaml index 6c4846b34e4b..a1085ef4fd05 100644 --- a/Documentation/devicetree/bindings/clock/qcom,gcc-sc8180x.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,gcc-sc8180x.yaml @@ -31,10 +31,15 @@ properties: - const: bi_tcxo_ao - const: sleep_clk + power-domains: + items: + - description: CX domain + required: - compatible - clocks - clock-names + - power-domains allOf: - $ref: qcom,gcc.yaml# @@ -44,6 +49,7 @@ unevaluatedProperties: false examples: - | #include + #include clock-controller@100000 { compatible = "qcom,gcc-sc8180x"; reg = <0x00100000 0x1f0000>; @@ -51,6 +57,7 @@ examples: <&rpmhcc RPMH_CXO_CLK_A>, <&sleep_clk>; clock-names = "bi_tcxo", "bi_tcxo_ao", "sleep_clk"; + power-domains = <&rpmhpd SC8180X_CX>; #clock-cells = <1>; #reset-cells = <1>; #power-domain-cells = <1>; -- cgit v1.2.3 From 9ac3ebaef3cc43ecd136911c44f1427286ee5a05 Mon Sep 17 00:00:00 2001 From: Erick Archer Date: Sun, 21 Jan 2024 11:43:44 +0100 Subject: Documentation: power: Use kcalloc() instead of kzalloc() As noted in the "Deprecated Interfaces, Language Features, Attributes, and Conventions" documentation [1], size calculations (especially multiplication) should not be performed in memory allocator (or similar) function arguments due to the risk of them overflowing. This could lead to values wrapping around and a smaller allocation being made than the caller was expecting. Using those allocations could lead to linear overflows of heap memory and other misbehaviors. So, in the example code use the purpose specific kcalloc() function instead of the argument size * count in the kzalloc() function. At the same time, modify the translations accordingly. Signed-off-by: Erick Archer Reviewed-by: Hu Haowen <2023002089@link.tyut.edu.cn> Reviewed-by: Yanteng Si Reviewed-by: Hu Haowen <2023002089@link.tyut.edu.cn> Signed-off-by: Viresh Kumar --- Documentation/power/opp.rst | 2 +- Documentation/translations/zh_CN/power/opp.rst | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/power/opp.rst b/Documentation/power/opp.rst index a7c03c470980..1b7f1d854f14 100644 --- a/Documentation/power/opp.rst +++ b/Documentation/power/opp.rst @@ -305,7 +305,7 @@ dev_pm_opp_get_opp_count { /* Do things */ num_available = dev_pm_opp_get_opp_count(dev); - speeds = kzalloc(sizeof(u32) * num_available, GFP_KERNEL); + speeds = kcalloc(num_available, sizeof(u32), GFP_KERNEL); /* populate the table in increasing order */ freq = 0; while (!IS_ERR(opp = dev_pm_opp_find_freq_ceil(dev, &freq))) { diff --git a/Documentation/translations/zh_CN/power/opp.rst b/Documentation/translations/zh_CN/power/opp.rst index 8d6e3f6f6202..7470fa2d4c43 100644 --- a/Documentation/translations/zh_CN/power/opp.rst +++ b/Documentation/translations/zh_CN/power/opp.rst @@ -274,7 +274,7 @@ dev_pm_opp_get_opp_count { /* 做一些事情 */ num_available = dev_pm_opp_get_opp_count(dev); - speeds = kzalloc(sizeof(u32) * num_available, GFP_KERNEL); + speeds = kcalloc(num_available, sizeof(u32), GFP_KERNEL); /* 按升序填充表 */ freq = 0; while (!IS_ERR(opp = dev_pm_opp_find_freq_ceil(dev, &freq))) { -- cgit v1.2.3 From 1cf2bf8ffadf2f0ab9ad10a1e0f65b3a0a10d402 Mon Sep 17 00:00:00 2001 From: David Wronek Date: Sun, 21 Jan 2024 17:57:43 +0100 Subject: dt-bindings: phy: Add QMP UFS PHY compatible for SC7180 Document the QMP UFS PHY compatible for SC7180 Acked-by: Rob Herring Signed-off-by: David Wronek Link: https://lore.kernel.org/r/20240121-sm7125-upstream-v4-3-f7d1212c8ebb@gmail.com Signed-off-by: Vinod Koul --- Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-ufs-phy.yaml | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-ufs-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-ufs-phy.yaml index 8474eef8d0ff..5faa1cb3a12e 100644 --- a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-ufs-phy.yaml +++ b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-ufs-phy.yaml @@ -19,6 +19,7 @@ properties: - qcom,msm8996-qmp-ufs-phy - qcom,msm8998-qmp-ufs-phy - qcom,sa8775p-qmp-ufs-phy + - qcom,sc7180-qmp-ufs-phy - qcom,sc7280-qmp-ufs-phy - qcom,sc8180x-qmp-ufs-phy - qcom,sc8280xp-qmp-ufs-phy @@ -102,6 +103,7 @@ allOf: contains: enum: - qcom,msm8998-qmp-ufs-phy + - qcom,sc7180-qmp-ufs-phy - qcom,sc8180x-qmp-ufs-phy - qcom,sc8280xp-qmp-ufs-phy - qcom,sdm845-qmp-ufs-phy -- cgit v1.2.3 From f80c43887ab3bea4f8b1e112dc1dcc044904cf7b Mon Sep 17 00:00:00 2001 From: Tudor Ambarus Date: Fri, 19 Jan 2024 11:11:25 +0000 Subject: dt-bindings: clock: google,gs101-clock: add PERIC0 clock management unit Add dt-schema documentation for the Connectivity Peripheral 0 (PERIC0) clock management unit. Reviewed-by: Sam Protsenko Reviewed-by: Peter Griffin Reviewed-by: Rob Herring Signed-off-by: Tudor Ambarus Link: https://lore.kernel.org/r/20240119111132.1290455-2-tudor.ambarus@linaro.org Signed-off-by: Krzysztof Kozlowski --- .../bindings/clock/google,gs101-clock.yaml | 25 ++++++- include/dt-bindings/clock/google,gs101.h | 81 ++++++++++++++++++++++ 2 files changed, 104 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/google,gs101-clock.yaml b/Documentation/devicetree/bindings/clock/google,gs101-clock.yaml index 3eebc03a309b..b1202a4f6593 100644 --- a/Documentation/devicetree/bindings/clock/google,gs101-clock.yaml +++ b/Documentation/devicetree/bindings/clock/google,gs101-clock.yaml @@ -30,14 +30,15 @@ properties: - google,gs101-cmu-top - google,gs101-cmu-apm - google,gs101-cmu-misc + - google,gs101-cmu-peric0 clocks: minItems: 1 - maxItems: 2 + maxItems: 3 clock-names: minItems: 1 - maxItems: 2 + maxItems: 3 "#clock-cells": const: 1 @@ -88,6 +89,26 @@ allOf: - const: dout_cmu_misc_bus - const: dout_cmu_misc_sss + - if: + properties: + compatible: + contains: + const: google,gs101-cmu-peric0 + + then: + properties: + clocks: + items: + - description: External reference clock (24.576 MHz) + - description: Connectivity Peripheral 0 bus clock (from CMU_TOP) + - description: Connectivity Peripheral 0 IP clock (from CMU_TOP) + + clock-names: + items: + - const: oscclk + - const: bus + - const: ip + additionalProperties: false examples: diff --git a/include/dt-bindings/clock/google,gs101.h b/include/dt-bindings/clock/google,gs101.h index 21adec22387c..64e6bdc6359c 100644 --- a/include/dt-bindings/clock/google,gs101.h +++ b/include/dt-bindings/clock/google,gs101.h @@ -389,4 +389,85 @@ #define CLK_GOUT_MISC_WDT_CLUSTER1_PCLK 73 #define CLK_GOUT_MISC_XIU_D_MISC_ACLK 74 +/* CMU_PERIC0 */ +#define CLK_MOUT_PERIC0_BUS_USER 1 +#define CLK_MOUT_PERIC0_I3C_USER 2 +#define CLK_MOUT_PERIC0_USI0_UART_USER 3 +#define CLK_MOUT_PERIC0_USI14_USI_USER 4 +#define CLK_MOUT_PERIC0_USI1_USI_USER 5 +#define CLK_MOUT_PERIC0_USI2_USI_USER 6 +#define CLK_MOUT_PERIC0_USI3_USI_USER 7 +#define CLK_MOUT_PERIC0_USI4_USI_USER 8 +#define CLK_MOUT_PERIC0_USI5_USI_USER 9 +#define CLK_MOUT_PERIC0_USI6_USI_USER 10 +#define CLK_MOUT_PERIC0_USI7_USI_USER 11 +#define CLK_MOUT_PERIC0_USI8_USI_USER 12 +#define CLK_DOUT_PERIC0_I3C 13 +#define CLK_DOUT_PERIC0_USI0_UART 14 +#define CLK_DOUT_PERIC0_USI14_USI 15 +#define CLK_DOUT_PERIC0_USI1_USI 16 +#define CLK_DOUT_PERIC0_USI2_USI 17 +#define CLK_DOUT_PERIC0_USI3_USI 18 +#define CLK_DOUT_PERIC0_USI4_USI 19 +#define CLK_DOUT_PERIC0_USI5_USI 20 +#define CLK_DOUT_PERIC0_USI6_USI 21 +#define CLK_DOUT_PERIC0_USI7_USI 22 +#define CLK_DOUT_PERIC0_USI8_USI 23 +#define CLK_GOUT_PERIC0_IP 24 +#define CLK_GOUT_PERIC0_PERIC0_CMU_PERIC0_PCLK 25 +#define CLK_GOUT_PERIC0_CLK_PERIC0_OSCCLK_CLK 26 +#define CLK_GOUT_PERIC0_D_TZPC_PERIC0_PCLK 27 +#define CLK_GOUT_PERIC0_GPC_PERIC0_PCLK 28 +#define CLK_GOUT_PERIC0_GPIO_PERIC0_PCLK 29 +#define CLK_GOUT_PERIC0_LHM_AXI_P_PERIC0_I_CLK 30 +#define CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_0 31 +#define CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_1 32 +#define CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_10 33 +#define CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_11 34 +#define CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_12 35 +#define CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_13 36 +#define CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_14 37 +#define CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_15 38 +#define CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_2 39 +#define CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_3 40 +#define CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_4 41 +#define CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_5 42 +#define CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_6 43 +#define CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_7 44 +#define CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_8 45 +#define CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_9 46 +#define CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_0 47 +#define CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_1 48 +#define CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_10 49 +#define CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_11 50 +#define CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_12 51 +#define CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_13 52 +#define CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_14 53 +#define CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_15 54 +#define CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_2 55 +#define CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_3 56 +#define CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_4 57 +#define CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_5 58 +#define CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_6 59 +#define CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_7 60 +#define CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_8 61 +#define CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_9 62 +#define CLK_GOUT_PERIC0_PERIC0_TOP1_IPCLK_0 63 +#define CLK_GOUT_PERIC0_PERIC0_TOP1_IPCLK_2 64 +#define CLK_GOUT_PERIC0_PERIC0_TOP1_PCLK_0 65 +#define CLK_GOUT_PERIC0_PERIC0_TOP1_PCLK_2 66 +#define CLK_GOUT_PERIC0_CLK_PERIC0_BUSP_CLK 67 +#define CLK_GOUT_PERIC0_CLK_PERIC0_I3C_CLK 68 +#define CLK_GOUT_PERIC0_CLK_PERIC0_USI0_UART_CLK 69 +#define CLK_GOUT_PERIC0_CLK_PERIC0_USI14_USI_CLK 70 +#define CLK_GOUT_PERIC0_CLK_PERIC0_USI1_USI_CLK 71 +#define CLK_GOUT_PERIC0_CLK_PERIC0_USI2_USI_CLK 72 +#define CLK_GOUT_PERIC0_CLK_PERIC0_USI3_USI_CLK 73 +#define CLK_GOUT_PERIC0_CLK_PERIC0_USI4_USI_CLK 74 +#define CLK_GOUT_PERIC0_CLK_PERIC0_USI5_USI_CLK 75 +#define CLK_GOUT_PERIC0_CLK_PERIC0_USI6_USI_CLK 76 +#define CLK_GOUT_PERIC0_CLK_PERIC0_USI7_USI_CLK 77 +#define CLK_GOUT_PERIC0_CLK_PERIC0_USI8_USI_CLK 78 +#define CLK_GOUT_PERIC0_SYSREG_PERIC0_PCLK 79 + #endif /* _DT_BINDINGS_CLOCK_GOOGLE_GS101_H */ -- cgit v1.2.3 From dd4905de4702197f50990be15d359ed9bd0cfa8f Mon Sep 17 00:00:00 2001 From: Varada Pavani Date: Tue, 19 Dec 2023 17:28:33 +0530 Subject: dt-bindings: clock: tesla,fsd: Fix spelling mistake Fix typo 'inteernal' to 'internal' in 'Documentation/devicetree/ bindings/clock/tesla,fsd-clock.yaml'. Signed-off-by: Varada Pavani Link: https://lore.kernel.org/r/20231219115834.65720-1-v.pavani@samsung.com Signed-off-by: Krzysztof Kozlowski --- Documentation/devicetree/bindings/clock/tesla,fsd-clock.yaml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/tesla,fsd-clock.yaml b/Documentation/devicetree/bindings/clock/tesla,fsd-clock.yaml index dc808e2f8327..b370a10a23a6 100644 --- a/Documentation/devicetree/bindings/clock/tesla,fsd-clock.yaml +++ b/Documentation/devicetree/bindings/clock/tesla,fsd-clock.yaml @@ -12,7 +12,7 @@ maintainers: description: | FSD clock controller consist of several clock management unit - (CMU), which generates clocks for various inteernal SoC blocks. + (CMU), which generates clocks for various internal SoC blocks. The root clock comes from external OSC clock (24 MHz). All available clocks are defined as preprocessor macros in -- cgit v1.2.3 From 159919a184c5ef82fac3605b2390b17a549c06ac Mon Sep 17 00:00:00 2001 From: Dmitry Baryshkov Date: Sat, 13 Jan 2024 22:55:46 +0200 Subject: dt-bindings: phy: qcom,msm8998-qmp-usb3-phy: split from sc8280xp PHY schema In preparation to defining the USB-C handling on MSM8998, QCM2290 and SM6115 split existing QMP USB3 PHY schema into pure USB3 and USB-C schema definitions. Signed-off-by: Dmitry Baryshkov Reviewed-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20240113-pmi632-typec-v2-3-182d9aa0a5b3@linaro.org Signed-off-by: Vinod Koul --- .../bindings/phy/qcom,msm8998-qmp-usb3-phy.yaml | 132 +++++++++++++++++++++ .../phy/qcom,sc8280xp-qmp-usb3-uni-phy.yaml | 22 ---- 2 files changed, 132 insertions(+), 22 deletions(-) create mode 100644 Documentation/devicetree/bindings/phy/qcom,msm8998-qmp-usb3-phy.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/phy/qcom,msm8998-qmp-usb3-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,msm8998-qmp-usb3-phy.yaml new file mode 100644 index 000000000000..868fabd44d72 --- /dev/null +++ b/Documentation/devicetree/bindings/phy/qcom,msm8998-qmp-usb3-phy.yaml @@ -0,0 +1,132 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/phy/qcom,msm8998-qmp-usb3-phy.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm QMP PHY controller (USB, MSM8998) + +maintainers: + - Vinod Koul + +description: + The QMP PHY controller supports physical layer functionality for USB-C on + several Qualcomm chipsets. + +properties: + compatible: + enum: + - qcom,msm8998-qmp-usb3-phy + - qcom,qcm2290-qmp-usb3-phy + - qcom,sm6115-qmp-usb3-phy + + reg: + maxItems: 1 + + clocks: + maxItems: 4 + + clock-names: + maxItems: 4 + + resets: + maxItems: 2 + + reset-names: + items: + - const: phy + - const: phy_phy + + vdda-phy-supply: true + + vdda-pll-supply: true + + "#clock-cells": + const: 0 + + clock-output-names: + maxItems: 1 + + "#phy-cells": + const: 0 + +required: + - compatible + - reg + - clocks + - clock-names + - resets + - reset-names + - vdda-phy-supply + - vdda-pll-supply + - "#clock-cells" + - clock-output-names + - "#phy-cells" + +allOf: + - if: + properties: + compatible: + contains: + enum: + - qcom,msm8998-qmp-usb3-phy + then: + properties: + clocks: + maxItems: 4 + clock-names: + items: + - const: aux + - const: ref + - const: cfg_ahb + - const: pipe + + - if: + properties: + compatible: + contains: + enum: + - qcom,qcm2290-qmp-usb3-phy + - qcom,sm6115-qmp-usb3-phy + then: + properties: + clocks: + maxItems: 4 + clock-names: + items: + - const: cfg_ahb + - const: ref + - const: com_aux + - const: pipe + +additionalProperties: false + +examples: + - | + #include + #include + + phy@c010000 { + compatible = "qcom,msm8998-qmp-usb3-phy"; + reg = <0x0c010000 0x1000>; + + clocks = <&gcc GCC_USB3_PHY_AUX_CLK>, + <&gcc GCC_USB3_CLKREF_CLK>, + <&gcc GCC_USB_PHY_CFG_AHB2PHY_CLK>, + <&gcc GCC_USB3_PHY_PIPE_CLK>; + clock-names = "aux", + "ref", + "cfg_ahb", + "pipe"; + clock-output-names = "usb3_phy_pipe_clk_src"; + #clock-cells = <0>; + #phy-cells = <0>; + + resets = <&gcc GCC_USB3_PHY_BCR>, + <&gcc GCC_USB3PHY_PHY_BCR>; + reset-names = "phy", + "phy_phy"; + + vdda-phy-supply = <&vreg_l1a_0p875>; + vdda-pll-supply = <&vreg_l2a_1p2>; + }; diff --git a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-usb3-uni-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-usb3-uni-phy.yaml index 15d82c67f157..1e2d4ddc5391 100644 --- a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-usb3-uni-phy.yaml +++ b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-usb3-uni-phy.yaml @@ -20,15 +20,12 @@ properties: - qcom,ipq8074-qmp-usb3-phy - qcom,ipq9574-qmp-usb3-phy - qcom,msm8996-qmp-usb3-phy - - qcom,msm8998-qmp-usb3-phy - - qcom,qcm2290-qmp-usb3-phy - qcom,sa8775p-qmp-usb3-uni-phy - qcom,sc8280xp-qmp-usb3-uni-phy - qcom,sdm845-qmp-usb3-uni-phy - qcom,sdx55-qmp-usb3-uni-phy - qcom,sdx65-qmp-usb3-uni-phy - qcom,sdx75-qmp-usb3-uni-phy - - qcom,sm6115-qmp-usb3-phy - qcom,sm8150-qmp-usb3-uni-phy - qcom,sm8250-qmp-usb3-uni-phy - qcom,sm8350-qmp-usb3-uni-phy @@ -93,7 +90,6 @@ allOf: - qcom,ipq8074-qmp-usb3-phy - qcom,ipq9574-qmp-usb3-phy - qcom,msm8996-qmp-usb3-phy - - qcom,msm8998-qmp-usb3-phy - qcom,sdx55-qmp-usb3-uni-phy - qcom,sdx65-qmp-usb3-uni-phy - qcom,sdx75-qmp-usb3-uni-phy @@ -108,24 +104,6 @@ allOf: - const: cfg_ahb - const: pipe - - if: - properties: - compatible: - contains: - enum: - - qcom,qcm2290-qmp-usb3-phy - - qcom,sm6115-qmp-usb3-phy - then: - properties: - clocks: - maxItems: 4 - clock-names: - items: - - const: cfg_ahb - - const: ref - - const: com_aux - - const: pipe - - if: properties: compatible: -- cgit v1.2.3 From c1214b579733df7017c0e5f97f26eeb4b66df0c6 Mon Sep 17 00:00:00 2001 From: Dmitry Baryshkov Date: Sat, 13 Jan 2024 22:55:47 +0200 Subject: dt-bindings: phy: qcom,msm8998-qmp-usb3-phy: support USB-C data Extend the Qualcomm USB-C QMP PHY schema with the USB-C related entry points: orientation-switch property and USB-C connection graph. Reviewed-by: Bryan O'Donoghue Signed-off-by: Dmitry Baryshkov Reviewed-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20240113-pmi632-typec-v2-4-182d9aa0a5b3@linaro.org Signed-off-by: Vinod Koul --- .../bindings/phy/qcom,msm8998-qmp-usb3-phy.yaml | 39 ++++++++++++++++++++++ 1 file changed, 39 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/phy/qcom,msm8998-qmp-usb3-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,msm8998-qmp-usb3-phy.yaml index 868fabd44d72..da5d4cbca24c 100644 --- a/Documentation/devicetree/bindings/phy/qcom,msm8998-qmp-usb3-phy.yaml +++ b/Documentation/devicetree/bindings/phy/qcom,msm8998-qmp-usb3-phy.yaml @@ -50,6 +50,22 @@ properties: "#phy-cells": const: 0 + orientation-switch: + description: + Flag the PHY as possible handler of USB Type-C orientation switching + type: boolean + + ports: + $ref: /schemas/graph.yaml#/properties/ports + properties: + port@0: + $ref: /schemas/graph.yaml#/properties/port + description: Output endpoint of the PHY + + port@1: + $ref: /schemas/graph.yaml#/properties/port + description: Incoming endpoint from the USB controller + required: - compatible - reg @@ -129,4 +145,27 @@ examples: vdda-phy-supply = <&vreg_l1a_0p875>; vdda-pll-supply = <&vreg_l2a_1p2>; + + orientation-switch; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + + endpoint { + remote-endpoint = <&pmic_typec_mux_in>; + }; + }; + + port@1 { + reg = <1>; + + endpoint { + remote-endpoint = <&usb_dwc3_ss>; + }; + }; + }; }; -- cgit v1.2.3 From f2b2f86a8bd19feb70649abf8a63d639f4c838d8 Mon Sep 17 00:00:00 2001 From: Dmitry Baryshkov Date: Wed, 17 Jan 2024 16:04:23 +0200 Subject: dt-bindings: phy: qcom,msm8998-qmp-usb3-phy: add TCSR registers The QMP USB PHYs on msm8998, qcm2290 and some other platforms don't have the PCS_MISC_CLAMP_ENABLE register. Instead they need to toggle the register in the TCSR space. Declare the registers accessible through the TCSR space. Reviewed-by: Krzysztof Kozlowski Signed-off-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20240117-usbc-phy-vls-clamp-v2-2-a950c223f10f@linaro.org Signed-off-by: Vinod Koul --- .../devicetree/bindings/phy/qcom,msm8998-qmp-usb3-phy.yaml | 11 +++++++++++ 1 file changed, 11 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/phy/qcom,msm8998-qmp-usb3-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,msm8998-qmp-usb3-phy.yaml index da5d4cbca24c..140843347d1e 100644 --- a/Documentation/devicetree/bindings/phy/qcom,msm8998-qmp-usb3-phy.yaml +++ b/Documentation/devicetree/bindings/phy/qcom,msm8998-qmp-usb3-phy.yaml @@ -55,6 +55,14 @@ properties: Flag the PHY as possible handler of USB Type-C orientation switching type: boolean + qcom,tcsr-reg: + $ref: /schemas/types.yaml#/definitions/phandle-array + items: + - items: + - description: phandle to TCSR hardware block + - description: offset of the VLS CLAMP register + description: Clamp register present in the TCSR + ports: $ref: /schemas/graph.yaml#/properties/ports properties: @@ -78,6 +86,7 @@ required: - "#clock-cells" - clock-output-names - "#phy-cells" + - qcom,tcsr-reg allOf: - if: @@ -148,6 +157,8 @@ examples: orientation-switch; + qcom,tcsr-reg = <&tcsr_regs_1 0x6b244>; + ports { #address-cells = <1>; #size-cells = <0>; -- cgit v1.2.3 From 0ca5e2bf2f4753a879ed3f4a747ee5c947152838 Mon Sep 17 00:00:00 2001 From: Dmitry Baryshkov Date: Tue, 16 Jan 2024 03:10:55 +0200 Subject: dt-bindings: phy: qcom,msm8998-qmp-usb3-phy: support SDM660 Declare the USB-C QMP PHY present on the Qualcomm SDM660 / SDM630 platforms. Signed-off-by: Dmitry Baryshkov Reviewed-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20240116-sdm660-usb3-support-v1-1-2fbd683aea77@linaro.org Signed-off-by: Vinod Koul --- Documentation/devicetree/bindings/phy/qcom,msm8998-qmp-usb3-phy.yaml | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/phy/qcom,msm8998-qmp-usb3-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,msm8998-qmp-usb3-phy.yaml index 140843347d1e..f1f4e4f83352 100644 --- a/Documentation/devicetree/bindings/phy/qcom,msm8998-qmp-usb3-phy.yaml +++ b/Documentation/devicetree/bindings/phy/qcom,msm8998-qmp-usb3-phy.yaml @@ -18,6 +18,7 @@ properties: enum: - qcom,msm8998-qmp-usb3-phy - qcom,qcm2290-qmp-usb3-phy + - qcom,sdm660-qmp-usb3-phy - qcom,sm6115-qmp-usb3-phy reg: @@ -95,6 +96,7 @@ allOf: contains: enum: - qcom,msm8998-qmp-usb3-phy + - qcom,sdm660-qmp-usb3-phy then: properties: clocks: -- cgit v1.2.3 From 55067a491000a28288e25c3fb906ce796d4d5e7d Mon Sep 17 00:00:00 2001 From: Luca Weiss Date: Mon, 22 Jan 2024 19:33:35 -0800 Subject: dt-bindings: input: melfas,mms114: add MMS252 compatible Add a compatible for MMS252 touchscreen which appears to work fine with the MMS114 driver. Signed-off-by: Luca Weiss Signed-off-by: Bryant Mairs Reviewed-by: Krzysztof Kozlowski Reviewed-by: Linus Walleij Link: https://lore.kernel.org/r/20231105204759.37107-2-bryant@mai.rs Signed-off-by: Dmitry Torokhov --- .../devicetree/bindings/input/touchscreen/melfas,mms114.yaml | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/input/touchscreen/melfas,mms114.yaml b/Documentation/devicetree/bindings/input/touchscreen/melfas,mms114.yaml index 07f9dd6b1c9c..90ebd4f8354c 100644 --- a/Documentation/devicetree/bindings/input/touchscreen/melfas,mms114.yaml +++ b/Documentation/devicetree/bindings/input/touchscreen/melfas,mms114.yaml @@ -17,13 +17,17 @@ properties: pattern: "^touchscreen(@.*)?$" compatible: - items: + oneOf: - enum: - melfas,mms114 - melfas,mms134s - melfas,mms136 - melfas,mms152 - melfas,mms345l + - items: + - enum: + - melfas,mms252 + - const: melfas,mms114 reg: description: I2C address -- cgit v1.2.3 From 41b5684e58b1286ae0fa180bc50b661a27efee33 Mon Sep 17 00:00:00 2001 From: ChiYuan Huang Date: Mon, 8 Jan 2024 09:47:27 +0800 Subject: dt-bindings: iio: adc: rtq6056: add support for the whole RTQ6056 family Add compatible support for RTQ6053 and RTQ6059. Signed-off-by: ChiYuan Huang Reviewed-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/c1abb261bb00846f456eb8fe9b5919f59f287c24.1704676198.git.cy_huang@richtek.com Signed-off-by: Jonathan Cameron --- Documentation/devicetree/bindings/iio/adc/richtek,rtq6056.yaml | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/iio/adc/richtek,rtq6056.yaml b/Documentation/devicetree/bindings/iio/adc/richtek,rtq6056.yaml index 88e008629ea8..af2c3a67f888 100644 --- a/Documentation/devicetree/bindings/iio/adc/richtek,rtq6056.yaml +++ b/Documentation/devicetree/bindings/iio/adc/richtek,rtq6056.yaml @@ -25,7 +25,14 @@ description: | properties: compatible: - const: richtek,rtq6056 + oneOf: + - enum: + - richtek,rtq6056 + - richtek,rtq6059 + - items: + - enum: + - richtek,rtq6053 + - const: richtek,rtq6056 reg: maxItems: 1 -- cgit v1.2.3 From 81777efbf59305fa145bede97dd4abdc35540578 Mon Sep 17 00:00:00 2001 From: Dave Thaler Date: Mon, 8 Jan 2024 13:42:31 -0800 Subject: Introduce concept of conformance groups The discussion of what the actual conformance groups should be is still in progress, so this is just part 1 which only uses "legacy" for deprecated instructions and "basic" for everything else. Subsequent patches will add more groups as discussion continues. Signed-off-by: Dave Thaler Acked-by: David Vernet Link: https://lore.kernel.org/r/20240108214231.5280-1-dthaler1968@gmail.com Signed-off-by: Alexei Starovoitov --- .../bpf/standardization/instruction-set.rst | 26 +++++++++++++++++++++- 1 file changed, 25 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/bpf/standardization/instruction-set.rst b/Documentation/bpf/standardization/instruction-set.rst index 245b6defc298..eb0f234a8001 100644 --- a/Documentation/bpf/standardization/instruction-set.rst +++ b/Documentation/bpf/standardization/instruction-set.rst @@ -97,6 +97,28 @@ Definitions A: 10000110 B: 11111111 10000110 +Conformance groups +------------------ + +An implementation does not need to support all instructions specified in this +document (e.g., deprecated instructions). Instead, a number of conformance +groups are specified. An implementation must support the "basic" conformance +group and may support additional conformance groups, where supporting a +conformance group means it must support all instructions in that conformance +group. + +The use of named conformance groups enables interoperability between a runtime +that executes instructions, and tools as such compilers that generate +instructions for the runtime. Thus, capability discovery in terms of +conformance groups might be done manually by users or automatically by tools. + +Each conformance group has a short ASCII label (e.g., "basic") that +corresponds to a set of instructions that are mandatory. That is, each +instruction has one or more conformance groups of which it is a member. + +The "basic" conformance group includes all instructions defined in this +specification unless otherwise noted. + Instruction encoding ==================== @@ -610,4 +632,6 @@ Legacy BPF Packet access instructions BPF previously introduced special instructions for access to packet data that were carried over from classic BPF. However, these instructions are -deprecated and should no longer be used. +deprecated and should no longer be used. All legacy packet access +instructions belong to the "legacy" conformance group instead of the "basic" +conformance group. -- cgit v1.2.3 From 88031b929c01fe3686d34a848c413c2e51e6a7c8 Mon Sep 17 00:00:00 2001 From: Yonghong Song Date: Wed, 10 Jan 2024 21:21:36 -0800 Subject: docs/bpf: Fix an incorrect statement in verifier.rst In verifier.rst, I found an incorrect statement (maybe a typo) in section 'Liveness marks tracking'. Basically, the wrong register is attributed to have a read mark. This may confuse the user. Signed-off-by: Yonghong Song Acked-by: Eduard Zingerman Link: https://lore.kernel.org/r/20240111052136.3440417-1-yonghong.song@linux.dev Signed-off-by: Alexei Starovoitov --- Documentation/bpf/verifier.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/bpf/verifier.rst b/Documentation/bpf/verifier.rst index f0ec19db301c..356894399fbf 100644 --- a/Documentation/bpf/verifier.rst +++ b/Documentation/bpf/verifier.rst @@ -562,7 +562,7 @@ works:: * ``checkpoint[0].r1`` is marked as read; * At instruction #5 exit is reached and ``checkpoint[0]`` can now be processed - by ``clean_live_states()``. After this processing ``checkpoint[0].r0`` has a + by ``clean_live_states()``. After this processing ``checkpoint[0].r1`` has a read mark and all other registers and stack slots are marked as ``NOT_INIT`` or ``STACK_INVALID`` -- cgit v1.2.3 From 20e109ea9842158a153b24ef42ec5cc3d44e9485 Mon Sep 17 00:00:00 2001 From: Dave Thaler Date: Thu, 18 Jan 2024 15:29:54 -0800 Subject: bpf, docs: Clarify that MOVSX is only for BPF_X not BPF_K Per discussion on the mailing list at https://mailarchive.ietf.org/arch/msg/bpf/uQiqhURdtxV_ZQOTgjCdm-seh74/ the MOVSX operation is only defined to support register extension. The document didn't previously state this and incorrectly implied that one could use an immediate value. Signed-off-by: Dave Thaler Acked-by: David Vernet Acked-by: Yonghong Song Link: https://lore.kernel.org/r/20240118232954.27206-1-dthaler1968@gmail.com Signed-off-by: Alexei Starovoitov --- Documentation/bpf/standardization/instruction-set.rst | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/bpf/standardization/instruction-set.rst b/Documentation/bpf/standardization/instruction-set.rst index eb0f234a8001..d17a96c6254f 100644 --- a/Documentation/bpf/standardization/instruction-set.rst +++ b/Documentation/bpf/standardization/instruction-set.rst @@ -317,7 +317,8 @@ The ``BPF_MOVSX`` instruction does a move operation with sign extension. ``BPF_ALU | BPF_MOVSX`` :term:`sign extends` 8-bit and 16-bit operands into 32 bit operands, and zeroes the remaining upper 32 bits. ``BPF_ALU64 | BPF_MOVSX`` :term:`sign extends` 8-bit, 16-bit, and 32-bit -operands into 64 bit operands. +operands into 64 bit operands. Unlike other arithmetic instructions, +``BPF_MOVSX`` is only defined for register source operands (``BPF_X``). Shift operations use a mask of 0x3F (63) for 64-bit operations and 0x1F (31) for 32-bit operations. -- cgit v1.2.3 From e94b29f2bd73db149ce7fee9a41a7b6ca17f7918 Mon Sep 17 00:00:00 2001 From: Abel Vesa Date: Sat, 23 Dec 2023 13:55:21 +0200 Subject: dt-bindings: phy: qcom,sc8280xp-qmp-pcie-phy: Document the X1E80100 QMP PCIe PHYs Document the QMP PCIe PHYs on the X1E80100 platform. Reviewed-by: Krzysztof Kozlowski Signed-off-by: Abel Vesa Link: https://lore.kernel.org/r/20231223-x1e80100-phy-pcie-v2-1-223c0556908a@linaro.org Signed-off-by: Vinod Koul --- .../devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml | 6 ++++++ 1 file changed, 6 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml index 6c03f2d5fca3..ba966a78a128 100644 --- a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml +++ b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml @@ -38,6 +38,8 @@ properties: - qcom,sm8550-qmp-gen4x2-pcie-phy - qcom,sm8650-qmp-gen3x2-pcie-phy - qcom,sm8650-qmp-gen4x2-pcie-phy + - qcom,x1e80100-qmp-gen3x2-pcie-phy + - qcom,x1e80100-qmp-gen4x2-pcie-phy reg: minItems: 1 @@ -151,6 +153,8 @@ allOf: - qcom,sm8550-qmp-gen4x2-pcie-phy - qcom,sm8650-qmp-gen3x2-pcie-phy - qcom,sm8650-qmp-gen4x2-pcie-phy + - qcom,x1e80100-qmp-gen3x2-pcie-phy + - qcom,x1e80100-qmp-gen4x2-pcie-phy then: properties: clocks: @@ -194,6 +198,8 @@ allOf: enum: - qcom,sm8550-qmp-gen4x2-pcie-phy - qcom,sm8650-qmp-gen4x2-pcie-phy + - qcom,x1e80100-qmp-gen3x2-pcie-phy + - qcom,x1e80100-qmp-gen4x2-pcie-phy then: properties: resets: -- cgit v1.2.3 From 0959afbafaf8791a9810fba2c55a64dfdcc3b66e Mon Sep 17 00:00:00 2001 From: Mark Pearson Date: Sat, 20 Jan 2024 18:29:34 -0500 Subject: platform/x86: Support for mode FN key MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit New Thinkpads have added a 'Mode' Function key that on Windows allows you to choose the active profile (low-power, balanced, performance) Added suppoort for this hotkey (F8), and have it cycle through the options available. Tested on X1 Carbon G12. Signed-off-by: Mark Pearson Reviewed-by: Hans de Goede Link: https://lore.kernel.org/r/20240120232949.317337-1-mpearson-lenovo@squebb.ca Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen --- Documentation/admin-guide/laptops/thinkpad-acpi.rst | 7 ++++++- drivers/platform/x86/thinkpad_acpi.c | 20 +++++++++++++++++++- 2 files changed, 25 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/admin-guide/laptops/thinkpad-acpi.rst b/Documentation/admin-guide/laptops/thinkpad-acpi.rst index 98d304010170..7f674a6cfa8a 100644 --- a/Documentation/admin-guide/laptops/thinkpad-acpi.rst +++ b/Documentation/admin-guide/laptops/thinkpad-acpi.rst @@ -444,7 +444,9 @@ event code Key Notes 0x1008 0x07 FN+F8 IBM: toggle screen expand Lenovo: configure UltraNav, - or toggle screen expand + or toggle screen expand. + On newer platforms (2024+) + replaced by 0x131f (see below) 0x1009 0x08 FN+F9 - @@ -504,6 +506,9 @@ event code Key Notes 0x1019 0x18 unknown +0x131f ... FN+F8 Platform Mode change. + Implemented in driver. + ... ... ... 0x1020 0x1F unknown diff --git a/drivers/platform/x86/thinkpad_acpi.c b/drivers/platform/x86/thinkpad_acpi.c index b769d9d60432..897d4cd9e5f4 100644 --- a/drivers/platform/x86/thinkpad_acpi.c +++ b/drivers/platform/x86/thinkpad_acpi.c @@ -166,6 +166,7 @@ enum tpacpi_hkey_event_t { TP_HKEY_EV_VOL_MUTE = 0x1017, /* Mixer output mute */ TP_HKEY_EV_PRIVACYGUARD_TOGGLE = 0x130f, /* Toggle priv.guard on/off */ TP_HKEY_EV_AMT_TOGGLE = 0x131a, /* Toggle AMT on/off */ + TP_HKEY_EV_PROFILE_TOGGLE = 0x131f, /* Toggle platform profile */ /* Reasons for waking up from S3/S4 */ TP_HKEY_EV_WKUP_S3_UNDOCK = 0x2304, /* undock requested, S3 */ @@ -3731,6 +3732,7 @@ static bool hotkey_notify_extended_hotkey(const u32 hkey) switch (hkey) { case TP_HKEY_EV_PRIVACYGUARD_TOGGLE: case TP_HKEY_EV_AMT_TOGGLE: + case TP_HKEY_EV_PROFILE_TOGGLE: tpacpi_driver_event(hkey); return true; } @@ -11115,7 +11117,23 @@ static void tpacpi_driver_event(const unsigned int hkey_event) else dytc_control_amt(!dytc_amt_active); } - + if (hkey_event == TP_HKEY_EV_PROFILE_TOGGLE) { + switch (dytc_current_profile) { + case PLATFORM_PROFILE_LOW_POWER: + dytc_profile_set(NULL, PLATFORM_PROFILE_BALANCED); + break; + case PLATFORM_PROFILE_BALANCED: + dytc_profile_set(NULL, PLATFORM_PROFILE_PERFORMANCE); + break; + case PLATFORM_PROFILE_PERFORMANCE: + dytc_profile_set(NULL, PLATFORM_PROFILE_LOW_POWER); + break; + default: + pr_warn("Profile HKEY unexpected profile %d", dytc_current_profile); + } + /* Notify user space the profile changed */ + platform_profile_notify(); + } } static void hotkey_driver_event(const unsigned int scancode) -- cgit v1.2.3 From 737cf74b38007fd5d5d2f15d4d4bc16e5f1cbfed Mon Sep 17 00:00:00 2001 From: Sam Protsenko Date: Fri, 19 Jan 2024 19:29:43 -0600 Subject: spi: dt-bindings: samsung: Add Exynos850 SPI Document samsung,exynos850-spi compatible which will be used on Exynos850 SoC. Exynos850 doesn't have ioclk, so only two clocks are needed (bus clock and functional SPI clock). Signed-off-by: Sam Protsenko Reviewed-by: Tudor Ambarus Reviewed-by: Krzysztof Kozlowski Link: https://msgid.link/r/20240120012948.8836-3-semen.protsenko@linaro.org Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/spi/samsung,spi.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/spi/samsung,spi.yaml b/Documentation/devicetree/bindings/spi/samsung,spi.yaml index 79da99ca0e53..f71099852653 100644 --- a/Documentation/devicetree/bindings/spi/samsung,spi.yaml +++ b/Documentation/devicetree/bindings/spi/samsung,spi.yaml @@ -22,6 +22,7 @@ properties: - samsung,s5pv210-spi # for S5PV210 and S5PC110 - samsung,exynos4210-spi - samsung,exynos5433-spi + - samsung,exynos850-spi - samsung,exynosautov9-spi - tesla,fsd-spi - const: samsung,exynos7-spi -- cgit v1.2.3 From 42969726a19f796f0e731ec74347fd8a0e4e91a2 Mon Sep 17 00:00:00 2001 From: Kent Gibson Date: Tue, 23 Jan 2024 21:38:28 +0800 Subject: Documentation: gpio: describe uAPI behaviour for unsupported config The existing uAPI documentation does not adequately describe how the kernel handles the case where the underlying hardware or driver does not support the requested configuration. Add a Configuration Support section describing that behaviour to both the v1 and v2 documentation, and better document the errors returned where the requested configuration cannot be supported. Signed-off-by: Kent Gibson Signed-off-by: Bartosz Golaszewski --- Documentation/userspace-api/gpio/error-codes.rst | 3 +- .../gpio/gpio-get-lineevent-ioctl.rst | 6 +++ .../gpio/gpio-get-linehandle-ioctl.rst | 39 +++++++++++++++ .../gpio/gpio-handle-set-config-ioctl.rst | 5 +- .../userspace-api/gpio/gpio-v2-get-line-ioctl.rst | 57 ++++++++++++++++++++-- .../gpio/gpio-v2-line-set-config-ioctl.rst | 3 +- 6 files changed, 106 insertions(+), 7 deletions(-) (limited to 'Documentation') diff --git a/Documentation/userspace-api/gpio/error-codes.rst b/Documentation/userspace-api/gpio/error-codes.rst index edf01f2cf9d2..6bf2948990cd 100644 --- a/Documentation/userspace-api/gpio/error-codes.rst +++ b/Documentation/userspace-api/gpio/error-codes.rst @@ -65,7 +65,8 @@ GPIO Error Codes - - ``ENXIO`` - - No device corresponding to this device special file exists. + - Typically returned when a feature requiring interrupt support was + requested, but the line does not support interrupts. .. note:: diff --git a/Documentation/userspace-api/gpio/gpio-get-lineevent-ioctl.rst b/Documentation/userspace-api/gpio/gpio-get-lineevent-ioctl.rst index 7d0b932925c6..09a9254f38cf 100644 --- a/Documentation/userspace-api/gpio/gpio-get-lineevent-ioctl.rst +++ b/Documentation/userspace-api/gpio/gpio-get-lineevent-ioctl.rst @@ -48,6 +48,12 @@ to its default state. Requesting a line already in use is an error (**EBUSY**). +Requesting edge detection on a line that does not support interrupts is an +error (**ENXIO**). + +As with the :ref:`line handle`, the +bias configuration is best effort. + Closing the ``chip_fd`` has no effect on existing line events. Configuration Rules diff --git a/Documentation/userspace-api/gpio/gpio-get-linehandle-ioctl.rst b/Documentation/userspace-api/gpio/gpio-get-linehandle-ioctl.rst index c8256afe306e..9112a9d31174 100644 --- a/Documentation/userspace-api/gpio/gpio-get-linehandle-ioctl.rst +++ b/Documentation/userspace-api/gpio/gpio-get-linehandle-ioctl.rst @@ -76,6 +76,45 @@ If no bias flags are set then the bias configuration is not changed. Requesting an invalid configuration is an error (**EINVAL**). + +.. _gpio-get-linehandle-config-support: + +Configuration Support +--------------------- + +Where the requested configuration is not directly supported by the underlying +hardware and driver, the kernel applies one of these approaches: + + - reject the request + - emulate the feature in software + - treat the feature as best effort + +The approach applied depends on whether the feature can reasonably be emulated +in software, and the impact on the hardware and userspace if the feature is not +supported. +The approach applied for each feature is as follows: + +============== =========== +Feature Approach +============== =========== +Bias best effort +Direction reject +Drive emulate +============== =========== + +Bias is treated as best effort to allow userspace to apply the same +configuration for platforms that support internal bias as those that require +external bias. +Worst case the line floats rather than being biased as expected. + +Drive is emulated by switching the line to an input when the line should not +be driven. + +In all cases, the configuration reported by gpio-get-lineinfo-ioctl.rst +is the requested configuration, not the resulting hardware configuration. +Userspace cannot determine if a feature is supported in hardware, is +emulated, or is best effort. + Return Value ============ diff --git a/Documentation/userspace-api/gpio/gpio-handle-set-config-ioctl.rst b/Documentation/userspace-api/gpio/gpio-handle-set-config-ioctl.rst index 8f1e748dccc8..d002a84681ac 100644 --- a/Documentation/userspace-api/gpio/gpio-handle-set-config-ioctl.rst +++ b/Documentation/userspace-api/gpio/gpio-handle-set-config-ioctl.rst @@ -41,12 +41,13 @@ line or introducing potential glitches. The configuration applies to all requested lines. -The same :ref:`gpio-get-linehandle-config-rules` that apply when requesting the +The same :ref:`gpio-get-linehandle-config-rules` and +:ref:`gpio-get-linehandle-config-support` that apply when requesting the lines also apply when updating the line configuration. The motivating use case for this command is changing direction of bi-directional lines between input and output, but it may be used more -generally move lines seamlessly from one configuration state to another. +generally to move lines seamlessly from one configuration state to another. To only change the value of output lines, use gpio-handle-set-line-values-ioctl.rst. diff --git a/Documentation/userspace-api/gpio/gpio-v2-get-line-ioctl.rst b/Documentation/userspace-api/gpio/gpio-v2-get-line-ioctl.rst index d76e614c8343..56b975801b6a 100644 --- a/Documentation/userspace-api/gpio/gpio-v2-get-line-ioctl.rst +++ b/Documentation/userspace-api/gpio/gpio-v2-get-line-ioctl.rst @@ -74,7 +74,8 @@ If no bias flags are set then the bias configuration is not changed. The edge flags, ``GPIO_V2_LINE_FLAG_EDGE_xxx``, require ``GPIO_V2_LINE_FLAG_INPUT`` to be set and may be combined to detect both rising -and falling edges. +and falling edges. Requesting edge detection from a line that does not support +it is an error (**ENXIO**). Only one event clock flag, ``GPIO_V2_LINE_FLAG_EVENT_CLOCK_xxx``, may be set. If none are set then the event clock defaults to ``CLOCK_MONOTONIC``. @@ -86,11 +87,61 @@ The :c:type:`debounce_period_us` attribute may only be applied to lines with ``GPIO_V2_LINE_FLAG_INPUT`` set. When set, debounce applies to both the values returned by gpio-v2-line-get-values-ioctl.rst and the edges returned by gpio-v2-line-event-read.rst. If not -supported directly by hardware, the debouncing is performed in software by the -kernel. +supported directly by hardware, debouncing is emulated in software by the +kernel. Requesting debounce on a line that supports neither debounce in +hardware nor interrupts, as required for software emulation, is an error +(**ENXIO**). Requesting an invalid configuration is an error (**EINVAL**). +.. _gpio-v2-get-line-config-support: + +Configuration Support +--------------------- + +Where the requested configuration is not directly supported by the underlying +hardware and driver, the kernel applies one of these approaches: + + - reject the request + - emulate the feature in software + - treat the feature as best effort + +The approach applied depends on whether the feature can reasonably be emulated +in software, and the impact on the hardware and userspace if the feature is not +supported. +The approach applied for each feature is as follows: + +============== =========== +Feature Approach +============== =========== +Bias best effort +Debounce emulate +Direction reject +Drive emulate +Edge Detection reject +============== =========== + +Bias is treated as best effort to allow userspace to apply the same +configuration for platforms that support internal bias as those that require +external bias. +Worst case the line floats rather than being biased as expected. + +Debounce is emulated by applying a filter to hardware interrupts on the line. +An edge event is generated after an edge is detected and the line remains +stable for the debounce period. +The event timestamp corresponds to the end of the debounce period. + +Drive is emulated by switching the line to an input when the line should not +be actively driven. + +Edge detection requires interrupt support, and is rejected if that is not +supported. Emulation by polling can still be performed from userspace. + +In all cases, the configuration reported by gpio-v2-get-lineinfo-ioctl.rst +is the requested configuration, not the resulting hardware configuration. +Userspace cannot determine if a feature is supported in hardware, is +emulated, or is best effort. + Return Value ============ diff --git a/Documentation/userspace-api/gpio/gpio-v2-line-set-config-ioctl.rst b/Documentation/userspace-api/gpio/gpio-v2-line-set-config-ioctl.rst index 126c2626ba6b..9b942a8a53ca 100644 --- a/Documentation/userspace-api/gpio/gpio-v2-line-set-config-ioctl.rst +++ b/Documentation/userspace-api/gpio/gpio-v2-line-set-config-ioctl.rst @@ -37,7 +37,8 @@ line or introducing potential glitches. The new configuration must specify the configuration of all requested lines. -The same :ref:`gpio-v2-get-line-config-rules` that apply when requesting the lines +The same :ref:`gpio-v2-get-line-config-rules` and +:ref:`gpio-v2-get-line-config-support` that apply when requesting the lines also apply when updating the line configuration. The motivating use case for this command is changing direction of -- cgit v1.2.3 From 2f542c937c48c2bd5a8ddf180b417fbe7152559f Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Tue, 23 Jan 2024 09:35:17 +0100 Subject: dt-bindings: memory-controllers: narrow regex for unit address to hex numbers Regular expression used to match the unit address part should not allow non-hex numbers. Reviewed-by: Jon Hunter Link: https://lore.kernel.org/r/20240123083517.21091-1-krzysztof.kozlowski@linaro.org Signed-off-by: Krzysztof Kozlowski --- .../devicetree/bindings/memory-controllers/nvidia,tegra20-emc.yaml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra20-emc.yaml b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra20-emc.yaml index f54e553e6c0e..71896cb10692 100644 --- a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra20-emc.yaml +++ b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra20-emc.yaml @@ -145,7 +145,7 @@ patternProperties: "^emc-table@[0-9]+$": $ref: "#/$defs/emc-table" - "^emc-tables@[a-z0-9-]+$": + "^emc-tables@[a-f0-9-]+$": type: object properties: reg: -- cgit v1.2.3 From 738227ab42fe0c6047f932aef11b9fd647d203f9 Mon Sep 17 00:00:00 2001 From: Cristian Ciocaltea Date: Fri, 19 Jan 2024 21:38:01 +0200 Subject: dt-bindings: soc: rockchip: Add rk3588 hdptxphy syscon Add compatible for the hdptxphy GRF used by rk3588-hdptx-phy. Signed-off-by: Cristian Ciocaltea Acked-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20240119193806.1030214-2-cristian.ciocaltea@collabora.com Signed-off-by: Heiko Stuebner --- Documentation/devicetree/bindings/soc/rockchip/grf.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/soc/rockchip/grf.yaml b/Documentation/devicetree/bindings/soc/rockchip/grf.yaml index 9793ea6f0fe6..61bfe678dc7f 100644 --- a/Documentation/devicetree/bindings/soc/rockchip/grf.yaml +++ b/Documentation/devicetree/bindings/soc/rockchip/grf.yaml @@ -22,6 +22,7 @@ properties: - rockchip,rk3568-usb2phy-grf - rockchip,rk3588-bigcore0-grf - rockchip,rk3588-bigcore1-grf + - rockchip,rk3588-hdptxphy-grf - rockchip,rk3588-ioc - rockchip,rk3588-php-grf - rockchip,rk3588-pipe-phy-grf -- cgit v1.2.3 From e441dd472eb23329de738f365a5429fe7e6f844b Mon Sep 17 00:00:00 2001 From: Chris Morgan Date: Tue, 23 Jan 2024 15:21:09 -0600 Subject: dt-bindings: arm: rockchip: Add Anbernic RG-Arc Add the Anbernic RG-Arc S and RG-Arc D devices, and consolidate all Anbernic RK3566 based devices under a single description. Signed-off-by: Chris Morgan Reviewed-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20240123212111.202146-3-macroalpha82@gmail.com Signed-off-by: Heiko Stuebner --- .../devicetree/bindings/arm/rockchip.yaml | 31 +++++++--------------- 1 file changed, 9 insertions(+), 22 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/rockchip.yaml b/Documentation/devicetree/bindings/arm/rockchip.yaml index 5cf5cbef2cf5..5592fdc85b9e 100644 --- a/Documentation/devicetree/bindings/arm/rockchip.yaml +++ b/Documentation/devicetree/bindings/arm/rockchip.yaml @@ -37,29 +37,16 @@ properties: - anbernic,rg351v - const: rockchip,rk3326 - - description: Anbernic RG353P + - description: Anbernic RK3566 Handheld Gaming Console items: - - const: anbernic,rg353p - - const: rockchip,rk3566 - - - description: Anbernic RG353PS - items: - - const: anbernic,rg353ps - - const: rockchip,rk3566 - - - description: Anbernic RG353V - items: - - const: anbernic,rg353v - - const: rockchip,rk3566 - - - description: Anbernic RG353VS - items: - - const: anbernic,rg353vs - - const: rockchip,rk3566 - - - description: Anbernic RG503 - items: - - const: anbernic,rg503 + - enum: + - anbernic,rg353p + - anbernic,rg353ps + - anbernic,rg353v + - anbernic,rg353vs + - anbernic,rg503 + - anbernic,rg-arc-d + - anbernic,rg-arc-s - const: rockchip,rk3566 - description: Asus Tinker board -- cgit v1.2.3 From 2eaa5e73f51ff5abce18d58f6d0635880df1b8d0 Mon Sep 17 00:00:00 2001 From: Muhammed Efe Cetin Date: Sat, 30 Dec 2023 14:17:59 +0300 Subject: dt-bindings: arm: rockchip: Add NanoPi R6 series boards Add support for NanoPi R6 series boards that based on RK3588S. NanoPi R6S basically has: - USB3 - USB2 - eMMC - 2x 2.5GBe & 1x 1GBe ethernet - HDMI - SD card support Unlike R6S variant, NanoPi R6C has PCIe M.2 M-key instead of 1x 2.5GBe. Signed-off-by: Muhammed Efe Cetin Acked-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/30c1c7eac02cd32b76edb77572523f6ad8de89fb.1703934548.git.efectn@protonmail.com Signed-off-by: Heiko Stuebner --- Documentation/devicetree/bindings/arm/rockchip.yaml | 7 +++++++ 1 file changed, 7 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/rockchip.yaml b/Documentation/devicetree/bindings/arm/rockchip.yaml index 5592fdc85b9e..b03c85a05a92 100644 --- a/Documentation/devicetree/bindings/arm/rockchip.yaml +++ b/Documentation/devicetree/bindings/arm/rockchip.yaml @@ -224,6 +224,13 @@ properties: - friendlyarm,nanopi-r5s - const: rockchip,rk3568 + - description: FriendlyElec NanoPi R6 series boards + items: + - enum: + - friendlyarm,nanopi-r6c + - friendlyarm,nanopi-r6s + - const: rockchip,rk3588s + - description: FriendlyElec NanoPC T6 items: - const: friendlyarm,nanopc-t6 -- cgit v1.2.3 From 35df039b26ac771a019d2f48abd44020eb2615e2 Mon Sep 17 00:00:00 2001 From: Andrew Davis Date: Tue, 9 Jan 2024 11:19:40 -0600 Subject: dt-bindings: gpu: Rename img,powervr to img,powervr-rogue This binding will be used for GPUs starting from Series6 (Rogue) and later. A different binding document will describe Series5. With that the name "img,powervr" is too generic, rename to "img,powervr-rogue" to avoid confusion. Suggested-by: Maxime Ripard Signed-off-by: Andrew Davis Reviewed-by: Javier Martinez Canillas Reviewed-by: Frank Binns Acked-by: Krzysztof Kozlowski Message-ID: <20240109171950.31010-2-afd@ti.com> Signed-off-by: Tony Lindgren --- .../devicetree/bindings/gpu/img,powervr-rogue.yaml | 73 ++++++++++++++++++++++ .../devicetree/bindings/gpu/img,powervr.yaml | 73 ---------------------- MAINTAINERS | 2 +- 3 files changed, 74 insertions(+), 74 deletions(-) create mode 100644 Documentation/devicetree/bindings/gpu/img,powervr-rogue.yaml delete mode 100644 Documentation/devicetree/bindings/gpu/img,powervr.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/gpu/img,powervr-rogue.yaml b/Documentation/devicetree/bindings/gpu/img,powervr-rogue.yaml new file mode 100644 index 000000000000..256e252f8087 --- /dev/null +++ b/Documentation/devicetree/bindings/gpu/img,powervr-rogue.yaml @@ -0,0 +1,73 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +# Copyright (c) 2023 Imagination Technologies Ltd. +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/gpu/img,powervr-rogue.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Imagination Technologies PowerVR and IMG Rogue GPUs + +maintainers: + - Frank Binns + +properties: + compatible: + items: + - enum: + - ti,am62-gpu + - const: img,img-axe # IMG AXE GPU model/revision is fully discoverable + + reg: + maxItems: 1 + + clocks: + minItems: 1 + maxItems: 3 + + clock-names: + items: + - const: core + - const: mem + - const: sys + minItems: 1 + + interrupts: + maxItems: 1 + + power-domains: + maxItems: 1 + +required: + - compatible + - reg + - clocks + - clock-names + - interrupts + +additionalProperties: false + +allOf: + - if: + properties: + compatible: + contains: + const: ti,am62-gpu + then: + properties: + clocks: + maxItems: 1 + +examples: + - | + #include + #include + #include + + gpu@fd00000 { + compatible = "ti,am62-gpu", "img,img-axe"; + reg = <0x0fd00000 0x20000>; + clocks = <&k3_clks 187 0>; + clock-names = "core"; + interrupts = ; + power-domains = <&k3_pds 187 TI_SCI_PD_EXCLUSIVE>; + }; diff --git a/Documentation/devicetree/bindings/gpu/img,powervr.yaml b/Documentation/devicetree/bindings/gpu/img,powervr.yaml deleted file mode 100644 index a13298f1a182..000000000000 --- a/Documentation/devicetree/bindings/gpu/img,powervr.yaml +++ /dev/null @@ -1,73 +0,0 @@ -# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) -# Copyright (c) 2023 Imagination Technologies Ltd. -%YAML 1.2 ---- -$id: http://devicetree.org/schemas/gpu/img,powervr.yaml# -$schema: http://devicetree.org/meta-schemas/core.yaml# - -title: Imagination Technologies PowerVR and IMG GPU - -maintainers: - - Frank Binns - -properties: - compatible: - items: - - enum: - - ti,am62-gpu - - const: img,img-axe # IMG AXE GPU model/revision is fully discoverable - - reg: - maxItems: 1 - - clocks: - minItems: 1 - maxItems: 3 - - clock-names: - items: - - const: core - - const: mem - - const: sys - minItems: 1 - - interrupts: - maxItems: 1 - - power-domains: - maxItems: 1 - -required: - - compatible - - reg - - clocks - - clock-names - - interrupts - -additionalProperties: false - -allOf: - - if: - properties: - compatible: - contains: - const: ti,am62-gpu - then: - properties: - clocks: - maxItems: 1 - -examples: - - | - #include - #include - #include - - gpu@fd00000 { - compatible = "ti,am62-gpu", "img,img-axe"; - reg = <0x0fd00000 0x20000>; - clocks = <&k3_clks 187 0>; - clock-names = "core"; - interrupts = ; - power-domains = <&k3_pds 187 TI_SCI_PD_EXCLUSIVE>; - }; diff --git a/MAINTAINERS b/MAINTAINERS index 8d1052fa6a69..149e2c8c2a5a 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -10470,7 +10470,7 @@ M: Donald Robson M: Matt Coster S: Supported T: git git://anongit.freedesktop.org/drm/drm-misc -F: Documentation/devicetree/bindings/gpu/img,powervr.yaml +F: Documentation/devicetree/bindings/gpu/img,powervr-rogue.yaml F: Documentation/gpu/imagination/ F: drivers/gpu/drm/imagination/ F: include/uapi/drm/pvr_drm.h -- cgit v1.2.3 From 796da8ca7e058ecf7ed2021cb8ce32c2318f83c4 Mon Sep 17 00:00:00 2001 From: Andrew Davis Date: Tue, 9 Jan 2024 11:19:41 -0600 Subject: dt-bindings: gpu: Add PowerVR Series5 SGX GPUs The Imagination PowerVR Series5 "SGX" GPU is part of several SoCs from multiple vendors. Describe how the SGX GPU is integrated in these SoC, including register space and interrupts. Clocks, reset, and power domain information is SoC specific. Signed-off-by: Andrew Davis Reviewed-by: Javier Martinez Canillas Reviewed-by: Krzysztof Kozlowski Message-ID: <20240109171950.31010-3-afd@ti.com> Signed-off-by: Tony Lindgren --- .../devicetree/bindings/gpu/img,powervr-sgx.yaml | 138 +++++++++++++++++++++ MAINTAINERS | 1 + 2 files changed, 139 insertions(+) create mode 100644 Documentation/devicetree/bindings/gpu/img,powervr-sgx.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/gpu/img,powervr-sgx.yaml b/Documentation/devicetree/bindings/gpu/img,powervr-sgx.yaml new file mode 100644 index 000000000000..f5898b04381c --- /dev/null +++ b/Documentation/devicetree/bindings/gpu/img,powervr-sgx.yaml @@ -0,0 +1,138 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +# Copyright (c) 2023 Imagination Technologies Ltd. +# Copyright (C) 2024 Texas Instruments Incorporated - https://www.ti.com/ +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/gpu/img,powervr-sgx.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Imagination Technologies PowerVR SGX GPUs + +maintainers: + - Frank Binns + +properties: + compatible: + oneOf: + - items: + - enum: + - ti,omap3430-gpu # Rev 121 + - ti,omap3630-gpu # Rev 125 + - const: img,powervr-sgx530 + - items: + - enum: + - ingenic,jz4780-gpu # Rev 130 + - ti,omap4430-gpu # Rev 120 + - const: img,powervr-sgx540 + - items: + - enum: + - allwinner,sun6i-a31-gpu # MP2 Rev 115 + - ti,omap4470-gpu # MP1 Rev 112 + - ti,omap5432-gpu # MP2 Rev 105 + - ti,am5728-gpu # MP2 Rev 116 + - ti,am6548-gpu # MP1 Rev 117 + - const: img,powervr-sgx544 + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + minItems: 1 + maxItems: 3 + + clock-names: + minItems: 1 + items: + - const: core + - const: mem + - const: sys + + power-domains: + maxItems: 1 + +required: + - compatible + - reg + - interrupts + +allOf: + - if: + properties: + compatible: + contains: + const: ti,am6548-gpu + then: + required: + - power-domains + else: + properties: + power-domains: false + - if: + properties: + compatible: + contains: + enum: + - allwinner,sun6i-a31-gpu + - ingenic,jz4780-gpu + then: + required: + - clocks + - clock-names + else: + properties: + clocks: false + clock-names: false + - if: + properties: + compatible: + contains: + const: allwinner,sun6i-a31-gpu + then: + properties: + clocks: + minItems: 2 + maxItems: 2 + clock-names: + minItems: 2 + maxItems: 2 + - if: + properties: + compatible: + contains: + const: ingenic,jz4780-gpu + then: + properties: + clocks: + maxItems: 1 + clock-names: + maxItems: 1 + +additionalProperties: false + +examples: + - | + #include + #include + #include + + gpu@7000000 { + compatible = "ti,am6548-gpu", "img,powervr-sgx544"; + reg = <0x7000000 0x10000>; + interrupts = ; + power-domains = <&k3_pds 65 TI_SCI_PD_EXCLUSIVE>; + }; + + - | + #include + #include + + gpu: gpu@1c40000 { + compatible = "allwinner,sun6i-a31-gpu", "img,powervr-sgx544"; + reg = <0x01c40000 0x10000>; + interrupts = ; + clocks = <&ccu 1>, <&ccu 2>; + clock-names = "core", "mem"; + }; diff --git a/MAINTAINERS b/MAINTAINERS index 149e2c8c2a5a..cdc432aab760 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -10471,6 +10471,7 @@ M: Matt Coster S: Supported T: git git://anongit.freedesktop.org/drm/drm-misc F: Documentation/devicetree/bindings/gpu/img,powervr-rogue.yaml +F: Documentation/devicetree/bindings/gpu/img,powervr-sgx.yaml F: Documentation/gpu/imagination/ F: drivers/gpu/drm/imagination/ F: include/uapi/drm/pvr_drm.h -- cgit v1.2.3 From 5d7e1c411c0d703e51cc812a3dac22f1f0b11253 Mon Sep 17 00:00:00 2001 From: Luca Weiss Date: Fri, 5 Jan 2024 17:15:43 +0100 Subject: dt-bindings: qcom-qce: Add compatible for SM6350 Add a compatible for the crypto block found on the SM6350 SoC. Signed-off-by: Luca Weiss Acked-by: Krzysztof Kozlowski Signed-off-by: Herbert Xu --- Documentation/devicetree/bindings/crypto/qcom-qce.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/crypto/qcom-qce.yaml b/Documentation/devicetree/bindings/crypto/qcom-qce.yaml index a48bd381063a..e285e382d4ec 100644 --- a/Documentation/devicetree/bindings/crypto/qcom-qce.yaml +++ b/Documentation/devicetree/bindings/crypto/qcom-qce.yaml @@ -45,6 +45,7 @@ properties: - items: - enum: - qcom,sc7280-qce + - qcom,sm6350-qce - qcom,sm8250-qce - qcom,sm8350-qce - qcom,sm8450-qce -- cgit v1.2.3 From 8413fe3e7fdfb412baa9e31b3f1d2eaf6d21a373 Mon Sep 17 00:00:00 2001 From: Weili Qian Date: Fri, 12 Jan 2024 18:25:45 +0800 Subject: crypto: hisilicon/qm - support get device state Support get device current state. The value 0 indicates that the device is busy, and the value 1 indicates that the device is idle. When the device is in suspended, 1 is returned. Signed-off-by: Weili Qian Signed-off-by: Herbert Xu --- Documentation/ABI/testing/debugfs-hisi-hpre | 7 +++++++ Documentation/ABI/testing/debugfs-hisi-sec | 7 +++++++ Documentation/ABI/testing/debugfs-hisi-zip | 7 +++++++ drivers/crypto/hisilicon/debugfs.c | 29 +++++++++++++++++++++++++++++ 4 files changed, 50 insertions(+) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/debugfs-hisi-hpre b/Documentation/ABI/testing/debugfs-hisi-hpre index 8e8de49c5cc6..6ed9258605c7 100644 --- a/Documentation/ABI/testing/debugfs-hisi-hpre +++ b/Documentation/ABI/testing/debugfs-hisi-hpre @@ -111,6 +111,13 @@ Description: QM debug registers(regs) read hardware register value. This node is used to show the change of the qm register values. This node can be help users to check the change of register values. +What: /sys/kernel/debug/hisi_hpre//qm/qm_state +Date: Jan 2024 +Contact: linux-crypto@vger.kernel.org +Description: Dump the state of the device. + 0: busy, 1: idle. + Only available for PF, and take no other effect on HPRE. + What: /sys/kernel/debug/hisi_hpre//hpre_dfx/diff_regs Date: Mar 2022 Contact: linux-crypto@vger.kernel.org diff --git a/Documentation/ABI/testing/debugfs-hisi-sec b/Documentation/ABI/testing/debugfs-hisi-sec index deeefe2c735e..403f5de96318 100644 --- a/Documentation/ABI/testing/debugfs-hisi-sec +++ b/Documentation/ABI/testing/debugfs-hisi-sec @@ -91,6 +91,13 @@ Description: QM debug registers(regs) read hardware register value. This node is used to show the change of the qm register values. This node can be help users to check the change of register values. +What: /sys/kernel/debug/hisi_sec2//qm/qm_state +Date: Jan 2024 +Contact: linux-crypto@vger.kernel.org +Description: Dump the state of the device. + 0: busy, 1: idle. + Only available for PF, and take no other effect on SEC. + What: /sys/kernel/debug/hisi_sec2//sec_dfx/diff_regs Date: Mar 2022 Contact: linux-crypto@vger.kernel.org diff --git a/Documentation/ABI/testing/debugfs-hisi-zip b/Documentation/ABI/testing/debugfs-hisi-zip index 593714afaed2..2394e6a3cfe2 100644 --- a/Documentation/ABI/testing/debugfs-hisi-zip +++ b/Documentation/ABI/testing/debugfs-hisi-zip @@ -104,6 +104,13 @@ Description: QM debug registers(regs) read hardware register value. This node is used to show the change of the qm registers value. This node can be help users to check the change of register values. +What: /sys/kernel/debug/hisi_zip//qm/qm_state +Date: Jan 2024 +Contact: linux-crypto@vger.kernel.org +Description: Dump the state of the device. + 0: busy, 1: idle. + Only available for PF, and take no other effect on ZIP. + What: /sys/kernel/debug/hisi_zip//zip_dfx/diff_regs Date: Mar 2022 Contact: linux-crypto@vger.kernel.org diff --git a/drivers/crypto/hisilicon/debugfs.c b/drivers/crypto/hisilicon/debugfs.c index 80ed4b2d209c..615c8e18d8b0 100644 --- a/drivers/crypto/hisilicon/debugfs.c +++ b/drivers/crypto/hisilicon/debugfs.c @@ -24,6 +24,8 @@ #define QM_DFX_QN_SHIFT 16 #define QM_DFX_CNT_CLR_CE 0x100118 #define QM_DBG_WRITE_LEN 1024 +#define QM_IN_IDLE_ST_REG 0x1040e4 +#define QM_IN_IDLE_STATE 0x1 static const char * const qm_debug_file_name[] = { [CURRENT_QM] = "current_qm", @@ -1001,6 +1003,30 @@ static int qm_diff_regs_show(struct seq_file *s, void *unused) } DEFINE_SHOW_ATTRIBUTE(qm_diff_regs); +static int qm_state_show(struct seq_file *s, void *unused) +{ + struct hisi_qm *qm = s->private; + u32 val; + int ret; + + /* If device is in suspended, directly return the idle state. */ + ret = hisi_qm_get_dfx_access(qm); + if (!ret) { + val = readl(qm->io_base + QM_IN_IDLE_ST_REG); + hisi_qm_put_dfx_access(qm); + } else if (ret == -EAGAIN) { + val = QM_IN_IDLE_STATE; + } else { + return ret; + } + + seq_printf(s, "%u\n", val); + + return 0; +} + +DEFINE_SHOW_ATTRIBUTE(qm_state); + static ssize_t qm_status_read(struct file *filp, char __user *buffer, size_t count, loff_t *pos) { @@ -1072,6 +1098,9 @@ void hisi_qm_debug_init(struct hisi_qm *qm) /* only show this in PF */ if (qm->fun_type == QM_HW_PF) { + debugfs_create_file("qm_state", 0444, qm->debug.qm_d, + qm, &qm_state_fops); + qm_create_debugfs_file(qm, qm->debug.debug_root, CURRENT_QM); for (i = CURRENT_Q; i < DEBUG_FILE_NUM; i++) qm_create_debugfs_file(qm, qm->debug.qm_d, i); -- cgit v1.2.3 From 4d314d27130b674a3687135fe94f44a40f107f76 Mon Sep 17 00:00:00 2001 From: David Wronek Date: Sun, 21 Jan 2024 17:57:41 +0100 Subject: dt-bindings: crypto: ice: Document SC7180 inline crypto engine Document the compatible used for the inline crypto engine found on SC7180. Acked-by: Rob Herring Signed-off-by: David Wronek Signed-off-by: Herbert Xu --- Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml b/Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml index 09e43157cc71..e91bc7dc6ad3 100644 --- a/Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml +++ b/Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml @@ -14,6 +14,7 @@ properties: items: - enum: - qcom,sa8775p-inline-crypto-engine + - qcom,sc7180-inline-crypto-engine - qcom,sm8450-inline-crypto-engine - qcom,sm8550-inline-crypto-engine - qcom,sm8650-inline-crypto-engine -- cgit v1.2.3 From 36553eb7785da18568de2b8ecafb3d80db1a0d6b Mon Sep 17 00:00:00 2001 From: Rob Herring Date: Wed, 24 Jan 2024 13:07:53 -0600 Subject: ASoC: dt-bindings: samsung,tm2: Correct "audio-codec" constraints The "audio-codec" constraints define how many entries(2), but not the size of each entry. Each entry is a single phandle. Define the size with an inner 'items' list. Signed-off-by: Rob Herring Link: https://msgid.link/r/20240124190754.1554899-1-robh@kernel.org Reviewed-by: Krzysztof Kozlowski Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/sound/samsung,tm2.yaml | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/samsung,tm2.yaml b/Documentation/devicetree/bindings/sound/samsung,tm2.yaml index 760592599143..cbc7ba37362a 100644 --- a/Documentation/devicetree/bindings/sound/samsung,tm2.yaml +++ b/Documentation/devicetree/bindings/sound/samsung,tm2.yaml @@ -25,8 +25,11 @@ properties: description: Phandles to the codecs. $ref: /schemas/types.yaml#/definitions/phandle-array items: - - description: Phandle to the WM5110 audio codec. - - description: Phandle to the HDMI transmitter node. + - items: + - description: Phandle to the WM5110 audio codec. + - items: + - description: Phandle to the HDMI transmitter node. + samsung,audio-routing: description: | -- cgit v1.2.3 From 01dffdcaa094858a03e3694694815f1a4915940c Mon Sep 17 00:00:00 2001 From: Rob Herring Date: Wed, 24 Jan 2024 13:08:07 -0600 Subject: ASoC: dt-bindings: audio-graph-port: Drop type from "clocks" "clocks" is a standard property which already has a type. Users only need to define how many clocks and what each clock is if more than 1 clock. Signed-off-by: Rob Herring Link: https://msgid.link/r/20240124190808.1555263-1-robh@kernel.org Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/sound/audio-graph-port.yaml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/audio-graph-port.yaml b/Documentation/devicetree/bindings/sound/audio-graph-port.yaml index b13c08de505e..28b27e7e45de 100644 --- a/Documentation/devicetree/bindings/sound/audio-graph-port.yaml +++ b/Documentation/devicetree/bindings/sound/audio-graph-port.yaml @@ -51,7 +51,7 @@ definitions: - $ref: /schemas/types.yaml#/definitions/phandle clocks: description: Indicates system clock - $ref: /schemas/types.yaml#/definitions/phandle + maxItems: 1 system-clock-frequency: $ref: simple-card.yaml#/definitions/system-clock-frequency system-clock-direction-out: -- cgit v1.2.3 From e48f0f4a9bfed8947e4d1123e8b6a15c18ee1708 Mon Sep 17 00:00:00 2001 From: Dave Thaler Date: Thu, 25 Jan 2024 20:00:50 -0800 Subject: bpf, docs: Clarify definitions of various instructions Clarify definitions of several instructions: * BPF_NEG does not support BPF_X * BPF_CALL does not support BPF_JMP32 or BPF_X * BPF_EXIT does not support BPF_X * BPF_JA does not support BPF_X (was implied but not explicitly stated) Also fix a typo in the wide instruction figure where the field is actually named "opcode" not "code". Signed-off-by: Dave Thaler Signed-off-by: Daniel Borkmann Acked-by: Yonghong Song Link: https://lore.kernel.org/bpf/20240126040050.8464-1-dthaler1968@gmail.com --- .../bpf/standardization/instruction-set.rst | 51 ++++++++++++---------- 1 file changed, 27 insertions(+), 24 deletions(-) (limited to 'Documentation') diff --git a/Documentation/bpf/standardization/instruction-set.rst b/Documentation/bpf/standardization/instruction-set.rst index d17a96c6254f..af43227b6ee4 100644 --- a/Documentation/bpf/standardization/instruction-set.rst +++ b/Documentation/bpf/standardization/instruction-set.rst @@ -174,12 +174,12 @@ and imm containing the high 32 bits of the immediate value. This is depicted in the following figure:: basic_instruction - .-----------------------------. - | | - code:8 regs:8 offset:16 imm:32 unused:32 imm:32 - | | - '--------------' - pseudo instruction + .------------------------------. + | | + opcode:8 regs:8 offset:16 imm:32 unused:32 imm:32 + | | + '--------------' + pseudo instruction Thus the 64-bit immediate value is constructed as follows: @@ -320,6 +320,9 @@ bit operands, and zeroes the remaining upper 32 bits. operands into 64 bit operands. Unlike other arithmetic instructions, ``BPF_MOVSX`` is only defined for register source operands (``BPF_X``). +The ``BPF_NEG`` instruction is only defined when the source bit is clear +(``BPF_K``). + Shift operations use a mask of 0x3F (63) for 64-bit operations and 0x1F (31) for 32-bit operations. @@ -375,27 +378,27 @@ Jump instructions otherwise identical operations. The 'code' field encodes the operation as below: -======== ===== === =========================================== ========================================= -code value src description notes -======== ===== === =========================================== ========================================= -BPF_JA 0x0 0x0 PC += offset BPF_JMP class -BPF_JA 0x0 0x0 PC += imm BPF_JMP32 class +======== ===== === =============================== ============================================= +code value src description notes +======== ===== === =============================== ============================================= +BPF_JA 0x0 0x0 PC += offset BPF_JMP | BPF_K only +BPF_JA 0x0 0x0 PC += imm BPF_JMP32 | BPF_K only BPF_JEQ 0x1 any PC += offset if dst == src -BPF_JGT 0x2 any PC += offset if dst > src unsigned -BPF_JGE 0x3 any PC += offset if dst >= src unsigned +BPF_JGT 0x2 any PC += offset if dst > src unsigned +BPF_JGE 0x3 any PC += offset if dst >= src unsigned BPF_JSET 0x4 any PC += offset if dst & src BPF_JNE 0x5 any PC += offset if dst != src -BPF_JSGT 0x6 any PC += offset if dst > src signed -BPF_JSGE 0x7 any PC += offset if dst >= src signed -BPF_CALL 0x8 0x0 call helper function by address see `Helper functions`_ -BPF_CALL 0x8 0x1 call PC += imm see `Program-local functions`_ -BPF_CALL 0x8 0x2 call helper function by BTF ID see `Helper functions`_ -BPF_EXIT 0x9 0x0 return BPF_JMP only -BPF_JLT 0xa any PC += offset if dst < src unsigned -BPF_JLE 0xb any PC += offset if dst <= src unsigned -BPF_JSLT 0xc any PC += offset if dst < src signed -BPF_JSLE 0xd any PC += offset if dst <= src signed -======== ===== === =========================================== ========================================= +BPF_JSGT 0x6 any PC += offset if dst > src signed +BPF_JSGE 0x7 any PC += offset if dst >= src signed +BPF_CALL 0x8 0x0 call helper function by address BPF_JMP | BPF_K only, see `Helper functions`_ +BPF_CALL 0x8 0x1 call PC += imm BPF_JMP | BPF_K only, see `Program-local functions`_ +BPF_CALL 0x8 0x2 call helper function by BTF ID BPF_JMP | BPF_K only, see `Helper functions`_ +BPF_EXIT 0x9 0x0 return BPF_JMP | BPF_K only +BPF_JLT 0xa any PC += offset if dst < src unsigned +BPF_JLE 0xb any PC += offset if dst <= src unsigned +BPF_JSLT 0xc any PC += offset if dst < src signed +BPF_JSLE 0xd any PC += offset if dst <= src signed +======== ===== === =============================== ============================================= The BPF program needs to store the return value into register R0 before doing a ``BPF_EXIT``. -- cgit v1.2.3 From c94d1783136eb66f2a464a6891a32eeb55eaeacc Mon Sep 17 00:00:00 2001 From: Christian Marangi Date: Thu, 25 Jan 2024 21:36:57 +0100 Subject: dt-bindings: net: phy: Make LED active-low property common Move LED active-low property to common.yaml. This property is currently defined multiple times by bcm LEDs. This property will now be supported in a generic way for PHY LEDs with the use of a generic function. With active-low bool property not defined, active-high is always assumed. Signed-off-by: Christian Marangi Reviewed-by: Andrew Lunn Acked-by: Lee Jones Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20240125203702.4552-2-ansuelsmth@gmail.com Signed-off-by: Jakub Kicinski --- Documentation/devicetree/bindings/leds/common.yaml | 6 ++++++ Documentation/devicetree/bindings/leds/leds-bcm63138.yaml | 4 ---- Documentation/devicetree/bindings/leds/leds-bcm6328.yaml | 4 ---- Documentation/devicetree/bindings/leds/leds-bcm6358.txt | 2 -- Documentation/devicetree/bindings/leds/leds-pwm-multicolor.yaml | 4 ---- Documentation/devicetree/bindings/leds/leds-pwm.yaml | 5 ----- 6 files changed, 6 insertions(+), 19 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/leds/common.yaml b/Documentation/devicetree/bindings/leds/common.yaml index 55a8d1385e21..5633e0aa6bdf 100644 --- a/Documentation/devicetree/bindings/leds/common.yaml +++ b/Documentation/devicetree/bindings/leds/common.yaml @@ -200,6 +200,12 @@ properties: #trigger-source-cells property in the source node. $ref: /schemas/types.yaml#/definitions/phandle-array + active-low: + type: boolean + description: + Makes LED active low. To turn the LED ON, line needs to be + set to low voltage instead of high. + # Required properties for flash LED child nodes: flash-max-microamp: description: diff --git a/Documentation/devicetree/bindings/leds/leds-bcm63138.yaml b/Documentation/devicetree/bindings/leds/leds-bcm63138.yaml index 52252fb6bb32..bb20394fca5c 100644 --- a/Documentation/devicetree/bindings/leds/leds-bcm63138.yaml +++ b/Documentation/devicetree/bindings/leds/leds-bcm63138.yaml @@ -52,10 +52,6 @@ patternProperties: maxItems: 1 description: LED pin number - active-low: - type: boolean - description: Makes LED active low - required: - reg diff --git a/Documentation/devicetree/bindings/leds/leds-bcm6328.yaml b/Documentation/devicetree/bindings/leds/leds-bcm6328.yaml index 51cc0d82c12e..f3a3ef992929 100644 --- a/Documentation/devicetree/bindings/leds/leds-bcm6328.yaml +++ b/Documentation/devicetree/bindings/leds/leds-bcm6328.yaml @@ -78,10 +78,6 @@ patternProperties: - maximum: 23 description: LED pin number (only LEDs 0 to 23 are valid). - active-low: - type: boolean - description: Makes LED active low. - brcm,hardware-controlled: type: boolean description: Makes this LED hardware controlled. diff --git a/Documentation/devicetree/bindings/leds/leds-bcm6358.txt b/Documentation/devicetree/bindings/leds/leds-bcm6358.txt index 6e51c6b91ee5..211ffc3c4a20 100644 --- a/Documentation/devicetree/bindings/leds/leds-bcm6358.txt +++ b/Documentation/devicetree/bindings/leds/leds-bcm6358.txt @@ -25,8 +25,6 @@ LED sub-node required properties: LED sub-node optional properties: - label : see Documentation/devicetree/bindings/leds/common.txt - - active-low : Boolean, makes LED active low. - Default : false - default-state : see Documentation/devicetree/bindings/leds/common.txt - linux,default-trigger : see diff --git a/Documentation/devicetree/bindings/leds/leds-pwm-multicolor.yaml b/Documentation/devicetree/bindings/leds/leds-pwm-multicolor.yaml index bd6ec04a8727..5edfbe347341 100644 --- a/Documentation/devicetree/bindings/leds/leds-pwm-multicolor.yaml +++ b/Documentation/devicetree/bindings/leds/leds-pwm-multicolor.yaml @@ -41,10 +41,6 @@ properties: pwm-names: true - active-low: - description: For PWMs where the LED is wired to supply rather than ground. - type: boolean - color: true required: diff --git a/Documentation/devicetree/bindings/leds/leds-pwm.yaml b/Documentation/devicetree/bindings/leds/leds-pwm.yaml index 7de6da58be3c..113b7c218303 100644 --- a/Documentation/devicetree/bindings/leds/leds-pwm.yaml +++ b/Documentation/devicetree/bindings/leds/leds-pwm.yaml @@ -34,11 +34,6 @@ patternProperties: Maximum brightness possible for the LED $ref: /schemas/types.yaml#/definitions/uint32 - active-low: - description: - For PWMs where the LED is wired to supply rather than ground. - type: boolean - required: - pwms - max-brightness -- cgit v1.2.3 From 355c6dc37efa7fe6a64d155254cec8e180e5e6cb Mon Sep 17 00:00:00 2001 From: Christian Marangi Date: Thu, 25 Jan 2024 21:36:58 +0100 Subject: dt-bindings: net: phy: Document LED inactive high impedance mode Document LED inactive high impedance mode to set the LED to require high impedance configuration to be turned OFF. Signed-off-by: Christian Marangi Reviewed-by: Andrew Lunn Acked-by: Lee Jones Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20240125203702.4552-3-ansuelsmth@gmail.com Signed-off-by: Jakub Kicinski --- Documentation/devicetree/bindings/leds/common.yaml | 6 ++++++ 1 file changed, 6 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/leds/common.yaml b/Documentation/devicetree/bindings/leds/common.yaml index 5633e0aa6bdf..8a3c2398b10c 100644 --- a/Documentation/devicetree/bindings/leds/common.yaml +++ b/Documentation/devicetree/bindings/leds/common.yaml @@ -206,6 +206,12 @@ properties: Makes LED active low. To turn the LED ON, line needs to be set to low voltage instead of high. + inactive-high-impedance: + type: boolean + description: + Set LED to high-impedance mode to turn the LED OFF. LED might also + describe this mode as tristate. + # Required properties for flash LED child nodes: flash-max-microamp: description: -- cgit v1.2.3 From 91e893b43d1c8e8b6f4ba0737b597091423024f3 Mon Sep 17 00:00:00 2001 From: Christian Marangi Date: Thu, 25 Jan 2024 21:37:00 +0100 Subject: dt-bindings: net: Document QCA808x PHYs Add Documentation for QCA808x PHYs for the additional LED configuration for this PHY. Signed-off-by: Christian Marangi Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20240125203702.4552-5-ansuelsmth@gmail.com Signed-off-by: Jakub Kicinski --- .../devicetree/bindings/net/qca,qca808x.yaml | 54 ++++++++++++++++++++++ 1 file changed, 54 insertions(+) create mode 100644 Documentation/devicetree/bindings/net/qca,qca808x.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/qca,qca808x.yaml b/Documentation/devicetree/bindings/net/qca,qca808x.yaml new file mode 100644 index 000000000000..e2552655902a --- /dev/null +++ b/Documentation/devicetree/bindings/net/qca,qca808x.yaml @@ -0,0 +1,54 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/qca,qca808x.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Atheros QCA808X PHY + +maintainers: + - Christian Marangi + +description: + QCA808X PHYs can have up to 3 LEDs attached. + All 3 LEDs are disabled by default. + 2 LEDs have dedicated pins with the 3rd LED having the + double function of Interrupt LEDs/GPIO or additional LED. + + By default this special PIN is set to LED function. + +allOf: + - $ref: ethernet-phy.yaml# + +properties: + compatible: + enum: + - ethernet-phy-id004d.d101 + +unevaluatedProperties: false + +examples: + - | + #include + + mdio { + #address-cells = <1>; + #size-cells = <0>; + + ethernet-phy@0 { + compatible = "ethernet-phy-id004d.d101"; + reg = <0>; + + leds { + #address-cells = <1>; + #size-cells = <0>; + + led@0 { + reg = <0>; + color = ; + function = LED_FUNCTION_WAN; + default-state = "keep"; + }; + }; + }; + }; -- cgit v1.2.3 From 6f83b62283edc295be1cfa18dd49d4f278575118 Mon Sep 17 00:00:00 2001 From: William Tu Date: Wed, 24 Jan 2024 20:00:41 -0800 Subject: Documentation: mlx5.rst: Add note for eswitch MD Add a note when using esw_port_metadata. The parameter has runtime mode but setting it does not take effect immediately. Setting it must happen in legacy mode, and the port metadata takes effects when the switchdev mode is enabled. Disable eswitch port metadata:: $ devlink dev param set pci/0000:06:00.0 name esw_port_metadata value \ false cmode runtime Change eswitch mode to switchdev mode where after choosing the metadata value:: $ devlink dev eswitch set pci/0000:06:00.0 mode switchdev Note that other mlx5 devlink runtime parameters, esw_multiport and flow_steering_mode, do not have this limitation. Signed-off-by: William Tu Reviewed-by: Jiri Pirko Signed-off-by: David S. Miller --- Documentation/networking/devlink/mlx5.rst | 4 ++++ 1 file changed, 4 insertions(+) (limited to 'Documentation') diff --git a/Documentation/networking/devlink/mlx5.rst b/Documentation/networking/devlink/mlx5.rst index 702f204a3dbd..b9587b3400b9 100644 --- a/Documentation/networking/devlink/mlx5.rst +++ b/Documentation/networking/devlink/mlx5.rst @@ -97,6 +97,10 @@ parameters. When metadata is disabled, the above use cases will fail to initialize if users try to enable them. + + Note: Setting this parameter does not take effect immediately. Setting + must happen in legacy mode and eswitch port metadata takes effect after + enabling switchdev mode. * - ``hairpin_num_queues`` - u32 - driverinit -- cgit v1.2.3 From 507cad6e0f0ea64d33f9d7902520d7c72fc8c0ca Mon Sep 17 00:00:00 2001 From: Neil Armstrong Date: Thu, 25 Jan 2024 09:13:34 +0100 Subject: dt-bindings: arm: qcom: Document the HDK8550 board Document the Qualcomm SM8550 based HDK (Hardware Development Kit) embedded development platform designed by Qualcomm and sold by Lantronix. [1] https://www.lantronix.com/products/snapdragon-8-gen-2-mobile-hardware-development-kit/ Reviewed-by: Krzysztof Kozlowski Signed-off-by: Neil Armstrong Link: https://lore.kernel.org/r/20240125-topic-sm8550-upstream-hdk8550-v3-1-73bb5ef11cf8@linaro.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 1a5fb889a444..c1720dd960c1 100644 --- a/Documentation/devicetree/bindings/arm/qcom.yaml +++ b/Documentation/devicetree/bindings/arm/qcom.yaml @@ -1035,6 +1035,7 @@ properties: - items: - enum: + - qcom,sm8550-hdk - qcom,sm8550-mtp - qcom,sm8550-qrd - const: qcom,sm8550 -- cgit v1.2.3 From 8796fa0f9a08359bb87e859d6010350a9d7da38f Mon Sep 17 00:00:00 2001 From: Rob Herring Date: Wed, 24 Jan 2024 13:07:44 -0600 Subject: dt-bindings: soc/qcom: Add size constraints on "qcom,rpm-msg-ram" The 'phandle-array' type is a bit ambiguous. It can be either just an array of phandles or an array of phandles plus args. "qcom,rpm-msg-ram" is the former and needs to constrain each entry to a single phandle value. Signed-off-by: Rob Herring Reviewed-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20240124190744.1554625-1-robh@kernel.org Signed-off-by: Bjorn Andersson --- Documentation/devicetree/bindings/soc/qcom/qcom,rpm-master-stats.yaml | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,rpm-master-stats.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,rpm-master-stats.yaml index 031800985b5e..9410404f87f1 100644 --- a/Documentation/devicetree/bindings/soc/qcom/qcom,rpm-master-stats.yaml +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,rpm-master-stats.yaml @@ -35,6 +35,8 @@ properties: description: Phandle to an RPM MSG RAM slice containing the master stats minItems: 1 maxItems: 5 + items: + maxItems: 1 qcom,master-names: $ref: /schemas/types.yaml#/definitions/string-array -- cgit v1.2.3 From 80daa2fa2ff2ce01550713956a6f7e18bbbd3f7f Mon Sep 17 00:00:00 2001 From: Raymond Hackley Date: Sat, 20 Jan 2024 09:57:38 +0000 Subject: dt-bindings: qcom: Document new msm8916-samsung devices Document the new following device tree bindings used in their device trees: - samsung,fortuna3g - samsung,gprimeltecan - samsung,grandprimelte - samsung,rossa Signed-off-by: Raymond Hackley Acked-by: Rob Herring Link: https://lore.kernel.org/r/20240120095715.13689-2-raymondhackley@protonmail.com Signed-off-by: Bjorn Andersson --- Documentation/devicetree/bindings/arm/qcom.yaml | 4 ++++ 1 file changed, 4 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml index c1720dd960c1..097c91c0b32f 100644 --- a/Documentation/devicetree/bindings/arm/qcom.yaml +++ b/Documentation/devicetree/bindings/arm/qcom.yaml @@ -244,11 +244,15 @@ properties: - samsung,a5u-eur - samsung,e5 - samsung,e7 + - samsung,fortuna3g + - samsung,gprimeltecan - samsung,grandmax + - samsung,grandprimelte - samsung,gt510 - samsung,gt58 - samsung,j5 - samsung,j5x + - samsung,rossa - samsung,serranove - thwc,uf896 - thwc,ufi001c -- cgit v1.2.3 From 47eed1127d2af6fada49565efca4671a56e5839d Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Tue, 23 Jan 2024 09:35:11 +0100 Subject: dt-bindings: pinctrl: amlogic: narrow regex for unit address to hex numbers Regular expression used to match the unit address part should not allow non-hex numbers. Signed-off-by: Krzysztof Kozlowski Reviewed-by: Neil Armstrong Link: https://lore.kernel.org/r/20240123083511.21063-1-krzysztof.kozlowski@linaro.org Signed-off-by: Linus Walleij --- Documentation/devicetree/bindings/pinctrl/amlogic,meson-pinctrl-a1.yaml | 2 +- .../devicetree/bindings/pinctrl/amlogic,meson-pinctrl-g12a-aobus.yaml | 2 +- .../devicetree/bindings/pinctrl/amlogic,meson-pinctrl-g12a-periphs.yaml | 2 +- .../devicetree/bindings/pinctrl/amlogic,meson8-pinctrl-aobus.yaml | 2 +- .../devicetree/bindings/pinctrl/amlogic,meson8-pinctrl-cbus.yaml | 2 +- 5 files changed, 5 insertions(+), 5 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pinctrl/amlogic,meson-pinctrl-a1.yaml b/Documentation/devicetree/bindings/pinctrl/amlogic,meson-pinctrl-a1.yaml index c7df4cd34197..d9e0b2c48e84 100644 --- a/Documentation/devicetree/bindings/pinctrl/amlogic,meson-pinctrl-a1.yaml +++ b/Documentation/devicetree/bindings/pinctrl/amlogic,meson-pinctrl-a1.yaml @@ -24,7 +24,7 @@ required: - compatible patternProperties: - "^bank@[0-9a-z]+$": + "^bank@[0-9a-f]+$": $ref: amlogic,meson-pinctrl-common.yaml#/$defs/meson-gpio unevaluatedProperties: false diff --git a/Documentation/devicetree/bindings/pinctrl/amlogic,meson-pinctrl-g12a-aobus.yaml b/Documentation/devicetree/bindings/pinctrl/amlogic,meson-pinctrl-g12a-aobus.yaml index 0942ea60c6cd..108719bde0d0 100644 --- a/Documentation/devicetree/bindings/pinctrl/amlogic,meson-pinctrl-g12a-aobus.yaml +++ b/Documentation/devicetree/bindings/pinctrl/amlogic,meson-pinctrl-g12a-aobus.yaml @@ -21,7 +21,7 @@ required: - compatible patternProperties: - "^bank@[0-9a-z]+$": + "^bank@[0-9a-f]+$": $ref: amlogic,meson-pinctrl-common.yaml#/$defs/meson-gpio unevaluatedProperties: false diff --git a/Documentation/devicetree/bindings/pinctrl/amlogic,meson-pinctrl-g12a-periphs.yaml b/Documentation/devicetree/bindings/pinctrl/amlogic,meson-pinctrl-g12a-periphs.yaml index e3c8bde30559..dc277f2e2edf 100644 --- a/Documentation/devicetree/bindings/pinctrl/amlogic,meson-pinctrl-g12a-periphs.yaml +++ b/Documentation/devicetree/bindings/pinctrl/amlogic,meson-pinctrl-g12a-periphs.yaml @@ -21,7 +21,7 @@ required: - compatible patternProperties: - "^bank@[0-9a-z]+$": + "^bank@[0-9a-f]+$": $ref: amlogic,meson-pinctrl-common.yaml#/$defs/meson-gpio unevaluatedProperties: false diff --git a/Documentation/devicetree/bindings/pinctrl/amlogic,meson8-pinctrl-aobus.yaml b/Documentation/devicetree/bindings/pinctrl/amlogic,meson8-pinctrl-aobus.yaml index c1b03147e8ec..add83c676327 100644 --- a/Documentation/devicetree/bindings/pinctrl/amlogic,meson8-pinctrl-aobus.yaml +++ b/Documentation/devicetree/bindings/pinctrl/amlogic,meson8-pinctrl-aobus.yaml @@ -29,7 +29,7 @@ required: - compatible patternProperties: - "^bank@[0-9a-z]+$": + "^bank@[0-9a-f]+$": $ref: amlogic,meson-pinctrl-common.yaml#/$defs/meson-gpio unevaluatedProperties: false diff --git a/Documentation/devicetree/bindings/pinctrl/amlogic,meson8-pinctrl-cbus.yaml b/Documentation/devicetree/bindings/pinctrl/amlogic,meson8-pinctrl-cbus.yaml index 4ec85b8248fa..412bbcc276f3 100644 --- a/Documentation/devicetree/bindings/pinctrl/amlogic,meson8-pinctrl-cbus.yaml +++ b/Documentation/devicetree/bindings/pinctrl/amlogic,meson8-pinctrl-cbus.yaml @@ -29,7 +29,7 @@ required: - compatible patternProperties: - "^bank@[0-9a-z]+$": + "^bank@[0-9a-f]+$": $ref: amlogic,meson-pinctrl-common.yaml#/$defs/meson-gpio unevaluatedProperties: false -- cgit v1.2.3 From cde644ae1967d4fcb0fb27b47709654fd24208ae Mon Sep 17 00:00:00 2001 From: AngeloGioacchino Del Regno Date: Mon, 22 Jan 2024 12:04:45 +0100 Subject: dt-bindings: usb: Introduce ITE IT5205 Alt. Mode Passive MUX Introduce a binding for the ITE IT5205 Alternate Mode Passive MUX, used for connecting, disconnecting and switching orientation and control the SBU signals for alternate modes on USB Type-C ports. Signed-off-by: AngeloGioacchino Del Regno Reviewed-by: Conor Dooley Link: https://lore.kernel.org/r/20240122110446.140226-2-angelogioacchino.delregno@collabora.com Signed-off-by: Greg Kroah-Hartman --- .../devicetree/bindings/usb/ite,it5205.yaml | 72 ++++++++++++++++++++++ 1 file changed, 72 insertions(+) create mode 100644 Documentation/devicetree/bindings/usb/ite,it5205.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/usb/ite,it5205.yaml b/Documentation/devicetree/bindings/usb/ite,it5205.yaml new file mode 100644 index 000000000000..36ec4251b5f2 --- /dev/null +++ b/Documentation/devicetree/bindings/usb/ite,it5205.yaml @@ -0,0 +1,72 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/usb/ite,it5205.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: ITE IT5202 Type-C USB Alternate Mode Passive MUX + +maintainers: + - AngeloGioacchino Del Regno + - Tianping Fang + +properties: + compatible: + const: ite,it5205 + + reg: + maxItems: 1 + + vcc-supply: + description: Power supply for VCC pin (3.3V) + + mode-switch: + description: Flag the port as possible handle of altmode switching + type: boolean + + orientation-switch: + description: Flag the port as possible handler of orientation switching + type: boolean + + ite,ovp-enable: + description: Enable Over Voltage Protection functionality + type: boolean + + port: + $ref: /schemas/graph.yaml#/properties/port + description: + A port node to link the IT5205 to a TypeC controller for the purpose of + handling altmode muxing and orientation switching. + +required: + - compatible + - reg + - orientation-switch + - port + +additionalProperties: false + +examples: + - | + #include + i2c2 { + #address-cells = <1>; + #size-cells = <0>; + + typec-mux@48 { + compatible = "ite,it5205"; + reg = <0x48>; + + mode-switch; + orientation-switch; + + vcc-supply = <&mt6359_vibr_ldo_reg>; + + port { + it5205_usbss_sbu: endpoint { + remote-endpoint = <&typec_controller>; + }; + }; + }; + }; +... -- cgit v1.2.3 From 2fa5c7e53112a5ffef385c587d7d5de96d0b2d08 Mon Sep 17 00:00:00 2001 From: Elad Nachman Date: Sun, 14 Jan 2024 19:21:53 +0200 Subject: dt-bindings: usb: Add Marvell ac5 Add Marvell ac5 device tree bindings to generic EHCI. This compatible enables the Marvell Orion platform code to properly configure the DMA mask for the Marvell AC5 SOC. Signed-off-by: Elad Nachman Acked-by: Conor Dooley Link: https://lore.kernel.org/r/20240114172154.2622275-2-enachman@marvell.com 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 87986c45be88..2ed178f16a78 100644 --- a/Documentation/devicetree/bindings/usb/generic-ehci.yaml +++ b/Documentation/devicetree/bindings/usb/generic-ehci.yaml @@ -77,6 +77,7 @@ properties: - const: usb-ehci - enum: - generic-ehci + - marvell,ac5-ehci - marvell,armada-3700-ehci - marvell,orion-ehci - nuvoton,npcm750-ehci -- cgit v1.2.3 From fd2a052ccd69f3780b96291cacc21089e198d02c Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Mon, 22 Jan 2024 10:44:06 +0100 Subject: dt-bindings: usb: add common Type-C USB Switch schema Several bindings implement parts of Type-C USB orientation and mode switching, and retiming. Keep definition of such properties in one place, new usb-switch schema, to avoid duplicate defines. Signed-off-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20240122094406.32198-1-krzysztof.kozlowski@linaro.org Signed-off-by: Greg Kroah-Hartman --- .../devicetree/bindings/usb/fcs,fsa4480.yaml | 12 ++-- .../devicetree/bindings/usb/gpio-sbu-mux.yaml | 12 ++-- .../devicetree/bindings/usb/nxp,ptn36502.yaml | 12 ++-- .../devicetree/bindings/usb/onnn,nb7vpq904m.yaml | 13 ++--- .../bindings/usb/qcom,wcd939x-usbss.yaml | 12 ++-- .../devicetree/bindings/usb/usb-switch.yaml | 67 ++++++++++++++++++++++ 6 files changed, 92 insertions(+), 36 deletions(-) create mode 100644 Documentation/devicetree/bindings/usb/usb-switch.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/usb/fcs,fsa4480.yaml b/Documentation/devicetree/bindings/usb/fcs,fsa4480.yaml index f9410eb76a62..8b25b9a01ced 100644 --- a/Documentation/devicetree/bindings/usb/fcs,fsa4480.yaml +++ b/Documentation/devicetree/bindings/usb/fcs,fsa4480.yaml @@ -27,13 +27,8 @@ properties: vcc-supply: description: power supply (2.7V-5.5V) - mode-switch: - description: Flag the port as possible handle of altmode switching - type: boolean - - orientation-switch: - description: Flag the port as possible handler of orientation switching - type: boolean + mode-switch: true + orientation-switch: true port: $ref: /schemas/graph.yaml#/$defs/port-base @@ -79,6 +74,9 @@ required: - reg - port +allOf: + - $ref: usb-switch.yaml# + additionalProperties: false examples: diff --git a/Documentation/devicetree/bindings/usb/gpio-sbu-mux.yaml b/Documentation/devicetree/bindings/usb/gpio-sbu-mux.yaml index d3b2b666ec2a..88e1607cf053 100644 --- a/Documentation/devicetree/bindings/usb/gpio-sbu-mux.yaml +++ b/Documentation/devicetree/bindings/usb/gpio-sbu-mux.yaml @@ -33,13 +33,8 @@ properties: vcc-supply: description: power supply - mode-switch: - description: Flag the port as possible handle of altmode switching - type: boolean - - orientation-switch: - description: Flag the port as possible handler of orientation switching - type: boolean + mode-switch: true + orientation-switch: true port: $ref: /schemas/graph.yaml#/properties/port @@ -54,6 +49,9 @@ required: - orientation-switch - port +allOf: + - $ref: usb-switch.yaml# + additionalProperties: false examples: diff --git a/Documentation/devicetree/bindings/usb/nxp,ptn36502.yaml b/Documentation/devicetree/bindings/usb/nxp,ptn36502.yaml index eee548ac1abe..d805dde80796 100644 --- a/Documentation/devicetree/bindings/usb/nxp,ptn36502.yaml +++ b/Documentation/devicetree/bindings/usb/nxp,ptn36502.yaml @@ -20,13 +20,8 @@ properties: vdd18-supply: description: Power supply for VDD18 pin - retimer-switch: - description: Flag the port as possible handle of SuperSpeed signals retiming - type: boolean - - orientation-switch: - description: Flag the port as possible handler of orientation switching - type: boolean + orientation-switch: true + retimer-switch: true ports: $ref: /schemas/graph.yaml#/properties/ports @@ -49,6 +44,9 @@ required: - compatible - reg +allOf: + - $ref: usb-switch.yaml# + additionalProperties: false examples: diff --git a/Documentation/devicetree/bindings/usb/onnn,nb7vpq904m.yaml b/Documentation/devicetree/bindings/usb/onnn,nb7vpq904m.yaml index c0201da002f6..589914d22bf2 100644 --- a/Documentation/devicetree/bindings/usb/onnn,nb7vpq904m.yaml +++ b/Documentation/devicetree/bindings/usb/onnn,nb7vpq904m.yaml @@ -21,14 +21,8 @@ properties: description: power supply (1.8V) enable-gpios: true - - retimer-switch: - description: Flag the port as possible handle of SuperSpeed signals retiming - type: boolean - - orientation-switch: - description: Flag the port as possible handler of orientation switching - type: boolean + orientation-switch: true + retimer-switch: true ports: $ref: /schemas/graph.yaml#/properties/ports @@ -95,6 +89,9 @@ required: - compatible - reg +allOf: + - $ref: usb-switch.yaml# + additionalProperties: false examples: diff --git a/Documentation/devicetree/bindings/usb/qcom,wcd939x-usbss.yaml b/Documentation/devicetree/bindings/usb/qcom,wcd939x-usbss.yaml index 7ddfd3313a18..96346723f3e9 100644 --- a/Documentation/devicetree/bindings/usb/qcom,wcd939x-usbss.yaml +++ b/Documentation/devicetree/bindings/usb/qcom,wcd939x-usbss.yaml @@ -35,13 +35,8 @@ properties: vdd-supply: description: USBSS VDD power supply - mode-switch: - description: Flag the port as possible handle of altmode switching - type: boolean - - orientation-switch: - description: Flag the port as possible handler of orientation switching - type: boolean + mode-switch: true + orientation-switch: true ports: $ref: /schemas/graph.yaml#/properties/ports @@ -63,6 +58,9 @@ required: - reg - ports +allOf: + - $ref: usb-switch.yaml# + additionalProperties: false examples: diff --git a/Documentation/devicetree/bindings/usb/usb-switch.yaml b/Documentation/devicetree/bindings/usb/usb-switch.yaml new file mode 100644 index 000000000000..da76118e73a5 --- /dev/null +++ b/Documentation/devicetree/bindings/usb/usb-switch.yaml @@ -0,0 +1,67 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/usb/usb-switch.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: USB Orientation and Mode Switches Common Properties + +maintainers: + - Greg Kroah-Hartman + +description: + Common properties for devices handling USB mode and orientation switching. + +properties: + mode-switch: + description: Possible handler of altmode switching + type: boolean + + orientation-switch: + description: Possible handler of orientation switching + type: boolean + + retimer-switch: + description: Possible handler of SuperSpeed signals retiming + type: boolean + + port: + $ref: /schemas/graph.yaml#/properties/port + description: + A port node to link the device to a TypeC controller for the purpose of + handling altmode muxing and orientation switching. + + ports: + $ref: /schemas/graph.yaml#/properties/ports + properties: + port@0: + $ref: /schemas/graph.yaml#/properties/port + description: + Super Speed (SS) Output endpoint to the Type-C connector + + port@1: + $ref: /schemas/graph.yaml#/$defs/port-base + description: + Super Speed (SS) Input endpoint from the Super-Speed PHY + unevaluatedProperties: false + + properties: + endpoint: + $ref: /schemas/graph.yaml#/$defs/endpoint-base + unevaluatedProperties: false + properties: + data-lanes: + $ref: /schemas/types.yaml#/definitions/uint32-array + minItems: 1 + maxItems: 8 + uniqueItems: true + items: + maximum: 8 + +oneOf: + - required: + - port + - required: + - ports + +additionalProperties: true -- cgit v1.2.3 From 665029ecd1e0e21718d284c4024add683c05e9f8 Mon Sep 17 00:00:00 2001 From: Rob Herring Date: Wed, 24 Jan 2024 13:07:24 -0600 Subject: dt-bindings: usb: Clean-up "usb-phy" constraints "usb-phy" has multiple type definitions. Unify the type with the looser definition, phandle-array, as there are cases with multiple entries (USB2 and USB3). However, the 'phandle-array' type alone is a bit ambiguous. It can be either just an array of phandles or an array of phandles plus args. "usb-phy" is the former and needs to constrain each entry to a single phandle value. Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20240124190725.1554080-1-robh@kernel.org Signed-off-by: Greg Kroah-Hartman --- Documentation/devicetree/bindings/usb/ci-hdrc-usb2.yaml | 2 +- Documentation/devicetree/bindings/usb/usb.yaml | 2 ++ 2 files changed, 3 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.yaml b/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.yaml index b7e664f7395b..3b56e0edb1c6 100644 --- a/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.yaml +++ b/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.yaml @@ -313,7 +313,7 @@ properties: usb-phy: description: phandle for the PHY device. Use "phys" instead. - $ref: /schemas/types.yaml#/definitions/phandle + maxItems: 1 deprecated: true fsl,usbphy: diff --git a/Documentation/devicetree/bindings/usb/usb.yaml b/Documentation/devicetree/bindings/usb/usb.yaml index 326b14f05d1c..1761b7aa92f0 100644 --- a/Documentation/devicetree/bindings/usb/usb.yaml +++ b/Documentation/devicetree/bindings/usb/usb.yaml @@ -25,6 +25,8 @@ properties: usb-phy: $ref: /schemas/types.yaml#/definitions/phandle-array + items: + maxItems: 1 description: List of all the USB PHYs on this HCD to be accepted by the legacy USB Physical Layer subsystem. -- cgit v1.2.3 From f99044cd1451d13f2d812ede24eb186ea6335a07 Mon Sep 17 00:00:00 2001 From: AngeloGioacchino Del Regno Date: Mon, 22 Jan 2024 12:18:08 +0100 Subject: dt-bindings: usb: mtu3: Add MT8195 MTU3 ip-sleep support Of the four USB controllers present on the MediaTek MT8195 SoC, three of them (0, 2 and 3) are behind MTU3: add wakeup controls for them. Acked-by: Conor Dooley Reviewed-by: Matthias Brugger Signed-off-by: AngeloGioacchino Del Regno Link: https://lore.kernel.org/r/20240122111809.148546-1-angelogioacchino.delregno@collabora.com Signed-off-by: Greg Kroah-Hartman --- Documentation/devicetree/bindings/usb/mediatek,mtu3.yaml | 5 ++++- 1 file changed, 4 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 a59d91243ac8..d4e187c78a0b 100644 --- a/Documentation/devicetree/bindings/usb/mediatek,mtu3.yaml +++ b/Documentation/devicetree/bindings/usb/mediatek,mtu3.yaml @@ -185,7 +185,10 @@ properties: 2 - used by mt2712 etc, revision 2 with following IPM rule; 101 - used by mt8183, specific 1.01; 102 - used by mt8192, specific 1.02; - enum: [1, 2, 101, 102] + 103 - used by mt8195, IP0, specific 1.03; + 105 - used by mt8195, IP2, specific 1.05; + 106 - used by mt8195, IP3, specific 1.06; + enum: [1, 2, 101, 102, 103, 105, 106] mediatek,u3p-dis-msk: $ref: /schemas/types.yaml#/definitions/uint32 -- cgit v1.2.3 From c281d8a5a58a8c2dca797132ff48033d50fde742 Mon Sep 17 00:00:00 2001 From: Sean Anderson Date: Tue, 23 Jan 2024 17:51:08 -0500 Subject: dt-bindings: usb: usb-nop-xceiv: Repurpose vbus-regulator The vbus-regulator property was never actually read from the device tree. Introduce a new property vbus-supply to represent the regulator powering the VBUS when acting as an A-Device. This supply will be enabled and disabled as necessary. Note that this is different from vbus-regulator, which represented the available current available to draw from VBUS in B-Device mode. Because no one was using vbus-regulator, remove it. Signed-off-by: Sean Anderson Reviewed-by: Linus Walleij Link: https://lore.kernel.org/r/20240123225111.1629405-2-sean.anderson@seco.com Signed-off-by: Greg Kroah-Hartman --- Documentation/devicetree/bindings/usb/usb-nop-xceiv.yaml | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/usb/usb-nop-xceiv.yaml b/Documentation/devicetree/bindings/usb/usb-nop-xceiv.yaml index 6734f4d3aa78..9b3ea23654af 100644 --- a/Documentation/devicetree/bindings/usb/usb-nop-xceiv.yaml +++ b/Documentation/devicetree/bindings/usb/usb-nop-xceiv.yaml @@ -37,10 +37,11 @@ properties: description: Should specify the GPIO detecting a VBus insertion maxItems: 1 - vbus-regulator: - description: Should specify the regulator supplying current drawn from - the VBus line. - $ref: /schemas/types.yaml#/definitions/phandle + vbus-supply: + description: regulator supplying VBUS. It will be enabled and disabled + dynamically in OTG mode. If the regulator is controlled by a + GPIO line, this should be modeled as a regulator-fixed and + referenced by this supply. wakeup-source: description: @@ -65,7 +66,7 @@ examples: vcc-supply = <&hsusb1_vcc_regulator>; reset-gpios = <&gpio1 7 GPIO_ACTIVE_LOW>; vbus-detect-gpio = <&gpio2 13 GPIO_ACTIVE_HIGH>; - vbus-regulator = <&vbus_regulator>; + vbus-supply = <&vbus_regulator>; #phy-cells = <0>; }; -- cgit v1.2.3 From bc83a87759cabbf6f3366568e44bda088b315204 Mon Sep 17 00:00:00 2001 From: Ran Wang Date: Wed, 24 Jan 2024 10:25:24 -0500 Subject: dt-bindings: usb: dwc3: Add snps,host-vbus-glitches-quirk avoid vbus glitch When DWC3 is set to host mode by programming register DWC3_GCTL, VBUS (or its control signal) will turn on immediately on related Root Hub ports. Then the VBUS will be de-asserted for a little while during xhci reset (conducted by xhci driver) for a little while and back to normal. This VBUS glitch might cause some USB devices emuration fail if kernel boot with them connected. One SW workaround which can fix this is to program all PORTSC[PP] to 0 to turn off VBUS immediately after setting host mode in DWC3 driver(per signal measurement result, it will be too late to do it in xhci-plat.c or xhci.c). Signed-off-by: Ran Wang Reviewed-by: Peter Chen Signed-off-by: Frank Li Link: https://lore.kernel.org/r/20240124152525.3910311-3-Frank.Li@nxp.com Signed-off-by: Greg Kroah-Hartman --- Documentation/devicetree/bindings/usb/snps,dwc3.yaml | 7 +++++++ 1 file changed, 7 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/usb/snps,dwc3.yaml b/Documentation/devicetree/bindings/usb/snps,dwc3.yaml index 203a1eb66691..8f5d250070c7 100644 --- a/Documentation/devicetree/bindings/usb/snps,dwc3.yaml +++ b/Documentation/devicetree/bindings/usb/snps,dwc3.yaml @@ -273,6 +273,13 @@ properties: with an external supply. type: boolean + snps,host-vbus-glitches-quirk: + description: + When set, power off all Root Hub ports immediately after + setting host mode to avoid vbus (negative) glitch happen in later + xhci reset. And the vbus will back to 5V automatically when reset done. + type: boolean + snps,is-utmi-l1-suspend: description: True when DWC3 asserts output signal utmi_l1_suspend_n, false when -- cgit v1.2.3 From 43a029724d1c8219cc4e58e9fafbeedd1bc283fa Mon Sep 17 00:00:00 2001 From: Peter Korsgaard Date: Fri, 26 Jan 2024 21:32:08 +0100 Subject: usb: gadget: f_fs: expose ready state in configfs When a USB gadget is configured through configfs with 1 or more f_fs functions, then the logic setting up the gadget configuration has to wait until the user space code (typically separate applications) responsible for those functions have written their descriptors before the gadget can be activated. The f_fs instance already knows if this has been done, so expose it through a "ready" attribute in configfs for easier synchronization. Signed-off-by: Peter Korsgaard Link: https://lore.kernel.org/r/20240126203208.2482573-1-peter@korsgaard.com Signed-off-by: Greg Kroah-Hartman --- Documentation/ABI/testing/configfs-usb-gadget-ffs | 12 ++++++++++-- Documentation/usb/gadget-testing.rst | 8 ++++++++ drivers/usb/gadget/function/f_fs.c | 20 ++++++++++++++++++++ 3 files changed, 38 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/configfs-usb-gadget-ffs b/Documentation/ABI/testing/configfs-usb-gadget-ffs index e39b27653c65..bf8936ff6d38 100644 --- a/Documentation/ABI/testing/configfs-usb-gadget-ffs +++ b/Documentation/ABI/testing/configfs-usb-gadget-ffs @@ -4,6 +4,14 @@ KernelVersion: 3.13 Description: The purpose of this directory is to create and remove it. A corresponding USB function instance is created/removed. - There are no attributes here. - All parameters are set through FunctionFS. + All attributes are read only: + + ============= ============================================ + ready 1 if the function is ready to be used, E.G. + if userspace has written descriptors and + strings to ep0, so the gadget can be + enabled - 0 otherwise. + ============= ============================================ + + All other parameters are set through FunctionFS. diff --git a/Documentation/usb/gadget-testing.rst b/Documentation/usb/gadget-testing.rst index 8cd62c466d20..4ec6b775ebba 100644 --- a/Documentation/usb/gadget-testing.rst +++ b/Documentation/usb/gadget-testing.rst @@ -206,6 +206,14 @@ the standard procedure for using FunctionFS (mount it, run the userspace process which implements the function proper). The gadget should be enabled by writing a suitable string to usb_gadget//UDC. +The FFS function provides just one attribute in its function directory: + + ready + +The attribute is read-only and signals if the function is ready (1) to be +used, E.G. if userspace has written descriptors and strings to ep0, so +the gadget can be enabled. + Testing the FFS function ------------------------ diff --git a/drivers/usb/gadget/function/f_fs.c b/drivers/usb/gadget/function/f_fs.c index 6bff6cb93789..be3851cffb73 100644 --- a/drivers/usb/gadget/function/f_fs.c +++ b/drivers/usb/gadget/function/f_fs.c @@ -3445,6 +3445,25 @@ static inline struct f_fs_opts *to_ffs_opts(struct config_item *item) func_inst.group); } +static ssize_t f_fs_opts_ready_show(struct config_item *item, char *page) +{ + struct f_fs_opts *opts = to_ffs_opts(item); + int ready; + + ffs_dev_lock(); + ready = opts->dev->desc_ready; + ffs_dev_unlock(); + + return sprintf(page, "%d\n", ready); +} + +CONFIGFS_ATTR_RO(f_fs_opts_, ready); + +static struct configfs_attribute *ffs_attrs[] = { + &f_fs_opts_attr_ready, + NULL, +}; + static void ffs_attr_release(struct config_item *item) { struct f_fs_opts *opts = to_ffs_opts(item); @@ -3458,6 +3477,7 @@ static struct configfs_item_operations ffs_item_ops = { static const struct config_item_type ffs_func_type = { .ct_item_ops = &ffs_item_ops, + .ct_attrs = ffs_attrs, .ct_owner = THIS_MODULE, }; -- cgit v1.2.3 From cf066f9334b9632ca1a8185118083a9218504e0a Mon Sep 17 00:00:00 2001 From: "Jiri Slaby (SUSE)" Date: Mon, 22 Jan 2024 12:04:01 +0100 Subject: Documentation: add console.rst Now, that the console kernel-doc is in better shape, include it in the tty/ docs. It's not supernice, but it is what it is. At least for the beginning. Signed-off-by: "Jiri Slaby (SUSE)" Cc: Jonathan Corbet Cc: linux-doc@vger.kernel.org Tested-by: Helge Deller # parisc STI console Link: https://lore.kernel.org/r/20240122110401.7289-48-jirislaby@kernel.org Signed-off-by: Greg Kroah-Hartman --- Documentation/driver-api/tty/console.rst | 45 ++++++++++++++++++++++++++++++++ Documentation/driver-api/tty/index.rst | 1 + 2 files changed, 46 insertions(+) create mode 100644 Documentation/driver-api/tty/console.rst (limited to 'Documentation') diff --git a/Documentation/driver-api/tty/console.rst b/Documentation/driver-api/tty/console.rst new file mode 100644 index 000000000000..4348e36cd33b --- /dev/null +++ b/Documentation/driver-api/tty/console.rst @@ -0,0 +1,45 @@ +.. SPDX-License-Identifier: GPL-2.0 + +======= +Console +======= + +.. contents:: :local: + +Struct Console +============== + +.. kernel-doc:: include/linux/console.h + :identifiers: console cons_flags + +Internals +--------- + +.. kernel-doc:: include/linux/console.h + :identifiers: nbcon_state nbcon_prio nbcon_context nbcon_write_context + +Struct Consw +============ + +.. kernel-doc:: include/linux/console.h + :identifiers: consw + +Console functions +================= + +.. kernel-doc:: include/linux/console.h + :identifiers: console_srcu_read_flags console_srcu_write_flags + console_is_registered for_each_console_srcu for_each_console + +.. kernel-doc:: drivers/tty/vt/selection.c + :export: +.. kernel-doc:: drivers/tty/vt/vt.c + :export: + +Internals +--------- + +.. kernel-doc:: drivers/tty/vt/selection.c + :internal: +.. kernel-doc:: drivers/tty/vt/vt.c + :internal: diff --git a/Documentation/driver-api/tty/index.rst b/Documentation/driver-api/tty/index.rst index b490da11f257..c1ffe3d1ec46 100644 --- a/Documentation/driver-api/tty/index.rst +++ b/Documentation/driver-api/tty/index.rst @@ -38,6 +38,7 @@ In-detail description of the named TTY structures is in separate documents: tty_buffer tty_ioctl tty_internals + console Writing TTY Driver ================== -- cgit v1.2.3 From 1d3f02abd551c69c6a82b9f22430b497b0bf7c55 Mon Sep 17 00:00:00 2001 From: Tudor Ambarus Date: Fri, 19 Jan 2024 10:45:09 +0000 Subject: dt-bindings: serial: samsung: do not allow reg-io-width for gs101 All gs101 serial ports are restricted to 32-bit register accesses. This requirement will be inferred from the compatible. Do not allow the reg-io-width property for the google,gs101-uart compatible. Suggested-by: Krzysztof Kozlowski Reviewed-by: Krzysztof Kozlowski Reviewed-by: Peter Griffin Signed-off-by: Tudor Ambarus Reviewed-by: Sam Protsenko Link: https://lore.kernel.org/r/20240119104526.1221243-3-tudor.ambarus@linaro.org Signed-off-by: Greg Kroah-Hartman --- Documentation/devicetree/bindings/serial/samsung_uart.yaml | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/serial/samsung_uart.yaml b/Documentation/devicetree/bindings/serial/samsung_uart.yaml index 133259ed3a34..0f0131026911 100644 --- a/Documentation/devicetree/bindings/serial/samsung_uart.yaml +++ b/Documentation/devicetree/bindings/serial/samsung_uart.yaml @@ -143,6 +143,8 @@ allOf: then: required: - samsung,uart-fifosize + properties: + reg-io-width: false unevaluatedProperties: false -- cgit v1.2.3 From 09aec324b60f4309eeba8d2d5c897e882cce23bc Mon Sep 17 00:00:00 2001 From: Peng Fan Date: Sun, 21 Jan 2024 19:53:01 +0800 Subject: dt-bindings: serial: fsl-lpuart: support i.MX95 Add i.MX95 compatible string. Same as i.MX93, it is compatible with i.MX8ULP. Signed-off-by: Peng Fan Acked-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20240121115301.1420502-1-peng.fan@oss.nxp.com Signed-off-by: Greg Kroah-Hartman --- Documentation/devicetree/bindings/serial/fsl-lpuart.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/serial/fsl-lpuart.yaml b/Documentation/devicetree/bindings/serial/fsl-lpuart.yaml index 3a5b59f5d3e3..3f9ace89dee9 100644 --- a/Documentation/devicetree/bindings/serial/fsl-lpuart.yaml +++ b/Documentation/devicetree/bindings/serial/fsl-lpuart.yaml @@ -30,6 +30,7 @@ properties: - items: - enum: - fsl,imx93-lpuart + - fsl,imx95-lpuart - const: fsl,imx8ulp-lpuart - const: fsl,imx7ulp-lpuart - items: -- cgit v1.2.3 From d2a2a5602cfe7fed309c81135b5ecb62556ce89b Mon Sep 17 00:00:00 2001 From: Nghia Nguyen Date: Wed, 24 Jan 2024 12:27:15 +0100 Subject: dt-bindings: serial: renesas,hscif: Document r8a779h0 bindings The R-Car V4M (R8A779H0) SoC has R-Car Gen4 compatible HSCIF ports, so document the SoC-specific bindings. Signed-off-by: Nghia Nguyen Signed-off-by: Geert Uytterhoeven Reviewed-by: Wolfram Sang Acked-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/55b458e0ba9824e1246e556075bf882032c37279.1706095578.git.geert@linux-m68k.org Signed-off-by: Greg Kroah-Hartman --- Documentation/devicetree/bindings/serial/renesas,hscif.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/serial/renesas,hscif.yaml b/Documentation/devicetree/bindings/serial/renesas,hscif.yaml index 2046e2dc0a3d..9480ed30915c 100644 --- a/Documentation/devicetree/bindings/serial/renesas,hscif.yaml +++ b/Documentation/devicetree/bindings/serial/renesas,hscif.yaml @@ -59,6 +59,7 @@ properties: - renesas,hscif-r8a779a0 # R-Car V3U - renesas,hscif-r8a779f0 # R-Car S4-8 - renesas,hscif-r8a779g0 # R-Car V4H + - renesas,hscif-r8a779h0 # R-Car V4M - const: renesas,rcar-gen4-hscif # R-Car Gen4 - const: renesas,hscif # generic HSCIF compatible UART -- cgit v1.2.3 From 32152467ffac3b79eae7313959c310946b0e6072 Mon Sep 17 00:00:00 2001 From: Manikanta Guntupalli Date: Tue, 23 Jan 2024 11:46:53 +0530 Subject: dt-bindings: Add reference to rs485.yaml Xilinx/AMD Kria SOM KD240 board has a rs485 compatible peripheral. Update the binding to have rs485 support. Acked-by: Conor Dooley Signed-off-by: Manikanta Guntupalli Link: https://lore.kernel.org/r/20240123061655.2150946-2-manikanta.guntupalli@amd.com Signed-off-by: Greg Kroah-Hartman --- Documentation/devicetree/bindings/serial/cdns,uart.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/serial/cdns,uart.yaml b/Documentation/devicetree/bindings/serial/cdns,uart.yaml index e35ad1109efc..2129247d7c81 100644 --- a/Documentation/devicetree/bindings/serial/cdns,uart.yaml +++ b/Documentation/devicetree/bindings/serial/cdns,uart.yaml @@ -55,6 +55,7 @@ required: allOf: - $ref: serial.yaml# + - $ref: rs485.yaml# - if: properties: compatible: -- cgit v1.2.3 From 7a61bbc10a7b2734fbffa4438340b6878cce2e5c Mon Sep 17 00:00:00 2001 From: Yannic Moog Date: Fri, 26 Jan 2024 09:57:23 +0100 Subject: dt-bindings: display: panel-simple: add ETML1010G3DRA Add Emerging Display Technology Corp. etml1010g3dra 10.1" LCD-TFT LVDS panel compatible string. Signed-off-by: Yannic Moog Acked-by: Conor Dooley Link: https://lore.kernel.org/r/20240126-wip-y-moog-phytec-de-upstream-pollux-lvds-v1-1-8ec5b48eec05@phytec.de Signed-off-by: Neil Armstrong Link: https://patchwork.freedesktop.org/patch/msgid/20240126-wip-y-moog-phytec-de-upstream-pollux-lvds-v1-1-8ec5b48eec05@phytec.de --- 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 2021aa82871a..365a13d74fe2 100644 --- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml +++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml @@ -141,6 +141,8 @@ properties: - edt,etm0700g0edh6 # Emerging Display Technology Corp. LVDS WSVGA TFT Display with capacitive touch - edt,etml0700y5dha + # Emerging Display Technology Corp. 10.1" LVDS WXGA TFT Display with capacitive touch + - edt,etml1010g3dra # Emerging Display Technology Corp. 5.7" VGA TFT LCD panel with # capacitive touch - edt,etmv570g2dhu -- cgit v1.2.3 From 9e1aa985d61eacd5931496b80fbd1c2d2cdeece5 Mon Sep 17 00:00:00 2001 From: Tobias Schramm Date: Thu, 25 Jan 2024 21:15:05 +0100 Subject: dt-bindings: nfc: ti,trf7970a: fix usage example The TRF7970A is a SPI device, not I2C. Signed-off-by: Tobias Schramm Reviewed-by: Krzysztof Kozlowski Signed-off-by: David S. Miller --- Documentation/devicetree/bindings/net/nfc/ti,trf7970a.yaml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/nfc/ti,trf7970a.yaml b/Documentation/devicetree/bindings/net/nfc/ti,trf7970a.yaml index 9cc236ec42f2..d0332eb76ad2 100644 --- a/Documentation/devicetree/bindings/net/nfc/ti,trf7970a.yaml +++ b/Documentation/devicetree/bindings/net/nfc/ti,trf7970a.yaml @@ -73,7 +73,7 @@ examples: #include #include - i2c { + spi { #address-cells = <1>; #size-cells = <0>; -- cgit v1.2.3 From c18327b36e9c1efb917953fc14b869c37d2884e1 Mon Sep 17 00:00:00 2001 From: Geert Uytterhoeven Date: Thu, 25 Jan 2024 15:48:51 +0100 Subject: dt-bindings: soc: renesas: Document R-Car V4H White Hawk Single Document the compatible values for the Renesas R-Car V4H ES2.0 (R8A779G2) SoC and the Renesas White Hawk Single board. The former is an updated version of R-Car V4H (R8A779G0). The latter is a single-board integration of the Renesas White Hawk CPU and Breakout board stack. Signed-off-by: Geert Uytterhoeven Reviewed-by: Wolfram Sang Acked-by: Conor Dooley Link: https://lore.kernel.org/r/a44d990c962c8e0aac3b133eaa563f8c92b2ce29.1706192990.git.geert+renesas@glider.be --- Documentation/devicetree/bindings/soc/renesas/renesas.yaml | 7 +++++++ 1 file changed, 7 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/soc/renesas/renesas.yaml b/Documentation/devicetree/bindings/soc/renesas/renesas.yaml index 16ca3ff7b1ae..15b9dd529389 100644 --- a/Documentation/devicetree/bindings/soc/renesas/renesas.yaml +++ b/Documentation/devicetree/bindings/soc/renesas/renesas.yaml @@ -348,6 +348,13 @@ properties: - renesas,white-hawk-cpu # White Hawk CPU board (RTP8A779G0ASKB0FC0SA000) - const: renesas,r8a779g0 + - description: R-Car V4H (R8A779G2) + items: + - enum: + - renesas,white-hawk-single # White Hawk Single board (RTP8A779G2ASKB0F10SA001) + - const: renesas,r8a779g2 + - const: renesas,r8a779g0 + - items: - enum: - renesas,white-hawk-breakout # White Hawk BreakOut board (RTP8A779G0ASKB0SB0SA000) -- cgit v1.2.3 From ced33f2cfa21a14a292a00e31dc9f85c1bfbda1c Mon Sep 17 00:00:00 2001 From: Yonghong Song Date: Sat, 27 Jan 2024 11:46:29 -0800 Subject: docs/bpf: Improve documentation of 64-bit immediate instructions For 64-bit immediate instruction, 'BPF_IMM | BPF_DW | BPF_LD' and src_reg=[0-6], the current documentation describes the 64-bit immediate is constructed by: imm64 = (next_imm << 32) | imm But actually imm64 is only used when src_reg=0. For all other variants (src_reg != 0), 'imm' and 'next_imm' have separate special encoding requirement and imm64 cannot be easily used to describe instruction semantics. This patch clarifies that 64-bit immediate instructions use two 32-bit immediate values instead of a 64-bit immediate value, so later describing individual 64-bit immediate instructions becomes less confusing. Signed-off-by: Yonghong Song Signed-off-by: Daniel Borkmann Acked-by: Dave Thaler Link: https://lore.kernel.org/bpf/20240127194629.737589-1-yonghong.song@linux.dev --- Documentation/bpf/standardization/instruction-set.rst | 13 ++++--------- 1 file changed, 4 insertions(+), 9 deletions(-) (limited to 'Documentation') diff --git a/Documentation/bpf/standardization/instruction-set.rst b/Documentation/bpf/standardization/instruction-set.rst index af43227b6ee4..fceacca46299 100644 --- a/Documentation/bpf/standardization/instruction-set.rst +++ b/Documentation/bpf/standardization/instruction-set.rst @@ -166,7 +166,7 @@ Note that most instructions do not use all of the fields. Unused fields shall be cleared to zero. As discussed below in `64-bit immediate instructions`_, a 64-bit immediate -instruction uses a 64-bit immediate value that is constructed as follows. +instruction uses two 32-bit immediate values that are constructed as follows. The 64 bits following the basic instruction contain a pseudo instruction using the same format but with opcode, dst_reg, src_reg, and offset all set to zero, and imm containing the high 32 bits of the immediate value. @@ -181,13 +181,8 @@ This is depicted in the following figure:: '--------------' pseudo instruction -Thus the 64-bit immediate value is constructed as follows: - - imm64 = (next_imm << 32) | imm - -where 'next_imm' refers to the imm value of the pseudo instruction -following the basic instruction. The unused bytes in the pseudo -instruction are reserved and shall be cleared to zero. +Here, the imm value of the pseudo instruction is called 'next_imm'. The unused +bytes in the pseudo instruction are reserved and shall be cleared to zero. Instruction classes ------------------- @@ -590,7 +585,7 @@ defined further below: ========================= ====== === ========================================= =========== ============== opcode construction opcode src pseudocode imm type dst type ========================= ====== === ========================================= =========== ============== -BPF_IMM | BPF_DW | BPF_LD 0x18 0x0 dst = imm64 integer integer +BPF_IMM | BPF_DW | BPF_LD 0x18 0x0 dst = (next_imm << 32) | imm integer integer BPF_IMM | BPF_DW | BPF_LD 0x18 0x1 dst = map_by_fd(imm) map fd map BPF_IMM | BPF_DW | BPF_LD 0x18 0x2 dst = map_val(map_by_fd(imm)) + next_imm map fd data pointer BPF_IMM | BPF_DW | BPF_LD 0x18 0x3 dst = var_addr(imm) variable id data pointer -- cgit v1.2.3 From d9b3869602476929e52e73ee3bc5c4e1aaf4d900 Mon Sep 17 00:00:00 2001 From: Florian Fainelli Date: Thu, 11 Jan 2024 15:15:38 -0800 Subject: dt-bindings: bus: Document Broadcom GISB arbiter 74165 compatible The 74165 chip introduces a new layout for the GISB arbiter which is not identical to previous chips, document the new compatible that we are going to key off. Link: https://lore.kernel.org/r/20240111231539.783785-2-florian.fainelli@broadcom.com Signed-off-by: Florian Fainelli Acked-by: Krzysztof Kozlowski --- Documentation/devicetree/bindings/bus/brcm,gisb-arb.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/bus/brcm,gisb-arb.yaml b/Documentation/devicetree/bindings/bus/brcm,gisb-arb.yaml index 3aaefdbe361e..9017c5a3f3d2 100644 --- a/Documentation/devicetree/bindings/bus/brcm,gisb-arb.yaml +++ b/Documentation/devicetree/bindings/bus/brcm,gisb-arb.yaml @@ -18,6 +18,7 @@ properties: - const: brcm,gisb-arb - items: - enum: + - brcm,bcm74165-gisb-arb # for V7 new style 16nm chips - brcm,bcm7278-gisb-arb # for V7 28nm chips - brcm,bcm7435-gisb-arb # for newer 40nm chips - brcm,bcm7400-gisb-arb # for older 40nm chips and all 65nm chips -- cgit v1.2.3 From a91cf53a1077557f6b7ae6bdfdbc86804f26e79d Mon Sep 17 00:00:00 2001 From: Alex Deucher Date: Thu, 18 Jan 2024 13:52:28 -0500 Subject: drm/amdgpu: update documentation on new chips These have been released now, so add them to the documentation. Acked-by: Feifei Xu Signed-off-by: Alex Deucher --- Documentation/gpu/amdgpu/dgpu-asic-info-table.csv | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/gpu/amdgpu/dgpu-asic-info-table.csv b/Documentation/gpu/amdgpu/dgpu-asic-info-table.csv index 882d2518f8ed..3825f00ca9fe 100644 --- a/Documentation/gpu/amdgpu/dgpu-asic-info-table.csv +++ b/Documentation/gpu/amdgpu/dgpu-asic-info-table.csv @@ -16,6 +16,7 @@ Radeon (RX|TM) (PRO|WX) Vega /MI25 /V320 /V340L /8200 /9100 /SSG MxGPU, VEGA10, AMD Radeon (Pro) VII /MI50 /MI60, VEGA20, DCE 12, 9.4.0, VCE 4.1.0 / UVD 7.2.0, 4.2.0 MI100, ARCTURUS, *, 9.4.1, VCN 2.5.0, 4.2.2 MI200, ALDEBARAN, *, 9.4.2, VCN 2.6.0, 4.4.0 +MI300, AQUA_VANGARAM, *, 9.4.3, VCN 4.0.3, 4.4.2 AMD Radeon (RX|Pro) 5600(M|XT) /5700 (M|XT|XTB) /W5700, NAVI10, DCN 2.0.0, 10.1.10, VCN 2.0.0, 5.0.0 AMD Radeon (Pro) 5300 /5500XTB/5500(XT|M) /W5500M /W5500, NAVI14, DCN 2.0.0, 10.1.1, VCN 2.0.2, 5.0.2 AMD Radeon RX 6800(XT) /6900(XT) /W6800, SIENNA_CICHLID, DCN 3.0.0, 10.3.0, VCN 3.0.0, 5.2.0 @@ -23,4 +24,5 @@ AMD Radeon RX 6700 XT / 6800M / 6700M, NAVY_FLOUNDER, DCN 3.0.0, 10.3.2, VCN 3.0 AMD Radeon RX 6600(XT) /6600M /W6600 /W6600M, DIMGREY_CAVEFISH, DCN 3.0.2, 10.3.4, VCN 3.0.16, 5.2.4 AMD Radeon RX 6500M /6300M /W6500M /W6300M, BEIGE_GOBY, DCN 3.0.3, 10.3.5, VCN 3.0.33, 5.2.5 AMD Radeon RX 7900 XT /XTX, , DCN 3.2.0, 11.0.0, VCN 4.0.0, 6.0.0 +AMD Radeon RX 7800 XT, , DCN 3.2.0, 11.0.3, VCN 4.0.0, 6.0.3 AMD Radeon RX 7600M (XT) /7700S /7600S, , DCN 3.2.1, 11.0.2, VCN 4.0.4, 6.0.2 -- cgit v1.2.3 From ee0a54a6ef6b61588bf97e9d35ff80f4e1a1de05 Mon Sep 17 00:00:00 2001 From: Rodrigo Siqueira Date: Mon, 22 Jan 2024 14:24:54 -0700 Subject: Documentation/gpu: Add basic page for HUBP MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Create the HUBP documentation page and add the doc references to extract the HUBP code documentation. Cc: Mario Limonciello Cc: Alex Deucher Cc: Harry Wentland Cc: Hamza Mahfooz Cc: Christian König Cc: Aurabindo Pillai Reviewed-by: Mario Limonciello Acked-by: Christian König Acked-by: Hamza Mahfooz Signed-off-by: Rodrigo Siqueira Signed-off-by: Alex Deucher --- Documentation/gpu/amdgpu/display/dcn-blocks.rst | 18 ++++++++++++++++++ Documentation/gpu/amdgpu/display/index.rst | 1 + drivers/gpu/drm/amd/display/dc/inc/hw/hubp.h | 13 ++++++++++++- 3 files changed, 31 insertions(+), 1 deletion(-) create mode 100644 Documentation/gpu/amdgpu/display/dcn-blocks.rst (limited to 'Documentation') diff --git a/Documentation/gpu/amdgpu/display/dcn-blocks.rst b/Documentation/gpu/amdgpu/display/dcn-blocks.rst new file mode 100644 index 000000000000..5da34d5b73d8 --- /dev/null +++ b/Documentation/gpu/amdgpu/display/dcn-blocks.rst @@ -0,0 +1,18 @@ +========== +DCN Blocks +========== + +In this section, you will find some extra details about some of the DCN blocks +and the code documentation when it is automatically generated. + +HUBP +---- + +.. kernel-doc:: drivers/gpu/drm/amd/display/dc/inc/hw/hubp.h + :doc: overview + +.. kernel-doc:: drivers/gpu/drm/amd/display/dc/inc/hw/hubp.h + :export: + +.. kernel-doc:: drivers/gpu/drm/amd/display/dc/inc/hw/hubp.h + :internal: diff --git a/Documentation/gpu/amdgpu/display/index.rst b/Documentation/gpu/amdgpu/display/index.rst index f8a4f53d70d8..b09d1434754d 100644 --- a/Documentation/gpu/amdgpu/display/index.rst +++ b/Documentation/gpu/amdgpu/display/index.rst @@ -28,5 +28,6 @@ table of content: display-manager.rst dc-debug.rst dcn-overview.rst + dcn-blocks.rst mpo-overview.rst dc-glossary.rst diff --git a/drivers/gpu/drm/amd/display/dc/inc/hw/hubp.h b/drivers/gpu/drm/amd/display/dc/inc/hw/hubp.h index 7f3f9b69e903..dedc5370023e 100644 --- a/drivers/gpu/drm/amd/display/dc/inc/hw/hubp.h +++ b/drivers/gpu/drm/amd/display/dc/inc/hw/hubp.h @@ -26,13 +26,24 @@ #ifndef __DAL_HUBP_H__ #define __DAL_HUBP_H__ +/** + * DOC: overview + * + * Display Controller Hub (DCHUB) is the gateway between the Scalable Data Port + * (SDP) and DCN. This component has multiple features, such as memory + * arbitration, rotation, and cursor manipulation. + * + * There is one HUBP allocated per pipe, which fetches data and converts + * different pixel formats (i.e. ARGB8888, NV12, etc) into linear, interleaved + * and fixed-depth streams of pixel data. + */ + #include "mem_input.h" #include "cursor_reg_cache.h" #define OPP_ID_INVALID 0xf #define MAX_TTU 0xffffff - enum cursor_pitch { CURSOR_PITCH_64_PIXELS = 0, CURSOR_PITCH_128_PIXELS, -- cgit v1.2.3 From 3595678ff8335f2deb73b3f47353bc30e1443a58 Mon Sep 17 00:00:00 2001 From: Rodrigo Siqueira Date: Mon, 22 Jan 2024 14:24:55 -0700 Subject: Documentation/gpu: Add simple doc page for DCHUBBUB MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Enable the documentation to extract code documentation from dchubbub.h file. Cc: Mario Limonciello Cc: Alex Deucher Cc: Harry Wentland Cc: Hamza Mahfooz Cc: Christian König Cc: Aurabindo Pillai Reviewed-by: Mario Limonciello Acked-by: Christian König Acked-by: Hamza Mahfooz Signed-off-by: Rodrigo Siqueira Signed-off-by: Alex Deucher --- Documentation/gpu/amdgpu/display/dcn-blocks.rst | 12 ++++++++++++ drivers/gpu/drm/amd/display/dc/inc/hw/dchubbub.h | 6 ++++++ 2 files changed, 18 insertions(+) (limited to 'Documentation') diff --git a/Documentation/gpu/amdgpu/display/dcn-blocks.rst b/Documentation/gpu/amdgpu/display/dcn-blocks.rst index 5da34d5b73d8..e4e0a4ddca4e 100644 --- a/Documentation/gpu/amdgpu/display/dcn-blocks.rst +++ b/Documentation/gpu/amdgpu/display/dcn-blocks.rst @@ -5,6 +5,18 @@ DCN Blocks In this section, you will find some extra details about some of the DCN blocks and the code documentation when it is automatically generated. +DCHUBBUB +-------- + +.. kernel-doc:: drivers/gpu/drm/amd/display/dc/inc/hw/hubp.h + :doc: overview + +.. kernel-doc:: drivers/gpu/drm/amd/display/dc/inc/hw/hubp.h + :export: + +.. kernel-doc:: drivers/gpu/drm/amd/display/dc/inc/hw/hubp.h + :internal: + HUBP ---- diff --git a/drivers/gpu/drm/amd/display/dc/inc/hw/dchubbub.h b/drivers/gpu/drm/amd/display/dc/inc/hw/dchubbub.h index 901891316dfb..2ae7484d18af 100644 --- a/drivers/gpu/drm/amd/display/dc/inc/hw/dchubbub.h +++ b/drivers/gpu/drm/amd/display/dc/inc/hw/dchubbub.h @@ -26,6 +26,12 @@ #ifndef __DAL_DCHUBBUB_H__ #define __DAL_DCHUBBUB_H__ +/** + * DOC: overview + * + * There is only one common DCHUBBUB. It contains the common request and return + * blocks for the Data Fabric Interface that are not clock/power gated. + */ enum dcc_control { dcc_control__256_256_xxx, -- cgit v1.2.3 From c371aa12d817f847c15911f17b785a063fea8a3e Mon Sep 17 00:00:00 2001 From: Rodrigo Siqueira Date: Mon, 22 Jan 2024 14:24:56 -0700 Subject: Documentation/gpu: Add kernel doc entry for DPP MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit This commit introduces basic DPP information and the struct scan for code documentation. Cc: Mario Limonciello Cc: Alex Deucher Cc: Harry Wentland Cc: Hamza Mahfooz Cc: Christian König Cc: Aurabindo Pillai Reviewed-by: Mario Limonciello Acked-by: Christian König Acked-by: Hamza Mahfooz Signed-off-by: Rodrigo Siqueira Signed-off-by: Alex Deucher --- Documentation/gpu/amdgpu/display/dcn-blocks.rst | 12 ++++++++++++ drivers/gpu/drm/amd/display/dc/inc/hw/dpp.h | 25 +++++++++++++++++++++++++ 2 files changed, 37 insertions(+) (limited to 'Documentation') diff --git a/Documentation/gpu/amdgpu/display/dcn-blocks.rst b/Documentation/gpu/amdgpu/display/dcn-blocks.rst index e4e0a4ddca4e..83fc4a03113e 100644 --- a/Documentation/gpu/amdgpu/display/dcn-blocks.rst +++ b/Documentation/gpu/amdgpu/display/dcn-blocks.rst @@ -28,3 +28,15 @@ HUBP .. kernel-doc:: drivers/gpu/drm/amd/display/dc/inc/hw/hubp.h :internal: + +DPP +--- + +.. kernel-doc:: drivers/gpu/drm/amd/display/dc/inc/hw/hubp.h + :doc: overview + +.. kernel-doc:: drivers/gpu/drm/amd/display/dc/inc/hw/hubp.h + :export: + +.. kernel-doc:: drivers/gpu/drm/amd/display/dc/inc/hw/hubp.h + :internal: diff --git a/drivers/gpu/drm/amd/display/dc/inc/hw/dpp.h b/drivers/gpu/drm/amd/display/dc/inc/hw/dpp.h index 4e604bf24f51..0f24afbf4388 100644 --- a/drivers/gpu/drm/amd/display/dc/inc/hw/dpp.h +++ b/drivers/gpu/drm/amd/display/dc/inc/hw/dpp.h @@ -27,6 +27,31 @@ #ifndef __DAL_DPP_H__ #define __DAL_DPP_H__ +/** + * DOC: overview + * + * The DPP (Display Pipe and Plane) block is the unified display data + * processing engine in DCN for processing graphic or video data on per DPP + * rectangle base. This rectangle can be a part of SLS (Single Large Surface), + * or a layer to be blended with other DPP, or a rectangle associated with a + * display tile. + * + * It provides various functions including: + * - graphic color keyer + * - graphic cursor compositing + * - graphic or video image source to destination scaling + * - image sharping + * - video format conversion from 4:2:0 or 4:2:2 to 4:4:4 + * - Color Space Conversion + * - Host LUT gamma adjustment + * - Color Gamut Remap + * - brightness and contrast adjustment. + * + * DPP pipe consists of Converter and Cursor (CNVC), Scaler (DSCL), Color + * Management (CM), Output Buffer (OBUF) and Digital Bypass (DPB) module + * connected in a video/graphics pipeline. + */ + #include "transform.h" #include "cursor_reg_cache.h" -- cgit v1.2.3 From b8c1c3a82e7564cfecac8aee361ec45e5061442a Mon Sep 17 00:00:00 2001 From: Rodrigo Siqueira Date: Mon, 22 Jan 2024 14:24:57 -0700 Subject: Documentation/gpu: Add kernel doc entry for MPC MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit This commit adds a kernel-doc entry for the MPC block. Since it enabled the kernel-doc to parse some of the documentation in the mpc.h file, fixing some of the comments was required. Cc: Mario Limonciello Cc: Alex Deucher Cc: Harry Wentland Cc: Hamza Mahfooz Cc: Christian König Cc: Aurabindo Pillai Reviewed-by: Mario Limonciello Acked-by: Christian König Acked-by: Hamza Mahfooz Signed-off-by: Rodrigo Siqueira Signed-off-by: Alex Deucher --- Documentation/gpu/amdgpu/display/dcn-blocks.rst | 12 + .../gpu/amdgpu/display/display-manager.rst | 3 - drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h | 250 ++++++++++++++------- 3 files changed, 185 insertions(+), 80 deletions(-) (limited to 'Documentation') diff --git a/Documentation/gpu/amdgpu/display/dcn-blocks.rst b/Documentation/gpu/amdgpu/display/dcn-blocks.rst index 83fc4a03113e..1a223f33202e 100644 --- a/Documentation/gpu/amdgpu/display/dcn-blocks.rst +++ b/Documentation/gpu/amdgpu/display/dcn-blocks.rst @@ -40,3 +40,15 @@ DPP .. kernel-doc:: drivers/gpu/drm/amd/display/dc/inc/hw/hubp.h :internal: + +MPC +--- + +.. kernel-doc:: drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h + :doc: overview + +.. kernel-doc:: drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h + :export: + +.. kernel-doc:: drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h + :internal: diff --git a/Documentation/gpu/amdgpu/display/display-manager.rst b/Documentation/gpu/amdgpu/display/display-manager.rst index be2651ecdd7f..67a811e6891f 100644 --- a/Documentation/gpu/amdgpu/display/display-manager.rst +++ b/Documentation/gpu/amdgpu/display/display-manager.rst @@ -131,9 +131,6 @@ The DRM blend mode and its elements are then mapped by AMDGPU display manager (DM) to program the blending configuration of the Multiple Pipe/Plane Combined (MPC), as follows: -.. kernel-doc:: drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h - :doc: mpc-overview - .. kernel-doc:: drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h :functions: mpcc_blnd_cfg diff --git a/drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h b/drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h index a11e40fddc44..ba9b942ce09f 100644 --- a/drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h +++ b/drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h @@ -23,13 +23,28 @@ */ /** - * DOC: mpc-overview + * DOC: overview * - * Multiple Pipe/Plane Combined (MPC) is a component in the hardware pipeline + * Multiple Pipe/Plane Combiner (MPC) is a component in the hardware pipeline * that performs blending of multiple planes, using global and per-pixel alpha. * It also performs post-blending color correction operations according to the * hardware capabilities, such as color transformation matrix and gamma 1D and * 3D LUT. + * + * MPC receives output from all DPP pipes and combines them to multiple outputs + * supporting "M MPC inputs -> N MPC outputs" flexible composition + * architecture. It features: + * + * - Programmable blending structure to allow software controlled blending and + * cascading; + * - Programmable window location of each DPP in active region of display; + * - Combining multiple DPP pipes in one active region when a single DPP pipe + * cannot process very large surface; + * - Combining multiple DPP from different SLS with blending; + * - Stereo formats from single DPP in top-bottom or side-by-side modes; + * - Stereo formats from 2 DPPs; + * - Alpha blending of multiple layers from different DPP pipes; + * - Programmable background color; */ #ifndef __DC_MPCC_H__ @@ -83,34 +98,66 @@ enum mpcc_alpha_blend_mode { /** * struct mpcc_blnd_cfg - MPCC blending configuration - * - * @black_color: background color - * @alpha_mode: alpha blend mode (MPCC_ALPHA_BLND_MODE) - * @pre_multiplied_alpha: whether pixel color values were pre-multiplied by the - * alpha channel (MPCC_ALPHA_MULTIPLIED_MODE) - * @global_gain: used when blend mode considers both pixel alpha and plane - * alpha value and assumes the global alpha value. - * @global_alpha: plane alpha value - * @overlap_only: whether overlapping of different planes is allowed - * @bottom_gain_mode: blend mode for bottom gain setting - * @background_color_bpc: background color for bpc - * @top_gain: top gain setting - * @bottom_inside_gain: blend mode for bottom inside - * @bottom_outside_gain: blend mode for bottom outside */ struct mpcc_blnd_cfg { - struct tg_color black_color; /* background color */ - enum mpcc_alpha_blend_mode alpha_mode; /* alpha blend mode */ - bool pre_multiplied_alpha; /* alpha pre-multiplied mode flag */ + /** + * @black_color: background color. + */ + struct tg_color black_color; + + /** + * @alpha_mode: alpha blend mode (MPCC_ALPHA_BLND_MODE). + */ + enum mpcc_alpha_blend_mode alpha_mode; + + /*** + * @@pre_multiplied_alpha: + * + * Whether pixel color values were pre-multiplied by the alpha channel + * (MPCC_ALPHA_MULTIPLIED_MODE). + */ + bool pre_multiplied_alpha; + + /** + * @global_gain: Used when blend mode considers both pixel alpha and plane. + */ int global_gain; + + /** + * @global_alpha: Plane alpha value. + */ int global_alpha; + + /** + * @@overlap_only: Whether overlapping of different planes is allowed. + */ bool overlap_only; /* MPCC top/bottom gain settings */ + + /** + * @bottom_gain_mode: Blend mode for bottom gain setting. + */ int bottom_gain_mode; + + /** + * @background_color_bpc: Background color for bpc. + */ int background_color_bpc; + + /** + * @top_gain: Top gain setting. + */ int top_gain; + + /** + * @bottom_inside_gain: Blend mode for bottom inside. + */ int bottom_inside_gain; + + /** + * @bottom_outside_gain: Blend mode for bottom outside. + */ int bottom_outside_gain; }; @@ -150,34 +197,58 @@ struct mpc_dwb_flow_control { /** * struct mpcc - MPCC connection and blending configuration for a single MPCC instance. - * @mpcc_id: MPCC physical instance - * @dpp_id: DPP input to this MPCC - * @mpcc_bot: pointer to bottom layer MPCC. NULL when not connected. - * @blnd_cfg: the blending configuration for this MPCC - * @sm_cfg: stereo mix setting for this MPCC - * @shared_bottom: if MPCC output to both OPP and DWB endpoints, true. Otherwise, false. * * This struct is used as a node in an MPC tree. */ struct mpcc { - int mpcc_id; /* MPCC physical instance */ - int dpp_id; /* DPP input to this MPCC */ - struct mpcc *mpcc_bot; /* pointer to bottom layer MPCC. NULL when not connected */ - struct mpcc_blnd_cfg blnd_cfg; /* The blending configuration for this MPCC */ - struct mpcc_sm_cfg sm_cfg; /* stereo mix setting for this MPCC */ - bool shared_bottom; /* TRUE if MPCC output to both OPP and DWB endpoints, else FALSE */ + /** + * @mpcc_id: MPCC physical instance. + */ + int mpcc_id; + + /** + * @dpp_id: DPP input to this MPCC + */ + int dpp_id; + + /** + * @mpcc_bot: Pointer to bottom layer MPCC. NULL when not connected. + */ + struct mpcc *mpcc_bot; + + /** + * @blnd_cfg: The blending configuration for this MPCC. + */ + struct mpcc_blnd_cfg blnd_cfg; + + /** + * @sm_cfg: stereo mix setting for this MPCC + */ + struct mpcc_sm_cfg sm_cfg; + + /** + * @shared_bottom: + * + * If MPCC output to both OPP and DWB endpoints, true. Otherwise, false. + */ + bool shared_bottom; }; /** * struct mpc_tree - MPC tree represents all MPCC connections for a pipe. * - * @opp_id: the OPP instance that owns this MPC tree - * @opp_list: the top MPCC layer of the MPC tree that outputs to OPP endpoint * */ struct mpc_tree { - int opp_id; /* The OPP instance that owns this MPC tree */ - struct mpcc *opp_list; /* The top MPCC layer of the MPC tree that outputs to OPP endpoint */ + /** + * @opp_id: The OPP instance that owns this MPC tree. + */ + int opp_id; + + /** + * @opp_list: the top MPCC layer of the MPC tree that outputs to OPP endpoint + */ + struct mpcc *opp_list; }; struct mpc { @@ -224,16 +295,20 @@ struct mpc_funcs { * Only used for planes that are part of blending chain for OPP output * * Parameters: - * [in/out] mpc - MPC context. - * [in/out] tree - MPC tree structure that plane will be added to. - * [in] blnd_cfg - MPCC blending configuration for the new blending layer. - * [in] sm_cfg - MPCC stereo mix configuration for the new blending layer. - * stereo mix must disable for the very bottom layer of the tree config. - * [in] insert_above_mpcc - Insert new plane above this MPCC. If NULL, insert as bottom plane. - * [in] dpp_id - DPP instance for the plane to be added. - * [in] mpcc_id - The MPCC physical instance to use for blending. - * - * Return: struct mpcc* - MPCC that was added. + * + * - [in/out] mpc - MPC context. + * - [in/out] tree - MPC tree structure that plane will be added to. + * - [in] blnd_cfg - MPCC blending configuration for the new blending layer. + * - [in] sm_cfg - MPCC stereo mix configuration for the new blending layer. + * stereo mix must disable for the very bottom layer of the tree config. + * - [in] insert_above_mpcc - Insert new plane above this MPCC. + * If NULL, insert as bottom plane. + * - [in] dpp_id - DPP instance for the plane to be added. + * - [in] mpcc_id - The MPCC physical instance to use for blending. + * + * Return: + * + * struct mpcc* - MPCC that was added. */ struct mpcc* (*insert_plane)( struct mpc *mpc, @@ -250,11 +325,14 @@ struct mpc_funcs { * Remove a specified MPCC from the MPC tree. * * Parameters: - * [in/out] mpc - MPC context. - * [in/out] tree - MPC tree structure that plane will be removed from. - * [in/out] mpcc - MPCC to be removed from tree. * - * Return: void + * - [in/out] mpc - MPC context. + * - [in/out] tree - MPC tree structure that plane will be removed from. + * - [in/out] mpcc - MPCC to be removed from tree. + * + * Return: + * + * void */ void (*remove_mpcc)( struct mpc *mpc, @@ -267,9 +345,12 @@ struct mpc_funcs { * Reset the MPCC HW status by disconnecting all muxes. * * Parameters: - * [in/out] mpc - MPC context. * - * Return: void + * - [in/out] mpc - MPC context. + * + * Return: + * + * void */ void (*mpc_init)(struct mpc *mpc); void (*mpc_init_single_inst)( @@ -282,11 +363,14 @@ struct mpc_funcs { * Update the blending configuration for a specified MPCC. * * Parameters: - * [in/out] mpc - MPC context. - * [in] blnd_cfg - MPCC blending configuration. - * [in] mpcc_id - The MPCC physical instance. * - * Return: void + * - [in/out] mpc - MPC context. + * - [in] blnd_cfg - MPCC blending configuration. + * - [in] mpcc_id - The MPCC physical instance. + * + * Return: + * + * void */ void (*update_blending)( struct mpc *mpc, @@ -296,15 +380,18 @@ struct mpc_funcs { /** * @cursor_lock: * - * Lock cursor updates for the specified OPP. - * OPP defines the set of MPCC that are locked together for cursor. + * Lock cursor updates for the specified OPP. OPP defines the set of + * MPCC that are locked together for cursor. * * Parameters: - * [in] mpc - MPC context. - * [in] opp_id - The OPP to lock cursor updates on - * [in] lock - lock/unlock the OPP * - * Return: void + * - [in] mpc - MPC context. + * - [in] opp_id - The OPP to lock cursor updates on + * - [in] lock - lock/unlock the OPP + * + * Return: + * + * void */ void (*cursor_lock)( struct mpc *mpc, @@ -314,20 +401,25 @@ struct mpc_funcs { /** * @insert_plane_to_secondary: * - * Add DPP into secondary MPC tree based on specified blending position. - * Only used for planes that are part of blending chain for DWB output + * Add DPP into secondary MPC tree based on specified blending + * position. Only used for planes that are part of blending chain for + * DWB output * * Parameters: - * [in/out] mpc - MPC context. - * [in/out] tree - MPC tree structure that plane will be added to. - * [in] blnd_cfg - MPCC blending configuration for the new blending layer. - * [in] sm_cfg - MPCC stereo mix configuration for the new blending layer. - * stereo mix must disable for the very bottom layer of the tree config. - * [in] insert_above_mpcc - Insert new plane above this MPCC. If NULL, insert as bottom plane. - * [in] dpp_id - DPP instance for the plane to be added. - * [in] mpcc_id - The MPCC physical instance to use for blending. - * - * Return: struct mpcc* - MPCC that was added. + * + * - [in/out] mpc - MPC context. + * - [in/out] tree - MPC tree structure that plane will be added to. + * - [in] blnd_cfg - MPCC blending configuration for the new blending layer. + * - [in] sm_cfg - MPCC stereo mix configuration for the new blending layer. + * stereo mix must disable for the very bottom layer of the tree config. + * - [in] insert_above_mpcc - Insert new plane above this MPCC. If + * NULL, insert as bottom plane. + * - [in] dpp_id - DPP instance for the plane to be added. + * - [in] mpcc_id - The MPCC physical instance to use for blending. + * + * Return: + * + * struct mpcc* - MPCC that was added. */ struct mpcc* (*insert_plane_to_secondary)( struct mpc *mpc, @@ -344,10 +436,14 @@ struct mpc_funcs { * Remove a specified DPP from the 'secondary' MPC tree. * * Parameters: - * [in/out] mpc - MPC context. - * [in/out] tree - MPC tree structure that plane will be removed from. - * [in] mpcc - MPCC to be removed from tree. - * Return: void + * + * - [in/out] mpc - MPC context. + * - [in/out] tree - MPC tree structure that plane will be removed from. + * - [in] mpcc - MPCC to be removed from tree. + * + * Return: + * + * void */ void (*remove_mpcc_from_secondary)( struct mpc *mpc, -- cgit v1.2.3 From 0fba33311e63aff39862e022bea97c103c4c0346 Mon Sep 17 00:00:00 2001 From: Rodrigo Siqueira Date: Mon, 22 Jan 2024 14:24:58 -0700 Subject: Documentation/gpu: Add entry for OPP in the kernel doc MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Introduce OPP as part of the kernel documentation. Cc: Mario Limonciello Cc: Alex Deucher Cc: Harry Wentland Cc: Hamza Mahfooz Cc: Christian König Cc: Aurabindo Pillai Reviewed-by: Mario Limonciello Acked-by: Christian König Acked-by: Hamza Mahfooz Signed-off-by: Rodrigo Siqueira Signed-off-by: Alex Deucher --- Documentation/gpu/amdgpu/display/dcn-blocks.rst | 12 ++++++++++++ drivers/gpu/drm/amd/display/dc/inc/hw/opp.h | 16 ++++++++++++++++ 2 files changed, 28 insertions(+) (limited to 'Documentation') diff --git a/Documentation/gpu/amdgpu/display/dcn-blocks.rst b/Documentation/gpu/amdgpu/display/dcn-blocks.rst index 1a223f33202e..5ba3c04c1db0 100644 --- a/Documentation/gpu/amdgpu/display/dcn-blocks.rst +++ b/Documentation/gpu/amdgpu/display/dcn-blocks.rst @@ -52,3 +52,15 @@ MPC .. kernel-doc:: drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h :internal: + +OPP +--- + +.. kernel-doc:: drivers/gpu/drm/amd/display/dc/inc/hw/opp.h + :doc: overview + +.. kernel-doc:: drivers/gpu/drm/amd/display/dc/inc/hw/opp.h + :export: + +.. kernel-doc:: drivers/gpu/drm/amd/display/dc/inc/hw/opp.h + :internal: diff --git a/drivers/gpu/drm/amd/display/dc/inc/hw/opp.h b/drivers/gpu/drm/amd/display/dc/inc/hw/opp.h index 7617fabbd16e..aee5372e292c 100644 --- a/drivers/gpu/drm/amd/display/dc/inc/hw/opp.h +++ b/drivers/gpu/drm/amd/display/dc/inc/hw/opp.h @@ -23,6 +23,22 @@ * */ +/** + * DOC: overview + * + * The Output Plane Processor (OPP) block groups have functions that format + * pixel streams such that they are suitable for display at the display device. + * The key functions contained in the OPP are: + * + * - Adaptive Backlight Modulation (ABM) + * - Formatter (FMT) which provide pixel-by-pixel operations for format the + * incoming pixel stream. + * - Output Buffer that provide pixel replication, and overlapping. + * - Interface between MPC and OPTC. + * - Clock and reset generation. + * - CRC generation. + */ + #ifndef __DAL_OPP_H__ #define __DAL_OPP_H__ -- cgit v1.2.3 From d79833f34bdc6859327015c1e9f56a448452454c Mon Sep 17 00:00:00 2001 From: Rodrigo Siqueira Date: Mon, 22 Jan 2024 14:24:59 -0700 Subject: Documentation/gpu: Add entry for the DIO component MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: Mario Limonciello Cc: Alex Deucher Cc: Harry Wentland Cc: Hamza Mahfooz Cc: Christian König Cc: Aurabindo Pillai Reviewed-by: Mario Limonciello Acked-by: Christian König Acked-by: Hamza Mahfooz Signed-off-by: Rodrigo Siqueira Signed-off-by: Alex Deucher --- Documentation/gpu/amdgpu/display/dcn-blocks.rst | 12 ++++++++++++ drivers/gpu/drm/amd/display/dc/link/hwss/link_hwss_dio.h | 10 ++++++++++ 2 files changed, 22 insertions(+) (limited to 'Documentation') diff --git a/Documentation/gpu/amdgpu/display/dcn-blocks.rst b/Documentation/gpu/amdgpu/display/dcn-blocks.rst index 5ba3c04c1db0..a3fbd3ea028b 100644 --- a/Documentation/gpu/amdgpu/display/dcn-blocks.rst +++ b/Documentation/gpu/amdgpu/display/dcn-blocks.rst @@ -64,3 +64,15 @@ OPP .. kernel-doc:: drivers/gpu/drm/amd/display/dc/inc/hw/opp.h :internal: + +DIO +--- + +.. kernel-doc:: drivers/gpu/drm/amd/display/dc/link/hwss/link_hwss_dio.h + :doc: overview + +.. kernel-doc:: drivers/gpu/drm/amd/display/dc/link/hwss/link_hwss_dio.h + :export: + +.. kernel-doc:: drivers/gpu/drm/amd/display/dc/link/hwss/link_hwss_dio.h + :internal: diff --git a/drivers/gpu/drm/amd/display/dc/link/hwss/link_hwss_dio.h b/drivers/gpu/drm/amd/display/dc/link/hwss/link_hwss_dio.h index f4633d3cf9b9..a1f72fe378ee 100644 --- a/drivers/gpu/drm/amd/display/dc/link/hwss/link_hwss_dio.h +++ b/drivers/gpu/drm/amd/display/dc/link/hwss/link_hwss_dio.h @@ -22,6 +22,16 @@ * Authors: AMD * */ + +/** + * DOC: overview + * + * Display Input Output (DIO), is the display input and output unit in DCN. It + * includes output encoders to support different display output, like + * DisplayPort, HDMI, DVI interface, and others. It also includes the control + * and status channels for these interfaces. + */ + #ifndef __LINK_HWSS_DIO_H__ #define __LINK_HWSS_DIO_H__ -- cgit v1.2.3 From 21dd98b0ef89f5a31927ce43ec4ed40ceef305da Mon Sep 17 00:00:00 2001 From: Rodrigo Siqueira Date: Mon, 22 Jan 2024 14:25:00 -0700 Subject: Documentation/gpu: Add an explanation about the DC weekly patches MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit This commit introduces some explanation about the display team validation. Changes since V1: - Remove unprecise information about the DC process for now, can be added later on. - Jani: Fix bullets Cc: Mario Limonciello Cc: Alex Deucher Cc: Harry Wentland Cc: Hamza Mahfooz Cc: Christian König Cc: Aurabindo Pillai Reviewed-by: Mario Limonciello Acked-by: Christian König Acked-by: Hamza Mahfooz Signed-off-by: Rodrigo Siqueira Signed-off-by: Alex Deucher --- Documentation/gpu/amdgpu/display/index.rst | 76 +++++++++++++++++++++++++++--- 1 file changed, 69 insertions(+), 7 deletions(-) (limited to 'Documentation') diff --git a/Documentation/gpu/amdgpu/display/index.rst b/Documentation/gpu/amdgpu/display/index.rst index b09d1434754d..aa89e8f9ab89 100644 --- a/Documentation/gpu/amdgpu/display/index.rst +++ b/Documentation/gpu/amdgpu/display/index.rst @@ -7,18 +7,80 @@ drm/amd/display - Display Core (DC) AMD display engine is partially shared with other operating systems; for this reason, our Display Core Driver is divided into two pieces: -1. **Display Core (DC)** contains the OS-agnostic components. Things like +#. **Display Core (DC)** contains the OS-agnostic components. Things like hardware programming and resource management are handled here. -2. **Display Manager (DM)** contains the OS-dependent components. Hooks to the - amdgpu base driver and DRM are implemented here. +#. **Display Manager (DM)** contains the OS-dependent components. Hooks to the + amdgpu base driver and DRM are implemented here. For example, you can check + display/amdgpu_dm/ folder. + +------------------ +DC Code validation +------------------ + +Maintaining the same code base across multiple OSes requires a lot of +synchronization effort between repositories and exhaustive validation. In the +DC case, we maintain a tree to centralize code from different parts. The shared +repository has integration tests with our Internal Linux CI farm, and we run a +comprehensive set of IGT tests in various AMD GPUs/APUs (mostly recent dGPUs +and APUs). Our CI also checks ARM64/32, PPC64/32, and x86_64/32 compilation +with DCN enabled and disabled. + +When we upstream a new feature or some patches, we pack them in a patchset with +the prefix **DC Patches for **, which is created based on the latest +`amd-staging-drm-next `_. All of +those patches are under a DC version tested as follows: + +* Ensure that every patch compiles and the entire series pass our set of IGT + test in different hardware. +* Prepare a branch with those patches for our validation team. If there is an + error, a developer will debug as fast as possible; usually, a simple bisect + in the series is enough to point to a bad change, and two possible actions + emerge: fix the issue or drop the patch. If it is not an easy fix, the bad + patch is dropped. +* Finally, developers wait a few days for community feedback before we merge + the series. + +It is good to stress that the test phase is something that we take extremely +seriously, and we never merge anything that fails our validation. Follows an +overview of our test set: + +#. Manual test + * Multiple Hotplugs with DP and HDMI. + * Stress test with multiple display configuration changes via the user interface. + * Validate VRR behaviour. + * Check PSR. + * Validate MPO when playing video. + * Test more than two displays connected at the same time. + * Check suspend/resume. + * Validate FPO. + * Check MST. +#. Automated test + * IGT tests in a farm with GPUs and APUs that support DCN and DCE. + * Compilation validation with the latest GCC and Clang from LTS distro. + * Cross-compilation for PowerPC 64/32, ARM 64/32, and x86 32. + +In terms of test setup for CI and manual tests, we usually use: + +#. The latest Ubuntu LTS. +#. In terms of userspace, we only use fully updated open-source components + provided by the distribution official package manager. +#. Regarding IGT, we use the latest code from the upstream. +#. Most of the manual tests are conducted in the GNome but we also use KDE. + +Notice that someone from our test team will always reply to the cover letter +with the test report. + +-------------- +DC Information +-------------- The display pipe is responsible for "scanning out" a rendered frame from the GPU memory (also called VRAM, FrameBuffer, etc.) to a display. In other words, it would: -1. Read frame information from memory; -2. Perform required transformation; -3. Send pixel data to sink devices. +#. Read frame information from memory; +#. Perform required transformation; +#. Send pixel data to sink devices. If you want to learn more about our driver details, take a look at the below table of content: @@ -26,8 +88,8 @@ table of content: .. toctree:: display-manager.rst - dc-debug.rst dcn-overview.rst dcn-blocks.rst mpo-overview.rst + dc-debug.rst dc-glossary.rst -- cgit v1.2.3 From ba162ae749a5526025a6f1061bfcbb301a6adb65 Mon Sep 17 00:00:00 2001 From: Rodrigo Siqueira Date: Mon, 22 Jan 2024 14:25:01 -0700 Subject: Documentation/gpu: Introduce a simple contribution list for display code MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit This commit adds a contribution list for display under the kernel documentation with some first suggestions. It also drops an old TODO list from the display folder. Cc: Mario Limonciello Cc: Alex Deucher Cc: Harry Wentland Cc: Hamza Mahfooz Cc: Christian König Cc: Aurabindo Pillai Reviewed-by: Mario Limonciello Acked-by: Christian König Acked-by: Hamza Mahfooz Signed-off-by: Rodrigo Siqueira Signed-off-by: Alex Deucher --- .../gpu/amdgpu/display/display-contributing.rst | 168 +++++++++++++++++++++ Documentation/gpu/amdgpu/display/index.rst | 1 + drivers/gpu/drm/amd/display/TODO | 110 -------------- 3 files changed, 169 insertions(+), 110 deletions(-) create mode 100644 Documentation/gpu/amdgpu/display/display-contributing.rst delete mode 100644 drivers/gpu/drm/amd/display/TODO (limited to 'Documentation') diff --git a/Documentation/gpu/amdgpu/display/display-contributing.rst b/Documentation/gpu/amdgpu/display/display-contributing.rst new file mode 100644 index 000000000000..fdb2bea01d53 --- /dev/null +++ b/Documentation/gpu/amdgpu/display/display-contributing.rst @@ -0,0 +1,168 @@ +.. _display_todos: + +============================== +AMDGPU - Display Contributions +============================== + +First of all, if you are here, you probably want to give some technical +contribution to the display code, and for that, we say thank you :) + +This page summarizes some of the issues you can help with; keep in mind that +this is a static page, and it is always a good idea to try to reach developers +in the amdgfx or some of the maintainers. Finally, this page follows the DRM +way of creating a TODO list; for more information, check +'Documentation/gpu/todo.rst'. + +Gitlab issues +============= + +Users can report issues associated with AMD GPUs at: + +- https://gitlab.freedesktop.org/drm/amd + +Usually, we try to add a proper label to all new tickets to make it easy to +filter issues. If you can reproduce any problem, you could help by adding more +information or fixing the issue. + +Level: diverse + +IGT +=== + +`IGT`_ provides many integration tests that can be run on your GPU. We always +want to pass a large set of tests to increase the test coverage in our CI. If +you wish to contribute to the display code but are unsure where a good place +is, we recommend you run all IGT tests and try to fix any failure you see in +your hardware. Keep in mind that this failure can be an IGT problem or a kernel +issue; it is necessary to analyze case-by-case. + +Level: diverse + +.. _IGT: https://gitlab.freedesktop.org/drm/igt-gpu-tools + +Compilation +=========== + +Fix compilation warnings +------------------------ + +Enable the W1 or W2 warning level in the kernel compilation and try to fix the +issues on the display side. + +Level: Starter + +Fix compilation issues when using um architecture +------------------------------------------------- + +Linux has a User-mode Linux (UML) feature, and the kernel can be compiled to +the **um** architecture. Compiling for **um** can bring multiple advantages +from the test perspective. We currently have some compilation issues in this +area that we need to fix. + +Level: Intermediate + +Code Refactor +============= + +Add prefix to DC functions to improve the debug with ftrace +----------------------------------------------------------- + +The Ftrace debug feature (check 'Documentation/trace/ftrace.rst') is a +fantastic way to check the code path when developers try to make sense of a +bug. Ftrace provides a filter mechanism that can be useful when the developer +has some hunch of which part of the code can cause the issue; for this reason, +if a set of functions has a proper prefix, it becomes easy to create a good +filter. Additionally, prefixes can improve stack trace readability. + +The DC code does not follow some prefix rules, which makes the Ftrace filter +more complicated and reduces the readability of the stack trace. If you want +something simple to start contributing to the display, you can make patches for +adding prefixes to DC functions. To create those prefixes, use part of the file +name as a prefix for all functions in the target file. Check the +'amdgpu_dm_crtc.c` and `amdgpu_dm_plane.c` for some references. However, we +strongly advise not to send huge patches changing these prefixes; otherwise, it +will be hard to review and test, which can generate second thoughts from +maintainers. Try small steps; in case of double, you can ask before you put in +effort. We recommend first looking at folders like dceXYZ, dcnXYZ, basics, +bios, core, clk_mgr, hwss, resource, and irq. + +Level: Starter + +Reduce code duplication +----------------------- + +AMD has an extensive portfolio with various dGPUs and APUs that amdgpu +supports. To maintain the new hardware release cadence, DCE/DCN was designed in +a modular design, making the bring-up for new hardware fast. Over the years, +amdgpu accumulated some technical debt in the code duplication area. For this +task, it would be a good idea to find a tool that can discover code duplication +(including patterns) and use it as guidance to reduce duplications. + +Level: Intermediate + +Make atomic_commit_[check|tail] more readable +--------------------------------------------- + +The functions responsible for atomic commit and tail are intricate and +extensive. In particular `amdgpu_dm_atomic_commit_tail` is a long function and +could benefit from being split into smaller helpers. Improvements in this area +are more than welcome, but keep in mind that changes in this area will affect +all ASICs, meaning that refactoring requires a comprehensive verification; in +other words, this effort can take some time for validation. + +Level: Advanced + +Documentation +============= + +Expand kernel-doc +----------------- + +Many DC functions do not have a proper kernel-doc; understanding a function and +adding documentation is a great way to learn more about the amdgpu driver and +also leave an outstanding contribution to the entire community. + +Level: Starter + +Beyond AMDGPU +============= + +AMDGPU provides features that are not yet enabled in the userspace. This +section highlights some of the coolest display features, which could be enabled +with the userspace developer helper. + +Enable underlay +--------------- + +AMD display has this feature called underlay (which you can read more about at +'Documentation/GPU/amdgpu/display/mpo-overview.rst') which is intended to +save power when playing a video. The basic idea is to put a video in the +underlay plane at the bottom and the desktop in the plane above it with a hole +in the video area. This feature is enabled in ChromeOS, and from our data +measurement, it can save power. + +Level: Unknown + +Adaptive Backlight Modulation (ABM) +----------------------------------- + +ABM is a feature that adjusts the display panel's backlight level and pixel +values depending on the displayed image. This power-saving feature can be very +useful when the system starts to run off battery; since this will impact the +display output fidelity, it would be good if this option was something that +users could turn on or off. + +Level: Unknown + + +HDR & Color management & VRR +---------------------------- + +HDR, Color Management, and VRR are huge topics and it's hard to put these into +concise ToDos. If you are interested in this topic, we recommend checking some +blog posts from the community developers to better understand some of the +specific challenges and people working on the subject. If anyone wants to work +on some particular part, we can try to help with some basic guidance. Finally, +keep in mind that we already have some kernel-doc in place for those areas. + +Level: Unknown diff --git a/Documentation/gpu/amdgpu/display/index.rst b/Documentation/gpu/amdgpu/display/index.rst index aa89e8f9ab89..f0c342e00a39 100644 --- a/Documentation/gpu/amdgpu/display/index.rst +++ b/Documentation/gpu/amdgpu/display/index.rst @@ -92,4 +92,5 @@ table of content: dcn-blocks.rst mpo-overview.rst dc-debug.rst + display-contributing.rst dc-glossary.rst diff --git a/drivers/gpu/drm/amd/display/TODO b/drivers/gpu/drm/amd/display/TODO deleted file mode 100644 index a8a6c106e8c7..000000000000 --- a/drivers/gpu/drm/amd/display/TODO +++ /dev/null @@ -1,110 +0,0 @@ -=============================================================================== -TODOs -=============================================================================== - -1. Base this on drm-next - WIP - - -2. Cleanup commit history - - -3. WIP - Drop page flip helper and use DRM's version - - -4. DONE - Flatten all DC objects - * dc_stream/core_stream/stream should just be dc_stream - * Same for other DC objects - - "Is there any major reason to keep all those abstractions? - - Could you collapse everything into struct dc_stream? - - I haven't looked recently but I didn't get the impression there was a - lot of design around what was public/protected, more whatever needed - to be used by someone else was in public." - ~ Dave Airlie - - -5. DONE - Rename DC objects to align more with DRM - * dc_surface -> dc_plane_state - * dc_stream -> dc_stream_state - - -6. DONE - Per-plane and per-stream validation - - -7. WIP - Per-plane and per-stream commit - - -8. WIP - Split pipe_ctx into plane and stream resource structs - - -9. Attach plane and stream reources to state object instead of validate_context - - -10. Remove dc_edid_caps and drm_helpers_parse_edid_caps - * Use drm_display_info instead - * Remove DC's edid quirks and rely on DRM's quirks (add quirks if needed) - - "Making sure you use the sink-specific helper libraries and kernel - subsystems, since there's really no good reason to have 2nd - implementation of those in the kernel. Looks likes that's done for mst - and edid parsing. There's still a bit a midlayer feeling to the edid - parsing side (e.g. dc_edid_caps and dm_helpers_parse_edid_caps, I - think it'd be much better if you convert that over to reading stuff - from drm_display_info and if needed, push stuff into the core). Also, - I can't come up with a good reason why DC needs all this (except to - reimplement half of our edid quirk table, which really isn't a good - idea). Might be good if you put this onto the list of things to fix - long-term, but imo not a blocker. Definitely make sure new stuff - doesn't slip in (i.e. if you start adding edid quirks to DC instead of - the drm core, refactoring to use the core edid stuff was pointless)." - ~ Daniel Vetter - - -11. Remove dc/i2caux. This folder can be somewhat misleading. It's basically an -overy complicated HW programming function for sendind and receiving i2c/aux -commands. We can greatly simplify that and move it into dc/dceXYZ like other -HW blocks. - -12. drm_modeset_lock in MST should no longer be needed in recent kernels - * Adopt appropriate locking scheme - -13. get_modes and best_encoder callbacks look a bit funny. Can probably rip out -a few indirections, and consider removing entirely and using the -drm_atomic_helper_best_encoder default behaviour. - -14. core/dc_debug.c, consider switching to the atomic state debug helpers and -moving all your driver state printing into the various atomic_print_state -callbacks. There's also plans to expose this stuff in a standard way across all -drivers, to make debugging userspace compositors easier across different hw. - -15. Move DP/HDMI dual mode adaptors to drm_dp_dual_mode_helper.c. See -dal_ddc_service_i2c_query_dp_dual_mode_adaptor. - -16. Move to core SCDC helpers (I think those are new since initial DC review). - -17. There's still a pretty massive layer cake around dp aux and DPCD handling, -with like 3 levels of abstraction and using your own structures instead of the -stuff in drm_dp_helper.h. drm_dp_helper.h isn't really great and already has 2 -incompatible styles, just means more reasons not to add a third (or well third -one gets to do the cleanup refactor). - -18. There's a pile of sink handling code, both for DP and HDMI where I didn't -immediately recognize the standard. I think long term it'd be best for the drm -subsystem if we try to move as much of that into helpers/core as possible, and -share it with drivers. But that's a very long term goal, and by far not just an -issue with DC - other drivers, especially around DP sink handling, are equally -guilty. - -19. DONE - The DC logger is still a rather sore thing, but I know that the -DRM_DEBUG stuff just isn't up to the challenges either. We need to figure out -something that integrates better with DRM and linux debug printing, while not -being useless with filtering output. dynamic debug printing might be an option. - -20. Use kernel i2c device to program HDMI retimer. Some boards have an HDMI -retimer that we need to program to pass PHY compliance. Currently that's -bypassing the i2c device and goes directly to HW. This should be changed. - -21. Remove vector.c from dc/basics. It's used in DDC code which can probably -be simplified enough to no longer need a vector implementation. -- cgit v1.2.3 From 1fa8924a488a46b2709f1babd7176193fa077a93 Mon Sep 17 00:00:00 2001 From: Duy Nguyen Date: Thu, 25 Jan 2024 16:34:31 +0100 Subject: dt-bindings: power: renesas,rcar-sysc: Document R-Car V4M support MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Document support for the System Controller (SYSC) in the R-Car V4M (R8A779H0) SoC. Signed-off-by: Duy Nguyen Signed-off-by: Geert Uytterhoeven Acked-by: Conor Dooley Reviewed-by: Niklas Söderlund Reviewed-by: Wolfram Sang Link: https://lore.kernel.org/r/6315cbd0b6e9b92a7914d98f397a2c663ad521c6.1706194617.git.geert+renesas@glider.be Signed-off-by: Ulf Hansson --- Documentation/devicetree/bindings/power/renesas,rcar-sysc.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/power/renesas,rcar-sysc.yaml b/Documentation/devicetree/bindings/power/renesas,rcar-sysc.yaml index 0720b54881c2..e76fb273490f 100644 --- a/Documentation/devicetree/bindings/power/renesas,rcar-sysc.yaml +++ b/Documentation/devicetree/bindings/power/renesas,rcar-sysc.yaml @@ -45,6 +45,7 @@ properties: - renesas,r8a779a0-sysc # R-Car V3U - renesas,r8a779f0-sysc # R-Car S4-8 - renesas,r8a779g0-sysc # R-Car V4H + - renesas,r8a779h0-sysc # R-Car V4M reg: maxItems: 1 -- cgit v1.2.3 From b32eb97edeb8d69092d57419917b19c909ff962a Mon Sep 17 00:00:00 2001 From: Chen-Yu Tsai Date: Sun, 28 Jan 2024 00:32:44 +0800 Subject: dt-bindings: dma: allwinner,sun50i-a64-dma: Add compatible for H616 The DMA controllers found on the H616 and H618 are the same as the one found on the A100. The only difference is the DMA endpoint (DRQ) layout. Since the number of channels and endpoints are described with additional generic properties, just add a new H616-specific compatible string and fallback to the A100 one. Signed-off-by: Chen-Yu Tsai Acked-by: Conor Dooley Reviewed-by: Andre Przywara Link: https://lore.kernel.org/r/20240127163247.384439-5-wens@kernel.org Signed-off-by: Vinod Koul --- .../devicetree/bindings/dma/allwinner,sun50i-a64-dma.yaml | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/dma/allwinner,sun50i-a64-dma.yaml b/Documentation/devicetree/bindings/dma/allwinner,sun50i-a64-dma.yaml index ec2d7a789ffe..0f2501f72cca 100644 --- a/Documentation/devicetree/bindings/dma/allwinner,sun50i-a64-dma.yaml +++ b/Documentation/devicetree/bindings/dma/allwinner,sun50i-a64-dma.yaml @@ -28,6 +28,9 @@ properties: - items: - const: allwinner,sun8i-r40-dma - const: allwinner,sun50i-a64-dma + - items: + - const: allwinner,sun50i-h616-dma + - const: allwinner,sun50i-a100-dma reg: maxItems: 1 @@ -59,10 +62,11 @@ required: if: properties: compatible: - enum: - - allwinner,sun20i-d1-dma - - allwinner,sun50i-a100-dma - - allwinner,sun50i-h6-dma + contains: + enum: + - allwinner,sun20i-d1-dma + - allwinner,sun50i-a100-dma + - allwinner,sun50i-h6-dma then: properties: -- cgit v1.2.3 From 517fd647359a0c635314cd23082e46b402f2f046 Mon Sep 17 00:00:00 2001 From: Rafał Miłecki Date: Tue, 23 Jan 2024 07:08:04 +0100 Subject: dt-bindings: interrupt-controller: convert MediaTek sysirq 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: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20240123060804.32254-1-zajec5@gmail.com Signed-off-by: Rob Herring --- .../mediatek,mt6577-sysirq.yaml | 85 ++++++++++++++++++++++ .../interrupt-controller/mediatek,sysirq.txt | 44 ----------- 2 files changed, 85 insertions(+), 44 deletions(-) create mode 100644 Documentation/devicetree/bindings/interrupt-controller/mediatek,mt6577-sysirq.yaml delete mode 100644 Documentation/devicetree/bindings/interrupt-controller/mediatek,sysirq.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/interrupt-controller/mediatek,mt6577-sysirq.yaml b/Documentation/devicetree/bindings/interrupt-controller/mediatek,mt6577-sysirq.yaml new file mode 100644 index 000000000000..e1a379c052e4 --- /dev/null +++ b/Documentation/devicetree/bindings/interrupt-controller/mediatek,mt6577-sysirq.yaml @@ -0,0 +1,85 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/interrupt-controller/mediatek,mt6577-sysirq.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: MediaTek sysirq + +description: + MediaTek SOCs sysirq support controllable irq inverter for each GIC SPI + interrupt. + +maintainers: + - Matthias Brugger + +properties: + compatible: + oneOf: + - const: mediatek,mt6577-sysirq + - items: + - enum: + - mediatek,mt2701-sysirq + - mediatek,mt2712-sysirq + - mediatek,mt6580-sysirq + - mediatek,mt6582-sysirq + - mediatek,mt6589-sysirq + - mediatek,mt6592-sysirq + - mediatek,mt6755-sysirq + - mediatek,mt6765-sysirq + - mediatek,mt6779-sysirq + - mediatek,mt6795-sysirq + - mediatek,mt6797-sysirq + - mediatek,mt7622-sysirq + - mediatek,mt7623-sysirq + - mediatek,mt7629-sysirq + - mediatek,mt8127-sysirq + - mediatek,mt8135-sysirq + - mediatek,mt8173-sysirq + - mediatek,mt8183-sysirq + - mediatek,mt8365-sysirq + - mediatek,mt8516-sysirq + - const: mediatek,mt6577-sysirq + + reg: + minItems: 1 + maxItems: 2 + + interrupt-controller: true + + "#interrupt-cells": + $ref: "arm,gic.yaml#/properties/#interrupt-cells" + +required: + - reg + - interrupt-controller + - "#interrupt-cells" + +allOf: + - $ref: /schemas/interrupt-controller.yaml# + - if: + properties: + compatible: + contains: + const: mediatek,mt6797-sysirq + then: + properties: + reg: + minItems: 2 + else: + properties: + reg: + maxItems: 1 + +unevaluatedProperties: false + +examples: + - | + interrupt-controller@10200620 { + compatible = "mediatek,mt6797-sysirq", "mediatek,mt6577-sysirq"; + reg = <0x10220620 0x20>, + <0x10220690 0x10>; + interrupt-parent = <&gic>; + interrupt-controller; + #interrupt-cells = <3>; + }; diff --git a/Documentation/devicetree/bindings/interrupt-controller/mediatek,sysirq.txt b/Documentation/devicetree/bindings/interrupt-controller/mediatek,sysirq.txt deleted file mode 100644 index 3ffc60184e44..000000000000 --- a/Documentation/devicetree/bindings/interrupt-controller/mediatek,sysirq.txt +++ /dev/null @@ -1,44 +0,0 @@ -MediaTek sysirq - -MediaTek SOCs sysirq support controllable irq inverter for each GIC SPI -interrupt. - -Required properties: -- compatible: should be - "mediatek,mt8516-sysirq", "mediatek,mt6577-sysirq": for MT8516 - "mediatek,mt8183-sysirq", "mediatek,mt6577-sysirq": for MT8183 - "mediatek,mt8173-sysirq", "mediatek,mt6577-sysirq": for MT8173 - "mediatek,mt8135-sysirq", "mediatek,mt6577-sysirq": for MT8135 - "mediatek,mt8127-sysirq", "mediatek,mt6577-sysirq": for MT8127 - "mediatek,mt7622-sysirq", "mediatek,mt6577-sysirq": for MT7622 - "mediatek,mt7623-sysirq", "mediatek,mt6577-sysirq": for MT7623 - "mediatek,mt7629-sysirq", "mediatek,mt6577-sysirq": for MT7629 - "mediatek,mt6795-sysirq", "mediatek,mt6577-sysirq": for MT6795 - "mediatek,mt6797-sysirq", "mediatek,mt6577-sysirq": for MT6797 - "mediatek,mt6779-sysirq", "mediatek,mt6577-sysirq": for MT6779 - "mediatek,mt6765-sysirq", "mediatek,mt6577-sysirq": for MT6765 - "mediatek,mt6755-sysirq", "mediatek,mt6577-sysirq": for MT6755 - "mediatek,mt6592-sysirq", "mediatek,mt6577-sysirq": for MT6592 - "mediatek,mt6589-sysirq", "mediatek,mt6577-sysirq": for MT6589 - "mediatek,mt6582-sysirq", "mediatek,mt6577-sysirq": for MT6582 - "mediatek,mt6580-sysirq", "mediatek,mt6577-sysirq": for MT6580 - "mediatek,mt6577-sysirq": for MT6577 - "mediatek,mt2712-sysirq", "mediatek,mt6577-sysirq": for MT2712 - "mediatek,mt2701-sysirq", "mediatek,mt6577-sysirq": for MT2701 - "mediatek,mt8365-sysirq", "mediatek,mt6577-sysirq": for MT8365 -- interrupt-controller : Identifies the node as an interrupt controller -- #interrupt-cells : Use the same format as specified by GIC in arm,gic.txt. -- reg: Physical base address of the intpol registers and length of memory - mapped region. Could be multiple bases here. Ex: mt6797 needs 2 reg, others - need 1. - -Example: - sysirq: intpol-controller@10200620 { - compatible = "mediatek,mt6797-sysirq", - "mediatek,mt6577-sysirq"; - interrupt-controller; - #interrupt-cells = <3>; - interrupt-parent = <&gic>; - reg = <0 0x10220620 0 0x20>, - <0 0x10220690 0 0x10>; - }; -- cgit v1.2.3 From 60804e5889fe3b87d71be9b50322cfacf21117e1 Mon Sep 17 00:00:00 2001 From: Vegard Nossum Date: Thu, 11 Jan 2024 10:48:38 +0100 Subject: docs: add blurb about target audience to maintainer-profile It's good to be clear about who the intended target audience for any given piece of documentation is, as this will help us put new text in the correct place. Let's encourage submitters to state it explicitly rather than relying on where they placed it in the directory hierarchy as there isn't necessarily a one-to-one correspondence between them. Target audience: documentation contributors and reviewers. Signed-off-by: Vegard Nossum Acked-by: Randy Dunlap Signed-off-by: Jonathan Corbet Link: https://lore.kernel.org/r/20240111094838.3695697-1-vegard.nossum@oracle.com --- Documentation/doc-guide/maintainer-profile.rst | 7 +++++++ 1 file changed, 7 insertions(+) (limited to 'Documentation') diff --git a/Documentation/doc-guide/maintainer-profile.rst b/Documentation/doc-guide/maintainer-profile.rst index 755d39f0d407..db3636d0d71d 100644 --- a/Documentation/doc-guide/maintainer-profile.rst +++ b/Documentation/doc-guide/maintainer-profile.rst @@ -27,6 +27,13 @@ documentation and ensure that no new errors or warnings have been introduced. Generating HTML documents and looking at the result will help to avoid unsightly misunderstandings about how things will be rendered. +All new documentation (including additions to existing documents) should +ideally justify who the intended target audience is somewhere in the +changelog; this way, we ensure that the documentation ends up in the correct +place. Some possible categories are: kernel developers (experts or +beginners), userspace programmers, end users and/or system administrators, +and distributors. + Key cycle dates --------------- -- cgit v1.2.3 From 91a3d6be99e63f6b0a4b2983aef20bd3da2d1a74 Mon Sep 17 00:00:00 2001 From: Randy Dunlap Date: Sat, 6 Jan 2024 17:24:00 -0800 Subject: doc-guide: kernel-doc: tell about object-like macros Since 2014 kernel-doc has supported describing object-like macros but it is not documented anywhere. I should have required some documentation for it when I merged the patch. :( There are currently only 3 uses of this (all in DRM headers, in include/drm/*.h). Add object-like macro kernel-doc documentation now so that more may know about it and use it. Fixes: cbb4d3e6510b ("scripts/kernel-doc: handle object-like macros") Signed-off-by: Randy Dunlap Cc: Jonathan Corbet Cc: linux-doc@vger.kernel.org Acked-by: Daniel Vetter Signed-off-by: Jonathan Corbet Link: https://lore.kernel.org/r/20240107012400.32587-1-rdunlap@infradead.org --- Documentation/doc-guide/kernel-doc.rst | 45 ++++++++++++++++++++++++++++++++++ 1 file changed, 45 insertions(+) (limited to 'Documentation') diff --git a/Documentation/doc-guide/kernel-doc.rst b/Documentation/doc-guide/kernel-doc.rst index 6ad72ac6861b..d6f7efefea42 100644 --- a/Documentation/doc-guide/kernel-doc.rst +++ b/Documentation/doc-guide/kernel-doc.rst @@ -341,6 +341,51 @@ Typedefs with function prototypes can also be documented:: */ typedef void (*type_name)(struct v4l2_ctrl *arg1, void *arg2); +Object-like macro documentation +------------------------------- + +Object-like macros are distinct from function-like macros. They are +differentiated by whether the macro name is immediately followed by a +left parenthesis ('(') for function-like macros or not followed by one +for object-like macros. + +Function-like macros are handled like functions by ``scripts/kernel-doc``. +They may have a parameter list. Object-like macros have do not have a +parameter list. + +The general format of an object-like macro kernel-doc comment is:: + + /** + * define object_name - Brief description. + * + * Description of the object. + */ + +Example:: + + /** + * define MAX_ERRNO - maximum errno value that is supported + * + * Kernel pointers have redundant information, so we can use a + * scheme where we can return either an error code or a normal + * pointer with the same return value. + */ + #define MAX_ERRNO 4095 + +Example:: + + /** + * define DRM_GEM_VRAM_PLANE_HELPER_FUNCS - \ + * Initializes struct drm_plane_helper_funcs for VRAM handling + * + * This macro initializes struct drm_plane_helper_funcs to use the + * respective helper functions. + */ + #define DRM_GEM_VRAM_PLANE_HELPER_FUNCS \ + .prepare_fb = drm_gem_vram_plane_helper_prepare_fb, \ + .cleanup_fb = drm_gem_vram_plane_helper_cleanup_fb + + Highlights and cross-references ------------------------------- -- cgit v1.2.3 From 6151b9c8f21e91bc5c8074ff297311c682993ea0 Mon Sep 17 00:00:00 2001 From: Federico Vaga Date: Sun, 7 Jan 2024 00:38:20 +0100 Subject: doc:it_IT: first translation for locking/ To begin with: - locking/index.rst - locking/lockdep-design.rst - locking/lockstat.rst - locking/lockturture.rst - locking/locktypes.rst And RCU/torture.rst to avoid broken references. Signed-off-by: Federico Vaga Signed-off-by: Jonathan Corbet Link: https://lore.kernel.org/r/20240106233820.30454-1-federico.vaga@vaga.pv.it --- Documentation/RCU/torture.rst | 2 +- Documentation/translations/it_IT/RCU/index.rst | 19 + Documentation/translations/it_IT/RCU/torture.rst | 369 +++++++++++ .../translations/it_IT/core-api/index.rst | 12 + Documentation/translations/it_IT/index.rst | 1 + Documentation/translations/it_IT/locking/index.rst | 20 + .../translations/it_IT/locking/lockdep-design.rst | 678 +++++++++++++++++++++ .../translations/it_IT/locking/lockstat.rst | 230 +++++++ .../translations/it_IT/locking/locktorture.rst | 181 ++++++ .../translations/it_IT/locking/locktypes.rst | 547 +++++++++++++++++ 10 files changed, 2058 insertions(+), 1 deletion(-) create mode 100644 Documentation/translations/it_IT/RCU/index.rst create mode 100644 Documentation/translations/it_IT/RCU/torture.rst create mode 100644 Documentation/translations/it_IT/locking/index.rst create mode 100644 Documentation/translations/it_IT/locking/lockdep-design.rst create mode 100644 Documentation/translations/it_IT/locking/lockstat.rst create mode 100644 Documentation/translations/it_IT/locking/locktorture.rst create mode 100644 Documentation/translations/it_IT/locking/locktypes.rst (limited to 'Documentation') diff --git a/Documentation/RCU/torture.rst b/Documentation/RCU/torture.rst index 49e7beea6ae1..4b1f99c4181f 100644 --- a/Documentation/RCU/torture.rst +++ b/Documentation/RCU/torture.rst @@ -318,7 +318,7 @@ Suppose that a previous kvm.sh run left its output in this directory:: tools/testing/selftests/rcutorture/res/2022.11.03-11.26.28 -Then this run can be re-run without rebuilding as follow: +Then this run can be re-run without rebuilding as follow:: kvm-again.sh tools/testing/selftests/rcutorture/res/2022.11.03-11.26.28 diff --git a/Documentation/translations/it_IT/RCU/index.rst b/Documentation/translations/it_IT/RCU/index.rst new file mode 100644 index 000000000000..22adf1d58752 --- /dev/null +++ b/Documentation/translations/it_IT/RCU/index.rst @@ -0,0 +1,19 @@ +.. SPDX-License-Identifier: GPL-2.0 + +.. _it_rcu_concepts: + +=============== +Concetti su RCU +=============== + +.. toctree:: + :maxdepth: 3 + + torture + +.. only:: subproject and html + + Indici + ====== + + * :ref:`genindex` diff --git a/Documentation/translations/it_IT/RCU/torture.rst b/Documentation/translations/it_IT/RCU/torture.rst new file mode 100644 index 000000000000..79d9e6932acc --- /dev/null +++ b/Documentation/translations/it_IT/RCU/torture.rst @@ -0,0 +1,369 @@ +.. SPDX-License-Identifier: GPL-2.0 + +.. include:: ../disclaimer-ita.rst + +============================================= +Le operazioni RCU per le verifiche *torture* +============================================= + +CONFIG_RCU_TORTURE_TEST +======================= + +L'opzione CONFIG_RCU_TORTURE_TEST è disponibile per tutte le implementazione di +RCU. L'opzione creerà un modulo rcutorture che potrete caricare per avviare le +verifiche. La verifica userà printk() per riportare lo stato, dunque potrete +visualizzarlo con dmesg (magari usate grep per filtrare "torture"). Le verifiche +inizieranno al caricamento, e si fermeranno alla sua rimozione. + +I parametri di modulo hanno tutti il prefisso "rcutortute.", vedere +Documentation/admin-guide/kernel-parameters.txt. + +Rapporto +======== + +Il rapporto sulle verifiche si presenta nel seguente modo:: + + rcu-torture:--- Start of test: nreaders=16 nfakewriters=4 stat_interval=30 verbose=0 test_no_idle_hz=1 shuffle_interval=3 stutter=5 irqreader=1 fqs_duration=0 fqs_holdoff=0 fqs_stutter=3 test_boost=1/0 test_boost_interval=7 test_boost_duration=4 + rcu-torture: rtc: (null) ver: 155441 tfle: 0 rta: 155441 rtaf: 8884 rtf: 155440 rtmbe: 0 rtbe: 0 rtbke: 0 rtbre: 0 rtbf: 0 rtb: 0 nt: 3055767 + rcu-torture: Reader Pipe: 727860534 34213 0 0 0 0 0 0 0 0 0 + rcu-torture: Reader Batch: 727877838 17003 0 0 0 0 0 0 0 0 0 + rcu-torture: Free-Block Circulation: 155440 155440 155440 155440 155440 155440 155440 155440 155440 155440 0 + rcu-torture:--- End of test: SUCCESS: nreaders=16 nfakewriters=4 stat_interval=30 verbose=0 test_no_idle_hz=1 shuffle_interval=3 stutter=5 irqreader=1 fqs_duration=0 fqs_holdoff=0 fqs_stutter=3 test_boost=1/0 test_boost_interval=7 test_boost_duration=4 + +Sulla maggior parte dei sistemi questo rapporto si produce col comando "dmesg | +grep torture:". Su configurazioni più esoteriche potrebbe essere necessario +usare altri comandi per visualizzare i messaggi di printk(). La funzione +printk() usa KERN_ALERT, dunque i messaggi dovrebbero essere ben visibili. ;-) + +La prima e l'ultima riga mostrano i parametri di module di rcutorture, e solo +sull'ultima riga abbiamo il risultato finale delle verifiche effettuate che può +essere "SUCCESS" (successo) or "FAILURE" (insuccesso). + +Le voci sono le seguenti: + +* "rtc": L'indirizzo in esadecimale della struttura attualmente visibile dai + lettori. + +* "ver": Il numero di volte dall'avvio che il processo scrittore di RCU ha + cambiato la struttura visible ai lettori. + +* "tfle": se non è zero, indica la lista di strutture "torture freelist" da + mettere in "rtc" è vuota. Questa condizione è importante perché potrebbe + illuderti che RCU stia funzionando mentre invece non è il caso. :-/ + +* "rta": numero di strutture allocate dalla lista "torture freelist". + +* "rtaf": il numero di allocazioni fallite dalla lista "torture freelist" a + causa del fatto che fosse vuota. Non è inusuale che sia diverso da zero, ma è + un brutto segno se questo numero rappresenta una frazione troppo alta di + "rta". + +* "rtf": il numero di rilasci nella lista "torture freelist" + +* "rtmbe": Un valore diverso da zero indica che rcutorture crede che + rcu_assign_pointer() e rcu_dereference() non funzionino correttamente. Il + valore dovrebbe essere zero. + +* "rtbe": un valore diverso da zero indica che le funzioni della famiglia + rcu_barrier() non funzionano correttamente. + +* "rtbke": rcutorture è stato capace di creare dei kthread real-time per forzare + l'inversione di priorità di RCU. Il valore dovrebbe essere zero. + +* "rtbre": sebbene rcutorture sia riuscito a creare dei kthread capaci di + forzare l'inversione di priorità, non è riuscito però ad impostarne la + priorità real-time al livello 1. Il valore dovrebbe essere zero. + +* "rtbf": Il numero di volte che è fallita la promozione della priorità per + risolvere un'inversione. + +* "rtb": Il numero di volte che rcutorture ha provato a forzare l'inversione di + priorità. Il valore dovrebbe essere diverso da zero Se state verificando la + promozione della priorità col parametro "test_bootst". + +* "nt": il numero di volte che rcutorture ha eseguito codice lato lettura + all'interno di un gestore di *timer*. Questo valore dovrebbe essere diverso da + zero se avete specificato il parametro "irqreader". + +* "Reader Pipe": un istogramma dell'età delle strutture viste dai lettori. RCU + non funziona correttamente se una qualunque voce, dalla terza in poi, ha un + valore diverso da zero. Se dovesse succedere, rcutorture stampa la stringa + "!!!" per renderlo ben visibile. L'età di una struttura appena creata è zero, + diventerà uno quando sparisce dalla visibilità di un lettore, e incrementata + successivamente per ogni periodo di grazia; infine rilasciata dopo essere + passata per (RCU_TORTURE_PIPE_LEN-2) periodi di grazia. + + L'istantanea qui sopra è stata presa da una corretta implementazione di RCU. + Se volete vedere come appare quando non funziona, sbizzarritevi nel romperla. + ;-) + +* "Reader Batch": un istogramma di età di strutture viste dai lettori, ma + conteggiata in termini di lotti piuttosto che periodi. Anche qui dalla terza + voce in poi devono essere zero. La ragione d'esistere di questo rapporto è che + a volte è più facile scatenare un terzo valore diverso da zero qui piuttosto + che nella lista "Reader Pipe". + +* "Free-Block Circulation": il numero di strutture *torture* che hanno raggiunto + un certo punto nella catena. Il primo numero dovrebbe corrispondere + strettamente al numero di strutture allocate; il secondo conta quelle rimosse + dalla vista dei lettori. Ad eccezione dell'ultimo valore, gli altri + corrispondono al numero di passaggi attraverso il periodo di grazia. L'ultimo + valore dovrebbe essere zero, perché viene incrementato solo se il contatore + della struttura torture viene in un qualche modo incrementato oltre il + normale. + +Una diversa implementazione di RCU potrebbe fornire informazioni aggiuntive. Per +esempio, *Tree SRCU* fornisce anche la seguente riga:: + + srcud-torture: Tree SRCU per-CPU(idx=0): 0(35,-21) 1(-4,24) 2(1,1) 3(-26,20) 4(28,-47) 5(-9,4) 6(-10,14) 7(-14,11) T(1,6) + +Questa riga mostra lo stato dei contatori per processore, in questo caso per +*Tree SRCU*, usando un'allocazione dinamica di srcu_struct (dunque "srcud-" +piuttosto che "srcu-"). I numeri fra parentesi sono i valori del "vecchio" +contatore e di quello "corrente" per ogni processore. Il valore "idx" mappa +questi due valori nell'array, ed è utile per il *debug*. La "T" finale contiene +il valore totale dei contatori. + +Uso su specifici kernel +======================= + +A volte può essere utile eseguire RCU torture su un kernel già compilato, ad +esempio quando lo si sta per mettere in proeduzione. In questo caso, il kernel +dev'essere compilato con CONFIG_RCU_TORTUE_TEST=m, cosicché le verifiche possano +essere avviate usano modprobe e terminate con rmmod. + +Per esempio, potreste usare questo script:: + + #!/bin/sh + + modprobe rcutorture + sleep 3600 + rmmod rcutorture + dmesg | grep torture: + +Potete controllare il rapporto verificando manualmente la presenza del marcatore +di errore "!!!". Ovviamente, siete liberi di scriverne uno più elaborato che +identifichi automaticamente gli errori. Il comando "rmmod" forza la stampa di +"SUCCESS" (successo), "FAILURE" (fallimento), o "RCU_HOTPLUG". I primi due sono +autoesplicativi; invece, l'ultimo indica che non son stati trovati problemi in +RCU, tuttavia ci sono stati problemi con CPU-hotplug. + + +Uso sul kernel di riferimento +============================= + +Quando si usa rcutorture per verificare modifiche ad RCU stesso, spesso è +necessario compilare un certo numero di kernel usando configurazioni diverse e +con parametri d'avvio diversi. In questi casi, usare modprobe ed rmmod potrebbe +richiedere molto tempo ed il processo essere suscettibile ad errori. + +Dunque, viene messo a disposizione il programma +tools/testing/selftests/rcutorture/bin/kvm.sh per le architetture x86, arm64 e +powerpc. Di base, eseguirà la serie di verifiche elencate in +tools/testing/selftests/rcutorture/configs/rcu/CFLIST. Ognuna di queste verrà +eseguita per 30 minuti in una macchina virtuale con uno spazio utente minimale +fornito da un initrd generato automaticamente. Al completamento, gli artefatti +prodotti e i messaggi vengono analizzati alla ricerca di errori, ed i risultati +delle esecuzioni riassunti in un rapporto. + +Su grandi sistemi, le verifiche di rcutorture posso essere velocizzare passano a +kvm.sh l'argomento --cpus. Per esempio, su un sistema a 64 processori, "--cpus +43" userà fino a 43 processori per eseguire contemporaneamente le verifiche. Su +un kernel v5.4 per eseguire tutti gli scenari in due serie, riduce il tempo +d'esecuzione da otto ore a un'ora (senza contare il tempo per compilare sedici +kernel). L'argomento "--dryrun sched" non eseguirà verifiche, piuttosto vi +informerà su come queste verranno organizzate in serie. Questo può essere utile +per capire quanti processori riservare per le verifiche in --cpus. + +Non serve eseguire tutti gli scenari di verifica per ogni modifica. Per esempio, +per una modifica a Tree SRCU potete eseguire gli scenari SRCU-N e SRCU-P. Per +farlo usate l'argomento --configs di kvm.sh in questo modo: "--configs 'SRCU-N +SRCU-P'". Su grandi sistemi si possono eseguire più copie degli stessi scenari, +per esempio, un hardware che permette di eseguire 448 thread, può eseguire 5 +istanze complete contemporaneamente. Per farlo:: + + kvm.sh --cpus 448 --configs '5*CFLIST' + +Oppure, lo stesso sistema, può eseguire contemporaneamente 56 istanze dello +scenario su otto processori:: + + kvm.sh --cpus 448 --configs '56*TREE04' + +O ancora 28 istanze per ogni scenario su otto processori:: + + kvm.sh --cpus 448 --configs '28*TREE03 28*TREE04' + +Ovviamente, ogni esecuzione utilizzerà della memoria. Potete limitarne l'uso con +l'argomento --memory, che di base assume il valore 512M. Per poter usare valori +piccoli dovrete disabilitare le verifiche *callback-flooding* usando il +parametro --bootargs che vedremo in seguito. + +A volte è utile avere informazioni aggiuntive di debug, in questo caso potete +usare il parametro --kconfig, per esempio, ``--kconfig +'CONFIG_RCU_EQS_DEBUG=y'``. In aggiunta, ci sono i parametri --gdb, --kasan, and +kcsan. Da notare che --gdb vi limiterà all'uso di un solo scenario per +esecuzione di kvm.sh e richiede di avere anche un'altra finestra aperta dalla +quale eseguire ``gdb`` come viene spiegato dal programma. + +Potete passare anche i parametri d'avvio del kernel, per esempio, per +controllare i parametri del modulo rcutorture. Per esempio, per verificare +modifiche del codice RCU CPU stall-warning, usate ``bootargs +'rcutorture.stall_cpu=30``. Il programma riporterà un fallimento, ossia il +risultato della verifica. Come visto in precedenza, ridurre la memoria richiede +la disabilitazione delle verifiche *callback-flooding*:: + + kvm.sh --cpus 448 --configs '56*TREE04' --memory 128M \ + --bootargs 'rcutorture.fwd_progress=0' + +A volte tutto quello che serve è una serie completa di compilazioni del kernel. +Questo si ottiene col parametro --buildonly. + +Il parametro --duration sovrascrive quello di base di 30 minuti. Per esempio, +con ``--duration 2d`` l'esecuzione sarà di due giorni, ``--duraction 5min`` di +cinque minuti, e ``--duration 45s`` di 45 secondi. L'ultimo può essere utile per +scovare rari errori nella sequenza d'avvio. + +Infine, il parametro --trust-make permette ad ogni nuova compilazione del kernel +di riutilizzare tutto il possibile da quelle precedenti. Da notare che senza il +parametro --trust-make, i vostri file di *tag* potrebbero essere distrutti. + +Ci sono altri parametri più misteriosi che sono documentati nel codice sorgente +dello programma kvm.sh. + +Se un'esecuzione contiene degli errori, il loro numero durante la compilazione e +all'esecuzione verranno elencati alla fine fra i risultati di kvm.sh (che vi +consigliamo caldamente di reindirizzare verso un file). I file prodotti dalla +compilazione ed i risultati stampati vengono salvati, usando un riferimento +temporale, nelle cartella tools/testing/selftests/rcutorture/res. Una cartella +di queste cartelle può essere fornita a kvm-find-errors.sh per estrarne gli +errori. Per esempio:: + + tools/testing/selftests/rcutorture/bin/kvm-find-errors.sh \ + tools/testing/selftests/rcutorture/res/2020.01.20-15.54.23 + +Tuttavia, molto spesso è più conveniente aprire i file direttamente. I file +riguardanti tutti gli scenari di un'esecuzione di trovano nella cartella +principale (2020.01.20-15.54.23 nell'esempio precedente), mentre quelli +specifici per scenario si trovano in sotto cartelle che prendono il nome dello +scenario stesso (per esempio, "TREE04"). Se un dato scenario viene eseguito più +di una volta (come abbiamo visto con "--configs '56*TREE04'"), allora dalla +seconda esecuzione in poi le sottocartelle includeranno un numero di +progressione, per esempio "TREE04.2", "TREE04.3", e via dicendo. + +Il file solitamente più usato nella cartella principale è testid.txt. Se la +verifica viene eseguita in un repositorio git, allora questo file conterrà il +*commit* sul quale si basano le verifiche, mentre tutte le modifiche non +registrare verranno mostrate in formato diff. + +I file solitamente più usati nelle cartelle di scenario sono: + +.config + Questo file contiene le opzioni di Kconfig + +Make.out + Questo file contiene il risultato di compilazione per uno specifico scenario + +console.log + Questo file contiene il risultato d'esecuzione per uno specifico scenario. + Questo file può essere esaminato una volta che il kernel è stato avviato, + ma potrebbe non esistere se l'avvia non è fallito. + +vmlinux + Questo file contiene il kernel, e potrebbe essere utile da esaminare con + programmi come pbjdump e gdb + +Ci sono altri file, ma vengono usati meno. Molti sono utili all'analisi di +rcutorture stesso o dei suoi programmi. + +Nel kernel v5.4, su un sistema a 12 processori, un'esecuzione senza errori +usando gli scenari di base produce il seguente risultato:: + + SRCU-N ------- 804233 GPs (148.932/s) [srcu: g10008272 f0x0 ] + SRCU-P ------- 202320 GPs (37.4667/s) [srcud: g1809476 f0x0 ] + SRCU-t ------- 1122086 GPs (207.794/s) [srcu: g0 f0x0 ] + SRCU-u ------- 1111285 GPs (205.794/s) [srcud: g1 f0x0 ] + TASKS01 ------- 19666 GPs (3.64185/s) [tasks: g0 f0x0 ] + TASKS02 ------- 20541 GPs (3.80389/s) [tasks: g0 f0x0 ] + TASKS03 ------- 19416 GPs (3.59556/s) [tasks: g0 f0x0 ] + TINY01 ------- 836134 GPs (154.84/s) [rcu: g0 f0x0 ] n_max_cbs: 34198 + TINY02 ------- 850371 GPs (157.476/s) [rcu: g0 f0x0 ] n_max_cbs: 2631 + TREE01 ------- 162625 GPs (30.1157/s) [rcu: g1124169 f0x0 ] + TREE02 ------- 333003 GPs (61.6672/s) [rcu: g2647753 f0x0 ] n_max_cbs: 35844 + TREE03 ------- 306623 GPs (56.782/s) [rcu: g2975325 f0x0 ] n_max_cbs: 1496497 + CPU count limited from 16 to 12 + TREE04 ------- 246149 GPs (45.5831/s) [rcu: g1695737 f0x0 ] n_max_cbs: 434961 + TREE05 ------- 314603 GPs (58.2598/s) [rcu: g2257741 f0x2 ] n_max_cbs: 193997 + TREE07 ------- 167347 GPs (30.9902/s) [rcu: g1079021 f0x0 ] n_max_cbs: 478732 + CPU count limited from 16 to 12 + TREE09 ------- 752238 GPs (139.303/s) [rcu: g13075057 f0x0 ] n_max_cbs: 99011 + +Ripetizioni +=========== + +Immaginate di essere alla caccia di un raro problema che si verifica all'avvio. +Potreste usare kvm.sh, tuttavia questo ricompilerebbe il kernel ad ogni +esecuzione. Se avete bisogno di (diciamo) 1000 esecuzioni per essere sicuri di +aver risolto il problema, allora queste inutili ricompilazioni possono diventare +estremamente fastidiose. + +Per questo motivo esiste kvm-again.sh. + +Immaginate che un'esecuzione precedente di kvm.sh abbia lasciato i suoi +artefatti nella cartella:: + + tools/testing/selftests/rcutorture/res/2022.11.03-11.26.28 + +Questa esecuzione può essere rieseguita senza ricompilazioni:: + + kvm-again.sh tools/testing/selftests/rcutorture/res/2022.11.03-11.26.28 + +Alcuni dei parametri originali di kvm.sh possono essere sovrascritti, in +particolare --duration e --bootargs. Per esempio:: + + kvm-again.sh tools/testing/selftests/rcutorture/res/2022.11.03-11.26.28 \ + --duration 45s + +rieseguirebbe il test precedente, ma solo per 45 secondi, e quindi aiutando a +trovare quel raro problema all'avvio sopracitato. + +Esecuzioni distribuite +====================== + +Sebbene kvm.sh sia utile, le sue verifiche sono limitate ad un singolo sistema. +Non è poi così difficile usare un qualsiasi ambiente di sviluppo per eseguire +(diciamo) 5 istanze di kvm.sh su altrettanti sistemi, ma questo avvierebbe +inutili ricompilazioni del kernel. In aggiunta, il processo di distribuzione +degli scenari di verifica per rcutorture sui sistemi disponibili richiede +scrupolo perché soggetto ad errori. + +Per questo esiste kvm-remote.sh. + +Se il seguente comando funziona:: + + ssh system0 date + +e funziona anche per system1, system2, system3, system4, e system5, e tutti +questi sistemi hanno 64 CPU, allora potere eseguire:: + + kvm-remote.sh "system0 system1 system2 system3 system4 system5" \ + --cpus 64 --duration 8h --configs "5*CFLIST" + +Questo compilerà lo scenario di base sul sistema locale, poi lo distribuirà agli +altri cinque sistemi elencati fra i parametri, ed eseguirà ogni scenario per +otto ore. Alla fine delle esecuzioni, i risultati verranno raccolti, registrati, +e stampati. La maggior parte dei parametri di kvm.sh possono essere usati con +kvm-remote.sh, tuttavia la lista dei sistemi deve venire sempre per prima. + +L'argomento di kvm.sh ``--dryrun scenarios`` può essere utile per scoprire +quanti scenari potrebbero essere eseguiti in gruppo di sistemi. + +Potete rieseguire anche una precedente esecuzione remota come abbiamo già fatto +per kvm.sh:: + + kvm-remote.sh "system0 system1 system2 system3 system4 system5" \ + tools/testing/selftests/rcutorture/res/2022.11.03-11.26.28-remote \ + --duration 24h + +In questo caso, la maggior parte dei parametri di kvm-again.sh possono essere +usati dopo il percorso alla cartella contenente gli artefatti dell'esecuzione da +ripetere. diff --git a/Documentation/translations/it_IT/core-api/index.rst b/Documentation/translations/it_IT/core-api/index.rst index cc4c4328ad03..dad20402d11b 100644 --- a/Documentation/translations/it_IT/core-api/index.rst +++ b/Documentation/translations/it_IT/core-api/index.rst @@ -10,6 +10,18 @@ Utilità di base symbol-namespaces +Primitive di sincronizzazione +============================= + +Come Linux impedisce che tutto si verifichi contemporaneamente. Consultate +Documentation/translations/it_IT/locking/index.rst per maggiorni informazioni +sul tema. + +.. toctree:: + :maxdepth: 1 + + ../RCU/index + .. only:: subproject and html Indices diff --git a/Documentation/translations/it_IT/index.rst b/Documentation/translations/it_IT/index.rst index b95dfa1ded04..51a15bf37577 100644 --- a/Documentation/translations/it_IT/index.rst +++ b/Documentation/translations/it_IT/index.rst @@ -91,6 +91,7 @@ interfacciarsi con il resto del kernel. :maxdepth: 1 core-api/index + Sincronizzazione nel kernel Strumenti e processi per lo sviluppo ==================================== diff --git a/Documentation/translations/it_IT/locking/index.rst b/Documentation/translations/it_IT/locking/index.rst new file mode 100644 index 000000000000..19963d33e84d --- /dev/null +++ b/Documentation/translations/it_IT/locking/index.rst @@ -0,0 +1,20 @@ +.. SPDX-License-Identifier: GPL-2.0 + +================ +Sincronizzazione +================ + +.. toctree:: + :maxdepth: 1 + + locktypes + lockdep-design + lockstat + locktorture + +.. only:: subproject and html + + Indici + ====== + + * :ref:`genindex` diff --git a/Documentation/translations/it_IT/locking/lockdep-design.rst b/Documentation/translations/it_IT/locking/lockdep-design.rst new file mode 100644 index 000000000000..9ed00d8cf280 --- /dev/null +++ b/Documentation/translations/it_IT/locking/lockdep-design.rst @@ -0,0 +1,678 @@ +.. SPDX-License-Identifier: GPL-2.0 + +.. include:: ../disclaimer-ita.rst + +Validatore di sincronizzazione durante l'esecuzione +=================================================== + +Classi di blocchi +----------------- + +L'oggetto su cui il validatore lavora è una "classe" di blocchi. + +Una classe di blocchi è un gruppo di blocchi che seguono le stesse regole di +sincronizzazione, anche quando i blocchi potrebbero avere più istanze (anche +decine di migliaia). Per esempio un blocco nella struttura inode è una classe, +mentre ogni inode sarà un'istanza di questa classe di blocco. + +Il validatore traccia lo "stato d'uso" di una classe di blocchi e le sue +dipendenze con altre classi. L'uso di un blocco indica come quel blocco viene +usato rispetto al suo contesto d'interruzione, mentre le dipendenze di un blocco +possono essere interpretate come il loro ordine; per esempio L1 -> L2 suggerisce +che un processo cerca di acquisire L2 mentre già trattiene L1. Dal punto di +vista di lockdep, i due blocchi (L1 ed L2) non sono per forza correlati: quella +dipendenza indica solamente l'ordine in cui sono successe le cose. Il validatore +verifica permanentemente la correttezza dell'uso dei blocchi e delle loro +dipendenze, altrimenti ritornerà un errore. + +Il comportamento di una classe di blocchi viene costruito dall'insieme delle sue +istanze. Una classe di blocco viene registrata alla creazione della sua prima +istanza, mentre tutte le successive istanze verranno mappate; dunque, il loro +uso e le loro dipendenze contribuiranno a costruire quello della classe. Una +classe di blocco non sparisce quando sparisce una sua istanza, ma può essere +rimossa quando il suo spazio in memoria viene reclamato. Per esempio, questo +succede quando si rimuove un modulo, o quando una *workqueue* viene eliminata. + +Stato +----- + +Il validatore traccia l'uso cronologico delle classi di blocchi e ne divide +l'uso in categorie (4 USI * n STATI + 1). + +I quattro USI possono essere: + +- 'sempre trattenuto nel contesto ' +- 'sempre trattenuto come blocco di lettura nel contesto ' +- 'sempre trattenuto con abilitato' +- 'sempre trattenuto come blocco di lettura con abilitato' + +gli `n` STATI sono codificati in kernel/locking/lockdep_states.h, ad oggi +includono: + +- hardirq +- softirq + +infine l'ultima categoria è: + +- 'sempre trattenuto' [ == !unused ] + +Quando vengono violate le regole di sincronizzazione, questi bit di utilizzo +vengono presentati nei messaggi di errore di sincronizzazione, fra parentesi +graffe, per un totale di `2 * n` (`n`: bit STATO). Un esempio inventato:: + + modprobe/2287 is trying to acquire lock: + (&sio_locks[i].lock){-.-.}, at: [] mutex_lock+0x21/0x24 + + but task is already holding lock: + (&sio_locks[i].lock){-.-.}, at: [] mutex_lock+0x21/0x24 + +Per un dato blocco, da sinistra verso destra, la posizione del bit indica l'uso +del blocco e di un eventuale blocco di lettura, per ognuno degli `n` STATI elencati +precedentemente. Il carattere mostrato per ogni bit indica: + + === =========================================================================== + '.' acquisito con interruzioni disabilitate fuori da un contesto d'interruzione + '-' acquisito in contesto d'interruzione + '+' acquisito con interruzioni abilitate + '?' acquisito in contesto d'interruzione con interruzioni abilitate + === =========================================================================== + +Il seguente esempio mostra i bit:: + + (&sio_locks[i].lock){-.-.}, at: [] mutex_lock+0x21/0x24 + |||| + ||| \-> softirq disabilitati e fuori da un contesto di softirq + || \--> acquisito in un contesto di softirq + | \---> hardirq disabilitati e fuori da un contesto di hardirq + \----> acquisito in un contesto di hardirq + +Per un dato STATO, che il blocco sia mai stato acquisito in quel contesto di +STATO, o che lo STATO sia abilitato, ci lascia coi quattro possibili scenari +mostrati nella seguente tabella. Il carattere associato al bit indica con +esattezza in quale scenario ci si trova al momento del rapporto. + + +---------------+---------------+------------------+ + | | irq abilitati | irq disabilitati | + +---------------+---------------+------------------+ + | sempre in irq | '?' | '-' | + +---------------+---------------+------------------+ + | mai in irq | '+' | '.' | + +---------------+---------------+------------------+ + +Il carattere '-' suggerisce che le interruzioni sono disabilitate perché +altrimenti verrebbe mostrato il carattere '?'. Una deduzione simile può essere +fatta anche per '+' + +I blocchi inutilizzati (ad esempio i mutex) non possono essere fra le cause di +un errore. + +Regole dello stato per un blocco singolo +---------------------------------------- + +Avere un blocco sicuro in interruzioni (*irq-safe*) significa che è sempre stato +usato in un contesto d'interruzione, mentre un blocco insicuro in interruzioni +(*irq-unsafe*) significa che è sempre stato acquisito con le interruzioni +abilitate. + +Una classe softirq insicura è automaticamente insicura anche per hardirq. I +seguenti stati sono mutualmente esclusivi: solo una può essere vero quando viene +usata una classe di blocco:: + + o + o + +Questo perché se un blocco può essere usato in un contesto di interruzioni +(sicuro in interruzioni), allora non può mai essere acquisito con le +interruzioni abilitate (insicuro in interruzioni). Altrimenti potrebbe +verificarsi uno stallo. Per esempio, questo blocco viene acquisito, ma prima di +essere rilasciato il contesto d'esecuzione viene interrotto nuovamente, e quindi +si tenterà di acquisirlo nuovamente. Questo porterà ad uno stallo, in +particolare uno stallo ricorsivo. + +Il validatore rileva e riporta gli usi di blocchi che violano queste regole per +blocchi singoli. + +Regole per le dipendenze di blocchi multipli +-------------------------------------------- + +La stessa classe di blocco non deve essere acquisita due volte, questo perché +potrebbe portare ad uno blocco ricorsivo e dunque ad uno stallo. + +Inoltre, due blocchi non possono essere trattenuti in ordine inverso:: + + -> + -> + +perché porterebbe ad uno stallo - chiamato stallo da blocco inverso - in cui si +cerca di trattenere i due blocchi in un ciclo in cui entrambe i contesti +aspettano per sempre che l'altro termini. Il validatore è in grado di trovare +queste dipendenze cicliche di qualsiasi complessità, ovvero nel mezzo ci +potrebbero essere altre sequenze di blocchi. Il validatore troverà se questi +blocchi possono essere acquisiti circolarmente. + +In aggiunta, le seguenti sequenze di blocco nei contesti indicati non sono +permesse, indipendentemente da quale che sia la classe di blocco:: + + -> + -> + +La prima regola deriva dal fatto che un blocco sicuro in interruzioni può essere +trattenuto in un contesto d'interruzione che, per definizione, ha la possibilità +di interrompere un blocco insicuro in interruzioni; questo porterebbe ad uno +stallo da blocco inverso. La seconda, analogamente, ci dice che un blocco sicuro +in interruzioni software potrebbe essere trattenuto in un contesto di +interruzione software, dunque potrebbe interrompere un blocco insicuro in +interruzioni software. + +Le suddette regole vengono applicate per qualsiasi sequenza di blocchi: quando +si acquisiscono nuovi blocchi, il validatore verifica se vi è una violazione +delle regole fra il nuovo blocco e quelli già trattenuti. + +Quando una classe di blocco cambia stato, applicheremo le seguenti regole: + +- se viene trovato un nuovo blocco sicuro in interruzioni, verificheremo se + abbia mai trattenuto dei blocchi insicuri in interruzioni. + +- se viene trovato un nuovo blocco sicuro in interruzioni software, + verificheremo se abbia trattenuto dei blocchi insicuri in interruzioni + software. + +- se viene trovato un nuovo blocco insicuro in interruzioni, verificheremo se + abbia trattenuto dei blocchi sicuri in interruzioni. + +- se viene trovato un nuovo blocco insicuro in interruzioni software, + verificheremo se abbia trattenuto dei blocchi sicuri in interruzioni + software. + +(Di nuovo, questi controlli vengono fatti perché un contesto d'interruzione +potrebbe interrompere l'esecuzione di qualsiasi blocco insicuro portando ad uno +stallo; questo anche se lo stallo non si verifica in pratica) + +Eccezione: dipendenze annidate sui dati portano a blocchi annidati +------------------------------------------------------------------ + +Ci sono alcuni casi in cui il kernel Linux acquisisce più volte la stessa +istanza di una classe di blocco. Solitamente, questo succede quando esiste una +gerarchia fra oggetti dello stesso tipo. In questi casi viene ereditato +implicitamente l'ordine fra i due oggetti (definito dalle proprietà di questa +gerarchia), ed il kernel tratterrà i blocchi in questo ordine prefissato per +ognuno degli oggetti. + +Un esempio di questa gerarchia di oggetti che producono "blocchi annidati" sono +i *block-dev* che rappresentano l'intero disco e quelli che rappresentano una +sua partizione; la partizione è una parte del disco intero, e l'ordine dei +blocchi sarà corretto fintantoche uno acquisisce il blocco del disco intero e +poi quello della partizione. Il validatore non rileva automaticamente questo +ordine implicito, perché queste regole di sincronizzazione non sono statiche. + +Per istruire il validatore riguardo a questo uso corretto dei blocchi sono stati +introdotte nuove primitive per specificare i "livelli di annidamento". Per +esempio, per i blocchi a mutua esclusione dei *block-dev* si avrebbe una +chiamata simile a:: + + enum bdev_bd_mutex_lock_class + { + BD_MUTEX_NORMAL, + BD_MUTEX_WHOLE, + BD_MUTEX_PARTITION + }; + + mutex_lock_nested(&bdev->bd_contains->bd_mutex, BD_MUTEX_PARTITION); + +In questo caso la sincronizzazione viene fatta su un *block-dev* sapendo che si +tratta di una partizione. + +Ai fini della validazione, il validatore lo considererà con una - sotto - classe +di blocco separata. + +Nota: Prestate estrema attenzione che la vostra gerarchia sia corretta quando si +vogliono usare le primitive _nested(); altrimenti potreste avere sia falsi +positivi che falsi negativi. + +Annotazioni +----------- + +Si possono utilizzare due costrutti per verificare ed annotare se certi blocchi +devono essere trattenuti: lockdep_assert_held*(&lock) e +lockdep_*pin_lock(&lock). + +Come suggerito dal nome, la famiglia di macro lockdep_assert_held* asseriscono +che un dato blocco in un dato momento deve essere trattenuto (altrimenti, verrà +generato un WARN()). Queste vengono usate abbondantemente nel kernel, per +esempio in kernel/sched/core.c:: + + void update_rq_clock(struct rq *rq) + { + s64 delta; + + lockdep_assert_held(&rq->lock); + [...] + } + +dove aver trattenuto rq->lock è necessario per aggiornare in sicurezza il clock +rq. + +L'altra famiglia di macro è lockdep_*pin_lock(), che a dire il vero viene usata +solo per rq->lock ATM. Se per caso un blocco non viene trattenuto, queste +genereranno un WARN(). Questo si rivela particolarmente utile quando si deve +verificare la correttezza di codice con *callback*, dove livelli superiori +potrebbero assumere che un blocco rimanga trattenuto, ma livelli inferiori +potrebbero invece pensare che il blocco possa essere rilasciato e poi +riacquisito (involontariamente si apre una sezione critica). lockdep_pin_lock() +restituisce 'struct pin_cookie' che viene usato da lockdep_unpin_lock() per +verificare che nessuno abbia manomesso il blocco. Per esempio in +kernel/sched/sched.h abbiamo:: + + static inline void rq_pin_lock(struct rq *rq, struct rq_flags *rf) + { + rf->cookie = lockdep_pin_lock(&rq->lock); + [...] + } + + static inline void rq_unpin_lock(struct rq *rq, struct rq_flags *rf) + { + [...] + lockdep_unpin_lock(&rq->lock, rf->cookie); + } + +I commenti riguardo alla sincronizzazione possano fornire informazioni utili, +tuttavia sono le verifiche in esecuzione effettuate da queste macro ad essere +vitali per scovare problemi di sincronizzazione, ed inoltre forniscono lo stesso +livello di informazioni quando si ispeziona il codice. Nel dubbio, preferite +queste annotazioni! + +Dimostrazione di correttezza al 100% +------------------------------------ + +Il validatore verifica la proprietà di chiusura in senso matematico. Ovvero, per +ogni sequenza di sincronizzazione di un singolo processo che si verifichi almeno +una volta nel kernel, il validatore dimostrerà con una certezza del 100% che +nessuna combinazione e tempistica di queste sequenze possa causare uno stallo in +una qualsiasi classe di blocco. [1]_ + +In pratica, per dimostrare l'esistenza di uno stallo non servono complessi +scenari di sincronizzazione multi-processore e multi-processo. Il validatore può +dimostrare la correttezza basandosi sulla sola sequenza di sincronizzazione +apparsa almeno una volta (in qualunque momento, in qualunque processo o +contesto). Uno scenario complesso che avrebbe bisogno di 3 processori e una +sfortunata presenza di processi, interruzioni, e pessimo tempismo, può essere +riprodotto su un sistema a singolo processore. + +Questo riduce drasticamente la complessità del controllo di qualità della +sincronizzazione nel kernel: quello che deve essere fatto è di innescare nel +kernel quante più possibili "semplici" sequenze di sincronizzazione, almeno una +volta, allo scopo di dimostrarne la correttezza. Questo al posto di innescare +una verifica per ogni possibile combinazione di sincronizzazione fra processori, +e differenti scenari con hardirq e softirq e annidamenti vari (nella pratica, +impossibile da fare) + +.. [1] + + assumendo che il validatore sia corretto al 100%, e che nessun altra parte + del sistema possa corromperne lo stato. Assumiamo anche che tutti i percorsi + MNI/SMM [potrebbero interrompere anche percorsi dove le interruzioni sono + disabilitate] sono corretti e non interferiscono con il validatore. Inoltre, + assumiamo che un hash a 64-bit sia unico per ogni sequenza di + sincronizzazione nel sistema. Infine, la ricorsione dei blocchi non deve + essere maggiore di 20. + +Prestazione +----------- + +Le regole sopracitate hanno bisogno di una quantità **enorme** di verifiche +durante l'esecuzione. Il sistema sarebbe diventato praticamente inutilizzabile +per la sua lentezza se le avessimo fatte davvero per ogni blocco trattenuto e +per ogni abilitazione delle interruzioni. La complessità della verifica è +O(N^2), quindi avremmo dovuto fare decine di migliaia di verifiche per ogni +evento, il tutto per poche centinaia di classi. + +Il problema è stato risolto facendo una singola verifica per ogni 'scenario di +sincronizzazione' (una sequenza unica di blocchi trattenuti uno dopo l'altro). +Per farlo, viene mantenuta una pila dei blocchi trattenuti, e viene calcolato un +hash a 64-bit unico per ogni sequenza. Quando la sequenza viene verificata per +la prima volta, l'hash viene inserito in una tabella hash. La tabella potrà +essere verificata senza bisogno di blocchi. Se la sequenza dovesse ripetersi, la +tabella ci dirà che non è necessario verificarla nuovamente. + +Risoluzione dei problemi +------------------------ + +Il massimo numero di classi di blocco che il validatore può tracciare è: +MAX_LOCKDEP_KEYS. Oltrepassare questo limite indurrà lokdep a generare il +seguente avviso:: + + (DEBUG_LOCKS_WARN_ON(id >= MAX_LOCKDEP_KEYS)) + +Di base questo valore è 8191, e un classico sistema da ufficio ha meno di 1000 +classi, dunque questo avviso è solitamente la conseguenza di un problema di +perdita delle classi di blocco o d'inizializzazione dei blocchi. Di seguito una +descrizione dei due problemi: + +1. caricare e rimuovere continuamente i moduli mentre il validatore è in + esecuzione porterà ad una perdita di classi di blocco. Il problema è che ogni + caricamento crea un nuovo insieme di classi di blocco per tutti i blocchi di + quel modulo. Tuttavia, la rimozione del modulo non rimuove le vecchie classi + (vedi dopo perché non le riusiamo). Dunque, il continuo caricamento e + rimozione di un modulo non fa altro che aumentare il contatore di classi fino + a raggiungere, eventualmente, il limite. + +2. Usare array con un gran numero di blocchi che non vengono esplicitamente + inizializzati. Per esempio, una tabella hash con 8192 *bucket* dove ognuno ha + il proprio spinlock_t consumerà 8192 classi di blocco a meno che non vengano + esplicitamente inizializzati in esecuzione usando spin_lock_init() invece + dell'inizializzazione durante la compilazione con __SPIN_LOCK_UNLOCKED(). + Sbagliare questa inizializzazione garantisce un esaurimento di classi di + blocco. Viceversa, un ciclo che invoca spin_lock_init() su tutti i blocchi li + mapperebbe tutti alla stessa classe di blocco. + + La morale della favola è che dovete sempre inizializzare esplicitamente i + vostri blocchi. + +Qualcuno potrebbe argomentare che il validatore debba permettere il riuso di +classi di blocco. Tuttavia, se siete tentati dall'argomento, prima revisionate +il codice e pensate alla modifiche necessarie, e tenendo a mente che le classi +di blocco da rimuovere probabilmente sono legate al grafo delle dipendenze. Più +facile a dirsi che a farsi. + +Ovviamente, se non esaurite le classi di blocco, la prossima cosa da fare è +quella di trovare le classi non funzionanti. Per prima cosa, il seguente comando +ritorna il numero di classi attualmente in uso assieme al valore massimo:: + + grep "lock-classes" /proc/lockdep_stats + +Questo comando produce il seguente messaggio:: + + lock-classes: 748 [max: 8191] + +Se il numero di assegnazioni (748 qui sopra) aumenta continuamente nel tempo, +allora c'è probabilmente un problema da qualche parte. Il seguente comando può +essere utilizzato per identificare le classi di blocchi problematiche:: + + grep "BD" /proc/lockdep + +Eseguite il comando e salvatene l'output, quindi confrontatelo con l'output di +un'esecuzione successiva per identificare eventuali problemi. Questo stesso +output può anche aiutarti a trovare situazioni in cui l'inizializzazione del +blocco è stata omessa. + +Lettura ricorsiva dei blocchi +----------------------------- + +Il resto di questo documento vuole dimostrare che certi cicli equivalgono ad una +possibilità di stallo. + +Ci sono tre tipi di bloccatori: gli scrittori (bloccatori esclusivi, come +spin_lock() o write_lock()), lettori non ricorsivi (bloccatori condivisi, come +down_read()), e lettori ricorsivi (bloccatori condivisi ricorsivi, come +rcu_read_lock()). D'ora in poi, per questi tipi di bloccatori, useremo la +seguente notazione: + + W o E: per gli scrittori (bloccatori esclusivi) (W dall'inglese per + *Writer*, ed E per *Exclusive*). + + r: per i lettori non ricorsivi (r dall'inglese per *reader*). + + R: per i lettori ricorsivi (R dall'inglese per *Reader*). + + S: per qualsiasi lettore (non ricorsivi + ricorsivi), dato che entrambe + sono bloccatori condivisi (S dall'inglese per *Shared*). + + N: per gli scrittori ed i lettori non ricorsivi, dato che entrambe sono + non ricorsivi. + +Ovviamente, N equivale a "r o W" ed S a "r o R". + +Come suggerisce il nome, i lettori ricorsivi sono dei bloccatori a cui è +permesso di acquisire la stessa istanza di blocco anche all'interno della +sezione critica di un altro lettore. In altre parole, permette di annidare la +stessa istanza di blocco nelle sezioni critiche dei lettori. + +Dall'altro canto, lo stesso comportamento indurrebbe un lettore non ricorsivo ad +auto infliggersi uno stallo. + +La differenza fra questi due tipi di lettori esiste perché: quelli ricorsivi +vengono bloccati solo dal trattenimento di un blocco di scrittura, mentre quelli +non ricorsivi possono essere bloccati dall'attesa di un blocco di scrittura. +Consideriamo il seguente esempio:: + + TASK A: TASK B: + + read_lock(X); + write_lock(X); + read_lock_2(X); + +L'attività A acquisisce il blocco di lettura X (non importa se di tipo ricorsivo +o meno) usando read_lock(). Quando l'attività B tenterà di acquisire il blocco +X, si fermerà e rimarrà in attesa che venga rilasciato. Ora se read_lock_2() è +un tipo lettore ricorsivo, l'attività A continuerà perché gli scrittori in +attesa non possono bloccare lettori ricorsivi, e non avremo alcuno stallo. +Tuttavia, se read_lock_2() è un lettore non ricorsivo, allora verrà bloccato +dall'attività B e si causerà uno stallo. + +Condizioni bloccanti per lettori/scrittori su uno stesso blocco +--------------------------------------------------------------- +Essenzialmente ci sono quattro condizioni bloccanti: + +1. Uno scrittore blocca un altro scrittore. +2. Un lettore blocca uno scrittore. +3. Uno scrittore blocca sia i lettori ricorsivi che non ricorsivi. +4. Un lettore (ricorsivo o meno) non blocca altri lettori ricorsivi ma potrebbe + bloccare quelli non ricorsivi (perché potrebbero esistere degli scrittori in + attesa). + +Di seguito le tabella delle condizioni bloccanti, Y (*Yes*) significa che il +tipo in riga blocca quello in colonna, mentre N l'opposto. + + +---+---+---+---+ + | | W | r | R | + +---+---+---+---+ + | W | Y | Y | Y | + +---+---+---+---+ + | r | Y | Y | N | + +---+---+---+---+ + | R | Y | Y | N | + +---+---+---+---+ + + (W: scrittori, r: lettori non ricorsivi, R: lettori ricorsivi) + +Al contrario dei blocchi per lettori non ricorsivi, quelli ricorsivi vengono +trattenuti da chi trattiene il blocco di scrittura piuttosto che da chi ne +attende il rilascio. Per esempio:: + + TASK A: TASK B: + + read_lock(X); + + write_lock(X); + + read_lock(X); + +non produce uno stallo per i lettori ricorsivi, in quanto il processo B rimane +in attesta del blocco X, mentre il secondo read_lock() non ha bisogno di +aspettare perché si tratta di un lettore ricorsivo. Tuttavia, se read_lock() +fosse un lettore non ricorsivo, questo codice produrrebbe uno stallo. + +Da notare che in funzione dell'operazione di blocco usate per l'acquisizione (in +particolare il valore del parametro 'read' in lock_acquire()), un blocco può +essere di scrittura (blocco esclusivo), di lettura non ricorsivo (blocco +condiviso e non ricorsivo), o di lettura ricorsivo (blocco condiviso e +ricorsivo). In altre parole, per un'istanza di blocco esistono tre tipi di +acquisizione che dipendono dalla funzione di acquisizione usata: esclusiva, di +lettura non ricorsiva, e di lettura ricorsiva. + +In breve, chiamiamo "non ricorsivi" blocchi di scrittura e quelli di lettura non +ricorsiva, mentre "ricorsivi" i blocchi di lettura ricorsivi. + +I blocchi ricorsivi non si bloccano a vicenda, mentre quelli non ricorsivi sì +(anche in lettura). Un blocco di lettura non ricorsivi può bloccare uno +ricorsivo, e viceversa. + +Il seguente esempio mostra uno stallo con blocchi ricorsivi:: + + TASK A: TASK B: + + read_lock(X); + read_lock(Y); + write_lock(Y); + write_lock(X); + +Il processo A attende che il processo B esegua read_unlock() so Y, mentre il +processo B attende che A esegua read_unlock() su X. + +Tipi di dipendenze e percorsi forti +----------------------------------- +Le dipendenze fra blocchi tracciano l'ordine con cui una coppia di blocchi viene +acquisita, e perché vi sono 3 tipi di bloccatori, allora avremo 9 tipi di +dipendenze. Tuttavia, vi mostreremo che 4 sono sufficienti per individuare gli +stalli. + +Per ogni dipendenza fra blocchi avremo:: + + L1 -> L2 + +Questo significa che lockdep ha visto acquisire L1 prima di L2 nello stesso +contesto di esecuzione. Per quanto riguarda l'individuazione degli stalli, ci +interessa sapere se possiamo rimanere bloccati da L2 mentre L1 viene trattenuto. +In altre parole, vogliamo sapere se esiste un bloccatore L3 che viene bloccato +da L1 e un L2 che viene bloccato da L3. Dunque, siamo interessati a (1) quello +che L1 blocca e (2) quello che blocca L2. Di conseguenza, possiamo combinare +lettori ricorsivi e non per L1 (perché bloccano gli stessi tipi) e possiamo +combinare scrittori e lettori non ricorsivi per L2 (perché vengono bloccati +dagli stessi tipi). + +Con questa semplificazione, possiamo dedurre che ci sono 4 tipi di rami nel +grafo delle dipendenze di lockdep: + +1) -(ER)->: + dipendenza da scrittore esclusivo a lettore ricorsivo. "X -(ER)-> Y" + significa X -> Y, dove X è uno scrittore e Y un lettore ricorsivo. + +2) -(EN)->: + dipendenza da scrittore esclusivo a bloccatore non ricorsivo. + "X -(EN)->" significa X-> Y, dove X è uno scrittore e Y può essere + o uno scrittore o un lettore non ricorsivo. + +3) -(SR)->: + dipendenza da lettore condiviso a lettore ricorsivo. "X -(SR)->" + significa X -> Y, dove X è un lettore (ricorsivo o meno) e Y è un + lettore ricorsivo. + +4) -(SN)->: + dipendenza da lettore condiviso a bloccatore non ricorsivo. + "X -(SN)-> Y" significa X -> Y , dove X è un lettore (ricorsivo + o meno) e Y può essere o uno scrittore o un lettore non ricorsivo. + +Da notare che presi due blocchi, questi potrebbero avere più dipendenza fra di +loro. Per esempio:: + + TASK A: + + read_lock(X); + write_lock(Y); + ... + + TASK B: + + write_lock(X); + write_lock(Y); + +Nel grafo delle dipendenze avremo sia X -(SN)-> Y che X -(EN)-> Y. + +Usiamo -(xN)-> per rappresentare i rami sia per -(EN)-> che -(SN)->, allo stesso +modo -(Ex)->, -(xR)-> e -(Sx)-> + +Un "percorso" in un grafo è una serie di nodi e degli archi che li congiungono. +Definiamo un percorso "forte", come il percorso che non ha archi (dipendenze) di +tipo -(xR)-> e -(Sx)->. In altre parole, un percorso "forte" è un percorso da un +blocco ad un altro attraverso le varie dipendenze, e se sul percorso abbiamo X +-> Y -> Z (dove X, Y, e Z sono blocchi), e da X a Y si ha una dipendenza -(SR)-> +o -(ER)->, allora fra Y e Z non deve esserci una dipendenza -(SN)-> o -(SR)->. + +Nella prossima sezione vedremo perché definiamo questo percorso "forte". + +Identificazione di stalli da lettura ricorsiva +---------------------------------------------- +Ora vogliamo dimostrare altre due cose: + +Lemma 1: + +Se esiste un percorso chiuso forte (ciclo forte), allora esiste anche una +combinazione di sequenze di blocchi che causa uno stallo. In altre parole, +l'esistenza di un ciclo forte è sufficiente alla scoperta di uno stallo. + +Lemma 2: + +Se non esiste un percorso chiuso forte (ciclo forte), allora non esiste una +combinazione di sequenze di blocchi che causino uno stallo. In altre parole, i +cicli forti sono necessari alla rilevazione degli stallo. + +Con questi due lemmi possiamo facilmente affermare che un percorso chiuso forte +è sia sufficiente che necessario per avere gli stalli, dunque averli equivale +alla possibilità di imbattersi concretamente in uno stallo. Un percorso chiuso +forte significa che può causare stalli, per questo lo definiamo "forte", ma ci +sono anche cicli di dipendenze che non causeranno stalli. + +Dimostrazione di sufficienza (lemma 1): + +Immaginiamo d'avere un ciclo forte:: + + L1 -> L2 ... -> Ln -> L1 + +Questo significa che abbiamo le seguenti dipendenze:: + + L1 -> L2 + L2 -> L3 + ... + Ln-1 -> Ln + Ln -> L1 + +Ora possiamo costruire una combinazione di sequenze di blocchi che causano lo +stallo. + +Per prima cosa facciamo sì che un processo/processore prenda L1 in L1 -> L2, poi +un altro prende L2 in L2 -> L3, e così via. Alla fine, tutti i Lx in Lx -> Lx+1 +saranno trattenuti da processi/processori diversi. + +Poi visto che abbiamo L1 -> L2, chi trattiene L1 vorrà acquisire L2 in L1 -> L2, +ma prima dovrà attendere che venga rilasciato da chi lo trattiene. Questo perché +L2 è già trattenuto da un altro processo/processore, ed in più L1 -> L2 e L2 -> +L3 non sono -(xR)-> né -(Sx)-> (la definizione di forte). Questo significa che L2 +in L1 -> L2 non è un bloccatore non ricorsivo (bloccabile da chiunque), e L2 in +L2 -> L3 non è uno scrittore (che blocca chiunque). + +In aggiunta, possiamo trarre una simile conclusione per chi sta trattenendo L2: +deve aspettare che L3 venga rilasciato, e così via. Ora possiamo dimostrare che +chi trattiene Lx deve aspettare che Lx+1 venga rilasciato. Notiamo che Ln+1 è +L1, dunque si è creato un ciclo dal quale non possiamo uscire, quindi si ha uno +stallo. + +Dimostrazione della necessità (lemma 2): + +Questo lemma equivale a dire che: se siamo in uno scenario di stallo, allora +deve esiste un ciclo forte nel grafo delle dipendenze. + +Secondo Wikipedia[1], se c'è uno stallo, allora deve esserci un ciclo di attese, +ovvero ci sono N processi/processori dove P1 aspetta un blocco trattenuto da P2, +e P2 ne aspetta uno trattenuto da P3, ... e Pn attende che il blocco P1 venga +rilasciato. Chiamiamo Lx il blocco che attende Px, quindi P1 aspetta L1 e +trattiene Ln. Quindi avremo Ln -> L1 nel grafo delle dipendenze. Similarmente, +nel grafo delle dipendenze avremo L1 -> L2, L2 -> L3, ..., Ln-1 -> Ln, il che +significa che abbiamo un ciclo:: + + Ln -> L1 -> L2 -> ... -> Ln + +, ed ora dimostriamo d'avere un ciclo forte. + +Per un blocco Lx, il processo Px contribuisce alla dipendenza Lx-1 -> Lx e Px+1 +contribuisce a quella Lx -> Lx+1. Visto che Px aspetta che Px+1 rilasci Lx, sarà +impossibile che Lx in Px+1 sia un lettore e che Lx in Px sia un lettore +ricorsivo. Questo perché i lettori (ricorsivi o meno) non bloccano lettori +ricorsivi. Dunque, Lx-1 -> Lx e Lx -> Lx+1 non possono essere una coppia di +-(xR)-> -(Sx)->. Questo è vero per ogni ciclo, dunque, questo è un ciclo forte. + +Riferimenti +----------- + +[1]: https://it.wikipedia.org/wiki/Stallo_(informatica) + +[2]: Shibu, K. (2009). Intro To Embedded Systems (1st ed.). Tata McGraw-Hill diff --git a/Documentation/translations/it_IT/locking/lockstat.rst b/Documentation/translations/it_IT/locking/lockstat.rst new file mode 100644 index 000000000000..77972d971d7c --- /dev/null +++ b/Documentation/translations/it_IT/locking/lockstat.rst @@ -0,0 +1,230 @@ +.. SPDX-License-Identifier: GPL-2.0 + +.. include:: ../disclaimer-ita.rst + +======================= +Statistiche sui blocchi +======================= + +Cosa +==== + +Come suggerisce il nome, fornisce statistiche sui blocchi. + + +Perché +====== + +Perché, tanto per fare un esempio, le contese sui blocchi possono influenzare +significativamente le prestazioni. + +Come +==== + +*Lockdep* ha punti di collegamento nelle funzioni di blocco e inoltre +mappa le istanze di blocco con le relative classi. Partiamo da questo punto +(vedere Documentation/translations/it_IT/locking/lockdep-design.rst). +Il grafico sottostante mostra la relazione che intercorre fra le +funzioni di blocco e i vari punti di collegamenti che ci sono al loro +interno:: + + __acquire + | + lock _____ + | \ + | __contended + | | + | + | _______/ + |/ + | + __acquired + | + . + + . + | + __release + | + unlock + + lock, unlock - le classiche funzioni di blocco + __* - i punti di collegamento + <> - stati + +Grazie a questi punti di collegamento possiamo fornire le seguenti statistiche: + +con-bounces + - numero di contese su un blocco che riguarda dati di un processore + +contentions + - numero di acquisizioni di blocchi che hanno dovuto attendere + +wait time + min + - tempo minimo (diverso da zero) che sia mai stato speso in attesa di + un blocco + + max + - tempo massimo che sia mai stato speso in attesa di un blocco + + total + - tempo totale speso in attesa di un blocco + + avg + - tempo medio speso in attesa di un blocco + +acq-bounces + - numero di acquisizioni di blocco che riguardavano i dati su un processore + +acquisitions + - numero di volte che un blocco è stato ottenuto + +hold time + min + - tempo minimo (diverso da zero) che sia mai stato speso trattenendo un blocco + + max + - tempo massimo che sia mai stato speso trattenendo un blocco + + total + - tempo totale di trattenimento di un blocco + + avg + - tempo medio di trattenimento di un blocco + +Questi numeri vengono raccolti per classe di blocco, e per ogni stato di +lettura/scrittura (quando applicabile). + +Inoltre, questa raccolta di statistiche tiene traccia di 4 punti di contesa +per classe di blocco. Un punto di contesa è una chiamata che ha dovuto +aspettare l'acquisizione di un blocco. + +Configurazione +-------------- + +Le statistiche sui blocchi si abilitano usando l'opzione di configurazione +CONFIG_LOCK_STAT. + +Uso +--- + +Abilitare la raccolta di statistiche:: + + # echo 1 >/proc/sys/kernel/lock_stat + +Disabilitare la raccolta di statistiche:: + + # echo 0 >/proc/sys/kernel/lock_stat + +Per vedere le statistiche correnti sui blocchi:: + + ( i numeri di riga non fanno parte dell'output del comando, ma sono stati + aggiunti ai fini di questa spiegazione ) + + # less /proc/lock_stat + + 01 lock_stat version 0.4 + 02----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- + 03 class name con-bounces contentions waittime-min waittime-max waittime-total waittime-avg acq-bounces acquisitions holdtime-min holdtime-max holdtime-total holdtime-avg + 04----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- + 05 + 06 &mm->mmap_sem-W: 46 84 0.26 939.10 16371.53 194.90 47291 2922365 0.16 2220301.69 17464026916.32 5975.99 + 07 &mm->mmap_sem-R: 37 100 1.31 299502.61 325629.52 3256.30 212344 34316685 0.10 7744.91 95016910.20 2.77 + 08 --------------- + 09 &mm->mmap_sem 1 [] khugepaged_scan_mm_slot+0x57/0x280 + 10 &mm->mmap_sem 96 [] __do_page_fault+0x1d4/0x510 + 11 &mm->mmap_sem 34 [] vm_mmap_pgoff+0x87/0xd0 + 12 &mm->mmap_sem 17 [] vm_munmap+0x41/0x80 + 13 --------------- + 14 &mm->mmap_sem 1 [] dup_mmap+0x2a/0x3f0 + 15 &mm->mmap_sem 60 [] SyS_mprotect+0xe9/0x250 + 16 &mm->mmap_sem 41 [] __do_page_fault+0x1d4/0x510 + 17 &mm->mmap_sem 68 [] vm_mmap_pgoff+0x87/0xd0 + 18 + 19............................................................................................................................................................................................................................. + 20 + 21 unix_table_lock: 110 112 0.21 49.24 163.91 1.46 21094 66312 0.12 624.42 31589.81 0.48 + 22 --------------- + 23 unix_table_lock 45 [] unix_create1+0x16e/0x1b0 + 24 unix_table_lock 47 [] unix_release_sock+0x31/0x250 + 25 unix_table_lock 15 [] unix_find_other+0x117/0x230 + 26 unix_table_lock 5 [] unix_autobind+0x11f/0x1b0 + 27 --------------- + 28 unix_table_lock 39 [] unix_release_sock+0x31/0x250 + 29 unix_table_lock 49 [] unix_create1+0x16e/0x1b0 + 30 unix_table_lock 20 [] unix_find_other+0x117/0x230 + 31 unix_table_lock 4 [] unix_autobind+0x11f/0x1b0 + +Questo estratto mostra le statistiche delle prime due classi di +blocco. La riga 01 mostra la versione dell'output - la versione +cambierà ogni volta che cambia il formato. Le righe dalla 02 alla 04 +rappresentano l'intestazione con la descrizione delle colonne. Le +statistiche sono mostrate nelle righe dalla 05 alla 18 e dalla 20 +alla 31. Queste statistiche sono divise in due parti: le statistiche, +seguite dai punti di contesa (righe 08 e 13) separati da un divisore. + +Le righe dalla 09 alla 12 mostrano i primi quattro punti di contesa +registrati (il codice che tenta di acquisire un blocco) e le righe +dalla 14 alla 17 mostrano i primi quattro punti contesi registrati +(ovvero codice che ha acquisito un blocco). È possibile che nelle +statistiche manchi il valore *max con-bounces*. + +Il primo blocco (righe dalla 05 alla 18) è di tipo lettura/scrittura e quindi +mostra due righe prima del divisore. I punti di contesa non corrispondono alla +descrizione delle colonne nell'intestazione; essi hanno due colonne: *punti di +contesa* e *[] simboli*. Il secondo gruppo di punti di contesa sono i punti +con cui si contende il blocco. + +La parte interna del tempo è espressa in us (microsecondi). + +Quando si ha a che fare con blocchi annidati si potrebbero vedere le +sottoclassi di blocco:: + + 32........................................................................................................................................................................................................................... + 33 + 34 &rq->lock: 13128 13128 0.43 190.53 103881.26 7.91 97454 3453404 0.00 401.11 13224683.11 3.82 + 35 --------- + 36 &rq->lock 645 [] task_rq_lock+0x43/0x75 + 37 &rq->lock 297 [] try_to_wake_up+0x127/0x25a + 38 &rq->lock 360 [] select_task_rq_fair+0x1f0/0x74a + 39 &rq->lock 428 [] scheduler_tick+0x46/0x1fb + 40 --------- + 41 &rq->lock 77 [] task_rq_lock+0x43/0x75 + 42 &rq->lock 174 [] try_to_wake_up+0x127/0x25a + 43 &rq->lock 4715 [] double_rq_lock+0x42/0x54 + 44 &rq->lock 893 [] schedule+0x157/0x7b8 + 45 + 46........................................................................................................................................................................................................................... + 47 + 48 &rq->lock/1: 1526 11488 0.33 388.73 136294.31 11.86 21461 38404 0.00 37.93 109388.53 2.84 + 49 ----------- + 50 &rq->lock/1 11526 [] double_rq_lock+0x4f/0x54 + 51 ----------- + 52 &rq->lock/1 5645 [] double_rq_lock+0x42/0x54 + 53 &rq->lock/1 1224 [] schedule+0x157/0x7b8 + 54 &rq->lock/1 4336 [] double_rq_lock+0x4f/0x54 + 55 &rq->lock/1 181 [] try_to_wake_up+0x127/0x25a + +La riga 48 mostra le statistiche per la seconda sottoclasse (/1) della +classe *&irq->lock* (le sottoclassi partono da 0); in questo caso, +come suggerito dalla riga 50, ``double_rq_lock`` tenta di acquisire un blocco +annidato di due spinlock. + +Per vedere i blocco più contesi:: + + # grep : /proc/lock_stat | head + clockevents_lock: 2926159 2947636 0.15 46882.81 1784540466.34 605.41 3381345 3879161 0.00 2260.97 53178395.68 13.71 + tick_broadcast_lock: 346460 346717 0.18 2257.43 39364622.71 113.54 3642919 4242696 0.00 2263.79 49173646.60 11.59 + &mapping->i_mmap_mutex: 203896 203899 3.36 645530.05 31767507988.39 155800.21 3361776 8893984 0.17 2254.15 14110121.02 1.59 + &rq->lock: 135014 136909 0.18 606.09 842160.68 6.15 1540728 10436146 0.00 728.72 17606683.41 1.69 + &(&zone->lru_lock)->rlock: 93000 94934 0.16 59.18 188253.78 1.98 1199912 3809894 0.15 391.40 3559518.81 0.93 + tasklist_lock-W: 40667 41130 0.23 1189.42 428980.51 10.43 270278 510106 0.16 653.51 3939674.91 7.72 + tasklist_lock-R: 21298 21305 0.20 1310.05 215511.12 10.12 186204 241258 0.14 1162.33 1179779.23 4.89 + rcu_node_1: 47656 49022 0.16 635.41 193616.41 3.95 844888 1865423 0.00 764.26 1656226.96 0.89 + &(&dentry->d_lockref.lock)->rlock: 39791 40179 0.15 1302.08 88851.96 2.21 2790851 12527025 0.10 1910.75 3379714.27 0.27 + rcu_node_0: 29203 30064 0.16 786.55 1555573.00 51.74 88963 244254 0.00 398.87 428872.51 1.76 + +Per cancellare le statistiche:: + + # echo 0 > /proc/lock_stat diff --git a/Documentation/translations/it_IT/locking/locktorture.rst b/Documentation/translations/it_IT/locking/locktorture.rst new file mode 100644 index 000000000000..87a0dbeaca77 --- /dev/null +++ b/Documentation/translations/it_IT/locking/locktorture.rst @@ -0,0 +1,181 @@ +.. SPDX-License-Identifier: GPL-2.0 + +.. include:: ../disclaimer-ita.rst + +============================================ +Funzionamento del test *Kernel Lock Torture* +============================================ + +CONFIG_LOCK_TORTURE_TEST +======================== + +L'opzione di configurazione CONFIG_LOCK_TORTURE_TEST fornisce un +modulo kernel che esegue delle verifiche che *torturano* le primitive di +sincronizzazione del kernel. Se dovesse servire, il modulo kernel, +'locktorture', può essere generato successivamente su un kernel che +volete verificare. Periodicamente le verifiche stampano messaggi tramite +``printk()`` e che quindi possono essere letti tramite ``dmesg`` (magari +filtrate l'output con ``grep "torture"``). La verifica inizia quando +il modulo viene caricato e termina quando viene rimosso. Questo +programma si basa sulle modalità di verifica di RCU tramite rcutorture. + +Questa verifica consiste nella creazione di un certo numero di thread +del kernel che acquisiscono un blocco e lo trattengono per una certa +quantità di tempo così da simulare diversi comportamenti nelle sezioni +critiche. La quantità di contese su un blocco può essere simulata +allargando la sezione critica e/o creando più thread. + + +Parametri del modulo +==================== + +Questo modulo ha i seguenti parametri: + + +Specifici di locktorture +------------------------ + +nwriters_stress + Numero di thread del kernel che stresseranno l'acquisizione + esclusiva dei blocchi (scrittori). Il valore di base è il + doppio del numero di processori attivi presenti. + +nreaders_stress + Numero di thread del kernel che stresseranno l'acquisizione + condivisa dei blocchi (lettori). Il valore di base è lo stesso + di nwriters_stress. Se l'utente non ha specificato + nwriters_stress, allora entrambe i valori corrisponderanno + al numero di processori attivi presenti. + +torture_type + Tipo di blocco da verificare. Di base, solo gli spinlock + verranno verificati. Questo modulo può verificare anche + i seguenti tipi di blocchi: + + - "lock_busted": + Simula un'incorretta implementazione del + blocco. + + - "spin_lock": + coppie di spin_lock() e spin_unlock(). + + - "spin_lock_irq": + coppie di spin_lock_irq() e spin_unlock_irq(). + + - "rw_lock": + coppie di rwlock read/write lock() e unlock(). + + - "rw_lock_irq": + copie di rwlock read/write lock_irq() e + unlock_irq(). + + - "mutex_lock": + coppie di mutex_lock() e mutex_unlock(). + + - "rtmutex_lock": + coppie di rtmutex_lock() e rtmutex_unlock(). + Il kernel deve avere CONFIG_RT_MUTEXES=y. + + - "rwsem_lock": + coppie di semafori read/write down() e up(). + + +Generici dell'ambiente di sviluppo 'torture' (RCU + locking) +------------------------------------------------------------ + +shutdown_secs + Numero di secondi prima che la verifica termini e il sistema + venga spento. Il valore di base è zero, il che disabilita + la possibilità di terminare e spegnere. Questa funzionalità + può essere utile per verifiche automatizzate. + +onoff_interval + Numero di secondi fra ogni tentativo di esecuzione di + un'operazione casuale di CPU-hotplug. Di base è zero, il + che disabilita la funzionalità di CPU-hotplug. Nei kernel + con CONFIG_HOTPLUG_CPU=n, locktorture si rifiuterà, senza + dirlo, di effettuare una qualsiasi operazione di + CPU-hotplug indipendentemente dal valore specificato in + onoff_interval. + +onoff_holdoff + Numero di secondi da aspettare prima di iniziare le + operazioni di CPU-hotplug. Normalmente questo verrebbe + usato solamente quando locktorture è compilato come parte + integrante del kernel ed eseguito automaticamente all'avvio, + in questo caso è utile perché permette di non confondere + l'avvio con i processori che vanno e vengono. Questo + parametro è utile sono se CONFIG_HOTPLUG_CPU è abilitato. + +stat_interval + Numero di secondi fra una stampa (printk()) delle + statistiche e l'altra. Di base, locktorture riporta le + statistiche ogni 60 secondi. Impostando l'intervallo a 0 + ha l'effetto di stampare le statistiche -solo- quando il + modulo viene rimosso. + +stutter + Durata della verifica prima di effettuare una pausa di + eguale durata. Di base "stutter=5", quindi si eseguono + verifiche e pause di (circa) cinque secondi. + L'impostazione di "stutter=0" fa si che la verifica + venga eseguita continuamente senza fermarsi. + +shuffle_interval + Il numero di secondi per cui un thread debba mantenere + l'affinità con un sottoinsieme di processori, di base è + 3 secondi. Viene usato assieme a test_no_idle_hz. + +verbose + Abilita le stampe di debug, via printk(). Di base è + abilitato. Queste informazioni aggiuntive sono per la + maggior parte relative ad errori di alto livello e resoconti + da parte dell'struttura 'torture'. + + +Statistiche +=========== + +Le statistiche vengono stampate secondo il seguente formato:: + + spin_lock-torture: Writes: Total: 93746064 Max/Min: 0/0 Fail: 0 + (A) (B) (C) (D) (E) + + (A): tipo di lock sotto verifica -- parametro torture_type. + + (B): Numero di acquisizione del blocco in scrittura. Se si ha a che fare + con una primitiva di lettura/scrittura apparirà di seguito anche una + seconda voce "Reads" + + (C): Numero di volte che il blocco è stato acquisito + + (D): Numero minimo e massimo di volte che un thread ha fallito + nell'acquisire il blocco + + (E): valori true/false nel caso di errori durante l'acquisizione del blocco. + Questo dovrebbe dare un riscontro positivo -solo- se c'è un baco + nell'implementazione delle primitive di sincronizzazione. Altrimenti un + blocco non dovrebbe mai fallire (per esempio, spin_lock()). + Ovviamente lo stesso si applica per (C). Un semplice esempio è il tipo + "lock_busted". + +Uso +=== + +Il seguente script può essere utilizzato per verificare i blocchi:: + + #!/bin/sh + + modprobe locktorture + sleep 3600 + rmmod locktorture + dmesg | grep torture: + +L'output può essere manualmente ispezionato cercando il marcatore d'errore +"!!!". Ovviamente potreste voler creare degli script più elaborati che +verificano automaticamente la presenza di errori. Il comando "rmmod" forza la +stampa (usando printk()) di "SUCCESS", "FAILURE", oppure "RCU_HOTPLUG". I primi +due si piegano da soli, mentre l'ultimo indica che non stati trovati problemi di +sincronizzazione, tuttavia ne sono stati trovati in CPU-hotplug. + +Consultate anche: Documentation/translations/it_IT/RCU/torture.rst diff --git a/Documentation/translations/it_IT/locking/locktypes.rst b/Documentation/translations/it_IT/locking/locktypes.rst new file mode 100644 index 000000000000..1c7056283b9d --- /dev/null +++ b/Documentation/translations/it_IT/locking/locktypes.rst @@ -0,0 +1,547 @@ +.. SPDX-License-Identifier: GPL-2.0 + +.. include:: ../disclaimer-ita.rst + +.. _it_kernel_hacking_locktypes: + +======================================== +Tipologie di blocco e le loro istruzioni +======================================== + +Introduzione +============ + +Il kernel fornisce un certo numero di primitive di blocco che possiamo dividere +in tre categorie: + + - blocchi ad attesa con sospensione + - blocchi locali per CPU + - blocchi ad attesa attiva + +Questo documento descrive questi tre tipi e fornisce istruzioni su come +annidarli, ed usarli su kernel PREEMPT_RT. + +Categorie di blocchi +==================== + +Blocchi ad attesa con sospensione +--------------------------------- + +I blocchi ad attesa con sospensione possono essere acquisiti solo in un contesti +dov'è possibile la prelazione. + +Diverse implementazioni permettono di usare try_lock() anche in altri contesti, +nonostante ciò è bene considerare anche la sicurezza dei corrispondenti +unlock(). Inoltre, vanno prese in considerazione anche le varianti di *debug* +di queste primitive. Insomma, non usate i blocchi ad attesa con sospensioni in +altri contesti a meno che proprio non vi siano alternative. + +In questa categoria troviamo: + + - mutex + - rt_mutex + - semaphore + - rw_semaphore + - ww_mutex + - percpu_rw_semaphore + +Nei kernel con PREEMPT_RT, i seguenti blocchi sono convertiti in blocchi ad +attesa con sospensione: + + - local_lock + - spinlock_t + - rwlock_t + +Blocchi locali per CPU +---------------------- + + - local_lock + +Su kernel non-PREEMPT_RT, le funzioni local_lock gestiscono le primitive di +disabilitazione di prelazione ed interruzioni. Al contrario di altri meccanismi, +la disabilitazione della prelazione o delle interruzioni sono puri meccanismi +per il controllo della concorrenza su una CPU e quindi non sono adatti per la +gestione della concorrenza inter-CPU. + +Blocchi ad attesa attiva +------------------------ + + - raw_spinlcok_t + - bit spinlocks + + Nei kernel non-PREEMPT_RT, i seguenti blocchi sono ad attesa attiva: + + - spinlock_t + - rwlock_t + +Implicitamente, i blocchi ad attesa attiva disabilitano la prelazione e le +funzioni lock/unlock hanno anche dei suffissi per gestire il livello di +protezione: + + =================== ========================================================================= + _bh() disabilita / abilita *bottom halves* (interruzioni software) + _irq() disabilita / abilita le interruzioni + _irqsave/restore() salva e disabilita le interruzioni / ripristina ed attiva le interruzioni + =================== ========================================================================= + +Semantica del proprietario +========================== + +Eccetto i semafori, i sopracitati tipi di blocchi hanno tutti una semantica +molto stringente riguardo al proprietario di un blocco: + + Il contesto (attività) che ha acquisito il blocco deve rilasciarlo + +I semafori rw_semaphores hanno un'interfaccia speciale che permette anche ai non +proprietari del blocco di rilasciarlo per i lettori. + +rtmutex +======= + +I blocchi a mutua esclusione RT (*rtmutex*) sono un sistema a mutua esclusione +con supporto all'ereditarietà della priorità (PI). + +Questo meccanismo ha delle limitazioni sui kernel non-PREEMPT_RT dovuti alla +prelazione e alle sezioni con interruzioni disabilitate. + +Chiaramente, questo meccanismo non può avvalersi della prelazione su una sezione +dove la prelazione o le interruzioni sono disabilitate; anche sui kernel +PREEMPT_RT. Tuttavia, i kernel PREEMPT_RT eseguono la maggior parte delle +sezioni in contesti dov'è possibile la prelazione, specialmente in contesti +d'interruzione (anche software). Questa conversione permette a spinlock_t e +rwlock_t di essere implementati usando rtmutex. + +semaphore +========= + +La primitiva semaphore implementa un semaforo con contatore. + +I semafori vengono spesso utilizzati per la serializzazione e l'attesa, ma per +nuovi casi d'uso si dovrebbero usare meccanismi diversi, come mutex e +completion. + +semaphore e PREEMPT_RT +---------------------- + +I kernel PREEMPT_RT non cambiano l'implementazione di semaphore perché non hanno +un concetto di proprietario, dunque impediscono a PREEMPT_RT d'avere +l'ereditarietà della priorità sui semafori. Un proprietario sconosciuto non può +ottenere una priorità superiore. Di consequenza, bloccarsi sui semafori porta +all'inversione di priorità. + + +rw_semaphore +============ + +Il blocco rw_semaphore è un meccanismo che permette più lettori ma un solo scrittore. + +Sui kernel non-PREEMPT_RT l'implementazione è imparziale, quindi previene +l'inedia dei processi scrittori. + +Questi blocchi hanno una semantica molto stringente riguardo il proprietario, ma +offre anche interfacce speciali che permettono ai processi non proprietari di +rilasciare un processo lettore. Queste interfacce funzionano indipendentemente +dalla configurazione del kernel. + +rw_semaphore e PREEMPT_RT +------------------------- + +I kernel PREEMPT_RT sostituiscono i rw_semaphore con un'implementazione basata +su rt_mutex, e questo ne modifica l'imparzialità: + + Dato che uno scrittore rw_semaphore non può assicurare la propria priorità ai + suoi lettori, un lettore con priorità più bassa che ha subito la prelazione + continuerà a trattenere il blocco, quindi porta all'inedia anche gli scrittori + con priorità più alta. Per contro, dato che i lettori possono garantire la + propria priorità agli scrittori, uno scrittore a bassa priorità che subisce la + prelazione vedrà la propria priorità alzata finché non rilascerà il blocco, e + questo preverrà l'inedia dei processi lettori a causa di uno scrittore. + + +local_lock +========== + +I local_lock forniscono nomi agli ambiti di visibilità delle sezioni critiche +protette tramite la disattivazione della prelazione o delle interruzioni. + +Sui kernel non-PREEMPT_RT le operazioni local_lock si traducono +nell'abilitazione o disabilitazione della prelazione o le interruzioni. + + =============================== ====================== + local_lock(&llock) preempt_disable() + local_unlock(&llock) preempt_enable() + local_lock_irq(&llock) local_irq_disable() + local_unlock_irq(&llock) local_irq_enable() + local_lock_irqsave(&llock) local_irq_save() + local_unlock_irqrestore(&llock) local_irq_restore() + =============================== ====================== + +Gli ambiti di visibilità con nome hanno due vantaggi rispetto alle primitive di +base: + + - Il nome del blocco permette di fare un'analisi statica, ed è anche chiaro su + cosa si applichi la protezione cosa che invece non si può fare con le + classiche primitive in quanto sono opache e senza alcun ambito di + visibilità. + + - Se viene abilitato lockdep, allora local_lock ottiene un lockmap che + permette di verificare la bontà della protezione. Per esempio, questo può + identificare i casi dove una funzione usa preempt_disable() come meccanismo + di protezione in un contesto d'interruzione (anche software). A parte + questo, lockdep_assert_held(&llock) funziona come tutte le altre primitive + di sincronizzazione. + +local_lock e PREEMPT_RT +------------------------- + +I kernel PREEMPT_RT sostituiscono local_lock con uno spinlock_t per CPU, quindi +ne cambia la semantica: + + - Tutte le modifiche a spinlock_t si applicano anche a local_lock + +L'uso di local_lock +------------------- + +I local_lock dovrebbero essere usati su kernel non-PREEMPT_RT quando la +disabilitazione della prelazione o delle interruzioni è il modo più adeguato per +gestire l'accesso concorrente a strutture dati per CPU. + +Questo meccanismo non è adatto alla protezione da prelazione o interruzione su +kernel PREEMPT_RT dato che verrà convertito in spinlock_t. + + +raw_spinlock_t e spinlock_t +=========================== + +raw_spinlock_t +-------------- + +I blocco raw_spinlock_t è un blocco ad attesa attiva su tutti i tipi di kernel, +incluso quello PREEMPT_RT. Usate raw_spinlock_t solo in sezioni critiche nel +cuore del codice, nella gestione delle interruzioni di basso livello, e in posti +dove è necessario disabilitare la prelazione o le interruzioni. Per esempio, per +accedere in modo sicuro lo stato dell'hardware. A volte, i raw_spinlock_t +possono essere usati quando la sezione critica è minuscola, per evitare gli +eccessi di un rtmutex. + +spinlock_t +---------- + +Il significato di spinlock_t cambia in base allo stato di PREEMPT_RT. + +Sui kernel non-PREEMPT_RT, spinlock_t si traduce in un raw_spinlock_t ed ha +esattamente lo stesso significato. + +spinlock_t e PREEMPT_RT +----------------------- + +Sui kernel PREEMPT_RT, spinlock_t ha un'implementazione dedicata che si basa +sull'uso di rt_mutex. Questo ne modifica il significato: + + - La prelazione non viene disabilitata. + + - I suffissi relativi alla interruzioni (_irq, _irqsave / _irqrestore) per le + operazioni spin_lock / spin_unlock non hanno alcun effetto sullo stato delle + interruzioni della CPU. + + - I suffissi relativi alle interruzioni software (_bh()) disabilitano i + relativi gestori d'interruzione. + + I kernel non-PREEMPT_RT disabilitano la prelazione per ottenere lo stesso effetto. + + I kernel PREEMPT_RT usano un blocco per CPU per la serializzazione, il che + permette di tenere attiva la prelazione. Il blocco disabilita i gestori + d'interruzione software e previene la rientranza vista la prelazione attiva. + +A parte quanto appena discusso, i kernel PREEMPT_RT preservano il significato +di tutti gli altri aspetti di spinlock_t: + + - Le attività che trattengono un blocco spinlock_t non migrano su altri + processori. Disabilitando la prelazione, i kernel non-PREEMPT_RT evitano la + migrazione. Invece, i kernel PREEMPT_RT disabilitano la migrazione per + assicurarsi che i puntatori a variabili per CPU rimangano validi anche + quando un'attività subisce la prelazione. + + - Lo stato di un'attività si mantiene durante le acquisizioni del blocco al + fine di garantire che le regole basate sullo stato delle attività si possano + applicare a tutte le configurazioni del kernel. I kernel non-PREEMPT_RT + lasciano lo stato immutato. Tuttavia, la funzionalità PREEMPT_RT deve + cambiare lo stato se l'attività si blocca durante l'acquisizione. Dunque, + salva lo stato attuale prima di bloccarsi ed il rispettivo risveglio lo + ripristinerà come nell'esempio seguente:: + + task->state = TASK_INTERRUPTIBLE + lock() + block() + task->saved_state = task->state + task->state = TASK_UNINTERRUPTIBLE + schedule() + lock wakeup + task->state = task->saved_state + + Altri tipi di risvegli avrebbero impostato direttamente lo stato a RUNNING, + ma in questo caso non avrebbe funzionato perché l'attività deve rimanere + bloccata fintanto che il blocco viene trattenuto. Quindi, lo stato salvato + viene messo a RUNNING quando il risveglio di un non-blocco cerca di + risvegliare un'attività bloccata in attesa del rilascio di uno spinlock. Poi, + quando viene completata l'acquisizione del blocco, il suo risveglio + ripristinerà lo stato salvato, in questo caso a RUNNING:: + + task->state = TASK_INTERRUPTIBLE + lock() + block() + task->saved_state = task->state + task->state = TASK_UNINTERRUPTIBLE + schedule() + non lock wakeup + task->saved_state = TASK_RUNNING + + lock wakeup + task->state = task->saved_state + + Questo garantisce che il vero risveglio non venga perso. + +rwlock_t +======== + +Il blocco rwlock_t è un meccanismo che permette più lettori ma un solo scrittore. + +Sui kernel non-PREEMPT_RT questo è un blocco ad attesa e per i suoi suffissi si +applicano le stesse regole per spinlock_t. La sua implementazione è imparziale, +quindi previene l'inedia dei processi scrittori. + +rwlock_t e PREEMPT_RT +--------------------- + +Sui kernel PREEMPT_RT rwlock_t ha un'implementazione dedicata che si basa +sull'uso di rt_mutex. Questo ne modifica il significato: + + - Tutte le modifiche fatte a spinlock_t si applicano anche a rwlock_t. + + - Dato che uno scrittore rw_semaphore non può assicurare la propria priorità ai + suoi lettori, un lettore con priorità più bassa che ha subito la prelazione + continuerà a trattenere il blocco, quindi porta all'inedia anche gli + scrittori con priorità più alta. Per contro, dato che i lettori possono + garantire la propria priorità agli scrittori, uno scrittore a bassa priorità + che subisce la prelazione vedrà la propria priorità alzata finché non + rilascerà il blocco, e questo preverrà l'inedia dei processi lettori a causa + di uno scrittore. + + +Precisazioni su PREEMPT_RT +========================== + +local_lock su RT +---------------- + +Sui kernel PREEMPT_RT Ci sono alcune implicazioni dovute alla conversione di +local_lock in un spinlock_t. Per esempio, su un kernel non-PREEMPT_RT il +seguente codice funzionerà come ci si aspetta:: + + local_lock_irq(&local_lock); + raw_spin_lock(&lock); + +ed è equivalente a:: + + raw_spin_lock_irq(&lock); + +Ma su un kernel PREEMPT_RT questo codice non funzionerà perché local_lock_irq() +si traduce in uno spinlock_t per CPU che non disabilita né le interruzioni né la +prelazione. Il seguente codice funzionerà su entrambe i kernel con o senza +PREEMPT_RT:: + + local_lock_irq(&local_lock); + spin_lock(&lock); + +Un altro dettaglio da tenere a mente con local_lock è che ognuno di loro ha un +ambito di protezione ben preciso. Dunque, la seguente sostituzione è errate:: + + + func1() + { + local_irq_save(flags); -> local_lock_irqsave(&local_lock_1, flags); + func3(); + local_irq_restore(flags); -> local_unlock_irqrestore(&local_lock_1, flags); + } + + func2() + { + local_irq_save(flags); -> local_lock_irqsave(&local_lock_2, flags); + func3(); + local_irq_restore(flags); -> local_unlock_irqrestore(&local_lock_2, flags); + } + + func3() + { + lockdep_assert_irqs_disabled(); + access_protected_data(); + } + +Questo funziona correttamente su un kernel non-PREEMPT_RT, ma su un kernel +PREEMPT_RT local_lock_1 e local_lock_2 sono distinti e non possono serializzare +i chiamanti di func3(). L'*assert* di lockdep verrà attivato su un kernel +PREEMPT_RT perché local_lock_irqsave() non disabilita le interruzione a casa +della specifica semantica di spinlock_t in PREEMPT_RT. La corretta sostituzione +è:: + + func1() + { + local_irq_save(flags); -> local_lock_irqsave(&local_lock, flags); + func3(); + local_irq_restore(flags); -> local_unlock_irqrestore(&local_lock, flags); + } + + func2() + { + local_irq_save(flags); -> local_lock_irqsave(&local_lock, flags); + func3(); + local_irq_restore(flags); -> local_unlock_irqrestore(&local_lock, flags); + } + + func3() + { + lockdep_assert_held(&local_lock); + access_protected_data(); + } + +spinlock_t e rwlock_t +--------------------- + +Ci sono alcune conseguenze di cui tener conto dal cambiamento di semantica di +spinlock_t e rwlock_t sui kernel PREEMPT_RT. Per esempio, sui kernel non +PREEMPT_RT il seguente codice funziona come ci si aspetta:: + + local_irq_disable(); + spin_lock(&lock); + +ed è equivalente a:: + + spin_lock_irq(&lock); + +Lo stesso vale per rwlock_t e le varianti con _irqsave(). + +Sui kernel PREEMPT_RT questo codice non funzionerà perché gli rtmutex richiedono +un contesto con la possibilità di prelazione. Al suo posto, usate +spin_lock_irq() o spin_lock_irqsave() e le loro controparti per il rilascio. I +kernel PREEMPT_RT offrono un meccanismo local_lock per i casi in cui la +disabilitazione delle interruzioni ed acquisizione di un blocco devono rimanere +separati. Acquisire un local_lock àncora un processo ad una CPU permettendo cose +come un'acquisizione di un blocco con interruzioni disabilitate per singola CPU. + +Il tipico scenario è quando si vuole proteggere una variabile di processore nel +contesto di un thread:: + + + struct foo *p = get_cpu_ptr(&var1); + + spin_lock(&p->lock); + p->count += this_cpu_read(var2); + +Questo codice è corretto su un kernel non-PREEMPT_RT, ma non lo è su un +PREEMPT_RT. La modifica della semantica di spinlock_t su PREEMPT_RT non permette +di acquisire p->lock perché, implicitamente, get_cpu_ptr() disabilita la +prelazione. La seguente sostituzione funzionerà su entrambe i kernel:: + + struct foo *p; + + migrate_disable(); + p = this_cpu_ptr(&var1); + spin_lock(&p->lock); + p->count += this_cpu_read(var2); + +La funzione migrate_disable() assicura che il processo venga tenuto sulla CPU +corrente, e di conseguenza garantisce che gli accessi per-CPU alle variabili var1 e +var2 rimangano sulla stessa CPU fintanto che il processo rimane prelabile. + +La sostituzione con migrate_disable() non funzionerà nel seguente scenario:: + + func() + { + struct foo *p; + + migrate_disable(); + p = this_cpu_ptr(&var1); + p->val = func2(); + +Questo non funziona perché migrate_disable() non protegge dal ritorno da un +processo che aveva avuto il diritto di prelazione. Una sostituzione più adatta +per questo caso è:: + + func() + { + struct foo *p; + + local_lock(&foo_lock); + p = this_cpu_ptr(&var1); + p->val = func2(); + +Su un kernel non-PREEMPT_RT, questo codice protegge dal rientro disabilitando la +prelazione. Su un kernel PREEMPT_RT si ottiene lo stesso risultato acquisendo lo +spinlock di CPU. + +raw_spinlock_t su RT +-------------------- + +Acquisire un raw_spinlock_t disabilita la prelazione e possibilmente anche le +interruzioni, quindi la sezione critica deve evitare di acquisire uno spinlock_t +o rwlock_t. Per esempio, la sezione critica non deve fare allocazioni di +memoria. Su un kernel non-PREEMPT_RT il seguente codice funziona perfettamente:: + + raw_spin_lock(&lock); + p = kmalloc(sizeof(*p), GFP_ATOMIC); + +Ma lo stesso codice non funziona su un kernel PREEMPT_RT perché l'allocatore di +memoria può essere oggetto di prelazione e quindi non può essere chiamato in un +contesto atomico. Tuttavia, si può chiamare l'allocatore di memoria quando si +trattiene un blocco *non-raw* perché non disabilitano la prelazione sui kernel +PREEMPT_RT:: + + spin_lock(&lock); + p = kmalloc(sizeof(*p), GFP_ATOMIC); + + +bit spinlocks +------------- + +I kernel PREEMPT_RT non possono sostituire i bit spinlock perché un singolo bit +è troppo piccolo per farci stare un rtmutex. Dunque, la semantica dei bit +spinlock è mantenuta anche sui kernel PREEMPT_RT. Quindi, le precisazioni fatte +per raw_spinlock_t valgono anche qui. + +In PREEMPT_RT, alcuni bit spinlock sono sostituiti con normali spinlock_t usando +condizioni di preprocessore in base a dove vengono usati. Per contro, questo non +serve quando si sostituiscono gli spinlock_t. Invece, le condizioni poste sui +file d'intestazione e sul cuore dell'implementazione della sincronizzazione +permettono al compilatore di effettuare la sostituzione in modo trasparente. + + +Regole d'annidamento dei tipi di blocchi +======================================== + +Le regole principali sono: + + - I tipi di blocco appartenenti alla stessa categoria possono essere annidati + liberamente a patto che si rispetti l'ordine di blocco al fine di evitare + stalli. + + - I blocchi con sospensione non possono essere annidati in blocchi del tipo + CPU locale o ad attesa attiva + + - I blocchi ad attesa attiva e su CPU locale possono essere annidati nei + blocchi ad attesa con sospensione. + + - I blocchi ad attesa attiva possono essere annidati in qualsiasi altro tipo. + +Queste limitazioni si applicano ad entrambe i kernel con o senza PREEMPT_RT. + +Il fatto che un kernel PREEMPT_RT cambi i blocchi spinlock_t e rwlock_t dal tipo +ad attesa attiva a quello con sospensione, e che sostituisca local_lock con uno +spinlock_t per CPU, significa che non possono essere acquisiti quando si è in un +blocco raw_spinlock. Ne consegue il seguente ordine d'annidamento: + + 1) blocchi ad attesa con sospensione + 2) spinlock_t, rwlock_t, local_lock + 3) raw_spinlock_t e bit spinlocks + +Se queste regole verranno violate, allora lockdep se ne accorgerà e questo sia +con o senza PREEMPT_RT. -- cgit v1.2.3 From 0c17bb5e360981616d3d0eafc904bffe6e3ee626 Mon Sep 17 00:00:00 2001 From: Jonathan Corbet Date: Mon, 22 Jan 2024 15:19:19 -0700 Subject: docs: rework the driver-api top-level page Add subsections in an attempt to bring a bit order to this page; also sort most subsections into alphabetical order. With luck all this will help to prevent merge conflicts on this page due to everybody adding entries at the end. Signed-off-by: Jonathan Corbet Link: https://lore.kernel.org/r/87plxtm2oo.fsf@meer.lwn.net --- Documentation/driver-api/index.rst | 169 ++++++++++++++++++++++--------------- 1 file changed, 100 insertions(+), 69 deletions(-) (limited to 'Documentation') diff --git a/Documentation/driver-api/index.rst b/Documentation/driver-api/index.rst index eba851605388..f10decc2c14b 100644 --- a/Documentation/driver-api/index.rst +++ b/Documentation/driver-api/index.rst @@ -9,110 +9,141 @@ of device drivers. This document is an only somewhat organized collection of some of those interfaces — it will hopefully get better over time! The available subsections can be seen below. + +General information for driver authors +====================================== + +This section contains documentation that should, at some point or other, be +of interest to most developers working on device drivers. + .. toctree:: - :caption: Table of contents - :maxdepth: 2 + :maxdepth: 1 - driver-model/index basics + driver-model/index + device_link infrastructure ioctl - early-userspace/index pm/index - clk + +Useful support libraries +======================== + +This section contains documentation that should, at some point or other, be +of interest to most developers working on device drivers. + +.. toctree:: + :maxdepth: 1 + + early-userspace/index + connector device-io + devfreq dma-buf - device_link component - message-based - infiniband - aperture - frame-buffer - regulator - reset - iio/index - input - usb/index - firewire - pci/index + io-mapping + io_ordering + uio-howto + vfio-mediated-device + vfio + vfio-pci-device-specific-driver-acceptance + +Bus-level documentation +======================= + +.. toctree:: + :maxdepth: 1 + + auxiliary_bus cxl/index - spi - i2c - ipmb - ipmi + eisa + firewire i3c/index - interconnect - devfreq - hsi - edac - scsi - libata - target - mailbox - mtdnand - miscellaneous - mei/index - mtd/index - mmc/index - nvdimm/index - w1 + isa + men-chameleon-bus + pci/index rapidio/index - s390-drivers + slimbus + usb/index + virtio/index vme + w1 + xillybus + + +Subsystem-specific APIs +======================= + +.. toctree:: + :maxdepth: 1 + 80211/index - uio-howto + acpi/index + backlight/lp855x-driver.rst + clk + console + crypto/index + dmaengine/index + dpll + edac firmware/index - pin-control + fpga/index + frame-buffer + aperture + generic-counter gpio/index + hsi + hte/index + i2c + iio/index + infiniband + input + interconnect + ipmb + ipmi + libata + mailbox md/index media/index + mei/index + memory-devices/index + message-based misc_devices + miscellaneous + mmc/index + mtd/index + mtdnand nfc/index - dmaengine/index - slimbus - soundwire/index - thermal/index - fpga/index - acpi/index - auxiliary_bus - backlight/lp855x-driver.rst - connector - console - eisa - isa - io-mapping - io_ordering - generic-counter - memory-devices/index - men-chameleon-bus ntb + nvdimm/index nvmem parport-lowlevel + phy/index + pin-control + pldmfw/index pps ptp - phy/index pwm - pldmfw/index + regulator + reset rfkill + s390-drivers + scsi serial/index sm501 + soundwire/index + spi surface_aggregator/index switchtec sync_file + target + tee + thermal/index tty/index - vfio-mediated-device - vfio - vfio-pci-device-specific-driver-acceptance - virtio/index + wbrf + wmi xilinx/index - xillybus zorro - hte/index - wmi - dpll - wbrf - crypto/index - tee .. only:: subproject and html -- cgit v1.2.3 From e60b95d2b68724baaacc5f7d91cfc3060811a1c1 Mon Sep 17 00:00:00 2001 From: Bjorn Andersson Date: Thu, 25 Jan 2024 13:05:07 -0800 Subject: dt-bindings: clock: qcom: Allow VDD_GFX supply to GX In some designs the SoC's VDD_GFX pads are supplied by an external regulator, rather than a power-domain. Allow this to be described in the GPU clock controller binding. Reviewed-by: Krzysztof Kozlowski Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20240125-sa8295p-gpu-v4-1-7011c2a63037@quicinc.com Signed-off-by: Bjorn Andersson --- Documentation/devicetree/bindings/clock/qcom,gpucc.yaml | 9 +++++++++ 1 file changed, 9 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/qcom,gpucc.yaml b/Documentation/devicetree/bindings/clock/qcom,gpucc.yaml index f369fa34e00c..f57aceddac6b 100644 --- a/Documentation/devicetree/bindings/clock/qcom,gpucc.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,gpucc.yaml @@ -53,6 +53,9 @@ properties: power-domains: maxItems: 1 + vdd-gfx-supply: + description: Regulator supply for the VDD_GFX pads + '#clock-cells': const: 1 @@ -74,6 +77,12 @@ required: - '#reset-cells' - '#power-domain-cells' +# Require that power-domains and vdd-gfx-supply are not both present +not: + required: + - power-domains + - vdd-gfx-supply + additionalProperties: false examples: -- cgit v1.2.3 From 8722435d325b642d2969f32ec0daacf0dbaae276 Mon Sep 17 00:00:00 2001 From: Jonathan Corbet Date: Mon, 22 Jan 2024 15:18:30 -0700 Subject: docs: rework the userspace-api top page Add some subsection headings and reorder entries so that the page makes a bit more sense. With luck, adding some ordering will also reduce merge conflicts due to everybody adding new entries at the end. Signed-off-by: Jonathan Corbet Link: https://lore.kernel.org/r/87ttn5m2q1.fsf@meer.lwn.net --- Documentation/userspace-api/index.rst | 48 ++++++++++++++++++++++++++--------- 1 file changed, 36 insertions(+), 12 deletions(-) (limited to 'Documentation') diff --git a/Documentation/userspace-api/index.rst b/Documentation/userspace-api/index.rst index 09f61bd2ac2e..99a388fdefb5 100644 --- a/Documentation/userspace-api/index.rst +++ b/Documentation/userspace-api/index.rst @@ -9,31 +9,55 @@ While much of the kernel's user-space API is documented elsewhere also be found in the kernel tree itself. This manual is intended to be the place where this information is gathered. + +System calls +============ + .. toctree:: - :caption: Table of contents - :maxdepth: 2 + :maxdepth: 1 + + unshare + futex2 + ebpf/index + ioctl/index + +Security-related interfaces +=========================== + +.. toctree:: + :maxdepth: 1 no_new_privs seccomp_filter landlock - unshare + lsm spec_ctrl + tee + +Devices and I/O +=============== + +.. toctree:: + :maxdepth: 1 + accelerators/ocxl dma-buf-alloc-exchange - ebpf/index - ELF - ioctl/index iommu iommufd media/index - netlink/index - sysfs-platform_profile + dcdbas vduse - futex2 - lsm - tee isapnp - dcdbas + +Everything else +=============== + +.. toctree:: + :maxdepth: 1 + + ELF + netlink/index + sysfs-platform_profile .. only:: subproject and html -- cgit v1.2.3 From 413971526a90f4639d84a027f7cd65a87958cb3b Mon Sep 17 00:00:00 2001 From: Leo Yan Date: Tue, 2 Jan 2024 16:50:01 +0800 Subject: Documentation: userspace-api: Document perf ring buffer mechanism In the Linux perf tool, the ring buffer serves not only as a medium for transferring PMU event data but also as a vital mechanism for hardware tracing using technologies like Intel PT and Arm CoreSight, etc. Consequently, the ring buffer mechanism plays a crucial role by ensuring high throughput for data transfer between the kernel and user space while avoiding excessive overhead caused by the ring buffer itself. This commit documents the ring buffer mechanism in detail. It explains the implementation of both the regular ring buffer and the AUX ring buffer. Additionally, it covers how these ring buffers support various tracing modes and explains the synchronization with memory barriers. Signed-off-by: Leo Yan Reviewed-by: James Clark Reviewed-by: Namhyung Kim Signed-off-by: Jonathan Corbet Link: https://lore.kernel.org/r/20240102085001.228815-1-leo.yan@linaro.org --- Documentation/userspace-api/index.rst | 3 + Documentation/userspace-api/perf_ring_buffer.rst | 830 +++++++++++++++++++++++ 2 files changed, 833 insertions(+) create mode 100644 Documentation/userspace-api/perf_ring_buffer.rst (limited to 'Documentation') diff --git a/Documentation/userspace-api/index.rst b/Documentation/userspace-api/index.rst index 99a388fdefb5..67d663cf2ff2 100644 --- a/Documentation/userspace-api/index.rst +++ b/Documentation/userspace-api/index.rst @@ -58,6 +58,9 @@ Everything else ELF netlink/index sysfs-platform_profile + vduse + futex2 + perf_ring_buffer .. only:: subproject and html diff --git a/Documentation/userspace-api/perf_ring_buffer.rst b/Documentation/userspace-api/perf_ring_buffer.rst new file mode 100644 index 000000000000..bde9d8cbc106 --- /dev/null +++ b/Documentation/userspace-api/perf_ring_buffer.rst @@ -0,0 +1,830 @@ +.. SPDX-License-Identifier: GPL-2.0 + +================ +Perf ring buffer +================ + +.. CONTENTS + + 1. Introduction + + 2. Ring buffer implementation + 2.1 Basic algorithm + 2.2 Ring buffer for different tracing modes + 2.2.1 Default mode + 2.2.2 Per-thread mode + 2.2.3 Per-CPU mode + 2.2.4 System wide mode + 2.3 Accessing buffer + 2.3.1 Producer-consumer model + 2.3.2 Properties of the ring buffers + 2.3.3 Writing samples into buffer + 2.3.4 Reading samples from buffer + 2.3.5 Memory synchronization + + 3. The mechanism of AUX ring buffer + 3.1 The relationship between AUX and regular ring buffers + 3.2 AUX events + 3.3 Snapshot mode + + +1. Introduction +=============== + +The ring buffer is a fundamental mechanism for data transfer. perf uses +ring buffers to transfer event data from kernel to user space, another +kind of ring buffer which is so called auxiliary (AUX) ring buffer also +plays an important role for hardware tracing with Intel PT, Arm +CoreSight, etc. + +The ring buffer implementation is critical but it's also a very +challenging work. On the one hand, the kernel and perf tool in the user +space use the ring buffer to exchange data and stores data into data +file, thus the ring buffer needs to transfer data with high throughput; +on the other hand, the ring buffer management should avoid significant +overload to distract profiling results. + +This documentation dives into the details for perf ring buffer with two +parts: firstly it explains the perf ring buffer implementation, then the +second part discusses the AUX ring buffer mechanism. + +2. Ring buffer implementation +============================= + +2.1 Basic algorithm +------------------- + +That said, a typical ring buffer is managed by a head pointer and a tail +pointer; the head pointer is manipulated by a writer and the tail +pointer is updated by a reader respectively. + +:: + + +---------------------------+ + | | |***|***|***| | | + +---------------------------+ + `-> Tail `-> Head + + * : the data is filled by the writer. + + Figure 1. Ring buffer + +Perf uses the same way to manage its ring buffer. In the implementation +there are two key data structures held together in a set of consecutive +pages, the control structure and then the ring buffer itself. The page +with the control structure in is known as the "user page". Being held +in continuous virtual addresses simplifies locating the ring buffer +address, it is in the pages after the page with the user page. + +The control structure is named as ``perf_event_mmap_page``, it contains a +head pointer ``data_head`` and a tail pointer ``data_tail``. When the +kernel starts to fill records into the ring buffer, it updates the head +pointer to reserve the memory so later it can safely store events into +the buffer. On the other side, when the user page is a writable mapping, +the perf tool has the permission to update the tail pointer after consuming +data from the ring buffer. Yet another case is for the user page's +read-only mapping, which is to be addressed in the section +:ref:`writing_samples_into_buffer`. + +:: + + user page ring buffer + +---------+---------+ +---------------------------------------+ + |data_head|data_tail|...| | |***|***|***|***|***| | | | + +---------+---------+ +---------------------------------------+ + ` `----------------^ ^ + `----------------------------------------------| + + * : the data is filled by the writer. + + Figure 2. Perf ring buffer + +When using the ``perf record`` tool, we can specify the ring buffer size +with option ``-m`` or ``--mmap-pages=``, the given size will be rounded up +to a power of two that is a multiple of a page size. Though the kernel +allocates at once for all memory pages, it's deferred to map the pages +to VMA area until the perf tool accesses the buffer from the user space. +In other words, at the first time accesses the buffer's page from user +space in the perf tool, a data abort exception for page fault is taken +and the kernel uses this occasion to map the page into process VMA +(see ``perf_mmap_fault()``), thus the perf tool can continue to access +the page after returning from the exception. + +2.2 Ring buffer for different tracing modes +------------------------------------------- + +The perf profiles programs with different modes: default mode, per thread +mode, per cpu mode, and system wide mode. This section describes these +modes and how the ring buffer meets requirements for them. At last we +will review the race conditions caused by these modes. + +2.2.1 Default mode +^^^^^^^^^^^^^^^^^^ + +Usually we execute ``perf record`` command followed by a profiling program +name, like below command:: + + perf record test_program + +This command doesn't specify any options for CPU and thread modes, the +perf tool applies the default mode on the perf event. It maps all the +CPUs in the system and the profiled program's PID on the perf event, and +it enables inheritance mode on the event so that child tasks inherits +the events. As a result, the perf event is attributed as:: + + evsel::cpus::map[] = { 0 .. _SC_NPROCESSORS_ONLN-1 } + evsel::threads::map[] = { pid } + evsel::attr::inherit = 1 + +These attributions finally will be reflected on the deployment of ring +buffers. As shown below, the perf tool allocates individual ring buffer +for each CPU, but it only enables events for the profiled program rather +than for all threads in the system. The *T1* thread represents the +thread context of the 'test_program', whereas *T2* and *T3* are irrelevant +threads in the system. The perf samples are exclusively collected for +the *T1* thread and stored in the ring buffer associated with the CPU on +which the *T1* thread is running. + +:: + + T1 T2 T1 + +----+ +-----------+ +----+ + CPU0 |xxxx| |xxxxxxxxxxx| |xxxx| + +----+--------------+-----------+----------+----+--------> + | | + v v + +-----------------------------------------------------+ + | Ring buffer 0 | + +-----------------------------------------------------+ + + T1 + +-----+ + CPU1 |xxxxx| + -----+-----+---------------------------------------------> + | + v + +-----------------------------------------------------+ + | Ring buffer 1 | + +-----------------------------------------------------+ + + T1 T3 + +----+ +-------+ + CPU2 |xxxx| |xxxxxxx| + --------------------------+----+--------+-------+--------> + | + v + +-----------------------------------------------------+ + | Ring buffer 2 | + +-----------------------------------------------------+ + + T1 + +--------------+ + CPU3 |xxxxxxxxxxxxxx| + -----------+--------------+------------------------------> + | + v + +-----------------------------------------------------+ + | Ring buffer 3 | + +-----------------------------------------------------+ + + T1: Thread 1; T2: Thread 2; T3: Thread 3 + x: Thread is in running state + + Figure 3. Ring buffer for default mode + +2.2.2 Per-thread mode +^^^^^^^^^^^^^^^^^^^^^ + +By specifying option ``--per-thread`` in perf command, e.g. + +:: + + perf record --per-thread test_program + +The perf event doesn't map to any CPUs and is only bound to the +profiled process, thus, the perf event's attributions are:: + + evsel::cpus::map[0] = { -1 } + evsel::threads::map[] = { pid } + evsel::attr::inherit = 0 + +In this mode, a single ring buffer is allocated for the profiled thread; +if the thread is scheduled on a CPU, the events on that CPU will be +enabled; and if the thread is scheduled out from the CPU, the events on +the CPU will be disabled. When the thread is migrated from one CPU to +another, the events are to be disabled on the previous CPU and enabled +on the next CPU correspondingly. + +:: + + T1 T2 T1 + +----+ +-----------+ +----+ + CPU0 |xxxx| |xxxxxxxxxxx| |xxxx| + +----+--------------+-----------+----------+----+--------> + | | + | T1 | + | +-----+ | + CPU1 | |xxxxx| | + --|--+-----+----------------------------------|----------> + | | | + | | T1 T3 | + | | +----+ +---+ | + CPU2 | | |xxxx| |xxx| | + --|-----|-----------------+----+--------+---+-|----------> + | | | | + | | T1 | | + | | +--------------+ | | + CPU3 | | |xxxxxxxxxxxxxx| | | + --|-----|--+--------------+-|-----------------|----------> + | | | | | + v v v v v + +-----------------------------------------------------+ + | Ring buffer | + +-----------------------------------------------------+ + + T1: Thread 1 + x: Thread is in running state + + Figure 4. Ring buffer for per-thread mode + +When perf runs in per-thread mode, a ring buffer is allocated for the +profiled thread *T1*. The ring buffer is dedicated for thread *T1*, if the +thread *T1* is running, the perf events will be recorded into the ring +buffer; when the thread is sleeping, all associated events will be +disabled, thus no trace data will be recorded into the ring buffer. + +2.2.3 Per-CPU mode +^^^^^^^^^^^^^^^^^^ + +The option ``-C`` is used to collect samples on the list of CPUs, for +example the below perf command receives option ``-C 0,2``:: + + perf record -C 0,2 test_program + +It maps the perf event to CPUs 0 and 2, and the event is not associated to any +PID. Thus the perf event attributions are set as:: + + evsel::cpus::map[0] = { 0, 2 } + evsel::threads::map[] = { -1 } + evsel::attr::inherit = 0 + +This results in the session of ``perf record`` will sample all threads on CPU0 +and CPU2, and be terminated until test_program exits. Even there have tasks +running on CPU1 and CPU3, since the ring buffer is absent for them, any +activities on these two CPUs will be ignored. A usage case is to combine the +options for per-thread mode and per-CPU mode, e.g. the options ``–C 0,2`` and +``––per–thread`` are specified together, the samples are recorded only when +the profiled thread is scheduled on any of the listed CPUs. + +:: + + T1 T2 T1 + +----+ +-----------+ +----+ + CPU0 |xxxx| |xxxxxxxxxxx| |xxxx| + +----+--------------+-----------+----------+----+--------> + | | | + v v v + +-----------------------------------------------------+ + | Ring buffer 0 | + +-----------------------------------------------------+ + + T1 + +-----+ + CPU1 |xxxxx| + -----+-----+---------------------------------------------> + + T1 T3 + +----+ +-------+ + CPU2 |xxxx| |xxxxxxx| + --------------------------+----+--------+-------+--------> + | | + v v + +-----------------------------------------------------+ + | Ring buffer 1 | + +-----------------------------------------------------+ + + T1 + +--------------+ + CPU3 |xxxxxxxxxxxxxx| + -----------+--------------+------------------------------> + + T1: Thread 1; T2: Thread 2; T3: Thread 3 + x: Thread is in running state + + Figure 5. Ring buffer for per-CPU mode + +2.2.4 System wide mode +^^^^^^^^^^^^^^^^^^^^^^ + +By using option ``–a`` or ``––all–cpus``, perf collects samples on all CPUs +for all tasks, we call it as the system wide mode, the command is:: + + perf record -a test_program + +Similar to the per-CPU mode, the perf event doesn't bind to any PID, and +it maps to all CPUs in the system:: + + evsel::cpus::map[] = { 0 .. _SC_NPROCESSORS_ONLN-1 } + evsel::threads::map[] = { -1 } + evsel::attr::inherit = 0 + +In the system wide mode, every CPU has its own ring buffer, all threads +are monitored during the running state and the samples are recorded into +the ring buffer belonging to the CPU which the events occurred on. + +:: + + T1 T2 T1 + +----+ +-----------+ +----+ + CPU0 |xxxx| |xxxxxxxxxxx| |xxxx| + +----+--------------+-----------+----------+----+--------> + | | | + v v v + +-----------------------------------------------------+ + | Ring buffer 0 | + +-----------------------------------------------------+ + + T1 + +-----+ + CPU1 |xxxxx| + -----+-----+---------------------------------------------> + | + v + +-----------------------------------------------------+ + | Ring buffer 1 | + +-----------------------------------------------------+ + + T1 T3 + +----+ +-------+ + CPU2 |xxxx| |xxxxxxx| + --------------------------+----+--------+-------+--------> + | | + v v + +-----------------------------------------------------+ + | Ring buffer 2 | + +-----------------------------------------------------+ + + T1 + +--------------+ + CPU3 |xxxxxxxxxxxxxx| + -----------+--------------+------------------------------> + | + v + +-----------------------------------------------------+ + | Ring buffer 3 | + +-----------------------------------------------------+ + + T1: Thread 1; T2: Thread 2; T3: Thread 3 + x: Thread is in running state + + Figure 6. Ring buffer for system wide mode + +2.3 Accessing buffer +-------------------- + +Based on the understanding of how the ring buffer is allocated in +various modes, this section explains access the ring buffer. + +2.3.1 Producer-consumer model +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +In the Linux kernel, the PMU events can produce samples which are stored +into the ring buffer; the perf command in user space consumes the +samples by reading out data from the ring buffer and finally saves the +data into the file for post analysis. It’s a typical producer-consumer +model for using the ring buffer. + +The perf process polls on the PMU events and sleeps when no events are +incoming. To prevent frequent exchanges between the kernel and user +space, the kernel event core layer introduces a watermark, which is +stored in the ``perf_buffer::watermark``. When a sample is recorded into +the ring buffer, and if the used buffer exceeds the watermark, the +kernel wakes up the perf process to read samples from the ring buffer. + +:: + + Perf + / | Read samples + Polling / `--------------| Ring buffer + v v ;---------------------v + +----------------+ +---------+---------+ +-------------------+ + |Event wait queue| |data_head|data_tail| |***|***| | |***| + +----------------+ +---------+---------+ +-------------------+ + ^ ^ `------------------------^ + | Wake up tasks | Store samples + +-----------------------------+ + | Kernel event core layer | + +-----------------------------+ + + * : the data is filled by the writer. + + Figure 7. Writing and reading the ring buffer + +When the kernel event core layer notifies the user space, because +multiple events might share the same ring buffer for recording samples, +the core layer iterates every event associated with the ring buffer and +wakes up tasks waiting on the event. This is fulfilled by the kernel +function ``ring_buffer_wakeup()``. + +After the perf process is woken up, it starts to check the ring buffers +one by one, if it finds any ring buffer containing samples it will read +out the samples for statistics or saving into the data file. Given the +perf process is able to run on any CPU, this leads to the ring buffer +potentially being accessed from multiple CPUs simultaneously, which +causes race conditions. The race condition handling is described in the +section :ref:`memory_synchronization`. + +2.3.2 Properties of the ring buffers +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Linux kernel supports two write directions for the ring buffer: forward and +backward. The forward writing saves samples from the beginning of the ring +buffer, the backward writing stores data from the end of the ring buffer with +the reversed direction. The perf tool determines the writing direction. + +Additionally, the tool can map buffers in either read-write mode or read-only +mode to the user space. + +The ring buffer in the read-write mode is mapped with the property +``PROT_READ | PROT_WRITE``. With the write permission, the perf tool +updates the ``data_tail`` to indicate the data start position. Combining +with the head pointer ``data_head``, which works as the end position of +the current data, the perf tool can easily know where read out the data +from. + +Alternatively, in the read-only mode, only the kernel keeps to update +the ``data_head`` while the user space cannot access the ``data_tail`` due +to the mapping property ``PROT_READ``. + +As a result, the matrix below illustrates the various combinations of +direction and mapping characteristics. The perf tool employs two of these +combinations to support buffer types: the non-overwrite buffer and the +overwritable buffer. + +.. list-table:: + :widths: 1 1 1 + :header-rows: 1 + + * - Mapping mode + - Forward + - Backward + * - read-write + - Non-overwrite ring buffer + - Not used + * - read-only + - Not used + - Overwritable ring buffer + +The non-overwrite ring buffer uses the read-write mapping with forward +writing. It starts to save data from the beginning of the ring buffer +and wrap around when overflow, which is used with the read-write mode in +the normal ring buffer. When the consumer doesn't keep up with the +producer, it would lose some data, the kernel keeps how many records it +lost and generates the ``PERF_RECORD_LOST`` records in the next time +when it finds a space in the ring buffer. + +The overwritable ring buffer uses the backward writing with the +read-only mode. It saves the data from the end of the ring buffer and +the ``data_head`` keeps the position of current data, the perf always +knows where it starts to read and until the end of the ring buffer, thus +it don't need the ``data_tail``. In this mode, it will not generate the +``PERF_RECORD_LOST`` records. + +.. _writing_samples_into_buffer: + +2.3.3 Writing samples into buffer +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +When a sample is taken and saved into the ring buffer, the kernel +prepares sample fields based on the sample type; then it prepares the +info for writing ring buffer which is stored in the structure +``perf_output_handle``. In the end, the kernel outputs the sample into +the ring buffer and updates the head pointer in the user page so the +perf tool can see the latest value. + +The structure ``perf_output_handle`` serves as a temporary context for +tracking the information related to the buffer. The advantages of it is +that it enables concurrent writing to the buffer by different events. +For example, a software event and a hardware PMU event both are enabled +for profiling, two instances of ``perf_output_handle`` serve as separate +contexts for the software event and the hardware event respectively. +This allows each event to reserve its own memory space for populating +the record data. + +2.3.4 Reading samples from buffer +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +In the user space, the perf tool utilizes the ``perf_event_mmap_page`` +structure to handle the head and tail of the buffer. It also uses +``perf_mmap`` structure to keep track of a context for the ring buffer, this +context includes information about the buffer's starting and ending +addresses. Additionally, the mask value can be utilized to compute the +circular buffer pointer even for an overflow. + +Similar to the kernel, the perf tool in the user space first reads out +the recorded data from the ring buffer, and then updates the buffer's +tail pointer ``perf_event_mmap_page::data_tail``. + +.. _memory_synchronization: + +2.3.5 Memory synchronization +^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +The modern CPUs with relaxed memory model cannot promise the memory +ordering, this means it’s possible to access the ring buffer and the +``perf_event_mmap_page`` structure out of order. To assure the specific +sequence for memory accessing perf ring buffer, memory barriers are +used to assure the data dependency. The rationale for the memory +synchronization is as below:: + + Kernel User space + + if (LOAD ->data_tail) { LOAD ->data_head + (A) smp_rmb() (C) + STORE $data LOAD $data + smp_wmb() (B) smp_mb() (D) + STORE ->data_head STORE ->data_tail + } + +The comments in tools/include/linux/ring_buffer.h gives nice description +for why and how to use memory barriers, here we will just provide an +alternative explanation: + +(A) is a control dependency so that CPU assures order between checking +pointer ``perf_event_mmap_page::data_tail`` and filling sample into ring +buffer; + +(D) pairs with (A). (D) separates the ring buffer data reading from +writing the pointer ``data_tail``, perf tool first consumes samples and then +tells the kernel that the data chunk has been released. Since a reading +operation is followed by a writing operation, thus (D) is a full memory +barrier. + +(B) is a writing barrier in the middle of two writing operations, which +makes sure that recording a sample must be prior to updating the head +pointer. + +(C) pairs with (B). (C) is a read memory barrier to ensure the head +pointer is fetched before reading samples. + +To implement the above algorithm, the ``perf_output_put_handle()`` function +in the kernel and two helpers ``ring_buffer_read_head()`` and +``ring_buffer_write_tail()`` in the user space are introduced, they rely +on memory barriers as described above to ensure the data dependency. + +Some architectures support one-way permeable barrier with load-acquire +and store-release operations, these barriers are more relaxed with less +performance penalty, so (C) and (D) can be optimized to use barriers +``smp_load_acquire()`` and ``smp_store_release()`` respectively. + +If an architecture doesn’t support load-acquire and store-release in its +memory model, it will roll back to the old fashion of memory barrier +operations. In this case, ``smp_load_acquire()`` encapsulates +``READ_ONCE()`` + ``smp_mb()``, since ``smp_mb()`` is costly, +``ring_buffer_read_head()`` doesn't invoke ``smp_load_acquire()`` and it uses +the barriers ``READ_ONCE()`` + ``smp_rmb()`` instead. + +3. The mechanism of AUX ring buffer +=================================== + +In this chapter, we will explain the implementation of the AUX ring +buffer. In the first part it will discuss the connection between the +AUX ring buffer and the regular ring buffer, then the second part will +examine how the AUX ring buffer co-works with the regular ring buffer, +as well as the additional features introduced by the AUX ring buffer for +the sampling mechanism. + +3.1 The relationship between AUX and regular ring buffers +--------------------------------------------------------- + +Generally, the AUX ring buffer is an auxiliary for the regular ring +buffer. The regular ring buffer is primarily used to store the event +samples and every event format complies with the definition in the +union ``perf_event``; the AUX ring buffer is for recording the hardware +trace data and the trace data format is hardware IP dependent. + +The general use and advantage of the AUX ring buffer is that it is +written directly by hardware rather than by the kernel. For example, +regular profile samples that write to the regular ring buffer cause an +interrupt. Tracing execution requires a high number of samples and +using interrupts would be overwhelming for the regular ring buffer +mechanism. Having an AUX buffer allows for a region of memory more +decoupled from the kernel and written to directly by hardware tracing. + +The AUX ring buffer reuses the same algorithm with the regular ring +buffer for the buffer management. The control structure +``perf_event_mmap_page`` extends the new fields ``aux_head`` and ``aux_tail`` +for the head and tail pointers of the AUX ring buffer. + +During the initialisation phase, besides the mmap()-ed regular ring +buffer, the perf tool invokes a second syscall in the +``auxtrace_mmap__mmap()`` function for the mmap of the AUX buffer with +non-zero file offset; ``rb_alloc_aux()`` in the kernel allocates pages +correspondingly, these pages will be deferred to map into VMA when +handling the page fault, which is the same lazy mechanism with the +regular ring buffer. + +AUX events and AUX trace data are two different things. Let's see an +example:: + + perf record -a -e cycles -e cs_etm/@tmc_etr0/ -- sleep 2 + +The above command enables two events: one is the event *cycles* from PMU +and another is the AUX event *cs_etm* from Arm CoreSight, both are saved +into the regular ring buffer while the CoreSight's AUX trace data is +stored in the AUX ring buffer. + +As a result, we can see the regular ring buffer and the AUX ring buffer +are allocated in pairs. The perf in default mode allocates the regular +ring buffer and the AUX ring buffer per CPU-wise, which is the same as +the system wide mode, however, the default mode records samples only for +the profiled program, whereas the latter mode profiles for all programs +in the system. For per-thread mode, the perf tool allocates only one +regular ring buffer and one AUX ring buffer for the whole session. For +the per-CPU mode, the perf allocates two kinds of ring buffers for +selected CPUs specified by the option ``-C``. + +The below figure demonstrates the buffers' layout in the system wide +mode; if there are any activities on one CPU, the AUX event samples and +the hardware trace data will be recorded into the dedicated buffers for +the CPU. + +:: + + T1 T2 T1 + +----+ +-----------+ +----+ + CPU0 |xxxx| |xxxxxxxxxxx| |xxxx| + +----+--------------+-----------+----------+----+--------> + | | | + v v v + +-----------------------------------------------------+ + | Ring buffer 0 | + +-----------------------------------------------------+ + | | | + v v v + +-----------------------------------------------------+ + | AUX Ring buffer 0 | + +-----------------------------------------------------+ + + T1 + +-----+ + CPU1 |xxxxx| + -----+-----+---------------------------------------------> + | + v + +-----------------------------------------------------+ + | Ring buffer 1 | + +-----------------------------------------------------+ + | + v + +-----------------------------------------------------+ + | AUX Ring buffer 1 | + +-----------------------------------------------------+ + + T1 T3 + +----+ +-------+ + CPU2 |xxxx| |xxxxxxx| + --------------------------+----+--------+-------+--------> + | | + v v + +-----------------------------------------------------+ + | Ring buffer 2 | + +-----------------------------------------------------+ + | | + v v + +-----------------------------------------------------+ + | AUX Ring buffer 2 | + +-----------------------------------------------------+ + + T1 + +--------------+ + CPU3 |xxxxxxxxxxxxxx| + -----------+--------------+------------------------------> + | + v + +-----------------------------------------------------+ + | Ring buffer 3 | + +-----------------------------------------------------+ + | + v + +-----------------------------------------------------+ + | AUX Ring buffer 3 | + +-----------------------------------------------------+ + + T1: Thread 1; T2: Thread 2; T3: Thread 3 + x: Thread is in running state + + Figure 8. AUX ring buffer for system wide mode + +3.2 AUX events +-------------- + +Similar to ``perf_output_begin()`` and ``perf_output_end()``'s working for the +regular ring buffer, ``perf_aux_output_begin()`` and ``perf_aux_output_end()`` +serve for the AUX ring buffer for processing the hardware trace data. + +Once the hardware trace data is stored into the AUX ring buffer, the PMU +driver will stop hardware tracing by calling the ``pmu::stop()`` callback. +Similar to the regular ring buffer, the AUX ring buffer needs to apply +the memory synchronization mechanism as discussed in the section +:ref:`memory_synchronization`. Since the AUX ring buffer is managed by the +PMU driver, the barrier (B), which is a writing barrier to ensure the trace +data is externally visible prior to updating the head pointer, is asked +to be implemented in the PMU driver. + +Then ``pmu::stop()`` can safely call the ``perf_aux_output_end()`` function to +finish two things: + +- It fills an event ``PERF_RECORD_AUX`` into the regular ring buffer, this + event delivers the information of the start address and data size for a + chunk of hardware trace data has been stored into the AUX ring buffer; + +- Since the hardware trace driver has stored new trace data into the AUX + ring buffer, the argument *size* indicates how many bytes have been + consumed by the hardware tracing, thus ``perf_aux_output_end()`` updates the + header pointer ``perf_buffer::aux_head`` to reflect the latest buffer usage. + +At the end, the PMU driver will restart hardware tracing. During this +temporary suspending period, it will lose hardware trace data, which +will introduce a discontinuity during decoding phase. + +The event ``PERF_RECORD_AUX`` presents an AUX event which is handled in the +kernel, but it lacks the information for saving the AUX trace data in +the perf file. When the perf tool copies the trace data from AUX ring +buffer to the perf data file, it synthesizes a ``PERF_RECORD_AUXTRACE`` +event which is not a kernel ABI, it's defined by the perf tool to describe +which portion of data in the AUX ring buffer is saved. Afterwards, the perf +tool reads out the AUX trace data from the perf file based on the +``PERF_RECORD_AUXTRACE`` events, and the ``PERF_RECORD_AUX`` event is used to +decode a chunk of data by correlating with time order. + +3.3 Snapshot mode +----------------- + +Perf supports snapshot mode for AUX ring buffer, in this mode, users +only record AUX trace data at a specific time point which users are +interested in. E.g. below gives an example of how to take snapshots +with 1 second interval with Arm CoreSight:: + + perf record -e cs_etm/@tmc_etr0/u -S -a program & + PERFPID=$! + while true; do + kill -USR2 $PERFPID + sleep 1 + done + +The main flow for snapshot mode is: + +- Before a snapshot is taken, the AUX ring buffer acts in free run mode. + During free run mode the perf doesn't record any of the AUX events and + trace data; + +- Once the perf tool receives the *USR2* signal, it triggers the callback + function ``auxtrace_record::snapshot_start()`` to deactivate hardware + tracing. The kernel driver then populates the AUX ring buffer with the + hardware trace data, and the event ``PERF_RECORD_AUX`` is stored in the + regular ring buffer; + +- Then perf tool takes a snapshot, ``record__read_auxtrace_snapshot()`` + reads out the hardware trace data from the AUX ring buffer and saves it + into perf data file; + +- After the snapshot is finished, ``auxtrace_record::snapshot_finish()`` + restarts the PMU event for AUX tracing. + +The perf only accesses the head pointer ``perf_event_mmap_page::aux_head`` +in snapshot mode and doesn’t touch tail pointer ``aux_tail``, this is +because the AUX ring buffer can overflow in free run mode, the tail +pointer is useless in this case. Alternatively, the callback +``auxtrace_record::find_snapshot()`` is introduced for making the decision +of whether the AUX ring buffer has been wrapped around or not, at the +end it fixes up the AUX buffer's head which are used to calculate the +trace data size. + +As we know, the buffers' deployment can be per-thread mode, per-CPU +mode, or system wide mode, and the snapshot can be applied to any of +these modes. Below is an example of taking snapshot with system wide +mode. + +:: + + Snapshot is taken + | + v + +------------------------+ + | AUX Ring buffer 0 | <- aux_head + +------------------------+ + v + +--------------------------------+ + | AUX Ring buffer 1 | <- aux_head + +--------------------------------+ + v + +--------------------------------------------+ + | AUX Ring buffer 2 | <- aux_head + +--------------------------------------------+ + v + +---------------------------------------+ + | AUX Ring buffer 3 | <- aux_head + +---------------------------------------+ + + Figure 9. Snapshot with system wide mode -- cgit v1.2.3 From 01ac725c3b692bc6b29ee7520ced8dbf9e9dcab8 Mon Sep 17 00:00:00 2001 From: Michael Kelley Date: Wed, 24 Jan 2024 20:59:41 -0800 Subject: docs: Fix subsystem APIs page so ungrouped entries have their own header The kernel subsystem APIs front page currently has four top-level groupings with headers, and then everything else that isn't grouped. But in the table-of-contents, ungrouped subsystems are indented as if they were part of the preceding grouping (currently "Storage interfaces"), which is confusing. Fix this by adding an "Other subsystems" header for the ungrouped subsystems. Fixes: 3c591cc954d5 ("docs: consolidate human interface subsystems") Signed-off-by: Michael Kelley Signed-off-by: Jonathan Corbet Link: https://lore.kernel.org/r/20240125045941.123297-1-mhklinux@outlook.com --- Documentation/subsystem-apis.rst | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/subsystem-apis.rst b/Documentation/subsystem-apis.rst index 2d353fb8ea26..74af50d2ef7f 100644 --- a/Documentation/subsystem-apis.rst +++ b/Documentation/subsystem-apis.rst @@ -61,6 +61,8 @@ Storage interfaces scsi/index target/index +Other subsystems +---------------- **Fixme**: much more organizational work is needed here. .. toctree:: -- cgit v1.2.3 From 5c7944ca7b13978744ec83e131aef9255fdbabbe Mon Sep 17 00:00:00 2001 From: Abhishek Pandit-Subedi Date: Thu, 25 Jan 2024 16:53:11 -0800 Subject: coding-style: Add guidance to prefer dev_dbg During review, it was suggested that drivers only emit messages when something is wrong or it is a debug message. Document this as a formal recommendation. https://lore.kernel.org/linux-usb/2024012525-alienate-frown-916b@gregkh/ Signed-off-by: Abhishek Pandit-Subedi Acked-by: Greg Kroah-Hartman Signed-off-by: Jonathan Corbet Link: https://lore.kernel.org/r/20240125165311.1.I8d9c88e747e233917e527c7dad1feb8a18f070e2@changeid --- Documentation/process/coding-style.rst | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/process/coding-style.rst b/Documentation/process/coding-style.rst index c48382c6b477..f8ec23fa89bc 100644 --- a/Documentation/process/coding-style.rst +++ b/Documentation/process/coding-style.rst @@ -899,7 +899,8 @@ which you should use to make sure messages are matched to the right device and driver, and are tagged with the right level: dev_err(), dev_warn(), dev_info(), and so forth. For messages that aren't associated with a particular device, defines pr_notice(), pr_info(), -pr_warn(), pr_err(), etc. +pr_warn(), pr_err(), etc. When drivers are working properly they are quiet, +so prefer to use dev_dbg/pr_debug unless something is wrong. Coming up with good debugging messages can be quite a challenge; and once you have them, they can be a huge help for remote troubleshooting. However -- cgit v1.2.3 From 526b333d7c275a851ce982357218496569b3958e Mon Sep 17 00:00:00 2001 From: David Wronek Date: Sun, 21 Jan 2024 17:57:44 +0100 Subject: dt-bindings: arm: qcom: Add Xiaomi Redmi Note 9S Document the Xiaomi Redmi Note 9S (curtana) smartphone, which is based on the Qualcomm SM7125 SoC. Reviewed-by: Krzysztof Kozlowski Signed-off-by: David Wronek Link: https://lore.kernel.org/r/20240121-sm7125-upstream-v4-4-f7d1212c8ebb@gmail.com 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 097c91c0b32f..1999a5f2f254 100644 --- a/Documentation/devicetree/bindings/arm/qcom.yaml +++ b/Documentation/devicetree/bindings/arm/qcom.yaml @@ -992,6 +992,7 @@ properties: - items: - enum: + - xiaomi,curtana - xiaomi,joyeuse - const: qcom,sm7125 -- cgit v1.2.3 From 9c81ef43576e1721c442424abac48717da5e6266 Mon Sep 17 00:00:00 2001 From: Neil Armstrong Date: Mon, 29 Jan 2024 10:16:35 +0100 Subject: dt-bindings: input: document Goodix Berlin Touchscreen IC Document the Goodix GT9916 wich is part of the "Berlin" serie of Touchscreen controllers IC from Goodix. Reviewed-by: Rob Herring Signed-off-by: Neil Armstrong Link: https://lore.kernel.org/r/20240129-topic-goodix-berlin-upstream-initial-v15-1-6f7d096c0a0a@linaro.org Signed-off-by: Dmitry Torokhov --- .../bindings/input/touchscreen/goodix,gt9916.yaml | 95 ++++++++++++++++++++++ 1 file changed, 95 insertions(+) create mode 100644 Documentation/devicetree/bindings/input/touchscreen/goodix,gt9916.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/input/touchscreen/goodix,gt9916.yaml b/Documentation/devicetree/bindings/input/touchscreen/goodix,gt9916.yaml new file mode 100644 index 000000000000..d90f045ac06c --- /dev/null +++ b/Documentation/devicetree/bindings/input/touchscreen/goodix,gt9916.yaml @@ -0,0 +1,95 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/input/touchscreen/goodix,gt9916.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Goodix Berlin series touchscreen controller + +description: The Goodix Berlin series of touchscreen controllers + be connected to either I2C or SPI buses. + +maintainers: + - Neil Armstrong + +allOf: + - $ref: touchscreen.yaml# + - $ref: /schemas/spi/spi-peripheral-props.yaml# + +properties: + compatible: + enum: + - goodix,gt9916 + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + reset-gpios: + maxItems: 1 + + avdd-supply: + description: Analog power supply regulator on AVDD pin + + vddio-supply: + description: power supply regulator on VDDIO pin + + spi-max-frequency: true + touchscreen-inverted-x: true + touchscreen-inverted-y: true + touchscreen-size-x: true + touchscreen-size-y: true + touchscreen-swapped-x-y: true + +additionalProperties: false + +required: + - compatible + - reg + - interrupts + - avdd-supply + - touchscreen-size-x + - touchscreen-size-y + +examples: + - | + #include + #include + i2c { + #address-cells = <1>; + #size-cells = <0>; + touchscreen@5d { + compatible = "goodix,gt9916"; + reg = <0x5d>; + interrupt-parent = <&gpio>; + interrupts = <25 IRQ_TYPE_LEVEL_LOW>; + reset-gpios = <&gpio1 1 GPIO_ACTIVE_LOW>; + avdd-supply = <&ts_avdd>; + touchscreen-size-x = <1024>; + touchscreen-size-y = <768>; + }; + }; + - | + #include + #include + spi { + #address-cells = <1>; + #size-cells = <0>; + num-cs = <1>; + cs-gpios = <&gpio 2 GPIO_ACTIVE_HIGH>; + touchscreen@0 { + compatible = "goodix,gt9916"; + reg = <0>; + interrupt-parent = <&gpio>; + interrupts = <25 IRQ_TYPE_LEVEL_LOW>; + reset-gpios = <&gpio1 1 GPIO_ACTIVE_LOW>; + avdd-supply = <&ts_avdd>; + spi-max-frequency = <1000000>; + touchscreen-size-x = <1024>; + touchscreen-size-y = <768>; + }; + }; + +... -- cgit v1.2.3 From 736ed7ce0a5d10da3ff0e44719d1c232ce69da04 Mon Sep 17 00:00:00 2001 From: Rob Herring Date: Wed, 24 Jan 2024 13:01:04 -0600 Subject: dt-bindings: pinctrl: Unify "input-debounce" schema nuvoton,npcm845-pinctrl defines the common "input-debounce" property as an array rather than an scalar. Update the common definition to expand it to an uint32-array, and update all the users of the property with array constraints. Signed-off-by: Rob Herring Reviewed-by: Krzysztof Kozlowski Reviewed-by: Charles Keepax Link: https://lore.kernel.org/r/20240124190106.1540585-1-robh@kernel.org Signed-off-by: Linus Walleij --- Documentation/devicetree/bindings/pinctrl/cirrus,madera.yaml | 3 ++- Documentation/devicetree/bindings/pinctrl/nuvoton,npcm845-pinctrl.yaml | 1 - Documentation/devicetree/bindings/pinctrl/nuvoton,wpcm450-pinctrl.yaml | 3 ++- Documentation/devicetree/bindings/pinctrl/pincfg-node.yaml | 2 +- 4 files changed, 5 insertions(+), 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pinctrl/cirrus,madera.yaml b/Documentation/devicetree/bindings/pinctrl/cirrus,madera.yaml index bb61a30321a1..482acda88e73 100644 --- a/Documentation/devicetree/bindings/pinctrl/cirrus,madera.yaml +++ b/Documentation/devicetree/bindings/pinctrl/cirrus,madera.yaml @@ -93,7 +93,8 @@ properties: input-schmitt-disable: true - input-debounce: true + input-debounce: + maxItems: 1 output-low: true diff --git a/Documentation/devicetree/bindings/pinctrl/nuvoton,npcm845-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/nuvoton,npcm845-pinctrl.yaml index 3e8472898800..20cf0102aa63 100644 --- a/Documentation/devicetree/bindings/pinctrl/nuvoton,npcm845-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/nuvoton,npcm845-pinctrl.yaml @@ -152,7 +152,6 @@ patternProperties: description: Debouncing periods in microseconds, one period per interrupt bank found in the controller - $ref: /schemas/types.yaml#/definitions/uint32-array minItems: 1 maxItems: 4 diff --git a/Documentation/devicetree/bindings/pinctrl/nuvoton,wpcm450-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/nuvoton,wpcm450-pinctrl.yaml index 7b7f840ffc4c..08442c880f07 100644 --- a/Documentation/devicetree/bindings/pinctrl/nuvoton,wpcm450-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/nuvoton,wpcm450-pinctrl.yaml @@ -103,7 +103,8 @@ patternProperties: items: pattern: "^gpio1?[0-9]{1,2}$" - input-debounce: true + input-debounce: + maxItems: 1 additionalProperties: false diff --git a/Documentation/devicetree/bindings/pinctrl/pincfg-node.yaml b/Documentation/devicetree/bindings/pinctrl/pincfg-node.yaml index be81ed22a036..d0af21a564b4 100644 --- a/Documentation/devicetree/bindings/pinctrl/pincfg-node.yaml +++ b/Documentation/devicetree/bindings/pinctrl/pincfg-node.yaml @@ -97,7 +97,7 @@ properties: description: disable schmitt-trigger mode input-debounce: - $ref: /schemas/types.yaml#/definitions/uint32 + $ref: /schemas/types.yaml#/definitions/uint32-array description: Takes the debounce time in usec as argument or 0 to disable debouncing -- cgit v1.2.3 From 8758efbdc2b0c2fad7d7bddeb8732bc52b93b038 Mon Sep 17 00:00:00 2001 From: Rob Herring Date: Wed, 24 Jan 2024 13:01:05 -0600 Subject: dt-bindings: pinctrl: nuvoton,npcm845: Drop redundant type for "slew-rate" pincfg-node.yaml already defines the type for "slew-rate", so drop the type from the nuvoton,npcm845-pinctrl binding. Signed-off-by: Rob Herring Reviewed-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20240124190106.1540585-2-robh@kernel.org Signed-off-by: Linus Walleij --- Documentation/devicetree/bindings/pinctrl/nuvoton,npcm845-pinctrl.yaml | 1 - 1 file changed, 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pinctrl/nuvoton,npcm845-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/nuvoton,npcm845-pinctrl.yaml index 20cf0102aa63..b55d9c316659 100644 --- a/Documentation/devicetree/bindings/pinctrl/nuvoton,npcm845-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/nuvoton,npcm845-pinctrl.yaml @@ -159,7 +159,6 @@ patternProperties: description: | 0: Low rate 1: High rate - $ref: /schemas/types.yaml#/definitions/uint32 enum: [0, 1] drive-strength: -- cgit v1.2.3 From cd2807e73352114c5e30eab1a203ae9ca5175a49 Mon Sep 17 00:00:00 2001 From: Michal Simek Date: Wed, 24 Jan 2024 10:07:46 +0100 Subject: dt-bindings: pinctr: pinctrl-zynq: Fix compatible string Compatible string doesn't really match with compatible string listed in the driver itself. While binding was converted from txt to yaml xlnx,zynq-pinctrl was listed as compatible string but example was using xlnx,pinctrl-zynq and also this string is used in all DTSes. xlnx,zynq-pinctrl is used only in dt binding and not present in any DT which is stable for quite a long time that's why use old compatible string and update binding document instead of starting to use unused compatible string. Fixes: 153df45acda0 ("dt-bindings: pinctrl: pinctrl-zynq: Convert to yaml") Signed-off-by: Michal Simek Acked-by: Conor Dooley Link: https://lore.kernel.org/r/c1307a4dd5e30290acacc786cb2170deb9eaa539.1706087258.git.michal.simek@amd.com Signed-off-by: Linus Walleij --- .../bindings/pinctrl/xlnx,pinctrl-zynq.yaml | 217 +++++++++++++++++++++ .../bindings/pinctrl/xlnx,zynq-pinctrl.yaml | 217 --------------------- 2 files changed, 217 insertions(+), 217 deletions(-) create mode 100644 Documentation/devicetree/bindings/pinctrl/xlnx,pinctrl-zynq.yaml delete mode 100644 Documentation/devicetree/bindings/pinctrl/xlnx,zynq-pinctrl.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pinctrl/xlnx,pinctrl-zynq.yaml b/Documentation/devicetree/bindings/pinctrl/xlnx,pinctrl-zynq.yaml new file mode 100644 index 000000000000..de6c10ba36c4 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/xlnx,pinctrl-zynq.yaml @@ -0,0 +1,217 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pinctrl/xlnx,pinctrl-zynq.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,pinctrl-zynq + + reg: + description: Specifies the base address and size of the SLCR space. + maxItems: 1 + + syscon: + description: + phandle to the SLCR. + +patternProperties: + '^(.*-)?(default|gpio-grp)$': + 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] + + power-source: + enum: [1, 2, 3, 4] + + oneOf: + - required: [ groups ] + - required: [ pins ] + + additionalProperties: false + + additionalProperties: false + +allOf: + - $ref: pinctrl.yaml# + +required: + - compatible + - reg + - syscon + +additionalProperties: false + +examples: + - | + #include + 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>; + power-source = ; + }; + + conf-rx { + pins = "MIO49"; + bias-high-impedance; + }; + + conf-tx { + pins = "MIO48"; + bias-disable; + }; + }; + }; + + uart1 { + pinctrl-names = "default"; + pinctrl-0 = <&pinctrl_uart1_default>; + }; + +... diff --git a/Documentation/devicetree/bindings/pinctrl/xlnx,zynq-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/xlnx,zynq-pinctrl.yaml deleted file mode 100644 index d2676f92ef5b..000000000000 --- a/Documentation/devicetree/bindings/pinctrl/xlnx,zynq-pinctrl.yaml +++ /dev/null @@ -1,217 +0,0 @@ -# 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-grp)$': - 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] - - power-source: - enum: [1, 2, 3, 4] - - oneOf: - - required: [ groups ] - - required: [ pins ] - - additionalProperties: false - - additionalProperties: false - -allOf: - - $ref: pinctrl.yaml# - -required: - - compatible - - reg - - syscon - -additionalProperties: false - -examples: - - | - #include - 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>; - power-source = ; - }; - - 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 f935a52d03a6f0ffdf298763f365194d7978920a Mon Sep 17 00:00:00 2001 From: Michal Simek Date: Tue, 23 Jan 2024 15:16:44 +0100 Subject: dt-bindings: soc: xilinx: Add support for K26 rev2 SOMs Revision 2 is SW compatible with revision 1 but it is necessary to reflect it in model and compatible properties which are parsed by user space. Rev 2 has improved a power on boot reset and MIO34 shutdown glich improvement done via an additional filter in the GreenPak chip. Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/90e1a393154c3d87e8ee7dc9eef07fc937c1eaf7.1706019397.git.michal.simek@amd.com Signed-off-by: Michal Simek --- .../devicetree/bindings/soc/xilinx/xilinx.yaml | 36 ++++++++++++++++------ 1 file changed, 26 insertions(+), 10 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/soc/xilinx/xilinx.yaml b/Documentation/devicetree/bindings/soc/xilinx/xilinx.yaml index d4c0fe1fe435..7c75dbb4f307 100644 --- a/Documentation/devicetree/bindings/soc/xilinx/xilinx.yaml +++ b/Documentation/devicetree/bindings/soc/xilinx/xilinx.yaml @@ -117,20 +117,36 @@ properties: - const: xlnx,zynqmp - description: Xilinx Kria SOMs + minItems: 3 items: - - const: xlnx,zynqmp-sm-k26-rev1 - - const: xlnx,zynqmp-sm-k26-revB - - const: xlnx,zynqmp-sm-k26-revA - - const: xlnx,zynqmp-sm-k26 - - const: xlnx,zynqmp + enum: + - xlnx,zynqmp-sm-k26-rev2 + - xlnx,zynqmp-sm-k26-rev1 + - xlnx,zynqmp-sm-k26-revB + - xlnx,zynqmp-sm-k26-revA + - xlnx,zynqmp-sm-k26 + - xlnx,zynqmp + allOf: + - contains: + const: xlnx,zynqmp + - contains: + const: xlnx,zynqmp-sm-k26 - description: Xilinx Kria SOMs (starter) + minItems: 3 items: - - const: xlnx,zynqmp-smk-k26-rev1 - - const: xlnx,zynqmp-smk-k26-revB - - const: xlnx,zynqmp-smk-k26-revA - - const: xlnx,zynqmp-smk-k26 - - const: xlnx,zynqmp + enum: + - xlnx,zynqmp-smk-k26-rev2 + - xlnx,zynqmp-smk-k26-rev1 + - xlnx,zynqmp-smk-k26-revB + - xlnx,zynqmp-smk-k26-revA + - xlnx,zynqmp-smk-k26 + - xlnx,zynqmp + allOf: + - contains: + const: xlnx,zynqmp + - contains: + const: xlnx,zynqmp-smk-k26 - description: AMD MicroBlaze V (QEMU) items: -- cgit v1.2.3 From dbcd27526e6abee1c65cdf350c232a6e5c2afb47 Mon Sep 17 00:00:00 2001 From: Michal Simek Date: Tue, 23 Jan 2024 15:23:08 +0100 Subject: dt-bindings: soc: xilinx: Add support for KV260 CC When DT overlay is applied at run time compatible string or model AFAIK is not updated. But when fdtoverlay tool is used it actually creates full description for used SOM and carrier card(CC). That's why there is no reason to use generic SOM name and its compatible strings because they are not properly reflected in newly created DT. Composing dt overlays together was introduced by commit 7a4c31ee877a ("arm64: zynqmp: Add support for Xilinx Kria SOM board") and later renamed by commit 45fe0dc4ea2e ("arm64: xilinx: Use zynqmp prefix for SOM dt overlays"). DTB selection is done prior booting OS that's why there is no need to do run time composition for SOM and CC combination. And user space can use compatible string and all listed revisions to figured it out which SOM and CC combinations OS is running at. Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/14c184225cc4f0a61da5f8c98bc0767f8deba0df.1706019781.git.michal.simek@amd.com Signed-off-by: Michal Simek --- .../devicetree/bindings/soc/xilinx/xilinx.yaml | 34 ++++++++++++++++++++++ 1 file changed, 34 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/soc/xilinx/xilinx.yaml b/Documentation/devicetree/bindings/soc/xilinx/xilinx.yaml index 7c75dbb4f307..131aba5ed9f4 100644 --- a/Documentation/devicetree/bindings/soc/xilinx/xilinx.yaml +++ b/Documentation/devicetree/bindings/soc/xilinx/xilinx.yaml @@ -148,6 +148,40 @@ properties: - contains: const: xlnx,zynqmp-smk-k26 + - description: Xilinx Kria SOM KV260 revA/Y/Z + minItems: 3 + items: + enum: + - xlnx,zynqmp-sk-kv260-revA + - xlnx,zynqmp-sk-kv260-revY + - xlnx,zynqmp-sk-kv260-revZ + - xlnx,zynqmp-sk-kv260 + - xlnx,zynqmp + allOf: + - contains: + const: xlnx,zynqmp-sk-kv260-revA + - contains: + const: xlnx,zynqmp-sk-kv260 + - contains: + const: xlnx,zynqmp + + - description: Xilinx Kria SOM KV260 rev2/1/B + minItems: 3 + items: + enum: + - xlnx,zynqmp-sk-kv260-rev2 + - xlnx,zynqmp-sk-kv260-rev1 + - xlnx,zynqmp-sk-kv260-revB + - xlnx,zynqmp-sk-kv260 + - xlnx,zynqmp + allOf: + - contains: + const: xlnx,zynqmp-sk-kv260-revB + - contains: + const: xlnx,zynqmp-sk-kv260 + - contains: + const: xlnx,zynqmp + - description: AMD MicroBlaze V (QEMU) items: - const: qemu,mbv -- cgit v1.2.3 From 2a8998479328a6eb6a2b07a68c7a756fe717b9e2 Mon Sep 17 00:00:00 2001 From: Geert Uytterhoeven Date: Thu, 25 Jan 2024 16:34:29 +0100 Subject: dt-bindings: clock: renesas,cpg-mssr: Document R-Car V4M support MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Document support for the Clock Pulse Generator (CPG) and Module Standby Software Reset (MSSR) module on the Renesas R-Car V4M (R8A779H0) SoC. Signed-off-by: Geert Uytterhoeven Acked-by: Conor Dooley Reviewed-by: Niklas Söderlund Reviewed-by: Wolfram Sang Link: https://lore.kernel.org/r/eb3cd02b62f3ca834df079a3f1e551d9414fe42a.1706194617.git.geert+renesas@glider.be --- Documentation/devicetree/bindings/clock/renesas,cpg-mssr.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/renesas,cpg-mssr.yaml b/Documentation/devicetree/bindings/clock/renesas,cpg-mssr.yaml index 9c3dc6c4fa94..084259d30232 100644 --- a/Documentation/devicetree/bindings/clock/renesas,cpg-mssr.yaml +++ b/Documentation/devicetree/bindings/clock/renesas,cpg-mssr.yaml @@ -50,6 +50,7 @@ properties: - renesas,r8a779a0-cpg-mssr # R-Car V3U - renesas,r8a779f0-cpg-mssr # R-Car S4-8 - renesas,r8a779g0-cpg-mssr # R-Car V4H + - renesas,r8a779h0-cpg-mssr # R-Car V4M reg: maxItems: 1 -- cgit v1.2.3 From 53e41b76a8ff27f4969e3816c0ce3a1af8156091 Mon Sep 17 00:00:00 2001 From: Cristian Ciocaltea Date: Fri, 26 Jan 2024 21:21:25 +0200 Subject: dt-bindings: net: starfive,jh7110-dwmac: Add JH7100 SoC compatible The Synopsys DesignWare MAC found on StarFive JH7100 SoC is mostly similar to the newer JH7110, but it requires only two interrupts and a single reset line, which is 'ahb' instead of the commonly used 'stmmaceth'. Since the common binding 'snps,dwmac' allows selecting 'ahb' only in conjunction with 'stmmaceth', extend the logic to also permit exclusive usage of the 'ahb' reset name. This ensures the following use cases are supported: JH7110: reset-names = "stmmaceth", "ahb"; JH7100: reset-names = "ahb"; other: reset-names = "stmmaceth"; Also note the need to use a different dwmac fallback, as v5.20 applies to JH7110 only, while JH7100 relies on v3.7x. Additionally, drop the reset description items from top-level binding as they are already provided by the included snps,dwmac schema. Signed-off-by: Cristian Ciocaltea Reviewed-by: Jacob Keller Reviewed-by: Rob Herring Reviewed-by: Krzysztof Kozlowski Signed-off-by: David S. Miller --- .../devicetree/bindings/net/snps,dwmac.yaml | 11 ++-- .../bindings/net/starfive,jh7110-dwmac.yaml | 72 +++++++++++++++------- 2 files changed, 57 insertions(+), 26 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/snps,dwmac.yaml b/Documentation/devicetree/bindings/net/snps,dwmac.yaml index 5c2769dc689a..90c4db178c67 100644 --- a/Documentation/devicetree/bindings/net/snps,dwmac.yaml +++ b/Documentation/devicetree/bindings/net/snps,dwmac.yaml @@ -95,6 +95,7 @@ properties: - snps,dwmac-5.20 - snps,dwxgmac - snps,dwxgmac-2.10 + - starfive,jh7100-dwmac - starfive,jh7110-dwmac reg: @@ -144,10 +145,12 @@ properties: - description: AHB reset reset-names: - minItems: 1 - items: - - const: stmmaceth - - const: ahb + oneOf: + - items: + - enum: [stmmaceth, ahb] + - items: + - const: stmmaceth + - const: ahb power-domains: maxItems: 1 diff --git a/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml b/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml index 5e7cfbbebce6..0d1962980f57 100644 --- a/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml +++ b/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml @@ -16,16 +16,20 @@ select: compatible: contains: enum: + - starfive,jh7100-dwmac - starfive,jh7110-dwmac required: - compatible properties: compatible: - items: - - enum: - - starfive,jh7110-dwmac - - const: snps,dwmac-5.20 + oneOf: + - items: + - const: starfive,jh7100-dwmac + - const: snps,dwmac + - items: + - const: starfive,jh7110-dwmac + - const: snps,dwmac-5.20 reg: maxItems: 1 @@ -46,24 +50,6 @@ properties: - const: tx - const: gtx - interrupts: - minItems: 3 - maxItems: 3 - - interrupt-names: - minItems: 3 - maxItems: 3 - - resets: - items: - - description: MAC Reset signal. - - description: AHB Reset signal. - - reset-names: - items: - - const: stmmaceth - - const: ahb - starfive,tx-use-rgmii-clk: description: Tx clock is provided by external rgmii clock. @@ -94,6 +80,48 @@ required: allOf: - $ref: snps,dwmac.yaml# + - if: + properties: + compatible: + contains: + const: starfive,jh7100-dwmac + then: + properties: + interrupts: + minItems: 2 + maxItems: 2 + + interrupt-names: + minItems: 2 + maxItems: 2 + + resets: + maxItems: 1 + + reset-names: + const: ahb + + - if: + properties: + compatible: + contains: + const: starfive,jh7110-dwmac + then: + properties: + interrupts: + minItems: 3 + maxItems: 3 + + interrupt-names: + minItems: 3 + maxItems: 3 + + resets: + minItems: 2 + + reset-names: + minItems: 2 + unevaluatedProperties: false examples: -- cgit v1.2.3 From 2a0683be5b4c9829e8335e494a21d1148e832822 Mon Sep 17 00:00:00 2001 From: Benjamin Poirier Date: Fri, 26 Jan 2024 18:21:18 -0500 Subject: selftests: Introduce Makefile variable to list shared bash scripts Some tests written in bash source other files in a parent directory. For example, drivers/net/bonding/dev_addr_lists.sh sources net/forwarding/lib.sh. If a subset of tests is exported and run outside the source tree (for example by using `make -C tools/testing/selftests gen_tar TARGETS="drivers/net/bonding"`), these other files must be made available as well. Commit ae108c48b5d2 ("selftests: net: Fix cross-tree inclusion of scripts") addressed this problem by symlinking and copying the sourced files but this only works for direct dependencies. Commit 25ae948b4478 ("selftests/net: add lib.sh") changed net/forwarding/lib.sh to source net/lib.sh. As a result, that latter file must be included as well when the former is exported. This was not handled and was reverted in commit 2114e83381d3 ("selftests: forwarding: Avoid failures to source net/lib.sh"). In order to allow reinstating the inclusion of net/lib.sh from net/forwarding/lib.sh, add a mechanism to list dependent files in a new Makefile variable and export them. This allows sourcing those files using the same expression whether tests are run in-tree or exported. Dependencies are not resolved recursively so transitive dependencies must be listed in TEST_INCLUDES. For example, if net/forwarding/lib.sh sources net/lib.sh; the Makefile related to a test that sources net/forwarding/lib.sh from a parent directory must list: TEST_INCLUDES := \ ../../../net/forwarding/lib.sh \ ../../../net/lib.sh v2: Fix rst syntax in Documentation/dev-tools/kselftest.rst (Jakub Kicinski) v1 (from RFC): * changed TEST_INCLUDES to take relative paths, like other TEST_* variables (Vladimir Oltean) * preserved common "$(MAKE) OUTPUT=... -C ... target" ordering in Makefile (Petr Machata) Signed-off-by: Benjamin Poirier Signed-off-by: David S. Miller --- Documentation/dev-tools/kselftest.rst | 12 ++++++++++++ tools/testing/selftests/Makefile | 7 ++++++- tools/testing/selftests/lib.mk | 19 +++++++++++++++++++ 3 files changed, 37 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/dev-tools/kselftest.rst b/Documentation/dev-tools/kselftest.rst index ab376b316c36..522214c7b43b 100644 --- a/Documentation/dev-tools/kselftest.rst +++ b/Documentation/dev-tools/kselftest.rst @@ -255,9 +255,21 @@ Contributing new tests (details) TEST_PROGS_EXTENDED, TEST_GEN_PROGS_EXTENDED mean it is the executable which is not tested by default. + TEST_FILES, TEST_GEN_FILES mean it is the file which is used by test. + TEST_INCLUDES is similar to TEST_FILES, it lists files which should be + included when exporting or installing the tests, with the following + differences: + + * symlinks to files in other directories are preserved + * the part of paths below tools/testing/selftests/ is preserved when + copying the files to the output directory + + TEST_INCLUDES is meant to list dependencies located in other directories of + the selftests hierarchy. + * First use the headers inside the kernel source and/or git repo, and then the system headers. Headers for the kernel release as opposed to headers installed by the distro on the system should be the primary focus to be able diff --git a/tools/testing/selftests/Makefile b/tools/testing/selftests/Makefile index 15b6a111c3be..082db6b68060 100644 --- a/tools/testing/selftests/Makefile +++ b/tools/testing/selftests/Makefile @@ -191,6 +191,8 @@ run_tests: all @for TARGET in $(TARGETS); do \ BUILD_TARGET=$$BUILD/$$TARGET; \ $(MAKE) OUTPUT=$$BUILD_TARGET -C $$TARGET run_tests \ + SRC_PATH=$(shell readlink -e $$(pwd)) \ + OBJ_PATH=$(BUILD) \ O=$(abs_objtree); \ done; @@ -241,7 +243,10 @@ ifdef INSTALL_PATH @ret=1; \ for TARGET in $(TARGETS); do \ BUILD_TARGET=$$BUILD/$$TARGET; \ - $(MAKE) OUTPUT=$$BUILD_TARGET -C $$TARGET INSTALL_PATH=$(INSTALL_PATH)/$$TARGET install \ + $(MAKE) OUTPUT=$$BUILD_TARGET -C $$TARGET install \ + INSTALL_PATH=$(INSTALL_PATH)/$$TARGET \ + SRC_PATH=$(shell readlink -e $$(pwd)) \ + OBJ_PATH=$(INSTALL_PATH) \ O=$(abs_objtree) \ $(if $(FORCE_TARGETS),|| exit); \ ret=$$((ret * $$?)); \ diff --git a/tools/testing/selftests/lib.mk b/tools/testing/selftests/lib.mk index aa646e0661f3..087fee22dd53 100644 --- a/tools/testing/selftests/lib.mk +++ b/tools/testing/selftests/lib.mk @@ -69,11 +69,29 @@ define RUN_TESTS run_many $(1) endef +define INSTALL_INCLUDES + $(if $(TEST_INCLUDES), \ + relative_files=""; \ + for entry in $(TEST_INCLUDES); do \ + entry_dir=$$(readlink -e "$$(dirname "$$entry")"); \ + entry_name=$$(basename "$$entry"); \ + relative_dir=$${entry_dir#"$$SRC_PATH"/}; \ + if [ "$$relative_dir" = "$$entry_dir" ]; then \ + echo "Error: TEST_INCLUDES entry \"$$entry\" not located inside selftests directory ($$SRC_PATH)" >&2; \ + exit 1; \ + fi; \ + relative_files="$$relative_files $$relative_dir/$$entry_name"; \ + done; \ + cd $(SRC_PATH) && rsync -aR $$relative_files $(OBJ_PATH)/ \ + ) +endef + run_tests: all ifdef building_out_of_srctree @if [ "X$(TEST_PROGS)$(TEST_PROGS_EXTENDED)$(TEST_FILES)" != "X" ]; then \ rsync -aq --copy-unsafe-links $(TEST_PROGS) $(TEST_PROGS_EXTENDED) $(TEST_FILES) $(OUTPUT); \ fi + @$(INSTALL_INCLUDES) @if [ "X$(TEST_PROGS)" != "X" ]; then \ $(call RUN_TESTS, $(TEST_GEN_PROGS) $(TEST_CUSTOM_PROGS) \ $(addprefix $(OUTPUT)/,$(TEST_PROGS))) ; \ @@ -103,6 +121,7 @@ endef install: all ifdef INSTALL_PATH $(INSTALL_RULE) + $(INSTALL_INCLUDES) else $(error Error: set INSTALL_PATH to use install) endif -- cgit v1.2.3 From 47878b451216cf5e5a23bb3f931a9f932464e93d Mon Sep 17 00:00:00 2001 From: Adam Skladowski Date: Wed, 20 Dec 2023 11:38:49 +0100 Subject: dt-bindings: interconnect: Add Qualcomm MSM8909 DT bindings Add bindings for Qualcomm MSM8909 Network-On-Chip interconnect devices. [Stephan: Drop separate mm-snoc that exists downstream since it's actually the same NoC as SNoC in hardware] Signed-off-by: Adam Skladowski Reviewed-by: Krzysztof Kozlowski Signed-off-by: Stephan Gerhold Link: https://lore.kernel.org/r/20231220-icc-msm8909-v2-1-3b68bbed2891@kernkonzept.com Signed-off-by: Georgi Djakov --- .../devicetree/bindings/interconnect/qcom,rpm.yaml | 3 + include/dt-bindings/interconnect/qcom,msm8909.h | 93 ++++++++++++++++++++++ 2 files changed, 96 insertions(+) create mode 100644 include/dt-bindings/interconnect/qcom,msm8909.h (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/interconnect/qcom,rpm.yaml b/Documentation/devicetree/bindings/interconnect/qcom,rpm.yaml index 08c1c6b9d7cf..5aaa92a7cef7 100644 --- a/Documentation/devicetree/bindings/interconnect/qcom,rpm.yaml +++ b/Documentation/devicetree/bindings/interconnect/qcom,rpm.yaml @@ -23,6 +23,9 @@ properties: compatible: enum: + - qcom,msm8909-bimc + - qcom,msm8909-pcnoc + - qcom,msm8909-snoc - qcom,msm8916-bimc - qcom,msm8916-pcnoc - qcom,msm8916-snoc diff --git a/include/dt-bindings/interconnect/qcom,msm8909.h b/include/dt-bindings/interconnect/qcom,msm8909.h new file mode 100644 index 000000000000..76365d8aec21 --- /dev/null +++ b/include/dt-bindings/interconnect/qcom,msm8909.h @@ -0,0 +1,93 @@ +/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */ +/* + * Qualcomm MSM8909 interconnect IDs + */ + +#ifndef __DT_BINDINGS_INTERCONNECT_QCOM_MSM8909_H +#define __DT_BINDINGS_INTERCONNECT_QCOM_MSM8909_H + +/* BIMC fabric */ +#define MAS_APPS_PROC 0 +#define MAS_OXILI 1 +#define MAS_SNOC_BIMC_0 2 +#define MAS_SNOC_BIMC_1 3 +#define MAS_TCU_0 4 +#define MAS_TCU_1 5 +#define SLV_EBI 6 +#define SLV_BIMC_SNOC 7 + +/* PCNOC fabric */ +#define MAS_AUDIO 0 +#define MAS_SPDM 1 +#define MAS_DEHR 2 +#define MAS_QPIC 3 +#define MAS_BLSP_1 4 +#define MAS_USB_HS 5 +#define MAS_CRYPTO 6 +#define MAS_SDCC_1 7 +#define MAS_SDCC_2 8 +#define MAS_SNOC_PCNOC 9 +#define PCNOC_M_0 10 +#define PCNOC_M_1 11 +#define PCNOC_INT_0 12 +#define PCNOC_INT_1 13 +#define PCNOC_S_0 14 +#define PCNOC_S_1 15 +#define PCNOC_S_2 16 +#define PCNOC_S_3 17 +#define PCNOC_S_4 18 +#define PCNOC_S_5 19 +#define PCNOC_S_7 20 +#define SLV_TCSR 21 +#define SLV_SDCC_1 22 +#define SLV_BLSP_1 23 +#define SLV_CRYPTO_0_CFG 24 +#define SLV_MESSAGE_RAM 25 +#define SLV_PDM 26 +#define SLV_PRNG 27 +#define SLV_USB_HS 28 +#define SLV_QPIC 29 +#define SLV_SPDM 30 +#define SLV_SDCC_2 31 +#define SLV_AUDIO 32 +#define SLV_DEHR_CFG 33 +#define SLV_SNOC_CFG 34 +#define SLV_QDSS_CFG 35 +#define SLV_USB_PHY 36 +#define SLV_CAMERA_SS_CFG 37 +#define SLV_DISP_SS_CFG 38 +#define SLV_VENUS_CFG 39 +#define SLV_TLMM 40 +#define SLV_GPU_CFG 41 +#define SLV_IMEM_CFG 42 +#define SLV_BIMC_CFG 43 +#define SLV_PMIC_ARB 44 +#define SLV_TCU 45 +#define SLV_PCNOC_SNOC 46 + +/* SNOC fabric */ +#define MAS_QDSS_BAM 0 +#define MAS_BIMC_SNOC 1 +#define MAS_MDP 2 +#define MAS_PCNOC_SNOC 3 +#define MAS_VENUS 4 +#define MAS_VFE 5 +#define MAS_QDSS_ETR 6 +#define MM_INT_0 7 +#define MM_INT_1 8 +#define MM_INT_2 9 +#define MM_INT_BIMC 10 +#define QDSS_INT 11 +#define SNOC_INT_0 12 +#define SNOC_INT_1 13 +#define SNOC_INT_BIMC 14 +#define SLV_KPSS_AHB 15 +#define SLV_SNOC_BIMC_0 16 +#define SLV_SNOC_BIMC_1 17 +#define SLV_IMEM 18 +#define SLV_SNOC_PCNOC 19 +#define SLV_QDSS_STM 20 +#define SLV_CATS_0 21 +#define SLV_CATS_1 22 + +#endif /* __DT_BINDINGS_INTERCONNECT_QCOM_MSM8909_H */ -- cgit v1.2.3 From 3a004e1fee4ba3d37976c1a9707869acc8d60b55 Mon Sep 17 00:00:00 2001 From: Meng Li Date: Fri, 19 Jan 2024 17:05:01 +0800 Subject: Documentation: amd-pstate: introduce amd-pstate preferred core Introduce amd-pstate preferred core. check preferred core state set by the kernel parameter: $ cat /sys/devices/system/cpu/amd-pstate/prefcore Tested-by: Oleksandr Natalenko Reviewed-by: Wyes Karny Reviewed-by: Mario Limonciello Reviewed-by: Huang Rui Reviewed-by: Perry Yuan Signed-off-by: Meng Li Signed-off-by: Rafael J. Wysocki --- Documentation/admin-guide/pm/amd-pstate.rst | 59 ++++++++++++++++++++++++++++- 1 file changed, 57 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/admin-guide/pm/amd-pstate.rst b/Documentation/admin-guide/pm/amd-pstate.rst index 9eb26014d34b..0a3aa6b8ffd5 100644 --- a/Documentation/admin-guide/pm/amd-pstate.rst +++ b/Documentation/admin-guide/pm/amd-pstate.rst @@ -300,8 +300,8 @@ platforms. The AMD P-States mechanism is the more performance and energy efficiency frequency management method on AMD processors. -AMD Pstate Driver Operation Modes -================================= +``amd-pstate`` Driver Operation Modes +====================================== ``amd_pstate`` CPPC has 3 operation modes: autonomous (active) mode, non-autonomous (passive) mode and guided autonomous (guided) mode. @@ -353,6 +353,48 @@ is activated. In this mode, driver requests minimum and maximum performance level and the platform autonomously selects a performance level in this range and appropriate to the current workload. +``amd-pstate`` Preferred Core +================================= + +The core frequency is subjected to the process variation in semiconductors. +Not all cores are able to reach the maximum frequency respecting the +infrastructure limits. Consequently, AMD has redefined the concept of +maximum frequency of a part. This means that a fraction of cores can reach +maximum frequency. To find the best process scheduling policy for a given +scenario, OS needs to know the core ordering informed by the platform through +highest performance capability register of the CPPC interface. + +``amd-pstate`` preferred core enables the scheduler to prefer scheduling on +cores that can achieve a higher frequency with lower voltage. The preferred +core rankings can dynamically change based on the workload, platform conditions, +thermals and ageing. + +The priority metric will be initialized by the ``amd-pstate`` driver. The ``amd-pstate`` +driver will also determine whether or not ``amd-pstate`` preferred core is +supported by the platform. + +``amd-pstate`` driver will provide an initial core ordering when the system boots. +The platform uses the CPPC interfaces to communicate the core ranking to the +operating system and scheduler to make sure that OS is choosing the cores +with highest performance firstly for scheduling the process. When ``amd-pstate`` +driver receives a message with the highest performance change, it will +update the core ranking and set the cpu's priority. + +``amd-pstate`` Preferred Core Switch +================================= +Kernel Parameters +----------------- + +``amd-pstate`` peferred core`` has two states: enable and disable. +Enable/disable states can be chosen by different kernel parameters. +Default enable ``amd-pstate`` preferred core. + +``amd_prefcore=disable`` + +For systems that support ``amd-pstate`` preferred core, the core rankings will +always be advertised by the platform. But OS can choose to ignore that via the +kernel parameter ``amd_prefcore=disable``. + User Space Interface in ``sysfs`` - General =========================================== @@ -385,6 +427,19 @@ control its functionality at the system level. They are located in the to the operation mode represented by that string - or to be unregistered in the "disable" case. +``prefcore`` + Preferred core state of the driver: "enabled" or "disabled". + + "enabled" + Enable the ``amd-pstate`` preferred core. + + "disabled" + Disable the ``amd-pstate`` preferred core + + + This attribute is read-only to check the state of preferred core set + by the kernel parameter. + ``cpupower`` tool support for ``amd-pstate`` =============================================== -- cgit v1.2.3 From dfddf34a3f0d45483f5b3e46c2e7bda173796f1b Mon Sep 17 00:00:00 2001 From: Meng Li Date: Fri, 19 Jan 2024 17:05:02 +0800 Subject: Documentation: introduce amd-pstate preferrd core mode kernel command line options amd-pstate driver support enable/disable preferred core. Default enabled on platforms supporting amd-pstate preferred core. Disable amd-pstate preferred core with "amd_prefcore=disable" added to the kernel command line. Signed-off-by: Meng Li Reviewed-by: Mario Limonciello Reviewed-by: Wyes Karny Reviewed-by: Huang Rui Reviewed-by: Perry Yuan Tested-by: Oleksandr Natalenko Signed-off-by: Rafael J. Wysocki --- 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 31b3a25680d0..522530432548 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -374,6 +374,11 @@ selects a performance level in this range and appropriate to the current workload. + amd_prefcore= + [X86] + disable + Disable amd-pstate preferred core. + amijoy.map= [HW,JOY] Amiga joystick support Map of devices attached to JOY0DAT and JOY1DAT Format: , -- cgit v1.2.3 From cd508bba82e4e0f405f593d7ada8067ebba289cb Mon Sep 17 00:00:00 2001 From: Geert Uytterhoeven Date: Thu, 25 Jan 2024 16:34:33 +0100 Subject: dt-bindings: reset: renesas,rst: Document R-Car V4M support MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Document support for the Reset (RST) module in the Renesas R-Car V4M (R8A779H0) SoC. Signed-off-by: Geert Uytterhoeven Acked-by: Conor Dooley Reviewed-by: Niklas Söderlund Reviewed-by: Wolfram Sang Link: https://lore.kernel.org/r/bd26299d687412c20fea5e2d57195a763cc532e9.1706194617.git.geert+renesas@glider.be --- Documentation/devicetree/bindings/reset/renesas,rst.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/reset/renesas,rst.yaml b/Documentation/devicetree/bindings/reset/renesas,rst.yaml index e7e487247751..58b4a45d3380 100644 --- a/Documentation/devicetree/bindings/reset/renesas,rst.yaml +++ b/Documentation/devicetree/bindings/reset/renesas,rst.yaml @@ -50,6 +50,7 @@ properties: - renesas,r8a779a0-rst # R-Car V3U - renesas,r8a779f0-rst # R-Car S4-8 - renesas,r8a779g0-rst # R-Car V4H + - renesas,r8a779h0-rst # R-Car V4M reg: maxItems: 1 -- cgit v1.2.3 From 49558e814fefdf33bf0b2d1c46c30d6a3f9634f3 Mon Sep 17 00:00:00 2001 From: Geert Uytterhoeven Date: Thu, 25 Jan 2024 16:34:34 +0100 Subject: dt-bindings: soc: renesas: Document R-Car V4M Gray Hawk Single Document the compatible values for the Renesas R-Car V4M (R8A779H0) SoC and the Renesas Gray Hawk Single development board. Signed-off-by: Geert Uytterhoeven Acked-by: Conor Dooley Reviewed-by: Wolfram Sang Link: https://lore.kernel.org/r/1065a81afb8dbed09b0098b51dc7fb22da421a97.1706194617.git.geert+renesas@glider.be --- Documentation/devicetree/bindings/soc/renesas/renesas.yaml | 6 ++++++ 1 file changed, 6 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/soc/renesas/renesas.yaml b/Documentation/devicetree/bindings/soc/renesas/renesas.yaml index 15b9dd529389..1a228dd4822c 100644 --- a/Documentation/devicetree/bindings/soc/renesas/renesas.yaml +++ b/Documentation/devicetree/bindings/soc/renesas/renesas.yaml @@ -361,6 +361,12 @@ properties: - const: renesas,white-hawk-cpu - const: renesas,r8a779g0 + - description: R-Car V4M (R8A779H0) + items: + - enum: + - renesas,gray-hawk-single # Gray Hawk Single board (RTP8A779H0ASKB0F10S) + - const: renesas,r8a779h0 + - description: R-Car H3e (R8A779M0) items: - enum: -- cgit v1.2.3 From 0076a37a426b6c850a0b41b814952760e4a70fcf Mon Sep 17 00:00:00 2001 From: Geert Uytterhoeven Date: Wed, 31 Jan 2024 17:11:45 +0100 Subject: dt-bindings: timer: renesas,tmu: Document input capture interrupt MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Some Timer Unit (TMU) instances with 3 channels support a fourth interrupt: an input capture interrupt for the third channel. While at it, document the meaning of the four interrupts, and add "interrupt-names" for clarity. Update the example to match reality. Inspired by a patch by Yoshinori Sato for SH. Signed-off-by: Geert Uytterhoeven Reviewed-by: Niklas Söderlund Reviewed-by: Wolfram Sang Signed-off-by: Daniel Lezcano Link: https://lore.kernel.org/r/8cb38b5236213a467c6c0073f97ccc4bfd5a39ff.1706717378.git.geert+renesas@glider.be --- .../devicetree/bindings/timer/renesas,tmu.yaml | 18 ++++++++++++++++-- 1 file changed, 16 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/timer/renesas,tmu.yaml b/Documentation/devicetree/bindings/timer/renesas,tmu.yaml index a67e427a9e7e..84bbe15028a1 100644 --- a/Documentation/devicetree/bindings/timer/renesas,tmu.yaml +++ b/Documentation/devicetree/bindings/timer/renesas,tmu.yaml @@ -46,7 +46,19 @@ properties: interrupts: minItems: 2 - maxItems: 3 + items: + - description: Underflow interrupt, channel 0 + - description: Underflow interrupt, channel 1 + - description: Underflow interrupt, channel 2 + - description: Input capture interrupt, channel 2 + + interrupt-names: + minItems: 2 + items: + - const: tuni0 + - const: tuni1 + - const: tuni2 + - const: ticpi2 clocks: maxItems: 1 @@ -100,7 +112,9 @@ examples: reg = <0xffd80000 0x30>; interrupts = , , - ; + , + ; + interrupt-names = "tuni0", "tuni1", "tuni2", "ticpi2"; clocks = <&mstp0_clks R8A7779_CLK_TMU0>; clock-names = "fck"; power-domains = <&sysc R8A7779_PD_ALWAYS_ON>; -- cgit v1.2.3 From 442fd190d3471afdfd9ac8e067bc5e2aff88213c Mon Sep 17 00:00:00 2001 From: Rob Herring Date: Mon, 22 Jan 2024 15:15:26 -0600 Subject: MAINTAINERS: Drop my "+dt" sub-address I never really implemented any filtering on the "+dt" sub-address, so drop it. Acked-by: Wolfram Sang # for I2C Link: https://lore.kernel.org/r/20240122211528.1719994-1-robh@kernel.org Signed-off-by: Rob Herring --- Documentation/devicetree/bindings/gpio/mrvl-gpio.yaml | 2 +- Documentation/devicetree/bindings/i2c/i2c-pxa.yaml | 2 +- Documentation/devicetree/bindings/rtc/sa1100-rtc.yaml | 2 +- Documentation/devicetree/bindings/timer/mrvl,mmp-timer.yaml | 2 +- MAINTAINERS | 4 ++-- 5 files changed, 6 insertions(+), 6 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/gpio/mrvl-gpio.yaml b/Documentation/devicetree/bindings/gpio/mrvl-gpio.yaml index 9cf6137dd524..65155bb701a9 100644 --- a/Documentation/devicetree/bindings/gpio/mrvl-gpio.yaml +++ b/Documentation/devicetree/bindings/gpio/mrvl-gpio.yaml @@ -9,7 +9,7 @@ title: Marvell PXA GPIO controller maintainers: - Linus Walleij - Bartosz Golaszewski - - Rob Herring + - Rob Herring allOf: - if: diff --git a/Documentation/devicetree/bindings/i2c/i2c-pxa.yaml b/Documentation/devicetree/bindings/i2c/i2c-pxa.yaml index 31386a8d7684..e89ee361741e 100644 --- a/Documentation/devicetree/bindings/i2c/i2c-pxa.yaml +++ b/Documentation/devicetree/bindings/i2c/i2c-pxa.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Marvell MMP I2C controller maintainers: - - Rob Herring + - Rob Herring allOf: - $ref: /schemas/i2c/i2c-controller.yaml# diff --git a/Documentation/devicetree/bindings/rtc/sa1100-rtc.yaml b/Documentation/devicetree/bindings/rtc/sa1100-rtc.yaml index a16c355dcd11..fcf52d2cac9e 100644 --- a/Documentation/devicetree/bindings/rtc/sa1100-rtc.yaml +++ b/Documentation/devicetree/bindings/rtc/sa1100-rtc.yaml @@ -12,7 +12,7 @@ allOf: maintainers: - Alessandro Zummo - Alexandre Belloni - - Rob Herring + - Rob Herring properties: compatible: diff --git a/Documentation/devicetree/bindings/timer/mrvl,mmp-timer.yaml b/Documentation/devicetree/bindings/timer/mrvl,mmp-timer.yaml index 1ee4aab695d3..fe6bc4173789 100644 --- a/Documentation/devicetree/bindings/timer/mrvl,mmp-timer.yaml +++ b/Documentation/devicetree/bindings/timer/mrvl,mmp-timer.yaml @@ -9,7 +9,7 @@ title: Marvell MMP Timer maintainers: - Daniel Lezcano - Thomas Gleixner - - Rob Herring + - Rob Herring properties: $nodename: diff --git a/MAINTAINERS b/MAINTAINERS index eda745c0f92a..42b43337c266 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -16358,7 +16358,7 @@ S: Supported F: drivers/infiniband/ulp/opa_vnic OPEN FIRMWARE AND FLATTENED DEVICE TREE -M: Rob Herring +M: Rob Herring L: devicetree@vger.kernel.org S: Maintained W: http://www.devicetree.org/ @@ -16374,7 +16374,7 @@ K: of_overlay_fdt_apply K: of_overlay_remove OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS -M: Rob Herring +M: Rob Herring M: Krzysztof Kozlowski M: Conor Dooley L: devicetree@vger.kernel.org -- cgit v1.2.3 From 85f838adad5487f96ff3acf6d3eb8263a39a0757 Mon Sep 17 00:00:00 2001 From: Michal Simek Date: Mon, 29 Jan 2024 13:18:53 +0100 Subject: dt-bindings: fpga: Convert fpga-region binding to yaml Convert the generic fpga region DT binding to json-schema. There are some differences compare to txt version. 1. DT overlay can't be described in example that's why directly include information from overlay to node which was referenced. It is visible in example with /* DT Overlay contains: &... */ 2. All example have been rewritten to be simpler and describe only full reconfiguration and partial reconfiguration with one bridge. Completely drop the case where fpga region can inside partial reconfiguration region which is already described in description 3. Fixed some typos in descriptions compare to txt version but most of it is just c&p from txt file. Signed-off-by: Michal Simek Link: https://lore.kernel.org/r/37b107d86b39ef4bc9c482b57b27de8b92c3fa43.1706530726.git.michal.simek@amd.com Signed-off-by: Rob Herring --- .../devicetree/bindings/fpga/fpga-region.txt | 479 --------------------- .../devicetree/bindings/fpga/fpga-region.yaml | 358 +++++++++++++++ 2 files changed, 358 insertions(+), 479 deletions(-) delete mode 100644 Documentation/devicetree/bindings/fpga/fpga-region.txt create mode 100644 Documentation/devicetree/bindings/fpga/fpga-region.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/fpga/fpga-region.txt b/Documentation/devicetree/bindings/fpga/fpga-region.txt deleted file mode 100644 index 528df8a0e6d8..000000000000 --- a/Documentation/devicetree/bindings/fpga/fpga-region.txt +++ /dev/null @@ -1,479 +0,0 @@ -FPGA Region Device Tree Binding - -Alan Tull 2016 - - CONTENTS - - Introduction - - Terminology - - Sequence - - FPGA Region - - Supported Use Models - - Device Tree Examples - - Constraints - - -Introduction -============ - -FPGA Regions represent FPGA's and partial reconfiguration regions of FPGA's in -the Device Tree. FPGA Regions provide a way to program FPGAs under device tree -control. - -This device tree binding document hits some of the high points of FPGA usage and -attempts to include terminology used by both major FPGA manufacturers. This -document isn't a replacement for any manufacturers specifications for FPGA -usage. - - -Terminology -=========== - -Full Reconfiguration - * The entire FPGA is programmed. - -Partial Reconfiguration (PR) - * A section of an FPGA is reprogrammed while the rest of the FPGA is not - affected. - * Not all FPGA's support PR. - -Partial Reconfiguration Region (PRR) - * Also called a "reconfigurable partition" - * 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. - * The connections at the edge of each PRR are fixed. The image that is loaded - into a PRR must fit and must use a subset of the region's connections. - * The busses within the FPGA are split such that each region gets its own - branch that may be gated independently. - -Persona - * Also called a "partial bit stream" - * An FPGA image that is designed to be loaded into a PRR. There may be - any number of personas designed to fit into a PRR, but only one at at time - may be loaded. - * A persona may create more regions. - -FPGA Bridge - * FPGA Bridges gate bus signals between a host and FPGA. - * FPGA Bridges should be disabled while the FPGA is being programmed to - prevent spurious signals on the cpu bus and to the soft logic. - * FPGA bridges may be actual hardware or soft logic on an FPGA. - * During Full Reconfiguration, hardware bridges between the host and FPGA - will be disabled. - * During Partial Reconfiguration of a specific region, that region's bridge - will be used to gate the busses. Traffic to other regions is not affected. - * In some implementations, the FPGA Manager transparently handles gating the - buses, eliminating the need to show the hardware FPGA bridges in the - device tree. - * An FPGA image may create a set of reprogrammable regions, each having its - own bridge and its own split of the busses in the FPGA. - -FPGA Manager - * An FPGA Manager is a hardware block that programs an FPGA under the control - of a host processor. - -Base Image - * Also called the "static image" - * An FPGA image that is designed to do full reconfiguration of the FPGA. - * A base image may set up a set of partial reconfiguration regions that may - later be reprogrammed. - - ---------------- ---------------------------------- - | Host CPU | | FPGA | - | | | | - | ----| | ----------- -------- | - | | H | | |==>| Bridge0 |<==>| PRR0 | | - | | W | | | ----------- -------- | - | | | | | | - | | B |<=====>|<==| ----------- -------- | - | | R | | |==>| Bridge1 |<==>| PRR1 | | - | | I | | | ----------- -------- | - | | D | | | | - | | G | | | ----------- -------- | - | | E | | |==>| Bridge2 |<==>| PRR2 | | - | ----| | ----------- -------- | - | | | | - ---------------- ---------------------------------- - -Figure 1: An FPGA set up with a base image that created three regions. Each -region (PRR0-2) gets its own split of the busses that is independently gated by -a soft logic bridge (Bridge0-2) in the FPGA. The contents of each PRR can be -reprogrammed independently while the rest of the system continues to function. - - -Sequence -======== - -When a DT overlay that targets an FPGA Region is applied, the FPGA Region will -do the following: - - 1. Disable appropriate FPGA bridges. - 2. Program the FPGA using the FPGA manager. - 3. Enable the FPGA bridges. - 4. The Device Tree overlay is accepted into the live tree. - 5. Child devices are populated. - -When the overlay is removed, the child nodes will be removed and the FPGA Region -will disable the bridges. - - -FPGA Region -=========== - -FPGA Regions represent FPGA's and FPGA PR regions in the device tree. An FPGA -Region brings together the elements needed to program on a running system and -add the child devices: - - * FPGA Manager - * FPGA Bridges - * image-specific information needed to to the programming. - * child nodes - -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 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. - -The base FPGA Region in the device tree represents the FPGA and supports full -reconfiguration. It must include a phandle to an FPGA Manager. The base -FPGA region will be the child of one of the hardware bridges (the bridge that -allows register access) between the cpu and the FPGA. If there are more than -one bridge to control during FPGA programming, the region will also contain a -list of phandles to the additional hardware FPGA Bridges. - -For partial reconfiguration (PR), each PR region will have an FPGA Region. -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 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 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 -shutting down bridges that are upstream from the other active regions while one -region is getting reconfigured (see Figure 1 above). During PR, the FPGA's -hardware bridges remain enabled. The PR regions' bridges will be FPGA bridges -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. 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. - -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 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 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. -- external-fpga-config : boolean, set if the FPGA has already been configured - prior to OS boot up. -- encrypted-fpga-config : boolean, set if the bitstream is encrypted -- region-unfreeze-timeout-us : The maximum time in microseconds to wait for - bridges to successfully become enabled after the region has been - programmed. -- region-freeze-timeout-us : The maximum time in microseconds to wait for - bridges to successfully become disabled before the region has been - programmed. -- config-complete-timeout-us : The maximum time in microseconds time for the - FPGA to go to operating mode after the region has been programmed. -- child nodes : devices in the FPGA after programming. - -In the example below, when an overlay is applied targeting fpga-region0, -fpga_mgr is used to program the FPGA. Two bridges are controlled during -programming: the parent fpga_bridge0 and fpga_bridge1. Because the region is -the child of fpga_bridge0, only fpga_bridge1 needs to be specified in the -fpga-bridges property. During programming, these bridges are disabled, the -firmware specified in the overlay is loaded to the FPGA using the FPGA manager -specified in the region. If FPGA programming succeeds, the bridges are -reenabled and the overlay makes it into the live device tree. The child devices -are then populated. If FPGA programming fails, the bridges are left disabled -and the overlay is rejected. The overlay's ranges property maps the lwhps -bridge's region (0xff200000) and the hps bridge's region (0xc0000000) for use by -the two child devices. - -Example: -Base tree contains: - - fpga_mgr: fpga-mgr@ff706000 { - compatible = "altr,socfpga-fpga-mgr"; - reg = <0xff706000 0x1000 - 0xffb90000 0x20>; - interrupts = <0 175 4>; - }; - - fpga_bridge0: fpga-bridge@ff400000 { - compatible = "altr,socfpga-lwhps2fpga-bridge"; - reg = <0xff400000 0x100000>; - resets = <&rst LWHPS2FPGA_RESET>; - clocks = <&l4_main_clk>; - - #address-cells = <1>; - #size-cells = <1>; - ranges; - - fpga_region0: fpga-region0 { - compatible = "fpga-region"; - fpga-mgr = <&fpga_mgr>; - }; - }; - - fpga_bridge1: fpga-bridge@ff500000 { - compatible = "altr,socfpga-hps2fpga-bridge"; - reg = <0xff500000 0x10000>; - resets = <&rst HPS2FPGA_RESET>; - clocks = <&l4_main_clk>; - }; - -Overlay contains: - -/dts-v1/; -/plugin/; - -&fpga_region0 { - #address-cells = <1>; - #size-cells = <1>; - - firmware-name = "soc_system.rbf"; - fpga-bridges = <&fpga_bridge1>; - ranges = <0x20000 0xff200000 0x100000>, - <0x0 0xc0000000 0x20000000>; - - gpio@10040 { - compatible = "altr,pio-1.0"; - reg = <0x10040 0x20>; - altr,ngpio = <4>; - #gpio-cells = <2>; - clocks = <2>; - gpio-controller; - }; - - onchip-memory { - device_type = "memory"; - compatible = "altr,onchipmem-15.1"; - reg = <0x0 0x10000>; - }; -}; - - -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 an FPGA device. - - * No FPGA Bridges - In this case, the FPGA Manager which programs the FPGA also handles the - bridges behind the scenes. No FPGA Bridge devices are needed for full - reconfiguration. - - * Full reconfiguration with hardware bridges - In this case, there are hardware bridges between the processor and FPGA that - need to be controlled during full reconfiguration. Before the overlay is - applied, the live DT must include the FPGA Manager, FPGA Bridges, and a - FPGA Region. The FPGA Region is the child of the bridge that allows - register access to the FPGA. Additional bridges may be listed in a - fpga-bridges property in the FPGA region or in the device tree overlay. - - * Partial reconfiguration with bridges in the FPGA - In this case, the FPGA will have one or more PRR's that may be programmed - separately while the rest of the FPGA can remain active. To manage this, - 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 an FPGA region for each - PRR. - -Device Tree Examples -==================== - -The intention of this section is to give some simple examples, focusing on -the placement of the elements detailed above, especially: - * FPGA Manager - * FPGA Bridges - * FPGA Region - * ranges - * target-path or target - -For the purposes of this section, I'm dividing the Device Tree into two parts, -each with its own requirements. The two parts are: - * The live DT prior to the overlay being added - * The DT overlay - -The live Device Tree must contain an FPGA Region, an FPGA Manager, and any FPGA -Bridges. The FPGA Region's "fpga-mgr" property specifies the manager by phandle -to handle programming the FPGA. If the FPGA Region is the child of another FPGA -Region, the parent's FPGA Manager is used. If FPGA Bridges need to be involved, -they are specified in the FPGA Region by the "fpga-bridges" property. During -FPGA programming, the FPGA Region will disable the bridges that are in its -"fpga-bridges" list and will re-enable them after FPGA programming has -succeeded. - -The Device Tree Overlay will contain: - * "target-path" or "target" - The insertion point where the contents of the overlay will go into the - live tree. target-path is a full path, while target is a phandle. - * "ranges" - The address space mapping from processor to FPGA bus(ses). - * "firmware-name" - Specifies the name of the FPGA image file on the firmware search - path. The search path is described in the firmware class documentation. - * "partial-fpga-config" - This binding is a boolean and should be present if partial reconfiguration - is to be done. - * child nodes corresponding to hardware that will be loaded in this region of - the FPGA. - -Device Tree Example: Full Reconfiguration without Bridges -========================================================= - -Live Device Tree contains: - fpga_mgr0: fpga-mgr@f8007000 { - compatible = "xlnx,zynq-devcfg-1.0"; - reg = <0xf8007000 0x100>; - interrupt-parent = <&intc>; - interrupts = <0 8 4>; - clocks = <&clkc 12>; - clock-names = "ref_clk"; - syscon = <&slcr>; - }; - - fpga_region0: fpga-region0 { - compatible = "fpga-region"; - fpga-mgr = <&fpga_mgr0>; - #address-cells = <0x1>; - #size-cells = <0x1>; - ranges; - }; - -DT Overlay contains: - -/dts-v1/; -/plugin/; - -&fpga_region0 { - #address-cells = <1>; - #size-cells = <1>; - - firmware-name = "zynq-gpio.bin"; - - gpio1: gpio@40000000 { - compatible = "xlnx,xps-gpio-1.00.a"; - reg = <0x40000000 0x10000>; - gpio-controller; - #gpio-cells = <0x2>; - xlnx,gpio-width= <0x6>; - }; -}; - -Device Tree Example: Full Reconfiguration to add PRR's -====================================================== - -The base FPGA Region is specified similar to the first example above. - -This example programs the FPGA to have two regions that can later be partially -configured. Each region has its own bridge in the FPGA fabric. - -DT Overlay contains: - -/dts-v1/; -/plugin/; - -&fpga_region0 { - #address-cells = <1>; - #size-cells = <1>; - - firmware-name = "base.rbf"; - - fpga-bridge@4400 { - compatible = "altr,freeze-bridge-controller"; - reg = <0x4400 0x10>; - - fpga_region1: fpga-region1 { - compatible = "fpga-region"; - #address-cells = <0x1>; - #size-cells = <0x1>; - ranges; - }; - }; - - fpga-bridge@4420 { - compatible = "altr,freeze-bridge-controller"; - reg = <0x4420 0x10>; - - fpga_region2: fpga-region2 { - compatible = "fpga-region"; - #address-cells = <0x1>; - #size-cells = <0x1>; - ranges; - }; - }; -}; - -Device Tree Example: Partial Reconfiguration -============================================ - -This example reprograms one of the PRR's set up in the previous example. - -The sequence that occurs when this overlay is similar to the above, the only -differences are that the FPGA is partially reconfigured due to the -"partial-fpga-config" boolean and the only bridge that is controlled during -programming is the FPGA based bridge of fpga_region1. - -/dts-v1/; -/plugin/; - -&fpga_region1 { - #address-cells = <1>; - #size-cells = <1>; - - firmware-name = "soc_image2.rbf"; - partial-fpga-config; - - gpio@10040 { - compatible = "altr,pio-1.0"; - reg = <0x10040 0x20>; - clocks = <0x2>; - altr,ngpio = <0x4>; - #gpio-cells = <0x2>; - gpio-controller; - }; -}; - -Constraints -=========== - -It is beyond the scope of this document to fully describe all the FPGA design -constraints required to make partial reconfiguration work[1] [2] [3], but a few -deserve quick mention. - -A persona must have boundary connections that line up with those of the partition -or region it is designed to go into. - -During programming, transactions through those connections must be stopped and -the connections must be held at a fixed logic level. This can be achieved by -FPGA Bridges that exist on the FPGA fabric prior to the partial reconfiguration. - --- -[1] www.altera.com/content/dam/altera-www/global/en_US/pdfs/literature/ug/ug_partrecon.pdf -[2] tspace.library.utoronto.ca/bitstream/1807/67932/1/Byma_Stuart_A_201411_MAS_thesis.pdf -[3] https://www.xilinx.com/support/documentation/sw_manuals/xilinx14_1/ug702.pdf diff --git a/Documentation/devicetree/bindings/fpga/fpga-region.yaml b/Documentation/devicetree/bindings/fpga/fpga-region.yaml new file mode 100644 index 000000000000..77554885a6c4 --- /dev/null +++ b/Documentation/devicetree/bindings/fpga/fpga-region.yaml @@ -0,0 +1,358 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/fpga/fpga-region.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: FPGA Region + +maintainers: + - Michal Simek + +description: | + CONTENTS + - Introduction + - Terminology + - Sequence + - FPGA Region + - Supported Use Models + - Constraints + + + Introduction + ============ + + FPGA Regions represent FPGA's and partial reconfiguration regions of FPGA's in + the Device Tree. FPGA Regions provide a way to program FPGAs under device tree + control. + + The documentation hits some of the high points of FPGA usage and + attempts to include terminology used by both major FPGA manufacturers. This + document isn't a replacement for any manufacturers specifications for FPGA + usage. + + + Terminology + =========== + + Full Reconfiguration + * The entire FPGA is programmed. + + Partial Reconfiguration (PR) + * A section of an FPGA is reprogrammed while the rest of the FPGA is not + affected. + * Not all FPGA's support PR. + + Partial Reconfiguration Region (PRR) + * Also called a "reconfigurable partition" + * 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. + * The connections at the edge of each PRR are fixed. The image that is loaded + into a PRR must fit and must use a subset of the region's connections. + * The busses within the FPGA are split such that each region gets its own + branch that may be gated independently. + + Persona + * Also called a "partial bit stream" + * An FPGA image that is designed to be loaded into a PRR. There may be + any number of personas designed to fit into a PRR, but only one at a time + may be loaded. + * A persona may create more regions. + + FPGA Bridge + * FPGA Bridges gate bus signals between a host and FPGA. + * FPGA Bridges should be disabled while the FPGA is being programmed to + prevent spurious signals on the cpu bus and to the soft logic. + * FPGA bridges may be actual hardware or soft logic on an FPGA. + * During Full Reconfiguration, hardware bridges between the host and FPGA + will be disabled. + * During Partial Reconfiguration of a specific region, that region's bridge + will be used to gate the busses. Traffic to other regions is not affected. + * In some implementations, the FPGA Manager transparently handles gating the + buses, eliminating the need to show the hardware FPGA bridges in the + device tree. + * An FPGA image may create a set of reprogrammable regions, each having its + own bridge and its own split of the busses in the FPGA. + + FPGA Manager + * An FPGA Manager is a hardware block that programs an FPGA under the control + of a host processor. + + Base Image + * Also called the "static image" + * An FPGA image that is designed to do full reconfiguration of the FPGA. + * A base image may set up a set of partial reconfiguration regions that may + later be reprogrammed. + + ---------------- ---------------------------------- + | Host CPU | | FPGA | + | | | | + | ----| | ----------- -------- | + | | H | | |==>| Bridge0 |<==>| PRR0 | | + | | W | | | ----------- -------- | + | | | | | | + | | B |<=====>|<==| ----------- -------- | + | | R | | |==>| Bridge1 |<==>| PRR1 | | + | | I | | | ----------- -------- | + | | D | | | | + | | G | | | ----------- -------- | + | | E | | |==>| Bridge2 |<==>| PRR2 | | + | ----| | ----------- -------- | + | | | | + ---------------- ---------------------------------- + + Figure 1: An FPGA set up with a base image that created three regions. Each + region (PRR0-2) gets its own split of the busses that is independently gated by + a soft logic bridge (Bridge0-2) in the FPGA. The contents of each PRR can be + reprogrammed independently while the rest of the system continues to function. + + + Sequence + ======== + + When a DT overlay that targets an FPGA Region is applied, the FPGA Region will + do the following: + + 1. Disable appropriate FPGA bridges. + 2. Program the FPGA using the FPGA manager. + 3. Enable the FPGA bridges. + 4. The Device Tree overlay is accepted into the live tree. + 5. Child devices are populated. + + When the overlay is removed, the child nodes will be removed and the FPGA Region + will disable the bridges. + + + FPGA Region + =========== + + FPGA Regions represent FPGA's and FPGA PR regions in the device tree. An FPGA + Region brings together the elements needed to program on a running system and + add the child devices: + + * FPGA Manager + * FPGA Bridges + * image-specific information needed to the programming. + * child nodes + + 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 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. + + The base FPGA Region in the device tree represents the FPGA and supports full + reconfiguration. It must include a phandle to an FPGA Manager. The base + FPGA region will be the child of one of the hardware bridges (the bridge that + allows register access) between the cpu and the FPGA. If there are more than + one bridge to control during FPGA programming, the region will also contain a + list of phandles to the additional hardware FPGA Bridges. + + For partial reconfiguration (PR), each PR region will have an FPGA Region. + 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 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 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 + shutting down bridges that are upstream from the other active regions while one + region is getting reconfigured (see Figure 1 above). During PR, the FPGA's + hardware bridges remain enabled. The PR regions' bridges will be FPGA bridges + within the static image of the FPGA. + + + 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 an FPGA device. + + * No FPGA Bridges + In this case, the FPGA Manager which programs the FPGA also handles the + bridges behind the scenes. No FPGA Bridge devices are needed for full + reconfiguration. + + * Full reconfiguration with hardware bridges + In this case, there are hardware bridges between the processor and FPGA that + need to be controlled during full reconfiguration. Before the overlay is + applied, the live DT must include the FPGA Manager, FPGA Bridges, and a + FPGA Region. The FPGA Region is the child of the bridge that allows + register access to the FPGA. Additional bridges may be listed in a + fpga-bridges property in the FPGA region or in the device tree overlay. + + * Partial reconfiguration with bridges in the FPGA + In this case, the FPGA will have one or more PRR's that may be programmed + separately while the rest of the FPGA can remain active. To manage this, + 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 an FPGA region for each + PRR. + + Constraints + =========== + + It is beyond the scope of this document to fully describe all the FPGA design + constraints required to make partial reconfiguration work[1] [2] [3], but a few + deserve quick mention. + + A persona must have boundary connections that line up with those of the partition + or region it is designed to go into. + + During programming, transactions through those connections must be stopped and + the connections must be held at a fixed logic level. This can be achieved by + FPGA Bridges that exist on the FPGA fabric prior to the partial reconfiguration. + + -- + [1] www.altera.com/content/dam/altera-www/global/en_US/pdfs/literature/ug/ug_partrecon.pdf + [2] tspace.library.utoronto.ca/bitstream/1807/67932/1/Byma_Stuart_A_201411_MAS_thesis.pdf + [3] https://www.xilinx.com/support/documentation/sw_manuals/xilinx14_1/ug702.pdf + +properties: + $nodename: + pattern: "^fpga-region(@.*|-([0-9]|[1-9][0-9]+))?$" + + compatible: + const: fpga-region + + reg: + maxItems: 1 + + ranges: true + "#address-cells": true + "#size-cells": true + + config-complete-timeout-us: + description: + The maximum time in microseconds time for the FPGA to go to operating + mode after the region has been programmed. + + encrypted-fpga-config: + type: boolean + description: + Set if the bitstream is encrypted. + + external-fpga-config: + type: boolean + description: + Set if the FPGA has already been configured prior to OS boot up. + + firmware-name: + maxItems: 1 + description: + 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 an FPGA region, it is + a request to program the FPGA with that image. + + fpga-bridges: + $ref: /schemas/types.yaml#/definitions/phandle-array + description: + 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 an fpga-bridge, the list should not + contain the parent bridge. + + fpga-mgr: + $ref: /schemas/types.yaml#/definitions/phandle + description: + Should contain a phandle to an FPGA Manager. Child FPGA Regions + inherit this property from their ancestor regions. An fpga-mgr property + in a region will override any inherited FPGA manager. + + partial-fpga-config: + type: boolean + description: + Set if partial reconfiguration is to be done, otherwise full + reconfiguration is done. + + region-freeze-timeout-us: + description: + The maximum time in microseconds to wait for bridges to successfully + become disabled before the region has been programmed. + + region-unfreeze-timeout-us: + description: + The maximum time in microseconds to wait for bridges to successfully + become enabled after the region has been programmed. + +required: + - compatible + - fpga-mgr + +additionalProperties: + type: object + +examples: + - | + /* + * Full Reconfiguration without Bridges with DT overlay + */ + fpga_region0: fpga-region@0 { + compatible = "fpga-region"; + reg = <0 0>; + #address-cells = <1>; + #size-cells = <1>; + fpga-mgr = <&fpga_mgr0>; + ranges = <0x10000000 0x20000000 0x10000000>; + + /* DT Overlay contains: &fpga_region0 */ + firmware-name = "zynq-gpio.bin"; + gpio@40000000 { + compatible = "xlnx,xps-gpio-1.00.a"; + reg = <0x40000000 0x10000>; + gpio-controller; + #gpio-cells = <2>; + }; + }; + + - | + /* + * Partial reconfiguration with bridge + */ + fpga_region1: fpga-region@0 { + compatible = "fpga-region"; + reg = <0 0>; + ranges; + #address-cells = <1>; + #size-cells = <1>; + fpga-mgr = <&fpga_mgr1>; + fpga-bridges = <&fpga_bridge1>; + partial-fpga-config; + + /* DT Overlay contains: &fpga_region1 */ + firmware-name = "zynq-gpio-partial.bin"; + clk: clock { + compatible = "fixed-factor-clock"; + clocks = <&parentclk>; + #clock-cells = <0>; + clock-div = <2>; + clock-mult = <1>; + }; + axi { + compatible = "simple-bus"; + #address-cells = <1>; + #size-cells = <1>; + ranges; + gpio@40000000 { + compatible = "xlnx,xps-gpio-1.00.a"; + reg = <0x40000000 0x10000>; + #gpio-cells = <2>; + gpio-controller; + clocks = <&clk>; + }; + }; + }; -- cgit v1.2.3 From 6f3189f38a3e995232e028a4c341164c4aca1b20 Mon Sep 17 00:00:00 2001 From: Daniel Xu Date: Sun, 28 Jan 2024 18:24:08 -0700 Subject: bpf: treewide: Annotate BPF kfuncs in BTF This commit marks kfuncs as such inside the .BTF_ids section. The upshot of these annotations is that we'll be able to automatically generate kfunc prototypes for downstream users. The process is as follows: 1. In source, use BTF_KFUNCS_START/END macro pair to mark kfuncs 2. During build, pahole injects into BTF a "bpf_kfunc" BTF_DECL_TAG for each function inside BTF_KFUNCS sets 3. At runtime, vmlinux or module BTF is made available in sysfs 4. At runtime, bpftool (or similar) can look at provided BTF and generate appropriate prototypes for functions with "bpf_kfunc" tag To ensure future kfunc are similarly tagged, we now also return error inside kfunc registration for untagged kfuncs. For vmlinux kfuncs, we also WARN(), as initcall machinery does not handle errors. Signed-off-by: Daniel Xu Acked-by: Benjamin Tissoires Link: https://lore.kernel.org/r/e55150ceecbf0a5d961e608941165c0bee7bc943.1706491398.git.dxu@dxuuu.xyz Signed-off-by: Alexei Starovoitov --- Documentation/bpf/kfuncs.rst | 8 ++++---- drivers/hid/bpf/hid_bpf_dispatch.c | 8 ++++---- fs/verity/measure.c | 4 ++-- kernel/bpf/btf.c | 8 ++++++++ kernel/bpf/cpumask.c | 4 ++-- kernel/bpf/helpers.c | 8 ++++---- kernel/bpf/map_iter.c | 4 ++-- kernel/cgroup/rstat.c | 4 ++-- kernel/trace/bpf_trace.c | 8 ++++---- net/bpf/test_run.c | 8 ++++---- net/core/filter.c | 20 ++++++++++---------- net/core/xdp.c | 4 ++-- net/ipv4/bpf_tcp_ca.c | 4 ++-- net/ipv4/fou_bpf.c | 4 ++-- net/ipv4/tcp_bbr.c | 4 ++-- net/ipv4/tcp_cubic.c | 4 ++-- net/ipv4/tcp_dctcp.c | 4 ++-- net/netfilter/nf_conntrack_bpf.c | 4 ++-- net/netfilter/nf_nat_bpf.c | 4 ++-- net/xfrm/xfrm_interface_bpf.c | 4 ++-- net/xfrm/xfrm_state_bpf.c | 4 ++-- .../testing/selftests/bpf/bpf_testmod/bpf_testmod.c | 8 ++++---- 22 files changed, 70 insertions(+), 62 deletions(-) (limited to 'Documentation') diff --git a/Documentation/bpf/kfuncs.rst b/Documentation/bpf/kfuncs.rst index 7985c6615f3c..a8f5782bd833 100644 --- a/Documentation/bpf/kfuncs.rst +++ b/Documentation/bpf/kfuncs.rst @@ -177,10 +177,10 @@ In addition to kfuncs' arguments, verifier may need more information about the type of kfunc(s) being registered with the BPF subsystem. To do so, we define flags on a set of kfuncs as follows:: - BTF_SET8_START(bpf_task_set) + BTF_KFUNCS_START(bpf_task_set) BTF_ID_FLAGS(func, bpf_get_task_pid, KF_ACQUIRE | KF_RET_NULL) BTF_ID_FLAGS(func, bpf_put_pid, KF_RELEASE) - BTF_SET8_END(bpf_task_set) + BTF_KFUNCS_END(bpf_task_set) This set encodes the BTF ID of each kfunc listed above, and encodes the flags along with it. Ofcourse, it is also allowed to specify no flags. @@ -347,10 +347,10 @@ Once the kfunc is prepared for use, the final step to making it visible is registering it with the BPF subsystem. Registration is done per BPF program type. An example is shown below:: - BTF_SET8_START(bpf_task_set) + BTF_KFUNCS_START(bpf_task_set) BTF_ID_FLAGS(func, bpf_get_task_pid, KF_ACQUIRE | KF_RET_NULL) BTF_ID_FLAGS(func, bpf_put_pid, KF_RELEASE) - BTF_SET8_END(bpf_task_set) + BTF_KFUNCS_END(bpf_task_set) static const struct btf_kfunc_id_set bpf_task_kfunc_set = { .owner = THIS_MODULE, diff --git a/drivers/hid/bpf/hid_bpf_dispatch.c b/drivers/hid/bpf/hid_bpf_dispatch.c index d9ef45fcaeab..02c441aaa217 100644 --- a/drivers/hid/bpf/hid_bpf_dispatch.c +++ b/drivers/hid/bpf/hid_bpf_dispatch.c @@ -172,9 +172,9 @@ hid_bpf_get_data(struct hid_bpf_ctx *ctx, unsigned int offset, const size_t rdwr * The following set contains all functions we agree BPF programs * can use. */ -BTF_SET8_START(hid_bpf_kfunc_ids) +BTF_KFUNCS_START(hid_bpf_kfunc_ids) BTF_ID_FLAGS(func, hid_bpf_get_data, KF_RET_NULL) -BTF_SET8_END(hid_bpf_kfunc_ids) +BTF_KFUNCS_END(hid_bpf_kfunc_ids) static const struct btf_kfunc_id_set hid_bpf_kfunc_set = { .owner = THIS_MODULE, @@ -440,12 +440,12 @@ static const struct btf_kfunc_id_set hid_bpf_fmodret_set = { }; /* for syscall HID-BPF */ -BTF_SET8_START(hid_bpf_syscall_kfunc_ids) +BTF_KFUNCS_START(hid_bpf_syscall_kfunc_ids) BTF_ID_FLAGS(func, hid_bpf_attach_prog) BTF_ID_FLAGS(func, hid_bpf_allocate_context, KF_ACQUIRE | KF_RET_NULL) BTF_ID_FLAGS(func, hid_bpf_release_context, KF_RELEASE) BTF_ID_FLAGS(func, hid_bpf_hw_request) -BTF_SET8_END(hid_bpf_syscall_kfunc_ids) +BTF_KFUNCS_END(hid_bpf_syscall_kfunc_ids) static const struct btf_kfunc_id_set hid_bpf_syscall_kfunc_set = { .owner = THIS_MODULE, diff --git a/fs/verity/measure.c b/fs/verity/measure.c index bf7a5f4cccaf..3969d54158d1 100644 --- a/fs/verity/measure.c +++ b/fs/verity/measure.c @@ -159,9 +159,9 @@ __bpf_kfunc int bpf_get_fsverity_digest(struct file *file, struct bpf_dynptr_ker __bpf_kfunc_end_defs(); -BTF_SET8_START(fsverity_set_ids) +BTF_KFUNCS_START(fsverity_set_ids) BTF_ID_FLAGS(func, bpf_get_fsverity_digest, KF_TRUSTED_ARGS) -BTF_SET8_END(fsverity_set_ids) +BTF_KFUNCS_END(fsverity_set_ids) static int bpf_get_fsverity_digest_filter(const struct bpf_prog *prog, u32 kfunc_id) { diff --git a/kernel/bpf/btf.c b/kernel/bpf/btf.c index c8c6e6cf18e7..ef380e546952 100644 --- a/kernel/bpf/btf.c +++ b/kernel/bpf/btf.c @@ -8124,6 +8124,14 @@ int register_btf_kfunc_id_set(enum bpf_prog_type prog_type, { enum btf_kfunc_hook hook; + /* All kfuncs need to be tagged as such in BTF. + * WARN() for initcall registrations that do not check errors. + */ + if (!(kset->set->flags & BTF_SET8_KFUNCS)) { + WARN_ON(!kset->owner); + return -EINVAL; + } + hook = bpf_prog_type_to_kfunc_hook(prog_type); return __register_btf_kfunc_id_set(hook, kset); } diff --git a/kernel/bpf/cpumask.c b/kernel/bpf/cpumask.c index 2e73533a3811..dad0fb1c8e87 100644 --- a/kernel/bpf/cpumask.c +++ b/kernel/bpf/cpumask.c @@ -424,7 +424,7 @@ __bpf_kfunc u32 bpf_cpumask_weight(const struct cpumask *cpumask) __bpf_kfunc_end_defs(); -BTF_SET8_START(cpumask_kfunc_btf_ids) +BTF_KFUNCS_START(cpumask_kfunc_btf_ids) BTF_ID_FLAGS(func, bpf_cpumask_create, KF_ACQUIRE | KF_RET_NULL) BTF_ID_FLAGS(func, bpf_cpumask_release, KF_RELEASE) BTF_ID_FLAGS(func, bpf_cpumask_acquire, KF_ACQUIRE | KF_TRUSTED_ARGS) @@ -450,7 +450,7 @@ BTF_ID_FLAGS(func, bpf_cpumask_copy, KF_RCU) BTF_ID_FLAGS(func, bpf_cpumask_any_distribute, KF_RCU) BTF_ID_FLAGS(func, bpf_cpumask_any_and_distribute, KF_RCU) BTF_ID_FLAGS(func, bpf_cpumask_weight, KF_RCU) -BTF_SET8_END(cpumask_kfunc_btf_ids) +BTF_KFUNCS_END(cpumask_kfunc_btf_ids) static const struct btf_kfunc_id_set cpumask_kfunc_set = { .owner = THIS_MODULE, diff --git a/kernel/bpf/helpers.c b/kernel/bpf/helpers.c index bcb951a2ecf4..4db1c658254c 100644 --- a/kernel/bpf/helpers.c +++ b/kernel/bpf/helpers.c @@ -2544,7 +2544,7 @@ __bpf_kfunc void bpf_throw(u64 cookie) __bpf_kfunc_end_defs(); -BTF_SET8_START(generic_btf_ids) +BTF_KFUNCS_START(generic_btf_ids) #ifdef CONFIG_KEXEC_CORE BTF_ID_FLAGS(func, crash_kexec, KF_DESTRUCTIVE) #endif @@ -2573,7 +2573,7 @@ BTF_ID_FLAGS(func, bpf_task_get_cgroup1, KF_ACQUIRE | KF_RCU | KF_RET_NULL) #endif BTF_ID_FLAGS(func, bpf_task_from_pid, KF_ACQUIRE | KF_RET_NULL) BTF_ID_FLAGS(func, bpf_throw) -BTF_SET8_END(generic_btf_ids) +BTF_KFUNCS_END(generic_btf_ids) static const struct btf_kfunc_id_set generic_kfunc_set = { .owner = THIS_MODULE, @@ -2589,7 +2589,7 @@ BTF_ID(struct, cgroup) BTF_ID(func, bpf_cgroup_release_dtor) #endif -BTF_SET8_START(common_btf_ids) +BTF_KFUNCS_START(common_btf_ids) BTF_ID_FLAGS(func, bpf_cast_to_kern_ctx) BTF_ID_FLAGS(func, bpf_rdonly_cast) BTF_ID_FLAGS(func, bpf_rcu_read_lock) @@ -2618,7 +2618,7 @@ BTF_ID_FLAGS(func, bpf_dynptr_is_null) BTF_ID_FLAGS(func, bpf_dynptr_is_rdonly) BTF_ID_FLAGS(func, bpf_dynptr_size) BTF_ID_FLAGS(func, bpf_dynptr_clone) -BTF_SET8_END(common_btf_ids) +BTF_KFUNCS_END(common_btf_ids) static const struct btf_kfunc_id_set common_kfunc_set = { .owner = THIS_MODULE, diff --git a/kernel/bpf/map_iter.c b/kernel/bpf/map_iter.c index 6abd7c5df4b3..9575314f40a6 100644 --- a/kernel/bpf/map_iter.c +++ b/kernel/bpf/map_iter.c @@ -213,9 +213,9 @@ __bpf_kfunc s64 bpf_map_sum_elem_count(const struct bpf_map *map) __bpf_kfunc_end_defs(); -BTF_SET8_START(bpf_map_iter_kfunc_ids) +BTF_KFUNCS_START(bpf_map_iter_kfunc_ids) BTF_ID_FLAGS(func, bpf_map_sum_elem_count, KF_TRUSTED_ARGS) -BTF_SET8_END(bpf_map_iter_kfunc_ids) +BTF_KFUNCS_END(bpf_map_iter_kfunc_ids) static const struct btf_kfunc_id_set bpf_map_iter_kfunc_set = { .owner = THIS_MODULE, diff --git a/kernel/cgroup/rstat.c b/kernel/cgroup/rstat.c index a8350d2d63e6..07e2284bb499 100644 --- a/kernel/cgroup/rstat.c +++ b/kernel/cgroup/rstat.c @@ -562,10 +562,10 @@ void cgroup_base_stat_cputime_show(struct seq_file *seq) } /* Add bpf kfuncs for cgroup_rstat_updated() and cgroup_rstat_flush() */ -BTF_SET8_START(bpf_rstat_kfunc_ids) +BTF_KFUNCS_START(bpf_rstat_kfunc_ids) BTF_ID_FLAGS(func, cgroup_rstat_updated) BTF_ID_FLAGS(func, cgroup_rstat_flush, KF_SLEEPABLE) -BTF_SET8_END(bpf_rstat_kfunc_ids) +BTF_KFUNCS_END(bpf_rstat_kfunc_ids) static const struct btf_kfunc_id_set bpf_rstat_kfunc_set = { .owner = THIS_MODULE, diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c index 64fdaf79d113..241ddf5e3895 100644 --- a/kernel/trace/bpf_trace.c +++ b/kernel/trace/bpf_trace.c @@ -1412,14 +1412,14 @@ __bpf_kfunc int bpf_verify_pkcs7_signature(struct bpf_dynptr_kern *data_ptr, __bpf_kfunc_end_defs(); -BTF_SET8_START(key_sig_kfunc_set) +BTF_KFUNCS_START(key_sig_kfunc_set) BTF_ID_FLAGS(func, bpf_lookup_user_key, KF_ACQUIRE | KF_RET_NULL | KF_SLEEPABLE) BTF_ID_FLAGS(func, bpf_lookup_system_key, KF_ACQUIRE | KF_RET_NULL) BTF_ID_FLAGS(func, bpf_key_put, KF_RELEASE) #ifdef CONFIG_SYSTEM_DATA_VERIFICATION BTF_ID_FLAGS(func, bpf_verify_pkcs7_signature, KF_SLEEPABLE) #endif -BTF_SET8_END(key_sig_kfunc_set) +BTF_KFUNCS_END(key_sig_kfunc_set) static const struct btf_kfunc_id_set bpf_key_sig_kfunc_set = { .owner = THIS_MODULE, @@ -1475,9 +1475,9 @@ __bpf_kfunc int bpf_get_file_xattr(struct file *file, const char *name__str, __bpf_kfunc_end_defs(); -BTF_SET8_START(fs_kfunc_set_ids) +BTF_KFUNCS_START(fs_kfunc_set_ids) BTF_ID_FLAGS(func, bpf_get_file_xattr, KF_SLEEPABLE | KF_TRUSTED_ARGS) -BTF_SET8_END(fs_kfunc_set_ids) +BTF_KFUNCS_END(fs_kfunc_set_ids) static int bpf_get_file_xattr_filter(const struct bpf_prog *prog, u32 kfunc_id) { diff --git a/net/bpf/test_run.c b/net/bpf/test_run.c index dfd919374017..5535f9adc658 100644 --- a/net/bpf/test_run.c +++ b/net/bpf/test_run.c @@ -617,21 +617,21 @@ CFI_NOSEAL(bpf_kfunc_call_memb_release_dtor); __bpf_kfunc_end_defs(); -BTF_SET8_START(bpf_test_modify_return_ids) +BTF_KFUNCS_START(bpf_test_modify_return_ids) BTF_ID_FLAGS(func, bpf_modify_return_test) BTF_ID_FLAGS(func, bpf_modify_return_test2) BTF_ID_FLAGS(func, bpf_fentry_test1, KF_SLEEPABLE) -BTF_SET8_END(bpf_test_modify_return_ids) +BTF_KFUNCS_END(bpf_test_modify_return_ids) static const struct btf_kfunc_id_set bpf_test_modify_return_set = { .owner = THIS_MODULE, .set = &bpf_test_modify_return_ids, }; -BTF_SET8_START(test_sk_check_kfunc_ids) +BTF_KFUNCS_START(test_sk_check_kfunc_ids) BTF_ID_FLAGS(func, bpf_kfunc_call_test_release, KF_RELEASE) BTF_ID_FLAGS(func, bpf_kfunc_call_memb_release, KF_RELEASE) -BTF_SET8_END(test_sk_check_kfunc_ids) +BTF_KFUNCS_END(test_sk_check_kfunc_ids) static void *bpf_test_init(const union bpf_attr *kattr, u32 user_size, u32 size, u32 headroom, u32 tailroom) diff --git a/net/core/filter.c b/net/core/filter.c index 358870408a51..524adf1fa6d0 100644 --- a/net/core/filter.c +++ b/net/core/filter.c @@ -11982,21 +11982,21 @@ int bpf_dynptr_from_skb_rdonly(struct sk_buff *skb, u64 flags, return 0; } -BTF_SET8_START(bpf_kfunc_check_set_skb) +BTF_KFUNCS_START(bpf_kfunc_check_set_skb) BTF_ID_FLAGS(func, bpf_dynptr_from_skb) -BTF_SET8_END(bpf_kfunc_check_set_skb) +BTF_KFUNCS_END(bpf_kfunc_check_set_skb) -BTF_SET8_START(bpf_kfunc_check_set_xdp) +BTF_KFUNCS_START(bpf_kfunc_check_set_xdp) BTF_ID_FLAGS(func, bpf_dynptr_from_xdp) -BTF_SET8_END(bpf_kfunc_check_set_xdp) +BTF_KFUNCS_END(bpf_kfunc_check_set_xdp) -BTF_SET8_START(bpf_kfunc_check_set_sock_addr) +BTF_KFUNCS_START(bpf_kfunc_check_set_sock_addr) BTF_ID_FLAGS(func, bpf_sock_addr_set_sun_path) -BTF_SET8_END(bpf_kfunc_check_set_sock_addr) +BTF_KFUNCS_END(bpf_kfunc_check_set_sock_addr) -BTF_SET8_START(bpf_kfunc_check_set_tcp_reqsk) +BTF_KFUNCS_START(bpf_kfunc_check_set_tcp_reqsk) BTF_ID_FLAGS(func, bpf_sk_assign_tcp_reqsk, KF_TRUSTED_ARGS) -BTF_SET8_END(bpf_kfunc_check_set_tcp_reqsk) +BTF_KFUNCS_END(bpf_kfunc_check_set_tcp_reqsk) static const struct btf_kfunc_id_set bpf_kfunc_set_skb = { .owner = THIS_MODULE, @@ -12075,9 +12075,9 @@ __bpf_kfunc int bpf_sock_destroy(struct sock_common *sock) __bpf_kfunc_end_defs(); -BTF_SET8_START(bpf_sk_iter_kfunc_ids) +BTF_KFUNCS_START(bpf_sk_iter_kfunc_ids) BTF_ID_FLAGS(func, bpf_sock_destroy, KF_TRUSTED_ARGS) -BTF_SET8_END(bpf_sk_iter_kfunc_ids) +BTF_KFUNCS_END(bpf_sk_iter_kfunc_ids) static int tracing_iter_filter(const struct bpf_prog *prog, u32 kfunc_id) { diff --git a/net/core/xdp.c b/net/core/xdp.c index 4869c1c2d8f3..034fb80f3fbe 100644 --- a/net/core/xdp.c +++ b/net/core/xdp.c @@ -771,11 +771,11 @@ __bpf_kfunc int bpf_xdp_metadata_rx_vlan_tag(const struct xdp_md *ctx, __bpf_kfunc_end_defs(); -BTF_SET8_START(xdp_metadata_kfunc_ids) +BTF_KFUNCS_START(xdp_metadata_kfunc_ids) #define XDP_METADATA_KFUNC(_, __, name, ___) BTF_ID_FLAGS(func, name, KF_TRUSTED_ARGS) XDP_METADATA_KFUNC_xxx #undef XDP_METADATA_KFUNC -BTF_SET8_END(xdp_metadata_kfunc_ids) +BTF_KFUNCS_END(xdp_metadata_kfunc_ids) static const struct btf_kfunc_id_set xdp_metadata_kfunc_set = { .owner = THIS_MODULE, diff --git a/net/ipv4/bpf_tcp_ca.c b/net/ipv4/bpf_tcp_ca.c index 834edc18463a..7f518ea5f4ac 100644 --- a/net/ipv4/bpf_tcp_ca.c +++ b/net/ipv4/bpf_tcp_ca.c @@ -201,13 +201,13 @@ bpf_tcp_ca_get_func_proto(enum bpf_func_id func_id, } } -BTF_SET8_START(bpf_tcp_ca_check_kfunc_ids) +BTF_KFUNCS_START(bpf_tcp_ca_check_kfunc_ids) BTF_ID_FLAGS(func, tcp_reno_ssthresh) BTF_ID_FLAGS(func, tcp_reno_cong_avoid) BTF_ID_FLAGS(func, tcp_reno_undo_cwnd) BTF_ID_FLAGS(func, tcp_slow_start) BTF_ID_FLAGS(func, tcp_cong_avoid_ai) -BTF_SET8_END(bpf_tcp_ca_check_kfunc_ids) +BTF_KFUNCS_END(bpf_tcp_ca_check_kfunc_ids) static const struct btf_kfunc_id_set bpf_tcp_ca_kfunc_set = { .owner = THIS_MODULE, diff --git a/net/ipv4/fou_bpf.c b/net/ipv4/fou_bpf.c index 4da03bf45c9b..06e5572f296f 100644 --- a/net/ipv4/fou_bpf.c +++ b/net/ipv4/fou_bpf.c @@ -100,10 +100,10 @@ __bpf_kfunc int bpf_skb_get_fou_encap(struct __sk_buff *skb_ctx, __bpf_kfunc_end_defs(); -BTF_SET8_START(fou_kfunc_set) +BTF_KFUNCS_START(fou_kfunc_set) BTF_ID_FLAGS(func, bpf_skb_set_fou_encap) BTF_ID_FLAGS(func, bpf_skb_get_fou_encap) -BTF_SET8_END(fou_kfunc_set) +BTF_KFUNCS_END(fou_kfunc_set) static const struct btf_kfunc_id_set fou_bpf_kfunc_set = { .owner = THIS_MODULE, diff --git a/net/ipv4/tcp_bbr.c b/net/ipv4/tcp_bbr.c index 22358032dd48..05dc2d05bc7c 100644 --- a/net/ipv4/tcp_bbr.c +++ b/net/ipv4/tcp_bbr.c @@ -1155,7 +1155,7 @@ static struct tcp_congestion_ops tcp_bbr_cong_ops __read_mostly = { .set_state = bbr_set_state, }; -BTF_SET8_START(tcp_bbr_check_kfunc_ids) +BTF_KFUNCS_START(tcp_bbr_check_kfunc_ids) #ifdef CONFIG_X86 #ifdef CONFIG_DYNAMIC_FTRACE BTF_ID_FLAGS(func, bbr_init) @@ -1168,7 +1168,7 @@ BTF_ID_FLAGS(func, bbr_min_tso_segs) BTF_ID_FLAGS(func, bbr_set_state) #endif #endif -BTF_SET8_END(tcp_bbr_check_kfunc_ids) +BTF_KFUNCS_END(tcp_bbr_check_kfunc_ids) static const struct btf_kfunc_id_set tcp_bbr_kfunc_set = { .owner = THIS_MODULE, diff --git a/net/ipv4/tcp_cubic.c b/net/ipv4/tcp_cubic.c index 0fd78ecb67e7..44869ea089e3 100644 --- a/net/ipv4/tcp_cubic.c +++ b/net/ipv4/tcp_cubic.c @@ -485,7 +485,7 @@ static struct tcp_congestion_ops cubictcp __read_mostly = { .name = "cubic", }; -BTF_SET8_START(tcp_cubic_check_kfunc_ids) +BTF_KFUNCS_START(tcp_cubic_check_kfunc_ids) #ifdef CONFIG_X86 #ifdef CONFIG_DYNAMIC_FTRACE BTF_ID_FLAGS(func, cubictcp_init) @@ -496,7 +496,7 @@ BTF_ID_FLAGS(func, cubictcp_cwnd_event) BTF_ID_FLAGS(func, cubictcp_acked) #endif #endif -BTF_SET8_END(tcp_cubic_check_kfunc_ids) +BTF_KFUNCS_END(tcp_cubic_check_kfunc_ids) static const struct btf_kfunc_id_set tcp_cubic_kfunc_set = { .owner = THIS_MODULE, diff --git a/net/ipv4/tcp_dctcp.c b/net/ipv4/tcp_dctcp.c index bb23bb5b387a..e33fbe4933e4 100644 --- a/net/ipv4/tcp_dctcp.c +++ b/net/ipv4/tcp_dctcp.c @@ -260,7 +260,7 @@ static struct tcp_congestion_ops dctcp_reno __read_mostly = { .name = "dctcp-reno", }; -BTF_SET8_START(tcp_dctcp_check_kfunc_ids) +BTF_KFUNCS_START(tcp_dctcp_check_kfunc_ids) #ifdef CONFIG_X86 #ifdef CONFIG_DYNAMIC_FTRACE BTF_ID_FLAGS(func, dctcp_init) @@ -271,7 +271,7 @@ BTF_ID_FLAGS(func, dctcp_cwnd_undo) BTF_ID_FLAGS(func, dctcp_state) #endif #endif -BTF_SET8_END(tcp_dctcp_check_kfunc_ids) +BTF_KFUNCS_END(tcp_dctcp_check_kfunc_ids) static const struct btf_kfunc_id_set tcp_dctcp_kfunc_set = { .owner = THIS_MODULE, diff --git a/net/netfilter/nf_conntrack_bpf.c b/net/netfilter/nf_conntrack_bpf.c index 475358ec8212..d2492d050fe6 100644 --- a/net/netfilter/nf_conntrack_bpf.c +++ b/net/netfilter/nf_conntrack_bpf.c @@ -467,7 +467,7 @@ __bpf_kfunc int bpf_ct_change_status(struct nf_conn *nfct, u32 status) __bpf_kfunc_end_defs(); -BTF_SET8_START(nf_ct_kfunc_set) +BTF_KFUNCS_START(nf_ct_kfunc_set) BTF_ID_FLAGS(func, bpf_xdp_ct_alloc, KF_ACQUIRE | KF_RET_NULL) BTF_ID_FLAGS(func, bpf_xdp_ct_lookup, KF_ACQUIRE | KF_RET_NULL) BTF_ID_FLAGS(func, bpf_skb_ct_alloc, KF_ACQUIRE | KF_RET_NULL) @@ -478,7 +478,7 @@ BTF_ID_FLAGS(func, bpf_ct_set_timeout, KF_TRUSTED_ARGS) BTF_ID_FLAGS(func, bpf_ct_change_timeout, KF_TRUSTED_ARGS) BTF_ID_FLAGS(func, bpf_ct_set_status, KF_TRUSTED_ARGS) BTF_ID_FLAGS(func, bpf_ct_change_status, KF_TRUSTED_ARGS) -BTF_SET8_END(nf_ct_kfunc_set) +BTF_KFUNCS_END(nf_ct_kfunc_set) static const struct btf_kfunc_id_set nf_conntrack_kfunc_set = { .owner = THIS_MODULE, diff --git a/net/netfilter/nf_nat_bpf.c b/net/netfilter/nf_nat_bpf.c index 6e3b2f58855f..481be15609b1 100644 --- a/net/netfilter/nf_nat_bpf.c +++ b/net/netfilter/nf_nat_bpf.c @@ -54,9 +54,9 @@ __bpf_kfunc int bpf_ct_set_nat_info(struct nf_conn___init *nfct, __bpf_kfunc_end_defs(); -BTF_SET8_START(nf_nat_kfunc_set) +BTF_KFUNCS_START(nf_nat_kfunc_set) BTF_ID_FLAGS(func, bpf_ct_set_nat_info, KF_TRUSTED_ARGS) -BTF_SET8_END(nf_nat_kfunc_set) +BTF_KFUNCS_END(nf_nat_kfunc_set) static const struct btf_kfunc_id_set nf_bpf_nat_kfunc_set = { .owner = THIS_MODULE, diff --git a/net/xfrm/xfrm_interface_bpf.c b/net/xfrm/xfrm_interface_bpf.c index 7d5e920141e9..5ea15037ebd1 100644 --- a/net/xfrm/xfrm_interface_bpf.c +++ b/net/xfrm/xfrm_interface_bpf.c @@ -93,10 +93,10 @@ __bpf_kfunc int bpf_skb_set_xfrm_info(struct __sk_buff *skb_ctx, const struct bp __bpf_kfunc_end_defs(); -BTF_SET8_START(xfrm_ifc_kfunc_set) +BTF_KFUNCS_START(xfrm_ifc_kfunc_set) BTF_ID_FLAGS(func, bpf_skb_get_xfrm_info) BTF_ID_FLAGS(func, bpf_skb_set_xfrm_info) -BTF_SET8_END(xfrm_ifc_kfunc_set) +BTF_KFUNCS_END(xfrm_ifc_kfunc_set) static const struct btf_kfunc_id_set xfrm_interface_kfunc_set = { .owner = THIS_MODULE, diff --git a/net/xfrm/xfrm_state_bpf.c b/net/xfrm/xfrm_state_bpf.c index 9e20d4a377f7..2248eda741f8 100644 --- a/net/xfrm/xfrm_state_bpf.c +++ b/net/xfrm/xfrm_state_bpf.c @@ -117,10 +117,10 @@ __bpf_kfunc void bpf_xdp_xfrm_state_release(struct xfrm_state *x) __bpf_kfunc_end_defs(); -BTF_SET8_START(xfrm_state_kfunc_set) +BTF_KFUNCS_START(xfrm_state_kfunc_set) BTF_ID_FLAGS(func, bpf_xdp_get_xfrm_state, KF_RET_NULL | KF_ACQUIRE) BTF_ID_FLAGS(func, bpf_xdp_xfrm_state_release, KF_RELEASE) -BTF_SET8_END(xfrm_state_kfunc_set) +BTF_KFUNCS_END(xfrm_state_kfunc_set) static const struct btf_kfunc_id_set xfrm_state_xdp_kfunc_set = { .owner = THIS_MODULE, diff --git a/tools/testing/selftests/bpf/bpf_testmod/bpf_testmod.c b/tools/testing/selftests/bpf/bpf_testmod/bpf_testmod.c index 6f163a0f1c94..4754c662b39f 100644 --- a/tools/testing/selftests/bpf/bpf_testmod/bpf_testmod.c +++ b/tools/testing/selftests/bpf/bpf_testmod/bpf_testmod.c @@ -343,12 +343,12 @@ static struct bin_attribute bin_attr_bpf_testmod_file __ro_after_init = { .write = bpf_testmod_test_write, }; -BTF_SET8_START(bpf_testmod_common_kfunc_ids) +BTF_KFUNCS_START(bpf_testmod_common_kfunc_ids) BTF_ID_FLAGS(func, bpf_iter_testmod_seq_new, KF_ITER_NEW) BTF_ID_FLAGS(func, bpf_iter_testmod_seq_next, KF_ITER_NEXT | KF_RET_NULL) BTF_ID_FLAGS(func, bpf_iter_testmod_seq_destroy, KF_ITER_DESTROY) BTF_ID_FLAGS(func, bpf_kfunc_common_test) -BTF_SET8_END(bpf_testmod_common_kfunc_ids) +BTF_KFUNCS_END(bpf_testmod_common_kfunc_ids) static const struct btf_kfunc_id_set bpf_testmod_common_kfunc_set = { .owner = THIS_MODULE, @@ -494,7 +494,7 @@ __bpf_kfunc static u32 bpf_kfunc_call_test_static_unused_arg(u32 arg, u32 unused return arg; } -BTF_SET8_START(bpf_testmod_check_kfunc_ids) +BTF_KFUNCS_START(bpf_testmod_check_kfunc_ids) BTF_ID_FLAGS(func, bpf_testmod_test_mod_kfunc) BTF_ID_FLAGS(func, bpf_kfunc_call_test1) BTF_ID_FLAGS(func, bpf_kfunc_call_test2) @@ -520,7 +520,7 @@ BTF_ID_FLAGS(func, bpf_kfunc_call_test_ref, KF_TRUSTED_ARGS | KF_RCU) BTF_ID_FLAGS(func, bpf_kfunc_call_test_destructive, KF_DESTRUCTIVE) BTF_ID_FLAGS(func, bpf_kfunc_call_test_static_unused_arg) BTF_ID_FLAGS(func, bpf_kfunc_call_test_offset) -BTF_SET8_END(bpf_testmod_check_kfunc_ids) +BTF_KFUNCS_END(bpf_testmod_check_kfunc_ids) static int bpf_testmod_ops_init(struct btf *btf) { -- cgit v1.2.3 From 78d23416979500c749049d5d20bac457bcca2fb5 Mon Sep 17 00:00:00 2001 From: Donald Hunter Date: Mon, 29 Jan 2024 22:34:48 +0000 Subject: doc/netlink: Describe sub-message selector resolution Update the netlink-raw docs to add a description of sub-message selector resolution to explain that selector resolution is constrained by the spec. Signed-off-by: Donald Hunter Reviewed-by: Jiri Pirko Link: https://lore.kernel.org/r/20240129223458.52046-4-donald.hunter@gmail.com Signed-off-by: Jakub Kicinski --- Documentation/userspace-api/netlink/netlink-raw.rst | 8 ++++++++ 1 file changed, 8 insertions(+) (limited to 'Documentation') diff --git a/Documentation/userspace-api/netlink/netlink-raw.rst b/Documentation/userspace-api/netlink/netlink-raw.rst index 1e14f5f22b8e..32197f3cb40e 100644 --- a/Documentation/userspace-api/netlink/netlink-raw.rst +++ b/Documentation/userspace-api/netlink/netlink-raw.rst @@ -150,3 +150,11 @@ attributes from an ``attribute-set``. For example the following Note that a selector attribute must appear in a netlink message before any sub-message attributes that depend on it. + +If an attribute such as ``kind`` is defined at more than one nest level, then a +sub-message selector will be resolved using the value 'closest' to the selector. +For example, if the same attribute name is defined in a nested ``attribute-set`` +alongside a sub-message selector and also in a top level ``attribute-set``, then +the selector will be resolved using the value 'closest' to the selector. If the +value is not present in the message at the same level as defined in the spec +then this is an error. -- cgit v1.2.3 From bf08f32c8cedb12a23efcdc2c9584601d7030e16 Mon Sep 17 00:00:00 2001 From: Donald Hunter Date: Mon, 29 Jan 2024 22:34:55 +0000 Subject: tools/net/ynl: Add support for nested structs Make it possible for struct definitions to reference other struct definitions ofr binary members. For example, the tbf qdisc uses this struct definition for its parms attribute: - name: tc-tbf-qopt type: struct members: - name: rate type: binary struct: tc-ratespec - name: peakrate type: binary struct: tc-ratespec - name: limit type: u32 - name: buffer type: u32 - name: mtu type: u32 This adds the necessary schema changes and adds nested struct encoding and decoding to ynl. Signed-off-by: Donald Hunter Reviewed-by: Jiri Pirko Link: https://lore.kernel.org/r/20240129223458.52046-11-donald.hunter@gmail.com Signed-off-by: Jakub Kicinski --- Documentation/netlink/netlink-raw.yaml | 15 ++++++++++++--- tools/net/ynl/lib/nlspec.py | 2 ++ tools/net/ynl/lib/ynl.py | 26 ++++++++++++++++++++------ 3 files changed, 34 insertions(+), 9 deletions(-) (limited to 'Documentation') diff --git a/Documentation/netlink/netlink-raw.yaml b/Documentation/netlink/netlink-raw.yaml index 04b92f1a5cd6..ac4e05415f2f 100644 --- a/Documentation/netlink/netlink-raw.yaml +++ b/Documentation/netlink/netlink-raw.yaml @@ -152,14 +152,23 @@ properties: the right formatting mechanism when displaying values of this type. enum: [ hex, mac, fddi, ipv4, ipv6, uuid ] + struct: + description: Name of the nested struct type. + type: string if: properties: type: - oneOf: - - const: binary - - const: pad + const: pad then: required: [ len ] + if: + properties: + type: + const: binary + then: + oneOf: + - required: [ len ] + - required: [ struct ] # End genetlink-legacy attribute-sets: diff --git a/tools/net/ynl/lib/nlspec.py b/tools/net/ynl/lib/nlspec.py index 44f13e383e8a..5d197a12ab8d 100644 --- a/tools/net/ynl/lib/nlspec.py +++ b/tools/net/ynl/lib/nlspec.py @@ -248,6 +248,7 @@ class SpecStructMember(SpecElement): len integer, optional byte length of binary types display_hint string, hint to help choose format specifier when displaying the value + struct string, name of nested struct type """ def __init__(self, family, yaml): super().__init__(family, yaml) @@ -256,6 +257,7 @@ class SpecStructMember(SpecElement): self.enum = yaml.get('enum') self.len = yaml.get('len') self.display_hint = yaml.get('display-hint') + self.struct = yaml.get('struct') class SpecStruct(SpecElement): diff --git a/tools/net/ynl/lib/ynl.py b/tools/net/ynl/lib/ynl.py index 2b0ca61deaf8..0f4193cc2e3b 100644 --- a/tools/net/ynl/lib/ynl.py +++ b/tools/net/ynl/lib/ynl.py @@ -674,7 +674,10 @@ class YnlFamily(SpecFamily): size = 0 for m in members: if m.type in ['pad', 'binary']: - size += m.len + if m.struct: + size += self._struct_size(m.struct) + else: + size += m.len else: format = NlAttr.get_format(m.type, m.byte_order) size += format.size @@ -691,8 +694,14 @@ class YnlFamily(SpecFamily): if m.type == 'pad': offset += m.len elif m.type == 'binary': - value = data[offset : offset + m.len] - offset += m.len + if m.struct: + len = self._struct_size(m.struct) + value = self._decode_struct(data[offset : offset + len], + m.struct) + offset += len + else: + value = data[offset : offset + m.len] + offset += m.len else: format = NlAttr.get_format(m.type, m.byte_order) [ value ] = format.unpack_from(data, offset) @@ -713,10 +722,15 @@ class YnlFamily(SpecFamily): if m.type == 'pad': attr_payload += bytearray(m.len) elif m.type == 'binary': - if value is None: - attr_payload += bytearray(m.len) + if m.struct: + if value is None: + value = dict() + attr_payload += self._encode_struct(m.struct, value) else: - attr_payload += bytes.fromhex(value) + if value is None: + attr_payload += bytearray(m.len) + else: + attr_payload += bytes.fromhex(value) else: if value is None: value = 0 -- cgit v1.2.3 From 9d6429c33976fcce0d46124a9151314137687e0f Mon Sep 17 00:00:00 2001 From: Donald Hunter Date: Mon, 29 Jan 2024 22:34:56 +0000 Subject: doc/netlink: Describe nested structs in netlink raw docs Add a description and example of nested struct definitions to the netlink raw documentation. Signed-off-by: Donald Hunter Reviewed-by: Jiri Pirko Link: https://lore.kernel.org/r/20240129223458.52046-12-donald.hunter@gmail.com Signed-off-by: Jakub Kicinski --- .../userspace-api/netlink/netlink-raw.rst | 34 ++++++++++++++++++++++ 1 file changed, 34 insertions(+) (limited to 'Documentation') diff --git a/Documentation/userspace-api/netlink/netlink-raw.rst b/Documentation/userspace-api/netlink/netlink-raw.rst index 32197f3cb40e..1990eea772d0 100644 --- a/Documentation/userspace-api/netlink/netlink-raw.rst +++ b/Documentation/userspace-api/netlink/netlink-raw.rst @@ -158,3 +158,37 @@ alongside a sub-message selector and also in a top level ``attribute-set``, then the selector will be resolved using the value 'closest' to the selector. If the value is not present in the message at the same level as defined in the spec then this is an error. + +Nested struct definitions +------------------------- + +Many raw netlink families such as :doc:`tc<../../networking/netlink_spec/tc>` +make use of nested struct definitions. The ``netlink-raw`` schema makes it +possible to embed a struct within a struct definition using the ``struct`` +property. For example, the following struct definition embeds the +``tc-ratespec`` struct definition for both the ``rate`` and the ``peakrate`` +members of ``struct tc-tbf-qopt``. + +.. code-block:: yaml + + - + name: tc-tbf-qopt + type: struct + members: + - + name: rate + type: binary + struct: tc-ratespec + - + name: peakrate + type: binary + struct: tc-ratespec + - + name: limit + type: u32 + - + name: buffer + type: u32 + - + name: mtu + type: u32 -- cgit v1.2.3 From 2267672a6190cfb0349e95a70e09dc6a973007c1 Mon Sep 17 00:00:00 2001 From: Donald Hunter Date: Mon, 29 Jan 2024 22:34:58 +0000 Subject: doc/netlink/specs: Update the tc spec Fill in many of the gaps in the tc netlink spec, including stats attrs, classes and actions. Many documentation strings have also been added. This is still a work in progress, albeit fairly complete: - there are still many attributes left as binary blobs. - actions have not had much testing Signed-off-by: Donald Hunter Reviewed-by: Jiri Pirko Link: https://lore.kernel.org/r/20240129223458.52046-14-donald.hunter@gmail.com Signed-off-by: Jakub Kicinski --- Documentation/netlink/specs/tc.yaml | 2218 ++++++++++++++++++++++++++++++++--- 1 file changed, 2067 insertions(+), 151 deletions(-) (limited to 'Documentation') diff --git a/Documentation/netlink/specs/tc.yaml b/Documentation/netlink/specs/tc.yaml index 4346fa402fc9..4b21b00dbebe 100644 --- a/Documentation/netlink/specs/tc.yaml +++ b/Documentation/netlink/specs/tc.yaml @@ -48,21 +48,28 @@ definitions: - name: bytes type: u64 + doc: Number of enqueued bytes - name: packets type: u32 + doc: Number of enqueued packets - name: drops type: u32 + doc: Packets dropped because of lack of resources - name: overlimits type: u32 + doc: | + Number of throttle events when this flow goes out of allocated bandwidth - name: bps type: u32 + doc: Current flow byte rate - name: pps type: u32 + doc: Current flow packet rate - name: qlen type: u32 @@ -112,6 +119,7 @@ definitions: - name: limit type: u32 + doc: Queue length; bytes for bfifo, packets for pfifo - name: tc-htb-opt type: struct @@ -119,11 +127,11 @@ definitions: - name: rate type: binary - len: 12 + struct: tc-ratespec - name: ceil type: binary - len: 12 + struct: tc-ratespec - name: buffer type: u32 @@ -149,15 +157,19 @@ definitions: - name: rate2quantum type: u32 + doc: bps->quantum divisor - name: defcls type: u32 + doc: Default class number - name: debug type: u32 + doc: Debug flags - name: direct-pkts type: u32 + doc: Count of non shaped packets - name: tc-gred-qopt type: struct @@ -165,15 +177,19 @@ definitions: - name: limit type: u32 + doc: HARD maximal queue length in bytes - name: qth-min type: u32 + doc: Min average length threshold in bytes - name: qth-max type: u32 + doc: Max average length threshold in bytes - name: DP type: u32 + doc: Up to 2^32 DPs - name: backlog type: u32 @@ -195,15 +211,19 @@ definitions: - name: Wlog type: u8 + doc: log(W) - name: Plog type: u8 + doc: log(P_max / (qth-max - qth-min)) - name: Scell_log type: u8 + doc: cell size for idle damping - name: prio type: u8 + doc: Priority of this VQ - name: packets type: u32 @@ -266,9 +286,11 @@ definitions: - name: bands type: u16 + doc: Number of bands - name: max-bands type: u16 + doc: Maximum number of queues - name: tc-netem-qopt type: struct @@ -276,21 +298,138 @@ definitions: - name: latency type: u32 + doc: Added delay in microseconds - name: limit type: u32 + doc: Fifo limit in packets - name: loss type: u32 + doc: Random packet loss (0=none, ~0=100%) - name: gap type: u32 + doc: Re-ordering gap (0 for none) - name: duplicate type: u32 + doc: Random packet duplication (0=none, ~0=100%) - name: jitter type: u32 + doc: Random jitter latency in microseconds + - + name: tc-netem-gimodel + doc: State transition probabilities for 4 state model + type: struct + members: + - + name: p13 + type: u32 + - + name: p31 + type: u32 + - + name: p32 + type: u32 + - + name: p14 + type: u32 + - + name: p23 + type: u32 + - + name: tc-netem-gemodel + doc: Gilbert-Elliot models + type: struct + members: + - + name: p + type: u32 + - + name: r + type: u32 + - + name: h + type: u32 + - + name: k1 + type: u32 + - + name: tc-netem-corr + type: struct + members: + - + name: delay-corr + type: u32 + doc: Delay correlation + - + name: loss-corr + type: u32 + doc: Packet loss correlation + - + name: dup-corr + type: u32 + doc: Duplicate correlation + - + name: tc-netem-reorder + type: struct + members: + - + name: probability + type: u32 + - + name: correlation + type: u32 + - + name: tc-netem-corrupt + type: struct + members: + - + name: probability + type: u32 + - + name: correlation + type: u32 + - + name: tc-netem-rate + type: struct + members: + - + name: rate + type: u32 + - + name: packet-overhead + type: s32 + - + name: cell-size + type: u32 + - + name: cell-overhead + type: s32 + - + name: tc-netem-slot + type: struct + members: + - + name: min-delay + type: s64 + - + name: max-delay + type: s64 + - + name: max-packets + type: s32 + - + name: max-bytes + type: s32 + - + name: dist-delay + type: s64 + - + name: dist-jitter + type: s64 - name: tc-plug-qopt type: struct @@ -307,11 +446,13 @@ definitions: members: - name: bands - type: u16 + type: u32 + doc: Number of bands - name: priomap type: binary len: 16 + doc: Map of logical priority -> PRIO band - name: tc-red-qopt type: struct @@ -319,21 +460,27 @@ definitions: - name: limit type: u32 + doc: Hard queue length in packets - name: qth-min type: u32 + doc: Min average threshold in packets - name: qth-max type: u32 + doc: Max average threshold in packets - name: Wlog type: u8 + doc: log(W) - name: Plog type: u8 + doc: log(P_max / (qth-max - qth-min)) - name: Scell-log type: u8 + doc: Cell size for idle damping - name: flags type: u8 @@ -369,71 +516,128 @@ definitions: name: penalty-burst type: u32 - - name: tc-sfq-qopt-v1 # TODO nested structs + name: tc-sfq-qopt type: struct members: - name: quantum type: u32 + doc: Bytes per round allocated to flow - name: perturb-period type: s32 + doc: Period of hash perturbation - name: limit type: u32 + doc: Maximal packets in queue - name: divisor type: u32 + doc: Hash divisor - name: flows type: u32 + doc: Maximal number of flows + - + name: tc-sfqred-stats + type: struct + members: + - + name: prob-drop + type: u32 + doc: Early drops, below max threshold + - + name: forced-drop + type: u32 + doc: Early drops, after max threshold + - + name: prob-mark + type: u32 + doc: Marked packets, below max threshold + - + name: forced-mark + type: u32 + doc: Marked packets, after max threshold + - + name: prob-mark-head + type: u32 + doc: Marked packets, below max threshold + - + name: forced-mark-head + type: u32 + doc: Marked packets, after max threshold + - + name: tc-sfq-qopt-v1 + type: struct + members: + - + name: v0 + type: binary + struct: tc-sfq-qopt - name: depth type: u32 + doc: Maximum number of packets per flow - name: headdrop type: u32 - name: limit type: u32 + doc: HARD maximal flow queue length in bytes - name: qth-min type: u32 + doc: Min average length threshold in bytes - - name: qth-mac + name: qth-max type: u32 + doc: Max average length threshold in bytes - name: Wlog type: u8 + doc: log(W) - name: Plog type: u8 + doc: log(P_max / (qth-max - qth-min)) - name: Scell-log type: u8 + doc: Cell size for idle damping - name: flags type: u8 - name: max-P type: u32 + doc: probabilty, high resolution - - name: prob-drop - type: u32 + name: stats + type: binary + struct: tc-sfqred-stats + - + name: tc-ratespec + type: struct + members: - - name: forced-drop - type: u32 + name: cell-log + type: u8 - - name: prob-mark - type: u32 + name: linklayer + type: u8 - - name: forced-mark - type: u32 + name: overhead + type: u8 - - name: prob-mark-head - type: u32 + name: cell-align + type: u8 - - name: forced-mark-head + name: mpu + type: u8 + - + name: rate type: u32 - name: tc-tbf-qopt @@ -441,12 +645,12 @@ definitions: members: - name: rate - type: binary # TODO nested struct tc_ratespec - len: 12 + type: binary + struct: tc-ratespec - name: peakrate - type: binary # TODO nested struct tc_ratespec - len: 12 + type: binary + struct: tc-ratespec - name: limit type: u32 @@ -491,67 +695,1299 @@ definitions: - name: interval type: s8 + doc: Sampling period - name: ewma-log type: u8 -attribute-sets: + doc: The log() of measurement window weight - - name: tc-attrs + name: tc-choke-xstats + type: struct + members: + - + name: early + type: u32 + doc: Early drops + - + name: pdrop + type: u32 + doc: Drops due to queue limits + - + name: other + type: u32 + doc: Drops due to drop() calls + - + name: marked + type: u32 + doc: Marked packets + - + name: matched + type: u32 + doc: Drops due to flow match + - + name: tc-codel-xstats + type: struct + members: + - + name: maxpacket + type: u32 + doc: Largest packet we've seen so far + - + name: count + type: u32 + doc: How many drops we've done since the last time we entered dropping state + - + name: lastcount + type: u32 + doc: Count at entry to dropping state + - + name: ldelay + type: u32 + doc: in-queue delay seen by most recently dequeued packet + - + name: drop-next + type: s32 + doc: Time to drop next packet + - + name: drop-overlimit + type: u32 + doc: Number of times max qdisc packet limit was hit + - + name: ecn-mark + type: u32 + doc: Number of packets we've ECN marked instead of dropped + - + name: dropping + type: u32 + doc: Are we in a dropping state? + - + name: ce-mark + type: u32 + doc: Number of CE marked packets because of ce-threshold + - + name: tc-fq-codel-xstats + type: struct + members: + - + name: type + type: u32 + - + name: maxpacket + type: u32 + doc: Largest packet we've seen so far + - + name: drop-overlimit + type: u32 + doc: Number of times max qdisc packet limit was hit + - + name: ecn-mark + type: u32 + doc: Number of packets we ECN marked instead of being dropped + - + name: new-flow-count + type: u32 + doc: Number of times packets created a new flow + - + name: new-flows-len + type: u32 + doc: Count of flows in new list + - + name: old-flows-len + type: u32 + doc: Count of flows in old list + - + name: ce-mark + type: u32 + doc: Packets above ce-threshold + - + name: memory-usage + type: u32 + doc: Memory usage in bytes + - + name: drop-overmemory + type: u32 + - + name: tc-fq-pie-xstats + type: struct + members: + - + name: packets-in + type: u32 + doc: Total number of packets enqueued + - + name: dropped + type: u32 + doc: Packets dropped due to fq_pie_action + - + name: overlimit + type: u32 + doc: Dropped due to lack of space in queue + - + name: overmemory + type: u32 + doc: Dropped due to lack of memory in queue + - + name: ecn-mark + type: u32 + doc: Packets marked with ecn + - + name: new-flow-count + type: u32 + doc: Count of new flows created by packets + - + name: new-flows-len + type: u32 + doc: Count of flows in new list + - + name: old-flows-len + type: u32 + doc: Count of flows in old list + - + name: memory-usage + type: u32 + doc: Total memory across all queues + - + name: tc-fq-qd-stats + type: struct + members: + - + name: gc-flows + type: u64 + - + name: highprio-packets + type: u64 + doc: obsolete + - + name: tcp-retrans + type: u64 + doc: obsolete + - + name: throttled + type: u64 + - + name: flows-plimit + type: u64 + - + name: pkts-too-long + type: u64 + - + name: allocation-errors + type: u64 + - + name: time-next-delayed-flow + type: s64 + - + name: flows + type: u32 + - + name: inactive-flows + type: u32 + - + name: throttled-flows + type: u32 + - + name: unthrottle-latency-ns + type: u32 + - + name: ce-mark + type: u64 + doc: Packets above ce-threshold + - + name: horizon-drops + type: u64 + - + name: horizon-caps + type: u64 + - + name: fastpath-packets + type: u64 + - + name: band-drops + type: binary + len: 24 + - + name: band-pkt-count + type: binary + len: 12 + - + name: pad + type: pad + len: 4 + - + name: tc-hhf-xstats + type: struct + members: + - + name: drop-overlimit + type: u32 + doc: Number of times max qdisc packet limit was hit + - + name: hh-overlimit + type: u32 + doc: Number of times max heavy-hitters was hit + - + name: hh-tot-count + type: u32 + doc: Number of captured heavy-hitters so far + - + name: hh-cur-count + type: u32 + doc: Number of current heavy-hitters + - + name: tc-pie-xstats + type: struct + members: + - + name: prob + type: u64 + doc: Current probability + - + name: delay + type: u32 + doc: Current delay in ms + - + name: avg-dq-rate + type: u32 + doc: Current average dq rate in bits/pie-time + - + name: dq-rate-estimating + type: u32 + doc: Is avg-dq-rate being calculated? + - + name: packets-in + type: u32 + doc: Total number of packets enqueued + - + name: dropped + type: u32 + doc: Packets dropped due to pie action + - + name: overlimit + type: u32 + doc: Dropped due to lack of space in queue + - + name: maxq + type: u32 + doc: Maximum queue size + - + name: ecn-mark + type: u32 + doc: Packets marked with ecn + - + name: tc-red-xstats + type: struct + members: + - + name: early + type: u32 + doc: Early drops + - + name: pdrop + type: u32 + doc: Drops due to queue limits + - + name: other + type: u32 + doc: Drops due to drop() calls + - + name: marked + type: u32 + doc: Marked packets + - + name: tc-sfb-xstats + type: struct + members: + - + name: earlydrop + type: u32 + - + name: penaltydrop + type: u32 + - + name: bucketdrop + type: u32 + - + name: queuedrop + type: u32 + - + name: childdrop + type: u32 + doc: drops in child qdisc + - + name: marked + type: u32 + - + name: maxqlen + type: u32 + - + name: maxprob + type: u32 + - + name: avgprob + type: u32 + - + name: tc-sfq-xstats + type: struct + members: + - + name: allot + type: s32 + - + name: gnet-stats-basic + type: struct + members: + - + name: bytes + type: u64 + - + name: packets + type: u32 + - + name: gnet-stats-rate-est + type: struct + members: + - + name: bps + type: u32 + - + name: pps + type: u32 + - + name: gnet-stats-rate-est64 + type: struct + members: + - + name: bps + type: u64 + - + name: pps + type: u64 + - + name: gnet-stats-queue + type: struct + members: + - + name: qlen + type: u32 + - + name: backlog + type: u32 + - + name: drops + type: u32 + - + name: requeues + type: u32 + - + name: overlimits + type: u32 + - + name: tc-u32-key + type: struct + members: + - + name: mask + type: u32 + byte-order: big-endian + - + name: val + type: u32 + byte-order: big-endian + - + name: "off" + type: s32 + - + name: offmask + type: s32 + - + name: tc-u32-sel + type: struct + members: + - + name: flags + type: u8 + - + name: offshift + type: u8 + - + name: nkeys + type: u8 + - + name: offmask + type: u16 + byte-order: big-endian + - + name: "off" + type: u16 + - + name: offoff + type: s16 + - + name: hoff + type: s16 + - + name: hmask + type: u32 + byte-order: big-endian + - + name: keys + type: binary + struct: tc-u32-key # TODO: array + - + name: tc-u32-pcnt + type: struct + members: + - + name: rcnt + type: u64 + - + name: rhit + type: u64 + - + name: kcnts + type: u64 # TODO: array + - + name: tcf-t + type: struct + members: + - + name: install + type: u64 + - + name: lastuse + type: u64 + - + name: expires + type: u64 + - + name: firstuse + type: u64 + - + name: tc-gen + type: struct + members: + - + name: index + type: u32 + - + name: capab + type: u32 + - + name: action + type: s32 + - + name: refcnt + type: s32 + - + name: bindcnt + type: s32 + - + name: tc-gact-p + type: struct + members: + - + name: ptype + type: u16 + - + name: pval + type: u16 + - + name: paction + type: s32 + - + name: tcf-ematch-tree-hdr + type: struct + members: + - + name: nmatches + type: u16 + - + name: progid + type: u16 + - + name: tc-basic-pcnt + type: struct + members: + - + name: rcnt + type: u64 + - + name: rhit + type: u64 + - + name: tc-matchall-pcnt + type: struct + members: + - + name: rhit + type: u64 + - + name: tc-mpls + type: struct + members: + - + name: index + type: u32 + - + name: capab + type: u32 + - + name: action + type: s32 + - + name: refcnt + type: s32 + - + name: bindcnt + type: s32 + - + name: m-action + type: s32 + - + name: tc-police + type: struct + members: + - + name: index + type: u32 + - + name: action + type: s32 + - + name: limit + type: u32 + - + name: burst + type: u32 + - + name: mtu + type: u32 + - + name: rate + type: binary + struct: tc-ratespec + - + name: peakrate + type: binary + struct: tc-ratespec + - + name: refcnt + type: s32 + - + name: bindcnt + type: s32 + - + name: capab + type: u32 + - + name: tc-pedit-sel + type: struct + members: + - + name: index + type: u32 + - + name: capab + type: u32 + - + name: action + type: s32 + - + name: refcnt + type: s32 + - + name: bindcnt + type: s32 + - + name: nkeys + type: u8 + - + name: flags + type: u8 + - + name: keys + type: binary + struct: tc-pedit-key # TODO: array + - + name: tc-pedit-key + type: struct + members: + - + name: mask + type: u32 + - + name: val + type: u32 + - + name: "off" + type: u32 + - + name: at + type: u32 + - + name: offmask + type: u32 + - + name: shift + type: u32 + - + name: tc-vlan + type: struct + members: + - + name: index + type: u32 + - + name: capab + type: u32 + - + name: action + type: s32 + - + name: refcnt + type: s32 + - + name: bindcnt + type: s32 + - + name: v-action + type: s32 +attribute-sets: + - + name: tc-attrs + attributes: + - + name: kind + type: string + - + name: options + type: sub-message + sub-message: tc-options-msg + selector: kind + - + name: stats + type: binary + struct: tc-stats + - + name: xstats + type: sub-message + sub-message: tca-stats-app-msg + selector: kind + - + name: rate + type: binary + struct: gnet-estimator + - + name: fcnt + type: u32 + - + name: stats2 + type: nest + nested-attributes: tca-stats-attrs + - + name: stab + type: nest + nested-attributes: tca-stab-attrs + - + name: pad + type: pad + - + name: dump-invisible + type: flag + - + name: chain + type: u32 + - + name: hw-offload + type: u8 + - + name: ingress-block + type: u32 + - + name: egress-block + type: u32 + - + name: dump-flags + type: bitfield32 + - + name: ext-warn-msg + type: string + - + name: tc-act-attrs + attributes: + - + name: kind + type: string + - + name: options + type: sub-message + sub-message: tc-act-options-msg + selector: kind + - + name: index + type: u32 + - + name: stats + type: nest + nested-attributes: tc-act-stats-attrs + - + name: pad + type: pad + - + name: cookie + type: binary + - + name: flags + type: bitfield32 + - + name: hw-stats + type: bitfield32 + - + name: used-hw-stats + type: bitfield32 + - + name: in-hw-count + type: u32 + - + name: tc-act-stats-attrs + attributes: + - + name: basic + type: binary + struct: gnet-stats-basic + - + name: rate-est + type: binary + struct: gnet-stats-rate-est + - + name: queue + type: binary + struct: gnet-stats-queue + - + name: app + type: binary + - + name: rate-est64 + type: binary + struct: gnet-stats-rate-est64 + - + name: pad + type: pad + - + name: basic-hw + type: binary + struct: gnet-stats-basic + - + name: pkt64 + type: u64 + - + name: tc-act-bpf-attrs + attributes: + - + name: tm + type: binary + struct: tcf-t + - + name: parms + type: binary + - + name: ops-len + type: u16 + - + name: ops + type: binary + - + name: fd + type: u32 + - + name: name + type: string + - + name: pad + type: pad + - + name: tag + type: binary + - + name: id + type: binary + - + name: tc-act-connmark-attrs + attributes: + - + name: parms + type: binary + - + name: tm + type: binary + struct: tcf-t + - + name: pad + type: pad + - + name: tc-act-csum-attrs + attributes: + - + name: parms + type: binary + - + name: tm + type: binary + struct: tcf-t + - + name: pad + type: pad + - + name: tc-act-ct-attrs + attributes: + - + name: parms + type: binary + - + name: tm + type: binary + struct: tcf-t + - + name: action + type: u16 + - + name: zone + type: u16 + - + name: mark + type: u32 + - + name: mark-mask + type: u32 + - + name: labels + type: binary + - + name: labels-mask + type: binary + - + name: nat-ipv4-min + type: u32 + byte-order: big-endian + - + name: nat-ipv4-max + type: u32 + byte-order: big-endian + - + name: nat-ipv6-min + type: binary + - + name: nat-ipv6-max + type: binary + - + name: nat-port-min + type: u16 + byte-order: big-endian + - + name: nat-port-max + type: u16 + byte-order: big-endian + - + name: pad + type: pad + - + name: helper-name + type: string + - + name: helper-family + type: u8 + - + name: helper-proto + type: u8 + - + name: tc-act-ctinfo-attrs + attributes: + - + name: pad + type: pad + - + name: tm + type: binary + struct: tcf-t + - + name: act + type: binary + - + name: zone + type: u16 + - + name: parms-dscp-mask + type: u32 + - + name: parms-dscp-statemask + type: u32 + - + name: parms-cpmark-mask + type: u32 + - + name: stats-dscp-set + type: u64 + - + name: stats-dscp-error + type: u64 + - + name: stats-cpmark-set + type: u64 + - + name: tc-act-gate-attrs + attributes: + - + name: tm + type: binary + struct: tcf-t + - + name: parms + type: binary + - + name: pad + type: pad + - + name: priority + type: s32 + - + name: entry-list + type: binary + - + name: base-time + type: u64 + - + name: cycle-time + type: u64 + - + name: cycle-time-ext + type: u64 + - + name: flags + type: u32 + - + name: clockid + type: s32 + - + name: tc-act-ife-attrs + attributes: + - + name: parms + type: binary + - + name: tm + type: binary + struct: tcf-t + - + name: dmac + type: binary + - + name: smac + type: binary + - + name: type + type: u16 + - + name: metalst + type: binary + - + name: pad + type: pad + - + name: tc-act-mirred-attrs + attributes: + - + name: tm + type: binary + struct: tcf-t + - + name: parms + type: binary + - + name: pad + type: pad + - + name: blockid + type: binary + - + name: tc-act-mpls-attrs + attributes: + - + name: tm + type: binary + struct: tcf-t + - + name: parms + type: binary + struct: tc-mpls + - + name: pad + type: pad + - + name: proto + type: u16 + byte-order: big-endian + - + name: label + type: u32 + - + name: tc + type: u8 + - + name: ttl + type: u8 + - + name: bos + type: u8 + - + name: tc-act-nat-attrs + attributes: + - + name: parms + type: binary + - + name: tm + type: binary + struct: tcf-t + - + name: pad + type: pad + - + name: tc-act-pedit-attrs + attributes: + - + name: tm + type: binary + struct: tcf-t + - + name: parms + type: binary + struct: tc-pedit-sel + - + name: pad + type: pad + - + name: parms-ex + type: binary + - + name: keys-ex + type: binary + - + name: key-ex + type: binary + - + name: tc-act-simple-attrs + attributes: + - + name: tm + type: binary + struct: tcf-t + - + name: parms + type: binary + - + name: data + type: binary + - + name: pad + type: pad + - + name: tc-act-skbedit-attrs + attributes: + - + name: tm + type: binary + struct: tcf-t + - + name: parms + type: binary + - + name: priority + type: u32 + - + name: queue-mapping + type: u16 + - + name: mark + type: u32 + - + name: pad + type: pad + - + name: ptype + type: u16 + - + name: mask + type: u32 + - + name: flags + type: u64 + - + name: queue-mapping-max + type: u16 + - + name: tc-act-skbmod-attrs + attributes: + - + name: tm + type: binary + struct: tcf-t + - + name: parms + type: binary + - + name: dmac + type: binary + - + name: smac + type: binary + - + name: etype + type: binary + - + name: pad + type: pad + - + name: tc-act-tunnel-key-attrs + attributes: + - + name: tm + type: binary + struct: tcf-t + - + name: parms + type: binary + - + name: enc-ipv4-src + type: u32 + byte-order: big-endian + - + name: enc-ipv4-dst + type: u32 + byte-order: big-endian + - + name: enc-ipv6-src + type: binary + - + name: enc-ipv6-dst + type: binary + - + name: enc-key-id + type: u64 + byte-order: big-endian + - + name: pad + type: pad + - + name: enc-dst-port + type: u16 + byte-order: big-endian + - + name: no-csum + type: u8 + - + name: enc-opts + type: binary + - + name: enc-tos + type: u8 + - + name: enc-ttl + type: u8 + - + name: no-frag + type: flag + - + name: tc-act-vlan-attrs attributes: - - name: kind - type: string - - - name: options - type: sub-message - sub-message: tc-options-msg - selector: kind + name: tm + type: binary + struct: tcf-t - - name: stats + name: parms type: binary - struct: tc-stats + struct: tc-vlan - - name: xstats + name: push-vlan-id + type: u16 + - + name: push-vlan-protocol + type: u16 + - + name: pad + type: pad + - + name: push-vlan-priority + type: u8 + - + name: push-eth-dst type: binary - - name: rate + name: push-eth-src type: binary - struct: gnet-estimator + - + name: tc-basic-attrs + attributes: - - name: fcnt + name: classid type: u32 - - name: stats2 + name: ematches type: nest - nested-attributes: tca-stats-attrs + nested-attributes: tc-ematch-attrs - - name: stab + name: act + type: array-nest + nested-attributes: tc-act-attrs + - + name: police type: nest - nested-attributes: tca-stab-attrs + nested-attributes: tc-police-attrs + - + name: pcnt + type: binary + struct: tc-basic-pcnt - name: pad type: pad + - + name: tc-bpf-attrs + attributes: - - name: dump-invisible - type: flag + name: act + type: nest + nested-attributes: tc-act-attrs - - name: chain + name: police + type: nest + nested-attributes: tc-police-attrs + - + name: classid type: u32 - - name: hw-offload - type: u8 + name: ops-len + type: u16 - - name: ingress-block + name: ops + type: binary + - + name: fd type: u32 - - name: egress-block + name: name + type: string + - + name: flags type: u32 - - name: dump-flags - type: bitfield32 + name: flags-gen + type: u32 - - name: ext-warn-msg - type: string + name: tag + type: binary + - + name: id + type: u32 - name: tc-cake-attrs attributes: @@ -641,7 +2077,8 @@ attribute-sets: type: u32 - name: tin-stats - type: binary + type: array-nest + nested-attributes: tc-cake-tin-stats-attrs - name: deficit type: s32 @@ -660,6 +2097,84 @@ attribute-sets: - name: blue-timer-us type: s32 + - + name: tc-cake-tin-stats-attrs + attributes: + - + name: pad + type: pad + - + name: sent-packets + type: u32 + - + name: sent-bytes64 + type: u64 + - + name: dropped-packets + type: u32 + - + name: dropped-bytes64 + type: u64 + - + name: acks-dropped-packets + type: u32 + - + name: acks-dropped-bytes64 + type: u64 + - + name: ecn-marked-packets + type: u32 + - + name: ecn-marked-bytes64 + type: u64 + - + name: backlog-packets + type: u32 + - + name: backlog-bytes + type: u32 + - + name: threshold-rate64 + type: u64 + - + name: target-us + type: u32 + - + name: interval-us + type: u32 + - + name: way-indirect-hits + type: u32 + - + name: way-misses + type: u32 + - + name: way-collisions + type: u32 + - + name: peak-delay-us + type: u32 + - + name: avg-delay-us + type: u32 + - + name: base-delay-us + type: u32 + - + name: sparse-flows + type: u32 + - + name: bulk-flows + type: u32 + - + name: unresponsive-flows + type: u32 + - + name: max-skblen + type: u32 + - + name: flow-quantum + type: u32 - name: tc-cbs-attrs attributes: @@ -667,6 +2182,20 @@ attribute-sets: name: parms type: binary struct: tc-cbs-qopt + - + name: tc-cgroup-attrs + attributes: + - + name: act + type: nest + nested-attributes: tc-act-attrs + - + name: police + type: nest + nested-attributes: tc-police-attrs + - + name: ematches + type: binary - name: tc-choke-attrs attributes: @@ -677,6 +2206,9 @@ attribute-sets: - name: stab type: binary + checks: + min-len: 256 + max-len: 256 - name: max-p type: u32 @@ -704,6 +2236,56 @@ attribute-sets: - name: quantum type: u32 + - + name: tc-ematch-attrs + attributes: + - + name: tree-hdr + type: binary + struct: tcf-ematch-tree-hdr + - + name: tree-list + type: binary + - + name: tc-flow-attrs + attributes: + - + name: keys + type: u32 + - + name: mode + type: u32 + - + name: baseclass + type: u32 + - + name: rshift + type: u32 + - + name: addend + type: u32 + - + name: mask + type: u32 + - + name: xor + type: u32 + - + name: divisor + type: u32 + - + name: act + type: binary + - + name: police + type: nest + nested-attributes: tc-police-attrs + - + name: ematches + type: binary + - + name: perturb + type: u32 - name: tc-flower-attrs attributes: @@ -953,15 +2535,19 @@ attribute-sets: - name: key-arp-sha type: binary + display-hint: mac - name: key-arp-sha-mask type: binary + display-hint: mac - name: key-arp-tha type: binary + display-hint: mac - name: key-arp-tha-mask type: binary + display-hint: mac - name: key-mpls-ttl type: u8 @@ -1020,10 +2606,12 @@ attribute-sets: type: u8 - name: key-enc-opts - type: binary + type: nest + nested-attributes: tc-flower-key-enc-opts-attrs - name: key-enc-opts-mask - type: binary + type: nest + nested-attributes: tc-flower-key-enc-opts-attrs - name: in-hw-count type: u32 @@ -1056,41 +2644,165 @@ attribute-sets: name: key-ct-zone-mask type: u16 - - name: key-ct-mark - type: u32 + name: key-ct-mark + type: u32 + - + name: key-ct-mark-mask + type: u32 + - + name: key-ct-labels + type: binary + - + name: key-ct-labels-mask + type: binary + - + name: key-mpls-opts + type: nest + nested-attributes: tc-flower-key-mpls-opt-attrs + - + name: key-hash + type: u32 + - + name: key-hash-mask + type: u32 + - + name: key-num-of-vlans + type: u8 + - + name: key-pppoe-sid + type: u16 + byte-order: big-endian + - + name: key-ppp-proto + type: u16 + byte-order: big-endian + - + name: key-l2-tpv3-sid + type: u32 + byte-order: big-endian + - + name: l2-miss + type: u8 + - + name: key-cfm + type: nest + nested-attributes: tc-flower-key-cfm-attrs + - + name: key-spi + type: u32 + byte-order: big-endian + - + name: key-spi-mask + type: u32 + byte-order: big-endian + - + name: tc-flower-key-enc-opts-attrs + attributes: + - + name: geneve + type: nest + nested-attributes: tc-flower-key-enc-opt-geneve-attrs + - + name: vxlan + type: nest + nested-attributes: tc-flower-key-enc-opt-vxlan-attrs + - + name: erspan + type: nest + nested-attributes: tc-flower-key-enc-opt-erspan-attrs + - + name: gtp + type: nest + nested-attributes: tc-flower-key-enc-opt-gtp-attrs + - + name: tc-flower-key-enc-opt-geneve-attrs + attributes: + - + name: class + type: u16 + - + name: type + type: u8 + - + name: data + type: binary + - + name: tc-flower-key-enc-opt-vxlan-attrs + attributes: + - + name: gbp + type: u32 + - + name: tc-flower-key-enc-opt-erspan-attrs + attributes: + - + name: ver + type: u8 + - + name: index + type: u32 + - + name: dir + type: u8 + - + name: hwid + type: u8 + - + name: tc-flower-key-enc-opt-gtp-attrs + attributes: + - + name: pdu-type + type: u8 - - name: key-ct-mark-mask - type: u32 + name: qfi + type: u8 + - + name: tc-flower-key-mpls-opt-attrs + attributes: - - name: key-ct-labels - type: binary + name: lse-depth + type: u8 - - name: key-ct-labels-mask - type: binary + name: lse-ttl + type: u8 - - name: key-mpls-opts - type: binary + name: lse-bos + type: u8 - - name: key-hash - type: u32 + name: lse-tc + type: u8 - - name: key-hash-mask + name: lse-label type: u32 + - + name: tc-flower-key-cfm-attrs + attributes: - - name: key-num-of-vlans + name: md-level type: u8 - - name: key-pppoe-sid - type: u16 - byte-order: big-endian + name: opcode + type: u8 + - + name: tc-fw-attrs + attributes: - - name: key-ppp-proto - type: u16 - byte-order: big-endian + name: classid + type: u32 - - name: key-l2-tpv3-sid + name: police + type: nest + nested-attributes: tc-police-attrs + - + name: indev + type: string + - + name: act + type: array-nest + nested-attributes: tc-act-attrs + - + name: mask type: u32 - byte-order: big-endian - name: tc-gred-attrs attributes: @@ -1135,7 +2847,7 @@ attribute-sets: type: u32 - name: stat-bytes - type: u32 + type: u64 - name: stat-packets type: u32 @@ -1232,40 +2944,25 @@ attribute-sets: name: offload type: flag - - name: tc-act-attrs + name: tc-matchall-attrs attributes: - - name: kind - type: string + name: classid + type: u32 - - name: options - type: sub-message - sub-message: tc-act-options-msg - selector: kind + name: act + type: array-nest + nested-attributes: tc-act-attrs - - name: index + name: flags type: u32 - - name: stats + name: pcnt type: binary + struct: tc-matchall-pcnt - name: pad type: pad - - - name: cookie - type: binary - - - name: flags - type: bitfield32 - - - name: hw-stats - type: bitfield32 - - - name: used-hw-stats - type: bitfield32 - - - name: in-hw-count - type: u32 - name: tc-etf-attrs attributes: @@ -1304,48 +3001,71 @@ attribute-sets: - name: plimit type: u32 + doc: Limit of total number of packets in queue - name: flow-plimit type: u32 + doc: Limit of packets per flow - name: quantum type: u32 + doc: RR quantum - name: initial-quantum type: u32 + doc: RR quantum for new flow - name: rate-enable type: u32 + doc: Enable / disable rate limiting - name: flow-default-rate type: u32 + doc: Obsolete, do not use - name: flow-max-rate type: u32 + doc: Per flow max rate - name: buckets-log type: u32 + doc: log2(number of buckets) - name: flow-refill-delay type: u32 + doc: Flow credit refill delay in usec - name: orphan-mask type: u32 + doc: Mask applied to orphaned skb hashes - name: low-rate-threshold type: u32 + doc: Per packet delay under this rate - name: ce-threshold type: u32 + doc: DCTCP-like CE marking threshold - name: timer-slack type: u32 - name: horizon type: u32 + doc: Time horizon in usec - name: horizon-drop type: u8 + doc: Drop packets beyond horizon, or cap their EDT + - + name: priomap + type: binary + struct: tc-prio-qopt + - + name: weights + type: binary + sub-type: s32 + doc: Weights for each band - name: tc-fq-codel-attrs attributes: @@ -1427,6 +3147,7 @@ attribute-sets: - name: corr type: binary + struct: tc-netem-corr - name: delay-dist type: binary @@ -1434,15 +3155,19 @@ attribute-sets: - name: reorder type: binary + struct: tc-netem-reorder - name: corrupt type: binary + struct: tc-netem-corrupt - name: loss - type: binary + type: nest + nested-attributes: tc-netem-loss-attrs - name: rate type: binary + struct: tc-netem-rate - name: ecn type: u32 @@ -1461,10 +3186,27 @@ attribute-sets: - name: slot type: binary + struct: tc-netem-slot - name: slot-dist type: binary sub-type: s16 + - + name: prng-seed + type: u64 + - + name: tc-netem-loss-attrs + attributes: + - + name: gi + type: binary + doc: General Intuitive - 4 state model + struct: tc-netem-gimodel + - + name: ge + type: binary + doc: Gilbert Elliot models + struct: tc-netem-gemodel - name: tc-pie-attrs attributes: @@ -1492,6 +3234,44 @@ attribute-sets: - name: dq-rate-estimator type: u32 + - + name: tc-police-attrs + attributes: + - + name: tbf + type: binary + struct: tc-police + - + name: rate + type: binary + - + name: peakrate + type: binary + - + name: avrate + type: u32 + - + name: result + type: u32 + - + name: tm + type: binary + struct: tcf-t + - + name: pad + type: pad + - + name: rate64 + type: u64 + - + name: peakrate64 + type: u64 + - + name: pktrate64 + type: u64 + - + name: pktburst64 + type: u64 - name: tc-qfq-attrs attributes: @@ -1516,13 +3296,36 @@ attribute-sets: type: u32 - name: flags - type: binary + type: bitfield32 - name: early-drop-block type: u32 - name: mark-block type: u32 + - + name: tc-route-attrs + attributes: + - + name: classid + type: u32 + - + name: to + type: u32 + - + name: from + type: u32 + - + name: iif + type: u32 + - + name: police + type: nest + nested-attributes: tc-police-attrs + - + name: act + type: array-nest + nested-attributes: tc-act-attrs - name: tc-taprio-attrs attributes: @@ -1629,17 +3432,43 @@ attribute-sets: name: pad type: pad - - name: tca-gact-attrs + name: tc-act-sample-attrs + attributes: + - + name: tm + type: binary + struct: tcf-t + - + name: parms + type: binary + struct: tc-gen + - + name: rate + type: u32 + - + name: trunc-size + type: u32 + - + name: psample-group + type: u32 + - + name: pad + type: pad + - + name: tc-act-gact-attrs attributes: - name: tm type: binary + struct: tcf-t - name: parms type: binary + struct: tc-gen - name: prob type: binary + struct: tc-gact-p - name: pad type: pad @@ -1659,34 +3488,89 @@ attribute-sets: - name: basic type: binary + struct: gnet-stats-basic - name: rate-est type: binary + struct: gnet-stats-rate-est - name: queue type: binary + struct: gnet-stats-queue - name: app - type: binary # TODO sub-message needs 2+ level deep lookup + type: sub-message sub-message: tca-stats-app-msg selector: kind - name: rate-est64 type: binary + struct: gnet-stats-rate-est64 - name: pad type: pad - name: basic-hw type: binary + struct: gnet-stats-basic - name: pkt64 + type: u64 + - + name: tc-u32-attrs + attributes: + - + name: classid + type: u32 + - + name: hash + type: u32 + - + name: link + type: u32 + - + name: divisor + type: u32 + - + name: sel + type: binary + struct: tc-u32-sel + - + name: police + type: nest + nested-attributes: tc-police-attrs + - + name: act + type: array-nest + nested-attributes: tc-act-attrs + - + name: indev + type: string + - + name: pcnt + type: binary + struct: tc-u32-pcnt + - + name: mark type: binary + struct: tc-u32-mark + - + name: flags + type: u32 + - + name: pad + type: pad sub-messages: - name: tc-options-msg formats: + - + value: basic + attribute-set: tc-basic-attrs + - + value: bpf + attribute-set: tc-bpf-attrs - value: bfifo fixed-header: tc-fifo-qopt @@ -1696,6 +3580,9 @@ sub-messages: - value: cbs attribute-set: tc-cbs-attrs + - + value: cgroup + attribute-set: tc-cgroup-attrs - value: choke attribute-set: tc-choke-attrs @@ -1713,6 +3600,12 @@ sub-messages: - value: ets attribute-set: tc-ets-attrs + - + value: flow + attribute-set: tc-flow-attrs + - + value: flower + attribute-set: tc-flower-attrs - value: fq attribute-set: tc-fq-attrs @@ -1723,8 +3616,8 @@ sub-messages: value: fq_pie attribute-set: tc-fq-pie-attrs - - value: flower - attribute-set: tc-flower-attrs + value: fw + attribute-set: tc-fw-attrs - value: gred attribute-set: tc-gred-attrs @@ -1739,6 +3632,9 @@ sub-messages: attribute-set: tc-htb-attrs - value: ingress # no content + - + value: matchall + attribute-set: tc-matchall-attrs - value: mq # no content - @@ -1775,6 +3671,9 @@ sub-messages: - value: red attribute-set: tc-red-attrs + - + value: route + attribute-set: tc-route-attrs - value: sfb fixed-header: tc-sfb-qopt @@ -1787,88 +3686,105 @@ sub-messages: - value: tbf attribute-set: tc-tbf-attrs - - - name: tc-act-options-msg - formats: - - value: gact - attribute-set: tca-gact-attrs + value: u32 + attribute-set: tc-u32-attrs - - name: tca-stats-app-msg + name: tc-act-options-msg formats: - - value: bfifo - - - value: blackhole + value: bpf + attribute-set: tc-act-bpf-attrs - - value: cake - attribute-set: tc-cake-stats-attrs + value: connmark + attribute-set: tc-act-connmark-attrs - - value: cbs + value: csum + attribute-set: tc-act-csum-attrs - - value: choke + value: ct + attribute-set: tc-act-ct-attrs - - value: clsact + value: ctinfo + attribute-set: tc-act-ctinfo-attrs - - value: codel + value: gact + attribute-set: tc-act-gact-attrs - - value: drr + value: gate + attribute-set: tc-act-gate-attrs - - value: etf + value: ife + attribute-set: tc-act-ife-attrs - - value: ets + value: mirred + attribute-set: tc-act-mirred-attrs - - value: fq + value: mpls + attribute-set: tc-act-mpls-attrs - - value: fq_codel + value: nat + attribute-set: tc-act-nat-attrs - - value: fq_pie + value: pedit + attribute-set: tc-act-pedit-attrs - - value: flower + value: police + attribute-set: tc-act-police-attrs - - value: gred + value: sample + attribute-set: tc-act-sample-attrs - - value: hfsc + value: simple + attribute-set: tc-act-simple-attrs - - value: hhf + value: skbedit + attribute-set: tc-act-skbedit-attrs - - value: htb + value: skbmod + attribute-set: tc-act-skbmod-attrs - - value: ingress + value: tunnel_key + attribute-set: tc-act-tunnel-key-attrs - - value: mq + value: vlan + attribute-set: tc-act-vlan-attrs + - + name: tca-stats-app-msg + formats: - - value: mqprio + value: cake + attribute-set: tc-cake-stats-attrs - - value: multiq + value: choke + fixed-header: tc-choke-xstats - - value: netem + value: codel + fixed-header: tc-codel-xstats - - value: noqueue + value: fq + fixed-header: tc-fq-qd-stats - - value: pfifo + value: fq_codel + fixed-header: tc-fq-codel-xstats - - value: pfifo_fast + value: fq_pie + fixed-header: tc-fq-pie-xstats - - value: pfifo_head_drop + value: hhf + fixed-header: tc-hhf-xstats - value: pie - - - value: plug - - - value: prio - - - value: qfq + fixed-header: tc-pie-xstats - value: red + fixed-header: tc-red-xstats - value: sfb + fixed-header: tc-sfb-xstats - value: sfq - - - value: taprio - - - value: tbf + fixed-header: tc-sfq-xstats operations: enum-model: directional -- cgit v1.2.3 From b2005bb756e1d0ef400a79f3e1bce4f3870415a9 Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Mon, 29 Jan 2024 15:21:21 +0100 Subject: dt-bindings: net: qcom,ipa: do not override firmware-name $ref dtschema package defines firmware-name as string-array, so individual bindings should not make it a string but instead just narrow the number of expected firmware file names. Signed-off-by: Krzysztof Kozlowski Acked-by: Conor Dooley Acked-by: Alex Elder Link: https://lore.kernel.org/r/20240129142121.102450-1-krzysztof.kozlowski@linaro.org Signed-off-by: Paolo Abeni --- Documentation/devicetree/bindings/net/qcom,ipa.yaml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/qcom,ipa.yaml b/Documentation/devicetree/bindings/net/qcom,ipa.yaml index c30218684cfe..53cae71d9957 100644 --- a/Documentation/devicetree/bindings/net/qcom,ipa.yaml +++ b/Documentation/devicetree/bindings/net/qcom,ipa.yaml @@ -159,7 +159,7 @@ properties: when the AP (not the modem) performs early initialization. firmware-name: - $ref: /schemas/types.yaml#/definitions/string + maxItems: 1 description: If present, name (or relative path) of the file within the firmware search path containing the firmware image used when -- cgit v1.2.3 From cc605a4c1204ccaa117f6f56e863971e03072342 Mon Sep 17 00:00:00 2001 From: Alexander Stein Date: Thu, 14 Dec 2023 15:23:25 +0100 Subject: dt-bindings: arm: add TQMa8Xx boards TQMa8Xx is a SOM series featuring NXP i.MX8X SoC. They are called TQMa8XQP and TQMa8XDP respectively. MBa8Xx is an evaluation mainboard for this SOM Signed-off-by: Markus Niebel Signed-off-by: Alexander Stein Reviewed-by: Marco Felsch Reviewed-by: Conor Dooley Signed-off-by: Shawn Guo --- Documentation/devicetree/bindings/arm/fsl.yaml | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml index 228dcc5c7d6f..1fe59fe70b1f 100644 --- a/Documentation/devicetree/bindings/arm/fsl.yaml +++ b/Documentation/devicetree/bindings/arm/fsl.yaml @@ -1232,6 +1232,22 @@ properties: - const: toradex,colibri-imx8x - const: fsl,imx8qxp + - description: + TQMa8Xx is a series of SOM featuring NXP i.MX8X system-on-chip + variants. It is designed to be clicked on different carrier boards + MBa8Xx is the starterkit + oneOf: + - items: + - enum: + - tq,imx8dxp-tqma8xdp-mba8xx # TQ-Systems GmbH TQMa8XDP SOM on MBa8Xx + - const: tq,imx8dxp-tqma8xdp # TQ-Systems GmbH TQMa8XDP SOM (with i.MX8DXP) + - const: fsl,imx8dxp + - items: + - enum: + - tq,imx8qxp-tqma8xqp-mba8xx # TQ-Systems GmbH TQMa8XQP SOM on MBa8Xx + - const: tq,imx8qxp-tqma8xqp # TQ-Systems GmbH TQMa8XQP SOM (with i.MX8QXP) + - const: fsl,imx8qxp + - description: i.MX8ULP based Boards items: - enum: -- cgit v1.2.3 From 60314831d2942b6eab974af74d2238dffc321359 Mon Sep 17 00:00:00 2001 From: Hugues Fruchet Date: Wed, 10 Jan 2024 11:46:38 +0100 Subject: media: dt-bindings: media: Document STM32MP25 VDEC & VENC video codecs Add STM32MP25 VDEC video decoder & VENC video encoder bindings. Reviewed-by: Krzysztof Kozlowski Signed-off-by: Hugues Fruchet Signed-off-by: Mauro Carvalho Chehab --- .../bindings/media/st,stm32mp25-video-codec.yaml | 49 ++++++++++++++++++++++ 1 file changed, 49 insertions(+) create mode 100644 Documentation/devicetree/bindings/media/st,stm32mp25-video-codec.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/media/st,stm32mp25-video-codec.yaml b/Documentation/devicetree/bindings/media/st,stm32mp25-video-codec.yaml new file mode 100644 index 000000000000..b8611bc8756c --- /dev/null +++ b/Documentation/devicetree/bindings/media/st,stm32mp25-video-codec.yaml @@ -0,0 +1,49 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/media/st,stm32mp25-video-codec.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: STMicroelectronics STM32MP25 VDEC video decoder & VENC video encoder + +maintainers: + - Hugues Fruchet + +description: + The STMicroelectronics STM32MP25 SOCs embeds a VDEC video hardware + decoder peripheral based on Verisilicon VC8000NanoD IP (former Hantro G1) + and a VENC video hardware encoder peripheral based on Verisilicon + VC8000NanoE IP (former Hantro H1). + +properties: + compatible: + enum: + - st,stm32mp25-vdec + - st,stm32mp25-venc + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + +required: + - compatible + - reg + - interrupts + - clocks + +additionalProperties: false + +examples: + - | + #include + video-codec@580d0000 { + compatible = "st,stm32mp25-vdec"; + reg = <0x580d0000 0x3c8>; + interrupts = ; + clocks = <&ck_icn_p_vdec>; + }; -- cgit v1.2.3 From 5f8066d4578241a2d9d63428e6a604807c2ab226 Mon Sep 17 00:00:00 2001 From: Philippe Schenker Date: Tue, 30 Jan 2024 09:34:18 +0100 Subject: dt-bindings: net: dsa: Add KSZ8567 switch support This commit adds the dt-binding for KSZ8567, a robust 7-port Ethernet switch. The KSZ8567 features two RGMII/MII/RMII interfaces, each capable of gigabit speeds, complemented by five 10/100 Mbps MAC/PHYs. This binding is necessary to set specific capabilities for this switch chip that are necessary due to the ksz dsa driver only accepting specific chip ids. The KSZ8567 is very similar to KSZ9567 however only containing 100 Mbps phys on its downstream ports. Signed-off-by: Philippe Schenker Acked-by: Conor Dooley Reviewed-by: Andrew Lunn Reviewed-by: Florian Fainelli Link: https://lore.kernel.org/r/20240130083419.135763-1-dev@pschenker.ch Signed-off-by: Paolo Abeni --- Documentation/devicetree/bindings/net/dsa/microchip,ksz.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/dsa/microchip,ksz.yaml b/Documentation/devicetree/bindings/net/dsa/microchip,ksz.yaml index c963dc09e8e1..52acc15ebcbf 100644 --- a/Documentation/devicetree/bindings/net/dsa/microchip,ksz.yaml +++ b/Documentation/devicetree/bindings/net/dsa/microchip,ksz.yaml @@ -31,6 +31,7 @@ properties: - microchip,ksz9893 - microchip,ksz9563 - microchip,ksz8563 + - microchip,ksz8567 reset-gpios: description: -- cgit v1.2.3 From 088a464ed53feeab9632c6748b9f25354639e2bd Mon Sep 17 00:00:00 2001 From: Dave Thaler Date: Tue, 30 Jan 2024 19:37:59 -0800 Subject: bpf, docs: Clarify which legacy packet instructions existed As discussed on the BPF IETF mailing list (see link), this patch updates the "Legacy BPF Packet access instructions" section to clarify which instructions are deprecated (vs which were never defined and so are not deprecated). Signed-off-by: Dave Thaler Signed-off-by: Daniel Borkmann Acked-by: Yonghong Song Acked-by: David Vernet Link: https://mailarchive.ietf.org/arch/msg/bpf/5LnnKm093cGpOmDI9TnLQLBXyys Link: https://lore.kernel.org/bpf/20240131033759.3634-1-dthaler1968@gmail.com --- Documentation/bpf/standardization/instruction-set.rst | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/bpf/standardization/instruction-set.rst b/Documentation/bpf/standardization/instruction-set.rst index fceacca46299..dcbc9193c66f 100644 --- a/Documentation/bpf/standardization/instruction-set.rst +++ b/Documentation/bpf/standardization/instruction-set.rst @@ -630,7 +630,9 @@ Legacy BPF Packet access instructions ------------------------------------- BPF previously introduced special instructions for access to packet data that were -carried over from classic BPF. However, these instructions are +carried over from classic BPF. These instructions used an instruction +class of BPF_LD, a size modifier of BPF_W, BPF_H, or BPF_B, and a +mode modifier of BPF_ABS or BPF_IND. However, these instructions are deprecated and should no longer be used. All legacy packet access instructions belong to the "legacy" conformance group instead of the "basic" conformance group. -- cgit v1.2.3 From c06983f853bc58eafe05f75dfd7e8bdafba3cd8c Mon Sep 17 00:00:00 2001 From: Sakari Ailus Date: Fri, 5 Jan 2024 11:59:22 +0100 Subject: media: Documentation: Rework CCS driver documentation Drop duplicated UAPI specific portions of the CCS (kernel) documentation and fix a spelling error in UAPI documentation previously fixed in driver documentation. Also add references both ways. Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab --- Documentation/driver-api/media/drivers/ccs/ccs.rst | 53 ++-------------------- Documentation/userspace-api/media/drivers/ccs.rst | 6 ++- 2 files changed, 10 insertions(+), 49 deletions(-) (limited to 'Documentation') diff --git a/Documentation/driver-api/media/drivers/ccs/ccs.rst b/Documentation/driver-api/media/drivers/ccs/ccs.rst index 776eec72bc80..5d4451339b7f 100644 --- a/Documentation/driver-api/media/drivers/ccs/ccs.rst +++ b/Documentation/driver-api/media/drivers/ccs/ccs.rst @@ -2,59 +2,16 @@ .. include:: +.. _media-ccs-driver: + MIPI CCS camera sensor driver ============================= The MIPI CCS camera sensor driver is a generic driver for `MIPI CCS `_ compliant -camera sensors. It exposes three sub-devices representing the pixel array, -the binner and the scaler. - -As the capabilities of individual devices vary, the driver exposes -interfaces based on the capabilities that exist in hardware. - -Pixel Array sub-device ----------------------- - -The pixel array sub-device represents the camera sensor's pixel matrix, as well -as analogue crop functionality present in many compliant devices. The analogue -crop is configured using the ``V4L2_SEL_TGT_CROP`` on the source pad (0) of the -entity. The size of the pixel matrix can be obtained by getting the -``V4L2_SEL_TGT_NATIVE_SIZE`` target. - -Binner ------- - -The binner sub-device represents the binning functionality on the sensor. For -that purpose, selection target ``V4L2_SEL_TGT_COMPOSE`` is supported on the -sink pad (0). - -Additionally, if a device has no scaler or digital crop functionality, the -source pad (1) exposes another digital crop selection rectangle that can only -crop at the end of the lines and frames. - -Scaler ------- - -The scaler sub-device represents the digital crop and scaling functionality of -the sensor. The V4L2 selection target ``V4L2_SEL_TGT_CROP`` is used to -configure the digital crop on the sink pad (0) when digital crop is supported. -Scaling is configured using selection target ``V4L2_SEL_TGT_COMPOSE`` on the -sink pad (0) as well. - -Additionally, if the scaler sub-device exists, its source pad (1) exposes -another digital crop selection rectangle that can only crop at the end of the -lines and frames. - -Digital and analogue crop -------------------------- - -Digital crop functionality is referred to as cropping that effectively works by -dropping some data on the floor. Analogue crop, on the other hand, means that -the cropped information is never retrieved. In case of camera sensors, the -analogue data is never read from the pixel matrix that are outside the -configured selection rectangle that designates crop. The difference has an -effect in device timing and likely also in power consumption. +camera sensors. + +Also see :ref:`the CCS driver UAPI documentation `. CCS static data --------------- diff --git a/Documentation/userspace-api/media/drivers/ccs.rst b/Documentation/userspace-api/media/drivers/ccs.rst index 161cb65f4d98..03015b33d5ab 100644 --- a/Documentation/userspace-api/media/drivers/ccs.rst +++ b/Documentation/userspace-api/media/drivers/ccs.rst @@ -2,6 +2,8 @@ .. include:: +.. _media-ccs-uapi: + MIPI CCS camera sensor driver ============================= @@ -13,6 +15,8 @@ the binner and the scaler. As the capabilities of individual devices vary, the driver exposes interfaces based on the capabilities that exist in hardware. +Also see :ref:`the CCS driver kernel documentation `. + Pixel Array sub-device ---------------------- @@ -30,7 +34,7 @@ that purpose, selection target ``V4L2_SEL_TGT_COMPOSE`` is supported on the sink pad (0). Additionally, if a device has no scaler or digital crop functionality, the -source pad (1) expses another digital crop selection rectangle that can only +source pad (1) exposes another digital crop selection rectangle that can only crop at the end of the lines and frames. Scaler -- cgit v1.2.3 From bd765cc910127ee8ed6cd83dae0f0bfbca69d71e Mon Sep 17 00:00:00 2001 From: David Arinzon Date: Tue, 30 Jan 2024 09:53:44 +0000 Subject: net: ena: Add more documentation for RX copybreak This patch contains more details about the functionality of RX copybreak. Signed-off-by: Shay Agroskin Signed-off-by: David Arinzon Signed-off-by: Paolo Abeni --- Documentation/networking/device_drivers/ethernet/amazon/ena.rst | 6 ++++++ 1 file changed, 6 insertions(+) (limited to 'Documentation') diff --git a/Documentation/networking/device_drivers/ethernet/amazon/ena.rst b/Documentation/networking/device_drivers/ethernet/amazon/ena.rst index b842bcb14255..a4c7d0c65fd7 100644 --- a/Documentation/networking/device_drivers/ethernet/amazon/ena.rst +++ b/Documentation/networking/device_drivers/ethernet/amazon/ena.rst @@ -211,10 +211,16 @@ Documentation/networking/net_dim.rst RX copybreak ============ + 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. +This option controls the maximum packet length for which the RX +descriptor it was received on would be recycled. When a packet smaller +than RX copybreak bytes is received, it is copied into a new memory +buffer and the RX descriptor is returned to HW. + Statistics ========== -- cgit v1.2.3 From feb8831be9d468ee961289c6a275536a1ee0011c Mon Sep 17 00:00:00 2001 From: Jason Chen Date: Wed, 24 Jan 2024 15:43:01 +0100 Subject: media: ov08x40: Reduce start streaming time Because video duration involves calculating the streaming time, and i2c communication incurs too many XTALK register settings every 4 bytes with i2c START and STOP. So we have opted switch to the i2c burst method. This method involves writing the XTALK registers in the order of the register block. The start streaming time can be reduced from around 400ms to 150ms [Sakari Ailus: Drop unneeded dev_dbg().] Signed-off-by: Jason Chen Reviewed-by: Sergey Senozhatsky Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab --- .../bindings/media/video-interfaces.yaml | 2 +- arch/arm/boot/dts/ti/omap/omap3-n9.dts | 2 +- drivers/media/i2c/ov08x40.c | 1209 +------------------- 3 files changed, 59 insertions(+), 1154 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/media/video-interfaces.yaml b/Documentation/devicetree/bindings/media/video-interfaces.yaml index 26e3e7d7c67b..ea511f2fed98 100644 --- a/Documentation/devicetree/bindings/media/video-interfaces.yaml +++ b/Documentation/devicetree/bindings/media/video-interfaces.yaml @@ -190,7 +190,7 @@ properties: Allow MIPI CSI-2 non-continuous clock mode. link-frequencies: - $ref: /schemas/types.yaml#/definitions/uint64-array + $ref: /schemas/types.yaml#/definitions/uint32-array description: Allowed data bus frequencies. For MIPI CSI-2, for instance, this is the actual frequency of the bus, not bits per clock per lane value. An array diff --git a/arch/arm/boot/dts/ti/omap/omap3-n9.dts b/arch/arm/boot/dts/ti/omap/omap3-n9.dts index a3cf3f443785..728a8fcf25b3 100644 --- a/arch/arm/boot/dts/ti/omap/omap3-n9.dts +++ b/arch/arm/boot/dts/ti/omap/omap3-n9.dts @@ -26,7 +26,7 @@ flash-leds = <&as3645a_flash &as3645a_indicator>; port { smia_1_1: endpoint { - link-frequencies = /bits/ 64 <199200000 210000000 499200000>; + link-frequencies = /bits/ 32 <199200000 210000000 499200000>; clock-lanes = <0>; data-lanes = <1 2>; remote-endpoint = <&csi2a_ep>; diff --git a/drivers/media/i2c/ov08x40.c b/drivers/media/i2c/ov08x40.c index 010a6017e1ad..48df077522ad 100644 --- a/drivers/media/i2c/ov08x40.c +++ b/drivers/media/i2c/ov08x40.c @@ -1,6 +1,7 @@ // SPDX-License-Identifier: GPL-2.0 // Copyright (c) 2022 Intel Corporation. +#include #include #include #include @@ -95,6 +96,12 @@ /* Vertical Window Offset */ #define OV08X40_REG_V_WIN_OFFSET 0x3813 +/* Burst Register */ +#define OV08X40_REG_XTALK_FIRST_A 0x5a80 +#define OV08X40_REG_XTALK_LAST_A 0x5b9f +#define OV08X40_REG_XTALK_FIRST_B 0x5bc0 +#define OV08X40_REG_XTALK_LAST_B 0x5f1f + enum { OV08X40_LINK_FREQ_400MHZ_INDEX, }; @@ -670,1158 +677,6 @@ static const struct ov08x40_reg mode_3856x2416_regs[] = { {0x3502, 0x10}, {0x3508, 0x0f}, {0x3509, 0x80}, - {0x5a80, 0x75}, - {0x5a81, 0x75}, - {0x5a82, 0x75}, - {0x5a83, 0x75}, - {0x5a84, 0x75}, - {0x5a85, 0x75}, - {0x5a86, 0x75}, - {0x5a87, 0x75}, - {0x5a88, 0x75}, - {0x5a89, 0x75}, - {0x5a8a, 0x75}, - {0x5a8b, 0x75}, - {0x5a8c, 0x75}, - {0x5a8d, 0x75}, - {0x5a8e, 0x75}, - {0x5a8f, 0x75}, - {0x5a90, 0x75}, - {0x5a91, 0x75}, - {0x5a92, 0x75}, - {0x5a93, 0x75}, - {0x5a94, 0x75}, - {0x5a95, 0x75}, - {0x5a96, 0x75}, - {0x5a97, 0x75}, - {0x5a98, 0x75}, - {0x5a99, 0x75}, - {0x5a9a, 0x75}, - {0x5a9b, 0x75}, - {0x5a9c, 0x75}, - {0x5a9d, 0x75}, - {0x5a9e, 0x75}, - {0x5a9f, 0x75}, - {0x5aa0, 0x75}, - {0x5aa1, 0x75}, - {0x5aa2, 0x75}, - {0x5aa3, 0x75}, - {0x5aa4, 0x75}, - {0x5aa5, 0x75}, - {0x5aa6, 0x75}, - {0x5aa7, 0x75}, - {0x5aa8, 0x75}, - {0x5aa9, 0x75}, - {0x5aaa, 0x75}, - {0x5aab, 0x75}, - {0x5aac, 0x75}, - {0x5aad, 0x75}, - {0x5aae, 0x75}, - {0x5aaf, 0x75}, - {0x5ab0, 0x75}, - {0x5ab1, 0x75}, - {0x5ab2, 0x75}, - {0x5ab3, 0x75}, - {0x5ab4, 0x75}, - {0x5ab5, 0x75}, - {0x5ab6, 0x75}, - {0x5ab7, 0x75}, - {0x5ab8, 0x75}, - {0x5ab9, 0x75}, - {0x5aba, 0x75}, - {0x5abb, 0x75}, - {0x5abc, 0x75}, - {0x5abd, 0x75}, - {0x5abe, 0x75}, - {0x5abf, 0x75}, - {0x5ac0, 0x75}, - {0x5ac1, 0x75}, - {0x5ac2, 0x75}, - {0x5ac3, 0x75}, - {0x5ac4, 0x75}, - {0x5ac5, 0x75}, - {0x5ac6, 0x75}, - {0x5ac7, 0x75}, - {0x5ac8, 0x75}, - {0x5ac9, 0x75}, - {0x5aca, 0x75}, - {0x5acb, 0x75}, - {0x5acc, 0x75}, - {0x5acd, 0x75}, - {0x5ace, 0x75}, - {0x5acf, 0x75}, - {0x5ad0, 0x75}, - {0x5ad1, 0x75}, - {0x5ad2, 0x75}, - {0x5ad3, 0x75}, - {0x5ad4, 0x75}, - {0x5ad5, 0x75}, - {0x5ad6, 0x75}, - {0x5ad7, 0x75}, - {0x5ad8, 0x75}, - {0x5ad9, 0x75}, - {0x5ada, 0x75}, - {0x5adb, 0x75}, - {0x5adc, 0x75}, - {0x5add, 0x75}, - {0x5ade, 0x75}, - {0x5adf, 0x75}, - {0x5ae0, 0x75}, - {0x5ae1, 0x75}, - {0x5ae2, 0x75}, - {0x5ae3, 0x75}, - {0x5ae4, 0x75}, - {0x5ae5, 0x75}, - {0x5ae6, 0x75}, - {0x5ae7, 0x75}, - {0x5ae8, 0x75}, - {0x5ae9, 0x75}, - {0x5aea, 0x75}, - {0x5aeb, 0x75}, - {0x5aec, 0x75}, - {0x5aed, 0x75}, - {0x5aee, 0x75}, - {0x5aef, 0x75}, - {0x5af0, 0x75}, - {0x5af1, 0x75}, - {0x5af2, 0x75}, - {0x5af3, 0x75}, - {0x5af4, 0x75}, - {0x5af5, 0x75}, - {0x5af6, 0x75}, - {0x5af7, 0x75}, - {0x5af8, 0x75}, - {0x5af9, 0x75}, - {0x5afa, 0x75}, - {0x5afb, 0x75}, - {0x5afc, 0x75}, - {0x5afd, 0x75}, - {0x5afe, 0x75}, - {0x5aff, 0x75}, - {0x5b00, 0x75}, - {0x5b01, 0x75}, - {0x5b02, 0x75}, - {0x5b03, 0x75}, - {0x5b04, 0x75}, - {0x5b05, 0x75}, - {0x5b06, 0x75}, - {0x5b07, 0x75}, - {0x5b08, 0x75}, - {0x5b09, 0x75}, - {0x5b0a, 0x75}, - {0x5b0b, 0x75}, - {0x5b0c, 0x75}, - {0x5b0d, 0x75}, - {0x5b0e, 0x75}, - {0x5b0f, 0x75}, - {0x5b10, 0x75}, - {0x5b11, 0x75}, - {0x5b12, 0x75}, - {0x5b13, 0x75}, - {0x5b14, 0x75}, - {0x5b15, 0x75}, - {0x5b16, 0x75}, - {0x5b17, 0x75}, - {0x5b18, 0x75}, - {0x5b19, 0x75}, - {0x5b1a, 0x75}, - {0x5b1b, 0x75}, - {0x5b1c, 0x75}, - {0x5b1d, 0x75}, - {0x5b1e, 0x75}, - {0x5b1f, 0x75}, - {0x5b20, 0x75}, - {0x5b21, 0x75}, - {0x5b22, 0x75}, - {0x5b23, 0x75}, - {0x5b24, 0x75}, - {0x5b25, 0x75}, - {0x5b26, 0x75}, - {0x5b27, 0x75}, - {0x5b28, 0x75}, - {0x5b29, 0x75}, - {0x5b2a, 0x75}, - {0x5b2b, 0x75}, - {0x5b2c, 0x75}, - {0x5b2d, 0x75}, - {0x5b2e, 0x75}, - {0x5b2f, 0x75}, - {0x5b30, 0x75}, - {0x5b31, 0x75}, - {0x5b32, 0x75}, - {0x5b33, 0x75}, - {0x5b34, 0x75}, - {0x5b35, 0x75}, - {0x5b36, 0x75}, - {0x5b37, 0x75}, - {0x5b38, 0x75}, - {0x5b39, 0x75}, - {0x5b3a, 0x75}, - {0x5b3b, 0x75}, - {0x5b3c, 0x75}, - {0x5b3d, 0x75}, - {0x5b3e, 0x75}, - {0x5b3f, 0x75}, - {0x5b40, 0x75}, - {0x5b41, 0x75}, - {0x5b42, 0x75}, - {0x5b43, 0x75}, - {0x5b44, 0x75}, - {0x5b45, 0x75}, - {0x5b46, 0x75}, - {0x5b47, 0x75}, - {0x5b48, 0x75}, - {0x5b49, 0x75}, - {0x5b4a, 0x75}, - {0x5b4b, 0x75}, - {0x5b4c, 0x75}, - {0x5b4d, 0x75}, - {0x5b4e, 0x75}, - {0x5b4f, 0x75}, - {0x5b50, 0x75}, - {0x5b51, 0x75}, - {0x5b52, 0x75}, - {0x5b53, 0x75}, - {0x5b54, 0x75}, - {0x5b55, 0x75}, - {0x5b56, 0x75}, - {0x5b57, 0x75}, - {0x5b58, 0x75}, - {0x5b59, 0x75}, - {0x5b5a, 0x75}, - {0x5b5b, 0x75}, - {0x5b5c, 0x75}, - {0x5b5d, 0x75}, - {0x5b5e, 0x75}, - {0x5b5f, 0x75}, - {0x5b60, 0x75}, - {0x5b61, 0x75}, - {0x5b62, 0x75}, - {0x5b63, 0x75}, - {0x5b64, 0x75}, - {0x5b65, 0x75}, - {0x5b66, 0x75}, - {0x5b67, 0x75}, - {0x5b68, 0x75}, - {0x5b69, 0x75}, - {0x5b6a, 0x75}, - {0x5b6b, 0x75}, - {0x5b6c, 0x75}, - {0x5b6d, 0x75}, - {0x5b6e, 0x75}, - {0x5b6f, 0x75}, - {0x5b70, 0x75}, - {0x5b71, 0x75}, - {0x5b72, 0x75}, - {0x5b73, 0x75}, - {0x5b74, 0x75}, - {0x5b75, 0x75}, - {0x5b76, 0x75}, - {0x5b77, 0x75}, - {0x5b78, 0x75}, - {0x5b79, 0x75}, - {0x5b7a, 0x75}, - {0x5b7b, 0x75}, - {0x5b7c, 0x75}, - {0x5b7d, 0x75}, - {0x5b7e, 0x75}, - {0x5b7f, 0x75}, - {0x5b80, 0x75}, - {0x5b81, 0x75}, - {0x5b82, 0x75}, - {0x5b83, 0x75}, - {0x5b84, 0x75}, - {0x5b85, 0x75}, - {0x5b86, 0x75}, - {0x5b87, 0x75}, - {0x5b88, 0x75}, - {0x5b89, 0x75}, - {0x5b8a, 0x75}, - {0x5b8b, 0x75}, - {0x5b8c, 0x75}, - {0x5b8d, 0x75}, - {0x5b8e, 0x75}, - {0x5b8f, 0x75}, - {0x5b90, 0x75}, - {0x5b91, 0x75}, - {0x5b92, 0x75}, - {0x5b93, 0x75}, - {0x5b94, 0x75}, - {0x5b95, 0x75}, - {0x5b96, 0x75}, - {0x5b97, 0x75}, - {0x5b98, 0x75}, - {0x5b99, 0x75}, - {0x5b9a, 0x75}, - {0x5b9b, 0x75}, - {0x5b9c, 0x75}, - {0x5b9d, 0x75}, - {0x5b9e, 0x75}, - {0x5b9f, 0x75}, - {0x5bc0, 0x75}, - {0x5bc1, 0x75}, - {0x5bc2, 0x75}, - {0x5bc3, 0x75}, - {0x5bc4, 0x75}, - {0x5bc5, 0x75}, - {0x5bc6, 0x75}, - {0x5bc7, 0x75}, - {0x5bc8, 0x75}, - {0x5bc9, 0x75}, - {0x5bca, 0x75}, - {0x5bcb, 0x75}, - {0x5bcc, 0x75}, - {0x5bcd, 0x75}, - {0x5bce, 0x75}, - {0x5bcf, 0x75}, - {0x5bd0, 0x75}, - {0x5bd1, 0x75}, - {0x5bd2, 0x75}, - {0x5bd3, 0x75}, - {0x5bd4, 0x75}, - {0x5bd5, 0x75}, - {0x5bd6, 0x75}, - {0x5bd7, 0x75}, - {0x5bd8, 0x75}, - {0x5bd9, 0x75}, - {0x5bda, 0x75}, - {0x5bdb, 0x75}, - {0x5bdc, 0x75}, - {0x5bdd, 0x75}, - {0x5bde, 0x75}, - {0x5bdf, 0x75}, - {0x5be0, 0x75}, - {0x5be1, 0x75}, - {0x5be2, 0x75}, - {0x5be3, 0x75}, - {0x5be4, 0x75}, - {0x5be5, 0x75}, - {0x5be6, 0x75}, - {0x5be7, 0x75}, - {0x5be8, 0x75}, - {0x5be9, 0x75}, - {0x5bea, 0x75}, - {0x5beb, 0x75}, - {0x5bec, 0x75}, - {0x5bed, 0x75}, - {0x5bee, 0x75}, - {0x5bef, 0x75}, - {0x5bf0, 0x75}, - {0x5bf1, 0x75}, - {0x5bf2, 0x75}, - {0x5bf3, 0x75}, - {0x5bf4, 0x75}, - {0x5bf5, 0x75}, - {0x5bf6, 0x75}, - {0x5bf7, 0x75}, - {0x5bf8, 0x75}, - {0x5bf9, 0x75}, - {0x5bfa, 0x75}, - {0x5bfb, 0x75}, - {0x5bfc, 0x75}, - {0x5bfd, 0x75}, - {0x5bfe, 0x75}, - {0x5bff, 0x75}, - {0x5c00, 0x75}, - {0x5c01, 0x75}, - {0x5c02, 0x75}, - {0x5c03, 0x75}, - {0x5c04, 0x75}, - {0x5c05, 0x75}, - {0x5c06, 0x75}, - {0x5c07, 0x75}, - {0x5c08, 0x75}, - {0x5c09, 0x75}, - {0x5c0a, 0x75}, - {0x5c0b, 0x75}, - {0x5c0c, 0x75}, - {0x5c0d, 0x75}, - {0x5c0e, 0x75}, - {0x5c0f, 0x75}, - {0x5c10, 0x75}, - {0x5c11, 0x75}, - {0x5c12, 0x75}, - {0x5c13, 0x75}, - {0x5c14, 0x75}, - {0x5c15, 0x75}, - {0x5c16, 0x75}, - {0x5c17, 0x75}, - {0x5c18, 0x75}, - {0x5c19, 0x75}, - {0x5c1a, 0x75}, - {0x5c1b, 0x75}, - {0x5c1c, 0x75}, - {0x5c1d, 0x75}, - {0x5c1e, 0x75}, - {0x5c1f, 0x75}, - {0x5c20, 0x75}, - {0x5c21, 0x75}, - {0x5c22, 0x75}, - {0x5c23, 0x75}, - {0x5c24, 0x75}, - {0x5c25, 0x75}, - {0x5c26, 0x75}, - {0x5c27, 0x75}, - {0x5c28, 0x75}, - {0x5c29, 0x75}, - {0x5c2a, 0x75}, - {0x5c2b, 0x75}, - {0x5c2c, 0x75}, - {0x5c2d, 0x75}, - {0x5c2e, 0x75}, - {0x5c2f, 0x75}, - {0x5c30, 0x75}, - {0x5c31, 0x75}, - {0x5c32, 0x75}, - {0x5c33, 0x75}, - {0x5c34, 0x75}, - {0x5c35, 0x75}, - {0x5c36, 0x75}, - {0x5c37, 0x75}, - {0x5c38, 0x75}, - {0x5c39, 0x75}, - {0x5c3a, 0x75}, - {0x5c3b, 0x75}, - {0x5c3c, 0x75}, - {0x5c3d, 0x75}, - {0x5c3e, 0x75}, - {0x5c3f, 0x75}, - {0x5c40, 0x75}, - {0x5c41, 0x75}, - {0x5c42, 0x75}, - {0x5c43, 0x75}, - {0x5c44, 0x75}, - {0x5c45, 0x75}, - {0x5c46, 0x75}, - {0x5c47, 0x75}, - {0x5c48, 0x75}, - {0x5c49, 0x75}, - {0x5c4a, 0x75}, - {0x5c4b, 0x75}, - {0x5c4c, 0x75}, - {0x5c4d, 0x75}, - {0x5c4e, 0x75}, - {0x5c4f, 0x75}, - {0x5c50, 0x75}, - {0x5c51, 0x75}, - {0x5c52, 0x75}, - {0x5c53, 0x75}, - {0x5c54, 0x75}, - {0x5c55, 0x75}, - {0x5c56, 0x75}, - {0x5c57, 0x75}, - {0x5c58, 0x75}, - {0x5c59, 0x75}, - {0x5c5a, 0x75}, - {0x5c5b, 0x75}, - {0x5c5c, 0x75}, - {0x5c5d, 0x75}, - {0x5c5e, 0x75}, - {0x5c5f, 0x75}, - {0x5c60, 0x75}, - {0x5c61, 0x75}, - {0x5c62, 0x75}, - {0x5c63, 0x75}, - {0x5c64, 0x75}, - {0x5c65, 0x75}, - {0x5c66, 0x75}, - {0x5c67, 0x75}, - {0x5c68, 0x75}, - {0x5c69, 0x75}, - {0x5c6a, 0x75}, - {0x5c6b, 0x75}, - {0x5c6c, 0x75}, - {0x5c6d, 0x75}, - {0x5c6e, 0x75}, - {0x5c6f, 0x75}, - {0x5c70, 0x75}, - {0x5c71, 0x75}, - {0x5c72, 0x75}, - {0x5c73, 0x75}, - {0x5c74, 0x75}, - {0x5c75, 0x75}, - {0x5c76, 0x75}, - {0x5c77, 0x75}, - {0x5c78, 0x75}, - {0x5c79, 0x75}, - {0x5c7a, 0x75}, - {0x5c7b, 0x75}, - {0x5c7c, 0x75}, - {0x5c7d, 0x75}, - {0x5c7e, 0x75}, - {0x5c7f, 0x75}, - {0x5c80, 0x75}, - {0x5c81, 0x75}, - {0x5c82, 0x75}, - {0x5c83, 0x75}, - {0x5c84, 0x75}, - {0x5c85, 0x75}, - {0x5c86, 0x75}, - {0x5c87, 0x75}, - {0x5c88, 0x75}, - {0x5c89, 0x75}, - {0x5c8a, 0x75}, - {0x5c8b, 0x75}, - {0x5c8c, 0x75}, - {0x5c8d, 0x75}, - {0x5c8e, 0x75}, - {0x5c8f, 0x75}, - {0x5c90, 0x75}, - {0x5c91, 0x75}, - {0x5c92, 0x75}, - {0x5c93, 0x75}, - {0x5c94, 0x75}, - {0x5c95, 0x75}, - {0x5c96, 0x75}, - {0x5c97, 0x75}, - {0x5c98, 0x75}, - {0x5c99, 0x75}, - {0x5c9a, 0x75}, - {0x5c9b, 0x75}, - {0x5c9c, 0x75}, - {0x5c9d, 0x75}, - {0x5c9e, 0x75}, - {0x5c9f, 0x75}, - {0x5ca0, 0x75}, - {0x5ca1, 0x75}, - {0x5ca2, 0x75}, - {0x5ca3, 0x75}, - {0x5ca4, 0x75}, - {0x5ca5, 0x75}, - {0x5ca6, 0x75}, - {0x5ca7, 0x75}, - {0x5ca8, 0x75}, - {0x5ca9, 0x75}, - {0x5caa, 0x75}, - {0x5cab, 0x75}, - {0x5cac, 0x75}, - {0x5cad, 0x75}, - {0x5cae, 0x75}, - {0x5caf, 0x75}, - {0x5cb0, 0x75}, - {0x5cb1, 0x75}, - {0x5cb2, 0x75}, - {0x5cb3, 0x75}, - {0x5cb4, 0x75}, - {0x5cb5, 0x75}, - {0x5cb6, 0x75}, - {0x5cb7, 0x75}, - {0x5cb8, 0x75}, - {0x5cb9, 0x75}, - {0x5cba, 0x75}, - {0x5cbb, 0x75}, - {0x5cbc, 0x75}, - {0x5cbd, 0x75}, - {0x5cbe, 0x75}, - {0x5cbf, 0x75}, - {0x5cc0, 0x75}, - {0x5cc1, 0x75}, - {0x5cc2, 0x75}, - {0x5cc3, 0x75}, - {0x5cc4, 0x75}, - {0x5cc5, 0x75}, - {0x5cc6, 0x75}, - {0x5cc7, 0x75}, - {0x5cc8, 0x75}, - {0x5cc9, 0x75}, - {0x5cca, 0x75}, - {0x5ccb, 0x75}, - {0x5ccc, 0x75}, - {0x5ccd, 0x75}, - {0x5cce, 0x75}, - {0x5ccf, 0x75}, - {0x5cd0, 0x75}, - {0x5cd1, 0x75}, - {0x5cd2, 0x75}, - {0x5cd3, 0x75}, - {0x5cd4, 0x75}, - {0x5cd5, 0x75}, - {0x5cd6, 0x75}, - {0x5cd7, 0x75}, - {0x5cd8, 0x75}, - {0x5cd9, 0x75}, - {0x5cda, 0x75}, - {0x5cdb, 0x75}, - {0x5cdc, 0x75}, - {0x5cdd, 0x75}, - {0x5cde, 0x75}, - {0x5cdf, 0x75}, - {0x5ce0, 0x75}, - {0x5ce1, 0x75}, - {0x5ce2, 0x75}, - {0x5ce3, 0x75}, - {0x5ce4, 0x75}, - {0x5ce5, 0x75}, - {0x5ce6, 0x75}, - {0x5ce7, 0x75}, - {0x5ce8, 0x75}, - {0x5ce9, 0x75}, - {0x5cea, 0x75}, - {0x5ceb, 0x75}, - {0x5cec, 0x75}, - {0x5ced, 0x75}, - {0x5cee, 0x75}, - {0x5cef, 0x75}, - {0x5cf0, 0x75}, - {0x5cf1, 0x75}, - {0x5cf2, 0x75}, - {0x5cf3, 0x75}, - {0x5cf4, 0x75}, - {0x5cf5, 0x75}, - {0x5cf6, 0x75}, - {0x5cf7, 0x75}, - {0x5cf8, 0x75}, - {0x5cf9, 0x75}, - {0x5cfa, 0x75}, - {0x5cfb, 0x75}, - {0x5cfc, 0x75}, - {0x5cfd, 0x75}, - {0x5cfe, 0x75}, - {0x5cff, 0x75}, - {0x5d00, 0x75}, - {0x5d01, 0x75}, - {0x5d02, 0x75}, - {0x5d03, 0x75}, - {0x5d04, 0x75}, - {0x5d05, 0x75}, - {0x5d06, 0x75}, - {0x5d07, 0x75}, - {0x5d08, 0x75}, - {0x5d09, 0x75}, - {0x5d0a, 0x75}, - {0x5d0b, 0x75}, - {0x5d0c, 0x75}, - {0x5d0d, 0x75}, - {0x5d0e, 0x75}, - {0x5d0f, 0x75}, - {0x5d10, 0x75}, - {0x5d11, 0x75}, - {0x5d12, 0x75}, - {0x5d13, 0x75}, - {0x5d14, 0x75}, - {0x5d15, 0x75}, - {0x5d16, 0x75}, - {0x5d17, 0x75}, - {0x5d18, 0x75}, - {0x5d19, 0x75}, - {0x5d1a, 0x75}, - {0x5d1b, 0x75}, - {0x5d1c, 0x75}, - {0x5d1d, 0x75}, - {0x5d1e, 0x75}, - {0x5d1f, 0x75}, - {0x5d20, 0x75}, - {0x5d21, 0x75}, - {0x5d22, 0x75}, - {0x5d23, 0x75}, - {0x5d24, 0x75}, - {0x5d25, 0x75}, - {0x5d26, 0x75}, - {0x5d27, 0x75}, - {0x5d28, 0x75}, - {0x5d29, 0x75}, - {0x5d2a, 0x75}, - {0x5d2b, 0x75}, - {0x5d2c, 0x75}, - {0x5d2d, 0x75}, - {0x5d2e, 0x75}, - {0x5d2f, 0x75}, - {0x5d30, 0x75}, - {0x5d31, 0x75}, - {0x5d32, 0x75}, - {0x5d33, 0x75}, - {0x5d34, 0x75}, - {0x5d35, 0x75}, - {0x5d36, 0x75}, - {0x5d37, 0x75}, - {0x5d38, 0x75}, - {0x5d39, 0x75}, - {0x5d3a, 0x75}, - {0x5d3b, 0x75}, - {0x5d3c, 0x75}, - {0x5d3d, 0x75}, - {0x5d3e, 0x75}, - {0x5d3f, 0x75}, - {0x5d40, 0x75}, - {0x5d41, 0x75}, - {0x5d42, 0x75}, - {0x5d43, 0x75}, - {0x5d44, 0x75}, - {0x5d45, 0x75}, - {0x5d46, 0x75}, - {0x5d47, 0x75}, - {0x5d48, 0x75}, - {0x5d49, 0x75}, - {0x5d4a, 0x75}, - {0x5d4b, 0x75}, - {0x5d4c, 0x75}, - {0x5d4d, 0x75}, - {0x5d4e, 0x75}, - {0x5d4f, 0x75}, - {0x5d50, 0x75}, - {0x5d51, 0x75}, - {0x5d52, 0x75}, - {0x5d53, 0x75}, - {0x5d54, 0x75}, - {0x5d55, 0x75}, - {0x5d56, 0x75}, - {0x5d57, 0x75}, - {0x5d58, 0x75}, - {0x5d59, 0x75}, - {0x5d5a, 0x75}, - {0x5d5b, 0x75}, - {0x5d5c, 0x75}, - {0x5d5d, 0x75}, - {0x5d5e, 0x75}, - {0x5d5f, 0x75}, - {0x5d60, 0x75}, - {0x5d61, 0x75}, - {0x5d62, 0x75}, - {0x5d63, 0x75}, - {0x5d64, 0x75}, - {0x5d65, 0x75}, - {0x5d66, 0x75}, - {0x5d67, 0x75}, - {0x5d68, 0x75}, - {0x5d69, 0x75}, - {0x5d6a, 0x75}, - {0x5d6b, 0x75}, - {0x5d6c, 0x75}, - {0x5d6d, 0x75}, - {0x5d6e, 0x75}, - {0x5d6f, 0x75}, - {0x5d70, 0x75}, - {0x5d71, 0x75}, - {0x5d72, 0x75}, - {0x5d73, 0x75}, - {0x5d74, 0x75}, - {0x5d75, 0x75}, - {0x5d76, 0x75}, - {0x5d77, 0x75}, - {0x5d78, 0x75}, - {0x5d79, 0x75}, - {0x5d7a, 0x75}, - {0x5d7b, 0x75}, - {0x5d7c, 0x75}, - {0x5d7d, 0x75}, - {0x5d7e, 0x75}, - {0x5d7f, 0x75}, - {0x5d80, 0x75}, - {0x5d81, 0x75}, - {0x5d82, 0x75}, - {0x5d83, 0x75}, - {0x5d84, 0x75}, - {0x5d85, 0x75}, - {0x5d86, 0x75}, - {0x5d87, 0x75}, - {0x5d88, 0x75}, - {0x5d89, 0x75}, - {0x5d8a, 0x75}, - {0x5d8b, 0x75}, - {0x5d8c, 0x75}, - {0x5d8d, 0x75}, - {0x5d8e, 0x75}, - {0x5d8f, 0x75}, - {0x5d90, 0x75}, - {0x5d91, 0x75}, - {0x5d92, 0x75}, - {0x5d93, 0x75}, - {0x5d94, 0x75}, - {0x5d95, 0x75}, - {0x5d96, 0x75}, - {0x5d97, 0x75}, - {0x5d98, 0x75}, - {0x5d99, 0x75}, - {0x5d9a, 0x75}, - {0x5d9b, 0x75}, - {0x5d9c, 0x75}, - {0x5d9d, 0x75}, - {0x5d9e, 0x75}, - {0x5d9f, 0x75}, - {0x5da0, 0x75}, - {0x5da1, 0x75}, - {0x5da2, 0x75}, - {0x5da3, 0x75}, - {0x5da4, 0x75}, - {0x5da5, 0x75}, - {0x5da6, 0x75}, - {0x5da7, 0x75}, - {0x5da8, 0x75}, - {0x5da9, 0x75}, - {0x5daa, 0x75}, - {0x5dab, 0x75}, - {0x5dac, 0x75}, - {0x5dad, 0x75}, - {0x5dae, 0x75}, - {0x5daf, 0x75}, - {0x5db0, 0x75}, - {0x5db1, 0x75}, - {0x5db2, 0x75}, - {0x5db3, 0x75}, - {0x5db4, 0x75}, - {0x5db5, 0x75}, - {0x5db6, 0x75}, - {0x5db7, 0x75}, - {0x5db8, 0x75}, - {0x5db9, 0x75}, - {0x5dba, 0x75}, - {0x5dbb, 0x75}, - {0x5dbc, 0x75}, - {0x5dbd, 0x75}, - {0x5dbe, 0x75}, - {0x5dbf, 0x75}, - {0x5dc0, 0x75}, - {0x5dc1, 0x75}, - {0x5dc2, 0x75}, - {0x5dc3, 0x75}, - {0x5dc4, 0x75}, - {0x5dc5, 0x75}, - {0x5dc6, 0x75}, - {0x5dc7, 0x75}, - {0x5dc8, 0x75}, - {0x5dc9, 0x75}, - {0x5dca, 0x75}, - {0x5dcb, 0x75}, - {0x5dcc, 0x75}, - {0x5dcd, 0x75}, - {0x5dce, 0x75}, - {0x5dcf, 0x75}, - {0x5dd0, 0x75}, - {0x5dd1, 0x75}, - {0x5dd2, 0x75}, - {0x5dd3, 0x75}, - {0x5dd4, 0x75}, - {0x5dd5, 0x75}, - {0x5dd6, 0x75}, - {0x5dd7, 0x75}, - {0x5dd8, 0x75}, - {0x5dd9, 0x75}, - {0x5dda, 0x75}, - {0x5ddb, 0x75}, - {0x5ddc, 0x75}, - {0x5ddd, 0x75}, - {0x5dde, 0x75}, - {0x5ddf, 0x75}, - {0x5de0, 0x75}, - {0x5de1, 0x75}, - {0x5de2, 0x75}, - {0x5de3, 0x75}, - {0x5de4, 0x75}, - {0x5de5, 0x75}, - {0x5de6, 0x75}, - {0x5de7, 0x75}, - {0x5de8, 0x75}, - {0x5de9, 0x75}, - {0x5dea, 0x75}, - {0x5deb, 0x75}, - {0x5dec, 0x75}, - {0x5ded, 0x75}, - {0x5dee, 0x75}, - {0x5def, 0x75}, - {0x5df0, 0x75}, - {0x5df1, 0x75}, - {0x5df2, 0x75}, - {0x5df3, 0x75}, - {0x5df4, 0x75}, - {0x5df5, 0x75}, - {0x5df6, 0x75}, - {0x5df7, 0x75}, - {0x5df8, 0x75}, - {0x5df9, 0x75}, - {0x5dfa, 0x75}, - {0x5dfb, 0x75}, - {0x5dfc, 0x75}, - {0x5dfd, 0x75}, - {0x5dfe, 0x75}, - {0x5dff, 0x75}, - {0x5e00, 0x75}, - {0x5e01, 0x75}, - {0x5e02, 0x75}, - {0x5e03, 0x75}, - {0x5e04, 0x75}, - {0x5e05, 0x75}, - {0x5e06, 0x75}, - {0x5e07, 0x75}, - {0x5e08, 0x75}, - {0x5e09, 0x75}, - {0x5e0a, 0x75}, - {0x5e0b, 0x75}, - {0x5e0c, 0x75}, - {0x5e0d, 0x75}, - {0x5e0e, 0x75}, - {0x5e0f, 0x75}, - {0x5e10, 0x75}, - {0x5e11, 0x75}, - {0x5e12, 0x75}, - {0x5e13, 0x75}, - {0x5e14, 0x75}, - {0x5e15, 0x75}, - {0x5e16, 0x75}, - {0x5e17, 0x75}, - {0x5e18, 0x75}, - {0x5e19, 0x75}, - {0x5e1a, 0x75}, - {0x5e1b, 0x75}, - {0x5e1c, 0x75}, - {0x5e1d, 0x75}, - {0x5e1e, 0x75}, - {0x5e1f, 0x75}, - {0x5e20, 0x75}, - {0x5e21, 0x75}, - {0x5e22, 0x75}, - {0x5e23, 0x75}, - {0x5e24, 0x75}, - {0x5e25, 0x75}, - {0x5e26, 0x75}, - {0x5e27, 0x75}, - {0x5e28, 0x75}, - {0x5e29, 0x75}, - {0x5e2a, 0x75}, - {0x5e2b, 0x75}, - {0x5e2c, 0x75}, - {0x5e2d, 0x75}, - {0x5e2e, 0x75}, - {0x5e2f, 0x75}, - {0x5e30, 0x75}, - {0x5e31, 0x75}, - {0x5e32, 0x75}, - {0x5e33, 0x75}, - {0x5e34, 0x75}, - {0x5e35, 0x75}, - {0x5e36, 0x75}, - {0x5e37, 0x75}, - {0x5e38, 0x75}, - {0x5e39, 0x75}, - {0x5e3a, 0x75}, - {0x5e3b, 0x75}, - {0x5e3c, 0x75}, - {0x5e3d, 0x75}, - {0x5e3e, 0x75}, - {0x5e3f, 0x75}, - {0x5e40, 0x75}, - {0x5e41, 0x75}, - {0x5e42, 0x75}, - {0x5e43, 0x75}, - {0x5e44, 0x75}, - {0x5e45, 0x75}, - {0x5e46, 0x75}, - {0x5e47, 0x75}, - {0x5e48, 0x75}, - {0x5e49, 0x75}, - {0x5e4a, 0x75}, - {0x5e4b, 0x75}, - {0x5e4c, 0x75}, - {0x5e4d, 0x75}, - {0x5e4e, 0x75}, - {0x5e4f, 0x75}, - {0x5e50, 0x75}, - {0x5e51, 0x75}, - {0x5e52, 0x75}, - {0x5e53, 0x75}, - {0x5e54, 0x75}, - {0x5e55, 0x75}, - {0x5e56, 0x75}, - {0x5e57, 0x75}, - {0x5e58, 0x75}, - {0x5e59, 0x75}, - {0x5e5a, 0x75}, - {0x5e5b, 0x75}, - {0x5e5c, 0x75}, - {0x5e5d, 0x75}, - {0x5e5e, 0x75}, - {0x5e5f, 0x75}, - {0x5e60, 0x75}, - {0x5e61, 0x75}, - {0x5e62, 0x75}, - {0x5e63, 0x75}, - {0x5e64, 0x75}, - {0x5e65, 0x75}, - {0x5e66, 0x75}, - {0x5e67, 0x75}, - {0x5e68, 0x75}, - {0x5e69, 0x75}, - {0x5e6a, 0x75}, - {0x5e6b, 0x75}, - {0x5e6c, 0x75}, - {0x5e6d, 0x75}, - {0x5e6e, 0x75}, - {0x5e6f, 0x75}, - {0x5e70, 0x75}, - {0x5e71, 0x75}, - {0x5e72, 0x75}, - {0x5e73, 0x75}, - {0x5e74, 0x75}, - {0x5e75, 0x75}, - {0x5e76, 0x75}, - {0x5e77, 0x75}, - {0x5e78, 0x75}, - {0x5e79, 0x75}, - {0x5e7a, 0x75}, - {0x5e7b, 0x75}, - {0x5e7c, 0x75}, - {0x5e7d, 0x75}, - {0x5e7e, 0x75}, - {0x5e7f, 0x75}, - {0x5e80, 0x75}, - {0x5e81, 0x75}, - {0x5e82, 0x75}, - {0x5e83, 0x75}, - {0x5e84, 0x75}, - {0x5e85, 0x75}, - {0x5e86, 0x75}, - {0x5e87, 0x75}, - {0x5e88, 0x75}, - {0x5e89, 0x75}, - {0x5e8a, 0x75}, - {0x5e8b, 0x75}, - {0x5e8c, 0x75}, - {0x5e8d, 0x75}, - {0x5e8e, 0x75}, - {0x5e8f, 0x75}, - {0x5e90, 0x75}, - {0x5e91, 0x75}, - {0x5e92, 0x75}, - {0x5e93, 0x75}, - {0x5e94, 0x75}, - {0x5e95, 0x75}, - {0x5e96, 0x75}, - {0x5e97, 0x75}, - {0x5e98, 0x75}, - {0x5e99, 0x75}, - {0x5e9a, 0x75}, - {0x5e9b, 0x75}, - {0x5e9c, 0x75}, - {0x5e9d, 0x75}, - {0x5e9e, 0x75}, - {0x5e9f, 0x75}, - {0x5ea0, 0x75}, - {0x5ea1, 0x75}, - {0x5ea2, 0x75}, - {0x5ea3, 0x75}, - {0x5ea4, 0x75}, - {0x5ea5, 0x75}, - {0x5ea6, 0x75}, - {0x5ea7, 0x75}, - {0x5ea8, 0x75}, - {0x5ea9, 0x75}, - {0x5eaa, 0x75}, - {0x5eab, 0x75}, - {0x5eac, 0x75}, - {0x5ead, 0x75}, - {0x5eae, 0x75}, - {0x5eaf, 0x75}, - {0x5eb0, 0x75}, - {0x5eb1, 0x75}, - {0x5eb2, 0x75}, - {0x5eb3, 0x75}, - {0x5eb4, 0x75}, - {0x5eb5, 0x75}, - {0x5eb6, 0x75}, - {0x5eb7, 0x75}, - {0x5eb8, 0x75}, - {0x5eb9, 0x75}, - {0x5eba, 0x75}, - {0x5ebb, 0x75}, - {0x5ebc, 0x75}, - {0x5ebd, 0x75}, - {0x5ebe, 0x75}, - {0x5ebf, 0x75}, - {0x5ec0, 0x75}, - {0x5ec1, 0x75}, - {0x5ec2, 0x75}, - {0x5ec3, 0x75}, - {0x5ec4, 0x75}, - {0x5ec5, 0x75}, - {0x5ec6, 0x75}, - {0x5ec7, 0x75}, - {0x5ec8, 0x75}, - {0x5ec9, 0x75}, - {0x5eca, 0x75}, - {0x5ecb, 0x75}, - {0x5ecc, 0x75}, - {0x5ecd, 0x75}, - {0x5ece, 0x75}, - {0x5ecf, 0x75}, - {0x5ed0, 0x75}, - {0x5ed1, 0x75}, - {0x5ed2, 0x75}, - {0x5ed3, 0x75}, - {0x5ed4, 0x75}, - {0x5ed5, 0x75}, - {0x5ed6, 0x75}, - {0x5ed7, 0x75}, - {0x5ed8, 0x75}, - {0x5ed9, 0x75}, - {0x5eda, 0x75}, - {0x5edb, 0x75}, - {0x5edc, 0x75}, - {0x5edd, 0x75}, - {0x5ede, 0x75}, - {0x5edf, 0x75}, - {0x5ee0, 0x75}, - {0x5ee1, 0x75}, - {0x5ee2, 0x75}, - {0x5ee3, 0x75}, - {0x5ee4, 0x75}, - {0x5ee5, 0x75}, - {0x5ee6, 0x75}, - {0x5ee7, 0x75}, - {0x5ee8, 0x75}, - {0x5ee9, 0x75}, - {0x5eea, 0x75}, - {0x5eeb, 0x75}, - {0x5eec, 0x75}, - {0x5eed, 0x75}, - {0x5eee, 0x75}, - {0x5eef, 0x75}, - {0x5ef0, 0x75}, - {0x5ef1, 0x75}, - {0x5ef2, 0x75}, - {0x5ef3, 0x75}, - {0x5ef4, 0x75}, - {0x5ef5, 0x75}, - {0x5ef6, 0x75}, - {0x5ef7, 0x75}, - {0x5ef8, 0x75}, - {0x5ef9, 0x75}, - {0x5efa, 0x75}, - {0x5efb, 0x75}, - {0x5efc, 0x75}, - {0x5efd, 0x75}, - {0x5efe, 0x75}, - {0x5eff, 0x75}, - {0x5f00, 0x75}, - {0x5f01, 0x75}, - {0x5f02, 0x75}, - {0x5f03, 0x75}, - {0x5f04, 0x75}, - {0x5f05, 0x75}, - {0x5f06, 0x75}, - {0x5f07, 0x75}, - {0x5f08, 0x75}, - {0x5f09, 0x75}, - {0x5f0a, 0x75}, - {0x5f0b, 0x75}, - {0x5f0c, 0x75}, - {0x5f0d, 0x75}, - {0x5f0e, 0x75}, - {0x5f0f, 0x75}, - {0x5f10, 0x75}, - {0x5f11, 0x75}, - {0x5f12, 0x75}, - {0x5f13, 0x75}, - {0x5f14, 0x75}, - {0x5f15, 0x75}, - {0x5f16, 0x75}, - {0x5f17, 0x75}, - {0x5f18, 0x75}, - {0x5f19, 0x75}, - {0x5f1a, 0x75}, - {0x5f1b, 0x75}, - {0x5f1c, 0x75}, - {0x5f1d, 0x75}, - {0x5f1e, 0x75}, - {0x5f1f, 0x75}, }; static const struct ov08x40_reg mode_1928x1208_regs[] = { @@ -2484,6 +1339,40 @@ static int ov08x40_read_reg(struct ov08x40 *ov08x, return 0; } +static int ov08x40_burst_fill_regs(struct ov08x40 *ov08x, u16 first_reg, + u16 last_reg, u8 val) +{ + struct i2c_client *client = v4l2_get_subdevdata(&ov08x->sd); + struct i2c_msg msgs; + size_t i, num_regs; + int ret; + + num_regs = last_reg - first_reg + 1; + msgs.addr = client->addr; + msgs.flags = 0; + msgs.len = 2 + num_regs; + msgs.buf = kmalloc(msgs.len, GFP_KERNEL); + + if (!msgs.buf) + return -ENOMEM; + + put_unaligned_be16(first_reg, msgs.buf); + + for (i = 0; i < num_regs; ++i) + msgs.buf[2 + i] = val; + + ret = i2c_transfer(client->adapter, &msgs, 1); + + kfree(msgs.buf); + + if (ret != 1) { + dev_err(&client->dev, "Failed regs transferred: %d\n", ret); + return -EIO; + } + + return 0; +} + /* Write registers up to 4 at a time */ static int ov08x40_write_reg(struct ov08x40 *ov08x, u16 reg, u32 len, u32 __val) @@ -2924,6 +1813,22 @@ static int ov08x40_start_streaming(struct ov08x40 *ov08x) return ret; } + /* Use i2c burst to write register on full size registers */ + if (ov08x->cur_mode->exposure_shift == 1) { + ret = ov08x40_burst_fill_regs(ov08x, OV08X40_REG_XTALK_FIRST_A, + OV08X40_REG_XTALK_LAST_A, 0x75); + if (ret == 0) + ret = ov08x40_burst_fill_regs(ov08x, + OV08X40_REG_XTALK_FIRST_B, + OV08X40_REG_XTALK_LAST_B, + 0x75); + } + + if (ret) { + dev_err(&client->dev, "%s failed to set regs\n", __func__); + return ret; + } + /* Apply customized values from user */ ret = __v4l2_ctrl_handler_setup(ov08x->sd.ctrl_handler); if (ret) -- cgit v1.2.3 From cf4f0f1e1c465da7c1f6bc89c3ff50bf42f0ab02 Mon Sep 17 00:00:00 2001 From: Jiri Pirko Date: Tue, 30 Jan 2024 13:08:29 +0100 Subject: dpll: extend uapi by lock status error attribute If the dpll devices goes to state "unlocked" or "holdover", it may be caused by an error. In that case, allow user to see what the error was. Introduce a new attribute and values it can carry. Signed-off-by: Jiri Pirko Acked-by: Vadim Fedorenko Reviewed-by: Simon Horman Signed-off-by: Paolo Abeni --- Documentation/netlink/specs/dpll.yaml | 39 +++++++++++++++++++++++++++++++++++ include/uapi/linux/dpll.h | 30 +++++++++++++++++++++++++++ 2 files changed, 69 insertions(+) (limited to 'Documentation') diff --git a/Documentation/netlink/specs/dpll.yaml b/Documentation/netlink/specs/dpll.yaml index b14aed18065f..1755066d8308 100644 --- a/Documentation/netlink/specs/dpll.yaml +++ b/Documentation/netlink/specs/dpll.yaml @@ -51,6 +51,40 @@ definitions: if dpll lock-state was not DPLL_LOCK_STATUS_LOCKED_HO_ACQ, the dpll's lock-state shall remain DPLL_LOCK_STATUS_UNLOCKED) render-max: true + - + type: enum + name: lock-status-error + doc: | + if previous status change was done due to a failure, this provides + information of dpll device lock status error. + Valid values for DPLL_A_LOCK_STATUS_ERROR attribute + entries: + - + name: none + doc: | + dpll device lock status was changed without any error + value: 1 + - + name: undefined + doc: | + dpll device lock status was changed due to undefined error. + Driver fills this value up in case it is not able + to obtain suitable exact error type. + - + name: media-down + doc: | + dpll device lock status was changed because of associated + media got down. + This may happen for example if dpll device was previously + locked on an input pin of type PIN_TYPE_SYNCE_ETH_PORT. + - + name: fractional-frequency-offset-too-high + doc: | + the FFO (Fractional Frequency Offset) between the RX and TX + symbol rate on the media got too high. + This may happen for example if dpll device was previously + locked on an input pin of type PIN_TYPE_SYNCE_ETH_PORT. + render-max: true - type: const name: temp-divider @@ -214,6 +248,10 @@ attribute-sets: name: type type: u32 enum: type + - + name: lock-status-error + type: u32 + enum: lock-status-error - name: pin enum-name: dpll_a_pin @@ -379,6 +417,7 @@ operations: - mode - mode-supported - lock-status + - lock-status-error - temp - clock-id - type diff --git a/include/uapi/linux/dpll.h b/include/uapi/linux/dpll.h index b4e947f9bfbc..0c13d7f1a1bc 100644 --- a/include/uapi/linux/dpll.h +++ b/include/uapi/linux/dpll.h @@ -50,6 +50,35 @@ enum dpll_lock_status { DPLL_LOCK_STATUS_MAX = (__DPLL_LOCK_STATUS_MAX - 1) }; +/** + * enum dpll_lock_status_error - if previous status change was done due to a + * failure, this provides information of dpll device lock status error. Valid + * values for DPLL_A_LOCK_STATUS_ERROR attribute + * @DPLL_LOCK_STATUS_ERROR_NONE: dpll device lock status was changed without + * any error + * @DPLL_LOCK_STATUS_ERROR_UNDEFINED: dpll device lock status was changed due + * to undefined error. Driver fills this value up in case it is not able to + * obtain suitable exact error type. + * @DPLL_LOCK_STATUS_ERROR_MEDIA_DOWN: dpll device lock status was changed + * because of associated media got down. This may happen for example if dpll + * device was previously locked on an input pin of type + * PIN_TYPE_SYNCE_ETH_PORT. + * @DPLL_LOCK_STATUS_ERROR_FRACTIONAL_FREQUENCY_OFFSET_TOO_HIGH: the FFO + * (Fractional Frequency Offset) between the RX and TX symbol rate on the + * media got too high. This may happen for example if dpll device was + * previously locked on an input pin of type PIN_TYPE_SYNCE_ETH_PORT. + */ +enum dpll_lock_status_error { + DPLL_LOCK_STATUS_ERROR_NONE = 1, + DPLL_LOCK_STATUS_ERROR_UNDEFINED, + DPLL_LOCK_STATUS_ERROR_MEDIA_DOWN, + DPLL_LOCK_STATUS_ERROR_FRACTIONAL_FREQUENCY_OFFSET_TOO_HIGH, + + /* private: */ + __DPLL_LOCK_STATUS_ERROR_MAX, + DPLL_LOCK_STATUS_ERROR_MAX = (__DPLL_LOCK_STATUS_ERROR_MAX - 1) +}; + #define DPLL_TEMP_DIVIDER 1000 /** @@ -150,6 +179,7 @@ enum dpll_a { DPLL_A_LOCK_STATUS, DPLL_A_TEMP, DPLL_A_TYPE, + DPLL_A_LOCK_STATUS_ERROR, __DPLL_A_MAX, DPLL_A_MAX = (__DPLL_A_MAX - 1) -- cgit v1.2.3 From 64db3e8d7be00462ad95dd81f11cf8e3f0968d70 Mon Sep 17 00:00:00 2001 From: Andrei Simion Date: Thu, 1 Feb 2024 18:15:17 +0200 Subject: regulator: dt-bindings: microchip,mcp16502: convert to YAML Convert devicetree binding mcp16502-regulator.txt to YAML format. Signed-off-by: Andrei Simion Reviewed-by: Krzysztof Kozlowski Link: https://msgid.link/r/20240201161517.492162-1-andrei.simion@microchip.com Signed-off-by: Mark Brown --- .../bindings/regulator/mcp16502-regulator.txt | 144 ----------------- .../bindings/regulator/microchip,mcp16502.yaml | 180 +++++++++++++++++++++ 2 files changed, 180 insertions(+), 144 deletions(-) delete mode 100644 Documentation/devicetree/bindings/regulator/mcp16502-regulator.txt create mode 100644 Documentation/devicetree/bindings/regulator/microchip,mcp16502.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/regulator/mcp16502-regulator.txt b/Documentation/devicetree/bindings/regulator/mcp16502-regulator.txt deleted file mode 100644 index 451cc4e86b01..000000000000 --- a/Documentation/devicetree/bindings/regulator/mcp16502-regulator.txt +++ /dev/null @@ -1,144 +0,0 @@ -MCP16502 PMIC - -Required properties: -- compatible: "microchip,mcp16502" -- reg: I2C slave address -- lpm-gpios: GPIO for LPM pin. Note that this GPIO *must* remain high during - suspend-to-ram, keeping the PMIC into HIBERNATE mode; this - property is optional; -- regulators: A node that houses a sub-node for each regulator within - the device. Each sub-node is identified using the node's - name. The content of each sub-node is defined by the - standard binding for regulators; see regulator.txt. - -Regulators of MCP16502 PMIC: -1) VDD_IO - Buck (1.2 - 3.7 V) -2) VDD_DDR - Buck (0.6 - 1.85 V) -3) VDD_CORE - Buck (0.6 - 1.85 V) -4) VDD_OTHER - BUCK (0.6 - 1.85 V) -5) LDO1 - LDO (1.2 - 3.7 V) -6) LDO2 - LDO (1.2 - 3.7 V) - -Regulator modes: -2 - FPWM: higher precision, higher consumption -4 - AutoPFM: lower precision, lower consumption - -Each regulator is defined using the standard binding for regulators. - -Example: - -mcp16502@5b { - compatible = "microchip,mcp16502"; - reg = <0x5b>; - status = "okay"; - lpm-gpios = <&pioBU 7 GPIO_ACTIVE_HIGH>; - - regulators { - VDD_IO { - regulator-name = "VDD_IO"; - regulator-min-microvolt = <1200000>; - regulator-max-microvolt = <3700000>; - regulator-initial-mode = <2>; - regulator-allowed-modes = <2>, <4>; - regulator-always-on; - - regulator-state-standby { - regulator-on-in-suspend; - regulator-mode = <4>; - }; - - regulator-state-mem { - regulator-off-in-suspend; - regulator-mode = <4>; - }; - }; - - VDD_DDR { - regulator-name = "VDD_DDR"; - regulator-min-microvolt = <600000>; - regulator-max-microvolt = <1850000>; - regulator-initial-mode = <2>; - regulator-allowed-modes = <2>, <4>; - regulator-always-on; - - regulator-state-standby { - regulator-on-in-suspend; - regulator-mode = <4>; - }; - - regulator-state-mem { - regulator-on-in-suspend; - regulator-mode = <4>; - }; - }; - - VDD_CORE { - regulator-name = "VDD_CORE"; - regulator-min-microvolt = <600000>; - regulator-max-microvolt = <1850000>; - regulator-initial-mode = <2>; - regulator-allowed-modes = <2>, <4>; - regulator-always-on; - - regulator-state-standby { - regulator-on-in-suspend; - regulator-mode = <4>; - }; - - regulator-state-mem { - regulator-off-in-suspend; - regulator-mode = <4>; - }; - }; - - VDD_OTHER { - regulator-name = "VDD_OTHER"; - regulator-min-microvolt = <600000>; - regulator-max-microvolt = <1850000>; - regulator-initial-mode = <2>; - regulator-allowed-modes = <2>, <4>; - regulator-always-on; - - regulator-state-standby { - regulator-on-in-suspend; - regulator-mode = <4>; - }; - - regulator-state-mem { - regulator-off-in-suspend; - regulator-mode = <4>; - }; - }; - - LDO1 { - regulator-name = "LDO1"; - regulator-min-microvolt = <1200000>; - regulator-max-microvolt = <3700000>; - regulator-always-on; - - regulator-state-standby { - regulator-on-in-suspend; - }; - - regulator-state-mem { - regulator-off-in-suspend; - }; - }; - - LDO2 { - regulator-name = "LDO2"; - regulator-min-microvolt = <1200000>; - regulator-max-microvolt = <3700000>; - regulator-always-on; - - regulator-state-standby { - regulator-on-in-suspend; - }; - - regulator-state-mem { - regulator-off-in-suspend; - }; - }; - - }; -}; diff --git a/Documentation/devicetree/bindings/regulator/microchip,mcp16502.yaml b/Documentation/devicetree/bindings/regulator/microchip,mcp16502.yaml new file mode 100644 index 000000000000..1aca3646789e --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/microchip,mcp16502.yaml @@ -0,0 +1,180 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/regulator/microchip,mcp16502.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: MCP16502 - High-Performance PMIC + +maintainers: + - Andrei Simion + +description: + The MCP16502 is an optimally integrated PMIC compatible + with Microchip's eMPUs(Embedded Microprocessor Units), + requiring Dynamic Voltage Scaling (DVS) with the use + of High-Performance mode (HPM). + +properties: + compatible: + const: microchip,mcp16502 + + lpm-gpios: + maxItems: 1 + description: GPIO for LPM pin. + Note that this GPIO must remain high during + suspend-to-ram, keeping the PMIC into HIBERNATE mode. + + reg: + maxItems: 1 + + regulators: + type: object + additionalProperties: false + description: List of regulators and its properties. + + patternProperties: + "^(VDD_(IO|CORE|DDR|OTHER)|LDO[1-2])$": + type: object + $ref: regulator.yaml# + unevaluatedProperties: false + + properties: + regulator-initial-mode: + enum: [2, 4] + default: 2 + description: Initial operating mode + + regulator-allowed-modes: + items: + enum: [2, 4] + description: Supported modes + 2 - FPWM higher precision, higher consumption + 4 - AutoPFM lower precision, lower consumption + +required: + - compatible + - reg + - regulators + +additionalProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + pmic@5b { + compatible = "microchip,mcp16502"; + reg = <0x5b>; + + regulators { + VDD_IO { + regulator-name = "VDD_IO"; + regulator-min-microvolt = <3300000>; + regulator-max-microvolt = <3300000>; + regulator-initial-mode = <2>; + regulator-allowed-modes = <2>, <4>; + regulator-always-on; + + regulator-state-standby { + regulator-on-in-suspend; + regulator-mode = <4>; + }; + + regulator-state-mem { + regulator-off-in-suspend; + regulator-mode = <4>; + }; + }; + + VDD_DDR { + regulator-name = "VDD_DDR"; + regulator-min-microvolt = <1350000>; + regulator-max-microvolt = <1350000>; + regulator-initial-mode = <2>; + regulator-allowed-modes = <2>, <4>; + regulator-always-on; + + regulator-state-standby { + regulator-on-in-suspend; + regulator-mode = <4>; + }; + + regulator-state-mem { + regulator-on-in-suspend; + regulator-mode = <4>; + }; + }; + + VDD_CORE { + regulator-name = "VDD_CORE"; + regulator-min-microvolt = <1150000>; + regulator-max-microvolt = <1150000>; + regulator-initial-mode = <2>; + regulator-allowed-modes = <2>, <4>; + regulator-always-on; + + regulator-state-standby { + regulator-on-in-suspend; + regulator-mode = <4>; + }; + + regulator-state-mem { + regulator-off-in-suspend; + regulator-mode = <4>; + }; + }; + + VDD_OTHER { + regulator-name = "VDD_OTHER"; + regulator-min-microvolt = <1050000>; + regulator-max-microvolt = <1250000>; + regulator-initial-mode = <2>; + regulator-allowed-modes = <2>, <4>; + regulator-always-on; + + regulator-state-standby { + regulator-on-in-suspend; + regulator-mode = <4>; + }; + + regulator-state-mem { + regulator-off-in-suspend; + regulator-mode = <4>; + }; + }; + + LDO1 { + regulator-name = "LDO1"; + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <1800000>; + regulator-always-on; + + regulator-state-standby { + regulator-on-in-suspend; + }; + + regulator-state-mem { + regulator-off-in-suspend; + }; + }; + + LDO2 { + regulator-name = "LDO2"; + regulator-min-microvolt = <1200000>; + regulator-max-microvolt = <3700000>; + regulator-always-on; + + regulator-state-standby { + regulator-on-in-suspend; + }; + + regulator-state-mem { + regulator-off-in-suspend; + }; + }; + }; + }; + }; -- cgit v1.2.3 From 641fde51bdb26c09ea8cdbd82084e93bd88d1fcb Mon Sep 17 00:00:00 2001 From: Anjelique Melendez Date: Thu, 1 Feb 2024 12:44:22 -0800 Subject: dt-bindings: soc: qcom: Add qcom,pbs bindings Add binding for the Qualcomm Programmable Boot Sequencer device. Signed-off-by: Anjelique Melendez Reviewed-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20240201204421.16992-4-quic_amelende@quicinc.com Signed-off-by: Bjorn Andersson --- .../devicetree/bindings/soc/qcom/qcom,pbs.yaml | 46 ++++++++++++++++++++++ 1 file changed, 46 insertions(+) create mode 100644 Documentation/devicetree/bindings/soc/qcom/qcom,pbs.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,pbs.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,pbs.yaml new file mode 100644 index 000000000000..b502ca72266a --- /dev/null +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,pbs.yaml @@ -0,0 +1,46 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/soc/qcom/qcom,pbs.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Technologies, Inc. Programmable Boot Sequencer + +maintainers: + - Anjelique Melendez + +description: | + The Qualcomm Technologies, Inc. Programmable Boot Sequencer (PBS) + supports triggering power up and power down sequences for clients + upon request. + +properties: + compatible: + items: + - enum: + - qcom,pmi632-pbs + - const: qcom,pbs + + reg: + maxItems: 1 + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + #include + + pmic@0 { + reg = <0x0 SPMI_USID>; + #address-cells = <1>; + #size-cells = <0>; + + pbs@7400 { + compatible = "qcom,pmi632-pbs", "qcom,pbs"; + reg = <0x7400>; + }; + }; -- cgit v1.2.3 From 9484b9555de04ed16952dda6518b324f61a6fd6a Mon Sep 17 00:00:00 2001 From: Christian Marangi Date: Wed, 31 Jan 2024 03:26:03 +0100 Subject: dt-bindings: net: ipq4019-mdio: document now supported clock-frequency Document support for clock-frequency and add details on why this property is needed and what values are supported. From internal documentation, while other values are supported, the correct function of the MDIO bus is not assured hence add only the suggested supported values to the property enum. Signed-off-by: Christian Marangi Reviewed-by: Andrew Lunn Signed-off-by: David S. Miller --- .../devicetree/bindings/net/qcom,ipq4019-mdio.yaml | 15 +++++++++++++++ 1 file changed, 15 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/qcom,ipq4019-mdio.yaml b/Documentation/devicetree/bindings/net/qcom,ipq4019-mdio.yaml index 3407e909e8a7..0029e197a825 100644 --- a/Documentation/devicetree/bindings/net/qcom,ipq4019-mdio.yaml +++ b/Documentation/devicetree/bindings/net/qcom,ipq4019-mdio.yaml @@ -44,6 +44,21 @@ properties: items: - const: gcc_mdio_ahb_clk + clock-frequency: + description: + The MDIO bus clock that must be output by the MDIO bus hardware, if + absent, the default hardware values are used. + + MDC rate is feed by an external clock (fixed 100MHz) and is divider + internally. The default divider is /256 resulting in the default rate + applied of 390KHz. + + To follow 802.3 standard that instruct up to 2.5MHz by default, if + this property is not declared and the divider is set to /256, by + default 1.5625Mhz is select. + enum: [ 390625, 781250, 1562500, 3125000, 6250000, 12500000 ] + default: 1562500 + required: - compatible - reg -- cgit v1.2.3 From 84f90efd5076525a581e3f923f6c86579f41e713 Mon Sep 17 00:00:00 2001 From: Ravi Gunasekaran Date: Wed, 31 Jan 2024 14:23:51 +0530 Subject: dt-bindings: net: ti: Update maintainers list Update the list with the current maintainers of TI's CPSW ethernet peripheral. Signed-off-by: Ravi Gunasekaran Acked-by: Roger Quadros Signed-off-by: David S. Miller --- Documentation/devicetree/bindings/net/ti,cpsw-switch.yaml | 5 +++-- Documentation/devicetree/bindings/net/ti,k3-am654-cpsw-nuss.yaml | 5 +++-- Documentation/devicetree/bindings/net/ti,k3-am654-cpts.yaml | 5 +++-- 3 files changed, 9 insertions(+), 6 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/ti,cpsw-switch.yaml b/Documentation/devicetree/bindings/net/ti,cpsw-switch.yaml index f07ae3173b03..d5bd93ee4dbb 100644 --- a/Documentation/devicetree/bindings/net/ti,cpsw-switch.yaml +++ b/Documentation/devicetree/bindings/net/ti,cpsw-switch.yaml @@ -7,8 +7,9 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: TI SoC Ethernet Switch Controller (CPSW) maintainers: - - Grygorii Strashko - - Sekhar Nori + - Siddharth Vadapalli + - Ravi Gunasekaran + - Roger Quadros description: The 3-port switch gigabit ethernet subsystem provides ethernet packet diff --git a/Documentation/devicetree/bindings/net/ti,k3-am654-cpsw-nuss.yaml b/Documentation/devicetree/bindings/net/ti,k3-am654-cpsw-nuss.yaml index c9c25132d154..73ed5951d296 100644 --- a/Documentation/devicetree/bindings/net/ti,k3-am654-cpsw-nuss.yaml +++ b/Documentation/devicetree/bindings/net/ti,k3-am654-cpsw-nuss.yaml @@ -7,8 +7,9 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: The TI AM654x/J721E/AM642x SoC Gigabit Ethernet MAC (Media Access Controller) maintainers: - - Grygorii Strashko - - Sekhar Nori + - Siddharth Vadapalli + - Ravi Gunasekaran + - Roger Quadros description: The TI AM654x/J721E SoC Gigabit Ethernet MAC (CPSW2G NUSS) has two ports diff --git a/Documentation/devicetree/bindings/net/ti,k3-am654-cpts.yaml b/Documentation/devicetree/bindings/net/ti,k3-am654-cpts.yaml index 3e910d3b24a0..b1c875325776 100644 --- a/Documentation/devicetree/bindings/net/ti,k3-am654-cpts.yaml +++ b/Documentation/devicetree/bindings/net/ti,k3-am654-cpts.yaml @@ -7,8 +7,9 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: The TI AM654x/J721E Common Platform Time Sync (CPTS) module maintainers: - - Grygorii Strashko - - Sekhar Nori + - Siddharth Vadapalli + - Ravi Gunasekaran + - Roger Quadros description: |+ The TI AM654x/J721E CPTS module is used to facilitate host control of time -- cgit v1.2.3 From ff3d9bfa25fabc4bf014d4e350ded1dc12b0a44a Mon Sep 17 00:00:00 2001 From: Geert Uytterhoeven Date: Thu, 1 Feb 2024 13:16:33 +0100 Subject: dt-bindings: gpio: renesas,rcar-gpio: Add r8a779h0 support Document support for GPIO controller blocks in the Renesas R-Car V4M (R8A779H0) SoC. Signed-off-by: Geert Uytterhoeven Acked-by: Conor Dooley Signed-off-by: Bartosz Golaszewski --- Documentation/devicetree/bindings/gpio/renesas,rcar-gpio.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/gpio/renesas,rcar-gpio.yaml b/Documentation/devicetree/bindings/gpio/renesas,rcar-gpio.yaml index aa424e2b95f8..cc7a950a6030 100644 --- a/Documentation/devicetree/bindings/gpio/renesas,rcar-gpio.yaml +++ b/Documentation/devicetree/bindings/gpio/renesas,rcar-gpio.yaml @@ -53,6 +53,7 @@ properties: - renesas,gpio-r8a779a0 # R-Car V3U - renesas,gpio-r8a779f0 # R-Car S4-8 - renesas,gpio-r8a779g0 # R-Car V4H + - renesas,gpio-r8a779h0 # R-Car V4M - const: renesas,rcar-gen4-gpio # R-Car Gen4 reg: -- cgit v1.2.3 From 3d94e7584486f7ac4a44fe215330ae6a1094e492 Mon Sep 17 00:00:00 2001 From: Jessica Zhang Date: Fri, 2 Feb 2024 10:03:11 -0800 Subject: dt-bindings: visionox-rm69299: Update maintainers The current maintainer (Harigovindan P) is no longer reachable through the listed email. Update maintainers list to be Abhinav and I. Signed-off-by: Jessica Zhang Reviewed-by: Neil Armstrong Link: https://lore.kernel.org/r/20240202-rm69299-maintainers-v1-1-423aa40f344f@quicinc.com Signed-off-by: Neil Armstrong Link: https://patchwork.freedesktop.org/patch/msgid/20240202-rm69299-maintainers-v1-1-423aa40f344f@quicinc.com --- Documentation/devicetree/bindings/display/panel/visionox,rm69299.yaml | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/panel/visionox,rm69299.yaml b/Documentation/devicetree/bindings/display/panel/visionox,rm69299.yaml index fa745a6f4456..772399067515 100644 --- a/Documentation/devicetree/bindings/display/panel/visionox,rm69299.yaml +++ b/Documentation/devicetree/bindings/display/panel/visionox,rm69299.yaml @@ -7,7 +7,8 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Visionox model RM69299 Panels maintainers: - - Harigovindan P + - Abhinav Kumar + - Jessica Zhang description: | This binding is for display panels using a Visionox RM692999 panel. -- cgit v1.2.3 From d22118f005231f543ef45e17342c3eb2a71cbfe3 Mon Sep 17 00:00:00 2001 From: Jeffrey Hugo Date: Fri, 2 Feb 2024 10:19:15 -0700 Subject: dt-bindings: clock: qcom: Fix @codeaurora email in Q6SSTOP The servers for the @codeaurora domain are long retired and any messages addressed there will bounce. Govind Singh has left the company which appears to leave the Q6SSTOP clock controller binding unmaintained. Move maintenance of the binding to the Qualcomm Clock Drivers maintainer as suggested by Bjorn Andersson. Signed-off-by: Jeffrey Hugo Link: https://lore.kernel.org/r/20240202171915.4101842-1-quic_jhugo@quicinc.com Signed-off-by: Bjorn Andersson --- Documentation/devicetree/bindings/clock/qcom,q6sstopcc.yaml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/qcom,q6sstopcc.yaml b/Documentation/devicetree/bindings/clock/qcom,q6sstopcc.yaml index 03fa30fe9253..e0f4d692728c 100644 --- a/Documentation/devicetree/bindings/clock/qcom,q6sstopcc.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,q6sstopcc.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Q6SSTOP clock Controller maintainers: - - Govind Singh + - Bjorn Andersson properties: compatible: -- cgit v1.2.3 From 0e7d29a39a546161ea3a49e8e282a43212d7ff68 Mon Sep 17 00:00:00 2001 From: Johan Hovold Date: Fri, 2 Feb 2024 14:16:34 +0100 Subject: PCI/AER: Fix rootport attribute paths in ABI docs The 'aer_stats' directory never made it into the sixth and final revision of the series adding the sysfs AER attributes. Link: https://lore.kernel.org/r/20240202131635.11405-2-johan+linaro@kernel.org Link: https://lore.kernel.org/lkml/20180621184822.GB14136@bhelgaas-glaptop.roam.corp.google.com/ Fixes: 12833017e581 ("PCI/AER: Add sysfs attributes for rootport cumulative stats") Signed-off-by: Johan Hovold Signed-off-by: Bjorn Helgaas --- Documentation/ABI/testing/sysfs-bus-pci-devices-aer_stats | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-bus-pci-devices-aer_stats b/Documentation/ABI/testing/sysfs-bus-pci-devices-aer_stats index 860db53037a5..24087d5fd417 100644 --- a/Documentation/ABI/testing/sysfs-bus-pci-devices-aer_stats +++ b/Documentation/ABI/testing/sysfs-bus-pci-devices-aer_stats @@ -100,19 +100,19 @@ collectors) that are AER capable. These indicate the number of error messages as device, so these counters include them and are thus cumulative of all the error messages on the PCI hierarchy originating at that root port. -What: /sys/bus/pci/devices//aer_stats/aer_rootport_total_err_cor +What: /sys/bus/pci/devices//aer_rootport_total_err_cor Date: July 2018 KernelVersion: 4.19.0 Contact: linux-pci@vger.kernel.org, rajatja@google.com Description: Total number of ERR_COR messages reported to rootport. -What: /sys/bus/pci/devices//aer_stats/aer_rootport_total_err_fatal +What: /sys/bus/pci/devices//aer_rootport_total_err_fatal Date: July 2018 KernelVersion: 4.19.0 Contact: linux-pci@vger.kernel.org, rajatja@google.com Description: Total number of ERR_FATAL messages reported to rootport. -What: /sys/bus/pci/devices//aer_stats/aer_rootport_total_err_nonfatal +What: /sys/bus/pci/devices//aer_rootport_total_err_nonfatal Date: July 2018 KernelVersion: 4.19.0 Contact: linux-pci@vger.kernel.org, rajatja@google.com -- cgit v1.2.3 From 96ed79791b1b213c892301595459e0ea404540b3 Mon Sep 17 00:00:00 2001 From: Johan Hovold Date: Fri, 2 Feb 2024 14:16:35 +0100 Subject: PCI/AER: Clean up version indentation in ABI docs The 'KernelVersion' lines use a single space as separator instead of a tab so the values are not aligned with the other AER attribute fields. Link: https://lore.kernel.org/r/20240202131635.11405-3-johan+linaro@kernel.org Signed-off-by: Johan Hovold Signed-off-by: Bjorn Helgaas --- Documentation/ABI/testing/sysfs-bus-pci-devices-aer_stats | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-bus-pci-devices-aer_stats b/Documentation/ABI/testing/sysfs-bus-pci-devices-aer_stats index 24087d5fd417..d1f67bb81d5d 100644 --- a/Documentation/ABI/testing/sysfs-bus-pci-devices-aer_stats +++ b/Documentation/ABI/testing/sysfs-bus-pci-devices-aer_stats @@ -11,7 +11,7 @@ saw any problems). What: /sys/bus/pci/devices//aer_dev_correctable Date: July 2018 -KernelVersion: 4.19.0 +KernelVersion: 4.19.0 Contact: linux-pci@vger.kernel.org, rajatja@google.com Description: List of correctable errors seen and reported by this PCI device using ERR_COR. Note that since multiple errors may @@ -32,7 +32,7 @@ Description: List of correctable errors seen and reported by this What: /sys/bus/pci/devices//aer_dev_fatal Date: July 2018 -KernelVersion: 4.19.0 +KernelVersion: 4.19.0 Contact: linux-pci@vger.kernel.org, rajatja@google.com Description: List of uncorrectable fatal errors seen and reported by this PCI device using ERR_FATAL. Note that since multiple errors may @@ -62,7 +62,7 @@ Description: List of uncorrectable fatal errors seen and reported by this What: /sys/bus/pci/devices//aer_dev_nonfatal Date: July 2018 -KernelVersion: 4.19.0 +KernelVersion: 4.19.0 Contact: linux-pci@vger.kernel.org, rajatja@google.com Description: List of uncorrectable nonfatal errors seen and reported by this PCI device using ERR_NONFATAL. Note that since multiple errors @@ -102,18 +102,18 @@ messages on the PCI hierarchy originating at that root port. What: /sys/bus/pci/devices//aer_rootport_total_err_cor Date: July 2018 -KernelVersion: 4.19.0 +KernelVersion: 4.19.0 Contact: linux-pci@vger.kernel.org, rajatja@google.com Description: Total number of ERR_COR messages reported to rootport. What: /sys/bus/pci/devices//aer_rootport_total_err_fatal Date: July 2018 -KernelVersion: 4.19.0 +KernelVersion: 4.19.0 Contact: linux-pci@vger.kernel.org, rajatja@google.com Description: Total number of ERR_FATAL messages reported to rootport. What: /sys/bus/pci/devices//aer_rootport_total_err_nonfatal Date: July 2018 -KernelVersion: 4.19.0 +KernelVersion: 4.19.0 Contact: linux-pci@vger.kernel.org, rajatja@google.com Description: Total number of ERR_NONFATAL messages reported to rootport. -- cgit v1.2.3 From 6a0a5a2a71b3e3c4ae1ee0b34a496cbf2d980832 Mon Sep 17 00:00:00 2001 From: Manuel Traut Date: Sat, 27 Jan 2024 10:48:44 +0100 Subject: dt-bindings: arm64: rockchip: Add Pine64 PineTab2 Add devicvetree binding documentation for Pine64 PineTab2 which uses the Rockchip RK3566 SoC. Signed-off-by: Manuel Traut Acked-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20240127-pinetab2-v4-3-37aab1c39194@mecka.net [moved Pinetab below Pinephone to keep alphabetical sorting] Signed-off-by: Heiko Stuebner --- Documentation/devicetree/bindings/arm/rockchip.yaml | 8 ++++++++ 1 file changed, 8 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/rockchip.yaml b/Documentation/devicetree/bindings/arm/rockchip.yaml index b03c85a05a92..433a25f4e744 100644 --- a/Documentation/devicetree/bindings/arm/rockchip.yaml +++ b/Documentation/devicetree/bindings/arm/rockchip.yaml @@ -649,6 +649,14 @@ properties: - const: pine64,pinephone-pro - const: rockchip,rk3399 + - description: Pine64 PineTab2 + items: + - enum: + - pine64,pinetab2-v0.1 + - pine64,pinetab2-v2.0 + - const: pine64,pinetab2 + - const: rockchip,rk3566 + - description: Pine64 Rock64 items: - const: pine64,rock64 -- cgit v1.2.3 From d4d8fbcef03f590288b44955d8d51e334627b013 Mon Sep 17 00:00:00 2001 From: Dragan Cvetic Date: Wed, 31 Jan 2024 17:06:45 +0000 Subject: dt-bindings: misc: xlnx,sd-fec: convert bindings to yaml Convert AMD (Xilinx) sd-fec bindings to yaml format, so it can validate dt-entries as well as any future additions to yaml. Change in clocks is due to IP is itself configurable and only the first two clocks are in all combinations. The last 6 clocks can be present in some of them. It means order is not really fixed and any combination is possible. Interrupt may or may not be present. The documentation for sd-fec bindings is now YAML, so update the MAINTAINERS file. Update the link to the new yaml file in xilinx_sdfec.rst. Signed-off-by: Dragan Cvetic Link: https://lore.kernel.org/r/20240131170650.530079-1-dragan.cvetic@amd.com Signed-off-by: Rob Herring --- .../devicetree/bindings/misc/xlnx,sd-fec.txt | 58 --------- .../devicetree/bindings/misc/xlnx,sd-fec.yaml | 140 +++++++++++++++++++++ Documentation/misc-devices/xilinx_sdfec.rst | 2 +- MAINTAINERS | 2 +- 4 files changed, 142 insertions(+), 60 deletions(-) delete mode 100644 Documentation/devicetree/bindings/misc/xlnx,sd-fec.txt create mode 100644 Documentation/devicetree/bindings/misc/xlnx,sd-fec.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/misc/xlnx,sd-fec.txt b/Documentation/devicetree/bindings/misc/xlnx,sd-fec.txt deleted file mode 100644 index e3289634fa30..000000000000 --- a/Documentation/devicetree/bindings/misc/xlnx,sd-fec.txt +++ /dev/null @@ -1,58 +0,0 @@ -* Xilinx SDFEC(16nm) IP * - -The Soft Decision Forward Error Correction (SDFEC) Engine is a Hard IP block -which provides high-throughput LDPC and Turbo Code implementations. -The LDPC decode & encode functionality is capable of covering a range of -customer specified Quasi-cyclic (QC) codes. The Turbo decode functionality -principally covers codes used by LTE. The FEC Engine offers significant -power and area savings versus implementations done in the FPGA fabric. - - -Required properties: -- compatible: Must be "xlnx,sd-fec-1.1" -- clock-names : List of input clock names from the following: - - "core_clk", Main processing clock for processing core (required) - - "s_axi_aclk", AXI4-Lite memory-mapped slave interface clock (required) - - "s_axis_din_aclk", DIN AXI4-Stream Slave interface clock (optional) - - "s_axis_din_words-aclk", DIN_WORDS AXI4-Stream Slave interface clock (optional) - - "s_axis_ctrl_aclk", Control input AXI4-Stream Slave interface clock (optional) - - "m_axis_dout_aclk", DOUT AXI4-Stream Master interface clock (optional) - - "m_axis_dout_words_aclk", DOUT_WORDS AXI4-Stream Master interface clock (optional) - - "m_axis_status_aclk", Status output AXI4-Stream Master interface clock (optional) -- clocks : Clock phandles (see clock_bindings.txt for details). -- reg: Should contain Xilinx SDFEC 16nm Hardened IP block registers - location and length. -- xlnx,sdfec-code : Should contain "ldpc" or "turbo" to describe the codes - being used. -- xlnx,sdfec-din-words : A value 0 indicates that the DIN_WORDS interface is - driven with a fixed value and is not present on the device, a value of 1 - configures the DIN_WORDS to be block based, while a value of 2 configures the - DIN_WORDS input to be supplied for each AXI transaction. -- xlnx,sdfec-din-width : Configures the DIN AXI stream where a value of 1 - configures a width of "1x128b", 2 a width of "2x128b" and 4 configures a width - of "4x128b". -- xlnx,sdfec-dout-words : A value 0 indicates that the DOUT_WORDS interface is - driven with a fixed value and is not present on the device, a value of 1 - configures the DOUT_WORDS to be block based, while a value of 2 configures the - DOUT_WORDS input to be supplied for each AXI transaction. -- xlnx,sdfec-dout-width : Configures the DOUT AXI stream where a value of 1 - configures a width of "1x128b", 2 a width of "2x128b" and 4 configures a width - of "4x128b". -Optional properties: -- interrupts: should contain SDFEC interrupt number - -Example ---------------------------------------- - sd_fec_0: sd-fec@a0040000 { - compatible = "xlnx,sd-fec-1.1"; - clock-names = "core_clk","s_axi_aclk","s_axis_ctrl_aclk","s_axis_din_aclk","m_axis_status_aclk","m_axis_dout_aclk"; - clocks = <&misc_clk_2>,<&misc_clk_0>,<&misc_clk_1>,<&misc_clk_1>,<&misc_clk_1>, <&misc_clk_1>; - reg = <0x0 0xa0040000 0x0 0x40000>; - interrupt-parent = <&axi_intc>; - interrupts = <1 0>; - xlnx,sdfec-code = "ldpc"; - xlnx,sdfec-din-words = <0>; - xlnx,sdfec-din-width = <2>; - xlnx,sdfec-dout-words = <0>; - xlnx,sdfec-dout-width = <1>; - }; diff --git a/Documentation/devicetree/bindings/misc/xlnx,sd-fec.yaml b/Documentation/devicetree/bindings/misc/xlnx,sd-fec.yaml new file mode 100644 index 000000000000..9bd210337426 --- /dev/null +++ b/Documentation/devicetree/bindings/misc/xlnx,sd-fec.yaml @@ -0,0 +1,140 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/misc/xlnx,sd-fec.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Xilinx SDFEC(16nm) IP + +maintainers: + - Cvetic, Dragan + - Erim, Salih + +description: + The Soft Decision Forward Error Correction (SDFEC) Engine is a Hard IP block + which provides high-throughput LDPC and Turbo Code implementations. + The LDPC decode & encode functionality is capable of covering a range of + customer specified Quasi-cyclic (QC) codes. The Turbo decode functionality + principally covers codes used by LTE. The FEC Engine offers significant + power and area savings versus implementations done in the FPGA fabric. + +properties: + compatible: + const: xlnx,sd-fec-1.1 + + reg: + maxItems: 1 + + clocks: + minItems: 2 + maxItems: 8 + additionalItems: true + items: + - description: Main processing clock for processing core + - description: AXI4-Lite memory-mapped slave interface clock + - description: Control input AXI4-Stream Slave interface clock + - description: DIN AXI4-Stream Slave interface clock + - description: Status output AXI4-Stream Master interface clock + - description: DOUT AXI4-Stream Master interface clock + - description: DIN_WORDS AXI4-Stream Slave interface clock + - description: DOUT_WORDS AXI4-Stream Master interface clock + + clock-names: + allOf: + - minItems: 2 + maxItems: 8 + additionalItems: true + items: + - const: core_clk + - const: s_axi_aclk + - items: + enum: + - core_clk + - s_axi_aclk + - s_axis_ctrl_aclk + - s_axis_din_aclk + - m_axis_status_aclk + - m_axis_dout_aclk + - s_axis_din_words_aclk + - m_axis_dout_words_aclk + + interrupts: + maxItems: 1 + + xlnx,sdfec-code: + description: + The SD-FEC integrated block supports Low Density Parity Check (LDPC) + decoding and encoding and Turbo code decoding. The LDPC codes used are + highly configurable, and the specific code used can be specified on + a codeword-by-codeword basis. The Turbo code decoding is required by LTE + standard. + $ref: /schemas/types.yaml#/definitions/string + items: + enum: [ ldpc, turbo ] + + xlnx,sdfec-din-width: + description: + Configures the DIN AXI stream where a value of 1 + configures a width of "1x128b", 2 a width of "2x128b" and 4 configures a width + of "4x128b". + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [ 1, 2, 4 ] + + xlnx,sdfec-din-words: + description: + A value 0 indicates that the DIN_WORDS interface is + driven with a fixed value and is not present on the device, a value of 1 + configures the DIN_WORDS to be block based, while a value of 2 configures the + DIN_WORDS input to be supplied for each AXI transaction. + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [ 0, 1, 2 ] + + xlnx,sdfec-dout-width: + description: + Configures the DOUT AXI stream where a value of 1 configures a width of "1x128b", + 2 a width of "2x128b" and 4 configures a width of "4x128b". + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [ 1, 2, 4 ] + + xlnx,sdfec-dout-words: + description: + A value 0 indicates that the DOUT_WORDS interface is + driven with a fixed value and is not present on the device, a value of 1 + configures the DOUT_WORDS to be block based, while a value of 2 configures the + DOUT_WORDS input to be supplied for each AXI transaction. + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [ 0, 1, 2 ] + +required: + - compatible + - reg + - clocks + - clock-names + - xlnx,sdfec-code + - xlnx,sdfec-din-width + - xlnx,sdfec-din-words + - xlnx,sdfec-dout-width + - xlnx,sdfec-dout-words + +additionalProperties: false + +examples: + - | + #include + + sd-fec@a0040000 { + compatible = "xlnx,sd-fec-1.1"; + reg = <0xa0040000 0x40000>; + clocks = <&misc_clk_2>, <&misc_clk_0>, <&misc_clk_1>, <&misc_clk_1>, + <&misc_clk_1>, <&misc_clk_1>; + clock-names = "core_clk", "s_axi_aclk", "s_axis_ctrl_aclk", + "s_axis_din_aclk", "m_axis_status_aclk", + "m_axis_dout_aclk"; + interrupts = <1 IRQ_TYPE_LEVEL_HIGH>; + xlnx,sdfec-code = "ldpc"; + xlnx,sdfec-din-width = <2>; + xlnx,sdfec-din-words = <0>; + xlnx,sdfec-dout-width = <1>; + xlnx,sdfec-dout-words = <0>; + }; + diff --git a/Documentation/misc-devices/xilinx_sdfec.rst b/Documentation/misc-devices/xilinx_sdfec.rst index 8c8a289d69a3..698e6630f3a7 100644 --- a/Documentation/misc-devices/xilinx_sdfec.rst +++ b/Documentation/misc-devices/xilinx_sdfec.rst @@ -29,7 +29,7 @@ follows: - Does not support shared LDPC code table wraparound The device tree entry is described in: -`linux-xlnx/Documentation/devicetree/bindings/misc/xlnx,sd-fec.txt `_ +`linux-xlnx/Documentation/devicetree/bindings/misc/xlnx,sd-fec.yaml `_ Modes of Operation diff --git a/MAINTAINERS b/MAINTAINERS index 42b43337c266..b01f890ec789 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -24154,7 +24154,7 @@ XILINX SD-FEC IP CORES M: Derek Kiernan M: Dragan Cvetic S: Maintained -F: Documentation/devicetree/bindings/misc/xlnx,sd-fec.txt +F: Documentation/devicetree/bindings/misc/xlnx,sd-fec.yaml F: Documentation/misc-devices/xilinx_sdfec.rst F: drivers/misc/Kconfig F: drivers/misc/Makefile -- cgit v1.2.3 From 2ca8377bf20a341edc95e13e2bf45ff03040f0f5 Mon Sep 17 00:00:00 2001 From: Mathieu Othacehe Date: Mon, 8 Jan 2024 12:02:40 +0100 Subject: dt-bindings: arm: fsl: Add VAR-SOM-MX93 with Symphony Add support for Variscite i.MX93 VAR-SOM-MX93 SoM with Symphony board. Reviewed-by: Krzysztof Kozlowski Signed-off-by: Mathieu Othacehe Signed-off-by: Shawn Guo --- Documentation/devicetree/bindings/arm/fsl.yaml | 6 ++++++ 1 file changed, 6 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml index 1fe59fe70b1f..67d95124216f 100644 --- a/Documentation/devicetree/bindings/arm/fsl.yaml +++ b/Documentation/devicetree/bindings/arm/fsl.yaml @@ -1291,6 +1291,12 @@ properties: - const: tq,imx93-tqma9352 # TQ-Systems GmbH i.MX93 TQMa93xxCA/LA SOM - const: fsl,imx93 + - description: Variscite VAR-SOM-MX93 based boards + items: + - const: variscite,var-som-mx93-symphony + - const: variscite,var-som-mx93 + - const: fsl,imx93 + - description: Freescale Vybrid Platform Device Tree Bindings -- cgit v1.2.3 From 868206f1eba77fdced68395f8782a4b306e74f03 Mon Sep 17 00:00:00 2001 From: Rob Herring Date: Fri, 2 Feb 2024 16:23:51 -0600 Subject: dt-bindings: gpio: mvebu: Fix "unevaluatedProperties" to be false Schemas need "unevaluatedProperties" or "additionalProperties" to be false in order to disallow undefined properties. Only common or otherwise incomplete schemas should allow undefined properties. Signed-off-by: Rob Herring Signed-off-by: Bartosz Golaszewski --- Documentation/devicetree/bindings/gpio/gpio-mvebu.yaml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/gpio/gpio-mvebu.yaml b/Documentation/devicetree/bindings/gpio/gpio-mvebu.yaml index f1bd1e6b2e1f..33d4e4716516 100644 --- a/Documentation/devicetree/bindings/gpio/gpio-mvebu.yaml +++ b/Documentation/devicetree/bindings/gpio/gpio-mvebu.yaml @@ -115,7 +115,7 @@ allOf: required: - reg -unevaluatedProperties: true +unevaluatedProperties: false examples: - | -- cgit v1.2.3 From fc449cefe69d19d3a56903ca7e0fbc91c48ca3f5 Mon Sep 17 00:00:00 2001 From: Michal Simek Date: Thu, 1 Feb 2024 11:24:20 +0100 Subject: dt-bindings: gpio: pca9570: Add label property Add a label property to allow a custom name to be used for identifying a device on the board. This is useful when multiple devices are present on the same board. Similar change was done by commit ffae65fb1ae4 ("dt-bindings: spi: spi-cadence: Add label property") or by commit a53faa6bfa3b ("dt-bindings: hwmon: ina2xx: Add label property"). Signed-off-by: Michal Simek Acked-by: Rob Herring Signed-off-by: Bartosz Golaszewski --- Documentation/devicetree/bindings/gpio/gpio-pca9570.yaml | 3 +++ 1 file changed, 3 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/gpio/gpio-pca9570.yaml b/Documentation/devicetree/bindings/gpio/gpio-pca9570.yaml index 452f8972a965..6f73961001b7 100644 --- a/Documentation/devicetree/bindings/gpio/gpio-pca9570.yaml +++ b/Documentation/devicetree/bindings/gpio/gpio-pca9570.yaml @@ -28,6 +28,9 @@ properties: minItems: 4 maxItems: 8 + label: + description: A descriptive name for this device. + required: - compatible - reg -- cgit v1.2.3 From 6e489bd5aab648fe1bfd8f739e6e4246540b606a Mon Sep 17 00:00:00 2001 From: Frieder Schrempf Date: Tue, 16 Jan 2024 19:10:27 +0100 Subject: dt-bindings: arm: fsl: Add Sielaff i.MX6 Solo board Add compatible for the Sielaff i.MX6 Solo board. Signed-off-by: Frieder Schrempf Acked-by: Conor Dooley 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 67d95124216f..087189e661af 100644 --- a/Documentation/devicetree/bindings/arm/fsl.yaml +++ b/Documentation/devicetree/bindings/arm/fsl.yaml @@ -469,6 +469,7 @@ properties: - prt,prtvt7 # Protonic VT7 board - rex,imx6dl-rex-basic # Rex Basic i.MX6 Dual Lite Board - riot,imx6s-riotboard # RIoTboard i.MX6S + - sielaff,imx6dl-board # Sielaff i.MX6 Solo Board - skov,imx6dl-skov-revc-lt2 # SKOV IMX6 CPU SoloCore lt2 - skov,imx6dl-skov-revc-lt6 # SKOV IMX6 CPU SoloCore lt6 - solidrun,cubox-i/dl # SolidRun Cubox-i Solo/DualLite -- cgit v1.2.3 From f490d0cb9360466f6df0def3eccc47fabba9775b Mon Sep 17 00:00:00 2001 From: Lucas Stach Date: Sat, 3 Feb 2024 10:52:47 -0600 Subject: dt-bindings: display: imx: add binding for i.MX8MP HDMI PVI Add binding for the i.MX8MP HDMI parallel video interface block. Signed-off-by: Lucas Stach Reviewed-by: Laurent Pinchart Reviewed-by: Conor Dooley Signed-off-by: Adam Ford Link: https://lore.kernel.org/r/20240203165307.7806-8-aford173@gmail.com Signed-off-by: Neil Armstrong Link: https://patchwork.freedesktop.org/patch/msgid/20240203165307.7806-8-aford173@gmail.com --- .../bindings/display/imx/fsl,imx8mp-hdmi-pvi.yaml | 84 ++++++++++++++++++++++ 1 file changed, 84 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/imx/fsl,imx8mp-hdmi-pvi.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/imx/fsl,imx8mp-hdmi-pvi.yaml b/Documentation/devicetree/bindings/display/imx/fsl,imx8mp-hdmi-pvi.yaml new file mode 100644 index 000000000000..56da1636014c --- /dev/null +++ b/Documentation/devicetree/bindings/display/imx/fsl,imx8mp-hdmi-pvi.yaml @@ -0,0 +1,84 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/imx/fsl,imx8mp-hdmi-pvi.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Freescale i.MX8MP HDMI Parallel Video Interface + +maintainers: + - Lucas Stach + +description: + The HDMI parallel video interface is a timing and sync generator block in the + i.MX8MP SoC, that sits between the video source and the HDMI TX controller. + +properties: + compatible: + const: fsl,imx8mp-hdmi-pvi + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + power-domains: + maxItems: 1 + + ports: + $ref: /schemas/graph.yaml#/properties/ports + + properties: + port@0: + $ref: /schemas/graph.yaml#/properties/port + description: Input from the LCDIF controller. + + port@1: + $ref: /schemas/graph.yaml#/properties/port + description: Output to the HDMI TX controller. + + required: + - port@0 + - port@1 + +required: + - compatible + - reg + - interrupts + - power-domains + - ports + +additionalProperties: false + +examples: + - | + #include + #include + + display-bridge@32fc4000 { + compatible = "fsl,imx8mp-hdmi-pvi"; + reg = <0x32fc4000 0x44>; + interrupt-parent = <&irqsteer_hdmi>; + interrupts = <12 IRQ_TYPE_LEVEL_HIGH>; + power-domains = <&hdmi_blk_ctrl IMX8MP_HDMIBLK_PD_PVI>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + pvi_from_lcdif3: endpoint { + remote-endpoint = <&lcdif3_to_pvi>; + }; + }; + + port@1 { + reg = <1>; + pvi_to_hdmi_tx: endpoint { + remote-endpoint = <&hdmi_tx_from_pvi>; + }; + }; + }; + }; -- cgit v1.2.3 From fd4f587389e1202ab5737977c11f09ea56bbd1b2 Mon Sep 17 00:00:00 2001 From: Hans Verkuil Date: Fri, 15 Dec 2023 10:38:29 +0100 Subject: media: vidioc-subdev-g-client-cap.rst: document struct v4l2_subdev_client_capability The struct v4l2_subdev_client_capability was never actually documented, only the capability flags were documented. Add this. Signed-off-by: Hans Verkuil --- .../media/v4l/vidioc-subdev-g-client-cap.rst | 15 +++++++++++++++ 1 file changed, 15 insertions(+) (limited to 'Documentation') diff --git a/Documentation/userspace-api/media/v4l/vidioc-subdev-g-client-cap.rst b/Documentation/userspace-api/media/v4l/vidioc-subdev-g-client-cap.rst index 810b6a859dc8..da4a358ce762 100644 --- a/Documentation/userspace-api/media/v4l/vidioc-subdev-g-client-cap.rst +++ b/Documentation/userspace-api/media/v4l/vidioc-subdev-g-client-cap.rst @@ -61,6 +61,21 @@ been accepted. A common case for the kernel not accepting a capability is that the kernel is older than the headers the userspace uses, and thus the capability is unknown to the kernel. +.. tabularcolumns:: |p{1.5cm}|p{2.9cm}|p{12.9cm}| + +.. c:type:: v4l2_subdev_client_capability + +.. flat-table:: struct v4l2_subdev_client_capability + :header-rows: 0 + :stub-columns: 0 + :widths: 3 4 20 + + * - __u64 + - ``capabilities`` + - Sub-device client capabilities of the opened device. + +.. tabularcolumns:: |p{6.8cm}|p{2.4cm}|p{8.1cm}| + .. flat-table:: Client Capabilities :header-rows: 1 -- cgit v1.2.3 From c9cd7308d64b13741ee03be81836a324fc4d657d Mon Sep 17 00:00:00 2001 From: Rob Herring Date: Fri, 2 Feb 2024 16:23:25 -0600 Subject: media: dt-bindings: techwell,tw9900: Fix port schema ref The port@0 node doesn't define any extra properties in the port or endpoint nodes, so the $ref should be to "/properties/port" instead as it restricts extra properties. Fixes: 0f82ffa9a295 ("media: dt-bindings: media: i2c: Add bindings for TW9900") Signed-off-by: Rob Herring Signed-off-by: Hans Verkuil --- Documentation/devicetree/bindings/media/i2c/techwell,tw9900.yaml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/media/i2c/techwell,tw9900.yaml b/Documentation/devicetree/bindings/media/i2c/techwell,tw9900.yaml index e37317f81072..c9673391afdb 100644 --- a/Documentation/devicetree/bindings/media/i2c/techwell,tw9900.yaml +++ b/Documentation/devicetree/bindings/media/i2c/techwell,tw9900.yaml @@ -36,7 +36,7 @@ properties: properties: port@0: - $ref: /schemas/graph.yaml#/$defs/port-base + $ref: /schemas/graph.yaml#/properties/port description: Analog input port properties: -- cgit v1.2.3 From e76681afdc02b3ee0417d2f47825624697afe249 Mon Sep 17 00:00:00 2001 From: Dorcas Anono Litunya Date: Sat, 3 Feb 2024 11:58:05 +0300 Subject: documentation: media: vivid: Modify typo in documentation Correct the default value of node_type vivid parameter to 0xe1d3d. Signed-off-by: Dorcas Anono Litunya Signed-off-by: Hans Verkuil --- Documentation/admin-guide/media/vivid.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/admin-guide/media/vivid.rst b/Documentation/admin-guide/media/vivid.rst index 58ac25b2c385..b6f658c0997e 100644 --- a/Documentation/admin-guide/media/vivid.rst +++ b/Documentation/admin-guide/media/vivid.rst @@ -60,7 +60,7 @@ all configurable using the following module options: - node_types: which devices should each driver instance create. An array of - hexadecimal values, one for each instance. The default is 0x1d3d. + hexadecimal values, one for each instance. The default is 0xe1d3d. Each value is a bitmask with the following meaning: - bit 0: Video Capture node -- cgit v1.2.3 From 8d55a90b2b401e6b5dd289ebbc04dfd9e72ed35f Mon Sep 17 00:00:00 2001 From: Zhenhua Huang Date: Wed, 10 Jan 2024 19:21:45 +0800 Subject: dt-bindings: mtd: avoid automatically select from mtd.yaml The mtd binding is always $ref'ed by other bindings, default selector should be from other binding files which ref'ed it. Now, "$nodename" in mtd.yaml turns into a "select" automatically such that a few binding check issues reported because it conflicts with sram devices(eg, qcom,imem.yaml, rules in folder sram/*) To avoid the automatically created "select" in mtd.yaml, adding: select: false Suggested-by: Bjorn Andersson Fixes: 7bdc671822e9 ("dt-bindings: mtd: physmap: Reuse the generic definitions") Signed-off-by: Zhenhua Huang Reviewed-by: Bjorn Andersson Acked-by: Rob Herring Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/1704885705-7486-1-git-send-email-quic_zhenhuah@quicinc.com --- Documentation/devicetree/bindings/mtd/mtd.yaml | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mtd/mtd.yaml b/Documentation/devicetree/bindings/mtd/mtd.yaml index f322290ee516..ee442ecb11cd 100644 --- a/Documentation/devicetree/bindings/mtd/mtd.yaml +++ b/Documentation/devicetree/bindings/mtd/mtd.yaml @@ -10,6 +10,8 @@ maintainers: - Miquel Raynal - Richard Weinberger +select: false + properties: $nodename: pattern: "^(flash|.*sram|nand)(@.*)?$" -- cgit v1.2.3 From b3decc5ce7d778224d266423b542326ad469cb5f Mon Sep 17 00:00:00 2001 From: Laurent Pinchart Date: Mon, 15 Jan 2024 01:04:52 +0200 Subject: media: mc: Expand MUST_CONNECT flag to always require an enabled link The MEDIA_PAD_FL_MUST_CONNECT flag indicates that the pad requires an enabled link to stream, but only if it has any link at all. This makes little sense, as if a pad is part of a pipeline, there are very few use cases for an active link to be mandatory only if links exist at all. A review of in-tree drivers confirms they all need an enabled link for pads marked with the MEDIA_PAD_FL_MUST_CONNECT flag. Expand the scope of the flag by rejecting pads that have no links at all. This requires modifying the pipeline build code to add those pads to the pipeline. Cc: stable@vger.kernel.org # 6.1 Signed-off-by: Laurent Pinchart Acked-by: Sakari Ailus Signed-off-by: Hans Verkuil --- .../userspace-api/media/mediactl/media-types.rst | 11 ++--- drivers/media/mc/mc-entity.c | 53 ++++++++++++++++++---- 2 files changed, 48 insertions(+), 16 deletions(-) (limited to 'Documentation') diff --git a/Documentation/userspace-api/media/mediactl/media-types.rst b/Documentation/userspace-api/media/mediactl/media-types.rst index 0ffeece1e0c8..6332e8395263 100644 --- a/Documentation/userspace-api/media/mediactl/media-types.rst +++ b/Documentation/userspace-api/media/mediactl/media-types.rst @@ -375,12 +375,11 @@ Types and flags used to represent the media graph elements are origins of links. * - ``MEDIA_PAD_FL_MUST_CONNECT`` - - If this flag is set and the pad is linked to any other pad, then - at least one of those links must be enabled for the entity to be - able to stream. There could be temporary reasons (e.g. device - configuration dependent) for the pad to need enabled links even - when this flag isn't set; the absence of the flag doesn't imply - there is none. + - If this flag is set, then for this pad to be able to stream, it must + be connected by at least one enabled link. There could be temporary + reasons (e.g. device configuration dependent) for the pad to need + enabled links even when this flag isn't set; the absence of the flag + doesn't imply there is none. One and only one of ``MEDIA_PAD_FL_SINK`` and ``MEDIA_PAD_FL_SOURCE`` diff --git a/drivers/media/mc/mc-entity.c b/drivers/media/mc/mc-entity.c index 5907925ffd89..0e28b9a7936e 100644 --- a/drivers/media/mc/mc-entity.c +++ b/drivers/media/mc/mc-entity.c @@ -535,14 +535,15 @@ static int media_pipeline_walk_push(struct media_pipeline_walk *walk, /* * Move the top entry link cursor to the next link. If all links of the entry - * have been visited, pop the entry itself. + * have been visited, pop the entry itself. Return true if the entry has been + * popped. */ -static void media_pipeline_walk_pop(struct media_pipeline_walk *walk) +static bool media_pipeline_walk_pop(struct media_pipeline_walk *walk) { struct media_pipeline_walk_entry *entry; if (WARN_ON(walk->stack.top < 0)) - return; + return false; entry = media_pipeline_walk_top(walk); @@ -552,7 +553,7 @@ static void media_pipeline_walk_pop(struct media_pipeline_walk *walk) walk->stack.top); walk->stack.top--; - return; + return true; } entry->links = entry->links->next; @@ -560,6 +561,8 @@ static void media_pipeline_walk_pop(struct media_pipeline_walk *walk) dev_dbg(walk->mdev->dev, "media pipeline: moved entry %u to next link\n", walk->stack.top); + + return false; } /* Free all memory allocated while walking the pipeline. */ @@ -609,11 +612,12 @@ static int media_pipeline_explore_next_link(struct media_pipeline *pipe, struct media_link *link; struct media_pad *local; struct media_pad *remote; + bool last_link; int ret; origin = entry->pad; link = list_entry(entry->links, typeof(*link), list); - media_pipeline_walk_pop(walk); + last_link = media_pipeline_walk_pop(walk); dev_dbg(walk->mdev->dev, "media pipeline: exploring link '%s':%u -> '%s':%u\n", @@ -638,7 +642,7 @@ static int media_pipeline_explore_next_link(struct media_pipeline *pipe, local->index)) { dev_dbg(walk->mdev->dev, "media pipeline: skipping link (no route)\n"); - return 0; + goto done; } /* @@ -653,13 +657,44 @@ static int media_pipeline_explore_next_link(struct media_pipeline *pipe, if (!(link->flags & MEDIA_LNK_FL_ENABLED)) { dev_dbg(walk->mdev->dev, "media pipeline: skipping link (disabled)\n"); - return 0; + goto done; } ret = media_pipeline_add_pad(pipe, walk, remote); if (ret) return ret; +done: + /* + * If we're done iterating over links, iterate over pads of the entity. + * This is necessary to discover pads that are not connected with any + * link. Those are dead ends from a pipeline exploration point of view, + * but are still part of the pipeline and need to be added to enable + * proper validation. + */ + if (!last_link) + return 0; + + dev_dbg(walk->mdev->dev, + "media pipeline: adding unconnected pads of '%s'\n", + local->entity->name); + + media_entity_for_each_pad(origin->entity, local) { + /* + * Skip the origin pad (already handled), pad that have links + * (already discovered through iterating over links) and pads + * not internally connected. + */ + if (origin == local || !local->num_links || + !media_entity_has_pad_interdep(origin->entity, origin->index, + local->index)) + continue; + + ret = media_pipeline_add_pad(pipe, walk, local); + if (ret) + return ret; + } + return 0; } @@ -771,7 +806,6 @@ __must_check int __media_pipeline_start(struct media_pad *pad, struct media_pad *pad = ppad->pad; struct media_entity *entity = pad->entity; bool has_enabled_link = false; - bool has_link = false; struct media_link *link; dev_dbg(mdev->dev, "Validating pad '%s':%u\n", pad->entity->name, @@ -801,7 +835,6 @@ __must_check int __media_pipeline_start(struct media_pad *pad, /* Record if the pad has links and enabled links. */ if (link->flags & MEDIA_LNK_FL_ENABLED) has_enabled_link = true; - has_link = true; /* * Validate the link if it's enabled and has the @@ -839,7 +872,7 @@ __must_check int __media_pipeline_start(struct media_pad *pad, * 3. If the pad has the MEDIA_PAD_FL_MUST_CONNECT flag set, * ensure that it has either no link or an enabled link. */ - if ((pad->flags & MEDIA_PAD_FL_MUST_CONNECT) && has_link && + if ((pad->flags & MEDIA_PAD_FL_MUST_CONNECT) && !has_enabled_link) { dev_dbg(mdev->dev, "Pad '%s':%u must be connected by an enabled link\n", -- cgit v1.2.3 From 281dc6c69b0ef3e30781451e141628618152a8c0 Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Tue, 9 Jan 2024 09:25:11 +0100 Subject: dt-bindings: mux: restrict node name suffixes Make the pattern matching node names a bit stricter to improve DTS consistency. The pattern is restricted to -N suffixes to decimal numbers. Suggested-by: Rob Herring Signed-off-by: Krzysztof Kozlowski Acked-by: Peter Rosin Link: https://lore.kernel.org/r/20240109082511.15278-1-krzysztof.kozlowski@linaro.org Signed-off-by: Rob Herring --- Documentation/devicetree/bindings/mux/mux-controller.yaml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mux/mux-controller.yaml b/Documentation/devicetree/bindings/mux/mux-controller.yaml index 8b943082a241..571ad9e13ecf 100644 --- a/Documentation/devicetree/bindings/mux/mux-controller.yaml +++ b/Documentation/devicetree/bindings/mux/mux-controller.yaml @@ -74,7 +74,7 @@ select: properties: $nodename: - pattern: '^mux-controller(@.*|-[0-9a-f]+)?$' + pattern: '^mux-controller(@.*|-([0-9]|[1-9][0-9]+))?$' '#mux-control-cells': enum: [ 0, 1 ] -- cgit v1.2.3 From d74029f6c28ff83861c209d738670cf800441901 Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Wed, 31 Jan 2024 13:53:51 +0100 Subject: docs: maintainer: add existing SoC and netdev profiles Extend the list of maintainer profiles with SoC and netdev. Signed-off-by: Krzysztof Kozlowski Signed-off-by: Jonathan Corbet Link: https://lore.kernel.org/r/20240131125351.123509-1-krzysztof.kozlowski@linaro.org --- Documentation/maintainer/maintainer-entry-profile.rst | 3 +++ 1 file changed, 3 insertions(+) (limited to 'Documentation') diff --git a/Documentation/maintainer/maintainer-entry-profile.rst b/Documentation/maintainer/maintainer-entry-profile.rst index 18cee1edaecb..b49fb6dc4d0c 100644 --- a/Documentation/maintainer/maintainer-entry-profile.rst +++ b/Documentation/maintainer/maintainer-entry-profile.rst @@ -102,7 +102,10 @@ to do something different in the near future. ../doc-guide/maintainer-profile ../nvdimm/maintainer-entry-profile ../arch/riscv/patch-acceptance + ../process/maintainer-soc + ../process/maintainer-soc-clean-dts ../driver-api/media/maintainer-entry-profile + ../process/maintainer-netdev ../driver-api/vfio-pci-device-specific-driver-acceptance ../nvme/feature-and-quirk-policy ../filesystems/xfs/xfs-maintainer-entry-profile -- cgit v1.2.3 From 932be49b71e7a67a288b29e78c45bd095a4be704 Mon Sep 17 00:00:00 2001 From: Thorsten Blum Date: Sat, 3 Feb 2024 00:13:16 +0100 Subject: Documentation: coding-style: Fix indentation in code-blocks - Remove spaces in C code-blocks to align error labels consistently - Replace tab characters with spaces in emacs-lisp code blocks Signed-off-by: Thorsten Blum Signed-off-by: Jonathan Corbet Link: https://lore.kernel.org/r/20240202231316.7606-1-thorsten.blum@toblux.com --- Documentation/process/coding-style.rst | 6 +++--- Documentation/translations/it_IT/process/coding-style.rst | 6 +++--- Documentation/translations/sp_SP/process/coding-style.rst | 6 +++--- Documentation/translations/zh_CN/process/coding-style.rst | 4 ++-- Documentation/translations/zh_TW/process/coding-style.rst | 4 ++-- 5 files changed, 13 insertions(+), 13 deletions(-) (limited to 'Documentation') diff --git a/Documentation/process/coding-style.rst b/Documentation/process/coding-style.rst index f8ec23fa89bc..a15a2159b2a9 100644 --- a/Documentation/process/coding-style.rst +++ b/Documentation/process/coding-style.rst @@ -586,9 +586,9 @@ fix for this is to split it up into two error labels ``err_free_bar:`` and .. code-block:: c - err_free_bar: + err_free_bar: kfree(foo->bar); - err_free_foo: + err_free_foo: kfree(foo); return ret; @@ -679,7 +679,7 @@ values. To do the latter, you can stick the following in your .emacs file: (c-offsets-alist . ( (arglist-close . c-lineup-arglist-tabs-only) (arglist-cont-nonempty . - (c-lineup-gcc-asm-reg c-lineup-arglist-tabs-only)) + (c-lineup-gcc-asm-reg c-lineup-arglist-tabs-only)) (arglist-intro . +) (brace-list-intro . +) (c . c-lineup-C-comments) diff --git a/Documentation/translations/it_IT/process/coding-style.rst b/Documentation/translations/it_IT/process/coding-style.rst index 5f244e16f511..284a75ac19f8 100644 --- a/Documentation/translations/it_IT/process/coding-style.rst +++ b/Documentation/translations/it_IT/process/coding-style.rst @@ -575,9 +575,9 @@ due parti ``err_free_bar:`` e ``err_free_foo:``: .. code-block:: c - err_free_bar: + err_free_bar: kfree(foo->bar); - err_free_foo: + err_free_foo: kfree(foo); return ret; @@ -671,7 +671,7 @@ segue nel vostro file .emacs: (c-offsets-alist . ( (arglist-close . c-lineup-arglist-tabs-only) (arglist-cont-nonempty . - (c-lineup-gcc-asm-reg c-lineup-arglist-tabs-only)) + (c-lineup-gcc-asm-reg c-lineup-arglist-tabs-only)) (arglist-intro . +) (brace-list-intro . +) (c . c-lineup-C-comments) diff --git a/Documentation/translations/sp_SP/process/coding-style.rst b/Documentation/translations/sp_SP/process/coding-style.rst index a0261ba5b902..a37274764371 100644 --- a/Documentation/translations/sp_SP/process/coding-style.rst +++ b/Documentation/translations/sp_SP/process/coding-style.rst @@ -604,9 +604,9 @@ Normalmente la solución para esto es dividirlo en dos etiquetas de error .. code-block:: c - err_free_bar: + err_free_bar: kfree(foo->bar); - err_free_foo: + err_free_foo: kfree(foo); return ret; @@ -698,7 +698,7 @@ sanos. Para hacer esto último, puede pegar lo siguiente en su archivo (c-offsets-alist . ( (arglist-close . c-lineup-arglist-tabs-only) (arglist-cont-nonempty . - (c-lineup-gcc-asm-reg c-lineup-arglist-tabs-only)) + (c-lineup-gcc-asm-reg c-lineup-arglist-tabs-only)) (arglist-intro . +) (brace-list-intro . +) (c . c-lineup-C-comments) diff --git a/Documentation/translations/zh_CN/process/coding-style.rst b/Documentation/translations/zh_CN/process/coding-style.rst index fa28ef0a7fee..3bc2810b151d 100644 --- a/Documentation/translations/zh_CN/process/coding-style.rst +++ b/Documentation/translations/zh_CN/process/coding-style.rst @@ -523,9 +523,9 @@ Linux 里这是提倡的做法，因为这样可以很简单的给读者提供 .. code-block:: c - err_free_bar: + err_free_bar: kfree(foo->bar); - err_free_foo: + err_free_foo: kfree(foo); return ret; diff --git a/Documentation/translations/zh_TW/process/coding-style.rst b/Documentation/translations/zh_TW/process/coding-style.rst index f11dbb65ca21..c7ac504f6f40 100644 --- a/Documentation/translations/zh_TW/process/coding-style.rst +++ b/Documentation/translations/zh_TW/process/coding-style.rst @@ -526,9 +526,9 @@ Linux 裏這是提倡的做法，因爲這樣可以很簡單的給讀者提供 .. code-block:: c - err_free_bar: + err_free_bar: kfree(foo->bar); - err_free_foo: + err_free_foo: kfree(foo); return ret; -- cgit v1.2.3 From 3e3ede49ce93bc5549d1a1a756410071d6e3a7b1 Mon Sep 17 00:00:00 2001 From: "Guilherme G. Piccoli" Date: Sat, 3 Feb 2024 12:21:13 -0300 Subject: docs: Document possible_cpus parameter The number of possible CPUs is set be kernel in early boot time through some discovery mechanisms, like ACPI in x86. We have a parameter both in x86 and S390 to override that - there are some cases of BIOSes exposing more possible CPUs than the available ones, so this parameter is a good testing mechanism, but for some reason wasn't mentioned so far in the kernel parameters guide - let's fix that. Cc: Changwoo Min Signed-off-by: "Guilherme G. Piccoli" Reviewed-by: Randy Dunlap Signed-off-by: Jonathan Corbet Link: https://lore.kernel.org/r/20240203152208.1461293-1-gpiccoli@igalia.com --- 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 31b3a25680d0..e553740190ea 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -4644,6 +4644,11 @@ may be specified. Format: ,.... + possible_cpus= [SMP,S390,X86] + Format: + Set the number of possible CPUs, overriding the + regular discovery mechanisms (such as ACPI/FW, etc). + powersave=off [PPC] This option disables power saving features. It specifically disables cpuidle and sets the platform machine description specific power_save -- cgit v1.2.3 From 185ea7676ef3220de1ee90f288df3601f83afda0 Mon Sep 17 00:00:00 2001 From: Thorsten Blum Date: Sat, 3 Feb 2024 23:39:26 +0100 Subject: Documentation: coding-style: Update syntax highlighting for code-blocks Use c and elisp instead of none in code-blocks Signed-off-by: Thorsten Blum Signed-off-by: Jonathan Corbet Link: https://lore.kernel.org/r/20240203223926.5077-1-thorsten.blum@toblux.com --- Documentation/process/coding-style.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/process/coding-style.rst b/Documentation/process/coding-style.rst index a15a2159b2a9..9c7cf7347394 100644 --- a/Documentation/process/coding-style.rst +++ b/Documentation/process/coding-style.rst @@ -203,7 +203,7 @@ Do not unnecessarily use braces where a single statement will do. and -.. code-block:: none +.. code-block:: c if (condition) do_this(); @@ -660,7 +660,7 @@ make a good program). So, you can either get rid of GNU emacs, or change it to use saner values. To do the latter, you can stick the following in your .emacs file: -.. code-block:: none +.. code-block:: elisp (defun c-lineup-arglist-tabs-only (ignored) "Line up argument lists by tabs, not spaces" -- cgit v1.2.3 From 40be2369dc0ee803b2bacf32471472604a948b88 Mon Sep 17 00:00:00 2001 From: Thorsten Blum Date: Mon, 5 Feb 2024 01:01:17 +0100 Subject: Documentation: multiple .rst files: Fix grammar and more consistent formatting sphinx.rst: - Remove unnecessary newline - Fix grammar s/on/in/ - Fix grammar s/check/checks/ - Capitalize heading "The C domain" changes.rst: - Remove colon after "pahole" to be consistent with other entries howto.rst: - Fix grammar s/you will/will you/ - Hyphenate "real-world problems" Signed-off-by: Thorsten Blum Reviewed-by: Randy Dunlap Signed-off-by: Jonathan Corbet Link: https://lore.kernel.org/r/20240205000117.3285-1-thorsten.blum@toblux.com --- Documentation/doc-guide/sphinx.rst | 7 +++---- Documentation/process/changes.rst | 4 ++-- Documentation/process/howto.rst | 4 ++-- 3 files changed, 7 insertions(+), 8 deletions(-) (limited to 'Documentation') diff --git a/Documentation/doc-guide/sphinx.rst b/Documentation/doc-guide/sphinx.rst index 3d125fb4139d..709e19821a16 100644 --- a/Documentation/doc-guide/sphinx.rst +++ b/Documentation/doc-guide/sphinx.rst @@ -63,8 +63,7 @@ Image output ------------ The kernel documentation build system contains an extension that -handles images on both GraphViz and SVG formats (see -:ref:`sphinx_kfigure`). +handles images in both GraphViz and SVG formats (see :ref:`sphinx_kfigure`). For it to work, you need to install both GraphViz and ImageMagick packages. If those packages are not installed, the build system will @@ -108,7 +107,7 @@ further info. Checking for Sphinx dependencies -------------------------------- -There's a script that automatically check for Sphinx dependencies. If it can +There's a script that automatically checks for Sphinx dependencies. If it can recognize your distribution, it will also give a hint about the install command line options for your distro:: @@ -283,7 +282,7 @@ Here are some specific guidelines for the kernel documentation: from highlighting. For a short snippet of code embedded in the text, use \`\`. -the C domain +The C domain ------------ The **Sphinx C Domain** (name c) is suited for documentation of C API. E.g. a diff --git a/Documentation/process/changes.rst b/Documentation/process/changes.rst index 50b3d1cb1115..4c1552160321 100644 --- a/Documentation/process/changes.rst +++ b/Documentation/process/changes.rst @@ -144,8 +144,8 @@ Bison Since Linux 4.16, the build system generates parsers during build. This requires bison 2.0 or later. -pahole: -------- +pahole +------ Since Linux 5.2, if CONFIG_DEBUG_INFO_BTF is selected, the build system generates BTF (BPF Type Format) from DWARF in vmlinux, a bit later from kernel diff --git a/Documentation/process/howto.rst b/Documentation/process/howto.rst index 6c73889c98fc..eebda4910a88 100644 --- a/Documentation/process/howto.rst +++ b/Documentation/process/howto.rst @@ -351,8 +351,8 @@ Managing bug reports -------------------- One of the best ways to put into practice your hacking skills is by fixing -bugs reported by other people. Not only you will help to make the kernel -more stable, but you'll also learn to fix real world problems and you will +bugs reported by other people. Not only will you help to make the kernel +more stable, but you'll also learn to fix real-world problems and you will improve your skills, and other developers will be aware of your presence. Fixing bugs is one of the best ways to get merits among other developers, because not many people like wasting time fixing other people's bugs. -- cgit v1.2.3 From f9197538d71a5d3ccd57451e048a0eb302bddc03 Mon Sep 17 00:00:00 2001 From: Thorsten Blum Date: Mon, 5 Feb 2024 14:24:10 +0100 Subject: Documentation: admin-guide: tainted-kernels.rst: Add missing article and comma - Add missing article "the" - s/above example/example above/ - Add missing comma after introductory clause to improve readability Signed-off-by: Thorsten Blum Signed-off-by: Jonathan Corbet Link: https://lore.kernel.org/r/20240205132409.1957-1-thorsten.blum@toblux.com --- Documentation/admin-guide/tainted-kernels.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/admin-guide/tainted-kernels.rst b/Documentation/admin-guide/tainted-kernels.rst index 92a8a07f5c43..f92551539e8a 100644 --- a/Documentation/admin-guide/tainted-kernels.rst +++ b/Documentation/admin-guide/tainted-kernels.rst @@ -34,7 +34,7 @@ name of the command ('Comm:') that triggered the event:: You'll find a 'Not tainted: ' there if the kernel was not tainted at the time of the event; if it was, then it will print 'Tainted: ' and characters -either letters or blanks. In above example it looks like this:: +either letters or blanks. In the example above it looks like this:: Tainted: P W O @@ -52,7 +52,7 @@ At runtime, you can query the tainted state by reading tainted; any other number indicates the reasons why it is. The easiest way to decode that number is the script ``tools/debugging/kernel-chktaint``, which your distribution might ship as part of a package called ``linux-tools`` or -``kernel-tools``; if it doesn't you can download the script from +``kernel-tools``; if it doesn't, you can download the script from `git.kernel.org `_ and execute it with ``sh kernel-chktaint``, which would print something like this on the machine that had the statements in the logs that were quoted earlier:: -- cgit v1.2.3 From 2592a36d956955f0e0f399d608d7be0ec280a40c Mon Sep 17 00:00:00 2001 From: Jeffrey Hugo Date: Fri, 2 Feb 2024 13:23:29 -0700 Subject: dt-bindings: drm/bridge: ti-sn65dsi86: Fix bouncing @codeaurora address The servers for the @codeaurora domain are long retired and any messages sent there bounce. Sandeep Panda's email address is no longer valid and should be repleaced. However Sandeep has left the company and has not been active sice, therefore it looks like this binding is orphaned. Doug is listed as the reviewer for this file in MAINTAINERS and has volunteered to be listed within the file as the binding maintainer. Therefore replace Sandeep with Doug to make the documentation current. Signed-off-by: Jeffrey Hugo Reviewed-by: Douglas Anderson Reviewed-by: Abhinav Kumar Reviewed-by: Neil Armstrong Acked-by: Rob Herring Signed-off-by: Douglas Anderson Link: https://patchwork.freedesktop.org/patch/msgid/20240202202329.4172917-1-quic_jhugo@quicinc.com --- Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml | 2 +- 1 file changed, 1 insertion(+), 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 6ec6d287bff4..c93878b6d718 100644 --- a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml +++ b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: SN65DSI86 DSI to eDP bridge chip maintainers: - - Sandeep Panda + - Douglas Anderson description: | The Texas Instruments SN65DSI86 bridge takes MIPI DSI in and outputs eDP. -- cgit v1.2.3 From 2d9a925d0fbf0dae99af148adaf4f5cadf1be5e0 Mon Sep 17 00:00:00 2001 From: Dave Thaler Date: Fri, 2 Feb 2024 14:11:10 -0800 Subject: bpf, docs: Expand set of initial conformance groups This patch attempts to update the ISA specification according to the latest mailing list discussion about conformance groups, in a way that is intended to be consistent with IANA registry processes and IETF 118 WG meeting discussion. It does the following: * Split basic into base32 and base64 for 32-bit vs 64-bit base instructions * Split division/multiplication/modulo instructions out of base groups * Split atomic instructions out of base groups There may be additional changes as discussion continues, but there seems to be consensus on the principles above. v1->v2: fixed typo pointed out by David Vernet v2->v3: Moved multiplication to same groups as division/modulo Signed-off-by: Dave Thaler Acked-by: David Vernet Link: https://lore.kernel.org/r/20240202221110.3872-1-dthaler1968@gmail.com Signed-off-by: Alexei Starovoitov --- .../bpf/standardization/instruction-set.rst | 48 ++++++++++++++++------ 1 file changed, 36 insertions(+), 12 deletions(-) (limited to 'Documentation') diff --git a/Documentation/bpf/standardization/instruction-set.rst b/Documentation/bpf/standardization/instruction-set.rst index dcbc9193c66f..1c4258f1ce93 100644 --- a/Documentation/bpf/standardization/instruction-set.rst +++ b/Documentation/bpf/standardization/instruction-set.rst @@ -102,7 +102,7 @@ Conformance groups An implementation does not need to support all instructions specified in this document (e.g., deprecated instructions). Instead, a number of conformance -groups are specified. An implementation must support the "basic" conformance +groups are specified. An implementation must support the base32 conformance group and may support additional conformance groups, where supporting a conformance group means it must support all instructions in that conformance group. @@ -112,12 +112,21 @@ that executes instructions, and tools as such compilers that generate instructions for the runtime. Thus, capability discovery in terms of conformance groups might be done manually by users or automatically by tools. -Each conformance group has a short ASCII label (e.g., "basic") that +Each conformance group has a short ASCII label (e.g., "base32") that corresponds to a set of instructions that are mandatory. That is, each instruction has one or more conformance groups of which it is a member. -The "basic" conformance group includes all instructions defined in this -specification unless otherwise noted. +This document defines the following conformance groups: +* base32: includes all instructions defined in this + specification unless otherwise noted. +* base64: includes base32, plus instructions explicitly noted + as being in the base64 conformance group. +* atomic32: includes 32-bit atomic operation instructions (see `Atomic operations`_). +* atomic64: includes atomic32, plus 64-bit atomic operation instructions. +* divmul32: includes 32-bit division, multiplication, and modulo instructions. +* divmul64: includes divmul32, plus 64-bit division, multiplication, + and modulo instructions. +* legacy: deprecated packet access instructions. Instruction encoding ==================== @@ -234,7 +243,8 @@ Arithmetic instructions ----------------------- ``BPF_ALU`` uses 32-bit wide operands while ``BPF_ALU64`` uses 64-bit wide operands for -otherwise identical operations. +otherwise identical operations. ``BPF_ALU64`` instructions belong to the +base64 conformance group unless noted otherwise. The 'code' field encodes the operation as below, where 'src' and 'dst' refer to the values of the source and destination registers, respectively. @@ -288,6 +298,10 @@ where '(u32)' indicates that the upper 32 bits are zeroed. Note that most instructions have instruction offset of 0. Only three instructions (``BPF_SDIV``, ``BPF_SMOD``, ``BPF_MOVSX``) have a non-zero offset. +Division, multiplication, and modulo operations for ``BPF_ALU`` are part +of the "divmul32" conformance group, and division, multiplication, and +modulo operations for ``BPF_ALU64`` are part of the "divmul64" conformance +group. The division and modulo operations support both unsigned and signed flavors. For unsigned operations (``BPF_DIV`` and ``BPF_MOD``), for ``BPF_ALU``, @@ -344,7 +358,9 @@ BPF_ALU64 Reserved 0x00 do byte swap unconditionally ========= ========= ===== ================================================= The 'imm' field encodes the width of the swap operations. The following widths -are supported: 16, 32 and 64. +are supported: 16, 32 and 64. Width 64 operations belong to the base64 +conformance group and other swap operations belong to the base32 +conformance group. Examples: @@ -369,8 +385,10 @@ Examples: Jump instructions ----------------- -``BPF_JMP32`` uses 32-bit wide operands while ``BPF_JMP`` uses 64-bit wide operands for -otherwise identical operations. +``BPF_JMP32`` uses 32-bit wide operands and indicates the base32 +conformance group, while ``BPF_JMP`` uses 64-bit wide operands for +otherwise identical operations, and indicates the base64 conformance +group unless otherwise specified. The 'code' field encodes the operation as below: ======== ===== === =============================== ============================================= @@ -419,6 +437,9 @@ specified by the 'imm' field. A > 16-bit conditional jump may be converted to a < 16-bit conditional jump plus a 32-bit unconditional jump. +All ``BPF_CALL`` and ``BPF_JA`` instructions belong to the +base32 conformance group. + Helper functions ~~~~~~~~~~~~~~~~ @@ -476,6 +497,8 @@ The size modifier is one of: BPF_DW 0x18 double word (8 bytes) ============= ===== ===================== +Instructions using ``BPF_DW`` belong to the base64 conformance group. + Regular load and store operations --------------------------------- @@ -520,8 +543,10 @@ by other BPF programs or means outside of this specification. All atomic operations supported by BPF are encoded as store operations that use the ``BPF_ATOMIC`` mode modifier as follows: -* ``BPF_ATOMIC | BPF_W | BPF_STX`` for 32-bit operations -* ``BPF_ATOMIC | BPF_DW | BPF_STX`` for 64-bit operations +* ``BPF_ATOMIC | BPF_W | BPF_STX`` for 32-bit operations, which are + part of the "atomic32" conformance group. +* ``BPF_ATOMIC | BPF_DW | BPF_STX`` for 64-bit operations, which are + part of the "atomic64" conformance group. * 8-bit and 16-bit wide atomic operations are not supported. The 'imm' field is used to encode the actual atomic operation. @@ -634,5 +659,4 @@ carried over from classic BPF. These instructions used an instruction class of BPF_LD, a size modifier of BPF_W, BPF_H, or BPF_B, and a mode modifier of BPF_ABS or BPF_IND. However, these instructions are deprecated and should no longer be used. All legacy packet access -instructions belong to the "legacy" conformance group instead of the "basic" -conformance group. +instructions belong to the "legacy" conformance group. -- cgit v1.2.3 From fd2bc4195d5107f88c1b90e1ec935888ccbfc5c0 Mon Sep 17 00:00:00 2001 From: Leon Romanovsky Date: Tue, 3 Oct 2023 20:57:20 +0300 Subject: xfrm: generalize xdo_dev_state_update_curlft to allow statistics update In order to allow drivers to fill all statistics, change the name of xdo_dev_state_update_curlft to be xdo_dev_state_update_stats. Acked-by: Steffen Klassert Signed-off-by: Leon Romanovsky Signed-off-by: Saeed Mahameed --- Documentation/networking/xfrm_device.rst | 4 ++-- drivers/net/ethernet/mellanox/mlx5/core/en_accel/ipsec.c | 7 ++++--- include/linux/netdevice.h | 2 +- include/net/xfrm.h | 11 ++++------- net/xfrm/xfrm_state.c | 4 ++-- net/xfrm/xfrm_user.c | 2 +- 6 files changed, 14 insertions(+), 16 deletions(-) (limited to 'Documentation') diff --git a/Documentation/networking/xfrm_device.rst b/Documentation/networking/xfrm_device.rst index 535077cbeb07..bfea9d8579ed 100644 --- a/Documentation/networking/xfrm_device.rst +++ b/Documentation/networking/xfrm_device.rst @@ -71,9 +71,9 @@ Callbacks to implement bool (*xdo_dev_offload_ok) (struct sk_buff *skb, struct xfrm_state *x); void (*xdo_dev_state_advance_esn) (struct xfrm_state *x); + void (*xdo_dev_state_update_stats) (struct xfrm_state *x); /* Solely packet offload callbacks */ - void (*xdo_dev_state_update_curlft) (struct xfrm_state *x); int (*xdo_dev_policy_add) (struct xfrm_policy *x, struct netlink_ext_ack *extack); void (*xdo_dev_policy_delete) (struct xfrm_policy *x); void (*xdo_dev_policy_free) (struct xfrm_policy *x); @@ -191,6 +191,6 @@ xdo_dev_policy_free() on any remaining offloaded states. Outcome of HW handling packets, the XFRM core can't count hard, soft limits. The HW/driver are responsible to perform it and provide accurate data when -xdo_dev_state_update_curlft() is called. In case of one of these limits +xdo_dev_state_update_stats() is called. In case of one of these limits occuried, the driver needs to call to xfrm_state_check_expire() to make sure that XFRM performs rekeying sequence. diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_accel/ipsec.c b/drivers/net/ethernet/mellanox/mlx5/core/en_accel/ipsec.c index 05612d9c6080..f160522fbe75 100644 --- a/drivers/net/ethernet/mellanox/mlx5/core/en_accel/ipsec.c +++ b/drivers/net/ethernet/mellanox/mlx5/core/en_accel/ipsec.c @@ -984,7 +984,7 @@ static void mlx5e_xfrm_advance_esn_state(struct xfrm_state *x) queue_work(sa_entry->ipsec->wq, &work->work); } -static void mlx5e_xfrm_update_curlft(struct xfrm_state *x) +static void mlx5e_xfrm_update_stats(struct xfrm_state *x) { struct mlx5e_ipsec_sa_entry *sa_entry = to_ipsec_sa_entry(x); struct mlx5e_ipsec_rule *ipsec_rule = &sa_entry->ipsec_rule; @@ -993,7 +993,8 @@ static void mlx5e_xfrm_update_curlft(struct xfrm_state *x) lockdep_assert(lockdep_is_held(&x->lock) || lockdep_is_held(&dev_net(x->xso.real_dev)->xfrm.xfrm_cfg_mutex)); - if (x->xso.flags & XFRM_DEV_OFFLOAD_FLAG_ACQ) + if (x->xso.flags & XFRM_DEV_OFFLOAD_FLAG_ACQ || + x->xso.type != XFRM_DEV_OFFLOAD_PACKET) return; mlx5_fc_query_cached(ipsec_rule->fc, &bytes, &packets, &lastuse); @@ -1156,7 +1157,7 @@ static const struct xfrmdev_ops mlx5e_ipsec_xfrmdev_ops = { .xdo_dev_offload_ok = mlx5e_ipsec_offload_ok, .xdo_dev_state_advance_esn = mlx5e_xfrm_advance_esn_state, - .xdo_dev_state_update_curlft = mlx5e_xfrm_update_curlft, + .xdo_dev_state_update_stats = mlx5e_xfrm_update_stats, .xdo_dev_policy_add = mlx5e_xfrm_add_policy, .xdo_dev_policy_delete = mlx5e_xfrm_del_policy, .xdo_dev_policy_free = mlx5e_xfrm_free_policy, diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h index 118c40258d07..9538576dbebc 100644 --- a/include/linux/netdevice.h +++ b/include/linux/netdevice.h @@ -1062,7 +1062,7 @@ struct xfrmdev_ops { bool (*xdo_dev_offload_ok) (struct sk_buff *skb, struct xfrm_state *x); void (*xdo_dev_state_advance_esn) (struct xfrm_state *x); - void (*xdo_dev_state_update_curlft) (struct xfrm_state *x); + void (*xdo_dev_state_update_stats) (struct xfrm_state *x); int (*xdo_dev_policy_add) (struct xfrm_policy *x, struct netlink_ext_ack *extack); void (*xdo_dev_policy_delete) (struct xfrm_policy *x); void (*xdo_dev_policy_free) (struct xfrm_policy *x); diff --git a/include/net/xfrm.h b/include/net/xfrm.h index 1d107241b901..4ca2f3205190 100644 --- a/include/net/xfrm.h +++ b/include/net/xfrm.h @@ -1578,21 +1578,18 @@ struct xfrm_state *xfrm_state_lookup_byspi(struct net *net, __be32 spi, unsigned short family); int xfrm_state_check_expire(struct xfrm_state *x); #ifdef CONFIG_XFRM_OFFLOAD -static inline void xfrm_dev_state_update_curlft(struct xfrm_state *x) +static inline void xfrm_dev_state_update_stats(struct xfrm_state *x) { struct xfrm_dev_offload *xdo = &x->xso; struct net_device *dev = xdo->dev; - if (x->xso.type != XFRM_DEV_OFFLOAD_PACKET) - return; - if (dev && dev->xfrmdev_ops && - dev->xfrmdev_ops->xdo_dev_state_update_curlft) - dev->xfrmdev_ops->xdo_dev_state_update_curlft(x); + dev->xfrmdev_ops->xdo_dev_state_update_stats) + dev->xfrmdev_ops->xdo_dev_state_update_stats(x); } #else -static inline void xfrm_dev_state_update_curlft(struct xfrm_state *x) {} +static inline void xfrm_dev_state_update_stats(struct xfrm_state *x) {} #endif void xfrm_state_insert(struct xfrm_state *x); int xfrm_state_add(struct xfrm_state *x); diff --git a/net/xfrm/xfrm_state.c b/net/xfrm/xfrm_state.c index bda5327bf34d..d8701b2d0d57 100644 --- a/net/xfrm/xfrm_state.c +++ b/net/xfrm/xfrm_state.c @@ -570,7 +570,7 @@ static enum hrtimer_restart xfrm_timer_handler(struct hrtimer *me) int err = 0; spin_lock(&x->lock); - xfrm_dev_state_update_curlft(x); + xfrm_dev_state_update_stats(x); if (x->km.state == XFRM_STATE_DEAD) goto out; @@ -1935,7 +1935,7 @@ EXPORT_SYMBOL(xfrm_state_update); int xfrm_state_check_expire(struct xfrm_state *x) { - xfrm_dev_state_update_curlft(x); + xfrm_dev_state_update_stats(x); if (!READ_ONCE(x->curlft.use_time)) WRITE_ONCE(x->curlft.use_time, ktime_get_real_seconds()); diff --git a/net/xfrm/xfrm_user.c b/net/xfrm/xfrm_user.c index ad01997c3aa9..dc4f9b8d7cb0 100644 --- a/net/xfrm/xfrm_user.c +++ b/net/xfrm/xfrm_user.c @@ -902,7 +902,7 @@ static void copy_to_user_state(struct xfrm_state *x, struct xfrm_usersa_info *p) memcpy(&p->sel, &x->sel, sizeof(p->sel)); memcpy(&p->lft, &x->lft, sizeof(p->lft)); if (x->xso.dev) - xfrm_dev_state_update_curlft(x); + xfrm_dev_state_update_stats(x); memcpy(&p->curlft, &x->curlft, sizeof(p->curlft)); put_unaligned(x->stats.replay_window, &p->stats.replay_window); put_unaligned(x->stats.replay, &p->stats.replay); -- cgit v1.2.3 From 21e16fa5dc6c6f69d9f2cf84e6d8f147ec4c1fbe Mon Sep 17 00:00:00 2001 From: Moshe Shemesh Date: Fri, 26 Jan 2024 15:05:58 +0200 Subject: Documentation: Fix counter name of mlx5 vnic reporter Fix counter name in documentation of mlx5 vnic health reporter diagnose output: total_error_queues. While here fix alignment in the documentation file of another counter, comp_eq_overrun, as it should have its own line and not be part of another counter's description. Example: $ devlink health diagnose pci/0000:00:04.0 reporter vnic vNIC env counters: total_error_queues: 0 send_queue_priority_update_flow: 0 comp_eq_overrun: 0 async_eq_overrun: 0 cq_overrun: 0 invalid_command: 0 quota_exceeded_command: 0 nic_receive_steering_discard: 0 Signed-off-by: Moshe Shemesh Signed-off-by: Saeed Mahameed --- Documentation/networking/devlink/mlx5.rst | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/networking/devlink/mlx5.rst b/Documentation/networking/devlink/mlx5.rst index b9587b3400b9..456985407475 100644 --- a/Documentation/networking/devlink/mlx5.rst +++ b/Documentation/networking/devlink/mlx5.rst @@ -250,7 +250,7 @@ them in realtime. Description of the vnic counters: -- total_q_under_processor_handle +- total_error_queues number of queues in an error state due to an async error or errored command. - send_queue_priority_update_flow @@ -259,7 +259,8 @@ Description of the vnic counters: number of times CQ entered an error state due to an overflow. - async_eq_overrun number of times an EQ mapped to async events was overrun. - comp_eq_overrun number of times an EQ mapped to completion events was +- comp_eq_overrun + number of times an EQ mapped to completion events was overrun. - quota_exceeded_command number of commands issued and failed due to quota exceeded. -- cgit v1.2.3 From c7115e094ca820bb72e0c89f158d16bc48c6fa04 Mon Sep 17 00:00:00 2001 From: Chao Yu Date: Sat, 13 Jan 2024 03:41:32 +0800 Subject: f2fs: introduce FAULT_BLKADDR_CONSISTENCE We will encounter below inconsistent status when FAULT_BLKADDR type fault injection is on. Info: checkpoint state = d6 : nat_bits crc fsck compacted_summary orphan_inodes sudden-power-off [ASSERT] (fsck_chk_inode_blk:1254) --> ino: 0x1c100 has i_blocks: 000000c0, but has 191 blocks [FIX] (fsck_chk_inode_blk:1260) --> [0x1c100] i_blocks=0x000000c0 -> 0xbf [FIX] (fsck_chk_inode_blk:1269) --> [0x1c100] i_compr_blocks=0x00000026 -> 0x27 [ASSERT] (fsck_chk_inode_blk:1254) --> ino: 0x1cadb has i_blocks: 0000002f, but has 46 blocks [FIX] (fsck_chk_inode_blk:1260) --> [0x1cadb] i_blocks=0x0000002f -> 0x2e [FIX] (fsck_chk_inode_blk:1269) --> [0x1cadb] i_compr_blocks=0x00000011 -> 0x12 [ASSERT] (fsck_chk_inode_blk:1254) --> ino: 0x1c62c has i_blocks: 00000002, but has 1 blocks [FIX] (fsck_chk_inode_blk:1260) --> [0x1c62c] i_blocks=0x00000002 -> 0x1 After we inject fault into f2fs_is_valid_blkaddr() during truncation, a) it missed to increase @nr_free or @valid_blocks b) it can cause in blkaddr leak in truncated dnode Which may cause inconsistent status. This patch separates FAULT_BLKADDR_CONSISTENCE from FAULT_BLKADDR, and rename FAULT_BLKADDR to FAULT_BLKADDR_VALIDITY so that we can: a) use FAULT_BLKADDR_CONSISTENCE in f2fs_truncate_data_blocks_range() to simulate inconsistent issue independently, then it can verify fsck repair flow. b) FAULT_BLKADDR_VALIDITY fault will not cause any inconsistent status, we can just use it to check error path handling in kernel side. Reviewed-by: Daeho Jeong Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim --- Documentation/ABI/testing/sysfs-fs-f2fs | 47 +++++++++++++++++---------------- Documentation/filesystems/f2fs.rst | 47 +++++++++++++++++---------------- fs/f2fs/checkpoint.c | 19 ++++++++++--- fs/f2fs/f2fs.h | 5 +++- fs/f2fs/file.c | 8 ++++-- fs/f2fs/super.c | 37 +++++++++++++------------- 6 files changed, 92 insertions(+), 71 deletions(-) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-fs-f2fs b/Documentation/ABI/testing/sysfs-fs-f2fs index 99fa87a43926..48c135e24eb5 100644 --- a/Documentation/ABI/testing/sysfs-fs-f2fs +++ b/Documentation/ABI/testing/sysfs-fs-f2fs @@ -701,29 +701,30 @@ Description: Support configuring fault injection type, should be enabled with fault_injection option, fault type value is shown below, it supports single or combined type. - =================== =========== - Type_Name Type_Value - =================== =========== - FAULT_KMALLOC 0x000000001 - FAULT_KVMALLOC 0x000000002 - FAULT_PAGE_ALLOC 0x000000004 - FAULT_PAGE_GET 0x000000008 - FAULT_ALLOC_BIO 0x000000010 (obsolete) - FAULT_ALLOC_NID 0x000000020 - FAULT_ORPHAN 0x000000040 - FAULT_BLOCK 0x000000080 - FAULT_DIR_DEPTH 0x000000100 - FAULT_EVICT_INODE 0x000000200 - FAULT_TRUNCATE 0x000000400 - FAULT_READ_IO 0x000000800 - FAULT_CHECKPOINT 0x000001000 - FAULT_DISCARD 0x000002000 - FAULT_WRITE_IO 0x000004000 - FAULT_SLAB_ALLOC 0x000008000 - FAULT_DQUOT_INIT 0x000010000 - FAULT_LOCK_OP 0x000020000 - FAULT_BLKADDR 0x000040000 - =================== =========== + =========================== =========== + Type_Name Type_Value + =========================== =========== + FAULT_KMALLOC 0x000000001 + FAULT_KVMALLOC 0x000000002 + FAULT_PAGE_ALLOC 0x000000004 + FAULT_PAGE_GET 0x000000008 + FAULT_ALLOC_BIO 0x000000010 (obsolete) + FAULT_ALLOC_NID 0x000000020 + FAULT_ORPHAN 0x000000040 + FAULT_BLOCK 0x000000080 + FAULT_DIR_DEPTH 0x000000100 + FAULT_EVICT_INODE 0x000000200 + FAULT_TRUNCATE 0x000000400 + FAULT_READ_IO 0x000000800 + FAULT_CHECKPOINT 0x000001000 + FAULT_DISCARD 0x000002000 + FAULT_WRITE_IO 0x000004000 + FAULT_SLAB_ALLOC 0x000008000 + FAULT_DQUOT_INIT 0x000010000 + FAULT_LOCK_OP 0x000020000 + FAULT_BLKADDR_VALIDITY 0x000040000 + FAULT_BLKADDR_CONSISTENCE 0x000080000 + =========================== =========== What: /sys/fs/f2fs//discard_io_aware_gran Date: January 2023 diff --git a/Documentation/filesystems/f2fs.rst b/Documentation/filesystems/f2fs.rst index d32c6209685d..32cbfa864f38 100644 --- a/Documentation/filesystems/f2fs.rst +++ b/Documentation/filesystems/f2fs.rst @@ -184,29 +184,30 @@ fault_type=%d Support configuring fault injection type, should be enabled with fault_injection option, fault type value is shown below, it supports single or combined type. - =================== =========== - Type_Name Type_Value - =================== =========== - FAULT_KMALLOC 0x000000001 - FAULT_KVMALLOC 0x000000002 - FAULT_PAGE_ALLOC 0x000000004 - FAULT_PAGE_GET 0x000000008 - FAULT_ALLOC_BIO 0x000000010 (obsolete) - FAULT_ALLOC_NID 0x000000020 - FAULT_ORPHAN 0x000000040 - FAULT_BLOCK 0x000000080 - FAULT_DIR_DEPTH 0x000000100 - FAULT_EVICT_INODE 0x000000200 - FAULT_TRUNCATE 0x000000400 - FAULT_READ_IO 0x000000800 - FAULT_CHECKPOINT 0x000001000 - FAULT_DISCARD 0x000002000 - FAULT_WRITE_IO 0x000004000 - FAULT_SLAB_ALLOC 0x000008000 - FAULT_DQUOT_INIT 0x000010000 - FAULT_LOCK_OP 0x000020000 - FAULT_BLKADDR 0x000040000 - =================== =========== + =========================== =========== + Type_Name Type_Value + =========================== =========== + FAULT_KMALLOC 0x000000001 + FAULT_KVMALLOC 0x000000002 + FAULT_PAGE_ALLOC 0x000000004 + FAULT_PAGE_GET 0x000000008 + FAULT_ALLOC_BIO 0x000000010 (obsolete) + FAULT_ALLOC_NID 0x000000020 + FAULT_ORPHAN 0x000000040 + FAULT_BLOCK 0x000000080 + FAULT_DIR_DEPTH 0x000000100 + FAULT_EVICT_INODE 0x000000200 + FAULT_TRUNCATE 0x000000400 + FAULT_READ_IO 0x000000800 + FAULT_CHECKPOINT 0x000001000 + FAULT_DISCARD 0x000002000 + FAULT_WRITE_IO 0x000004000 + FAULT_SLAB_ALLOC 0x000008000 + FAULT_DQUOT_INIT 0x000010000 + FAULT_LOCK_OP 0x000020000 + FAULT_BLKADDR_VALIDITY 0x000040000 + FAULT_BLKADDR_CONSISTENCE 0x000080000 + =========================== =========== mode=%s Control block allocation mode which supports "adaptive" and "lfs". In "lfs" mode, there should be no random writes towards main area. diff --git a/fs/f2fs/checkpoint.c b/fs/f2fs/checkpoint.c index b0597a539fc5..b85820e70f5e 100644 --- a/fs/f2fs/checkpoint.c +++ b/fs/f2fs/checkpoint.c @@ -170,12 +170,9 @@ static bool __is_bitmap_valid(struct f2fs_sb_info *sbi, block_t blkaddr, return exist; } -bool f2fs_is_valid_blkaddr(struct f2fs_sb_info *sbi, +static bool __f2fs_is_valid_blkaddr(struct f2fs_sb_info *sbi, block_t blkaddr, int type) { - if (time_to_inject(sbi, FAULT_BLKADDR)) - return false; - switch (type) { case META_NAT: break; @@ -230,6 +227,20 @@ bool f2fs_is_valid_blkaddr(struct f2fs_sb_info *sbi, return true; } +bool f2fs_is_valid_blkaddr(struct f2fs_sb_info *sbi, + block_t blkaddr, int type) +{ + if (time_to_inject(sbi, FAULT_BLKADDR_VALIDITY)) + return false; + return __f2fs_is_valid_blkaddr(sbi, blkaddr, type); +} + +bool f2fs_is_valid_blkaddr_raw(struct f2fs_sb_info *sbi, + block_t blkaddr, int type) +{ + return __f2fs_is_valid_blkaddr(sbi, blkaddr, type); +} + /* * Readahead CP/NAT/SIT/SSA/POR pages */ diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h index ab710bb6d8b3..4481f68d6418 100644 --- a/fs/f2fs/f2fs.h +++ b/fs/f2fs/f2fs.h @@ -60,7 +60,8 @@ enum { FAULT_SLAB_ALLOC, FAULT_DQUOT_INIT, FAULT_LOCK_OP, - FAULT_BLKADDR, + FAULT_BLKADDR_VALIDITY, + FAULT_BLKADDR_CONSISTENCE, FAULT_MAX, }; @@ -3768,6 +3769,8 @@ struct page *f2fs_get_meta_page_retry(struct f2fs_sb_info *sbi, pgoff_t index); struct page *f2fs_get_tmp_page(struct f2fs_sb_info *sbi, pgoff_t index); bool f2fs_is_valid_blkaddr(struct f2fs_sb_info *sbi, block_t blkaddr, int type); +bool f2fs_is_valid_blkaddr_raw(struct f2fs_sb_info *sbi, + block_t blkaddr, int type); int f2fs_ra_meta_pages(struct f2fs_sb_info *sbi, block_t start, int nrpages, int type, bool sync); void f2fs_ra_meta_pages_cond(struct f2fs_sb_info *sbi, pgoff_t index, diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c index 1ff1c45e1927..25b119cf3499 100644 --- a/fs/f2fs/file.c +++ b/fs/f2fs/file.c @@ -590,9 +590,13 @@ void f2fs_truncate_data_blocks_range(struct dnode_of_data *dn, int count) f2fs_set_data_blkaddr(dn, NULL_ADDR); if (__is_valid_data_blkaddr(blkaddr)) { - if (!f2fs_is_valid_blkaddr(sbi, blkaddr, - DATA_GENERIC_ENHANCE)) + if (time_to_inject(sbi, FAULT_BLKADDR_CONSISTENCE)) + continue; + if (!f2fs_is_valid_blkaddr_raw(sbi, blkaddr, + DATA_GENERIC_ENHANCE)) { + f2fs_handle_error(sbi, ERROR_INVALID_BLKADDR); continue; + } if (compressed_cluster) valid_blocks++; } diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c index d45ab0992ae5..e2c066fbc0fa 100644 --- a/fs/f2fs/super.c +++ b/fs/f2fs/super.c @@ -44,24 +44,25 @@ static struct kmem_cache *f2fs_inode_cachep; #ifdef CONFIG_F2FS_FAULT_INJECTION const char *f2fs_fault_name[FAULT_MAX] = { - [FAULT_KMALLOC] = "kmalloc", - [FAULT_KVMALLOC] = "kvmalloc", - [FAULT_PAGE_ALLOC] = "page alloc", - [FAULT_PAGE_GET] = "page get", - [FAULT_ALLOC_NID] = "alloc nid", - [FAULT_ORPHAN] = "orphan", - [FAULT_BLOCK] = "no more block", - [FAULT_DIR_DEPTH] = "too big dir depth", - [FAULT_EVICT_INODE] = "evict_inode fail", - [FAULT_TRUNCATE] = "truncate fail", - [FAULT_READ_IO] = "read IO error", - [FAULT_CHECKPOINT] = "checkpoint error", - [FAULT_DISCARD] = "discard error", - [FAULT_WRITE_IO] = "write IO error", - [FAULT_SLAB_ALLOC] = "slab alloc", - [FAULT_DQUOT_INIT] = "dquot initialize", - [FAULT_LOCK_OP] = "lock_op", - [FAULT_BLKADDR] = "invalid blkaddr", + [FAULT_KMALLOC] = "kmalloc", + [FAULT_KVMALLOC] = "kvmalloc", + [FAULT_PAGE_ALLOC] = "page alloc", + [FAULT_PAGE_GET] = "page get", + [FAULT_ALLOC_NID] = "alloc nid", + [FAULT_ORPHAN] = "orphan", + [FAULT_BLOCK] = "no more block", + [FAULT_DIR_DEPTH] = "too big dir depth", + [FAULT_EVICT_INODE] = "evict_inode fail", + [FAULT_TRUNCATE] = "truncate fail", + [FAULT_READ_IO] = "read IO error", + [FAULT_CHECKPOINT] = "checkpoint error", + [FAULT_DISCARD] = "discard error", + [FAULT_WRITE_IO] = "write IO error", + [FAULT_SLAB_ALLOC] = "slab alloc", + [FAULT_DQUOT_INIT] = "dquot initialize", + [FAULT_LOCK_OP] = "lock_op", + [FAULT_BLKADDR_VALIDITY] = "invalid blkaddr", + [FAULT_BLKADDR_CONSISTENCE] = "inconsistent blkaddr", }; void f2fs_build_fault_attr(struct f2fs_sb_info *sbi, unsigned int rate, -- cgit v1.2.3 From 968595a93669b6b4f6d1fcf80cf2d97956b6868f Mon Sep 17 00:00:00 2001 From: Magnus Karlsson Date: Mon, 5 Feb 2024 13:35:51 +0100 Subject: xsk: document ability to redirect to any socket bound to the same umem Document the ability to redirect to any socket bound to the same umem. Signed-off-by: Magnus Karlsson Link: https://lore.kernel.org/r/20240205123553.22180-3-magnus.karlsson@gmail.com Signed-off-by: Alexei Starovoitov --- Documentation/networking/af_xdp.rst | 33 +++++++++++++++++++-------------- 1 file changed, 19 insertions(+), 14 deletions(-) (limited to 'Documentation') diff --git a/Documentation/networking/af_xdp.rst b/Documentation/networking/af_xdp.rst index dceeb0d763aa..72da7057e4cf 100644 --- a/Documentation/networking/af_xdp.rst +++ b/Documentation/networking/af_xdp.rst @@ -329,23 +329,24 @@ XDP_SHARED_UMEM option and provide the initial socket's fd in the sxdp_shared_umem_fd field as you registered the UMEM on that socket. These two sockets will now share one and the same UMEM. -There is no need to supply an XDP program like the one in the previous -case where sockets were bound to the same queue id and -device. Instead, use the NIC's packet steering capabilities to steer -the packets to the right queue. In the previous example, there is only -one queue shared among sockets, so the NIC cannot do this steering. It -can only steer between queues. - -In libbpf, you need to use the xsk_socket__create_shared() API as it -takes a reference to a FILL ring and a COMPLETION ring that will be -created for you and bound to the shared UMEM. You can use this -function for all the sockets you create, or you can use it for the -second and following ones and use xsk_socket__create() for the first -one. Both methods yield the same result. +In this case, it is possible to use the NIC's packet steering +capabilities to steer the packets to the right queue. This is not +possible in the previous example as there is only one queue shared +among sockets, so the NIC cannot do this steering as it can only steer +between queues. + +In libxdp (or libbpf prior to version 1.0), you need to use the +xsk_socket__create_shared() API as it takes a reference to a FILL ring +and a COMPLETION ring that will be created for you and bound to the +shared UMEM. You can use this function for all the sockets you create, +or you can use it for the second and following ones and use +xsk_socket__create() for the first one. Both methods yield the same +result. Note that a UMEM can be shared between sockets on the same queue id and device, as well as between queues on the same device and between -devices at the same time. +devices at the same time. It is also possible to redirect to any +socket as long as it is bound to the same umem with XDP_SHARED_UMEM. XDP_USE_NEED_WAKEUP bind flag ----------------------------- @@ -822,6 +823,10 @@ A: The short answer is no, that is not supported at the moment. The switch, or other distribution mechanism, in your NIC to direct traffic to the correct queue id and socket. + Note that if you are using the XDP_SHARED_UMEM option, it is + possible to switch traffic between any socket bound to the same + umem. + Q: My packets are sometimes corrupted. What is wrong? A: Care has to be taken not to feed the same buffer in the UMEM into -- cgit v1.2.3 From d8764d347bd737efec00fae81133ffad0ae084bb Mon Sep 17 00:00:00 2001 From: Michal Simek Date: Wed, 31 Jan 2024 10:17:28 +0100 Subject: dt-bindings: firmware: xilinx: Describe soc-nvmem subnode Describe soc-nvmem subnode as the part of firmware node. The name can't be pure nvmem because dt-schema already defines it as array property that's why different name should be used. Acked-by: Conor Dooley Link: https://lore.kernel.org/r/24fe6adbf2424360618e8f5ca541ebfd8bb0723e.1706692641.git.michal.simek@amd.com Signed-off-by: Michal Simek --- .../bindings/firmware/xilinx/xlnx,zynqmp-firmware.yaml | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) (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 index 7586fbff7ad6..ab8f32c440df 100644 --- a/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.yaml +++ b/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.yaml @@ -62,6 +62,12 @@ properties: interface. type: object + soc-nvmem: + $ref: /schemas/nvmem/xlnx,zynqmp-nvmem.yaml# + description: The ZynqMP MPSoC provides access to the hardware related data + like SOC revision, IDCODE and specific purpose efuses. + type: object + pcap: $ref: /schemas/fpga/xlnx,zynqmp-pcap-fpga.yaml description: The ZynqMP SoC uses the PCAP (Processor Configuration Port) to @@ -110,6 +116,18 @@ examples: firmware { zynqmp_firmware: zynqmp-firmware { #power-domain-cells = <1>; + soc-nvmem { + compatible = "xlnx,zynqmp-nvmem-fw"; + nvmem-layout { + compatible = "fixed-layout"; + #address-cells = <1>; + #size-cells = <1>; + + soc_revision: soc-revision@0 { + reg = <0x0 0x4>; + }; + }; + }; gpio { compatible = "xlnx,zynqmp-gpio-modepin"; gpio-controller; -- cgit v1.2.3 From bb191b14c5d57b46a983b5b531fb82803a9601cc Mon Sep 17 00:00:00 2001 From: Mathieu Othacehe Date: Wed, 24 Jan 2024 08:49:28 +0100 Subject: dt-bindings: arm: fsl: Add phyBOARD-Segin-i.MX93 Add support for phyBOARD-Segin-i.MX93 board. Acked-by: Conor Dooley Signed-off-by: Mathieu Othacehe Reviewed-by: Wadim Egorov Signed-off-by: Shawn Guo --- Documentation/devicetree/bindings/arm/fsl.yaml | 6 ++++++ 1 file changed, 6 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml index 087189e661af..1fe2ff2b1fcc 100644 --- a/Documentation/devicetree/bindings/arm/fsl.yaml +++ b/Documentation/devicetree/bindings/arm/fsl.yaml @@ -1292,6 +1292,12 @@ properties: - const: tq,imx93-tqma9352 # TQ-Systems GmbH i.MX93 TQMa93xxCA/LA SOM - const: fsl,imx93 + - description: PHYTEC phyCORE-i.MX93 SoM based boards + items: + - const: phytec,imx93-phyboard-segin # phyBOARD-Segin with i.MX93 + - const: phytec,imx93-phycore-som # phyCORE-i.MX93 SoM + - const: fsl,imx93 + - description: Variscite VAR-SOM-MX93 based boards items: - const: variscite,var-som-mx93-symphony -- cgit v1.2.3 From 258fb03de7910663b5ee1081097db6c8f0340174 Mon Sep 17 00:00:00 2001 From: Hiago De Franco Date: Wed, 24 Jan 2024 11:13:19 -0300 Subject: dt-bindings: arm: fsl: Add toradex,apalis_imx6q-eval-v1.2 board Add the toradex,apalis_imx6q-eval-v1.2 compatible string for version 1.2 of the Apalis Evaluation Board. Version v1.2 includes the following changes compared to v1.1: - 8-bit MMC connector replaced with a 4-bit uSD connector. - Audio codec NAU88C22 added. - M24C02 EEPROM i2c added. - MIPI-CSI-2 connector directly to the board added. - PCIe switch PEX8605 removed and PCIe now is routed directly to Mini PCIe connector. - Power measurement IC INA219 added. - Replaced DVI with HDMI connector. - Single-channel USB to UART converter replaced with four-channel USB to UART/JTAG. - Temperature sensor TMP75 added. Please note that version v1.0 (which reached EOL) is compatible with v1.1, therefore toradex,apalis_imx6q-eval compatible string should be used for both v1.0 and v1.1. Acked-by: Conor Dooley Signed-off-by: Hiago De Franco Signed-off-by: Shawn Guo --- Documentation/devicetree/bindings/arm/fsl.yaml | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml index 1fe2ff2b1fcc..4b1202f6d0c1 100644 --- a/Documentation/devicetree/bindings/arm/fsl.yaml +++ b/Documentation/devicetree/bindings/arm/fsl.yaml @@ -384,7 +384,8 @@ properties: - toradex,apalis_imx6q-ixora # Apalis iMX6Q/D Module on Ixora Carrier Board - toradex,apalis_imx6q-ixora-v1.1 # Apalis iMX6Q/D Module on Ixora V1.1 Carrier Board - toradex,apalis_imx6q-ixora-v1.2 # Apalis iMX6Q/D Module on Ixora V1.2 Carrier Board - - toradex,apalis_imx6q-eval # Apalis iMX6Q/D Module on Apalis Evaluation Board + - toradex,apalis_imx6q-eval # Apalis iMX6Q/D Module on Apalis Evaluation Board v1.0/v1.1 + - toradex,apalis_imx6q-eval-v1.2 # Apalis iMX6Q/D Module on Apalis Evaluation Board v1.2 - const: toradex,apalis_imx6q - const: fsl,imx6q -- cgit v1.2.3 From 8933d29e7703f6f905bc84186b915b0ab4fe03bb Mon Sep 17 00:00:00 2001 From: Lucas Stach Date: Sat, 3 Feb 2024 10:52:49 -0600 Subject: dt-bindings: display: imx: add binding for i.MX8MP HDMI TX The HDMI TX controller on the i.MX8MP SoC is a Synopsys designware IP core with a little bit of SoC integration around it. Signed-off-by: Lucas Stach Signed-off-by: Adam Ford Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20240203165307.7806-10-aford173@gmail.com Signed-off-by: Neil Armstrong Link: https://patchwork.freedesktop.org/patch/msgid/20240203165307.7806-10-aford173@gmail.com --- .../display/bridge/fsl,imx8mp-hdmi-tx.yaml | 102 +++++++++++++++++++++ 1 file changed, 102 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/bridge/fsl,imx8mp-hdmi-tx.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/bridge/fsl,imx8mp-hdmi-tx.yaml b/Documentation/devicetree/bindings/display/bridge/fsl,imx8mp-hdmi-tx.yaml new file mode 100644 index 000000000000..3791c9f4ebab --- /dev/null +++ b/Documentation/devicetree/bindings/display/bridge/fsl,imx8mp-hdmi-tx.yaml @@ -0,0 +1,102 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/bridge/fsl,imx8mp-hdmi-tx.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Freescale i.MX8MP DWC HDMI TX Encoder + +maintainers: + - Lucas Stach + +description: + The i.MX8MP HDMI transmitter is a Synopsys DesignWare + HDMI 2.0a TX controller IP. + +allOf: + - $ref: /schemas/display/bridge/synopsys,dw-hdmi.yaml# + +properties: + compatible: + enum: + - fsl,imx8mp-hdmi-tx + + reg-io-width: + const: 1 + + clocks: + maxItems: 4 + + clock-names: + items: + - const: iahb + - const: isfr + - const: cec + - const: pix + + power-domains: + maxItems: 1 + + ports: + $ref: /schemas/graph.yaml#/properties/ports + + properties: + port@0: + $ref: /schemas/graph.yaml#/properties/port + description: Parallel RGB input port + + port@1: + $ref: /schemas/graph.yaml#/properties/port + description: HDMI output port + + required: + - port@0 + - port@1 + +required: + - compatible + - reg + - clocks + - clock-names + - interrupts + - power-domains + - ports + +unevaluatedProperties: false + +examples: + - | + #include + #include + #include + + hdmi@32fd8000 { + compatible = "fsl,imx8mp-hdmi-tx"; + reg = <0x32fd8000 0x7eff>; + interrupts = <0 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&clk IMX8MP_CLK_HDMI_APB>, + <&clk IMX8MP_CLK_HDMI_REF_266M>, + <&clk IMX8MP_CLK_32K>, + <&hdmi_tx_phy>; + clock-names = "iahb", "isfr", "cec", "pix"; + power-domains = <&hdmi_blk_ctrl IMX8MP_HDMIBLK_PD_HDMI_TX>; + reg-io-width = <1>; + ports { + #address-cells = <1>; + #size-cells = <0>; + port@0 { + reg = <0>; + + hdmi_tx_from_pvi: endpoint { + remote-endpoint = <&pvi_to_hdmi_tx>; + }; + }; + + port@1 { + reg = <1>; + hdmi_tx_out: endpoint { + remote-endpoint = <&hdmi0_con>; + }; + }; + }; + }; -- cgit v1.2.3 From 73b30950320057ac96957a819612d0a127494022 Mon Sep 17 00:00:00 2001 From: Joao Paulo Goncalves Date: Thu, 25 Jan 2024 11:14:56 +0100 Subject: dt-bindings: arm: fsl: add imx8qm apalis eval v1.2 carrier board Add the toradex,apalis-imx8-eval-v1.2 and toradex,apalis-imx8-v1.1-eval-v1.2 compatible strings for version 1.2 of the Apalis Evaluation Board. Version v1.2 includes the following changes compared to v1.1: - 8-bit MMC connector replaced with a 4-bit uSD connector. - Audio codec NAU88C22 added. - M24C02 EEPROM i2c added. - MIPI-CSI-2 connector directly to the board added. - PCIe switch PEX8605 removed and PCIe now is routed directly to Mini PCIe connector. - Power measurement IC INA219 added. - Replaced DVI with HDMI connector. - Single-channel USB to UART converter replaced with four-channel USB to UART/JTAG. - Temperature sensor TMP75 added. Please note that board version v1.0 (which reached EOL) is compatible with v1.1, therefore toradex,apalis-imx8-eval and toradex,apalis-v1.1-imx8-eval compatible strings should be used for both v1.0 and v1.1. Signed-off-by: Joao Paulo Goncalves Signed-off-by: Francesco Dolcini Acked-by: Conor Dooley Signed-off-by: Shawn Guo --- Documentation/devicetree/bindings/arm/fsl.yaml | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml index 4b1202f6d0c1..b5c30c2c2d0d 100644 --- a/Documentation/devicetree/bindings/arm/fsl.yaml +++ b/Documentation/devicetree/bindings/arm/fsl.yaml @@ -1196,7 +1196,8 @@ properties: - description: i.MX8QM Boards with Toradex Apalis iMX8 Modules items: - enum: - - toradex,apalis-imx8-eval # Apalis iMX8 Module on Apalis Evaluation Board + - toradex,apalis-imx8-eval # Apalis iMX8 Module on Apalis Evaluation V1.0/V1.1 Board + - toradex,apalis-imx8-eval-v1.2 # Apalis iMX8 Module on Apalis Evaluation V1.2 Board - toradex,apalis-imx8-ixora-v1.1 # Apalis iMX8 Module on Ixora V1.1 Carrier Board - const: toradex,apalis-imx8 - const: fsl,imx8qm @@ -1204,7 +1205,8 @@ properties: - description: i.MX8QM Boards with Toradex Apalis iMX8 V1.1 Modules items: - enum: - - toradex,apalis-imx8-v1.1-eval # Apalis iMX8 V1.1 Module on Apalis Eval. Board + - toradex,apalis-imx8-v1.1-eval # Apalis iMX8 V1.1 Module on Apalis Eval. V1.0/V1.1 Board + - toradex,apalis-imx8-v1.1-eval-v1.2 # Apalis iMX8 V1.1 Module on Apalis Eval. V1.2 Board - toradex,apalis-imx8-v1.1-ixora-v1.1 # Apalis iMX8 V1.1 Module on Ixora V1.1 C. Board - toradex,apalis-imx8-v1.1-ixora-v1.2 # Apalis iMX8 V1.1 Module on Ixora V1.2 C. Board - const: toradex,apalis-imx8-v1.1 -- cgit v1.2.3 From 7f7f2b7624d4770978c15c0ecd720dc703f7ace3 Mon Sep 17 00:00:00 2001 From: Hari Prasath Gujulan Elango Date: Mon, 5 Feb 2024 16:22:01 +0530 Subject: dt-bindings: ata: atmel: remove at91 compact flash documentation The compatible "at91rm9200-cf" is not used by any driver, hence remove the corresponding documentation. Signed-off-by: Hari Prasath Gujulan Elango Acked-by: Rob Herring Acked-by: Nicolas Ferre [cassel: add missing space in commit log] Signed-off-by: Niklas Cassel --- .../devicetree/bindings/ata/atmel-at91_cf.txt | 19 ------------------- 1 file changed, 19 deletions(-) delete mode 100644 Documentation/devicetree/bindings/ata/atmel-at91_cf.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/ata/atmel-at91_cf.txt b/Documentation/devicetree/bindings/ata/atmel-at91_cf.txt deleted file mode 100644 index c1d22b3ae134..000000000000 --- a/Documentation/devicetree/bindings/ata/atmel-at91_cf.txt +++ /dev/null @@ -1,19 +0,0 @@ -Atmel AT91RM9200 CompactFlash - -Required properties: -- compatible : "atmel,at91rm9200-cf". -- reg : should specify localbus address and size used. -- gpios : specifies the gpio pins to control the CF device. Detect - and reset gpio's are mandatory while irq and vcc gpio's are - optional and may be set to 0 if not present. - -Example: -compact-flash@50000000 { - compatible = "atmel,at91rm9200-cf"; - reg = <0x50000000 0x30000000>; - gpios = <&pioC 13 0 /* irq */ - &pioC 15 0 /* detect */ - 0 /* vcc */ - &pioC 5 0 /* reset */ - >; -}; -- cgit v1.2.3 From 918327e9b7ffb45321cbb4b9b86b58ec555fe6b3 Mon Sep 17 00:00:00 2001 From: Kees Cook Date: Sun, 28 Jan 2024 10:45:29 -0800 Subject: ubsan: Remove CONFIG_UBSAN_SANITIZE_ALL For simplicity in splitting out UBSan options into separate rules, remove CONFIG_UBSAN_SANITIZE_ALL, effectively defaulting to "y", which is how it is generally used anyway. (There are no ":= y" cases beyond where a specific file is enabled when a top-level ":= n" is in effect.) Cc: Andrey Konovalov Cc: Marco Elver Cc: linux-doc@vger.kernel.org Cc: linux-kbuild@vger.kernel.org Signed-off-by: Kees Cook --- Documentation/dev-tools/ubsan.rst | 28 ++++++++-------------------- arch/arm/Kconfig | 2 +- arch/arm64/Kconfig | 2 +- arch/mips/Kconfig | 2 +- arch/parisc/Kconfig | 2 +- arch/powerpc/Kconfig | 2 +- arch/riscv/Kconfig | 2 +- arch/s390/Kconfig | 2 +- arch/x86/Kconfig | 2 +- lib/Kconfig.ubsan | 13 +------------ scripts/Makefile.lib | 2 +- 11 files changed, 18 insertions(+), 41 deletions(-) (limited to 'Documentation') diff --git a/Documentation/dev-tools/ubsan.rst b/Documentation/dev-tools/ubsan.rst index 2de7c63415da..e3591f8e9d5b 100644 --- a/Documentation/dev-tools/ubsan.rst +++ b/Documentation/dev-tools/ubsan.rst @@ -49,34 +49,22 @@ Report example Usage ----- -To enable UBSAN configure kernel with:: +To enable UBSAN, configure the kernel with:: - CONFIG_UBSAN=y + CONFIG_UBSAN=y -and to check the entire kernel:: - - CONFIG_UBSAN_SANITIZE_ALL=y - -To enable instrumentation for specific files or directories, add a line -similar to the following to the respective kernel Makefile: - -- For a single file (e.g. main.o):: - - UBSAN_SANITIZE_main.o := y - -- For all files in one directory:: - - UBSAN_SANITIZE := y - -To exclude files from being instrumented even if -``CONFIG_UBSAN_SANITIZE_ALL=y``, use:: +To exclude files from being instrumented use:: UBSAN_SANITIZE_main.o := n -and:: +and to exclude all targets in one directory use:: UBSAN_SANITIZE := n +When disabled for all targets, specific files can be enabled using:: + + UBSAN_SANITIZE_main.o := y + Detection of unaligned accesses controlled through the separate option - CONFIG_UBSAN_ALIGNMENT. It's off by default on architectures that support unaligned accesses (CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y). One could diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 0af6709570d1..287e62522064 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -29,7 +29,7 @@ config ARM select ARCH_HAVE_NMI_SAFE_CMPXCHG if CPU_V7 || CPU_V7M || CPU_V6K select ARCH_HAS_GCOV_PROFILE_ALL select ARCH_KEEP_MEMBLOCK - select ARCH_HAS_UBSAN_SANITIZE_ALL + select ARCH_HAS_UBSAN select ARCH_MIGHT_HAVE_PC_PARPORT select ARCH_OPTIONAL_KERNEL_RWX if ARCH_HAS_STRICT_KERNEL_RWX select ARCH_OPTIONAL_KERNEL_RWX_DEFAULT if CPU_V7 diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig index aa7c1d435139..78533d1b7f35 100644 --- a/arch/arm64/Kconfig +++ b/arch/arm64/Kconfig @@ -107,7 +107,7 @@ config ARM64 select ARCH_WANT_LD_ORPHAN_WARN select ARCH_WANTS_NO_INSTR select ARCH_WANTS_THP_SWAP if ARM64_4K_PAGES - select ARCH_HAS_UBSAN_SANITIZE_ALL + select ARCH_HAS_UBSAN select ARM_AMBA select ARM_ARCH_TIMER select ARM_GIC diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig index 797ae590ebdb..9750ce3e40d5 100644 --- a/arch/mips/Kconfig +++ b/arch/mips/Kconfig @@ -14,7 +14,7 @@ config MIPS select ARCH_HAS_STRNCPY_FROM_USER select ARCH_HAS_STRNLEN_USER select ARCH_HAS_TICK_BROADCAST if GENERIC_CLOCKEVENTS_BROADCAST - select ARCH_HAS_UBSAN_SANITIZE_ALL + select ARCH_HAS_UBSAN select ARCH_HAS_GCOV_PROFILE_ALL select ARCH_KEEP_MEMBLOCK select ARCH_USE_BUILTIN_BSWAP diff --git a/arch/parisc/Kconfig b/arch/parisc/Kconfig index d14ccc948a29..dbc9027ea2f4 100644 --- a/arch/parisc/Kconfig +++ b/arch/parisc/Kconfig @@ -12,7 +12,7 @@ config PARISC select ARCH_HAS_ELF_RANDOMIZE select ARCH_HAS_STRICT_KERNEL_RWX select ARCH_HAS_STRICT_MODULE_RWX - select ARCH_HAS_UBSAN_SANITIZE_ALL + select ARCH_HAS_UBSAN select ARCH_HAS_PTE_SPECIAL select ARCH_NO_SG_CHAIN select ARCH_SUPPORTS_HUGETLBFS if PA20 diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig index b9fc064d38d2..2065973e09d2 100644 --- a/arch/powerpc/Kconfig +++ b/arch/powerpc/Kconfig @@ -154,7 +154,7 @@ config PPC select ARCH_HAS_SYSCALL_WRAPPER if !SPU_BASE && !COMPAT select ARCH_HAS_TICK_BROADCAST if GENERIC_CLOCKEVENTS_BROADCAST select ARCH_HAS_UACCESS_FLUSHCACHE - select ARCH_HAS_UBSAN_SANITIZE_ALL + select ARCH_HAS_UBSAN select ARCH_HAVE_NMI_SAFE_CMPXCHG select ARCH_KEEP_MEMBLOCK select ARCH_MHP_MEMMAP_ON_MEMORY_ENABLE if PPC_RADIX_MMU diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig index bffbd869a068..d824d113a02d 100644 --- a/arch/riscv/Kconfig +++ b/arch/riscv/Kconfig @@ -37,7 +37,7 @@ config RISCV select ARCH_HAS_STRICT_MODULE_RWX if MMU && !XIP_KERNEL select ARCH_HAS_SYSCALL_WRAPPER select ARCH_HAS_TICK_BROADCAST if GENERIC_CLOCKEVENTS_BROADCAST - select ARCH_HAS_UBSAN_SANITIZE_ALL + select ARCH_HAS_UBSAN select ARCH_HAS_VDSO_DATA select ARCH_KEEP_MEMBLOCK if ACPI select ARCH_OPTIONAL_KERNEL_RWX if ARCH_HAS_STRICT_KERNEL_RWX diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig index fe565f3a3a91..97dd25521617 100644 --- a/arch/s390/Kconfig +++ b/arch/s390/Kconfig @@ -82,7 +82,7 @@ config S390 select ARCH_HAS_STRICT_KERNEL_RWX select ARCH_HAS_STRICT_MODULE_RWX select ARCH_HAS_SYSCALL_WRAPPER - select ARCH_HAS_UBSAN_SANITIZE_ALL + select ARCH_HAS_UBSAN select ARCH_HAS_VDSO_DATA select ARCH_HAVE_NMI_SAFE_CMPXCHG select ARCH_INLINE_READ_LOCK diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index 5edec175b9bf..1c4c326a3640 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -100,7 +100,7 @@ config X86 select ARCH_HAS_STRICT_MODULE_RWX select ARCH_HAS_SYNC_CORE_BEFORE_USERMODE select ARCH_HAS_SYSCALL_WRAPPER - select ARCH_HAS_UBSAN_SANITIZE_ALL + select ARCH_HAS_UBSAN select ARCH_HAS_DEBUG_WX select ARCH_HAS_ZONE_DMA_SET if EXPERT select ARCH_HAVE_NMI_SAFE_CMPXCHG diff --git a/lib/Kconfig.ubsan b/lib/Kconfig.ubsan index 59e21bfec188..56d7653f4941 100644 --- a/lib/Kconfig.ubsan +++ b/lib/Kconfig.ubsan @@ -1,5 +1,5 @@ # SPDX-License-Identifier: GPL-2.0-only -config ARCH_HAS_UBSAN_SANITIZE_ALL +config ARCH_HAS_UBSAN bool menuconfig UBSAN @@ -142,17 +142,6 @@ config UBSAN_ALIGNMENT Enabling this option on architectures that support unaligned accesses may produce a lot of false positives. -config UBSAN_SANITIZE_ALL - bool "Enable instrumentation for the entire kernel" - depends on ARCH_HAS_UBSAN_SANITIZE_ALL - default y - help - This option activates instrumentation for the entire kernel. - If you don't enable this option, you have to explicitly specify - UBSAN_SANITIZE := y for the files/directories you want to check for UB. - Enabling this option will get kernel image size increased - significantly. - config TEST_UBSAN tristate "Module for testing for undefined behavior detection" depends on m diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib index cd5b181060f1..52efc520ae4f 100644 --- a/scripts/Makefile.lib +++ b/scripts/Makefile.lib @@ -175,7 +175,7 @@ endif ifeq ($(CONFIG_UBSAN),y) _c_flags += $(if $(patsubst n%,, \ - $(UBSAN_SANITIZE_$(basetarget).o)$(UBSAN_SANITIZE)$(CONFIG_UBSAN_SANITIZE_ALL)), \ + $(UBSAN_SANITIZE_$(basetarget).o)$(UBSAN_SANITIZE)y), \ $(CFLAGS_UBSAN)) endif -- cgit v1.2.3 From e9d58978dc977dd185e49d0a1a839b0d04a00d99 Mon Sep 17 00:00:00 2001 From: Hugo Villeneuve Date: Thu, 25 Jan 2024 11:59:34 -0500 Subject: dt-bindings: arm: fsl: remove redundant company name Company name in compatible description appears twice, which is not really helpful, so remove it from product name. The board is a prototype developed by my company and we are still at the prototype stage, so there is zero ABI impact. Fixes: bb405e8b5336 ("dt-bindings: arm: fsl: add RVE gateway board") Signed-off-by: Hugo Villeneuve Acked-by: Krzysztof Kozlowski Signed-off-by: Shawn Guo --- Documentation/devicetree/bindings/arm/fsl.yaml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml index b5c30c2c2d0d..39378879777b 100644 --- a/Documentation/devicetree/bindings/arm/fsl.yaml +++ b/Documentation/devicetree/bindings/arm/fsl.yaml @@ -1028,7 +1028,7 @@ properties: items: - enum: - dimonoff,gateway-evk # i.MX8MN Dimonoff Gateway EVK Board - - rve,rve-gateway # i.MX8MN RVE Gateway Board + - rve,gateway # i.MX8MN RVE Gateway Board - variscite,var-som-mx8mn-symphony - const: variscite,var-som-mx8mn - const: fsl,imx8mn -- cgit v1.2.3 From 240fd405528bbf7fafa0559202ca7aa524c9cd96 Mon Sep 17 00:00:00 2001 From: Aahil Awatramani Date: Fri, 2 Feb 2024 17:58:58 +0000 Subject: bonding: Add independent control state machine Add support for the independent control state machine per IEEE 802.1AX-2008 5.4.15 in addition to the existing implementation of the coupled control state machine. Introduces two new states, AD_MUX_COLLECTING and AD_MUX_DISTRIBUTING in the LACP MUX state machine for separated handling of an initial Collecting state before the Collecting and Distributing state. This enables a port to be in a state where it can receive incoming packets while not still distributing. This is useful for reducing packet loss when a port begins distributing before its partner is able to collect. Added new functions such as bond_set_slave_tx_disabled_flags and bond_set_slave_rx_enabled_flags to precisely manage the port's collecting and distributing states. Previously, there was no dedicated method to disable TX while keeping RX enabled, which this patch addresses. Note that the regular flow process in the kernel's bonding driver remains unaffected by this patch. The extension requires explicit opt-in by the user (in order to ensure no disruptions for existing setups) via netlink support using the new bonding parameter coupled_control. The default value for coupled_control is set to 1 so as to preserve existing behaviour. Signed-off-by: Aahil Awatramani Reviewed-by: Hangbin Liu Link: https://lore.kernel.org/r/20240202175858.1573852-1-aahila@google.com Signed-off-by: Paolo Abeni --- Documentation/networking/bonding.rst | 12 +++ drivers/net/bonding/bond_3ad.c | 157 +++++++++++++++++++++++++++++++++-- drivers/net/bonding/bond_main.c | 1 + drivers/net/bonding/bond_netlink.c | 16 ++++ drivers/net/bonding/bond_options.c | 28 ++++++- include/net/bond_3ad.h | 2 + include/net/bond_options.h | 1 + include/net/bonding.h | 23 +++++ include/uapi/linux/if_link.h | 1 + tools/include/uapi/linux/if_link.h | 1 + 10 files changed, 234 insertions(+), 8 deletions(-) (limited to 'Documentation') diff --git a/Documentation/networking/bonding.rst b/Documentation/networking/bonding.rst index f7a73421eb76..e774b48de9f5 100644 --- a/Documentation/networking/bonding.rst +++ b/Documentation/networking/bonding.rst @@ -444,6 +444,18 @@ arp_missed_max The default value is 2, and the allowable range is 1 - 255. +coupled_control + + Specifies whether the LACP state machine's MUX in the 802.3ad mode + should have separate Collecting and Distributing states. + + This is by implementing the independent control state machine per + IEEE 802.1AX-2008 5.4.15 in addition to the existing coupled control + state machine. + + The default value is 1. This setting does not separate the Collecting + and Distributing states, maintaining the bond in coupled control. + downdelay Specifies the time, in milliseconds, to wait before disabling diff --git a/drivers/net/bonding/bond_3ad.c b/drivers/net/bonding/bond_3ad.c index c99ffe6c683a..f2942e8c6c91 100644 --- a/drivers/net/bonding/bond_3ad.c +++ b/drivers/net/bonding/bond_3ad.c @@ -106,6 +106,9 @@ static void ad_agg_selection_logic(struct aggregator *aggregator, static void ad_clear_agg(struct aggregator *aggregator); static void ad_initialize_agg(struct aggregator *aggregator); static void ad_initialize_port(struct port *port, int lacp_fast); +static void ad_enable_collecting(struct port *port); +static void ad_disable_distributing(struct port *port, + bool *update_slave_arr); static void ad_enable_collecting_distributing(struct port *port, bool *update_slave_arr); static void ad_disable_collecting_distributing(struct port *port, @@ -171,9 +174,38 @@ static inline int __agg_has_partner(struct aggregator *agg) return !is_zero_ether_addr(agg->partner_system.mac_addr_value); } +/** + * __disable_distributing_port - disable the port's slave for distributing. + * Port will still be able to collect. + * @port: the port we're looking at + * + * This will disable only distributing on the port's slave. + */ +static void __disable_distributing_port(struct port *port) +{ + bond_set_slave_tx_disabled_flags(port->slave, BOND_SLAVE_NOTIFY_LATER); +} + +/** + * __enable_collecting_port - enable the port's slave for collecting, + * if it's up + * @port: the port we're looking at + * + * This will enable only collecting on the port's slave. + */ +static void __enable_collecting_port(struct port *port) +{ + struct slave *slave = port->slave; + + if (slave->link == BOND_LINK_UP && bond_slave_is_up(slave)) + bond_set_slave_rx_enabled_flags(slave, BOND_SLAVE_NOTIFY_LATER); +} + /** * __disable_port - disable the port's slave * @port: the port we're looking at + * + * This will disable both collecting and distributing on the port's slave. */ static inline void __disable_port(struct port *port) { @@ -183,6 +215,8 @@ static inline void __disable_port(struct port *port) /** * __enable_port - enable the port's slave, if it's up * @port: the port we're looking at + * + * This will enable both collecting and distributing on the port's slave. */ static inline void __enable_port(struct port *port) { @@ -193,10 +227,27 @@ static inline void __enable_port(struct port *port) } /** - * __port_is_enabled - check if the port's slave is in active state + * __port_move_to_attached_state - check if port should transition back to attached + * state. + * @port: the port we're looking at + */ +static bool __port_move_to_attached_state(struct port *port) +{ + if (!(port->sm_vars & AD_PORT_SELECTED) || + (port->sm_vars & AD_PORT_STANDBY) || + !(port->partner_oper.port_state & LACP_STATE_SYNCHRONIZATION) || + !(port->actor_oper_port_state & LACP_STATE_SYNCHRONIZATION)) + port->sm_mux_state = AD_MUX_ATTACHED; + + return port->sm_mux_state == AD_MUX_ATTACHED; +} + +/** + * __port_is_collecting_distributing - check if the port's slave is in the + * combined collecting/distributing state * @port: the port we're looking at */ -static inline int __port_is_enabled(struct port *port) +static int __port_is_collecting_distributing(struct port *port) { return bond_is_active_slave(port->slave); } @@ -942,6 +993,7 @@ static int ad_marker_send(struct port *port, struct bond_marker *marker) */ static void ad_mux_machine(struct port *port, bool *update_slave_arr) { + struct bonding *bond = __get_bond_by_port(port); mux_states_t last_state; /* keep current State Machine state to compare later if it was @@ -999,9 +1051,13 @@ static void ad_mux_machine(struct port *port, bool *update_slave_arr) if ((port->sm_vars & AD_PORT_SELECTED) && (port->partner_oper.port_state & LACP_STATE_SYNCHRONIZATION) && !__check_agg_selection_timer(port)) { - if (port->aggregator->is_active) - port->sm_mux_state = - AD_MUX_COLLECTING_DISTRIBUTING; + if (port->aggregator->is_active) { + int state = AD_MUX_COLLECTING_DISTRIBUTING; + + if (!bond->params.coupled_control) + state = AD_MUX_COLLECTING; + port->sm_mux_state = state; + } } else if (!(port->sm_vars & AD_PORT_SELECTED) || (port->sm_vars & AD_PORT_STANDBY)) { /* if UNSELECTED or STANDBY */ @@ -1019,11 +1075,45 @@ static void ad_mux_machine(struct port *port, bool *update_slave_arr) } break; case AD_MUX_COLLECTING_DISTRIBUTING: + if (!__port_move_to_attached_state(port)) { + /* if port state hasn't changed make + * sure that a collecting distributing + * port in an active aggregator is enabled + */ + if (port->aggregator->is_active && + !__port_is_collecting_distributing(port)) { + __enable_port(port); + *update_slave_arr = true; + } + } + break; + case AD_MUX_COLLECTING: + if (!__port_move_to_attached_state(port)) { + if ((port->sm_vars & AD_PORT_SELECTED) && + (port->partner_oper.port_state & LACP_STATE_SYNCHRONIZATION) && + (port->partner_oper.port_state & LACP_STATE_COLLECTING)) { + port->sm_mux_state = AD_MUX_DISTRIBUTING; + } else { + /* If port state hasn't changed, make sure that a collecting + * port is enabled for an active aggregator. + */ + struct slave *slave = port->slave; + + if (port->aggregator->is_active && + bond_is_slave_rx_disabled(slave)) { + ad_enable_collecting(port); + *update_slave_arr = true; + } + } + } + break; + case AD_MUX_DISTRIBUTING: if (!(port->sm_vars & AD_PORT_SELECTED) || (port->sm_vars & AD_PORT_STANDBY) || + !(port->partner_oper.port_state & LACP_STATE_COLLECTING) || !(port->partner_oper.port_state & LACP_STATE_SYNCHRONIZATION) || !(port->actor_oper_port_state & LACP_STATE_SYNCHRONIZATION)) { - port->sm_mux_state = AD_MUX_ATTACHED; + port->sm_mux_state = AD_MUX_COLLECTING; } else { /* if port state hasn't changed make * sure that a collecting distributing @@ -1031,7 +1121,7 @@ static void ad_mux_machine(struct port *port, bool *update_slave_arr) */ if (port->aggregator && port->aggregator->is_active && - !__port_is_enabled(port)) { + !__port_is_collecting_distributing(port)) { __enable_port(port); *update_slave_arr = true; } @@ -1082,6 +1172,20 @@ static void ad_mux_machine(struct port *port, bool *update_slave_arr) update_slave_arr); port->ntt = true; break; + case AD_MUX_COLLECTING: + port->actor_oper_port_state |= LACP_STATE_COLLECTING; + port->actor_oper_port_state &= ~LACP_STATE_DISTRIBUTING; + port->actor_oper_port_state |= LACP_STATE_SYNCHRONIZATION; + ad_enable_collecting(port); + ad_disable_distributing(port, update_slave_arr); + port->ntt = true; + break; + case AD_MUX_DISTRIBUTING: + port->actor_oper_port_state |= LACP_STATE_DISTRIBUTING; + port->actor_oper_port_state |= LACP_STATE_SYNCHRONIZATION; + ad_enable_collecting_distributing(port, + update_slave_arr); + break; default: break; } @@ -1906,6 +2010,45 @@ static void ad_initialize_port(struct port *port, int lacp_fast) } } +/** + * ad_enable_collecting - enable a port's receive + * @port: the port we're looking at + * + * Enable @port if it's in an active aggregator + */ +static void ad_enable_collecting(struct port *port) +{ + if (port->aggregator->is_active) { + struct slave *slave = port->slave; + + slave_dbg(slave->bond->dev, slave->dev, + "Enabling collecting on port %d (LAG %d)\n", + port->actor_port_number, + port->aggregator->aggregator_identifier); + __enable_collecting_port(port); + } +} + +/** + * ad_disable_distributing - disable a port's transmit + * @port: the port we're looking at + * @update_slave_arr: Does slave array need update? + */ +static void ad_disable_distributing(struct port *port, bool *update_slave_arr) +{ + if (port->aggregator && + !MAC_ADDRESS_EQUAL(&port->aggregator->partner_system, + &(null_mac_addr))) { + slave_dbg(port->slave->bond->dev, port->slave->dev, + "Disabling distributing on port %d (LAG %d)\n", + port->actor_port_number, + port->aggregator->aggregator_identifier); + __disable_distributing_port(port); + /* Slave array needs an update */ + *update_slave_arr = true; + } +} + /** * ad_enable_collecting_distributing - enable a port's transmit/receive * @port: the port we're looking at diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c index 4e0600c7b050..ae9d32c0faf4 100644 --- a/drivers/net/bonding/bond_main.c +++ b/drivers/net/bonding/bond_main.c @@ -6306,6 +6306,7 @@ static int __init bond_check_params(struct bond_params *params) params->ad_actor_sys_prio = ad_actor_sys_prio; eth_zero_addr(params->ad_actor_system); params->ad_user_port_key = ad_user_port_key; + params->coupled_control = 1; if (packets_per_slave > 0) { params->reciprocal_packets_per_slave = reciprocal_value(packets_per_slave); diff --git a/drivers/net/bonding/bond_netlink.c b/drivers/net/bonding/bond_netlink.c index cfa74cf8bb1a..29b4c3d1b9b6 100644 --- a/drivers/net/bonding/bond_netlink.c +++ b/drivers/net/bonding/bond_netlink.c @@ -122,6 +122,7 @@ static const struct nla_policy bond_policy[IFLA_BOND_MAX + 1] = { [IFLA_BOND_PEER_NOTIF_DELAY] = NLA_POLICY_FULL_RANGE(NLA_U32, &delay_range), [IFLA_BOND_MISSED_MAX] = { .type = NLA_U8 }, [IFLA_BOND_NS_IP6_TARGET] = { .type = NLA_NESTED }, + [IFLA_BOND_COUPLED_CONTROL] = { .type = NLA_U8 }, }; static const struct nla_policy bond_slave_policy[IFLA_BOND_SLAVE_MAX + 1] = { @@ -549,6 +550,16 @@ static int bond_changelink(struct net_device *bond_dev, struct nlattr *tb[], return err; } + if (data[IFLA_BOND_COUPLED_CONTROL]) { + int coupled_control = nla_get_u8(data[IFLA_BOND_COUPLED_CONTROL]); + + bond_opt_initval(&newval, coupled_control); + err = __bond_opt_set(bond, BOND_OPT_COUPLED_CONTROL, &newval, + data[IFLA_BOND_COUPLED_CONTROL], extack); + if (err) + return err; + } + return 0; } @@ -615,6 +626,7 @@ static size_t bond_get_size(const struct net_device *bond_dev) /* IFLA_BOND_NS_IP6_TARGET */ nla_total_size(sizeof(struct nlattr)) + nla_total_size(sizeof(struct in6_addr)) * BOND_MAX_NS_TARGETS + + nla_total_size(sizeof(u8)) + /* IFLA_BOND_COUPLED_CONTROL */ 0; } @@ -774,6 +786,10 @@ static int bond_fill_info(struct sk_buff *skb, bond->params.missed_max)) goto nla_put_failure; + if (nla_put_u8(skb, IFLA_BOND_COUPLED_CONTROL, + bond->params.coupled_control)) + goto nla_put_failure; + if (BOND_MODE(bond) == BOND_MODE_8023AD) { struct ad_info info; diff --git a/drivers/net/bonding/bond_options.c b/drivers/net/bonding/bond_options.c index f3f27f0bd2a6..4cdbc7e084f4 100644 --- a/drivers/net/bonding/bond_options.c +++ b/drivers/net/bonding/bond_options.c @@ -84,7 +84,8 @@ static int bond_option_ad_user_port_key_set(struct bonding *bond, const struct bond_opt_value *newval); static int bond_option_missed_max_set(struct bonding *bond, const struct bond_opt_value *newval); - +static int bond_option_coupled_control_set(struct bonding *bond, + const struct bond_opt_value *newval); static const struct bond_opt_value bond_mode_tbl[] = { { "balance-rr", BOND_MODE_ROUNDROBIN, BOND_VALFLAG_DEFAULT}, @@ -232,6 +233,12 @@ static const struct bond_opt_value bond_missed_max_tbl[] = { { NULL, -1, 0}, }; +static const struct bond_opt_value bond_coupled_control_tbl[] = { + { "on", 1, BOND_VALFLAG_DEFAULT}, + { "off", 0, 0}, + { NULL, -1, 0}, +}; + static const struct bond_option bond_opts[BOND_OPT_LAST] = { [BOND_OPT_MODE] = { .id = BOND_OPT_MODE, @@ -496,6 +503,15 @@ static const struct bond_option bond_opts[BOND_OPT_LAST] = { .desc = "Delay between each peer notification on failover event, in milliseconds", .values = bond_peer_notif_delay_tbl, .set = bond_option_peer_notif_delay_set + }, + [BOND_OPT_COUPLED_CONTROL] = { + .id = BOND_OPT_COUPLED_CONTROL, + .name = "coupled_control", + .desc = "Opt into using coupled control MUX for LACP states", + .unsuppmodes = BOND_MODE_ALL_EX(BIT(BOND_MODE_8023AD)), + .flags = BOND_OPTFLAG_IFDOWN, + .values = bond_coupled_control_tbl, + .set = bond_option_coupled_control_set, } }; @@ -1692,3 +1708,13 @@ static int bond_option_ad_user_port_key_set(struct bonding *bond, bond->params.ad_user_port_key = newval->value; return 0; } + +static int bond_option_coupled_control_set(struct bonding *bond, + const struct bond_opt_value *newval) +{ + netdev_info(bond->dev, "Setting coupled_control to %s (%llu)\n", + newval->string, newval->value); + + bond->params.coupled_control = newval->value; + return 0; +} diff --git a/include/net/bond_3ad.h b/include/net/bond_3ad.h index c5e57c6bd873..9ce5ac2bfbad 100644 --- a/include/net/bond_3ad.h +++ b/include/net/bond_3ad.h @@ -54,6 +54,8 @@ typedef enum { AD_MUX_DETACHED, /* mux machine */ AD_MUX_WAITING, /* mux machine */ AD_MUX_ATTACHED, /* mux machine */ + AD_MUX_COLLECTING, /* mux machine */ + AD_MUX_DISTRIBUTING, /* mux machine */ AD_MUX_COLLECTING_DISTRIBUTING /* mux machine */ } mux_states_t; diff --git a/include/net/bond_options.h b/include/net/bond_options.h index 69292ecc0325..473a0147769e 100644 --- a/include/net/bond_options.h +++ b/include/net/bond_options.h @@ -76,6 +76,7 @@ enum { BOND_OPT_MISSED_MAX, BOND_OPT_NS_TARGETS, BOND_OPT_PRIO, + BOND_OPT_COUPLED_CONTROL, BOND_OPT_LAST }; diff --git a/include/net/bonding.h b/include/net/bonding.h index 5b8b1b644a2d..b61fb1aa3a56 100644 --- a/include/net/bonding.h +++ b/include/net/bonding.h @@ -148,6 +148,7 @@ struct bond_params { #if IS_ENABLED(CONFIG_IPV6) struct in6_addr ns_targets[BOND_MAX_NS_TARGETS]; #endif + int coupled_control; /* 2 bytes of padding : see ether_addr_equal_64bits() */ u8 ad_actor_system[ETH_ALEN + 2]; @@ -167,6 +168,7 @@ struct slave { u8 backup:1, /* indicates backup slave. Value corresponds with BOND_STATE_ACTIVE and BOND_STATE_BACKUP */ inactive:1, /* indicates inactive slave */ + rx_disabled:1, /* indicates whether slave's Rx is disabled */ should_notify:1, /* indicates whether the state changed */ should_notify_link:1; /* indicates whether the link changed */ u8 duplex; @@ -568,6 +570,14 @@ static inline void bond_set_slave_inactive_flags(struct slave *slave, bond_set_slave_state(slave, BOND_STATE_BACKUP, notify); if (!slave->bond->params.all_slaves_active) slave->inactive = 1; + if (BOND_MODE(slave->bond) == BOND_MODE_8023AD) + slave->rx_disabled = 1; +} + +static inline void bond_set_slave_tx_disabled_flags(struct slave *slave, + bool notify) +{ + bond_set_slave_state(slave, BOND_STATE_BACKUP, notify); } static inline void bond_set_slave_active_flags(struct slave *slave, @@ -575,6 +585,14 @@ static inline void bond_set_slave_active_flags(struct slave *slave, { bond_set_slave_state(slave, BOND_STATE_ACTIVE, notify); slave->inactive = 0; + if (BOND_MODE(slave->bond) == BOND_MODE_8023AD) + slave->rx_disabled = 0; +} + +static inline void bond_set_slave_rx_enabled_flags(struct slave *slave, + bool notify) +{ + slave->rx_disabled = 0; } static inline bool bond_is_slave_inactive(struct slave *slave) @@ -582,6 +600,11 @@ static inline bool bond_is_slave_inactive(struct slave *slave) return slave->inactive; } +static inline bool bond_is_slave_rx_disabled(struct slave *slave) +{ + return slave->rx_disabled; +} + static inline void bond_propose_link_state(struct slave *slave, int state) { slave->link_new_state = state; diff --git a/include/uapi/linux/if_link.h b/include/uapi/linux/if_link.h index ab9bcff96e4d..ffa637b38c93 100644 --- a/include/uapi/linux/if_link.h +++ b/include/uapi/linux/if_link.h @@ -1505,6 +1505,7 @@ enum { IFLA_BOND_AD_LACP_ACTIVE, IFLA_BOND_MISSED_MAX, IFLA_BOND_NS_IP6_TARGET, + IFLA_BOND_COUPLED_CONTROL, __IFLA_BOND_MAX, }; diff --git a/tools/include/uapi/linux/if_link.h b/tools/include/uapi/linux/if_link.h index a0aa05a28cf2..f0d71b2a3f1e 100644 --- a/tools/include/uapi/linux/if_link.h +++ b/tools/include/uapi/linux/if_link.h @@ -974,6 +974,7 @@ enum { IFLA_BOND_AD_LACP_ACTIVE, IFLA_BOND_MISSED_MAX, IFLA_BOND_NS_IP6_TARGET, + IFLA_BOND_COUPLED_CONTROL, __IFLA_BOND_MAX, }; -- cgit v1.2.3 From b83e2a91426ae4ee545e93a7dd61f03c3b5a417c Mon Sep 17 00:00:00 2001 From: Sakari Ailus Date: Sun, 4 Feb 2024 23:50:12 +0200 Subject: Revert "media: ov08x40: Reduce start streaming time" This reverts commit feb8831be9d468ee961289c6a275536a1ee0011c. Commit feb8831be9d468ee961289c6a275536a1ee0011c contained unintentional changes to Documentation/devicetree/bindings/media/video-interfaces.yaml and arch/arm/boot/dts/ti/omap/omap3-n9.dts. Revert the entire patch. Signed-off-by: Sakari Ailus Reviewed-by: Laurent Pinchart Signed-off-by: Hans Verkuil --- .../bindings/media/video-interfaces.yaml | 2 +- arch/arm/boot/dts/ti/omap/omap3-n9.dts | 2 +- drivers/media/i2c/ov08x40.c | 1209 +++++++++++++++++++- 3 files changed, 1154 insertions(+), 59 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/media/video-interfaces.yaml b/Documentation/devicetree/bindings/media/video-interfaces.yaml index ea511f2fed98..26e3e7d7c67b 100644 --- a/Documentation/devicetree/bindings/media/video-interfaces.yaml +++ b/Documentation/devicetree/bindings/media/video-interfaces.yaml @@ -190,7 +190,7 @@ properties: Allow MIPI CSI-2 non-continuous clock mode. link-frequencies: - $ref: /schemas/types.yaml#/definitions/uint32-array + $ref: /schemas/types.yaml#/definitions/uint64-array description: Allowed data bus frequencies. For MIPI CSI-2, for instance, this is the actual frequency of the bus, not bits per clock per lane value. An array diff --git a/arch/arm/boot/dts/ti/omap/omap3-n9.dts b/arch/arm/boot/dts/ti/omap/omap3-n9.dts index 728a8fcf25b3..a3cf3f443785 100644 --- a/arch/arm/boot/dts/ti/omap/omap3-n9.dts +++ b/arch/arm/boot/dts/ti/omap/omap3-n9.dts @@ -26,7 +26,7 @@ flash-leds = <&as3645a_flash &as3645a_indicator>; port { smia_1_1: endpoint { - link-frequencies = /bits/ 32 <199200000 210000000 499200000>; + link-frequencies = /bits/ 64 <199200000 210000000 499200000>; clock-lanes = <0>; data-lanes = <1 2>; remote-endpoint = <&csi2a_ep>; diff --git a/drivers/media/i2c/ov08x40.c b/drivers/media/i2c/ov08x40.c index 48df077522ad..010a6017e1ad 100644 --- a/drivers/media/i2c/ov08x40.c +++ b/drivers/media/i2c/ov08x40.c @@ -1,7 +1,6 @@ // SPDX-License-Identifier: GPL-2.0 // Copyright (c) 2022 Intel Corporation. -#include #include #include #include @@ -96,12 +95,6 @@ /* Vertical Window Offset */ #define OV08X40_REG_V_WIN_OFFSET 0x3813 -/* Burst Register */ -#define OV08X40_REG_XTALK_FIRST_A 0x5a80 -#define OV08X40_REG_XTALK_LAST_A 0x5b9f -#define OV08X40_REG_XTALK_FIRST_B 0x5bc0 -#define OV08X40_REG_XTALK_LAST_B 0x5f1f - enum { OV08X40_LINK_FREQ_400MHZ_INDEX, }; @@ -677,6 +670,1158 @@ static const struct ov08x40_reg mode_3856x2416_regs[] = { {0x3502, 0x10}, {0x3508, 0x0f}, {0x3509, 0x80}, + {0x5a80, 0x75}, + {0x5a81, 0x75}, + {0x5a82, 0x75}, + {0x5a83, 0x75}, + {0x5a84, 0x75}, + {0x5a85, 0x75}, + {0x5a86, 0x75}, + {0x5a87, 0x75}, + {0x5a88, 0x75}, + {0x5a89, 0x75}, + {0x5a8a, 0x75}, + {0x5a8b, 0x75}, + {0x5a8c, 0x75}, + {0x5a8d, 0x75}, + {0x5a8e, 0x75}, + {0x5a8f, 0x75}, + {0x5a90, 0x75}, + {0x5a91, 0x75}, + {0x5a92, 0x75}, + {0x5a93, 0x75}, + {0x5a94, 0x75}, + {0x5a95, 0x75}, + {0x5a96, 0x75}, + {0x5a97, 0x75}, + {0x5a98, 0x75}, + {0x5a99, 0x75}, + {0x5a9a, 0x75}, + {0x5a9b, 0x75}, + {0x5a9c, 0x75}, + {0x5a9d, 0x75}, + {0x5a9e, 0x75}, + {0x5a9f, 0x75}, + {0x5aa0, 0x75}, + {0x5aa1, 0x75}, + {0x5aa2, 0x75}, + {0x5aa3, 0x75}, + {0x5aa4, 0x75}, + {0x5aa5, 0x75}, + {0x5aa6, 0x75}, + {0x5aa7, 0x75}, + {0x5aa8, 0x75}, + {0x5aa9, 0x75}, + {0x5aaa, 0x75}, + {0x5aab, 0x75}, + {0x5aac, 0x75}, + {0x5aad, 0x75}, + {0x5aae, 0x75}, + {0x5aaf, 0x75}, + {0x5ab0, 0x75}, + {0x5ab1, 0x75}, + {0x5ab2, 0x75}, + {0x5ab3, 0x75}, + {0x5ab4, 0x75}, + {0x5ab5, 0x75}, + {0x5ab6, 0x75}, + {0x5ab7, 0x75}, + {0x5ab8, 0x75}, + {0x5ab9, 0x75}, + {0x5aba, 0x75}, + {0x5abb, 0x75}, + {0x5abc, 0x75}, + {0x5abd, 0x75}, + {0x5abe, 0x75}, + {0x5abf, 0x75}, + {0x5ac0, 0x75}, + {0x5ac1, 0x75}, + {0x5ac2, 0x75}, + {0x5ac3, 0x75}, + {0x5ac4, 0x75}, + {0x5ac5, 0x75}, + {0x5ac6, 0x75}, + {0x5ac7, 0x75}, + {0x5ac8, 0x75}, + {0x5ac9, 0x75}, + {0x5aca, 0x75}, + {0x5acb, 0x75}, + {0x5acc, 0x75}, + {0x5acd, 0x75}, + {0x5ace, 0x75}, + {0x5acf, 0x75}, + {0x5ad0, 0x75}, + {0x5ad1, 0x75}, + {0x5ad2, 0x75}, + {0x5ad3, 0x75}, + {0x5ad4, 0x75}, + {0x5ad5, 0x75}, + {0x5ad6, 0x75}, + {0x5ad7, 0x75}, + {0x5ad8, 0x75}, + {0x5ad9, 0x75}, + {0x5ada, 0x75}, + {0x5adb, 0x75}, + {0x5adc, 0x75}, + {0x5add, 0x75}, + {0x5ade, 0x75}, + {0x5adf, 0x75}, + {0x5ae0, 0x75}, + {0x5ae1, 0x75}, + {0x5ae2, 0x75}, + {0x5ae3, 0x75}, + {0x5ae4, 0x75}, + {0x5ae5, 0x75}, + {0x5ae6, 0x75}, + {0x5ae7, 0x75}, + {0x5ae8, 0x75}, + {0x5ae9, 0x75}, + {0x5aea, 0x75}, + {0x5aeb, 0x75}, + {0x5aec, 0x75}, + {0x5aed, 0x75}, + {0x5aee, 0x75}, + {0x5aef, 0x75}, + {0x5af0, 0x75}, + {0x5af1, 0x75}, + {0x5af2, 0x75}, + {0x5af3, 0x75}, + {0x5af4, 0x75}, + {0x5af5, 0x75}, + {0x5af6, 0x75}, + {0x5af7, 0x75}, + {0x5af8, 0x75}, + {0x5af9, 0x75}, + {0x5afa, 0x75}, + {0x5afb, 0x75}, + {0x5afc, 0x75}, + {0x5afd, 0x75}, + {0x5afe, 0x75}, + {0x5aff, 0x75}, + {0x5b00, 0x75}, + {0x5b01, 0x75}, + {0x5b02, 0x75}, + {0x5b03, 0x75}, + {0x5b04, 0x75}, + {0x5b05, 0x75}, + {0x5b06, 0x75}, + {0x5b07, 0x75}, + {0x5b08, 0x75}, + {0x5b09, 0x75}, + {0x5b0a, 0x75}, + {0x5b0b, 0x75}, + {0x5b0c, 0x75}, + {0x5b0d, 0x75}, + {0x5b0e, 0x75}, + {0x5b0f, 0x75}, + {0x5b10, 0x75}, + {0x5b11, 0x75}, + {0x5b12, 0x75}, + {0x5b13, 0x75}, + {0x5b14, 0x75}, + {0x5b15, 0x75}, + {0x5b16, 0x75}, + {0x5b17, 0x75}, + {0x5b18, 0x75}, + {0x5b19, 0x75}, + {0x5b1a, 0x75}, + {0x5b1b, 0x75}, + {0x5b1c, 0x75}, + {0x5b1d, 0x75}, + {0x5b1e, 0x75}, + {0x5b1f, 0x75}, + {0x5b20, 0x75}, + {0x5b21, 0x75}, + {0x5b22, 0x75}, + {0x5b23, 0x75}, + {0x5b24, 0x75}, + {0x5b25, 0x75}, + {0x5b26, 0x75}, + {0x5b27, 0x75}, + {0x5b28, 0x75}, + {0x5b29, 0x75}, + {0x5b2a, 0x75}, + {0x5b2b, 0x75}, + {0x5b2c, 0x75}, + {0x5b2d, 0x75}, + {0x5b2e, 0x75}, + {0x5b2f, 0x75}, + {0x5b30, 0x75}, + {0x5b31, 0x75}, + {0x5b32, 0x75}, + {0x5b33, 0x75}, + {0x5b34, 0x75}, + {0x5b35, 0x75}, + {0x5b36, 0x75}, + {0x5b37, 0x75}, + {0x5b38, 0x75}, + {0x5b39, 0x75}, + {0x5b3a, 0x75}, + {0x5b3b, 0x75}, + {0x5b3c, 0x75}, + {0x5b3d, 0x75}, + {0x5b3e, 0x75}, + {0x5b3f, 0x75}, + {0x5b40, 0x75}, + {0x5b41, 0x75}, + {0x5b42, 0x75}, + {0x5b43, 0x75}, + {0x5b44, 0x75}, + {0x5b45, 0x75}, + {0x5b46, 0x75}, + {0x5b47, 0x75}, + {0x5b48, 0x75}, + {0x5b49, 0x75}, + {0x5b4a, 0x75}, + {0x5b4b, 0x75}, + {0x5b4c, 0x75}, + {0x5b4d, 0x75}, + {0x5b4e, 0x75}, + {0x5b4f, 0x75}, + {0x5b50, 0x75}, + {0x5b51, 0x75}, + {0x5b52, 0x75}, + {0x5b53, 0x75}, + {0x5b54, 0x75}, + {0x5b55, 0x75}, + {0x5b56, 0x75}, + {0x5b57, 0x75}, + {0x5b58, 0x75}, + {0x5b59, 0x75}, + {0x5b5a, 0x75}, + {0x5b5b, 0x75}, + {0x5b5c, 0x75}, + {0x5b5d, 0x75}, + {0x5b5e, 0x75}, + {0x5b5f, 0x75}, + {0x5b60, 0x75}, + {0x5b61, 0x75}, + {0x5b62, 0x75}, + {0x5b63, 0x75}, + {0x5b64, 0x75}, + {0x5b65, 0x75}, + {0x5b66, 0x75}, + {0x5b67, 0x75}, + {0x5b68, 0x75}, + {0x5b69, 0x75}, + {0x5b6a, 0x75}, + {0x5b6b, 0x75}, + {0x5b6c, 0x75}, + {0x5b6d, 0x75}, + {0x5b6e, 0x75}, + {0x5b6f, 0x75}, + {0x5b70, 0x75}, + {0x5b71, 0x75}, + {0x5b72, 0x75}, + {0x5b73, 0x75}, + {0x5b74, 0x75}, + {0x5b75, 0x75}, + {0x5b76, 0x75}, + {0x5b77, 0x75}, + {0x5b78, 0x75}, + {0x5b79, 0x75}, + {0x5b7a, 0x75}, + {0x5b7b, 0x75}, + {0x5b7c, 0x75}, + {0x5b7d, 0x75}, + {0x5b7e, 0x75}, + {0x5b7f, 0x75}, + {0x5b80, 0x75}, + {0x5b81, 0x75}, + {0x5b82, 0x75}, + {0x5b83, 0x75}, + {0x5b84, 0x75}, + {0x5b85, 0x75}, + {0x5b86, 0x75}, + {0x5b87, 0x75}, + {0x5b88, 0x75}, + {0x5b89, 0x75}, + {0x5b8a, 0x75}, + {0x5b8b, 0x75}, + {0x5b8c, 0x75}, + {0x5b8d, 0x75}, + {0x5b8e, 0x75}, + {0x5b8f, 0x75}, + {0x5b90, 0x75}, + {0x5b91, 0x75}, + {0x5b92, 0x75}, + {0x5b93, 0x75}, + {0x5b94, 0x75}, + {0x5b95, 0x75}, + {0x5b96, 0x75}, + {0x5b97, 0x75}, + {0x5b98, 0x75}, + {0x5b99, 0x75}, + {0x5b9a, 0x75}, + {0x5b9b, 0x75}, + {0x5b9c, 0x75}, + {0x5b9d, 0x75}, + {0x5b9e, 0x75}, + {0x5b9f, 0x75}, + {0x5bc0, 0x75}, + {0x5bc1, 0x75}, + {0x5bc2, 0x75}, + {0x5bc3, 0x75}, + {0x5bc4, 0x75}, + {0x5bc5, 0x75}, + {0x5bc6, 0x75}, + {0x5bc7, 0x75}, + {0x5bc8, 0x75}, + {0x5bc9, 0x75}, + {0x5bca, 0x75}, + {0x5bcb, 0x75}, + {0x5bcc, 0x75}, + {0x5bcd, 0x75}, + {0x5bce, 0x75}, + {0x5bcf, 0x75}, + {0x5bd0, 0x75}, + {0x5bd1, 0x75}, + {0x5bd2, 0x75}, + {0x5bd3, 0x75}, + {0x5bd4, 0x75}, + {0x5bd5, 0x75}, + {0x5bd6, 0x75}, + {0x5bd7, 0x75}, + {0x5bd8, 0x75}, + {0x5bd9, 0x75}, + {0x5bda, 0x75}, + {0x5bdb, 0x75}, + {0x5bdc, 0x75}, + {0x5bdd, 0x75}, + {0x5bde, 0x75}, + {0x5bdf, 0x75}, + {0x5be0, 0x75}, + {0x5be1, 0x75}, + {0x5be2, 0x75}, + {0x5be3, 0x75}, + {0x5be4, 0x75}, + {0x5be5, 0x75}, + {0x5be6, 0x75}, + {0x5be7, 0x75}, + {0x5be8, 0x75}, + {0x5be9, 0x75}, + {0x5bea, 0x75}, + {0x5beb, 0x75}, + {0x5bec, 0x75}, + {0x5bed, 0x75}, + {0x5bee, 0x75}, + {0x5bef, 0x75}, + {0x5bf0, 0x75}, + {0x5bf1, 0x75}, + {0x5bf2, 0x75}, + {0x5bf3, 0x75}, + {0x5bf4, 0x75}, + {0x5bf5, 0x75}, + {0x5bf6, 0x75}, + {0x5bf7, 0x75}, + {0x5bf8, 0x75}, + {0x5bf9, 0x75}, + {0x5bfa, 0x75}, + {0x5bfb, 0x75}, + {0x5bfc, 0x75}, + {0x5bfd, 0x75}, + {0x5bfe, 0x75}, + {0x5bff, 0x75}, + {0x5c00, 0x75}, + {0x5c01, 0x75}, + {0x5c02, 0x75}, + {0x5c03, 0x75}, + {0x5c04, 0x75}, + {0x5c05, 0x75}, + {0x5c06, 0x75}, + {0x5c07, 0x75}, + {0x5c08, 0x75}, + {0x5c09, 0x75}, + {0x5c0a, 0x75}, + {0x5c0b, 0x75}, + {0x5c0c, 0x75}, + {0x5c0d, 0x75}, + {0x5c0e, 0x75}, + {0x5c0f, 0x75}, + {0x5c10, 0x75}, + {0x5c11, 0x75}, + {0x5c12, 0x75}, + {0x5c13, 0x75}, + {0x5c14, 0x75}, + {0x5c15, 0x75}, + {0x5c16, 0x75}, + {0x5c17, 0x75}, + {0x5c18, 0x75}, + {0x5c19, 0x75}, + {0x5c1a, 0x75}, + {0x5c1b, 0x75}, + {0x5c1c, 0x75}, + {0x5c1d, 0x75}, + {0x5c1e, 0x75}, + {0x5c1f, 0x75}, + {0x5c20, 0x75}, + {0x5c21, 0x75}, + {0x5c22, 0x75}, + {0x5c23, 0x75}, + {0x5c24, 0x75}, + {0x5c25, 0x75}, + {0x5c26, 0x75}, + {0x5c27, 0x75}, + {0x5c28, 0x75}, + {0x5c29, 0x75}, + {0x5c2a, 0x75}, + {0x5c2b, 0x75}, + {0x5c2c, 0x75}, + {0x5c2d, 0x75}, + {0x5c2e, 0x75}, + {0x5c2f, 0x75}, + {0x5c30, 0x75}, + {0x5c31, 0x75}, + {0x5c32, 0x75}, + {0x5c33, 0x75}, + {0x5c34, 0x75}, + {0x5c35, 0x75}, + {0x5c36, 0x75}, + {0x5c37, 0x75}, + {0x5c38, 0x75}, + {0x5c39, 0x75}, + {0x5c3a, 0x75}, + {0x5c3b, 0x75}, + {0x5c3c, 0x75}, + {0x5c3d, 0x75}, + {0x5c3e, 0x75}, + {0x5c3f, 0x75}, + {0x5c40, 0x75}, + {0x5c41, 0x75}, + {0x5c42, 0x75}, + {0x5c43, 0x75}, + {0x5c44, 0x75}, + {0x5c45, 0x75}, + {0x5c46, 0x75}, + {0x5c47, 0x75}, + {0x5c48, 0x75}, + {0x5c49, 0x75}, + {0x5c4a, 0x75}, + {0x5c4b, 0x75}, + {0x5c4c, 0x75}, + {0x5c4d, 0x75}, + {0x5c4e, 0x75}, + {0x5c4f, 0x75}, + {0x5c50, 0x75}, + {0x5c51, 0x75}, + {0x5c52, 0x75}, + {0x5c53, 0x75}, + {0x5c54, 0x75}, + {0x5c55, 0x75}, + {0x5c56, 0x75}, + {0x5c57, 0x75}, + {0x5c58, 0x75}, + {0x5c59, 0x75}, + {0x5c5a, 0x75}, + {0x5c5b, 0x75}, + {0x5c5c, 0x75}, + {0x5c5d, 0x75}, + {0x5c5e, 0x75}, + {0x5c5f, 0x75}, + {0x5c60, 0x75}, + {0x5c61, 0x75}, + {0x5c62, 0x75}, + {0x5c63, 0x75}, + {0x5c64, 0x75}, + {0x5c65, 0x75}, + {0x5c66, 0x75}, + {0x5c67, 0x75}, + {0x5c68, 0x75}, + {0x5c69, 0x75}, + {0x5c6a, 0x75}, + {0x5c6b, 0x75}, + {0x5c6c, 0x75}, + {0x5c6d, 0x75}, + {0x5c6e, 0x75}, + {0x5c6f, 0x75}, + {0x5c70, 0x75}, + {0x5c71, 0x75}, + {0x5c72, 0x75}, + {0x5c73, 0x75}, + {0x5c74, 0x75}, + {0x5c75, 0x75}, + {0x5c76, 0x75}, + {0x5c77, 0x75}, + {0x5c78, 0x75}, + {0x5c79, 0x75}, + {0x5c7a, 0x75}, + {0x5c7b, 0x75}, + {0x5c7c, 0x75}, + {0x5c7d, 0x75}, + {0x5c7e, 0x75}, + {0x5c7f, 0x75}, + {0x5c80, 0x75}, + {0x5c81, 0x75}, + {0x5c82, 0x75}, + {0x5c83, 0x75}, + {0x5c84, 0x75}, + {0x5c85, 0x75}, + {0x5c86, 0x75}, + {0x5c87, 0x75}, + {0x5c88, 0x75}, + {0x5c89, 0x75}, + {0x5c8a, 0x75}, + {0x5c8b, 0x75}, + {0x5c8c, 0x75}, + {0x5c8d, 0x75}, + {0x5c8e, 0x75}, + {0x5c8f, 0x75}, + {0x5c90, 0x75}, + {0x5c91, 0x75}, + {0x5c92, 0x75}, + {0x5c93, 0x75}, + {0x5c94, 0x75}, + {0x5c95, 0x75}, + {0x5c96, 0x75}, + {0x5c97, 0x75}, + {0x5c98, 0x75}, + {0x5c99, 0x75}, + {0x5c9a, 0x75}, + {0x5c9b, 0x75}, + {0x5c9c, 0x75}, + {0x5c9d, 0x75}, + {0x5c9e, 0x75}, + {0x5c9f, 0x75}, + {0x5ca0, 0x75}, + {0x5ca1, 0x75}, + {0x5ca2, 0x75}, + {0x5ca3, 0x75}, + {0x5ca4, 0x75}, + {0x5ca5, 0x75}, + {0x5ca6, 0x75}, + {0x5ca7, 0x75}, + {0x5ca8, 0x75}, + {0x5ca9, 0x75}, + {0x5caa, 0x75}, + {0x5cab, 0x75}, + {0x5cac, 0x75}, + {0x5cad, 0x75}, + {0x5cae, 0x75}, + {0x5caf, 0x75}, + {0x5cb0, 0x75}, + {0x5cb1, 0x75}, + {0x5cb2, 0x75}, + {0x5cb3, 0x75}, + {0x5cb4, 0x75}, + {0x5cb5, 0x75}, + {0x5cb6, 0x75}, + {0x5cb7, 0x75}, + {0x5cb8, 0x75}, + {0x5cb9, 0x75}, + {0x5cba, 0x75}, + {0x5cbb, 0x75}, + {0x5cbc, 0x75}, + {0x5cbd, 0x75}, + {0x5cbe, 0x75}, + {0x5cbf, 0x75}, + {0x5cc0, 0x75}, + {0x5cc1, 0x75}, + {0x5cc2, 0x75}, + {0x5cc3, 0x75}, + {0x5cc4, 0x75}, + {0x5cc5, 0x75}, + {0x5cc6, 0x75}, + {0x5cc7, 0x75}, + {0x5cc8, 0x75}, + {0x5cc9, 0x75}, + {0x5cca, 0x75}, + {0x5ccb, 0x75}, + {0x5ccc, 0x75}, + {0x5ccd, 0x75}, + {0x5cce, 0x75}, + {0x5ccf, 0x75}, + {0x5cd0, 0x75}, + {0x5cd1, 0x75}, + {0x5cd2, 0x75}, + {0x5cd3, 0x75}, + {0x5cd4, 0x75}, + {0x5cd5, 0x75}, + {0x5cd6, 0x75}, + {0x5cd7, 0x75}, + {0x5cd8, 0x75}, + {0x5cd9, 0x75}, + {0x5cda, 0x75}, + {0x5cdb, 0x75}, + {0x5cdc, 0x75}, + {0x5cdd, 0x75}, + {0x5cde, 0x75}, + {0x5cdf, 0x75}, + {0x5ce0, 0x75}, + {0x5ce1, 0x75}, + {0x5ce2, 0x75}, + {0x5ce3, 0x75}, + {0x5ce4, 0x75}, + {0x5ce5, 0x75}, + {0x5ce6, 0x75}, + {0x5ce7, 0x75}, + {0x5ce8, 0x75}, + {0x5ce9, 0x75}, + {0x5cea, 0x75}, + {0x5ceb, 0x75}, + {0x5cec, 0x75}, + {0x5ced, 0x75}, + {0x5cee, 0x75}, + {0x5cef, 0x75}, + {0x5cf0, 0x75}, + {0x5cf1, 0x75}, + {0x5cf2, 0x75}, + {0x5cf3, 0x75}, + {0x5cf4, 0x75}, + {0x5cf5, 0x75}, + {0x5cf6, 0x75}, + {0x5cf7, 0x75}, + {0x5cf8, 0x75}, + {0x5cf9, 0x75}, + {0x5cfa, 0x75}, + {0x5cfb, 0x75}, + {0x5cfc, 0x75}, + {0x5cfd, 0x75}, + {0x5cfe, 0x75}, + {0x5cff, 0x75}, + {0x5d00, 0x75}, + {0x5d01, 0x75}, + {0x5d02, 0x75}, + {0x5d03, 0x75}, + {0x5d04, 0x75}, + {0x5d05, 0x75}, + {0x5d06, 0x75}, + {0x5d07, 0x75}, + {0x5d08, 0x75}, + {0x5d09, 0x75}, + {0x5d0a, 0x75}, + {0x5d0b, 0x75}, + {0x5d0c, 0x75}, + {0x5d0d, 0x75}, + {0x5d0e, 0x75}, + {0x5d0f, 0x75}, + {0x5d10, 0x75}, + {0x5d11, 0x75}, + {0x5d12, 0x75}, + {0x5d13, 0x75}, + {0x5d14, 0x75}, + {0x5d15, 0x75}, + {0x5d16, 0x75}, + {0x5d17, 0x75}, + {0x5d18, 0x75}, + {0x5d19, 0x75}, + {0x5d1a, 0x75}, + {0x5d1b, 0x75}, + {0x5d1c, 0x75}, + {0x5d1d, 0x75}, + {0x5d1e, 0x75}, + {0x5d1f, 0x75}, + {0x5d20, 0x75}, + {0x5d21, 0x75}, + {0x5d22, 0x75}, + {0x5d23, 0x75}, + {0x5d24, 0x75}, + {0x5d25, 0x75}, + {0x5d26, 0x75}, + {0x5d27, 0x75}, + {0x5d28, 0x75}, + {0x5d29, 0x75}, + {0x5d2a, 0x75}, + {0x5d2b, 0x75}, + {0x5d2c, 0x75}, + {0x5d2d, 0x75}, + {0x5d2e, 0x75}, + {0x5d2f, 0x75}, + {0x5d30, 0x75}, + {0x5d31, 0x75}, + {0x5d32, 0x75}, + {0x5d33, 0x75}, + {0x5d34, 0x75}, + {0x5d35, 0x75}, + {0x5d36, 0x75}, + {0x5d37, 0x75}, + {0x5d38, 0x75}, + {0x5d39, 0x75}, + {0x5d3a, 0x75}, + {0x5d3b, 0x75}, + {0x5d3c, 0x75}, + {0x5d3d, 0x75}, + {0x5d3e, 0x75}, + {0x5d3f, 0x75}, + {0x5d40, 0x75}, + {0x5d41, 0x75}, + {0x5d42, 0x75}, + {0x5d43, 0x75}, + {0x5d44, 0x75}, + {0x5d45, 0x75}, + {0x5d46, 0x75}, + {0x5d47, 0x75}, + {0x5d48, 0x75}, + {0x5d49, 0x75}, + {0x5d4a, 0x75}, + {0x5d4b, 0x75}, + {0x5d4c, 0x75}, + {0x5d4d, 0x75}, + {0x5d4e, 0x75}, + {0x5d4f, 0x75}, + {0x5d50, 0x75}, + {0x5d51, 0x75}, + {0x5d52, 0x75}, + {0x5d53, 0x75}, + {0x5d54, 0x75}, + {0x5d55, 0x75}, + {0x5d56, 0x75}, + {0x5d57, 0x75}, + {0x5d58, 0x75}, + {0x5d59, 0x75}, + {0x5d5a, 0x75}, + {0x5d5b, 0x75}, + {0x5d5c, 0x75}, + {0x5d5d, 0x75}, + {0x5d5e, 0x75}, + {0x5d5f, 0x75}, + {0x5d60, 0x75}, + {0x5d61, 0x75}, + {0x5d62, 0x75}, + {0x5d63, 0x75}, + {0x5d64, 0x75}, + {0x5d65, 0x75}, + {0x5d66, 0x75}, + {0x5d67, 0x75}, + {0x5d68, 0x75}, + {0x5d69, 0x75}, + {0x5d6a, 0x75}, + {0x5d6b, 0x75}, + {0x5d6c, 0x75}, + {0x5d6d, 0x75}, + {0x5d6e, 0x75}, + {0x5d6f, 0x75}, + {0x5d70, 0x75}, + {0x5d71, 0x75}, + {0x5d72, 0x75}, + {0x5d73, 0x75}, + {0x5d74, 0x75}, + {0x5d75, 0x75}, + {0x5d76, 0x75}, + {0x5d77, 0x75}, + {0x5d78, 0x75}, + {0x5d79, 0x75}, + {0x5d7a, 0x75}, + {0x5d7b, 0x75}, + {0x5d7c, 0x75}, + {0x5d7d, 0x75}, + {0x5d7e, 0x75}, + {0x5d7f, 0x75}, + {0x5d80, 0x75}, + {0x5d81, 0x75}, + {0x5d82, 0x75}, + {0x5d83, 0x75}, + {0x5d84, 0x75}, + {0x5d85, 0x75}, + {0x5d86, 0x75}, + {0x5d87, 0x75}, + {0x5d88, 0x75}, + {0x5d89, 0x75}, + {0x5d8a, 0x75}, + {0x5d8b, 0x75}, + {0x5d8c, 0x75}, + {0x5d8d, 0x75}, + {0x5d8e, 0x75}, + {0x5d8f, 0x75}, + {0x5d90, 0x75}, + {0x5d91, 0x75}, + {0x5d92, 0x75}, + {0x5d93, 0x75}, + {0x5d94, 0x75}, + {0x5d95, 0x75}, + {0x5d96, 0x75}, + {0x5d97, 0x75}, + {0x5d98, 0x75}, + {0x5d99, 0x75}, + {0x5d9a, 0x75}, + {0x5d9b, 0x75}, + {0x5d9c, 0x75}, + {0x5d9d, 0x75}, + {0x5d9e, 0x75}, + {0x5d9f, 0x75}, + {0x5da0, 0x75}, + {0x5da1, 0x75}, + {0x5da2, 0x75}, + {0x5da3, 0x75}, + {0x5da4, 0x75}, + {0x5da5, 0x75}, + {0x5da6, 0x75}, + {0x5da7, 0x75}, + {0x5da8, 0x75}, + {0x5da9, 0x75}, + {0x5daa, 0x75}, + {0x5dab, 0x75}, + {0x5dac, 0x75}, + {0x5dad, 0x75}, + {0x5dae, 0x75}, + {0x5daf, 0x75}, + {0x5db0, 0x75}, + {0x5db1, 0x75}, + {0x5db2, 0x75}, + {0x5db3, 0x75}, + {0x5db4, 0x75}, + {0x5db5, 0x75}, + {0x5db6, 0x75}, + {0x5db7, 0x75}, + {0x5db8, 0x75}, + {0x5db9, 0x75}, + {0x5dba, 0x75}, + {0x5dbb, 0x75}, + {0x5dbc, 0x75}, + {0x5dbd, 0x75}, + {0x5dbe, 0x75}, + {0x5dbf, 0x75}, + {0x5dc0, 0x75}, + {0x5dc1, 0x75}, + {0x5dc2, 0x75}, + {0x5dc3, 0x75}, + {0x5dc4, 0x75}, + {0x5dc5, 0x75}, + {0x5dc6, 0x75}, + {0x5dc7, 0x75}, + {0x5dc8, 0x75}, + {0x5dc9, 0x75}, + {0x5dca, 0x75}, + {0x5dcb, 0x75}, + {0x5dcc, 0x75}, + {0x5dcd, 0x75}, + {0x5dce, 0x75}, + {0x5dcf, 0x75}, + {0x5dd0, 0x75}, + {0x5dd1, 0x75}, + {0x5dd2, 0x75}, + {0x5dd3, 0x75}, + {0x5dd4, 0x75}, + {0x5dd5, 0x75}, + {0x5dd6, 0x75}, + {0x5dd7, 0x75}, + {0x5dd8, 0x75}, + {0x5dd9, 0x75}, + {0x5dda, 0x75}, + {0x5ddb, 0x75}, + {0x5ddc, 0x75}, + {0x5ddd, 0x75}, + {0x5dde, 0x75}, + {0x5ddf, 0x75}, + {0x5de0, 0x75}, + {0x5de1, 0x75}, + {0x5de2, 0x75}, + {0x5de3, 0x75}, + {0x5de4, 0x75}, + {0x5de5, 0x75}, + {0x5de6, 0x75}, + {0x5de7, 0x75}, + {0x5de8, 0x75}, + {0x5de9, 0x75}, + {0x5dea, 0x75}, + {0x5deb, 0x75}, + {0x5dec, 0x75}, + {0x5ded, 0x75}, + {0x5dee, 0x75}, + {0x5def, 0x75}, + {0x5df0, 0x75}, + {0x5df1, 0x75}, + {0x5df2, 0x75}, + {0x5df3, 0x75}, + {0x5df4, 0x75}, + {0x5df5, 0x75}, + {0x5df6, 0x75}, + {0x5df7, 0x75}, + {0x5df8, 0x75}, + {0x5df9, 0x75}, + {0x5dfa, 0x75}, + {0x5dfb, 0x75}, + {0x5dfc, 0x75}, + {0x5dfd, 0x75}, + {0x5dfe, 0x75}, + {0x5dff, 0x75}, + {0x5e00, 0x75}, + {0x5e01, 0x75}, + {0x5e02, 0x75}, + {0x5e03, 0x75}, + {0x5e04, 0x75}, + {0x5e05, 0x75}, + {0x5e06, 0x75}, + {0x5e07, 0x75}, + {0x5e08, 0x75}, + {0x5e09, 0x75}, + {0x5e0a, 0x75}, + {0x5e0b, 0x75}, + {0x5e0c, 0x75}, + {0x5e0d, 0x75}, + {0x5e0e, 0x75}, + {0x5e0f, 0x75}, + {0x5e10, 0x75}, + {0x5e11, 0x75}, + {0x5e12, 0x75}, + {0x5e13, 0x75}, + {0x5e14, 0x75}, + {0x5e15, 0x75}, + {0x5e16, 0x75}, + {0x5e17, 0x75}, + {0x5e18, 0x75}, + {0x5e19, 0x75}, + {0x5e1a, 0x75}, + {0x5e1b, 0x75}, + {0x5e1c, 0x75}, + {0x5e1d, 0x75}, + {0x5e1e, 0x75}, + {0x5e1f, 0x75}, + {0x5e20, 0x75}, + {0x5e21, 0x75}, + {0x5e22, 0x75}, + {0x5e23, 0x75}, + {0x5e24, 0x75}, + {0x5e25, 0x75}, + {0x5e26, 0x75}, + {0x5e27, 0x75}, + {0x5e28, 0x75}, + {0x5e29, 0x75}, + {0x5e2a, 0x75}, + {0x5e2b, 0x75}, + {0x5e2c, 0x75}, + {0x5e2d, 0x75}, + {0x5e2e, 0x75}, + {0x5e2f, 0x75}, + {0x5e30, 0x75}, + {0x5e31, 0x75}, + {0x5e32, 0x75}, + {0x5e33, 0x75}, + {0x5e34, 0x75}, + {0x5e35, 0x75}, + {0x5e36, 0x75}, + {0x5e37, 0x75}, + {0x5e38, 0x75}, + {0x5e39, 0x75}, + {0x5e3a, 0x75}, + {0x5e3b, 0x75}, + {0x5e3c, 0x75}, + {0x5e3d, 0x75}, + {0x5e3e, 0x75}, + {0x5e3f, 0x75}, + {0x5e40, 0x75}, + {0x5e41, 0x75}, + {0x5e42, 0x75}, + {0x5e43, 0x75}, + {0x5e44, 0x75}, + {0x5e45, 0x75}, + {0x5e46, 0x75}, + {0x5e47, 0x75}, + {0x5e48, 0x75}, + {0x5e49, 0x75}, + {0x5e4a, 0x75}, + {0x5e4b, 0x75}, + {0x5e4c, 0x75}, + {0x5e4d, 0x75}, + {0x5e4e, 0x75}, + {0x5e4f, 0x75}, + {0x5e50, 0x75}, + {0x5e51, 0x75}, + {0x5e52, 0x75}, + {0x5e53, 0x75}, + {0x5e54, 0x75}, + {0x5e55, 0x75}, + {0x5e56, 0x75}, + {0x5e57, 0x75}, + {0x5e58, 0x75}, + {0x5e59, 0x75}, + {0x5e5a, 0x75}, + {0x5e5b, 0x75}, + {0x5e5c, 0x75}, + {0x5e5d, 0x75}, + {0x5e5e, 0x75}, + {0x5e5f, 0x75}, + {0x5e60, 0x75}, + {0x5e61, 0x75}, + {0x5e62, 0x75}, + {0x5e63, 0x75}, + {0x5e64, 0x75}, + {0x5e65, 0x75}, + {0x5e66, 0x75}, + {0x5e67, 0x75}, + {0x5e68, 0x75}, + {0x5e69, 0x75}, + {0x5e6a, 0x75}, + {0x5e6b, 0x75}, + {0x5e6c, 0x75}, + {0x5e6d, 0x75}, + {0x5e6e, 0x75}, + {0x5e6f, 0x75}, + {0x5e70, 0x75}, + {0x5e71, 0x75}, + {0x5e72, 0x75}, + {0x5e73, 0x75}, + {0x5e74, 0x75}, + {0x5e75, 0x75}, + {0x5e76, 0x75}, + {0x5e77, 0x75}, + {0x5e78, 0x75}, + {0x5e79, 0x75}, + {0x5e7a, 0x75}, + {0x5e7b, 0x75}, + {0x5e7c, 0x75}, + {0x5e7d, 0x75}, + {0x5e7e, 0x75}, + {0x5e7f, 0x75}, + {0x5e80, 0x75}, + {0x5e81, 0x75}, + {0x5e82, 0x75}, + {0x5e83, 0x75}, + {0x5e84, 0x75}, + {0x5e85, 0x75}, + {0x5e86, 0x75}, + {0x5e87, 0x75}, + {0x5e88, 0x75}, + {0x5e89, 0x75}, + {0x5e8a, 0x75}, + {0x5e8b, 0x75}, + {0x5e8c, 0x75}, + {0x5e8d, 0x75}, + {0x5e8e, 0x75}, + {0x5e8f, 0x75}, + {0x5e90, 0x75}, + {0x5e91, 0x75}, + {0x5e92, 0x75}, + {0x5e93, 0x75}, + {0x5e94, 0x75}, + {0x5e95, 0x75}, + {0x5e96, 0x75}, + {0x5e97, 0x75}, + {0x5e98, 0x75}, + {0x5e99, 0x75}, + {0x5e9a, 0x75}, + {0x5e9b, 0x75}, + {0x5e9c, 0x75}, + {0x5e9d, 0x75}, + {0x5e9e, 0x75}, + {0x5e9f, 0x75}, + {0x5ea0, 0x75}, + {0x5ea1, 0x75}, + {0x5ea2, 0x75}, + {0x5ea3, 0x75}, + {0x5ea4, 0x75}, + {0x5ea5, 0x75}, + {0x5ea6, 0x75}, + {0x5ea7, 0x75}, + {0x5ea8, 0x75}, + {0x5ea9, 0x75}, + {0x5eaa, 0x75}, + {0x5eab, 0x75}, + {0x5eac, 0x75}, + {0x5ead, 0x75}, + {0x5eae, 0x75}, + {0x5eaf, 0x75}, + {0x5eb0, 0x75}, + {0x5eb1, 0x75}, + {0x5eb2, 0x75}, + {0x5eb3, 0x75}, + {0x5eb4, 0x75}, + {0x5eb5, 0x75}, + {0x5eb6, 0x75}, + {0x5eb7, 0x75}, + {0x5eb8, 0x75}, + {0x5eb9, 0x75}, + {0x5eba, 0x75}, + {0x5ebb, 0x75}, + {0x5ebc, 0x75}, + {0x5ebd, 0x75}, + {0x5ebe, 0x75}, + {0x5ebf, 0x75}, + {0x5ec0, 0x75}, + {0x5ec1, 0x75}, + {0x5ec2, 0x75}, + {0x5ec3, 0x75}, + {0x5ec4, 0x75}, + {0x5ec5, 0x75}, + {0x5ec6, 0x75}, + {0x5ec7, 0x75}, + {0x5ec8, 0x75}, + {0x5ec9, 0x75}, + {0x5eca, 0x75}, + {0x5ecb, 0x75}, + {0x5ecc, 0x75}, + {0x5ecd, 0x75}, + {0x5ece, 0x75}, + {0x5ecf, 0x75}, + {0x5ed0, 0x75}, + {0x5ed1, 0x75}, + {0x5ed2, 0x75}, + {0x5ed3, 0x75}, + {0x5ed4, 0x75}, + {0x5ed5, 0x75}, + {0x5ed6, 0x75}, + {0x5ed7, 0x75}, + {0x5ed8, 0x75}, + {0x5ed9, 0x75}, + {0x5eda, 0x75}, + {0x5edb, 0x75}, + {0x5edc, 0x75}, + {0x5edd, 0x75}, + {0x5ede, 0x75}, + {0x5edf, 0x75}, + {0x5ee0, 0x75}, + {0x5ee1, 0x75}, + {0x5ee2, 0x75}, + {0x5ee3, 0x75}, + {0x5ee4, 0x75}, + {0x5ee5, 0x75}, + {0x5ee6, 0x75}, + {0x5ee7, 0x75}, + {0x5ee8, 0x75}, + {0x5ee9, 0x75}, + {0x5eea, 0x75}, + {0x5eeb, 0x75}, + {0x5eec, 0x75}, + {0x5eed, 0x75}, + {0x5eee, 0x75}, + {0x5eef, 0x75}, + {0x5ef0, 0x75}, + {0x5ef1, 0x75}, + {0x5ef2, 0x75}, + {0x5ef3, 0x75}, + {0x5ef4, 0x75}, + {0x5ef5, 0x75}, + {0x5ef6, 0x75}, + {0x5ef7, 0x75}, + {0x5ef8, 0x75}, + {0x5ef9, 0x75}, + {0x5efa, 0x75}, + {0x5efb, 0x75}, + {0x5efc, 0x75}, + {0x5efd, 0x75}, + {0x5efe, 0x75}, + {0x5eff, 0x75}, + {0x5f00, 0x75}, + {0x5f01, 0x75}, + {0x5f02, 0x75}, + {0x5f03, 0x75}, + {0x5f04, 0x75}, + {0x5f05, 0x75}, + {0x5f06, 0x75}, + {0x5f07, 0x75}, + {0x5f08, 0x75}, + {0x5f09, 0x75}, + {0x5f0a, 0x75}, + {0x5f0b, 0x75}, + {0x5f0c, 0x75}, + {0x5f0d, 0x75}, + {0x5f0e, 0x75}, + {0x5f0f, 0x75}, + {0x5f10, 0x75}, + {0x5f11, 0x75}, + {0x5f12, 0x75}, + {0x5f13, 0x75}, + {0x5f14, 0x75}, + {0x5f15, 0x75}, + {0x5f16, 0x75}, + {0x5f17, 0x75}, + {0x5f18, 0x75}, + {0x5f19, 0x75}, + {0x5f1a, 0x75}, + {0x5f1b, 0x75}, + {0x5f1c, 0x75}, + {0x5f1d, 0x75}, + {0x5f1e, 0x75}, + {0x5f1f, 0x75}, }; static const struct ov08x40_reg mode_1928x1208_regs[] = { @@ -1339,40 +2484,6 @@ static int ov08x40_read_reg(struct ov08x40 *ov08x, return 0; } -static int ov08x40_burst_fill_regs(struct ov08x40 *ov08x, u16 first_reg, - u16 last_reg, u8 val) -{ - struct i2c_client *client = v4l2_get_subdevdata(&ov08x->sd); - struct i2c_msg msgs; - size_t i, num_regs; - int ret; - - num_regs = last_reg - first_reg + 1; - msgs.addr = client->addr; - msgs.flags = 0; - msgs.len = 2 + num_regs; - msgs.buf = kmalloc(msgs.len, GFP_KERNEL); - - if (!msgs.buf) - return -ENOMEM; - - put_unaligned_be16(first_reg, msgs.buf); - - for (i = 0; i < num_regs; ++i) - msgs.buf[2 + i] = val; - - ret = i2c_transfer(client->adapter, &msgs, 1); - - kfree(msgs.buf); - - if (ret != 1) { - dev_err(&client->dev, "Failed regs transferred: %d\n", ret); - return -EIO; - } - - return 0; -} - /* Write registers up to 4 at a time */ static int ov08x40_write_reg(struct ov08x40 *ov08x, u16 reg, u32 len, u32 __val) @@ -1813,22 +2924,6 @@ static int ov08x40_start_streaming(struct ov08x40 *ov08x) return ret; } - /* Use i2c burst to write register on full size registers */ - if (ov08x->cur_mode->exposure_shift == 1) { - ret = ov08x40_burst_fill_regs(ov08x, OV08X40_REG_XTALK_FIRST_A, - OV08X40_REG_XTALK_LAST_A, 0x75); - if (ret == 0) - ret = ov08x40_burst_fill_regs(ov08x, - OV08X40_REG_XTALK_FIRST_B, - OV08X40_REG_XTALK_LAST_B, - 0x75); - } - - if (ret) { - dev_err(&client->dev, "%s failed to set regs\n", __func__); - return ret; - } - /* Apply customized values from user */ ret = __v4l2_ctrl_handler_setup(ov08x->sd.ctrl_handler); if (ret) -- cgit v1.2.3 From 8c2b1b48ad83d37a58a555c3bcf372b4ab477c64 Mon Sep 17 00:00:00 2001 From: Conor Dooley Date: Mon, 22 Jan 2024 12:19:50 +0000 Subject: dt-bindings: can: mpfs: add missing required clock The CAN controller on PolarFire SoC has an AHB peripheral clock _and_ a CAN bus clock. The bus clock was omitted when the binding was written, but is required for operation. Make up for lost time and add it. Cautionary tale in adding bindings without having implemented a real user for them perhaps. Fixes: c878d518d7b6 ("dt-bindings: can: mpfs: document the mpfs CAN controller") Reviewed-by: Krzysztof Kozlowski Signed-off-by: Conor Dooley --- Documentation/devicetree/bindings/net/can/microchip,mpfs-can.yaml | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/can/microchip,mpfs-can.yaml b/Documentation/devicetree/bindings/net/can/microchip,mpfs-can.yaml index 45aa3de7cf01..01e4d4a54df6 100644 --- a/Documentation/devicetree/bindings/net/can/microchip,mpfs-can.yaml +++ b/Documentation/devicetree/bindings/net/can/microchip,mpfs-can.yaml @@ -24,7 +24,9 @@ properties: maxItems: 1 clocks: - maxItems: 1 + items: + - description: AHB peripheral clock + - description: CAN bus clock required: - compatible @@ -39,7 +41,7 @@ examples: can@2010c000 { compatible = "microchip,mpfs-can"; reg = <0x2010c000 0x1000>; - clocks = <&clkcfg 17>; + clocks = <&clkcfg 17>, <&clkcfg 37>; interrupt-parent = <&plic>; interrupts = <56>; }; -- cgit v1.2.3 From a15f859ca312feb4730c93320bbe46929d0f9d26 Mon Sep 17 00:00:00 2001 From: Dharma Balasubiramani Date: Tue, 6 Feb 2024 12:14:18 +0530 Subject: ASoC: dt-bindings: atmel,sam9x5-wm8731: Convert to json-schema Convert atmel sam9x5-wm8731-audio devicetree binding to json-schema. Signed-off-by: Dharma Balasubiramani Reviewed-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20240206064418.237377-1-dharma.b@microchip.com Signed-off-by: Mark Brown --- .../bindings/sound/atmel,sam9x5-wm8731-audio.yaml | 76 ++++++++++++++++++++++ .../bindings/sound/atmel-sam9x5-wm8731-audio.txt | 35 ---------- 2 files changed, 76 insertions(+), 35 deletions(-) create mode 100644 Documentation/devicetree/bindings/sound/atmel,sam9x5-wm8731-audio.yaml delete mode 100644 Documentation/devicetree/bindings/sound/atmel-sam9x5-wm8731-audio.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/atmel,sam9x5-wm8731-audio.yaml b/Documentation/devicetree/bindings/sound/atmel,sam9x5-wm8731-audio.yaml new file mode 100644 index 000000000000..33717b728f63 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/atmel,sam9x5-wm8731-audio.yaml @@ -0,0 +1,76 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/atmel,sam9x5-wm8731-audio.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Atmel at91sam9x5ek wm8731 audio complex + +maintainers: + - Dharma Balasubiramani + +description: + The audio complex configuration for Atmel at91sam9x5ek with WM8731 audio codec. + +properties: + compatible: + const: atmel,sam9x5-wm8731-audio + + atmel,model: + $ref: /schemas/types.yaml#/definitions/string + description: The user-visible name of this sound complex. + + atmel,ssc-controller: + $ref: /schemas/types.yaml#/definitions/phandle + description: The phandle of the SSC controller. + + atmel,audio-codec: + $ref: /schemas/types.yaml#/definitions/phandle + description: The phandle of the WM8731 audio codec. + + atmel,audio-routing: + 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. + $ref: /schemas/types.yaml#/definitions/non-unique-string-array + items: + enum: + # Board Connectors + - Headphone Jack + - Line In Jack + + # CODEC Pins + - LOUT + - ROUT + - LHPOUT + - RHPOUT + - LLINEIN + - RLINEIN + - MICIN + +required: + - compatible + - atmel,model + - atmel,ssc-controller + - atmel,audio-codec + - atmel,audio-routing + +additionalProperties: false + +examples: + - | + sound { + compatible = "atmel,sam9x5-wm8731-audio"; + + atmel,model = "wm8731 @ AT91SAM9X5EK"; + + atmel,audio-routing = + "Headphone Jack", "RHPOUT", + "Headphone Jack", "LHPOUT", + "LLINEIN", "Line In Jack", + "RLINEIN", "Line In Jack"; + + atmel,ssc-controller = <&ssc0>; + atmel,audio-codec = <&wm8731>; + }; diff --git a/Documentation/devicetree/bindings/sound/atmel-sam9x5-wm8731-audio.txt b/Documentation/devicetree/bindings/sound/atmel-sam9x5-wm8731-audio.txt deleted file mode 100644 index 8facbce53db8..000000000000 --- a/Documentation/devicetree/bindings/sound/atmel-sam9x5-wm8731-audio.txt +++ /dev/null @@ -1,35 +0,0 @@ -* Atmel at91sam9x5ek wm8731 audio complex - -Required properties: - - compatible: "atmel,sam9x5-wm8731-audio" - - atmel,model: The user-visible name of this sound complex. - - atmel,ssc-controller: The phandle of the SSC controller - - atmel,audio-codec: The phandle of the WM8731 audio codec - - atmel,audio-routing: 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. - -Available audio endpoints for the audio-routing table: - -Board connectors: - * Headphone Jack - * Line In Jack - -wm8731 pins: -cf Documentation/devicetree/bindings/sound/wlf,wm8731.yaml - -Example: -sound { - compatible = "atmel,sam9x5-wm8731-audio"; - - atmel,model = "wm8731 @ AT91SAM9X5EK"; - - atmel,audio-routing = - "Headphone Jack", "RHPOUT", - "Headphone Jack", "LHPOUT", - "LLINEIN", "Line In Jack", - "RLINEIN", "Line In Jack"; - - atmel,ssc-controller = <&ssc0>; - atmel,audio-codec = <&wm8731>; -}; -- cgit v1.2.3 From fc67d663aabdfddbba8e16a40c3f6a973face509 Mon Sep 17 00:00:00 2001 From: Adam Ford Date: Sat, 3 Feb 2024 10:52:43 -0600 Subject: dt-bindings: soc: imx: add missing clock and power-domains to imx8mp-hdmi-blk-ctrl Per guidance from the NXP downstream kernel, if the clock is disabled before HDMI/LCDIF probe, LCDIF will not get pixel clock from HDMI PHY and throw an error: [CRTC:39:crtc-2] vblank wait timed out WARNING: CPU: 2 PID: 9 at drivers/gpu/drm/drm_atomic_helper.c: 1634 drm_atomic_helper_wait_for_vblanks.part.0+0x23c/0x260 Fix this by adding the fdcc clock to the hdmi_blk_ctrl. This should be safe, since neither this power domain nor the dependent HDMI and LCDIF drivers been enabled or added to the SoC device tree yet. According to Sandor Yu from NXP, "the FDCC clock is not for HDMITX in desgin, but it is part of HDMI domain that needed by HDMITX. So I think it is reasonable added it to the power domain driver." The driver also supports two power domains which are missing from the binding that also fix an issue with resuming from suspend. Signed-off-by: Adam Ford Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20240203165307.7806-4-aford173@gmail.com Signed-off-by: Ulf Hansson --- .../bindings/soc/imx/fsl,imx8mp-hdmi-blk-ctrl.yaml | 22 ++++++++++++++-------- 1 file changed, 14 insertions(+), 8 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/soc/imx/fsl,imx8mp-hdmi-blk-ctrl.yaml b/Documentation/devicetree/bindings/soc/imx/fsl,imx8mp-hdmi-blk-ctrl.yaml index 1be4ce2a45e8..bd1cdaa4f54b 100644 --- a/Documentation/devicetree/bindings/soc/imx/fsl,imx8mp-hdmi-blk-ctrl.yaml +++ b/Documentation/devicetree/bindings/soc/imx/fsl,imx8mp-hdmi-blk-ctrl.yaml @@ -27,8 +27,8 @@ properties: const: 1 power-domains: - minItems: 8 - maxItems: 8 + minItems: 10 + maxItems: 10 power-domain-names: items: @@ -40,10 +40,12 @@ properties: - const: trng - const: hdmi-tx - const: hdmi-tx-phy + - const: hdcp + - const: hrv clocks: - minItems: 4 - maxItems: 4 + minItems: 5 + maxItems: 5 clock-names: items: @@ -51,6 +53,7 @@ properties: - const: axi - const: ref_266m - const: ref_24m + - const: fdcc interconnects: maxItems: 3 @@ -82,12 +85,15 @@ examples: clocks = <&clk IMX8MP_CLK_HDMI_APB>, <&clk IMX8MP_CLK_HDMI_ROOT>, <&clk IMX8MP_CLK_HDMI_REF_266M>, - <&clk IMX8MP_CLK_HDMI_24M>; - clock-names = "apb", "axi", "ref_266m", "ref_24m"; + <&clk IMX8MP_CLK_HDMI_24M>, + <&clk IMX8MP_CLK_HDMI_FDCC_TST>; + clock-names = "apb", "axi", "ref_266m", "ref_24m", "fdcc"; power-domains = <&pgc_hdmimix>, <&pgc_hdmimix>, <&pgc_hdmimix>, <&pgc_hdmimix>, <&pgc_hdmimix>, <&pgc_hdmimix>, - <&pgc_hdmimix>, <&pgc_hdmi_phy>; + <&pgc_hdmimix>, <&pgc_hdmi_phy>, + <&pgc_hdmimix>, <&pgc_hdmimix>; power-domain-names = "bus", "irqsteer", "lcdif", "pai", "pvi", "trng", - "hdmi-tx", "hdmi-tx-phy"; + "hdmi-tx", "hdmi-tx-phy", + "hdcp", "hrv"; #power-domain-cells = <1>; }; -- cgit v1.2.3 From 563918a0e3afd97bcfb680b72c52ec080c82aea6 Mon Sep 17 00:00:00 2001 From: Dave Thaler Date: Mon, 5 Feb 2024 20:51:46 -0800 Subject: bpf, docs: Fix typos in instructions-set.rst * "imm32" should just be "imm" * Add blank line to fix formatting error reported by Stephen Rothwell [0] [0]: https://lore.kernel.org/bpf/20240206153301.4ead0bad@canb.auug.org.au/T/#u Signed-off-by: Dave Thaler Acked-by: David Vernet Link: https://lore.kernel.org/r/20240206045146.4965-1-dthaler1968@gmail.com Signed-off-by: Alexei Starovoitov --- Documentation/bpf/standardization/instruction-set.rst | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/bpf/standardization/instruction-set.rst b/Documentation/bpf/standardization/instruction-set.rst index 1c4258f1ce93..bdfe0cd0e499 100644 --- a/Documentation/bpf/standardization/instruction-set.rst +++ b/Documentation/bpf/standardization/instruction-set.rst @@ -117,6 +117,7 @@ corresponds to a set of instructions that are mandatory. That is, each instruction has one or more conformance groups of which it is a member. This document defines the following conformance groups: + * base32: includes all instructions defined in this specification unless otherwise noted. * base64: includes base32, plus instructions explicitly noted @@ -289,11 +290,11 @@ where '(u32)' indicates that the upper 32 bits are zeroed. ``BPF_XOR | BPF_K | BPF_ALU`` means:: - dst = (u32) dst ^ (u32) imm32 + dst = (u32) dst ^ (u32) imm ``BPF_XOR | BPF_K | BPF_ALU64`` means:: - dst = dst ^ imm32 + dst = dst ^ imm Note that most instructions have instruction offset of 0. Only three instructions (``BPF_SDIV``, ``BPF_SMOD``, ``BPF_MOVSX``) have a non-zero offset. @@ -511,7 +512,7 @@ instructions that transfer data between a register and memory. ``BPF_MEM | | BPF_ST`` means:: - *(size *) (dst + offset) = imm32 + *(size *) (dst + offset) = imm ``BPF_MEM | | BPF_LDX`` means:: -- cgit v1.2.3 From 0ebeba917f030811f9ea30cd6c435e5b9ebbed43 Mon Sep 17 00:00:00 2001 From: Abel Vesa Date: Mon, 29 Jan 2024 15:28:29 +0200 Subject: dt-bindings: soc: qcom: qcom,pmic-glink: document X1E80100 compatible Document the X1E80100 compatible used to describe the pmic glink on this platform. Signed-off-by: Abel Vesa Acked-by: Conor Dooley Link: https://lore.kernel.org/r/20240129-x1e80100-pmic-glink-v1-1-e45cf194b964@linaro.org Signed-off-by: Bjorn Andersson --- Documentation/devicetree/bindings/soc/qcom/qcom,pmic-glink.yaml | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,pmic-glink.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,pmic-glink.yaml index 61df97ffe1e4..d3f3259ef77d 100644 --- a/Documentation/devicetree/bindings/soc/qcom/qcom,pmic-glink.yaml +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,pmic-glink.yaml @@ -32,6 +32,7 @@ properties: - items: - enum: - qcom,sm8650-pmic-glink + - qcom,x1e80100-pmic-glink - const: qcom,sm8550-pmic-glink - const: qcom,pmic-glink @@ -65,6 +66,7 @@ allOf: enum: - qcom,sm8450-pmic-glink - qcom,sm8550-pmic-glink + - qcom,x1e80100-pmic-glink then: properties: orientation-gpios: false -- cgit v1.2.3 From c984dde8f3f85053fc1ec6baf57eb4fdfdd9bf46 Mon Sep 17 00:00:00 2001 From: Abel Vesa Date: Fri, 2 Feb 2024 20:34:36 +0200 Subject: dt-bindings: clock: Drop the SM8650 DISPCC dedicated schema The block is the same between these platforms, at least from devicetree point of view. So drop the dedicated schema and use the SM8550 one instead. Reviewed-by: Krzysztof Kozlowski Signed-off-by: Abel Vesa Link: https://lore.kernel.org/r/20240202-x1e80100-clock-controllers-v4-1-7fb08c861c7c@linaro.org Signed-off-by: Bjorn Andersson --- .../bindings/clock/qcom,sm8550-dispcc.yaml | 5 +- .../bindings/clock/qcom,sm8650-dispcc.yaml | 106 --------------------- 2 files changed, 4 insertions(+), 107 deletions(-) delete mode 100644 Documentation/devicetree/bindings/clock/qcom,sm8650-dispcc.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/qcom,sm8550-dispcc.yaml b/Documentation/devicetree/bindings/clock/qcom,sm8550-dispcc.yaml index c129f8c16b50..369a0491f8d6 100644 --- a/Documentation/devicetree/bindings/clock/qcom,sm8550-dispcc.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,sm8550-dispcc.yaml @@ -14,12 +14,15 @@ description: | Qualcomm display clock control module provides the clocks, resets and power domains on SM8550. - See also:: include/dt-bindings/clock/qcom,sm8550-dispcc.h + See also: + - include/dt-bindings/clock/qcom,sm8550-dispcc.h + - include/dt-bindings/clock/qcom,sm8650-dispcc.h properties: compatible: enum: - qcom,sm8550-dispcc + - qcom,sm8650-dispcc clocks: items: diff --git a/Documentation/devicetree/bindings/clock/qcom,sm8650-dispcc.yaml b/Documentation/devicetree/bindings/clock/qcom,sm8650-dispcc.yaml deleted file mode 100644 index 5e0c45c380f5..000000000000 --- a/Documentation/devicetree/bindings/clock/qcom,sm8650-dispcc.yaml +++ /dev/null @@ -1,106 +0,0 @@ -# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) -%YAML 1.2 ---- -$id: http://devicetree.org/schemas/clock/qcom,sm8650-dispcc.yaml# -$schema: http://devicetree.org/meta-schemas/core.yaml# - -title: Qualcomm Display Clock & Reset Controller for SM8650 - -maintainers: - - Bjorn Andersson - - Neil Armstrong - -description: | - Qualcomm display clock control module provides the clocks, resets and power - domains on SM8650. - - See also:: include/dt-bindings/clock/qcom,sm8650-dispcc.h - -properties: - compatible: - enum: - - qcom,sm8650-dispcc - - clocks: - items: - - description: Board XO source - - description: Board Always On XO source - - description: Display's AHB clock - - description: sleep clock - - description: Byte clock from DSI PHY0 - - description: Pixel clock from DSI PHY0 - - description: Byte clock from DSI PHY1 - - description: Pixel clock from DSI PHY1 - - description: Link clock from DP PHY0 - - description: VCO DIV clock from DP PHY0 - - description: Link clock from DP PHY1 - - description: VCO DIV clock from DP PHY1 - - description: Link clock from DP PHY2 - - description: VCO DIV clock from DP PHY2 - - description: Link clock from DP PHY3 - - description: VCO DIV clock from DP PHY3 - - '#clock-cells': - const: 1 - - '#reset-cells': - const: 1 - - '#power-domain-cells': - const: 1 - - reg: - maxItems: 1 - - power-domains: - description: - A phandle and PM domain specifier for the MMCX power domain. - maxItems: 1 - - required-opps: - description: - A phandle to an OPP node describing required MMCX performance point. - maxItems: 1 - -required: - - compatible - - reg - - clocks - - '#clock-cells' - - '#reset-cells' - - '#power-domain-cells' - -additionalProperties: false - -examples: - - | - #include - #include - #include - #include - clock-controller@af00000 { - compatible = "qcom,sm8650-dispcc"; - reg = <0x0af00000 0x10000>; - clocks = <&rpmhcc RPMH_CXO_CLK>, - <&rpmhcc RPMH_CXO_CLK_A>, - <&gcc GCC_DISP_AHB_CLK>, - <&sleep_clk>, - <&dsi0_phy 0>, - <&dsi0_phy 1>, - <&dsi1_phy 0>, - <&dsi1_phy 1>, - <&dp0_phy 0>, - <&dp0_phy 1>, - <&dp1_phy 0>, - <&dp1_phy 1>, - <&dp2_phy 0>, - <&dp2_phy 1>, - <&dp3_phy 0>, - <&dp3_phy 1>; - #clock-cells = <1>; - #reset-cells = <1>; - #power-domain-cells = <1>; - power-domains = <&rpmhpd RPMHPD_MMCX>; - required-opps = <&rpmhpd_opp_low_svs>; - }; -... -- cgit v1.2.3 From 4f70a09bde32d8fe59ef2101c5122fa460205c01 Mon Sep 17 00:00:00 2001 From: Rajendra Nayak Date: Fri, 2 Feb 2024 20:34:37 +0200 Subject: dt-bindings: clock: qcom: Document the X1E80100 Display Clock Controller Add bindings documentation for the X1E80100 Display Clock Controller. Signed-off-by: Rajendra Nayak Reviewed-by: Krzysztof Kozlowski Signed-off-by: Abel Vesa Link: https://lore.kernel.org/r/20240202-x1e80100-clock-controllers-v4-2-7fb08c861c7c@linaro.org Signed-off-by: Bjorn Andersson --- .../bindings/clock/qcom,sm8550-dispcc.yaml | 2 + include/dt-bindings/clock/qcom,x1e80100-dispcc.h | 98 ++++++++++++++++++++++ 2 files changed, 100 insertions(+) create mode 100644 include/dt-bindings/clock/qcom,x1e80100-dispcc.h (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/qcom,sm8550-dispcc.yaml b/Documentation/devicetree/bindings/clock/qcom,sm8550-dispcc.yaml index 369a0491f8d6..bad0260764d4 100644 --- a/Documentation/devicetree/bindings/clock/qcom,sm8550-dispcc.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,sm8550-dispcc.yaml @@ -17,12 +17,14 @@ description: | See also: - include/dt-bindings/clock/qcom,sm8550-dispcc.h - include/dt-bindings/clock/qcom,sm8650-dispcc.h + - include/dt-bindings/clock/qcom,x1e80100-dispcc.h properties: compatible: enum: - qcom,sm8550-dispcc - qcom,sm8650-dispcc + - qcom,x1e80100-dispcc clocks: items: diff --git a/include/dt-bindings/clock/qcom,x1e80100-dispcc.h b/include/dt-bindings/clock/qcom,x1e80100-dispcc.h new file mode 100644 index 000000000000..d4a83e4fd0d1 --- /dev/null +++ b/include/dt-bindings/clock/qcom,x1e80100-dispcc.h @@ -0,0 +1,98 @@ +/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */ +/* + * Copyright (c) 2023, Qualcomm Innovation Center, Inc. All rights reserved. + */ + +#ifndef _DT_BINDINGS_CLK_QCOM_X1E80100_DISP_CC_H +#define _DT_BINDINGS_CLK_QCOM_X1E80100_DISP_CC_H + +/* DISP_CC clocks */ +#define DISP_CC_MDSS_ACCU_CLK 0 +#define DISP_CC_MDSS_AHB1_CLK 1 +#define DISP_CC_MDSS_AHB_CLK 2 +#define DISP_CC_MDSS_AHB_CLK_SRC 3 +#define DISP_CC_MDSS_BYTE0_CLK 4 +#define DISP_CC_MDSS_BYTE0_CLK_SRC 5 +#define DISP_CC_MDSS_BYTE0_DIV_CLK_SRC 6 +#define DISP_CC_MDSS_BYTE0_INTF_CLK 7 +#define DISP_CC_MDSS_BYTE1_CLK 8 +#define DISP_CC_MDSS_BYTE1_CLK_SRC 9 +#define DISP_CC_MDSS_BYTE1_DIV_CLK_SRC 10 +#define DISP_CC_MDSS_BYTE1_INTF_CLK 11 +#define DISP_CC_MDSS_DPTX0_AUX_CLK 12 +#define DISP_CC_MDSS_DPTX0_AUX_CLK_SRC 13 +#define DISP_CC_MDSS_DPTX0_LINK_CLK 14 +#define DISP_CC_MDSS_DPTX0_LINK_CLK_SRC 15 +#define DISP_CC_MDSS_DPTX0_LINK_DIV_CLK_SRC 16 +#define DISP_CC_MDSS_DPTX0_LINK_INTF_CLK 17 +#define DISP_CC_MDSS_DPTX0_PIXEL0_CLK 18 +#define DISP_CC_MDSS_DPTX0_PIXEL0_CLK_SRC 19 +#define DISP_CC_MDSS_DPTX0_PIXEL1_CLK 20 +#define DISP_CC_MDSS_DPTX0_PIXEL1_CLK_SRC 21 +#define DISP_CC_MDSS_DPTX0_USB_ROUTER_LINK_INTF_CLK 22 +#define DISP_CC_MDSS_DPTX1_AUX_CLK 23 +#define DISP_CC_MDSS_DPTX1_AUX_CLK_SRC 24 +#define DISP_CC_MDSS_DPTX1_LINK_CLK 25 +#define DISP_CC_MDSS_DPTX1_LINK_CLK_SRC 26 +#define DISP_CC_MDSS_DPTX1_LINK_DIV_CLK_SRC 27 +#define DISP_CC_MDSS_DPTX1_LINK_INTF_CLK 28 +#define DISP_CC_MDSS_DPTX1_PIXEL0_CLK 29 +#define DISP_CC_MDSS_DPTX1_PIXEL0_CLK_SRC 30 +#define DISP_CC_MDSS_DPTX1_PIXEL1_CLK 31 +#define DISP_CC_MDSS_DPTX1_PIXEL1_CLK_SRC 32 +#define DISP_CC_MDSS_DPTX1_USB_ROUTER_LINK_INTF_CLK 33 +#define DISP_CC_MDSS_DPTX2_AUX_CLK 34 +#define DISP_CC_MDSS_DPTX2_AUX_CLK_SRC 35 +#define DISP_CC_MDSS_DPTX2_LINK_CLK 36 +#define DISP_CC_MDSS_DPTX2_LINK_CLK_SRC 37 +#define DISP_CC_MDSS_DPTX2_LINK_DIV_CLK_SRC 38 +#define DISP_CC_MDSS_DPTX2_LINK_INTF_CLK 39 +#define DISP_CC_MDSS_DPTX2_PIXEL0_CLK 40 +#define DISP_CC_MDSS_DPTX2_PIXEL0_CLK_SRC 41 +#define DISP_CC_MDSS_DPTX2_PIXEL1_CLK 42 +#define DISP_CC_MDSS_DPTX2_PIXEL1_CLK_SRC 43 +#define DISP_CC_MDSS_DPTX2_USB_ROUTER_LINK_INTF_CLK 44 +#define DISP_CC_MDSS_DPTX3_AUX_CLK 45 +#define DISP_CC_MDSS_DPTX3_AUX_CLK_SRC 46 +#define DISP_CC_MDSS_DPTX3_LINK_CLK 47 +#define DISP_CC_MDSS_DPTX3_LINK_CLK_SRC 48 +#define DISP_CC_MDSS_DPTX3_LINK_DIV_CLK_SRC 49 +#define DISP_CC_MDSS_DPTX3_LINK_INTF_CLK 50 +#define DISP_CC_MDSS_DPTX3_PIXEL0_CLK 51 +#define DISP_CC_MDSS_DPTX3_PIXEL0_CLK_SRC 52 +#define DISP_CC_MDSS_ESC0_CLK 53 +#define DISP_CC_MDSS_ESC0_CLK_SRC 54 +#define DISP_CC_MDSS_ESC1_CLK 55 +#define DISP_CC_MDSS_ESC1_CLK_SRC 56 +#define DISP_CC_MDSS_MDP1_CLK 57 +#define DISP_CC_MDSS_MDP_CLK 58 +#define DISP_CC_MDSS_MDP_CLK_SRC 59 +#define DISP_CC_MDSS_MDP_LUT1_CLK 60 +#define DISP_CC_MDSS_MDP_LUT_CLK 61 +#define DISP_CC_MDSS_NON_GDSC_AHB_CLK 62 +#define DISP_CC_MDSS_PCLK0_CLK 63 +#define DISP_CC_MDSS_PCLK0_CLK_SRC 64 +#define DISP_CC_MDSS_PCLK1_CLK 65 +#define DISP_CC_MDSS_PCLK1_CLK_SRC 66 +#define DISP_CC_MDSS_RSCC_AHB_CLK 67 +#define DISP_CC_MDSS_RSCC_VSYNC_CLK 68 +#define DISP_CC_MDSS_VSYNC1_CLK 69 +#define DISP_CC_MDSS_VSYNC_CLK 70 +#define DISP_CC_MDSS_VSYNC_CLK_SRC 71 +#define DISP_CC_PLL0 72 +#define DISP_CC_PLL1 73 +#define DISP_CC_SLEEP_CLK 74 +#define DISP_CC_SLEEP_CLK_SRC 75 +#define DISP_CC_XO_CLK 76 +#define DISP_CC_XO_CLK_SRC 77 + +/* DISP_CC resets */ +#define DISP_CC_MDSS_CORE_BCR 0 +#define DISP_CC_MDSS_CORE_INT2_BCR 1 +#define DISP_CC_MDSS_RSCC_BCR 2 + +/* DISP_CC GDSCR */ +#define MDSS_GDSC 0 +#define MDSS_INT2_GDSC 1 + +#endif -- cgit v1.2.3 From bb213e13cef07c39e102eb61d15604fa839daf94 Mon Sep 17 00:00:00 2001 From: Rajendra Nayak Date: Fri, 2 Feb 2024 20:34:38 +0200 Subject: dt-bindings: clock: qcom: Document the X1E80100 GPU Clock Controller Add bindings documentation for the X1E80100 Graphics Clock Controller. Signed-off-by: Rajendra Nayak Reviewed-by: Krzysztof Kozlowski Signed-off-by: Abel Vesa Link: https://lore.kernel.org/r/20240202-x1e80100-clock-controllers-v4-3-7fb08c861c7c@linaro.org Signed-off-by: Bjorn Andersson --- .../bindings/clock/qcom,sm8450-gpucc.yaml | 2 ++ include/dt-bindings/clock/qcom,x1e80100-gpucc.h | 41 ++++++++++++++++++++++ include/dt-bindings/reset/qcom,x1e80100-gpucc.h | 19 ++++++++++ 3 files changed, 62 insertions(+) create mode 100644 include/dt-bindings/clock/qcom,x1e80100-gpucc.h create mode 100644 include/dt-bindings/reset/qcom,x1e80100-gpucc.h (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/qcom,sm8450-gpucc.yaml b/Documentation/devicetree/bindings/clock/qcom,sm8450-gpucc.yaml index 1a384e8532a5..36974309cf69 100644 --- a/Documentation/devicetree/bindings/clock/qcom,sm8450-gpucc.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,sm8450-gpucc.yaml @@ -18,6 +18,7 @@ description: | include/dt-bindings/clock/qcom,sm8550-gpucc.h include/dt-bindings/reset/qcom,sm8450-gpucc.h include/dt-bindings/reset/qcom,sm8650-gpucc.h + include/dt-bindings/reset/qcom,x1e80100-gpucc.h properties: compatible: @@ -25,6 +26,7 @@ properties: - qcom,sm8450-gpucc - qcom,sm8550-gpucc - qcom,sm8650-gpucc + - qcom,x1e80100-gpucc clocks: items: diff --git a/include/dt-bindings/clock/qcom,x1e80100-gpucc.h b/include/dt-bindings/clock/qcom,x1e80100-gpucc.h new file mode 100644 index 000000000000..61a3a8f3ac43 --- /dev/null +++ b/include/dt-bindings/clock/qcom,x1e80100-gpucc.h @@ -0,0 +1,41 @@ +/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */ +/* + * Copyright (c) 2023, Qualcomm Innovation Center, Inc. All rights reserved. + */ + +#ifndef _DT_BINDINGS_CLK_QCOM_X1E80100_GPU_CC_H +#define _DT_BINDINGS_CLK_QCOM_X1E80100_GPU_CC_H + +/* GPU_CC clocks */ +#define GPU_CC_AHB_CLK 0 +#define GPU_CC_CB_CLK 1 +#define GPU_CC_CRC_AHB_CLK 2 +#define GPU_CC_CX_FF_CLK 3 +#define GPU_CC_CX_GMU_CLK 4 +#define GPU_CC_CXO_AON_CLK 5 +#define GPU_CC_CXO_CLK 6 +#define GPU_CC_DEMET_CLK 7 +#define GPU_CC_DEMET_DIV_CLK_SRC 8 +#define GPU_CC_FF_CLK_SRC 9 +#define GPU_CC_FREQ_MEASURE_CLK 10 +#define GPU_CC_GMU_CLK_SRC 11 +#define GPU_CC_GX_GMU_CLK 12 +#define GPU_CC_GX_VSENSE_CLK 13 +#define GPU_CC_HLOS1_VOTE_GPU_SMMU_CLK 14 +#define GPU_CC_HUB_AON_CLK 15 +#define GPU_CC_HUB_CLK_SRC 16 +#define GPU_CC_HUB_CX_INT_CLK 17 +#define GPU_CC_MEMNOC_GFX_CLK 18 +#define GPU_CC_MND1X_0_GFX3D_CLK 19 +#define GPU_CC_MND1X_1_GFX3D_CLK 20 +#define GPU_CC_PLL0 21 +#define GPU_CC_PLL1 22 +#define GPU_CC_SLEEP_CLK 23 +#define GPU_CC_XO_CLK_SRC 24 +#define GPU_CC_XO_DIV_CLK_SRC 25 + +/* GDSCs */ +#define GPU_CX_GDSC 0 +#define GPU_GX_GDSC 1 + +#endif diff --git a/include/dt-bindings/reset/qcom,x1e80100-gpucc.h b/include/dt-bindings/reset/qcom,x1e80100-gpucc.h new file mode 100644 index 000000000000..32b43e71a16f --- /dev/null +++ b/include/dt-bindings/reset/qcom,x1e80100-gpucc.h @@ -0,0 +1,19 @@ +/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */ +/* + * Copyright (c) 2023, Qualcomm Innovation Center, Inc. All rights reserved. + */ + +#ifndef _DT_BINDINGS_RESET_QCOM_X1E80100_GPU_CC_H +#define _DT_BINDINGS_RESET_QCOM_X1E80100_GPU_CC_H + +#define GPUCC_GPU_CC_ACD_BCR 0 +#define GPUCC_GPU_CC_CB_BCR 1 +#define GPUCC_GPU_CC_CX_BCR 2 +#define GPUCC_GPU_CC_FAST_HUB_BCR 3 +#define GPUCC_GPU_CC_FF_BCR 4 +#define GPUCC_GPU_CC_GFX3D_AON_BCR 5 +#define GPUCC_GPU_CC_GMU_BCR 6 +#define GPUCC_GPU_CC_GX_BCR 7 +#define GPUCC_GPU_CC_XO_BCR 8 + +#endif -- cgit v1.2.3 From 80de9d9dfba1739469b4cc5de5339762b6682e87 Mon Sep 17 00:00:00 2001 From: Abel Vesa Date: Fri, 2 Feb 2024 20:34:39 +0200 Subject: dt-bindings: clock: qcom: Document the X1E80100 TCSR Clock Controller Add bindings documentation for the X1E80100 TCSR Clock Controller. Co-developed-by: Rajendra Nayak Signed-off-by: Rajendra Nayak Reviewed-by: Krzysztof Kozlowski Signed-off-by: Abel Vesa Link: https://lore.kernel.org/r/20240202-x1e80100-clock-controllers-v4-4-7fb08c861c7c@linaro.org Signed-off-by: Bjorn Andersson --- .../bindings/clock/qcom,sm8550-tcsr.yaml | 1 + include/dt-bindings/clock/qcom,x1e80100-tcsr.h | 23 ++++++++++++++++++++++ 2 files changed, 24 insertions(+) create mode 100644 include/dt-bindings/clock/qcom,x1e80100-tcsr.h (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/qcom,sm8550-tcsr.yaml b/Documentation/devicetree/bindings/clock/qcom,sm8550-tcsr.yaml index af16b05eac96..48fdd562d743 100644 --- a/Documentation/devicetree/bindings/clock/qcom,sm8550-tcsr.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,sm8550-tcsr.yaml @@ -23,6 +23,7 @@ properties: - enum: - qcom,sm8550-tcsr - qcom,sm8650-tcsr + - qcom,x1e80100-tcsr - const: syscon clocks: diff --git a/include/dt-bindings/clock/qcom,x1e80100-tcsr.h b/include/dt-bindings/clock/qcom,x1e80100-tcsr.h new file mode 100644 index 000000000000..bae2c4654ee2 --- /dev/null +++ b/include/dt-bindings/clock/qcom,x1e80100-tcsr.h @@ -0,0 +1,23 @@ +/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */ +/* + * Copyright (c) 2023, Linaro Limited + */ + +#ifndef _DT_BINDINGS_CLK_QCOM_X1E80100_TCSR_CC_H +#define _DT_BINDINGS_CLK_QCOM_X1E80100_TCSR_CC_H + +/* TCSR CC clocks */ +#define TCSR_PCIE_2L_4_CLKREF_EN 0 +#define TCSR_PCIE_2L_5_CLKREF_EN 1 +#define TCSR_PCIE_8L_CLKREF_EN 2 +#define TCSR_USB3_MP0_CLKREF_EN 3 +#define TCSR_USB3_MP1_CLKREF_EN 4 +#define TCSR_USB2_1_CLKREF_EN 5 +#define TCSR_UFS_PHY_CLKREF_EN 6 +#define TCSR_USB4_1_CLKREF_EN 7 +#define TCSR_USB4_2_CLKREF_EN 8 +#define TCSR_USB2_2_CLKREF_EN 9 +#define TCSR_PCIE_4L_CLKREF_EN 10 +#define TCSR_EDP_CLKREF_EN 11 + +#endif -- cgit v1.2.3 From 7180f3685de9b420f822f9c880148f15c9793185 Mon Sep 17 00:00:00 2001 From: Rajendra Nayak Date: Fri, 2 Feb 2024 20:34:40 +0200 Subject: dt-bindings: clock: qcom: Document the X1E80100 Camera Clock Controller Add bindings documentation for the X1E80100 Camera Clock Controller. Signed-off-by: Rajendra Nayak Reviewed-by: Krzysztof Kozlowski Signed-off-by: Abel Vesa Link: https://lore.kernel.org/r/20240202-x1e80100-clock-controllers-v4-5-7fb08c861c7c@linaro.org Signed-off-by: Bjorn Andersson --- .../bindings/clock/qcom,sm8450-camcc.yaml | 2 + include/dt-bindings/clock/qcom,x1e80100-camcc.h | 135 +++++++++++++++++++++ 2 files changed, 137 insertions(+) create mode 100644 include/dt-bindings/clock/qcom,x1e80100-camcc.h (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/qcom,sm8450-camcc.yaml b/Documentation/devicetree/bindings/clock/qcom,sm8450-camcc.yaml index 48986460f994..fa0e5b6b02b8 100644 --- a/Documentation/devicetree/bindings/clock/qcom,sm8450-camcc.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,sm8450-camcc.yaml @@ -17,6 +17,7 @@ description: | include/dt-bindings/clock/qcom,sm8450-camcc.h include/dt-bindings/clock/qcom,sm8550-camcc.h include/dt-bindings/clock/qcom,sc8280xp-camcc.h + include/dt-bindings/clock/qcom,x1e80100-camcc.h allOf: - $ref: qcom,gcc.yaml# @@ -27,6 +28,7 @@ properties: - qcom,sc8280xp-camcc - qcom,sm8450-camcc - qcom,sm8550-camcc + - qcom,x1e80100-camcc clocks: items: diff --git a/include/dt-bindings/clock/qcom,x1e80100-camcc.h b/include/dt-bindings/clock/qcom,x1e80100-camcc.h new file mode 100644 index 000000000000..d72fdfb06a7c --- /dev/null +++ b/include/dt-bindings/clock/qcom,x1e80100-camcc.h @@ -0,0 +1,135 @@ +/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */ +/* + * Copyright (c) 2023, Qualcomm Innovation Center, Inc. All rights reserved. + */ + +#ifndef _DT_BINDINGS_CLK_QCOM_CAM_CC_X1E80100_H +#define _DT_BINDINGS_CLK_QCOM_CAM_CC_X1E80100_H + +/* CAM_CC clocks */ +#define CAM_CC_BPS_AHB_CLK 0 +#define CAM_CC_BPS_CLK 1 +#define CAM_CC_BPS_CLK_SRC 2 +#define CAM_CC_BPS_FAST_AHB_CLK 3 +#define CAM_CC_CAMNOC_AXI_NRT_CLK 4 +#define CAM_CC_CAMNOC_AXI_RT_CLK 5 +#define CAM_CC_CAMNOC_AXI_RT_CLK_SRC 6 +#define CAM_CC_CAMNOC_DCD_XO_CLK 7 +#define CAM_CC_CAMNOC_XO_CLK 8 +#define CAM_CC_CCI_0_CLK 9 +#define CAM_CC_CCI_0_CLK_SRC 10 +#define CAM_CC_CCI_1_CLK 11 +#define CAM_CC_CCI_1_CLK_SRC 12 +#define CAM_CC_CORE_AHB_CLK 13 +#define CAM_CC_CPAS_AHB_CLK 14 +#define CAM_CC_CPAS_BPS_CLK 15 +#define CAM_CC_CPAS_FAST_AHB_CLK 16 +#define CAM_CC_CPAS_IFE_0_CLK 17 +#define CAM_CC_CPAS_IFE_1_CLK 18 +#define CAM_CC_CPAS_IFE_LITE_CLK 19 +#define CAM_CC_CPAS_IPE_NPS_CLK 20 +#define CAM_CC_CPAS_SFE_0_CLK 21 +#define CAM_CC_CPHY_RX_CLK_SRC 22 +#define CAM_CC_CSI0PHYTIMER_CLK 23 +#define CAM_CC_CSI0PHYTIMER_CLK_SRC 24 +#define CAM_CC_CSI1PHYTIMER_CLK 25 +#define CAM_CC_CSI1PHYTIMER_CLK_SRC 26 +#define CAM_CC_CSI2PHYTIMER_CLK 27 +#define CAM_CC_CSI2PHYTIMER_CLK_SRC 28 +#define CAM_CC_CSI3PHYTIMER_CLK 29 +#define CAM_CC_CSI3PHYTIMER_CLK_SRC 30 +#define CAM_CC_CSI4PHYTIMER_CLK 31 +#define CAM_CC_CSI4PHYTIMER_CLK_SRC 32 +#define CAM_CC_CSI5PHYTIMER_CLK 33 +#define CAM_CC_CSI5PHYTIMER_CLK_SRC 34 +#define CAM_CC_CSID_CLK 35 +#define CAM_CC_CSID_CLK_SRC 36 +#define CAM_CC_CSID_CSIPHY_RX_CLK 37 +#define CAM_CC_CSIPHY0_CLK 38 +#define CAM_CC_CSIPHY1_CLK 39 +#define CAM_CC_CSIPHY2_CLK 40 +#define CAM_CC_CSIPHY3_CLK 41 +#define CAM_CC_CSIPHY4_CLK 42 +#define CAM_CC_CSIPHY5_CLK 43 +#define CAM_CC_FAST_AHB_CLK_SRC 44 +#define CAM_CC_GDSC_CLK 45 +#define CAM_CC_ICP_AHB_CLK 46 +#define CAM_CC_ICP_CLK 47 +#define CAM_CC_ICP_CLK_SRC 48 +#define CAM_CC_IFE_0_CLK 49 +#define CAM_CC_IFE_0_CLK_SRC 50 +#define CAM_CC_IFE_0_DSP_CLK 51 +#define CAM_CC_IFE_0_FAST_AHB_CLK 52 +#define CAM_CC_IFE_1_CLK 53 +#define CAM_CC_IFE_1_CLK_SRC 54 +#define CAM_CC_IFE_1_DSP_CLK 55 +#define CAM_CC_IFE_1_FAST_AHB_CLK 56 +#define CAM_CC_IFE_LITE_AHB_CLK 57 +#define CAM_CC_IFE_LITE_CLK 58 +#define CAM_CC_IFE_LITE_CLK_SRC 59 +#define CAM_CC_IFE_LITE_CPHY_RX_CLK 60 +#define CAM_CC_IFE_LITE_CSID_CLK 61 +#define CAM_CC_IFE_LITE_CSID_CLK_SRC 62 +#define CAM_CC_IPE_NPS_AHB_CLK 63 +#define CAM_CC_IPE_NPS_CLK 64 +#define CAM_CC_IPE_NPS_CLK_SRC 65 +#define CAM_CC_IPE_NPS_FAST_AHB_CLK 66 +#define CAM_CC_IPE_PPS_CLK 67 +#define CAM_CC_IPE_PPS_FAST_AHB_CLK 68 +#define CAM_CC_JPEG_CLK 69 +#define CAM_CC_JPEG_CLK_SRC 70 +#define CAM_CC_MCLK0_CLK 71 +#define CAM_CC_MCLK0_CLK_SRC 72 +#define CAM_CC_MCLK1_CLK 73 +#define CAM_CC_MCLK1_CLK_SRC 74 +#define CAM_CC_MCLK2_CLK 75 +#define CAM_CC_MCLK2_CLK_SRC 76 +#define CAM_CC_MCLK3_CLK 77 +#define CAM_CC_MCLK3_CLK_SRC 78 +#define CAM_CC_MCLK4_CLK 79 +#define CAM_CC_MCLK4_CLK_SRC 80 +#define CAM_CC_MCLK5_CLK 81 +#define CAM_CC_MCLK5_CLK_SRC 82 +#define CAM_CC_MCLK6_CLK 83 +#define CAM_CC_MCLK6_CLK_SRC 84 +#define CAM_CC_MCLK7_CLK 85 +#define CAM_CC_MCLK7_CLK_SRC 86 +#define CAM_CC_PLL0 87 +#define CAM_CC_PLL0_OUT_EVEN 88 +#define CAM_CC_PLL0_OUT_ODD 89 +#define CAM_CC_PLL1 90 +#define CAM_CC_PLL1_OUT_EVEN 91 +#define CAM_CC_PLL2 92 +#define CAM_CC_PLL3 93 +#define CAM_CC_PLL3_OUT_EVEN 94 +#define CAM_CC_PLL4 95 +#define CAM_CC_PLL4_OUT_EVEN 96 +#define CAM_CC_PLL6 97 +#define CAM_CC_PLL6_OUT_EVEN 98 +#define CAM_CC_PLL8 99 +#define CAM_CC_PLL8_OUT_EVEN 100 +#define CAM_CC_SFE_0_CLK 101 +#define CAM_CC_SFE_0_CLK_SRC 102 +#define CAM_CC_SFE_0_FAST_AHB_CLK 103 +#define CAM_CC_SLEEP_CLK 104 +#define CAM_CC_SLEEP_CLK_SRC 105 +#define CAM_CC_SLOW_AHB_CLK_SRC 106 +#define CAM_CC_XO_CLK_SRC 107 + +/* CAM_CC power domains */ +#define CAM_CC_BPS_GDSC 0 +#define CAM_CC_IFE_0_GDSC 1 +#define CAM_CC_IFE_1_GDSC 2 +#define CAM_CC_IPE_0_GDSC 3 +#define CAM_CC_SFE_0_GDSC 4 +#define CAM_CC_TITAN_TOP_GDSC 5 + +/* CAM_CC resets */ +#define CAM_CC_BPS_BCR 0 +#define CAM_CC_ICP_BCR 1 +#define CAM_CC_IFE_0_BCR 2 +#define CAM_CC_IFE_1_BCR 3 +#define CAM_CC_IPE_0_BCR 4 +#define CAM_CC_SFE_0_BCR 5 + +#endif -- cgit v1.2.3 From 3c28bf48065b38b3551b1944c0b5d37529e98ff2 Mon Sep 17 00:00:00 2001 From: Neil Armstrong Date: Tue, 23 Jan 2024 09:51:02 +0100 Subject: dt-bindings: remoteproc: qcom,sm8550-pas: document the SM8650 PAS Document the DSP Peripheral Authentication Service on the SM8650 Platform. Reviewed-by: Krzysztof Kozlowski Signed-off-by: Neil Armstrong Link: https://lore.kernel.org/r/20240123-topic-sm8650-upstream-remoteproc-v7-1-61283f50162f@linaro.org Signed-off-by: Bjorn Andersson --- .../bindings/remoteproc/qcom,sm8550-pas.yaml | 45 +++++++++++++++++++++- 1 file changed, 44 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,sm8550-pas.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,sm8550-pas.yaml index 58120829fb06..5f63b6b9a8f5 100644 --- a/Documentation/devicetree/bindings/remoteproc/qcom,sm8550-pas.yaml +++ b/Documentation/devicetree/bindings/remoteproc/qcom,sm8550-pas.yaml @@ -19,6 +19,9 @@ properties: - qcom,sm8550-adsp-pas - qcom,sm8550-cdsp-pas - qcom,sm8550-mpss-pas + - qcom,sm8650-adsp-pas + - qcom,sm8650-cdsp-pas + - qcom,sm8650-mpss-pas reg: maxItems: 1 @@ -49,6 +52,8 @@ properties: - description: Memory region for main Firmware authentication - description: Memory region for Devicetree Firmware authentication - description: DSM Memory region + - description: DSM Memory region 2 + - description: Memory region for Qlink Logging required: - compatible @@ -63,6 +68,7 @@ allOf: enum: - qcom,sm8550-adsp-pas - qcom,sm8550-cdsp-pas + - qcom,sm8650-adsp-pas then: properties: interrupts: @@ -71,7 +77,26 @@ allOf: maxItems: 5 memory-region: maxItems: 2 - else: + - if: + properties: + compatible: + enum: + - qcom,sm8650-cdsp-pas + then: + properties: + interrupts: + maxItems: 5 + interrupt-names: + maxItems: 5 + memory-region: + minItems: 3 + maxItems: 3 + - if: + properties: + compatible: + enum: + - qcom,sm8550-mpss-pas + then: properties: interrupts: minItems: 6 @@ -79,12 +104,28 @@ allOf: minItems: 6 memory-region: minItems: 3 + maxItems: 3 + - if: + properties: + compatible: + enum: + - qcom,sm8650-mpss-pas + then: + properties: + interrupts: + minItems: 6 + interrupt-names: + minItems: 6 + memory-region: + minItems: 5 + maxItems: 5 - if: properties: compatible: enum: - qcom,sm8550-adsp-pas + - qcom,sm8650-adsp-pas then: properties: power-domains: @@ -101,6 +142,7 @@ allOf: compatible: enum: - qcom,sm8550-mpss-pas + - qcom,sm8650-mpss-pas then: properties: power-domains: @@ -116,6 +158,7 @@ allOf: compatible: enum: - qcom,sm8550-cdsp-pas + - qcom,sm8650-cdsp-pas then: properties: power-domains: -- cgit v1.2.3 From 869c3d4eef65f3daf2f7a3a4155655f76a11eb87 Mon Sep 17 00:00:00 2001 From: Dmitry Baryshkov Date: Sun, 4 Feb 2024 18:56:35 +0200 Subject: dt-bindings: arm: qcom: drop the superfluous device compatibility schema The idea impressed in the commit b32e592d3c28 ("devicetree: bindings: Document qcom board compatible format") never got actually adopted. As can be seen from the existing board DT files, no device actually used the PMIC / foundry / version parts of the compatible string. Drop this compatibility string description to avoid possible confusion and keep just the generic terms and the SoC list. Fixes: b32e592d3c28 ("devicetree: bindings: Document qcom board compatible format") Signed-off-by: Dmitry Baryshkov Reviewed-by: Krzysztof Kozlowski Reviewed-by: Bjorn Andersson Link: https://lore.kernel.org/r/20240204-qcom-drop-compat-v1-1-69d6cd92aa0e@linaro.org Signed-off-by: Bjorn Andersson --- Documentation/devicetree/bindings/arm/qcom.yaml | 51 +++---------------------- 1 file changed, 5 insertions(+), 46 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml index 1999a5f2f254..2b993b4c51dc 100644 --- a/Documentation/devicetree/bindings/arm/qcom.yaml +++ b/Documentation/devicetree/bindings/arm/qcom.yaml @@ -10,17 +10,10 @@ maintainers: - Bjorn Andersson description: | - Some qcom based bootloaders identify the dtb blob based on a set of - device properties like SoC and platform and revisions of those components. - To support this scheme, we encode this information into the board compatible - string. - - Each board must specify a top-level board compatible string with the following - format: - - compatible = "qcom,[-][-]-[/][-]" - - The 'SoC' and 'board' elements are required. All other elements are optional. + For devices using the Qualcomm SoC the "compatible" properties consists of + one or several "manufacturer,model" strings, describing the device itself, + followed by one or several "qcom," strings, describing the SoC used in + the device. The 'SoC' element must be one of the following strings: @@ -90,43 +83,9 @@ description: | sm8650 x1e80100 - The 'board' element must be one of the following strings: - - adp - cdp - dragonboard - idp - liquid - mtp - qcp - qrd - rb2 - ride - sbc - x100 - - The 'soc_version' and 'board_version' elements take the form of v. - where the minor number may be omitted when it's zero, i.e. v1.0 is the same - as v1. If all versions of the 'board_version' elements match, then a - wildcard '*' should be used, e.g. 'v*'. - - The 'foundry_id' and 'subtype' elements are one or more digits from 0 to 9. - - Examples: - - "qcom,msm8916-v1-cdp-pm8916-v2.1" - - A CDP board with an msm8916 SoC, version 1 paired with a pm8916 PMIC of version - 2.1. - - "qcom,apq8074-v2.0-2-dragonboard/1-v0.1" - - A dragonboard board v0.1 of subtype 1 with an apq8074 SoC version 2, made in - foundry 2. - There are many devices in the list below that run the standard ChromeOS bootloader setup and use the open source depthcharge bootloader to boot the - OS. These devices do not use the scheme described above. For details, see: + OS. These devices use the bootflow explained at https://docs.kernel.org/arch/arm/google/chromebook-boot-flow.html properties: -- cgit v1.2.3 From 6284d33d1749e492596c54a590603d61fb7afc98 Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Thu, 1 Feb 2024 08:58:05 +0100 Subject: dt-bindings: trivial-devices: sort entries alphanumerically Sort entries alphanumerically. This was a semi manual job with help of: cat Documentation/devicetree/bindings/trivial-devices.yaml | grep ' - ' > old cat old | sort -n > new diff -ubB old new Signed-off-by: Krzysztof Kozlowski Acked-by: Conor Dooley Acked-by: Guenter Roeck Link: https://lore.kernel.org/r/20240201075805.7492-1-krzysztof.kozlowski@linaro.org Signed-off-by: Rob Herring --- .../devicetree/bindings/trivial-devices.yaml | 73 +++++++++++----------- 1 file changed, 37 insertions(+), 36 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/trivial-devices.yaml b/Documentation/devicetree/bindings/trivial-devices.yaml index 5b52950e6bfc..41982a41398a 100644 --- a/Documentation/devicetree/bindings/trivial-devices.yaml +++ b/Documentation/devicetree/bindings/trivial-devices.yaml @@ -28,6 +28,7 @@ properties: compatible: items: + # Entries are sorted alphanumerically by the compatible - enum: # Acbel fsg032 power supply - acbel,fsg032 @@ -49,12 +50,12 @@ properties: - ams,iaq-core # i2c serial eeprom (24cxx) - at,24c08 + # i2c h/w elliptic curve crypto module + - atmel,atecc508a # ATSHA204 - i2c h/w symmetric crypto module - atmel,atsha204 # ATSHA204A - i2c h/w symmetric crypto module - atmel,atsha204a - # i2c h/w elliptic curve crypto module - - atmel,atecc508a # BPA-RS600: Power Supply - blutek,bpa-rs600 # Bosch Sensortec pressure, temperature, humididty and VOC sensor @@ -115,20 +116,6 @@ properties: - fsl,mpl3115 # MPR121: Proximity Capacitive Touch Sensor Controller - fsl,mpr121 - # Monolithic Power Systems Inc. multi-phase controller mp2856 - - mps,mp2856 - # Monolithic Power Systems Inc. multi-phase controller mp2857 - - mps,mp2857 - # Monolithic Power Systems Inc. multi-phase controller mp2888 - - mps,mp2888 - # Monolithic Power Systems Inc. multi-phase controller mp2971 - - mps,mp2971 - # Monolithic Power Systems Inc. multi-phase controller mp2973 - - mps,mp2973 - # Monolithic Power Systems Inc. multi-phase controller mp2975 - - mps,mp2975 - # Monolithic Power Systems Inc. multi-phase hot-swap controller mp5990 - - mps,mp5990 # Honeywell Humidicon HIH-6130 humidity/temperature sensor - honeywell,hi6130 # IBM Common Form Factor Power Supply Versions (all versions) @@ -197,6 +184,8 @@ properties: - maxim,max1237 # Temperature Sensor, I2C interface - maxim,max1619 + # 3-Channel Remote Temperature Sensor + - maxim,max31730 # 10-bit 10 kOhm linear programmable voltage divider - maxim,max5481 # 10-bit 50 kOhm linear programmable voltage divider @@ -209,8 +198,6 @@ properties: - maxim,max6621 # 9-Bit/12-Bit Temperature Sensors with I²C-Compatible Serial Interface - maxim,max6625 - # 3-Channel Remote Temperature Sensor - - maxim,max31730 # mCube 3-axis 8-bit digital accelerometer - mcube,mc3230 # Measurement Specialities I2C temperature and humidity sensor @@ -241,8 +228,6 @@ properties: - memsic,mxc6655 # Menlo on-board CPLD trivial SPI device - menlo,m53cpld - # Micron SPI NOR Authenta - - micron,spi-authenta # Microchip differential I2C ADC, 1 Channel, 18 bit - microchip,mcp3421 # Microchip differential I2C ADC, 2 Channel, 18 bit @@ -259,40 +244,56 @@ properties: - microchip,mcp3427 # Microchip differential I2C ADC, 4 Channel, 16 bit - microchip,mcp3428 - # Microchip 7-bit Single I2C Digital POT (5k) - - microchip,mcp4017-502 # Microchip 7-bit Single I2C Digital POT (10k) - microchip,mcp4017-103 - # Microchip 7-bit Single I2C Digital POT (50k) - - microchip,mcp4017-503 # Microchip 7-bit Single I2C Digital POT (100k) - microchip,mcp4017-104 # Microchip 7-bit Single I2C Digital POT (5k) - - microchip,mcp4018-502 + - microchip,mcp4017-502 + # Microchip 7-bit Single I2C Digital POT (50k) + - microchip,mcp4017-503 # Microchip 7-bit Single I2C Digital POT (10k) - microchip,mcp4018-103 - # Microchip 7-bit Single I2C Digital POT (50k) - - microchip,mcp4018-503 # Microchip 7-bit Single I2C Digital POT (100k) - microchip,mcp4018-104 # Microchip 7-bit Single I2C Digital POT (5k) - - microchip,mcp4019-502 + - microchip,mcp4018-502 + # Microchip 7-bit Single I2C Digital POT (50k) + - microchip,mcp4018-503 # Microchip 7-bit Single I2C Digital POT (10k) - microchip,mcp4019-103 - # Microchip 7-bit Single I2C Digital POT (50k) - - microchip,mcp4019-503 # Microchip 7-bit Single I2C Digital POT (100k) - microchip,mcp4019-104 + # Microchip 7-bit Single I2C Digital POT (5k) + - microchip,mcp4019-502 + # Microchip 7-bit Single I2C Digital POT (50k) + - microchip,mcp4019-503 # PWM Fan Speed Controller With Fan Fault Detection - microchip,tc654 # PWM Fan Speed Controller With Fan Fault Detection - microchip,tc655 + # Micron SPI NOR Authenta + - micron,spi-authenta # MiraMEMS DA226 2-axis 14-bit digital accelerometer - miramems,da226 # MiraMEMS DA280 3-axis 14-bit digital accelerometer - miramems,da280 # MiraMEMS DA311 3-axis 12-bit digital accelerometer - miramems,da311 + # Monolithic Power Systems Inc. multi-phase controller mp2856 + - mps,mp2856 + # Monolithic Power Systems Inc. multi-phase controller mp2857 + - mps,mp2857 + # Monolithic Power Systems Inc. multi-phase controller mp2888 + - mps,mp2888 + # Monolithic Power Systems Inc. multi-phase controller mp2971 + - mps,mp2971 + # Monolithic Power Systems Inc. multi-phase controller mp2973 + - mps,mp2973 + # Monolithic Power Systems Inc. multi-phase controller mp2975 + - mps,mp2975 + # Monolithic Power Systems Inc. multi-phase hot-swap controller mp5990 + - mps,mp5990 # Temperature sensor with integrated fan control - national,lm63 # Serial Interface ACPI-Compatible Microprocessor System Hardware Monitor @@ -323,12 +324,12 @@ properties: - samsung,exynos-sataphy-i2c # Semtech sx1301 baseband processor - semtech,sx1301 - # Sensirion low power multi-pixel gas sensor with I2C interface - - sensirion,sgpc3 # Sensirion multi-pixel gas sensor with I2C interface - sensirion,sgp30 # Sensirion gas sensor with I2C interface - sensirion,sgp40 + # Sensirion low power multi-pixel gas sensor with I2C interface + - sensirion,sgpc3 # Sensirion temperature & humidity sensor with I2C interface - sensirion,sht4x # Sensortek 3 axis accelerometer @@ -374,8 +375,6 @@ properties: - ti,lm74 # Temperature sensor with integrated fan control - ti,lm96000 - # I2C Touch-Screen Controller - - ti,tsc2003 # Low Power Digital Temperature Sensor with SMBUS/Two Wire Serial Interface - ti,tmp103 # Thermometer with SPI interface @@ -397,10 +396,12 @@ properties: - ti,tps544b25 - ti,tps544c20 - ti,tps544c25 - # Winbond/Nuvoton H/W Monitor - - winbond,w83793 + # I2C Touch-Screen Controller + - ti,tsc2003 # Vicor Corporation Digital Supervisor - vicor,pli1209bc + # Winbond/Nuvoton H/W Monitor + - winbond,w83793 required: - compatible -- cgit v1.2.3 From 70ff9a91e86850103f71d5920eff6bee81bd2a0d Mon Sep 17 00:00:00 2001 From: Alessandro Marcolini Date: Sat, 3 Feb 2024 14:16:52 +0100 Subject: doc: netlink: specs: tc: add multi-attr to tc-taprio-sched-entry Add multi-attr attribute to tc-taprio-sched-entry to specify multiple entries. Signed-off-by: Alessandro Marcolini Reviewed-by: Donald Hunter Reviewed-by: Jakub Kicinski Link: https://lore.kernel.org/r/0ba5088ea715103a2bce83b12e2dcbdaa08da6ac.1706962013.git.alessandromarcolini99@gmail.com Signed-off-by: Jakub Kicinski --- Documentation/netlink/specs/tc.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/netlink/specs/tc.yaml b/Documentation/netlink/specs/tc.yaml index 4b21b00dbebe..324fa182cd14 100644 --- a/Documentation/netlink/specs/tc.yaml +++ b/Documentation/netlink/specs/tc.yaml @@ -3376,6 +3376,7 @@ attribute-sets: name: entry type: nest nested-attributes: tc-taprio-sched-entry + multi-attr: true - name: tc-taprio-sched-entry attributes: -- cgit v1.2.3 From 7976b003e8bd0f95187e7f7f841ad6501b4c3f01 Mon Sep 17 00:00:00 2001 From: Stefan Herdler Date: Mon, 29 Jan 2024 00:32:45 +0100 Subject: media: docs: uAPI: dvb/osd: completing the documentation The existing documentation of the legacy DVB Decoder API was incomplete. Revising the documentation, adding missing parts and arranging the documentation files new. This patch contains the documentation of osd.h. Link: https://lore.kernel.org/linux-media/20240128233249.32794-3-herdler@nurfuerspam.de Signed-off-by: Stefan Herdler Signed-off-by: Mauro Carvalho Chehab --- .../userspace-api/media/dvb/legacy_dvb_osd.rst | 883 +++++++++++++++++++++ 1 file changed, 883 insertions(+) create mode 100644 Documentation/userspace-api/media/dvb/legacy_dvb_osd.rst (limited to 'Documentation') diff --git a/Documentation/userspace-api/media/dvb/legacy_dvb_osd.rst b/Documentation/userspace-api/media/dvb/legacy_dvb_osd.rst new file mode 100644 index 000000000000..179b66a8016a --- /dev/null +++ b/Documentation/userspace-api/media/dvb/legacy_dvb_osd.rst @@ -0,0 +1,883 @@ +.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later OR GPL-2.0 + +.. c:namespace:: dtv.legacy.osd + +.. _dvb_osd: + +============== +DVB OSD Device +============== + +.. attention:: Do **not** use in new drivers! + See: :ref:`legacy_dvb_decoder_notes` + +The DVB OSD device controls the OnScreen-Display of the AV7110 based +DVB-cards with hardware MPEG2 decoder. It can be accessed through +``/dev/dvb/adapter?/osd0``. +Data types and ioctl definitions can be accessed by including +``linux/dvb/osd.h`` in your application. + +The OSD is not a frame-buffer like on many other cards. +It is a kind of canvas one can draw on. +The color-depth is limited depending on the memory size installed. +An appropriate palette of colors has to be set up. +The installed memory size can be identified with the `OSD_GET_CAPABILITY`_ +ioctl. + +OSD Data Types +============== + +OSD_Command +----------- + +Synopsis +~~~~~~~~ + +.. code-block:: c + + typedef enum { + /* All functions return -2 on "not open" */ + OSD_Close = 1, + OSD_Open, + OSD_Show, + OSD_Hide, + OSD_Clear, + OSD_Fill, + OSD_SetColor, + OSD_SetPalette, + OSD_SetTrans, + OSD_SetPixel, + OSD_GetPixel, + OSD_SetRow, + OSD_SetBlock, + OSD_FillRow, + OSD_FillBlock, + OSD_Line, + OSD_Query, + OSD_Test, + OSD_Text, + OSD_SetWindow, + OSD_MoveWindow, + OSD_OpenRaw, + } OSD_Command; + +Commands +~~~~~~~~ + +.. note:: All functions return -2 on "not open" + +.. flat-table:: + :header-rows: 1 + :stub-columns: 0 + + - .. + + - Command + + - | Used variables of ``struct`` `osd_cmd_t`_. + | Usage{variable} if alternative use. + + - :cspan:`2` Description + + + + - .. + + - ``OSD_Close`` + + - - + + - | Disables OSD and releases the buffers. + | Returns 0 on success. + + - .. + + - ``OSD_Open`` + + - | x0,y0,x1,y1, + | BitPerPixel[2/4/8]{color&0x0F}, + | mix[0..15]{color&0xF0} + + - | Opens OSD with this size and bit depth + | Returns 0 on success, + | -1 on DRAM allocation error, + | -2 on "already open". + + - .. + + - ``OSD_Show`` + + - - + + - | Enables OSD mode. + | Returns 0 on success. + + - .. + + - ``OSD_Hide`` + + - - + + - | Disables OSD mode. + | Returns 0 on success. + + - .. + + - ``OSD_Clear`` + + - - + + - | Sets all pixel to color 0. + | Returns 0 on success. + + - .. + + - ``OSD_Fill`` + + - color + + - | Sets all pixel to color . + | Returns 0 on success. + + - .. + + - ``OSD_SetColor`` + + - | color, + | R{x0},G{y0},B{x1}, + | opacity{y1} + + - | Set palette entry to , and apply + | R,G,B: 0..255 + | R=Red, G=Green, B=Blue + | opacity=0: pixel opacity 0% (only video pixel shows) + | opacity=1..254: pixel opacity as specified in header + | opacity=255: pixel opacity 100% (only OSD pixel shows) + | Returns 0 on success, -1 on error. + + - .. + + - ``OSD_SetPalette`` + + - | firstcolor{color}, + | lastcolor{x0},data + + - | Set a number of entries in the palette. + | Sets the entries "firstcolor" through "lastcolor" from the + array "data". + | Data has 4 byte for each color: + | R,G,B, and a opacity value: 0->transparent, 1..254->mix, + 255->pixel + + - .. + + - ``OSD_SetTrans`` + + - transparency{color} + + - | Sets transparency of mixed pixel (0..15). + | Returns 0 on success. + + - .. + + - ``OSD_SetPixel`` + + - x0,y0,color + + - | Sets pixel , to color number . + | Returns 0 on success, -1 on error. + + - .. + + - ``OSD_GetPixel`` + + - x0,y0 + + - | Returns color number of pixel ,, or -1. + | Command currently not supported by the AV7110! + + - .. + + - ``OSD_SetRow`` + + - x0,y0,x1,data + + - | Fills pixels x0,y through x1,y with the content of data[]. + | Returns 0 on success, -1 on clipping all pixel (no pixel + drawn). + + - .. + + - ``OSD_SetBlock`` + + - | x0,y0,x1,y1, + | increment{color}, + | data + + - | Fills pixels x0,y0 through x1,y1 with the content of data[]. + | Inc contains the width of one line in the data block, + | inc<=0 uses block width as line width. + | Returns 0 on success, -1 on clipping all pixel. + + - .. + + - ``OSD_FillRow`` + + - x0,y0,x1,color + + - | Fills pixels x0,y through x1,y with the color . + | Returns 0 on success, -1 on clipping all pixel. + + - .. + + - ``OSD_FillBlock`` + + - x0,y0,x1,y1,color + + - | Fills pixels x0,y0 through x1,y1 with the color . + | Returns 0 on success, -1 on clipping all pixel. + + - .. + + - ``OSD_Line`` + + - x0,y0,x1,y1,color + + - | Draw a line from x0,y0 to x1,y1 with the color . + | Returns 0 on success. + + - .. + + - ``OSD_Query`` + + - | x0,y0,x1,y1, + | xasp{color}; yasp=11 + + - | Fills parameters with the picture dimensions and the pixel + aspect ratio. + | Returns 0 on success. + | Command currently not supported by the AV7110! + + - .. + + - ``OSD_Test`` + + - - + + - | Draws a test picture. + | For debugging purposes only. + | Returns 0 on success. + - .. + + - ``OSD_Text`` + + - x0,y0,size,color,text + + - Draws a text at position x0,y0 with the color . + + - .. + + - ``OSD_SetWindow`` + + - x0 + + - Set window with number 0` chapter. + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + + - .. + + - ``EINVAL`` + + - Command is out of range. + + +----- + + +OSD_GET_CAPABILITY +------------------ + +Synopsis +~~~~~~~~ + +.. c:macro:: OSD_GET_CAPABILITY + +.. code-block:: c + + int ioctl(int fd, int request = OSD_GET_CAPABILITY, + struct osd_cap_t *cap) + +Arguments +~~~~~~~~~ + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + + - .. + + - ``int fd`` + + - :cspan:`1` File descriptor returned by a previous call + to `open()`_. + + - .. + + - ``int request`` + + - Equals ``OSD_GET_CAPABILITY`` for this command. + + - .. + + - ``unsigned int *cap`` + + - Pointer to the location of the structure `osd_cap_t`_ for this + command. + +Description +~~~~~~~~~~~ + +.. attention:: Do **not** use in new drivers! + See: :ref:`legacy_dvb_decoder_notes` + +This ioctl is used to get the capabilities of the OSD of the AV7110 based +DVB-decoder-card in use. + +.. note:: + The structure osd_cap_t has to be setup by the user and passed to the + driver. + +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 + + + - .. + + - ``EINVAL`` + + - Unsupported capability. + + +----- + + +open() +------ + +Synopsis +~~~~~~~~ + +.. code-block:: c + + #include + +.. c:function:: int open(const char *deviceName, int flags) + +Arguments +~~~~~~~~~ + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + + - .. + + - ``const char *deviceName`` + + - Name of specific OSD device. + + - .. + + - :rspan:`3` ``int flags`` + + - :cspan:`1` A bit-wise OR of the following flags: + + - .. + + - ``O_RDONLY`` + + - read-only access + + - .. + + - ``O_RDWR`` + + - read/write access + + - .. + + - ``O_NONBLOCK`` + - | Open in non-blocking mode + | (blocking mode is the default) + +Description +~~~~~~~~~~~ + +This system call opens a named OSD device (e.g. +``/dev/dvb/adapter?/osd0``) for subsequent use. + +Return Value +~~~~~~~~~~~~ + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + + - .. + + - ``ENODEV`` + + - Device driver not loaded/available. + + - .. + + - ``EINTERNAL`` + + - Internal error. + + - .. + + - ``EBUSY`` + + - Device or resource busy. + + - .. + + - ``EINVAL`` + + - Invalid argument. + + +----- + + +close() +------- + +Synopsis +~~~~~~~~ + +.. c:function:: int close(int fd) + +Arguments +~~~~~~~~~ + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + + - .. + + - ``int fd`` + + - :cspan:`1` File descriptor returned by a previous call + to `open()`_ . + +Description +~~~~~~~~~~~ + +This system call closes a previously opened OSD device. + +Return Value +~~~~~~~~~~~~ + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + + - .. + + - ``EBADF`` + + - fd is not a valid open file descriptor. -- cgit v1.2.3 From 2c7ff90604093c5c6df6a29565daf3a3b108bde4 Mon Sep 17 00:00:00 2001 From: Stefan Herdler Date: Mon, 29 Jan 2024 00:32:46 +0100 Subject: media: docs: uAPI: dvb/audio: completing the documentation (data types) The existing documentation of the legacy DVB Decoder API was incomplete. Revising the documentation, adding missing parts and arranging the documentation files new. This patch contains the documentation of the data types defined in audio.h. Link: https://lore.kernel.org/linux-media/20240128233249.32794-4-herdler@nurfuerspam.de Signed-off-by: Stefan Herdler Signed-off-by: Mauro Carvalho Chehab --- .../userspace-api/media/dvb/legacy_dvb_audio.rst | 447 +++++++++++++++++++++ 1 file changed, 447 insertions(+) create mode 100644 Documentation/userspace-api/media/dvb/legacy_dvb_audio.rst (limited to 'Documentation') diff --git a/Documentation/userspace-api/media/dvb/legacy_dvb_audio.rst b/Documentation/userspace-api/media/dvb/legacy_dvb_audio.rst new file mode 100644 index 000000000000..d15088748f55 --- /dev/null +++ b/Documentation/userspace-api/media/dvb/legacy_dvb_audio.rst @@ -0,0 +1,447 @@ +.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later OR GPL-2.0 + +.. c:namespace:: dtv.legacy.audio + +.. _dvb_audio: + +================ +DVB Audio Device +================ + +.. attention:: Do **not** use in new drivers! + See: :ref:`legacy_dvb_decoder_notes` + +The DVB audio device controls the MPEG2 audio decoder of the DVB +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 most DVB 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. Use :ref:`V4L2 ioctls