From 190362e03bed3f7bde7635f14c955fc9ed96eb78 Mon Sep 17 00:00:00 2001 From: Peng Fan Date: Fri, 21 Oct 2022 12:15:20 +0800 Subject: dt-bindings: remoteproc: imx_rproc: Support i.MX8QXP Add i.MX8QXP compatible Add a new property fsl,resource-id for SoC which supports SCFW. This property is used to check whether remote process is under control of Linux or not. Add fsl,entry-address to specify the entry address which used by SCFW to kick M4. To i.MX8QM/QXP, when M4 is in the same hardware partition with Cortex-A cores, need power up M4 through SCFW, then M4 could start. So introduce power-domains property. Reviewed-by: Rob Herring Signed-off-by: Peng Fan Link: https://lore.kernel.org/r/20221021041526.3696483-2-peng.fan@oss.nxp.com Signed-off-by: Mathieu Poirier --- .../devicetree/bindings/remoteproc/fsl,imx-rproc.yaml | 15 +++++++++++++++ 1 file changed, 15 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml b/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml index 3a1f59ad79e2..70322e57b6ff 100644 --- a/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml +++ b/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml @@ -22,6 +22,7 @@ properties: - fsl,imx8mn-cm7 - fsl,imx8mp-cm7 - fsl,imx8mq-cm4 + - fsl,imx8qxp-cm4 - fsl,imx8ulp-cm33 - fsl,imx93-cm33 @@ -54,12 +55,26 @@ properties: minItems: 1 maxItems: 32 + power-domains: + maxItems: 8 + fsl,auto-boot: $ref: /schemas/types.yaml#/definitions/flag description: Indicate whether need to load the default firmware and start the remote processor automatically. + fsl,entry-address: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + Specify CPU entry address for SCU enabled processor. + + fsl,resource-id: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + This property is to specify the resource id of the remote processor in SoC + which supports SCFW + required: - compatible -- cgit v1.2.3 From 505066645f3f14c15abd0875654fbc7b0610ca2e Mon Sep 17 00:00:00 2001 From: Peng Fan Date: Fri, 21 Oct 2022 12:15:21 +0800 Subject: dt-bindings: remoteproc: imx_rproc: Support i.MX8QM Add i.MX8QM compatible. Reviewed-by: Rob Herring Signed-off-by: Peng Fan Link: https://lore.kernel.org/r/20221021041526.3696483-3-peng.fan@oss.nxp.com Signed-off-by: Mathieu Poirier --- Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml b/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml index 70322e57b6ff..ad3b8d4ccd91 100644 --- a/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml +++ b/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml @@ -22,6 +22,7 @@ properties: - fsl,imx8mn-cm7 - fsl,imx8mp-cm7 - fsl,imx8mq-cm4 + - fsl,imx8qm-cm4 - fsl,imx8qxp-cm4 - fsl,imx8ulp-cm33 - fsl,imx93-cm33 -- cgit v1.2.3 From d683c67c5f50802b9b14ea29d89d66a25327e965 Mon Sep 17 00:00:00 2001 From: Daniel Pinto Date: Mon, 10 Oct 2022 12:16:29 +0100 Subject: fs/ntfs3: Document windows_names mount option Add documentation for windows_names mount option. Signed-off-by: Daniel Pinto Signed-off-by: Konstantin Komarov --- Documentation/filesystems/ntfs3.rst | 8 ++++++++ 1 file changed, 8 insertions(+) (limited to 'Documentation') diff --git a/Documentation/filesystems/ntfs3.rst b/Documentation/filesystems/ntfs3.rst index d67ccd22c63b..cda8e0e010d4 100644 --- a/Documentation/filesystems/ntfs3.rst +++ b/Documentation/filesystems/ntfs3.rst @@ -75,6 +75,14 @@ this table marked with no it means default is without **no**. - Files with the Windows-specific SYSTEM (FILE_ATTRIBUTE_SYSTEM) attribute will be marked as system immutable files. + * - windows_names + - Prevents the creation of files and directories with a name not allowed + by Windows, either because it contains some not allowed character (which + are the characters " * / : < > ? \\ | and those whose code is less than + 0x20), because the name (with or without extension) is a reserved file + name (CON, AUX, NUL, PRN, LPT1-9, COM1-9) or because the last character + is a space or a dot. Existing such files can still be read and renamed. + * - discard - Enable support of the TRIM command for improved performance on delete operations, which is recommended for use with the solid-state drives -- cgit v1.2.3 From 60adc860ca7d7a95d5befd2d3c3e644d23706b2c Mon Sep 17 00:00:00 2001 From: Daniel Pinto Date: Mon, 10 Oct 2022 12:35:46 +0100 Subject: fs/ntfs3: Document the hidedotfiles mount option Add documentation for the hidedotfiles mount option. Signed-off-by: Daniel Pinto Signed-off-by: Konstantin Komarov --- Documentation/filesystems/ntfs3.rst | 6 ++++++ 1 file changed, 6 insertions(+) (limited to 'Documentation') diff --git a/Documentation/filesystems/ntfs3.rst b/Documentation/filesystems/ntfs3.rst index cda8e0e010d4..3a20ecd13d45 100644 --- a/Documentation/filesystems/ntfs3.rst +++ b/Documentation/filesystems/ntfs3.rst @@ -75,6 +75,12 @@ this table marked with no it means default is without **no**. - Files with the Windows-specific SYSTEM (FILE_ATTRIBUTE_SYSTEM) attribute will be marked as system immutable files. + * - hidedotfiles + - Updates the Windows-specific HIDDEN (FILE_ATTRIBUTE_HIDDEN) attribute + when creating and moving or renaming files. Files whose names start + with a dot will have the HIDDEN attribute set and files whose names + do not start with a dot will have it unset. + * - windows_names - Prevents the creation of files and directories with a name not allowed by Windows, either because it contains some not allowed character (which -- cgit v1.2.3 From dc0fcc99b1756c3c703326aa0015ed73fc4e9a73 Mon Sep 17 00:00:00 2001 From: Daniel Pinto Date: Mon, 10 Oct 2022 12:37:13 +0100 Subject: fs/ntfs3: Rename hidedotfiles mount option to hide_dot_files The hidedotfiles mount option provides the same functionality as the NTFS-3G hide_dot_files mount option. As such, it should be named the same for compatibility with NTGS-3G. Rename the hidedotfiles to hide_dot_files for compatbility with NTFS-3G. Signed-off-by: Daniel Pinto Signed-off-by: Konstantin Komarov --- Documentation/filesystems/ntfs3.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/filesystems/ntfs3.rst b/Documentation/filesystems/ntfs3.rst index 3a20ecd13d45..7b1e78cf01ad 100644 --- a/Documentation/filesystems/ntfs3.rst +++ b/Documentation/filesystems/ntfs3.rst @@ -75,7 +75,7 @@ this table marked with no it means default is without **no**. - Files with the Windows-specific SYSTEM (FILE_ATTRIBUTE_SYSTEM) attribute will be marked as system immutable files. - * - hidedotfiles + * - hide_dot_files - Updates the Windows-specific HIDDEN (FILE_ATTRIBUTE_HIDDEN) attribute when creating and moving or renaming files. Files whose names start with a dot will have the HIDDEN attribute set and files whose names -- cgit v1.2.3 From d49436c34448e01eb6ab85413af87de73c99494d Mon Sep 17 00:00:00 2001 From: Daniel Pinto Date: Mon, 10 Oct 2022 12:46:12 +0100 Subject: fs/ntfs3: Document system.ntfs_attrib_be extended attribute Add documentation for system.ntfs_attrib_be extended attribute. Signed-off-by: Daniel Pinto Signed-off-by: Konstantin Komarov --- Documentation/filesystems/ntfs3.rst | 5 +++++ 1 file changed, 5 insertions(+) (limited to 'Documentation') diff --git a/Documentation/filesystems/ntfs3.rst b/Documentation/filesystems/ntfs3.rst index 7b1e78cf01ad..5aa102bd72c2 100644 --- a/Documentation/filesystems/ntfs3.rst +++ b/Documentation/filesystems/ntfs3.rst @@ -25,6 +25,11 @@ versions up to 3.1. File system type to use on mount is *ntfs3*. Note: Applied to empty files, this allows to switch type between sparse(0x200), compressed(0x800) and normal. + - *system.ntfs_attrib_be* gets/sets ntfs file/dir attributes. + + Same value as system.ntfs_attrib but always represent as big-endian + (endianness of system.ntfs_attrib is the same as of the CPU). + Mount Options ============= -- cgit v1.2.3 From 5719efcc5abb34ceb47b03e58709d99713f80db1 Mon Sep 17 00:00:00 2001 From: Geert Uytterhoeven Date: Mon, 21 Nov 2022 17:13:02 +0100 Subject: dt-bindings: pwm: renesas,pwm-rcar: Add r8a779g0 support MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Document support for the PWM timers in the Renesas R-Car V4H (R8A779G0) SoC. Based on a patch in the BSP by CongDang. Signed-off-by: Geert Uytterhoeven Acked-by: Krzysztof Kozlowski Reviewed-by: Wolfram Sang Acked-by: Uwe Kleine-König Signed-off-by: Thierry Reding --- Documentation/devicetree/bindings/pwm/renesas,pwm-rcar.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pwm/renesas,pwm-rcar.yaml b/Documentation/devicetree/bindings/pwm/renesas,pwm-rcar.yaml index 1c94acbc2b4a..4c8097010687 100644 --- a/Documentation/devicetree/bindings/pwm/renesas,pwm-rcar.yaml +++ b/Documentation/devicetree/bindings/pwm/renesas,pwm-rcar.yaml @@ -35,6 +35,7 @@ properties: - renesas,pwm-r8a77980 # R-Car V3H - renesas,pwm-r8a77990 # R-Car E3 - renesas,pwm-r8a77995 # R-Car D3 + - renesas,pwm-r8a779g0 # R-Car V4H - const: renesas,pwm-rcar reg: -- cgit v1.2.3 From 50315945d178eebec4e8e2c50c265767ddb926eb Mon Sep 17 00:00:00 2001 From: Geert Uytterhoeven Date: Mon, 21 Nov 2022 17:13:42 +0100 Subject: dt-bindings: pwm: renesas,tpu: Add r8a779g0 support MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Document support for the 16-Bit Timer Pulse Unit (TPU) in the Renesas R-Car V4H (R8A779G0) SoC. Based on a patch in the BSP by CongDang. Signed-off-by: Geert Uytterhoeven Acked-by: Krzysztof Kozlowski Reviewed-by: Laurent Pinchart Reviewed-by: Wolfram Sang Acked-by: Uwe Kleine-König Signed-off-by: Thierry Reding --- Documentation/devicetree/bindings/pwm/renesas,tpu-pwm.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pwm/renesas,tpu-pwm.yaml b/Documentation/devicetree/bindings/pwm/renesas,tpu-pwm.yaml index c6b2ab56b7fe..a3e52b22dd18 100644 --- a/Documentation/devicetree/bindings/pwm/renesas,tpu-pwm.yaml +++ b/Documentation/devicetree/bindings/pwm/renesas,tpu-pwm.yaml @@ -40,6 +40,7 @@ properties: - renesas,tpu-r8a77970 # R-Car V3M - renesas,tpu-r8a77980 # R-Car V3H - renesas,tpu-r8a779a0 # R-Car V3U + - renesas,tpu-r8a779g0 # R-Car V4H - const: renesas,tpu reg: -- cgit v1.2.3 From ba4fde74fc7fdd5ef37066a42721f37621cb80f2 Mon Sep 17 00:00:00 2001 From: Tanmay Shah Date: Mon, 14 Nov 2022 15:39:35 -0800 Subject: dt-bindings: remoteproc: Add Xilinx RPU subsystem bindings Xilinx ZynqMP platform has dual-core ARM Cortex R5 Realtime Processing Unit(RPU) subsystem. This patch adds dt-bindings for RPU subsystem (cluster). Signed-off-by: Tanmay Shah Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20221114233940.2096237-2-tanmay.shah@amd.com Signed-off-by: Mathieu Poirier --- .../bindings/remoteproc/xlnx,zynqmp-r5fss.yaml | 135 +++++++++++++++++++++ 1 file changed, 135 insertions(+) create mode 100644 Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml b/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml new file mode 100644 index 000000000000..9f677367dd9f --- /dev/null +++ b/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml @@ -0,0 +1,135 @@ +# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/remoteproc/xlnx,zynqmp-r5fss.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Xilinx R5F processor subsystem + +maintainers: + - Ben Levinsky + - Tanmay Shah + +description: | + The Xilinx platforms include a pair of Cortex-R5F processors (RPU) for + real-time processing based on the Cortex-R5F processor core from ARM. + The Cortex-R5F processor implements the Arm v7-R architecture and includes a + floating-point unit that implements the Arm VFPv3 instruction set. + +properties: + compatible: + const: xlnx,zynqmp-r5fss + + xlnx,cluster-mode: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1, 2] + description: | + The RPU MPCore can operate in split mode (Dual-processor performance), Safety + lock-step mode(Both RPU cores execute the same code in lock-step, + clock-for-clock) or Single CPU mode (RPU core 0 is held in reset while + core 1 runs normally). The processor does not support dynamic configuration. + Switching between modes is only permitted immediately after a processor reset. + If set to 1 then lockstep mode and if 0 then split mode. + If set to 2 then single CPU mode. When not defined, default will be lockstep mode. + In summary, + 0: split mode + 1: lockstep mode (default) + 2: single cpu mode + +patternProperties: + "^r5f-[a-f0-9]+$": + type: object + description: | + The RPU is located in the Low Power Domain of the Processor Subsystem. + Each processor includes separate L1 instruction and data caches and + tightly coupled memories (TCM). System memory is cacheable, but the TCM + memory space is non-cacheable. + + Each RPU contains one 64KB memory and two 32KB memories that + are accessed via the TCM A and B port interfaces, for a total of 128KB + per processor. In lock-step mode, the processor has access to 256KB of + TCM memory. + + properties: + compatible: + const: xlnx,zynqmp-r5f + + power-domains: + maxItems: 1 + + mboxes: + minItems: 1 + items: + - description: mailbox channel to send data to RPU + - description: mailbox channel to receive data from RPU + + mbox-names: + minItems: 1 + items: + - const: tx + - const: rx + + sram: + $ref: /schemas/types.yaml#/definitions/phandle-array + minItems: 1 + maxItems: 8 + items: + maxItems: 1 + description: | + phandles to one or more reserved on-chip SRAM regions. Other than TCM, + the RPU can execute instructions and access data from the OCM memory, + the main DDR memory, and other system memories. + + The regions should be defined as child nodes of the respective SRAM + node, and should be defined as per the generic bindings in + Documentation/devicetree/bindings/sram/sram.yaml + + memory-region: + description: | + List of phandles to the reserved memory regions associated with the + remoteproc device. This is variable and describes the memories shared with + the remote processor (e.g. remoteproc firmware and carveouts, rpmsg + vrings, ...). This reserved memory region will be allocated in DDR memory. + minItems: 1 + maxItems: 8 + items: + - description: region used for RPU firmware image section + - description: vdev buffer + - description: vring0 + - description: vring1 + additionalItems: true + + required: + - compatible + - power-domains + + unevaluatedProperties: false + +required: + - compatible + +additionalProperties: false + +examples: + - | + remoteproc { + compatible = "xlnx,zynqmp-r5fss"; + xlnx,cluster-mode = <1>; + + r5f-0 { + compatible = "xlnx,zynqmp-r5f"; + power-domains = <&zynqmp_firmware 0x7>; + memory-region = <&rproc_0_fw_image>, <&rpu0vdev0buffer>, <&rpu0vdev0vring0>, <&rpu0vdev0vring1>; + mboxes = <&ipi_mailbox_rpu0 0>, <&ipi_mailbox_rpu0 1>; + mbox-names = "tx", "rx"; + }; + + r5f-1 { + compatible = "xlnx,zynqmp-r5f"; + power-domains = <&zynqmp_firmware 0x8>; + memory-region = <&rproc_1_fw_image>, <&rpu1vdev0buffer>, <&rpu1vdev0vring0>, <&rpu1vdev0vring1>; + mboxes = <&ipi_mailbox_rpu1 0>, <&ipi_mailbox_rpu1 1>; + mbox-names = "tx", "rx"; + }; + }; +... -- cgit v1.2.3 From 763ab98687404d924b6612f7c9c8430333d31229 Mon Sep 17 00:00:00 2001 From: Bryan O'Donoghue Date: Wed, 28 Sep 2022 01:05:17 +0100 Subject: dt-bindings: mfd: qcom,spmi-pmic: Drop PWM reg dependency The PWM node is not a separate device and is expected to be part of parent SPMI PMIC node, thus it obtains the address space from the parent. One IO address in "reg" is also not correct description because LPG block maps to several regions. Fixes: 3f5117be9584 ("dt-bindings: mfd: convert to yaml Qualcomm SPMI PMIC") Suggested-by: Krzysztof Kozlowski Reviewed-by: Krzysztof Kozlowski Signed-off-by: Bryan O'Donoghue Signed-off-by: Lee Jones Link: https://lore.kernel.org/r/20220928000517.228382-2-bryan.odonoghue@linaro.org --- Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.yaml | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.yaml b/Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.yaml index 6a3e3ede1ede..777f2da52f1e 100644 --- a/Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.yaml +++ b/Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.yaml @@ -98,6 +98,10 @@ properties: type: object $ref: /schemas/regulator/qcom,spmi-regulator.yaml# + pwm: + type: object + $ref: /schemas/leds/leds-qcom-lpg.yaml# + patternProperties: "^adc@[0-9a-f]+$": type: object @@ -123,10 +127,6 @@ patternProperties: type: object $ref: /schemas/power/reset/qcom,pon.yaml# - "pwm@[0-9a-f]+$": - type: object - $ref: /schemas/leds/leds-qcom-lpg.yaml# - "^rtc@[0-9a-f]+$": type: object $ref: /schemas/rtc/qcom-pm8xxx-rtc.yaml# -- cgit v1.2.3 From 03317a86df980f255b80a9f7122ffa16b3451f3b Mon Sep 17 00:00:00 2001 From: Johan Hovold Date: Fri, 7 Oct 2022 14:11:10 +0200 Subject: dt-bindings: mfd: qcom,tcsr: Add sc8280xp binding Add a binding for the SC8280XP TCSR. Signed-off-by: Johan Hovold Reviewed-by: Krzysztof Kozlowski Signed-off-by: Lee Jones Link: https://lore.kernel.org/r/20221007121110.5432-1-johan+linaro@kernel.org --- Documentation/devicetree/bindings/mfd/qcom,tcsr.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mfd/qcom,tcsr.yaml b/Documentation/devicetree/bindings/mfd/qcom,tcsr.yaml index b12809b5cc22..cb0ae38a777f 100644 --- a/Documentation/devicetree/bindings/mfd/qcom,tcsr.yaml +++ b/Documentation/devicetree/bindings/mfd/qcom,tcsr.yaml @@ -21,6 +21,7 @@ properties: - qcom,qcs404-tcsr - qcom,sc7180-tcsr - qcom,sc7280-tcsr + - qcom,sc8280xp-tcsr - qcom,sdm630-tcsr - qcom,sdm845-tcsr - qcom,sm8150-tcsr -- cgit v1.2.3 From 4bef4d519b01cf15818b81a3fbf62d9f51612ad3 Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Thu, 8 Sep 2022 10:09:38 +0200 Subject: dt-bindings: mfd: qcom,spmi-pmic: Use generic node name "gpio" GPIO controller nodes are named by convention just "gpio", not "gpios". Signed-off-by: Krzysztof Kozlowski Acked-by: Rob Herring Signed-off-by: Lee Jones Link: https://lore.kernel.org/r/20220908080938.29199-3-krzysztof.kozlowski@linaro.org --- Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.yaml | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.yaml b/Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.yaml index 777f2da52f1e..c8362efd4345 100644 --- a/Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.yaml +++ b/Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.yaml @@ -119,7 +119,7 @@ patternProperties: type: object $ref: /schemas/extcon/qcom,pm8941-misc.yaml# - "gpio(s)?@[0-9a-f]+$": + "gpio@[0-9a-f]+$": type: object $ref: /schemas/pinctrl/qcom,pmic-gpio.yaml# @@ -199,7 +199,7 @@ examples: #address-cells = <1>; #size-cells = <0>; - pmi8998_gpio: gpios@c000 { + pmi8998_gpio: gpio@c000 { compatible = "qcom,pmi8998-gpio", "qcom,spmi-gpio"; reg = <0xc000>; gpio-controller; @@ -284,7 +284,7 @@ examples: }; }; - pm6150_gpio: gpios@c000 { + pm6150_gpio: gpio@c000 { compatible = "qcom,pm6150-gpio", "qcom,spmi-gpio"; reg = <0xc000>; gpio-controller; -- cgit v1.2.3 From 118ee241c423636c03527eada8f672301514751e Mon Sep 17 00:00:00 2001 From: Fabien Parent Date: Thu, 20 Oct 2022 18:20:45 +0200 Subject: dt-bindings: mfd: mt6397: Add binding for MT6357 Add binding documentation for the MT6357 PMIC. Signed-off-by: Fabien Parent Signed-off-by: Alexandre Mergnat Acked-by: Rob Herring Signed-off-by: Lee Jones Link: https://lore.kernel.org/r/20221005-mt6357-support-v3-1-7e0bd7c315b2@baylibre.com --- Documentation/devicetree/bindings/mfd/mt6397.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mfd/mt6397.txt b/Documentation/devicetree/bindings/mfd/mt6397.txt index 0088442efca1..518986c44880 100644 --- a/Documentation/devicetree/bindings/mfd/mt6397.txt +++ b/Documentation/devicetree/bindings/mfd/mt6397.txt @@ -21,6 +21,7 @@ Required properties: compatible: "mediatek,mt6323" for PMIC MT6323 "mediatek,mt6331" for PMIC MT6331 and MT6332 + "mediatek,mt6357" for PMIC MT6357 "mediatek,mt6358" for PMIC MT6358 and MT6366 "mediatek,mt6359" for PMIC MT6359 "mediatek,mt6397" for PMIC MT6397 -- cgit v1.2.3 From 5ed6cf8c0d55497f010c80fcf4c011e6febf9673 Mon Sep 17 00:00:00 2001 From: Matt Ranostay Date: Tue, 25 Oct 2022 01:00:14 -0700 Subject: dt-bindings: mfd: ti,am3359-tscadc: Add missing power-domains property Add optional power-domains property to avoid the following dt-schema failures: tscadc@40200000: 'power-domains' does not match any of the regexes: 'pinctrl-[0-9]+' Signed-off-by: Matt Ranostay Reviewed-by: Miquel Raynal Acked-by: Krzysztof Kozlowski Signed-off-by: Lee Jones Link: https://lore.kernel.org/r/20221025080014.403457-1-mranostay@ti.com --- Documentation/devicetree/bindings/mfd/ti,am3359-tscadc.yaml | 3 +++ 1 file changed, 3 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mfd/ti,am3359-tscadc.yaml b/Documentation/devicetree/bindings/mfd/ti,am3359-tscadc.yaml index 34bf6a01436f..23a63265be3c 100644 --- a/Documentation/devicetree/bindings/mfd/ti,am3359-tscadc.yaml +++ b/Documentation/devicetree/bindings/mfd/ti,am3359-tscadc.yaml @@ -52,6 +52,9 @@ properties: type: object description: Magnetic reader + power-domains: + maxItems: 1 + required: - compatible - reg -- cgit v1.2.3 From 9f8fa5e9b2fc90855fe4df770c4cf0fa653e5672 Mon Sep 17 00:00:00 2001 From: Matt Ranostay Date: Sun, 23 Oct 2022 20:54:04 -0700 Subject: dt-bindings: mfd: ti,j721e-system-controller: Add compatible strings for other platforms There are multiple J7 based platforms, and the j721e-system-controller shouldn't be define in non-j721e devices device trees. This is mainly for clarity; but also useful in case there are future erratas that need to be fixed for a specific platform. Signed-off-by: Matt Ranostay Acked-by: Rob Herring Signed-off-by: Lee Jones Link: https://lore.kernel.org/r/20221024035405.366208-2-mranostay@ti.com --- Documentation/devicetree/bindings/mfd/ti,j721e-system-controller.yaml | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mfd/ti,j721e-system-controller.yaml b/Documentation/devicetree/bindings/mfd/ti,j721e-system-controller.yaml index 873ee0c0973f..76ef4352e13c 100644 --- a/Documentation/devicetree/bindings/mfd/ti,j721e-system-controller.yaml +++ b/Documentation/devicetree/bindings/mfd/ti,j721e-system-controller.yaml @@ -26,7 +26,9 @@ properties: compatible: items: - enum: + - ti,j7200-system-controller - ti,j721e-system-controller + - ti,j721s2-system-controller - const: syscon - const: simple-mfd -- cgit v1.2.3 From 6af338b0011727da68c32ba79f8dfab8524fc4ae Mon Sep 17 00:00:00 2001 From: Neil Armstrong Date: Fri, 21 Oct 2022 11:06:41 +0200 Subject: dt-bindings: mfd: qcom-pm8xxx: Document qcom,pm8921 as fallback of qcom,pm8018 The PM8018 is used as compatible with PM8921 on the MDM9615, document this situation, and an example section to validate this change. Reviewed-by: Rob Herring Signed-off-by: Neil Armstrong Signed-off-by: Lee Jones Link: https://lore.kernel.org/r/20220928-mdm9615-dt-schema-fixes-v4-5-dac2dfaac703@linaro.org --- .../devicetree/bindings/mfd/qcom-pm8xxx.yaml | 33 ++++++++++++++++++---- 1 file changed, 28 insertions(+), 5 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mfd/qcom-pm8xxx.yaml b/Documentation/devicetree/bindings/mfd/qcom-pm8xxx.yaml index 61bd0b3ce02f..84b87f01e029 100644 --- a/Documentation/devicetree/bindings/mfd/qcom-pm8xxx.yaml +++ b/Documentation/devicetree/bindings/mfd/qcom-pm8xxx.yaml @@ -15,11 +15,15 @@ description: | properties: compatible: - enum: - - qcom,pm8018 - - qcom,pm8058 - - qcom,pm8821 - - qcom,pm8921 + oneOf: + - enum: + - qcom,pm8058 + - qcom,pm8821 + - qcom,pm8921 + - items: + - enum: + - qcom,pm8018 + - const: qcom,pm8921 reg: maxItems: 1 @@ -52,4 +56,23 @@ required: - interrupt-controller additionalProperties: false + +examples: + - | + #include + ssbi { + #address-cells = <1>; + #size-cells = <0>; + pmic@0 { + compatible = "qcom,pm8921"; + reg = <0>; + #address-cells = <1>; + #size-cells = <0>; + interrupt-controller; + #interrupt-cells = <2>; + + interrupt-parent = <&tlmm>; + interrupts = <32 IRQ_TYPE_EDGE_RISING>; + }; + }; ... -- cgit v1.2.3 From e112f2de151badd38a9c8a098a1f92f2369349cb Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Rafa=C5=82=20Mi=C5=82ecki?= Date: Fri, 28 Oct 2022 13:53:53 +0200 Subject: dt-bindings: timer: Add Broadcom's BCMBCA timers MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit BCA is a big set / family of Broadcom devices sharing multiple hardware blocks. One of them is timer that actually exists in two versions. It's a part of TWD MFD block. Add binding for it so SoCs can be properly described. Linux (and probably any other OS) doesn't really seem to need a driver for it. it may be needed for bootloaders (e.g. U-Boot) though. Especially for SoCs with CPUs other than Cortex-A9 (which contains arch timers). Signed-off-by: Rafał Miłecki Reviewed-by: Krzysztof Kozlowski Signed-off-by: Lee Jones Link: https://lore.kernel.org/r/20221028115353.13881-1-zajec5@gmail.com --- .../devicetree/bindings/mfd/brcm,twd.yaml | 8 +++++ .../bindings/timer/brcm,bcmbca-timer.yaml | 40 ++++++++++++++++++++++ 2 files changed, 48 insertions(+) create mode 100644 Documentation/devicetree/bindings/timer/brcm,bcmbca-timer.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mfd/brcm,twd.yaml b/Documentation/devicetree/bindings/mfd/brcm,twd.yaml index 634526f790b8..e5136a37b0a3 100644 --- a/Documentation/devicetree/bindings/mfd/brcm,twd.yaml +++ b/Documentation/devicetree/bindings/mfd/brcm,twd.yaml @@ -36,6 +36,9 @@ properties: const: 1 patternProperties: + '^timer@[a-f0-9]+$': + $ref: /schemas/timer/brcm,bcmbca-timer.yaml + '^watchdog@[a-f0-9]+$': $ref: /schemas/watchdog/brcm,bcm7038-wdt.yaml @@ -54,6 +57,11 @@ examples: #address-cells = <1>; #size-cells = <1>; + timer@0 { + compatible = "brcm,bcm63138-timer"; + reg = <0x0 0x28>; + }; + watchdog@28 { compatible = "brcm,bcm7038-wdt"; reg = <0x28 0x8>; diff --git a/Documentation/devicetree/bindings/timer/brcm,bcmbca-timer.yaml b/Documentation/devicetree/bindings/timer/brcm,bcmbca-timer.yaml new file mode 100644 index 000000000000..6707d9760857 --- /dev/null +++ b/Documentation/devicetree/bindings/timer/brcm,bcmbca-timer.yaml @@ -0,0 +1,40 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/timer/brcm,bcmbca-timer.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Broadcom Broadband SoC timer + +maintainers: + - Rafał Miłecki + +properties: + compatible: + oneOf: + - const: brcm,bcm6345-timer + description: > + An old block with 3 timers. + + It can be found in BCM6345, BCM6838 and BCM63268. + - const: brcm,bcm63138-timer + description: > + Updated block with 4 timers and control regs at the beginning. + + It can be found in newer SoCs, e.g. BCM63138, BCM63148, BCM63381, + BCM68360, BCM6848, BCM6858, BCM4908. + + reg: + maxItems: 1 + +additionalProperties: false + +required: + - reg + +examples: + - | + timer@fffe0200 { + compatible = "brcm,bcm6345-timer"; + reg = <0xfffe0200 0x1c>; + }; -- cgit v1.2.3 From 9f0345e335b2eccf56faf45fb9706b40052acbdf Mon Sep 17 00:00:00 2001 From: Quan Nguyen Date: Mon, 31 Oct 2022 09:44:40 +0700 Subject: dt-bindings: mfd: Add bindings for Ampere Altra SMPro MFD driver Adds device tree bindings for SMPro MFD driver found on the Mt.Jade hardware reference platform with Ampere's Altra Processor family. The SMpro co-processor on Ampere Altra processor family is to monitor and report various data included hwmon-related info, RAS errors, and other miscellaneous information. Signed-off-by: Quan Nguyen Reviewed-by: Rob Herring Signed-off-by: Lee Jones Link: https://lore.kernel.org/r/20221031024442.2490881-2-quan@os.amperecomputing.com --- .../devicetree/bindings/mfd/ampere,smpro.yaml | 42 ++++++++++++++++++++++ 1 file changed, 42 insertions(+) create mode 100644 Documentation/devicetree/bindings/mfd/ampere,smpro.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mfd/ampere,smpro.yaml b/Documentation/devicetree/bindings/mfd/ampere,smpro.yaml new file mode 100644 index 000000000000..c442c3cdffed --- /dev/null +++ b/Documentation/devicetree/bindings/mfd/ampere,smpro.yaml @@ -0,0 +1,42 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mfd/ampere,smpro.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Ampere Altra SMPro firmware driver + +maintainers: + - Quan Nguyen + +description: | + Ampere Altra SMPro firmware may contain different blocks like hardware + monitoring, error monitoring and other miscellaneous features. + +properties: + compatible: + enum: + - ampere,smpro + + reg: + description: + I2C device address. + maxItems: 1 + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + smpro@4f { + compatible = "ampere,smpro"; + reg = <0x4f>; + }; + }; -- cgit v1.2.3 From 4c7ee9a38dcc347887511deb773624550f7629ca Mon Sep 17 00:00:00 2001 From: Colin Foster Date: Mon, 24 Oct 2022 22:03:49 -0700 Subject: dt-bindings: mfd: ocelot: Remove spi-max-frequency from required properties The property spi-max-frequency was initially documented as a required property. It is not actually required, and will break bindings validation if other control mediums (e.g. PCIe) are used. Remove this property from the required arguments. Signed-off-by: Colin Foster Acked-by: Krzysztof Kozlowski Signed-off-by: Lee Jones Link: https://lore.kernel.org/r/20221025050355.3979380-2-colin.foster@in-advantage.com --- Documentation/devicetree/bindings/mfd/mscc,ocelot.yaml | 1 - 1 file changed, 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mfd/mscc,ocelot.yaml b/Documentation/devicetree/bindings/mfd/mscc,ocelot.yaml index 8bf45a5673a4..c6da91211a18 100644 --- a/Documentation/devicetree/bindings/mfd/mscc,ocelot.yaml +++ b/Documentation/devicetree/bindings/mfd/mscc,ocelot.yaml @@ -61,7 +61,6 @@ required: - reg - '#address-cells' - '#size-cells' - - spi-max-frequency additionalProperties: false -- cgit v1.2.3 From b092874ace67d5e33a9dc3aba7cb2e666dda8fd3 Mon Sep 17 00:00:00 2001 From: Colin Foster Date: Mon, 24 Oct 2022 22:03:50 -0700 Subject: dt-bindings: mfd: ocelot: Remove unnecessary driver wording Initially there was unnecessary verbage around "this driver" in the documentation. It was unnecessary. Remove self references about it being a "driver" documentation and replace it with a more detailed description about external interfaces that are supported. Signed-off-by: Colin Foster Suggested-by: Krzysztof Kozlowski Signed-off-by: Lee Jones Link: https://lore.kernel.org/r/20221025050355.3979380-3-colin.foster@in-advantage.com --- Documentation/devicetree/bindings/mfd/mscc,ocelot.yaml | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mfd/mscc,ocelot.yaml b/Documentation/devicetree/bindings/mfd/mscc,ocelot.yaml index c6da91211a18..1d1fee1a16c1 100644 --- a/Documentation/devicetree/bindings/mfd/mscc,ocelot.yaml +++ b/Documentation/devicetree/bindings/mfd/mscc,ocelot.yaml @@ -12,7 +12,8 @@ maintainers: description: | The Ocelot ethernet switch family contains chips that have an internal CPU (VSC7513, VSC7514) and chips that don't (VSC7511, VSC7512). All switches have - the option to be controlled externally, which is the purpose of this driver. + the option to be controlled externally via external interfaces like SPI or + PCIe. The switch family is a multi-port networking switch that supports many interfaces. Additionally, the device can perform pin control, MDIO buses, and -- cgit v1.2.3 From 411ffc82f93cf69f70712467ac85fdf2dc3be04a Mon Sep 17 00:00:00 2001 From: AngeloGioacchino Del Regno Date: Fri, 4 Nov 2022 18:21:19 +0100 Subject: dt-bindings: mfd: qcom,tcsr: Add compatible for MSM8976 Document the qcom,msm8976-tcsr compatible. Signed-off-by: AngeloGioacchino Del Regno Reviewed-by: Krzysztof Kozlowski Signed-off-by: Lee Jones Link: https://lore.kernel.org/r/20221104172122.252761-7-angelogioacchino.delregno@collabora.com --- Documentation/devicetree/bindings/mfd/qcom,tcsr.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mfd/qcom,tcsr.yaml b/Documentation/devicetree/bindings/mfd/qcom,tcsr.yaml index cb0ae38a777f..adcae6c007d9 100644 --- a/Documentation/devicetree/bindings/mfd/qcom,tcsr.yaml +++ b/Documentation/devicetree/bindings/mfd/qcom,tcsr.yaml @@ -17,6 +17,7 @@ properties: compatible: items: - enum: + - qcom,msm8976-tcsr - qcom,msm8998-tcsr - qcom,qcs404-tcsr - qcom,sc7180-tcsr -- cgit v1.2.3 From ef1709238aa50094d918e4f1dd5231dac5db13c3 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jonathan=20Neusch=C3=A4fer?= Date: Sat, 5 Nov 2022 19:59:07 +0100 Subject: dt-bindings: mfd: syscon: Add nuvoton,wpcm450-shm MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The Shared Memory interface (SHM) is a piece of hardware in Nuvoton BMCs that allows a host processor (connected via LPC) to access flash and RAM that belong to the BMC. The SHM includes a register block accessible from the BMC side. Signed-off-by: Jonathan Neuschäfer Acked-by: Krzysztof Kozlowski Signed-off-by: Lee Jones Link: https://lore.kernel.org/r/20221105185911.1547847-5-j.neuschaefer@gmx.net --- Documentation/devicetree/bindings/mfd/syscon.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mfd/syscon.yaml b/Documentation/devicetree/bindings/mfd/syscon.yaml index 4e4baf53796d..1b01bd010431 100644 --- a/Documentation/devicetree/bindings/mfd/syscon.yaml +++ b/Documentation/devicetree/bindings/mfd/syscon.yaml @@ -53,6 +53,7 @@ properties: - microchip,lan966x-cpu-syscon - microchip,sparx5-cpu-syscon - mstar,msc313-pmsleep + - nuvoton,wpcm450-shm - rockchip,px30-qos - rockchip,rk3036-qos - rockchip,rk3066-qos -- cgit v1.2.3 From ba215dd650c50fee321bb47af94fb689cb3cf776 Mon Sep 17 00:00:00 2001 From: Luca Weiss Date: Mon, 31 Oct 2022 18:39:31 +0100 Subject: dt-bindings: mfd: qcom,spmi-pmic: Support more types * 'adc@' is either spmi-iadc or spmi-vadc * 'charger@' is either pm8941-charger or pm8941-coincell * 'usb-vbus-regulator@' is usb-vbus-regulator * 'vibrator@' is now in yaml format, so add it Signed-off-by: Luca Weiss Reviewed-by: Rob Herring Signed-off-by: Lee Jones Link: https://lore.kernel.org/r/20221031173933.936147-1-luca@z3ntu.xyz --- .../devicetree/bindings/mfd/qcom,spmi-pmic.yaml | 16 ++++++++++++++-- 1 file changed, 14 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.yaml b/Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.yaml index c8362efd4345..8d9fbc278918 100644 --- a/Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.yaml +++ b/Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.yaml @@ -105,7 +105,9 @@ properties: patternProperties: "^adc@[0-9a-f]+$": type: object - $ref: /schemas/iio/adc/qcom,spmi-vadc.yaml# + oneOf: + - $ref: /schemas/iio/adc/qcom,spmi-iadc.yaml# + - $ref: /schemas/iio/adc/qcom,spmi-vadc.yaml# "^adc-tm@[0-9a-f]+$": type: object @@ -115,6 +117,12 @@ patternProperties: type: object additionalProperties: true # FIXME qcom,pm8916-wcd-analog-codec binding not converted yet + "^charger@[0-9a-f]+$": + type: object + oneOf: + - $ref: /schemas/power/supply/qcom,pm8941-charger.yaml# + - $ref: /schemas/power/supply/qcom,pm8941-coincell.yaml# + "extcon@[0-9a-f]+$": type: object $ref: /schemas/extcon/qcom,pm8941-misc.yaml# @@ -135,9 +143,13 @@ patternProperties: type: object $ref: /schemas/thermal/qcom,spmi-temp-alarm.yaml# + "^usb-vbus-regulator@[0-9a-f]+$": + type: object + $ref: /schemas/regulator/qcom,usb-vbus-regulator.yaml# + "^vibrator@[0-9a-f]+$": type: object - additionalProperties: true # FIXME qcom,pm8916-vib binding not converted yet + $ref: /schemas/input/qcom,pm8xxx-vib.yaml# "^mpps@[0-9a-f]+$": type: object -- cgit v1.2.3 From 0867c49146c2145ecfb07d6d03071cdbeae9b6e1 Mon Sep 17 00:00:00 2001 From: Luca Weiss Date: Mon, 31 Oct 2022 18:57:14 +0100 Subject: dt-bindings: mfd: qcom,spmi-pmic: Rename extcon node name extcon is a Linux-specific name and shouldn't be a part of the dts. Make it be called usb-detect@ instead. Signed-off-by: Luca Weiss Acked-by: Rob Herring Signed-off-by: Lee Jones Link: https://lore.kernel.org/r/20221031175717.942237-1-luca@z3ntu.xyz --- Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.yaml | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.yaml b/Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.yaml index 8d9fbc278918..a5e69836dcef 100644 --- a/Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.yaml +++ b/Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.yaml @@ -123,10 +123,6 @@ patternProperties: - $ref: /schemas/power/supply/qcom,pm8941-charger.yaml# - $ref: /schemas/power/supply/qcom,pm8941-coincell.yaml# - "extcon@[0-9a-f]+$": - type: object - $ref: /schemas/extcon/qcom,pm8941-misc.yaml# - "gpio@[0-9a-f]+$": type: object $ref: /schemas/pinctrl/qcom,pmic-gpio.yaml# @@ -143,6 +139,10 @@ patternProperties: type: object $ref: /schemas/thermal/qcom,spmi-temp-alarm.yaml# + "^usb-detect@[0-9a-f]+$": + type: object + $ref: /schemas/extcon/qcom,pm8941-misc.yaml# + "^usb-vbus-regulator@[0-9a-f]+$": type: object $ref: /schemas/regulator/qcom,usb-vbus-regulator.yaml# -- cgit v1.2.3 From 1ca8a011ddca3e44340d9db611b019054dfc37d6 Mon Sep 17 00:00:00 2001 From: Matti Vaittinen Date: Thu, 1 Dec 2022 08:57:52 +0200 Subject: dt-bindings: Fix maintainer email for a few ROHM ICs The email backend used by ROHM keeps labeling patches as spam. This can result to missing the patches. Switch my mail address from a company mail to a personal one. Signed-off-by: Matti Vaittinen Acked-by: Sebastian Reichel Acked-by: Mark Brown Acked-by: Krzysztof Kozlowski Signed-off-by: Lee Jones Link: https://lore.kernel.org/r/7986d30480df6179a3989fba4cd13817738635c5.1669877740.git.mazziesaccount@gmail.com --- Documentation/devicetree/bindings/leds/rohm,bd71828-leds.yaml | 2 +- Documentation/devicetree/bindings/mfd/rohm,bd71815-pmic.yaml | 2 +- Documentation/devicetree/bindings/mfd/rohm,bd71828-pmic.yaml | 2 +- Documentation/devicetree/bindings/mfd/rohm,bd71837-pmic.yaml | 2 +- Documentation/devicetree/bindings/mfd/rohm,bd71847-pmic.yaml | 2 +- Documentation/devicetree/bindings/mfd/rohm,bd9576-pmic.yaml | 2 +- Documentation/devicetree/bindings/power/supply/rohm,bd99954.yaml | 2 +- Documentation/devicetree/bindings/regulator/rohm,bd71815-regulator.yaml | 2 +- Documentation/devicetree/bindings/regulator/rohm,bd71828-regulator.yaml | 2 +- Documentation/devicetree/bindings/regulator/rohm,bd71837-regulator.yaml | 2 +- Documentation/devicetree/bindings/regulator/rohm,bd71847-regulator.yaml | 2 +- Documentation/devicetree/bindings/regulator/rohm,bd9576-regulator.yaml | 2 +- 12 files changed, 12 insertions(+), 12 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/leds/rohm,bd71828-leds.yaml b/Documentation/devicetree/bindings/leds/rohm,bd71828-leds.yaml index 86a37c92b834..d48c404c848e 100644 --- a/Documentation/devicetree/bindings/leds/rohm,bd71828-leds.yaml +++ b/Documentation/devicetree/bindings/leds/rohm,bd71828-leds.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: ROHM BD71828 Power Management Integrated Circuit LED driver maintainers: - - Matti Vaittinen + - Matti Vaittinen description: | This module is part of the ROHM BD71828 MFD device. For more details diff --git a/Documentation/devicetree/bindings/mfd/rohm,bd71815-pmic.yaml b/Documentation/devicetree/bindings/mfd/rohm,bd71815-pmic.yaml index fbface720678..7cda8adc178e 100644 --- a/Documentation/devicetree/bindings/mfd/rohm,bd71815-pmic.yaml +++ b/Documentation/devicetree/bindings/mfd/rohm,bd71815-pmic.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: ROHM BD71815 Power Management Integrated Circuit bindings maintainers: - - Matti Vaittinen + - Matti Vaittinen description: | BD71815AGW is a single-chip power management ICs for battery-powered diff --git a/Documentation/devicetree/bindings/mfd/rohm,bd71828-pmic.yaml b/Documentation/devicetree/bindings/mfd/rohm,bd71828-pmic.yaml index 8380166d176c..c13730aa34d9 100644 --- a/Documentation/devicetree/bindings/mfd/rohm,bd71828-pmic.yaml +++ b/Documentation/devicetree/bindings/mfd/rohm,bd71828-pmic.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: ROHM BD71828 Power Management Integrated Circuit bindings maintainers: - - Matti Vaittinen + - Matti Vaittinen description: | BD71828GW is a single-chip power management IC for battery-powered portable diff --git a/Documentation/devicetree/bindings/mfd/rohm,bd71837-pmic.yaml b/Documentation/devicetree/bindings/mfd/rohm,bd71837-pmic.yaml index 3bfdd33702ad..3ab8dcf0e8f1 100644 --- a/Documentation/devicetree/bindings/mfd/rohm,bd71837-pmic.yaml +++ b/Documentation/devicetree/bindings/mfd/rohm,bd71837-pmic.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: ROHM BD71837 Power Management Integrated Circuit bindings maintainers: - - Matti Vaittinen + - Matti Vaittinen description: | BD71837MWV is programmable Power Management ICs for powering single-core, diff --git a/Documentation/devicetree/bindings/mfd/rohm,bd71847-pmic.yaml b/Documentation/devicetree/bindings/mfd/rohm,bd71847-pmic.yaml index 5d531051a153..8ed4390bb43f 100644 --- a/Documentation/devicetree/bindings/mfd/rohm,bd71847-pmic.yaml +++ b/Documentation/devicetree/bindings/mfd/rohm,bd71847-pmic.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: ROHM BD71847 and BD71850 Power Management Integrated Circuit bindings maintainers: - - Matti Vaittinen + - Matti Vaittinen description: | BD71847AMWV and BD71850MWV are programmable Power Management ICs for powering diff --git a/Documentation/devicetree/bindings/mfd/rohm,bd9576-pmic.yaml b/Documentation/devicetree/bindings/mfd/rohm,bd9576-pmic.yaml index 6483860da955..e1ebea9ad5da 100644 --- a/Documentation/devicetree/bindings/mfd/rohm,bd9576-pmic.yaml +++ b/Documentation/devicetree/bindings/mfd/rohm,bd9576-pmic.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: ROHM BD9576MUF and BD9573MUF Power Management Integrated Circuit bindings maintainers: - - Matti Vaittinen + - Matti Vaittinen description: | BD9576MUF and BD9573MUF are power management ICs primarily intended for diff --git a/Documentation/devicetree/bindings/power/supply/rohm,bd99954.yaml b/Documentation/devicetree/bindings/power/supply/rohm,bd99954.yaml index 24b06957b4ca..6a0756e33eb8 100644 --- a/Documentation/devicetree/bindings/power/supply/rohm,bd99954.yaml +++ b/Documentation/devicetree/bindings/power/supply/rohm,bd99954.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: ROHM BD99954 Battery charger maintainers: - - Matti Vaittinen + - Matti Vaittinen - Markus Laine - Mikko Mutanen diff --git a/Documentation/devicetree/bindings/regulator/rohm,bd71815-regulator.yaml b/Documentation/devicetree/bindings/regulator/rohm,bd71815-regulator.yaml index d61e8675f067..027fab3dc181 100644 --- a/Documentation/devicetree/bindings/regulator/rohm,bd71815-regulator.yaml +++ b/Documentation/devicetree/bindings/regulator/rohm,bd71815-regulator.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: ROHM BD71815 Power Management Integrated Circuit regulators maintainers: - - Matti Vaittinen + - Matti Vaittinen description: | This module is part of the ROHM BD718215 MFD device. For more details diff --git a/Documentation/devicetree/bindings/regulator/rohm,bd71828-regulator.yaml b/Documentation/devicetree/bindings/regulator/rohm,bd71828-regulator.yaml index 5ce587fff961..3cbe3b76ccee 100644 --- a/Documentation/devicetree/bindings/regulator/rohm,bd71828-regulator.yaml +++ b/Documentation/devicetree/bindings/regulator/rohm,bd71828-regulator.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: ROHM BD71828 Power Management Integrated Circuit regulators maintainers: - - Matti Vaittinen + - Matti Vaittinen description: | This module is part of the ROHM BD71828 MFD device. For more details diff --git a/Documentation/devicetree/bindings/regulator/rohm,bd71837-regulator.yaml b/Documentation/devicetree/bindings/regulator/rohm,bd71837-regulator.yaml index 1941b36cf1ef..ab842817d847 100644 --- a/Documentation/devicetree/bindings/regulator/rohm,bd71837-regulator.yaml +++ b/Documentation/devicetree/bindings/regulator/rohm,bd71837-regulator.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: ROHM BD71837 Power Management Integrated Circuit regulators maintainers: - - Matti Vaittinen + - Matti Vaittinen description: | List of regulators provided by this controller. BD71837 regulators node diff --git a/Documentation/devicetree/bindings/regulator/rohm,bd71847-regulator.yaml b/Documentation/devicetree/bindings/regulator/rohm,bd71847-regulator.yaml index a1b806373853..65fc3d15f693 100644 --- a/Documentation/devicetree/bindings/regulator/rohm,bd71847-regulator.yaml +++ b/Documentation/devicetree/bindings/regulator/rohm,bd71847-regulator.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: ROHM BD71847 and BD71850 Power Management Integrated Circuit regulators maintainers: - - Matti Vaittinen + - Matti Vaittinen description: | List of regulators provided by this controller. BD71847 regulators node diff --git a/Documentation/devicetree/bindings/regulator/rohm,bd9576-regulator.yaml b/Documentation/devicetree/bindings/regulator/rohm,bd9576-regulator.yaml index 7cb74cc8c5d9..1e41168a4980 100644 --- a/Documentation/devicetree/bindings/regulator/rohm,bd9576-regulator.yaml +++ b/Documentation/devicetree/bindings/regulator/rohm,bd9576-regulator.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: ROHM BD9576 and BD9573 Power Management Integrated Circuit regulators maintainers: - - Matti Vaittinen + - Matti Vaittinen description: | This module is part of the ROHM BD9576 MFD device. For more details -- cgit v1.2.3 From e85b1f5a9769ac30f4d2f6fb1cdcd9570c38e0c1 Mon Sep 17 00:00:00 2001 From: Marek Vasut Date: Thu, 8 Dec 2022 04:53:54 +0100 Subject: ASoC: dt-bindings: fsl-sai: Reinstate i.MX93 SAI compatible string The ASoC: dt-bindings: fsl-sai: Fix mx6ul and mx7d compatible strings dropped i.MX93 SAI compatible string, reinstate it. Fixes: 81b6c043e7ba ("ASoC: dt-bindings: fsl-sai: Fix mx6ul and mx7d compatible strings") Signed-off-by: Marek Vasut Link: https://lore.kernel.org/r/20221208035354.255438-1-marex@denx.de 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 5b28d2d51327..7e56337d8edc 100644 --- a/Documentation/devicetree/bindings/sound/fsl,sai.yaml +++ b/Documentation/devicetree/bindings/sound/fsl,sai.yaml @@ -38,6 +38,7 @@ properties: - fsl,imx8mq-sai - fsl,imx8qm-sai - fsl,imx8ulp-sai + - fsl,imx93-sai - fsl,vf610-sai reg: -- cgit v1.2.3 From 7ef5c57758c4bbf8d5476c3fefcb585e150d116a Mon Sep 17 00:00:00 2001 From: Christoph Niedermaier Date: Tue, 22 Nov 2022 10:58:31 +0100 Subject: dt-bindings: mfd: da9062: Move IRQ to optional properties Move IRQ to optional properties, because the MFD DA9061/62 is usable without IRQ. This makes the chip usable for designs that don't have the IRQ pin connected. Signed-off-by: Christoph Niedermaier Acked-by: Krzysztof Kozlowski Signed-off-by: Lee Jones Link: https://lore.kernel.org/r/20221122095833.3957-2-cniedermaier@dh-electronics.com --- Documentation/devicetree/bindings/mfd/da9062.txt | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mfd/da9062.txt b/Documentation/devicetree/bindings/mfd/da9062.txt index bab0d0e66cb3..fe580206e18d 100644 --- a/Documentation/devicetree/bindings/mfd/da9062.txt +++ b/Documentation/devicetree/bindings/mfd/da9062.txt @@ -33,11 +33,6 @@ Required properties: "dlg,da9061" for DA9061 - reg : Specifies the I2C slave address (this defaults to 0x58 but it can be modified to match the chip's OTP settings). -- interrupts : IRQ line information. -- interrupt-controller - -See Documentation/devicetree/bindings/interrupt-controller/interrupts.txt for -further information on IRQ bindings. Optional properties: @@ -48,6 +43,12 @@ Optional properties: See Documentation/devicetree/bindings/gpio/gpio.txt for further information on GPIO bindings. +- interrupts : IRQ line information. +- interrupt-controller + +See Documentation/devicetree/bindings/interrupt-controller/interrupts.txt for +further information on IRQ bindings. + Sub-nodes: - regulators : This node defines the settings for the LDOs and BUCKs. -- cgit v1.2.3 From 37fecbb80721c4e72ba3e43d4f07ba9ec15b68fd Mon Sep 17 00:00:00 2001 From: Christoph Niedermaier Date: Wed, 30 Nov 2022 11:14:26 +0100 Subject: dt-bindings: mfd: da9062: Correct file name for watchdog Replace the watchdog file name with the name currently in use. Signed-off-by: Christoph Niedermaier Acked-by: Krzysztof Kozlowski Signed-off-by: Lee Jones Link: https://lore.kernel.org/r/20221130101426.5318-1-cniedermaier@dh-electronics.com --- Documentation/devicetree/bindings/mfd/da9062.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mfd/da9062.txt b/Documentation/devicetree/bindings/mfd/da9062.txt index fe580206e18d..e4eedd3bd233 100644 --- a/Documentation/devicetree/bindings/mfd/da9062.txt +++ b/Documentation/devicetree/bindings/mfd/da9062.txt @@ -86,7 +86,7 @@ Sub-nodes: - onkey : See ../input/da9062-onkey.txt -- watchdog: See ../watchdog/da9062-watchdog.txt +- watchdog: See ../watchdog/da9062-wdt.txt - thermal : See ../thermal/da9062-thermal.txt -- cgit v1.2.3 From 00dd027f721e0458418f7750d8a5a664ed3e5994 Mon Sep 17 00:00:00 2001 From: Kees Cook Date: Wed, 14 Dec 2022 14:35:47 -0800 Subject: docs: Fix path paste-o for /sys/kernel/warn_count Running "make htmldocs" shows that "/sys/kernel/oops_count" was duplicated. This should have been "warn_count": Warning: /sys/kernel/oops_count is defined 2 times: ./Documentation/ABI/testing/sysfs-kernel-warn_count:0 ./Documentation/ABI/testing/sysfs-kernel-oops_count:0 Fix the typo. Reported-by: kernel test robot Link: https://lore.kernel.org/linux-doc/202212110529.A3Qav8aR-lkp@intel.com Fixes: 8b05aa263361 ("panic: Expose "warn_count" to sysfs") Cc: linux-hardening@vger.kernel.org Signed-off-by: Kees Cook --- Documentation/ABI/testing/sysfs-kernel-warn_count | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-kernel-warn_count b/Documentation/ABI/testing/sysfs-kernel-warn_count index 08f083d2fd51..90a029813717 100644 --- a/Documentation/ABI/testing/sysfs-kernel-warn_count +++ b/Documentation/ABI/testing/sysfs-kernel-warn_count @@ -1,4 +1,4 @@ -What: /sys/kernel/oops_count +What: /sys/kernel/warn_count Date: November 2022 KernelVersion: 6.2.0 Contact: Linux Kernel Hardening List -- cgit v1.2.3 From 3b7ddab8a19aefc768f345fd3782af35b4a68d9b Mon Sep 17 00:00:00 2001 From: wuqiang Date: Thu, 10 Nov 2022 16:15:02 +0800 Subject: kprobes: kretprobe events missing on 2-core KVM guest Default value of maxactive is set as num_possible_cpus() for nonpreemptable systems. For a 2-core system, only 2 kretprobe instances would be allocated in default, then these 2 instances for execve kretprobe are very likely to be used up with a pipelined command. Here's the testcase: a shell script was added to crontab, and the content of the script is: #!/bin/sh do_something_magic `tr -dc a-z < /dev/urandom | head -c 10` cron will trigger a series of program executions (4 times every hour). Then events loss would be noticed normally after 3-4 hours of testings. The issue is caused by a burst of series of execve requests. The best number of kretprobe instances could be different case by case, and should be user's duty to determine, but num_possible_cpus() as the default value is inadequate especially for systems with small number of cpus. This patch enables the logic for preemption as default, thus increases the minimum of maxactive to 10 for nonpreemptable systems. Link: https://lore.kernel.org/all/20221110081502.492289-1-wuqiang.matt@bytedance.com/ Signed-off-by: wuqiang Reviewed-by: Solar Designer Acked-by: Masami Hiramatsu (Google) Signed-off-by: Masami Hiramatsu (Google) --- Documentation/trace/kprobes.rst | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/trace/kprobes.rst b/Documentation/trace/kprobes.rst index 48cf778a2468..fc7ce76eab65 100644 --- a/Documentation/trace/kprobes.rst +++ b/Documentation/trace/kprobes.rst @@ -131,8 +131,7 @@ For example, if the function is non-recursive and is called with a spinlock held, maxactive = 1 should be enough. If the function is non-recursive and can never relinquish the CPU (e.g., via a semaphore or preemption), NR_CPUS should be enough. If maxactive <= 0, it is -set to a default value. If CONFIG_PREEMPT is enabled, the default -is max(10, 2*NR_CPUS). Otherwise, the default is NR_CPUS. +set to a default value: max(10, 2*NR_CPUS). It's not a disaster if you set maxactive too low; you'll just miss some probes. In the kretprobe struct, the nmissed field is set to -- cgit v1.2.3 From b26a124cbfa80f42bfc4e63e1d5643ca98159d66 Mon Sep 17 00:00:00 2001 From: "Masami Hiramatsu (Google)" Date: Mon, 14 Nov 2022 13:47:56 +0900 Subject: tracing/probes: Add symstr type for dynamic events Add 'symstr' type for storing the kernel symbol as a string data instead of the symbol address. This allows us to filter the events by wildcard symbol name. e.g. # echo 'e:wqfunc workqueue.workqueue_execute_start symname=$function:symstr' >> dynamic_events # cat events/eprobes/wqfunc/format name: wqfunc ID: 2110 format: field:unsigned short common_type; offset:0; size:2; signed:0; field:unsigned char common_flags; offset:2; size:1; signed:0; field:unsigned char common_preempt_count; offset:3; size:1; signed:0; field:int common_pid; offset:4; size:4; signed:1; field:__data_loc char[] symname; offset:8; size:4; signed:1; print fmt: " symname=\"%s\"", __get_str(symname) Note that there is already 'symbol' type which just change the print format (so it still stores the symbol address in the tracing ring buffer.) On the other hand, 'symstr' type stores the actual "symbol+offset/size" data as a string. Link: https://lore.kernel.org/all/166679930847.1528100.4124308529180235965.stgit@devnote3/ Signed-off-by: Masami Hiramatsu (Google) --- Documentation/trace/kprobetrace.rst | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/trace/kprobetrace.rst b/Documentation/trace/kprobetrace.rst index 4274cc6a2f94..08a2a6a3782f 100644 --- a/Documentation/trace/kprobetrace.rst +++ b/Documentation/trace/kprobetrace.rst @@ -58,8 +58,8 @@ Synopsis of kprobe_events NAME=FETCHARG : Set NAME as the argument name of FETCHARG. FETCHARG:TYPE : Set TYPE as the type of FETCHARG. Currently, basic types (u8/u16/u32/u64/s8/s16/s32/s64), hexadecimal types - (x8/x16/x32/x64), "string", "ustring" and bitfield - are supported. + (x8/x16/x32/x64), "string", "ustring", "symbol", "symstr" + and bitfield are supported. (\*1) only for the probe on function entry (offs == 0). (\*2) only for return probe. @@ -96,6 +96,10 @@ offset, and container-size (usually 32). The syntax is:: Symbol type('symbol') is an alias of u32 or u64 type (depends on BITS_PER_LONG) which shows given pointer in "symbol+offset" style. +On the other hand, symbol-string type ('symstr') converts the given address to +"symbol+offset/symbolsize" style and stores it as a null-terminated string. +With 'symstr' type, you can filter the event with wildcard pattern of the +symbols, and you don't need to solve symbol name by yourself. For $comm, the default type is "string"; any other type is invalid. .. _user_mem_access: -- cgit v1.2.3 From e0cb05a02c5333323a32324d8e4048b7575d8ff5 Mon Sep 17 00:00:00 2001 From: Bhupesh Sharma Date: Mon, 28 Nov 2022 01:24:17 +0530 Subject: dt-bindings: mailbox: qcom: Add SM4250 APCS compatible Add compatible for the Qualcomm SM4250 APCS block. Signed-off-by: Bhupesh Sharma Acked-by: Krzysztof Kozlowski Signed-off-by: Jassi Brar --- Documentation/devicetree/bindings/mailbox/qcom,apcs-kpss-global.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mailbox/qcom,apcs-kpss-global.yaml b/Documentation/devicetree/bindings/mailbox/qcom,apcs-kpss-global.yaml index f24fd84b4b05..05fbef6486fe 100644 --- a/Documentation/devicetree/bindings/mailbox/qcom,apcs-kpss-global.yaml +++ b/Documentation/devicetree/bindings/mailbox/qcom,apcs-kpss-global.yaml @@ -28,6 +28,7 @@ properties: - qcom,sc8180x-apss-shared - qcom,sdm660-apcs-hmss-global - qcom,sdm845-apss-shared + - qcom,sm4250-apcs-hmss-global - qcom,sm6125-apcs-hmss-global - qcom,sm6115-apcs-hmss-global - qcom,sm8150-apss-shared -- cgit v1.2.3 From 76f708f635403d826ebea17ccce60d47c6671e22 Mon Sep 17 00:00:00 2001 From: Luca Weiss Date: Sun, 16 Oct 2022 11:00:32 +0200 Subject: dt-bindings: mailbox: qcom-ipcc: Add sc8280xp compatible Document the sc8280xp compatible, and at the same time also make sure the list is sorted alphabetically. Signed-off-by: Luca Weiss Reviewed-by: Krzysztof Kozlowski Signed-off-by: Jassi Brar --- Documentation/devicetree/bindings/mailbox/qcom-ipcc.yaml | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mailbox/qcom-ipcc.yaml b/Documentation/devicetree/bindings/mailbox/qcom-ipcc.yaml index baca4786ff94..bc599a864637 100644 --- a/Documentation/devicetree/bindings/mailbox/qcom-ipcc.yaml +++ b/Documentation/devicetree/bindings/mailbox/qcom-ipcc.yaml @@ -24,12 +24,13 @@ properties: compatible: items: - enum: + - qcom,sc7280-ipcc + - qcom,sc8280xp-ipcc - qcom,sm6350-ipcc - qcom,sm6375-ipcc - qcom,sm8250-ipcc - qcom,sm8350-ipcc - qcom,sm8450-ipcc - - qcom,sc7280-ipcc - const: qcom,ipcc reg: -- cgit v1.2.3 From f2b53c2956207b76c42407f3c089a2c1561a58ef Mon Sep 17 00:00:00 2001 From: Elvis Wang Date: Thu, 1 Dec 2022 15:13:16 +0800 Subject: dt-bindings: mailbox: mediatek,gce-mailbox: add mt8188 compatible name Add mt8188 compatible name. Signed-off-by: Elvis Wang Reviewed-by: AngeloGioacchino Del Regno Acked-by: Krzysztof Kozlowski Signed-off-by: Jassi Brar --- Documentation/devicetree/bindings/mailbox/mediatek,gce-mailbox.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mailbox/mediatek,gce-mailbox.yaml b/Documentation/devicetree/bindings/mailbox/mediatek,gce-mailbox.yaml index c579ac074ca7..d383b2ab3ce8 100644 --- a/Documentation/devicetree/bindings/mailbox/mediatek,gce-mailbox.yaml +++ b/Documentation/devicetree/bindings/mailbox/mediatek,gce-mailbox.yaml @@ -21,6 +21,7 @@ properties: - mediatek,mt8173-gce - mediatek,mt8183-gce - mediatek,mt8186-gce + - mediatek,mt8188-gce - mediatek,mt8192-gce - mediatek,mt8195-gce -- cgit v1.2.3 From 53c60d1004270045d63cdee91aa77c145282d7e4 Mon Sep 17 00:00:00 2001 From: Abel Vesa Date: Wed, 16 Nov 2022 13:34:57 +0200 Subject: dt-bindings: mailbox: qcom-ipcc: Add compatible for SM8550 Document the compatible for SM8550 mailbox. Signed-off-by: Abel Vesa Reviewed-by: Krzysztof Kozlowski Signed-off-by: Jassi Brar --- Documentation/devicetree/bindings/mailbox/qcom-ipcc.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mailbox/qcom-ipcc.yaml b/Documentation/devicetree/bindings/mailbox/qcom-ipcc.yaml index bc599a864637..f5c73437fef4 100644 --- a/Documentation/devicetree/bindings/mailbox/qcom-ipcc.yaml +++ b/Documentation/devicetree/bindings/mailbox/qcom-ipcc.yaml @@ -31,6 +31,7 @@ properties: - qcom,sm8250-ipcc - qcom,sm8350-ipcc - qcom,sm8450-ipcc + - qcom,sm8550-ipcc - const: qcom,ipcc reg: -- cgit v1.2.3 From 23e528d9bce2385967370ad95a7d52a3c7a0a016 Mon Sep 17 00:00:00 2001 From: Sean Christopherson Date: Wed, 7 Dec 2022 00:36:37 +0000 Subject: KVM: Delete extra block of "};" in the KVM API documentation Delete an extra block of code/documentation that snuck in when KVM's documentation was converted to ReST format. Fixes: 106ee47dc633 ("docs: kvm: Convert api.txt to ReST format") Signed-off-by: Sean Christopherson Message-Id: <20221207003637.2041211-1-seanjc@google.com> Signed-off-by: Paolo Bonzini --- Documentation/virt/kvm/api.rst | 5 ----- 1 file changed, 5 deletions(-) (limited to 'Documentation') diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst index 778c6460d1de..d795d683601c 100644 --- a/Documentation/virt/kvm/api.rst +++ b/Documentation/virt/kvm/api.rst @@ -6577,11 +6577,6 @@ Please note that the kernel is allowed to use the kvm_run structure as the primary storage for certain register types. Therefore, the kernel may use the values in kvm_run even if the corresponding bit in kvm_dirty_regs is not set. -:: - - }; - - 6. Capabilities that can be enabled on vCPUs ============================================ -- cgit v1.2.3 From af2808906aab0bf5786021d45b3ebfca6f4ad72f Mon Sep 17 00:00:00 2001 From: David Woodhouse Date: Mon, 26 Dec 2022 12:03:20 +0000 Subject: KVM: x86/xen: Documentation updates and clarifications Most notably, the KVM_XEN_EVTCHN_RESET feature had escaped documentation entirely. Along with how to turn most stuff off on SHUTDOWN_soft_reset. Signed-off-by: David Woodhouse Message-Id: <20221226120320.1125390-6-dwmw2@infradead.org> Signed-off-by: Paolo Bonzini --- Documentation/virt/kvm/api.rst | 41 ++++++++++++++++++++++++++--------------- 1 file changed, 26 insertions(+), 15 deletions(-) (limited to 'Documentation') diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst index d795d683601c..af6471657395 100644 --- a/Documentation/virt/kvm/api.rst +++ b/Documentation/virt/kvm/api.rst @@ -5343,9 +5343,9 @@ KVM_XEN_ATTR_TYPE_SHARED_INFO 32 vCPUs in the shared_info page, KVM does not automatically do so and instead requires that KVM_XEN_VCPU_ATTR_TYPE_VCPU_INFO be used explicitly even when the vcpu_info for a given vCPU resides at the - "default" location in the shared_info page. This is because KVM is - not aware of the Xen CPU id which is used as the index into the - vcpu_info[] array, so cannot know the correct default location. + "default" location in the shared_info page. This is because KVM may + not be aware of the Xen CPU id which is used as the index into the + vcpu_info[] array, so may know the correct default location. Note that the shared info page may be constantly written to by KVM; it contains the event channel bitmap used to deliver interrupts to @@ -5356,23 +5356,29 @@ KVM_XEN_ATTR_TYPE_SHARED_INFO any vCPU has been running or any event channel interrupts can be routed to the guest. + Setting the gfn to KVM_XEN_INVALID_GFN will disable the shared info + page. + KVM_XEN_ATTR_TYPE_UPCALL_VECTOR Sets the exception vector used to deliver Xen event channel upcalls. This is the HVM-wide vector injected directly by the hypervisor (not through the local APIC), typically configured by a guest via - HVM_PARAM_CALLBACK_IRQ. + HVM_PARAM_CALLBACK_IRQ. This can be disabled again (e.g. for guest + SHUTDOWN_soft_reset) by setting it to zero. KVM_XEN_ATTR_TYPE_EVTCHN This attribute is available when the KVM_CAP_XEN_HVM ioctl indicates support for KVM_XEN_HVM_CONFIG_EVTCHN_SEND features. It configures an outbound port number for interception of EVTCHNOP_send requests - from the guest. A given sending port number may be directed back - to a specified vCPU (by APIC ID) / port / priority on the guest, - or to trigger events on an eventfd. The vCPU and priority can be - changed by setting KVM_XEN_EVTCHN_UPDATE in a subsequent call, - but other fields cannot change for a given sending port. A port - mapping is removed by using KVM_XEN_EVTCHN_DEASSIGN in the flags - field. + from the guest. A given sending port number may be directed back to + a specified vCPU (by APIC ID) / port / priority on the guest, or to + trigger events on an eventfd. The vCPU and priority can be changed + by setting KVM_XEN_EVTCHN_UPDATE in a subsequent call, but but other + fields cannot change for a given sending port. A port mapping is + removed by using KVM_XEN_EVTCHN_DEASSIGN in the flags field. Passing + KVM_XEN_EVTCHN_RESET in the flags field removes all interception of + outbound event channels. The values of the flags field are mutually + exclusive and cannot be combined as a bitmask. KVM_XEN_ATTR_TYPE_XEN_VERSION This attribute is available when the KVM_CAP_XEN_HVM ioctl indicates @@ -5388,7 +5394,7 @@ KVM_XEN_ATTR_TYPE_RUNSTATE_UPDATE_FLAG support for KVM_XEN_HVM_CONFIG_RUNSTATE_UPDATE_FLAG. It enables the XEN_RUNSTATE_UPDATE flag which allows guest vCPUs to safely read other vCPUs' vcpu_runstate_info. Xen guests enable this feature via - the VM_ASST_TYPE_runstate_update_flag of the HYPERVISOR_vm_assist + the VMASST_TYPE_runstate_update_flag of the HYPERVISOR_vm_assist hypercall. 4.127 KVM_XEN_HVM_GET_ATTR @@ -5446,15 +5452,18 @@ KVM_XEN_VCPU_ATTR_TYPE_VCPU_INFO As with the shared_info page for the VM, the corresponding page may be dirtied at any time if event channel interrupt delivery is enabled, so userspace should always assume that the page is dirty without relying - on dirty logging. + on dirty logging. Setting the gpa to KVM_XEN_INVALID_GPA will disable + the vcpu_info. KVM_XEN_VCPU_ATTR_TYPE_VCPU_TIME_INFO Sets the guest physical address of an additional pvclock structure for a given vCPU. This is typically used for guest vsyscall support. + Setting the gpa to KVM_XEN_INVALID_GPA will disable the structure. KVM_XEN_VCPU_ATTR_TYPE_RUNSTATE_ADDR Sets the guest physical address of the vcpu_runstate_info for a given vCPU. This is how a Xen guest tracks CPU state such as steal time. + Setting the gpa to KVM_XEN_INVALID_GPA will disable the runstate area. KVM_XEN_VCPU_ATTR_TYPE_RUNSTATE_CURRENT Sets the runstate (RUNSTATE_running/_runnable/_blocked/_offline) of @@ -5487,7 +5496,8 @@ KVM_XEN_VCPU_ATTR_TYPE_TIMER This attribute is available when the KVM_CAP_XEN_HVM ioctl indicates support for KVM_XEN_HVM_CONFIG_EVTCHN_SEND features. It sets the event channel port/priority for the VIRQ_TIMER of the vCPU, as well - as allowing a pending timer to be saved/restored. + as allowing a pending timer to be saved/restored. Setting the timer + port to zero disables kernel handling of the singleshot timer. KVM_XEN_VCPU_ATTR_TYPE_UPCALL_VECTOR This attribute is available when the KVM_CAP_XEN_HVM ioctl indicates @@ -5495,7 +5505,8 @@ KVM_XEN_VCPU_ATTR_TYPE_UPCALL_VECTOR per-vCPU local APIC upcall vector, configured by a Xen guest with the HVMOP_set_evtchn_upcall_vector hypercall. This is typically used by Windows guests, and is distinct from the HVM-wide upcall - vector configured with HVM_PARAM_CALLBACK_IRQ. + vector configured with HVM_PARAM_CALLBACK_IRQ. It is disabled by + setting the vector to zero. 4.129 KVM_XEN_VCPU_GET_ATTR -- cgit v1.2.3 From f4ef681115f822daf7f36f8b1892d9f1e1a26fbf Mon Sep 17 00:00:00 2001 From: Jakub Kicinski Date: Thu, 22 Dec 2022 11:22:47 -0800 Subject: docs: netdev: reshuffle sections in prep for de-FAQization Subsequent changes will reformat the doc away from FAQ. To make that more readable perform the pure section moves now. Reviewed-by: Randy Dunlap Reviewed-by: Andrew Lunn Signed-off-by: Jakub Kicinski Signed-off-by: David S. Miller --- Documentation/process/maintainer-netdev.rst | 186 ++++++++++++++-------------- 1 file changed, 93 insertions(+), 93 deletions(-) (limited to 'Documentation') diff --git a/Documentation/process/maintainer-netdev.rst b/Documentation/process/maintainer-netdev.rst index 1fa5ab8754d3..8f22f8a3dcd1 100644 --- a/Documentation/process/maintainer-netdev.rst +++ b/Documentation/process/maintainer-netdev.rst @@ -44,17 +44,6 @@ for the future release. You can find the trees here: - https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git - https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git -How do I indicate which tree (net vs. net-next) my patch should be in? ----------------------------------------------------------------------- -To help maintainers and CI bots you should explicitly mark which tree -your patch is targeting. Assuming that you use git, use the prefix -flag:: - - git format-patch --subject-prefix='PATCH net-next' start..finish - -Use ``net`` instead of ``net-next`` (always lower case) in the above for -bug-fix ``net`` content. - How often do changes from these trees make it to the mainline Linus tree? ------------------------------------------------------------------------- To understand this, you need to know a bit of background information on @@ -127,15 +116,6 @@ patch. Patches are indexed by the ``Message-ID`` header of the emails which carried them so if you have trouble finding your patch append the value of ``Message-ID`` to the URL above. -How long before my patch is accepted? -------------------------------------- -Generally speaking, the patches get triaged quickly (in less than -48h). But be patient, if your patch is active in patchwork (i.e. it's -listed on the project's patch list) the chances it was missed are close to zero. -Asking the maintainer for status updates on your -patch is a good way to ensure your patch is ignored or pushed to the -bottom of the priority list. - Should I directly update patchwork state of my own patches? ----------------------------------------------------------- It may be tempting to help the maintainers and update the state of your @@ -145,19 +125,14 @@ it to the maintainer to figure out what is the most recent and current version that should be applied. If there is any doubt, the maintainer will reply and ask what should be done. -How do I divide my work into patches? +How long before my patch is accepted? ------------------------------------- - -Put yourself in the shoes of the reviewer. Each patch is read separately -and therefore should constitute a comprehensible step towards your stated -goal. - -Avoid sending series longer than 15 patches. Larger series takes longer -to review as reviewers will defer looking at it until they find a large -chunk of time. A small series can be reviewed in a short time, so Maintainers -just do it. As a result, a sequence of smaller series gets merged quicker and -with better review coverage. Re-posting large series also increases the mailing -list traffic. +Generally speaking, the patches get triaged quickly (in less than +48h). But be patient, if your patch is active in patchwork (i.e. it's +listed on the project's patch list) the chances it was missed are close to zero. +Asking the maintainer for status updates on your +patch is a good way to ensure your patch is ignored or pushed to the +bottom of the priority list. I made changes to only a few patches in a patch series should I resend only those changed? ------------------------------------------------------------------------------------------ @@ -165,17 +140,6 @@ No, please resend the entire patch series and make sure you do number your patches such that it is clear this is the latest and greatest set of patches that can be applied. -I have received review feedback, when should I post a revised version of the patches? -------------------------------------------------------------------------------------- -Allow at least 24 hours to pass between postings. This will ensure reviewers -from all geographical locations have a chance to chime in. Do not wait -too long (weeks) between postings either as it will make it harder for reviewers -to recall all the context. - -Make sure you address all the feedback in your new posting. Do not post a new -version of the code if the discussion about the previous version is still -ongoing, unless directly instructed by a reviewer. - I submitted multiple versions of a patch series and it looks like a version other than the last one has been accepted, what should I do? ---------------------------------------------------------------------------------------------------------------------------------------- There is no revert possible, once it is pushed out, it stays like that. @@ -191,6 +155,82 @@ the case today. Please follow the standard stable rules in :ref:`Documentation/process/stable-kernel-rules.rst `, and make sure you include appropriate Fixes tags! +I found a bug that might have possible security implications or similar. Should I mail the main netdev maintainer off-list? +--------------------------------------------------------------------------------------------------------------------------- +No. The current netdev maintainer has consistently requested that +people use the mailing lists and not reach out directly. If you aren't +OK with that, then perhaps consider mailing security@kernel.org or +reading about http://oss-security.openwall.org/wiki/mailing-lists/distros +as possible alternative mechanisms. + +How do I post corresponding changes to user space components? +------------------------------------------------------------- +User space code exercising kernel features should be posted +alongside kernel patches. This gives reviewers a chance to see +how any new interface is used and how well it works. + +When user space tools reside in the kernel repo itself all changes +should generally come as one series. If series becomes too large +or the user space project is not reviewed on netdev include a link +to a public repo where user space patches can be seen. + +In case user space tooling lives in a separate repository but is +reviewed on netdev (e.g. patches to ``iproute2`` tools) kernel and +user space patches should form separate series (threads) when posted +to the mailing list, e.g.:: + + [PATCH net-next 0/3] net: some feature cover letter + └─ [PATCH net-next 1/3] net: some feature prep + └─ [PATCH net-next 2/3] net: some feature do it + └─ [PATCH net-next 3/3] selftest: net: some feature + + [PATCH iproute2-next] ip: add support for some feature + +Posting as one thread is discouraged because it confuses patchwork +(as of patchwork 2.2.2). + +Any other tips to help ensure my net/net-next patch gets OK'd? +-------------------------------------------------------------- +Attention to detail. Re-read your own work as if you were the +reviewer. You can start with using ``checkpatch.pl``, perhaps even with +the ``--strict`` flag. But do not be mindlessly robotic in doing so. +If your change is a bug fix, make sure your commit log indicates the +end-user visible symptom, the underlying reason as to why it happens, +and then if necessary, explain why the fix proposed is the best way to +get things done. Don't mangle whitespace, and as is common, don't +mis-indent function arguments that span multiple lines. If it is your +first patch, mail it to yourself so you can test apply it to an +unpatched tree to confirm infrastructure didn't mangle it. + +Finally, go back and read +:ref:`Documentation/process/submitting-patches.rst ` +to be sure you are not repeating some common mistake documented there. + +How do I indicate which tree (net vs. net-next) my patch should be in? +---------------------------------------------------------------------- +To help maintainers and CI bots you should explicitly mark which tree +your patch is targeting. Assuming that you use git, use the prefix +flag:: + + git format-patch --subject-prefix='PATCH net-next' start..finish + +Use ``net`` instead of ``net-next`` (always lower case) in the above for +bug-fix ``net`` content. + +How do I divide my work into patches? +------------------------------------- + +Put yourself in the shoes of the reviewer. Each patch is read separately +and therefore should constitute a comprehensible step towards your stated +goal. + +Avoid sending series longer than 15 patches. Larger series takes longer +to review as reviewers will defer looking at it until they find a large +chunk of time. A small series can be reviewed in a short time, so Maintainers +just do it. As a result, a sequence of smaller series gets merged quicker and +with better review coverage. Re-posting large series also increases the mailing +list traffic. + Is the comment style convention different for the networking content? --------------------------------------------------------------------- Yes, in a largely trivial way. Instead of this:: @@ -224,13 +264,16 @@ I am working in existing code which uses non-standard formatting. Which formatti Make your code follow the most recent guidelines, so that eventually all code in the domain of netdev is in the preferred format. -I found a bug that might have possible security implications or similar. Should I mail the main netdev maintainer off-list? ---------------------------------------------------------------------------------------------------------------------------- -No. The current netdev maintainer has consistently requested that -people use the mailing lists and not reach out directly. If you aren't -OK with that, then perhaps consider mailing security@kernel.org or -reading about http://oss-security.openwall.org/wiki/mailing-lists/distros -as possible alternative mechanisms. +I have received review feedback, when should I post a revised version of the patches? +------------------------------------------------------------------------------------- +Allow at least 24 hours to pass between postings. This will ensure reviewers +from all geographical locations have a chance to chime in. Do not wait +too long (weeks) between postings either as it will make it harder for reviewers +to recall all the context. + +Make sure you address all the feedback in your new posting. Do not post a new +version of the code if the discussion about the previous version is still +ongoing, unless directly instructed by a reviewer. What level of testing is expected before I submit my change? ------------------------------------------------------------ @@ -244,32 +287,6 @@ and the patch series contains a set of kernel selftest for You are expected to test your changes on top of the relevant networking tree (``net`` or ``net-next``) and not e.g. a stable tree or ``linux-next``. -How do I post corresponding changes to user space components? -------------------------------------------------------------- -User space code exercising kernel features should be posted -alongside kernel patches. This gives reviewers a chance to see -how any new interface is used and how well it works. - -When user space tools reside in the kernel repo itself all changes -should generally come as one series. If series becomes too large -or the user space project is not reviewed on netdev include a link -to a public repo where user space patches can be seen. - -In case user space tooling lives in a separate repository but is -reviewed on netdev (e.g. patches to ``iproute2`` tools) kernel and -user space patches should form separate series (threads) when posted -to the mailing list, e.g.:: - - [PATCH net-next 0/3] net: some feature cover letter - └─ [PATCH net-next 1/3] net: some feature prep - └─ [PATCH net-next 2/3] net: some feature do it - └─ [PATCH net-next 3/3] selftest: net: some feature - - [PATCH iproute2-next] ip: add support for some feature - -Posting as one thread is discouraged because it confuses patchwork -(as of patchwork 2.2.2). - Can I reproduce the checks from patchwork on my local machine? -------------------------------------------------------------- @@ -303,23 +320,6 @@ it has a real, in-tree user. Mock-ups and tests based on ``netdevsim`` are strongly encouraged when adding new APIs, but ``netdevsim`` in itself is **not** considered a use case/user. -Any other tips to help ensure my net/net-next patch gets OK'd? --------------------------------------------------------------- -Attention to detail. Re-read your own work as if you were the -reviewer. You can start with using ``checkpatch.pl``, perhaps even with -the ``--strict`` flag. But do not be mindlessly robotic in doing so. -If your change is a bug fix, make sure your commit log indicates the -end-user visible symptom, the underlying reason as to why it happens, -and then if necessary, explain why the fix proposed is the best way to -get things done. Don't mangle whitespace, and as is common, don't -mis-indent function arguments that span multiple lines. If it is your -first patch, mail it to yourself so you can test apply it to an -unpatched tree to confirm infrastructure didn't mangle it. - -Finally, go back and read -:ref:`Documentation/process/submitting-patches.rst ` -to be sure you are not repeating some common mistake documented there. - My company uses peer feedback in employee performance reviews. Can I ask netdev maintainers for feedback? --------------------------------------------------------------------------------------------------------- -- cgit v1.2.3 From ff249be5cca9f982e58936847ba6c30104abbcad Mon Sep 17 00:00:00 2001 From: Jakub Kicinski Date: Thu, 22 Dec 2022 11:22:48 -0800 Subject: docs: netdev: convert to a non-FAQ document The netdev-FAQ document has grown over the years to the point where finding information in it is somewhat challenging. The length of the questions prevents readers from locating content that's relevant at a glance. Convert to a more standard documentation format with sections and sub-sections rather than questions and answers. The content edits are limited to what's necessary to change the format, and very minor clarifications. Reviewed-by: Randy Dunlap Reviewed-by: Andrew Lunn Signed-off-by: Jakub Kicinski Signed-off-by: David S. Miller --- Documentation/process/maintainer-netdev.rst | 221 ++++++++++++++++------------ 1 file changed, 125 insertions(+), 96 deletions(-) (limited to 'Documentation') diff --git a/Documentation/process/maintainer-netdev.rst b/Documentation/process/maintainer-netdev.rst index 8f22f8a3dcd1..4a75686d35ab 100644 --- a/Documentation/process/maintainer-netdev.rst +++ b/Documentation/process/maintainer-netdev.rst @@ -2,9 +2,9 @@ .. _netdev-FAQ: -========== -netdev FAQ -========== +============================= +Networking subsystem (netdev) +============================= tl;dr ----- @@ -15,14 +15,15 @@ tl;dr - don't repost your patches within one 24h period - reverse xmas tree -What is netdev? ---------------- -It is a mailing list for all network-related Linux stuff. This +netdev +------ + +netdev is a mailing list for all network-related Linux stuff. This includes anything found under net/ (i.e. core code like IPv6) and drivers/net (i.e. hardware specific drivers) in the Linux source tree. Note that some subsystems (e.g. wireless drivers) which have a high -volume of traffic have their own specific mailing lists. +volume of traffic have their own specific mailing lists and trees. The netdev list is managed (like many other Linux mailing lists) through VGER (http://vger.kernel.org/) with archives available at @@ -32,21 +33,10 @@ Aside from subsystems like those mentioned above, all network-related Linux development (i.e. RFC, review, comments, etc.) takes place on netdev. -How do the changes posted to netdev make their way into Linux? --------------------------------------------------------------- -There are always two trees (git repositories) in play. Both are -driven by David Miller, the main network maintainer. There is the -``net`` tree, and the ``net-next`` tree. As you can probably guess from -the names, the ``net`` tree is for fixes to existing code already in the -mainline tree from Linus, and ``net-next`` is where the new code goes -for the future release. You can find the trees here: - -- https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git -- https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git +Development cycle +----------------- -How often do changes from these trees make it to the mainline Linus tree? -------------------------------------------------------------------------- -To understand this, you need to know a bit of background information on +Here is a bit of background information on the cadence of Linux development. Each new release starts off with a two week "merge window" where the main maintainers feed their new stuff to Linus for merging into the mainline tree. After the two weeks, the @@ -58,9 +48,33 @@ rc2 is released. This repeats on a roughly weekly basis until rc7 state of churn), and a week after the last vX.Y-rcN was done, the official vX.Y is released. -Relating that to netdev: At the beginning of the 2-week merge window, -the ``net-next`` tree will be closed - no new changes/features. The -accumulated new content of the past ~10 weeks will be passed onto +To find out where we are now in the cycle - load the mainline (Linus) +page here: + + https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git + +and note the top of the "tags" section. If it is rc1, it is early in +the dev cycle. If it was tagged rc7 a week ago, then a release is +probably imminent. If the most recent tag is a final release tag +(without an ``-rcN`` suffix) - we are most likely in a merge window +and ``net-next`` is closed. + +git trees and patch flow +------------------------ + +There are two networking trees (git repositories) in play. Both are +driven by David Miller, the main network maintainer. There is the +``net`` tree, and the ``net-next`` tree. As you can probably guess from +the names, the ``net`` tree is for fixes to existing code already in the +mainline tree from Linus, and ``net-next`` is where the new code goes +for the future release. You can find the trees here: + +- https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git +- https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git + +Relating that to kernel development: At the beginning of the 2-week +merge window, the ``net-next`` tree will be closed - no new changes/features. +The accumulated new content of the past ~10 weeks will be passed onto mainline/Linus via a pull request for vX.Y -- at the same time, the ``net`` tree will start accumulating fixes for this pulled content relating to vX.Y @@ -92,22 +106,14 @@ focus for ``net`` is on stabilization and bug fixes. Finally, the vX.Y gets released, and the whole cycle starts over. -So where are we now in this cycle? ----------------------------------- +netdev patch review +------------------- -Load the mainline (Linus) page here: +Patch status +~~~~~~~~~~~~ - https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git - -and note the top of the "tags" section. If it is rc1, it is early in -the dev cycle. If it was tagged rc7 a week ago, then a release is -probably imminent. If the most recent tag is a final release tag -(without an ``-rcN`` suffix) - we are most likely in a merge window -and ``net-next`` is closed. - -How can I tell the status of a patch I've sent? ------------------------------------------------ -Start by looking at the main patchworks queue for netdev: +Status of a patch can be checked by looking at the main patchwork +queue for netdev: https://patchwork.kernel.org/project/netdevbpf/list/ @@ -116,17 +122,20 @@ patch. Patches are indexed by the ``Message-ID`` header of the emails which carried them so if you have trouble finding your patch append the value of ``Message-ID`` to the URL above. -Should I directly update patchwork state of my own patches? ------------------------------------------------------------ +Updating patch status +~~~~~~~~~~~~~~~~~~~~~ + It may be tempting to help the maintainers and update the state of your -own patches when you post a new version or spot a bug. Please do not do that. +own patches when you post a new version or spot a bug. Please **do not** +do that. Interfering with the patch status on patchwork will only cause confusion. Leave it to the maintainer to figure out what is the most recent and current version that should be applied. If there is any doubt, the maintainer will reply and ask what should be done. -How long before my patch is accepted? -------------------------------------- +Review timelines +~~~~~~~~~~~~~~~~ + Generally speaking, the patches get triaged quickly (in less than 48h). But be patient, if your patch is active in patchwork (i.e. it's listed on the project's patch list) the chances it was missed are close to zero. @@ -134,37 +143,47 @@ Asking the maintainer for status updates on your patch is a good way to ensure your patch is ignored or pushed to the bottom of the priority list. -I made changes to only a few patches in a patch series should I resend only those changed? ------------------------------------------------------------------------------------------- -No, please resend the entire patch series and make sure you do number your +Partial resends +~~~~~~~~~~~~~~~ + +Please always resend the entire patch series and make sure you do number your patches such that it is clear this is the latest and greatest set of patches -that can be applied. +that can be applied. Do not try to resend just the patches which changed. + +Handling misapplied patches +~~~~~~~~~~~~~~~~~~~~~~~~~~~ -I submitted multiple versions of a patch series and it looks like a version other than the last one has been accepted, what should I do? ----------------------------------------------------------------------------------------------------------------------------------------- +Occasionally a patch series gets applied before receiving critical feedback, +or the wrong version of a series gets applied. There is no revert possible, once it is pushed out, it stays like that. Please send incremental versions on top of what has been merged in order to fix the patches the way they would look like if your latest patch series was to be merged. -Are there special rules regarding stable submissions on netdev? ---------------------------------------------------------------- +Stable tree +~~~~~~~~~~~ + While it used to be the case that netdev submissions were not supposed to carry explicit ``CC: stable@vger.kernel.org`` tags that is no longer the case today. Please follow the standard stable rules in :ref:`Documentation/process/stable-kernel-rules.rst `, and make sure you include appropriate Fixes tags! -I found a bug that might have possible security implications or similar. Should I mail the main netdev maintainer off-list? ---------------------------------------------------------------------------------------------------------------------------- -No. The current netdev maintainer has consistently requested that +Security fixes +~~~~~~~~~~~~~~ + +Do not email netdev maintainers directly if you think you discovered +a bug that might have possible security implications. +The current netdev maintainer has consistently requested that people use the mailing lists and not reach out directly. If you aren't OK with that, then perhaps consider mailing security@kernel.org or reading about http://oss-security.openwall.org/wiki/mailing-lists/distros as possible alternative mechanisms. -How do I post corresponding changes to user space components? -------------------------------------------------------------- + +Co-posting changes to user space components +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + User space code exercising kernel features should be posted alongside kernel patches. This gives reviewers a chance to see how any new interface is used and how well it works. @@ -189,9 +208,10 @@ to the mailing list, e.g.:: Posting as one thread is discouraged because it confuses patchwork (as of patchwork 2.2.2). -Any other tips to help ensure my net/net-next patch gets OK'd? --------------------------------------------------------------- -Attention to detail. Re-read your own work as if you were the +Preparing changes +----------------- + +Attention to detail is important. Re-read your own work as if you were the reviewer. You can start with using ``checkpatch.pl``, perhaps even with the ``--strict`` flag. But do not be mindlessly robotic in doing so. If your change is a bug fix, make sure your commit log indicates the @@ -206,8 +226,9 @@ Finally, go back and read :ref:`Documentation/process/submitting-patches.rst ` to be sure you are not repeating some common mistake documented there. -How do I indicate which tree (net vs. net-next) my patch should be in? ----------------------------------------------------------------------- +Indicating target tree +~~~~~~~~~~~~~~~~~~~~~~ + To help maintainers and CI bots you should explicitly mark which tree your patch is targeting. Assuming that you use git, use the prefix flag:: @@ -217,8 +238,8 @@ flag:: Use ``net`` instead of ``net-next`` (always lower case) in the above for bug-fix ``net`` content. -How do I divide my work into patches? -------------------------------------- +Dividing work into patches +~~~~~~~~~~~~~~~~~~~~~~~~~~ Put yourself in the shoes of the reviewer. Each patch is read separately and therefore should constitute a comprehensible step towards your stated @@ -231,9 +252,11 @@ just do it. As a result, a sequence of smaller series gets merged quicker and with better review coverage. Re-posting large series also increases the mailing list traffic. -Is the comment style convention different for the networking content? ---------------------------------------------------------------------- -Yes, in a largely trivial way. Instead of this:: +Multi-line comments +~~~~~~~~~~~~~~~~~~~ + +Comment style convention is slightly different for networking and most of +the tree. Instead of this:: /* * foobar blah blah blah @@ -246,8 +269,8 @@ it is requested that you make it look like this:: * another line of text */ -What is "reverse xmas tree"? ----------------------------- +Local variable ordering ("reverse xmas tree", "RCS") +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Netdev has a convention for ordering local variables in functions. Order the variable declaration lines longest to shortest, e.g.:: @@ -259,13 +282,16 @@ Order the variable declaration lines longest to shortest, e.g.:: If there are dependencies between the variables preventing the ordering move the initialization out of line. -I am working in existing code which uses non-standard formatting. Which formatting should I use? ------------------------------------------------------------------------------------------------- -Make your code follow the most recent guidelines, so that eventually all code +Format precedence +~~~~~~~~~~~~~~~~~ + +When working in existing code which uses nonstandard formatting make +your code follow the most recent guidelines, so that eventually all code in the domain of netdev is in the preferred format. -I have received review feedback, when should I post a revised version of the patches? -------------------------------------------------------------------------------------- +Resending after review +~~~~~~~~~~~~~~~~~~~~~~ + Allow at least 24 hours to pass between postings. This will ensure reviewers from all geographical locations have a chance to chime in. Do not wait too long (weeks) between postings either as it will make it harder for reviewers @@ -275,8 +301,12 @@ Make sure you address all the feedback in your new posting. Do not post a new version of the code if the discussion about the previous version is still ongoing, unless directly instructed by a reviewer. -What level of testing is expected before I submit my change? ------------------------------------------------------------- +Testing +------- + +Expected level of testing +~~~~~~~~~~~~~~~~~~~~~~~~~ + At the very minimum your changes must survive an ``allyesconfig`` and an ``allmodconfig`` build with ``W=1`` set without new warnings or failures. @@ -287,43 +317,42 @@ and the patch series contains a set of kernel selftest for You are expected to test your changes on top of the relevant networking tree (``net`` or ``net-next``) and not e.g. a stable tree or ``linux-next``. -Can I reproduce the checks from patchwork on my local machine? --------------------------------------------------------------- +patchwork checks +~~~~~~~~~~~~~~~~ Checks in patchwork are mostly simple wrappers around existing kernel scripts, the sources are available at: https://github.com/kuba-moo/nipa/tree/master/tests -Running all the builds and checks locally is a pain, can I post my patches and have the patchwork bot validate them? --------------------------------------------------------------------------------------------------------------------- - -No, you must ensure that your patches are ready by testing them locally +**Do not** post your patches just to run them through the checks. +You must ensure that your patches are ready by testing them locally before posting to the mailing list. The patchwork build bot instance gets overloaded very easily and netdev@vger really doesn't need more traffic if we can help it. -netdevsim is great, can I extend it for my out-of-tree tests? -------------------------------------------------------------- +netdevsim +~~~~~~~~~ -No, ``netdevsim`` is a test vehicle solely for upstream tests. -(Please add your tests under ``tools/testing/selftests/``.) +``netdevsim`` is a test driver which can be used to exercise driver +configuration APIs without requiring capable hardware. +Mock-ups and tests based on ``netdevsim`` are strongly encouraged when +adding new APIs, but ``netdevsim`` in itself is **not** considered +a use case/user. You must also implement the new APIs in a real driver. -We also give no guarantees that ``netdevsim`` won't change in the future +We give no guarantees that ``netdevsim`` won't change in the future in a way which would break what would normally be considered uAPI. -Is netdevsim considered a "user" of an API? -------------------------------------------- - -Linux kernel has a long standing rule that no API should be added unless -it has a real, in-tree user. Mock-ups and tests based on ``netdevsim`` are -strongly encouraged when adding new APIs, but ``netdevsim`` in itself -is **not** considered a use case/user. +``netdevsim`` is reserved for use by upstream tests only, so any +new ``netdevsim`` features must be accompanied by selftests under +``tools/testing/selftests/``. -My company uses peer feedback in employee performance reviews. Can I ask netdev maintainers for feedback? ---------------------------------------------------------------------------------------------------------- +Testimonials / feedback +----------------------- -Yes, especially if you spend significant amount of time reviewing code +Some companies use peer feedback in employee performance reviews. +Please feel free to request feedback from netdev maintainers, +especially if you spend significant amount of time reviewing code and go out of your way to improve shared infrastructure. The feedback must be requested by you, the contributor, and will always -- cgit v1.2.3 From 02d9a04da453984b16f4a585ad808cf961df495e Mon Sep 17 00:00:00 2001 From: Paolo Bonzini Date: Wed, 28 Dec 2022 06:00:22 -0500 Subject: Documentation: kvm: clarify SRCU locking order Currently only the locking order of SRCU vs kvm->slots_arch_lock and kvm->slots_lock is documented. Extend this to kvm->lock since Xen emulation got it terribly wrong. Signed-off-by: Paolo Bonzini --- Documentation/virt/kvm/locking.rst | 19 ++++++++++++++----- 1 file changed, 14 insertions(+), 5 deletions(-) (limited to 'Documentation') diff --git a/Documentation/virt/kvm/locking.rst b/Documentation/virt/kvm/locking.rst index 845a561629f1..a3ca76f9be75 100644 --- a/Documentation/virt/kvm/locking.rst +++ b/Documentation/virt/kvm/locking.rst @@ -16,17 +16,26 @@ The acquisition orders for mutexes are as follows: - kvm->slots_lock is taken outside kvm->irq_lock, though acquiring them together is quite rare. -- Unlike kvm->slots_lock, kvm->slots_arch_lock is released before - synchronize_srcu(&kvm->srcu). Therefore kvm->slots_arch_lock - can be taken inside a kvm->srcu read-side critical section, - while kvm->slots_lock cannot. - - kvm->mn_active_invalidate_count ensures that pairs of invalidate_range_start() and invalidate_range_end() callbacks use the same memslots array. kvm->slots_lock and kvm->slots_arch_lock are taken on the waiting side in install_new_memslots, so MMU notifiers must not take either kvm->slots_lock or kvm->slots_arch_lock. +For SRCU: + +- ``synchronize_srcu(&kvm->srcu)`` is called _inside_ + the kvm->slots_lock critical section, therefore kvm->slots_lock + cannot be taken inside a kvm->srcu read-side critical section. + Instead, kvm->slots_arch_lock is released before the call + to ``synchronize_srcu()`` and _can_ be taken inside a + kvm->srcu read-side critical section. + +- kvm->lock is taken inside kvm->srcu, therefore + ``synchronize_srcu(&kvm->srcu)`` cannot be called inside + a kvm->lock critical section. If you cannot delay the + call until after kvm->lock is released, use ``call_srcu``. + On x86: - vcpu->mutex is taken outside kvm->arch.hyperv.hv_lock -- cgit v1.2.3 From 8ca4fc323d2e4ab9dabbdd57633af40b0c7e6af9 Mon Sep 17 00:00:00 2001 From: Christoph Hellwig Date: Mon, 12 Dec 2022 11:09:55 +0100 Subject: docs, nvme: add a feature and quirk policy document This adds a document about what specification features are supported by the Linux NVMe driver, and what qualifies for a quirk if an implementation has problems following the specification. Signed-off-by: Jens Axboe Signed-off-by: Keith Busch Signed-off-by: Sagi Grimberg Signed-off-by: Christoph Hellwig Reviewed-by: Randy Dunlap Acked-by: Jonathan Corbet --- .../maintainer/maintainer-entry-profile.rst | 1 + Documentation/nvme/feature-and-quirk-policy.rst | 77 ++++++++++++++++++++++ 2 files changed, 78 insertions(+) create mode 100644 Documentation/nvme/feature-and-quirk-policy.rst (limited to 'Documentation') diff --git a/Documentation/maintainer/maintainer-entry-profile.rst b/Documentation/maintainer/maintainer-entry-profile.rst index 93b2ae6c34a9..cfd37f31077f 100644 --- a/Documentation/maintainer/maintainer-entry-profile.rst +++ b/Documentation/maintainer/maintainer-entry-profile.rst @@ -104,3 +104,4 @@ to do something different in the near future. ../riscv/patch-acceptance ../driver-api/media/maintainer-entry-profile ../driver-api/vfio-pci-device-specific-driver-acceptance + ../nvme/feature-and-quirk-policy diff --git a/Documentation/nvme/feature-and-quirk-policy.rst b/Documentation/nvme/feature-and-quirk-policy.rst new file mode 100644 index 000000000000..c01d836d8e41 --- /dev/null +++ b/Documentation/nvme/feature-and-quirk-policy.rst @@ -0,0 +1,77 @@ +.. SPDX-License-Identifier: GPL-2.0 + +======================================= +Linux NVMe feature and and quirk policy +======================================= + +This file explains the policy used to decide what is supported by the +Linux NVMe driver and what is not. + + +Introduction +============ + +NVM Express is an open collection of standards and information. + +The Linux NVMe host driver in drivers/nvme/host/ supports devices +implementing the NVM Express (NVMe) family of specifications, which +currently consists of a number of documents: + + - the NVMe Base specification + - various Command Set specifications (e.g. NVM Command Set) + - various Transport specifications (e.g. PCIe, Fibre Channel, RDMA, TCP) + - the NVMe Management Interface specification + +See https://nvmexpress.org/developers/ for the NVMe specifications. + + +Supported features +================== + +NVMe is a large suite of specifications, and contains features that are only +useful or suitable for specific use-cases. It is important to note that Linux +does not aim to implement every feature in the specification. Every additional +feature implemented introduces more code, more maintenance and potentially more +bugs. Hence there is an inherent tradeoff between functionality and +maintainability of the NVMe host driver. + +Any feature implemented in the Linux NVMe host driver must support the +following requirements: + + 1. The feature is specified in a release version of an official NVMe + specification, or in a ratified Technical Proposal (TP) that is + available on NVMe website. Or if it is not directly related to the + on-wire protocol, does not contradict any of the NVMe specifications. + 2. Does not conflict with the Linux architecture, nor the design of the + NVMe host driver. + 3. Has a clear, indisputable value-proposition and a wide consensus across + the community. + +Vendor specific extensions are generally not supported in the NVMe host +driver. + +It is strongly recommended to work with the Linux NVMe and block layer +maintainers and get feedback on specification changes that are intended +to be used by the Linux NVMe host driver in order to avoid conflict at a +later stage. + + +Quirks +====== + +Sometimes implementations of open standards fail to correctly implement parts +of the standards. Linux uses identifier-based quirks to work around such +implementation bugs. The intent of quirks is to deal with widely available +hardware, usually consumer, which Linux users can't use without these quirks. +Typically these implementations are not or only superficially tested with Linux +by the hardware manufacturer. + +The Linux NVMe maintainers decide ad hoc whether to quirk implementations +based on the impact of the problem to Linux users and how it impacts +maintainability of the driver. In general quirks are a last resort, if no +firmware updates or other workarounds are available from the vendor. + +Quirks will not be added to the Linux kernel for hardware that isn't available +on the mass market. Hardware that fails qualification for enterprise Linux +distributions, ChromeOS, Android or other consumers of the Linux kernel +should be fixed before it is shipped instead of relying on Linux quirks. -- cgit v1.2.3 From a3542b0ccd58f9fd42f34afa9daea435279a7c1c Mon Sep 17 00:00:00 2001 From: Samuel Holland Date: Sat, 31 Dec 2022 16:05:46 -0600 Subject: dt-bindings: net: sun8i-emac: Add phy-supply property This property has always been supported by the Linux driver; see commit 9f93ac8d4085 ("net-next: stmmac: Add dwmac-sun8i"). In fact, the original driver submission includes the phy-supply code but no mention of it in the binding, so the omission appears to be accidental. In addition, the property is documented in the binding for the previous hardware generation, allwinner,sun7i-a20-gmac. Document phy-supply in the binding to fix devicetree validation for the 25+ boards that already use this property. Fixes: 0441bde003be ("dt-bindings: net-next: Add DT bindings documentation for Allwinner dwmac-sun8i") Acked-by: Rob Herring Reviewed-by: Andre Przywara Signed-off-by: Samuel Holland Signed-off-by: David S. Miller --- Documentation/devicetree/bindings/net/allwinner,sun8i-a83t-emac.yaml | 3 +++ 1 file changed, 3 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/allwinner,sun8i-a83t-emac.yaml b/Documentation/devicetree/bindings/net/allwinner,sun8i-a83t-emac.yaml index 1432fda3b603..47bc2057e629 100644 --- a/Documentation/devicetree/bindings/net/allwinner,sun8i-a83t-emac.yaml +++ b/Documentation/devicetree/bindings/net/allwinner,sun8i-a83t-emac.yaml @@ -40,6 +40,9 @@ properties: clock-names: const: stmmaceth + phy-supply: + description: PHY regulator + syscon: $ref: /schemas/types.yaml#/definitions/phandle description: -- cgit v1.2.3 From 91e2286160edd29d3fea8efff2dcda7df321878d Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Micha=C5=82=20Grzelak?= Date: Thu, 29 Dec 2022 15:22:19 +0100 Subject: dt-bindings: net: marvell,orion-mdio: Fix examples MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit As stated in marvell-orion-mdio.txt deleted in commit 0781434af811f ("dt-bindings: net: orion-mdio: Convert to JSON schema") if 'interrupts' property is present, width of 'reg' should be 0x84. Otherwise, width of 'reg' should be 0x4. Fix 'examples:' and add constraints checking whether 'interrupts' property is present and validate it against fixed values in reg. Signed-off-by: Michał Grzelak Reviewed-by: Krzysztof Kozlowski Signed-off-by: David S. Miller --- .../bindings/net/marvell,orion-mdio.yaml | 30 +++++++++++++++++++--- 1 file changed, 26 insertions(+), 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/marvell,orion-mdio.yaml b/Documentation/devicetree/bindings/net/marvell,orion-mdio.yaml index d2906b4a0f59..e35da8b01dc2 100644 --- a/Documentation/devicetree/bindings/net/marvell,orion-mdio.yaml +++ b/Documentation/devicetree/bindings/net/marvell,orion-mdio.yaml @@ -16,9 +16,6 @@ description: | 8k has a second unit which provides an interface with the xMDIO bus. This driver handles these interfaces. -allOf: - - $ref: "mdio.yaml#" - properties: compatible: enum: @@ -39,13 +36,38 @@ required: - compatible - reg +allOf: + - $ref: mdio.yaml# + + - if: + required: + - interrupts + + then: + properties: + reg: + items: + - items: + - $ref: /schemas/types.yaml#/definitions/cell + - const: 0x84 + + else: + properties: + reg: + items: + - items: + - $ref: /schemas/types.yaml#/definitions/cell + - enum: + - 0x4 + - 0x10 + unevaluatedProperties: false examples: - | mdio@d0072004 { compatible = "marvell,orion-mdio"; - reg = <0xd0072004 0x4>; + reg = <0xd0072004 0x84>; #address-cells = <1>; #size-cells = <0>; interrupts = <30>; -- cgit v1.2.3