diff options
Diffstat (limited to 'Documentation')
19 files changed, 491 insertions, 56 deletions
diff --git a/Documentation/ABI/testing/sysfs-bus-nfit b/Documentation/ABI/testing/sysfs-bus-nfit index a1cb44dcb908..e4f76e7eab93 100644 --- a/Documentation/ABI/testing/sysfs-bus-nfit +++ b/Documentation/ABI/testing/sysfs-bus-nfit @@ -202,6 +202,25 @@ Description: functions. See the section named 'NVDIMM Root Device _DSMs' in the ACPI specification. +What: /sys/bus/nd/devices/ndbusX/nfit/firmware_activate_noidle +Date: Apr, 2020 +KernelVersion: v5.8 +Contact: linux-nvdimm@lists.01.org +Description: + (RW) The Intel platform implementation of firmware activate + support exposes an option let the platform force idle devices in + the system over the activation event, or trust that the OS will + do it. The safe default is to let the platform force idle + devices since the kernel is already in a suspend state, and on + the chance that a driver does not properly quiesce bus-mastering + after a suspend callback the platform will handle it. However, + the activation might abort if, for example, platform firmware + determines that the activation time exceeds the max PCI-E + completion timeout. Since the platform does not know whether the + OS is running the activation from a suspend context it aborts, + but if the system owner trusts driver suspend callback to be + sufficient then 'firmware_activation_noidle' can be + enabled to bypass the activation abort. What: /sys/bus/nd/devices/regionX/nfit/range_index Date: Jun, 2015 diff --git a/Documentation/ABI/testing/sysfs-bus-nvdimm b/Documentation/ABI/testing/sysfs-bus-nvdimm new file mode 100644 index 000000000000..d64380262be8 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-bus-nvdimm @@ -0,0 +1,2 @@ +The libnvdimm sub-system implements a common sysfs interface for +platform nvdimm resources. See Documentation/driver-api/nvdimm/. diff --git a/Documentation/arm64/silicon-errata.rst b/Documentation/arm64/silicon-errata.rst index 3f7c3a7e8a2b..d3587805de64 100644 --- a/Documentation/arm64/silicon-errata.rst +++ b/Documentation/arm64/silicon-errata.rst @@ -125,6 +125,9 @@ stable kernels. | Cavium | ThunderX2 Core | #219 | CAVIUM_TX2_ERRATUM_219 | +----------------+-----------------+-----------------+-----------------------------+ +----------------+-----------------+-----------------+-----------------------------+ +| Marvell | ARM-MMU-500 | #582743 | N/A | ++----------------+-----------------+-----------------+-----------------------------+ ++----------------+-----------------+-----------------+-----------------------------+ | Freescale/NXP | LS2080A/LS1043A | A-008585 | FSL_ERRATUM_A008585 | +----------------+-----------------+-----------------+-----------------------------+ +----------------+-----------------+-----------------+-----------------------------+ diff --git a/Documentation/devicetree/bindings/arm/keystone/ti,k3-sci-common.yaml b/Documentation/devicetree/bindings/arm/keystone/ti,k3-sci-common.yaml new file mode 100644 index 000000000000..7597bc93a55f --- /dev/null +++ b/Documentation/devicetree/bindings/arm/keystone/ti,k3-sci-common.yaml @@ -0,0 +1,44 @@ +# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/arm/keystone/ti,k3-sci-common.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Common K3 TI-SCI bindings + +maintainers: + - Nishanth Menon <nm@ti.com> + +description: | + The TI K3 family of SoCs usually have a central System Controller Processor + that is responsible for managing various SoC-level resources like clocks, + resets, interrupts etc. The communication with that processor is performed + through the TI-SCI protocol. + + Each specific device management node like a clock controller node, a reset + controller node or an interrupt-controller node should define a common set + of properties that enables them to implement the corresponding functionality + over the TI-SCI protocol. The following are some of the common properties + needed by such individual nodes. The required properties for each device + management node is defined in the respective binding. + +properties: + ti,sci: + $ref: /schemas/types.yaml#/definitions/phandle + description: + Should be a phandle to the TI-SCI System Controller node + + ti,sci-dev-id: + $ref: /schemas/types.yaml#/definitions/uint32 + description: | + Should contain the TI-SCI device id corresponding to the device. Please + refer to the corresponding System Controller documentation for valid + values for the desired device. + + ti,sci-proc-ids: + description: Should contain a single tuple of <proc_id host_id>. + $ref: /schemas/types.yaml#/definitions/uint32-array + items: + - description: TI-SCI processor id for the remote processor device + - description: TI-SCI host id to which processor control ownership + should be transferred to diff --git a/Documentation/devicetree/bindings/hwlock/qcom-hwspinlock.txt b/Documentation/devicetree/bindings/hwlock/qcom-hwspinlock.txt deleted file mode 100644 index 4563f524556b..000000000000 --- a/Documentation/devicetree/bindings/hwlock/qcom-hwspinlock.txt +++ /dev/null @@ -1,39 +0,0 @@ -Qualcomm Hardware Mutex Block: - -The hardware block provides mutexes utilized between different processors on -the SoC as part of the communication protocol used by these processors. - -- compatible: - Usage: required - Value type: <string> - Definition: must be one of: - "qcom,sfpb-mutex", - "qcom,tcsr-mutex" - -- syscon: - Usage: required - Value type: <prop-encoded-array> - Definition: one cell containing: - syscon phandle - offset of the hwmutex block within the syscon - stride of the hwmutex registers - -- #hwlock-cells: - Usage: required - Value type: <u32> - Definition: must be 1, the specified cell represent the lock id - (hwlock standard property, see hwlock.txt) - -Example: - - tcsr_mutex_block: syscon@fd484000 { - compatible = "syscon"; - reg = <0xfd484000 0x2000>; - }; - - hwlock@fd484000 { - compatible = "qcom,tcsr-mutex"; - syscon = <&tcsr_mutex_block 0 0x80>; - - #hwlock-cells = <1>; - }; diff --git a/Documentation/devicetree/bindings/hwlock/qcom-hwspinlock.yaml b/Documentation/devicetree/bindings/hwlock/qcom-hwspinlock.yaml new file mode 100644 index 000000000000..1c7149f7d171 --- /dev/null +++ b/Documentation/devicetree/bindings/hwlock/qcom-hwspinlock.yaml @@ -0,0 +1,42 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/hwlock/qcom-hwspinlock.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Hardware Mutex Block + +maintainers: + - Bjorn Andersson <bjorn.andersson@linaro.org> + +description: + The hardware block provides mutexes utilized between different processors on + the SoC as part of the communication protocol used by these processors. + +properties: + compatible: + enum: + - qcom,sfpb-mutex + - qcom,tcsr-mutex + + reg: + maxItems: 1 + + '#hwlock-cells': + const: 1 + +required: + - compatible + - reg + - '#hwlock-cells' + +additionalProperties: false + +examples: + - | + tcsr_mutex: hwlock@1f40000 { + compatible = "qcom,tcsr-mutex"; + reg = <0x01f40000 0x40000>; + #hwlock-cells = <1>; + }; +... diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml index d7ceb4c34423..503160a7b9a0 100644 --- a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml +++ b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml @@ -37,7 +37,18 @@ properties: - enum: - qcom,sc7180-smmu-500 - qcom,sdm845-smmu-500 + - qcom,sm8150-smmu-500 + - qcom,sm8250-smmu-500 - const: arm,mmu-500 + - description: Marvell SoCs implementing "arm,mmu-500" + items: + - const: marvell,ap806-smmu-500 + - const: arm,mmu-500 + - description: NVIDIA SoCs that program two ARM MMU-500s identically + items: + - enum: + - nvidia,tegra194-smmu + - const: nvidia,smmu-500 - items: - const: arm,mmu-500 - const: arm,smmu-v2 @@ -55,7 +66,8 @@ properties: - cavium,smmu-v2 reg: - maxItems: 1 + minItems: 1 + maxItems: 2 '#global-interrupts': description: The number of global interrupts exposed by the device. @@ -138,6 +150,23 @@ required: additionalProperties: false +allOf: + - if: + properties: + compatible: + contains: + enum: + - nvidia,tegra194-smmu + then: + properties: + reg: + minItems: 2 + maxItems: 2 + else: + properties: + reg: + maxItems: 1 + examples: - |+ /* SMMU with stream matching or stream indexing */ diff --git a/Documentation/devicetree/bindings/iommu/mediatek,iommu.txt b/Documentation/devicetree/bindings/iommu/mediatek,iommu.txt index ce59a505f5a4..c1ccd8582eb2 100644 --- a/Documentation/devicetree/bindings/iommu/mediatek,iommu.txt +++ b/Documentation/devicetree/bindings/iommu/mediatek,iommu.txt @@ -58,6 +58,7 @@ Required properties: - compatible : must be one of the following string: "mediatek,mt2701-m4u" for mt2701 which uses generation one m4u HW. "mediatek,mt2712-m4u" for mt2712 which uses generation two m4u HW. + "mediatek,mt6779-m4u" for mt6779 which uses generation two m4u HW. "mediatek,mt7623-m4u", "mediatek,mt2701-m4u" for mt7623 which uses generation one m4u HW. "mediatek,mt8173-m4u" for mt8173 which uses generation two m4u HW. @@ -78,6 +79,7 @@ Required properties: Specifies the mtk_m4u_id as defined in dt-binding/memory/mt2701-larb-port.h for mt2701, mt7623 dt-binding/memory/mt2712-larb-port.h for mt2712, + dt-binding/memory/mt6779-larb-port.h for mt6779, dt-binding/memory/mt8173-larb-port.h for mt8173, and dt-binding/memory/mt8183-larb-port.h for mt8183. diff --git a/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml b/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml index 5e4fe54f51cd..6bfa090fd73a 100644 --- a/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml +++ b/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml @@ -36,6 +36,7 @@ properties: - renesas,ipmmu-r8a774c0 # RZ/G2E - renesas,ipmmu-r8a7795 # R-Car H3 - renesas,ipmmu-r8a7796 # R-Car M3-W + - renesas,ipmmu-r8a77961 # R-Car M3-W+ - renesas,ipmmu-r8a77965 # R-Car M3-N - renesas,ipmmu-r8a77970 # R-Car V3M - renesas,ipmmu-r8a77980 # R-Car V3H diff --git a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.txt b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.txt index b478ade4da65..b64573680b42 100644 --- a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.txt +++ b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.txt @@ -5,7 +5,7 @@ The hardware block diagram please check bindings/iommu/mediatek,iommu.txt Mediatek SMI have two generations of HW architecture, here is the list which generation the SoCs use: generation 1: mt2701 and mt7623. -generation 2: mt2712, mt8173 and mt8183. +generation 2: mt2712, mt6779, mt8173 and mt8183. There's slight differences between the two SMI, for generation 2, the register which control the iommu port is at each larb's register base. But @@ -18,6 +18,7 @@ Required properties: - compatible : must be one of : "mediatek,mt2701-smi-common" "mediatek,mt2712-smi-common" + "mediatek,mt6779-smi-common" "mediatek,mt7623-smi-common", "mediatek,mt2701-smi-common" "mediatek,mt8173-smi-common" "mediatek,mt8183-smi-common" @@ -35,7 +36,7 @@ Required properties: and these 2 option clocks for generation 2 smi HW: - "gals0": the path0 clock of GALS(Global Async Local Sync). - "gals1": the path1 clock of GALS(Global Async Local Sync). - Here is the list which has this GALS: mt8183. + Here is the list which has this GALS: mt6779 and mt8183. Example: smi_common: smi@14022000 { diff --git a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.txt b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.txt index 4b369b3e1a69..8f19dfe7d80e 100644 --- a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.txt +++ b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.txt @@ -6,6 +6,7 @@ Required properties: - compatible : must be one of : "mediatek,mt2701-smi-larb" "mediatek,mt2712-smi-larb" + "mediatek,mt6779-smi-larb" "mediatek,mt7623-smi-larb", "mediatek,mt2701-smi-larb" "mediatek,mt8173-smi-larb" "mediatek,mt8183-smi-larb" @@ -21,7 +22,7 @@ Required properties: - "gals": the clock for GALS(Global Async Local Sync). Here is the list which has this GALS: mt8183. -Required property for mt2701, mt2712 and mt7623: +Required property for mt2701, mt2712, mt6779 and mt7623: - mediatek,larb-id :the hardware id of this larb. Example: diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,pil-info.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,pil-info.yaml new file mode 100644 index 000000000000..87c52316ddbd --- /dev/null +++ b/Documentation/devicetree/bindings/remoteproc/qcom,pil-info.yaml @@ -0,0 +1,44 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/remoteproc/qcom,pil-info.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm peripheral image loader relocation info binding + +maintainers: + - Bjorn Andersson <bjorn.andersson@linaro.org> + +description: + The Qualcomm peripheral image loader relocation memory region, in IMEM, is + used for communicating remoteproc relocation information to post mortem + debugging tools. + +properties: + compatible: + const: qcom,pil-reloc-info + + reg: + maxItems: 1 + +required: + - compatible + - reg + +examples: + - | + imem@146bf000 { + compatible = "syscon", "simple-mfd"; + reg = <0x146bf000 0x1000>; + + #address-cells = <1>; + #size-cells = <1>; + + ranges = <0 0x146bf000 0x1000>; + + pil-reloc@94c { + compatible = "qcom,pil-reloc-info"; + reg = <0x94c 0xc8>; + }; + }; +... diff --git a/Documentation/devicetree/bindings/remoteproc/ti,k3-dsp-rproc.yaml b/Documentation/devicetree/bindings/remoteproc/ti,k3-dsp-rproc.yaml new file mode 100644 index 000000000000..24b0c50fa436 --- /dev/null +++ b/Documentation/devicetree/bindings/remoteproc/ti,k3-dsp-rproc.yaml @@ -0,0 +1,184 @@ +# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/remoteproc/ti,k3-dsp-rproc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: TI K3 DSP devices + +maintainers: + - Suman Anna <s-anna@ti.com> + +description: | + The TI K3 family of SoCs usually have one or more TI DSP Core sub-systems + that are used to offload some of the processor-intensive tasks or algorithms, + for achieving various system level goals. + + These processor sub-systems usually contain additional sub-modules like + L1 and/or L2 caches/SRAMs, an Interrupt Controller, an external memory + controller, a dedicated local power/sleep controller etc. The DSP processor + cores in the K3 SoCs are usually either a TMS320C66x CorePac processor or a + TMS320C71x CorePac processor. + + Each DSP Core sub-system is represented as a single DT node. Each node has a + number of required or optional properties that enable the OS running on the + host processor (Arm CorePac) to perform the device management of the remote + processor and to communicate with the remote processor. + +allOf: + - $ref: /schemas/arm/keystone/ti,k3-sci-common.yaml# + +properties: + compatible: + enum: + - ti,j721e-c66-dsp + - ti,j721e-c71-dsp + description: + Use "ti,j721e-c66-dsp" for C66x DSPs on K3 J721E SoCs + Use "ti,j721e-c71-dsp" for C71x DSPs on K3 J721E SoCs + + resets: + description: | + Should contain the phandle to the reset controller node managing the + local resets for this device, and a reset specifier. + maxItems: 1 + + firmware-name: + description: | + Should contain the name of the default firmware image + file located on the firmware search path + + mboxes: + description: | + OMAP Mailbox specifier denoting the sub-mailbox, to be used for + communication with the remote processor. This property should match + with the sub-mailbox node used in the firmware image. + maxItems: 1 + + memory-region: + minItems: 2 + maxItems: 8 + description: | + phandle to the reserved memory nodes to be associated with the remoteproc + device. There should be at least two reserved memory nodes defined. The + reserved memory nodes should be carveout nodes, and should be defined as + per the bindings in + Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt + items: + - description: region used for dynamic DMA allocations like vrings and + vring buffers + - description: region reserved for firmware image sections + additionalItems: true + +# Optional properties: +# -------------------- + + sram: + $ref: /schemas/types.yaml#/definitions/phandle-array + minItems: 1 + maxItems: 4 + description: | + phandles to one or more reserved on-chip SRAM regions. 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 + +if: + properties: + compatible: + enum: + - ti,j721e-c66-dsp +then: + properties: + reg: + items: + - description: Address and Size of the L2 SRAM internal memory region + - description: Address and Size of the L1 PRAM internal memory region + - description: Address and Size of the L1 DRAM internal memory region + reg-names: + items: + - const: l2sram + - const: l1pram + - const: l1dram +else: + if: + properties: + compatible: + enum: + - ti,j721e-c71-dsp + then: + properties: + reg: + items: + - description: Address and Size of the L2 SRAM internal memory region + - description: Address and Size of the L1 DRAM internal memory region + reg-names: + items: + - const: l2sram + - const: l1dram + +required: + - compatible + - reg + - reg-names + - ti,sci + - ti,sci-dev-id + - ti,sci-proc-ids + - resets + - firmware-name + - mboxes + - memory-region + +unevaluatedProperties: false + +examples: + - | + / { + model = "Texas Instruments K3 J721E SoC"; + compatible = "ti,j721e"; + #address-cells = <2>; + #size-cells = <2>; + + bus@100000 { + compatible = "simple-bus"; + #address-cells = <2>; + #size-cells = <2>; + ranges = <0x00 0x00100000 0x00 0x00100000 0x00 0x00020000>, /* ctrl mmr */ + <0x00 0x64800000 0x00 0x64800000 0x00 0x00800000>, /* C71_0 */ + <0x4d 0x80800000 0x4d 0x80800000 0x00 0x00800000>, /* C66_0 */ + <0x4d 0x81800000 0x4d 0x81800000 0x00 0x00800000>; /* C66_1 */ + + /* J721E C66_0 DSP node */ + dsp@4d80800000 { + compatible = "ti,j721e-c66-dsp"; + reg = <0x4d 0x80800000 0x00 0x00048000>, + <0x4d 0x80e00000 0x00 0x00008000>, + <0x4d 0x80f00000 0x00 0x00008000>; + reg-names = "l2sram", "l1pram", "l1dram"; + ti,sci = <&dmsc>; + ti,sci-dev-id = <142>; + ti,sci-proc-ids = <0x03 0xFF>; + resets = <&k3_reset 142 1>; + firmware-name = "j7-c66_0-fw"; + memory-region = <&c66_0_dma_memory_region>, + <&c66_0_memory_region>; + mboxes = <&mailbox0_cluster3 &mbox_c66_0>; + }; + + /* J721E C71_0 DSP node */ + c71_0: dsp@64800000 { + compatible = "ti,j721e-c71-dsp"; + reg = <0x00 0x64800000 0x00 0x00080000>, + <0x00 0x64e00000 0x00 0x0000c000>; + reg-names = "l2sram", "l1dram"; + ti,sci = <&dmsc>; + ti,sci-dev-id = <15>; + ti,sci-proc-ids = <0x30 0xFF>; + resets = <&k3_reset 15 1>; + firmware-name = "j7-c71_0-fw"; + memory-region = <&c71_0_dma_memory_region>, + <&c71_0_memory_region>; + mboxes = <&mailbox0_cluster4 &mbox_c71_0>; + }; + }; + }; diff --git a/Documentation/driver-api/nvdimm/firmware-activate.rst b/Documentation/driver-api/nvdimm/firmware-activate.rst new file mode 100644 index 000000000000..7ee7decbbdc3 --- /dev/null +++ b/Documentation/driver-api/nvdimm/firmware-activate.rst @@ -0,0 +1,86 @@ +.. SPDX-License-Identifier: GPL-2.0 + +================================== +NVDIMM Runtime Firmware Activation +================================== + +Some persistent memory devices run a firmware locally on the device / +"DIMM" to perform tasks like media management, capacity provisioning, +and health monitoring. The process of updating that firmware typically +involves a reboot because it has implications for in-flight memory +transactions. However, reboots are disruptive and at least the Intel +persistent memory platform implementation, described by the Intel ACPI +DSM specification [1], has added support for activating firmware at +runtime. + +A native sysfs interface is implemented in libnvdimm to allow platform +to advertise and control their local runtime firmware activation +capability. + +The libnvdimm bus object, ndbusX, implements an ndbusX/firmware/activate +attribute that shows the state of the firmware activation as one of 'idle', +'armed', 'overflow', and 'busy'. + +- idle: + No devices are set / armed to activate firmware + +- armed: + At least one device is armed + +- busy: + In the busy state armed devices are in the process of transitioning + back to idle and completing an activation cycle. + +- overflow: + If the platform has a concept of incremental work needed to perform + the activation it could be the case that too many DIMMs are armed for + activation. In that scenario the potential for firmware activation to + timeout is indicated by the 'overflow' state. + +The 'ndbusX/firmware/activate' property can be written with a value of +either 'live', or 'quiesce'. A value of 'quiesce' triggers the kernel to +run firmware activation from within the equivalent of the hibernation +'freeze' state where drivers and applications are notified to stop their +modifications of system memory. A value of 'live' attempts +firmware activation without this hibernation cycle. The +'ndbusX/firmware/activate' property will be elided completely if no +firmware activation capability is detected. + +Another property 'ndbusX/firmware/capability' indicates a value of +'live' or 'quiesce', where 'live' indicates that the firmware +does not require or inflict any quiesce period on the system to update +firmware. A capability value of 'quiesce' indicates that firmware does +expect and injects a quiet period for the memory controller, but 'live' +may still be written to 'ndbusX/firmware/activate' as an override to +assume the risk of racing firmware update with in-flight device and +application activity. The 'ndbusX/firmware/capability' property will be +elided completely if no firmware activation capability is detected. + +The libnvdimm memory-device / DIMM object, nmemX, implements +'nmemX/firmware/activate' and 'nmemX/firmware/result' attributes to +communicate the per-device firmware activation state. Similar to the +'ndbusX/firmware/activate' attribute, the 'nmemX/firmware/activate' +attribute indicates 'idle', 'armed', or 'busy'. The state transitions +from 'armed' to 'idle' when the system is prepared to activate firmware, +firmware staged + state set to armed, and 'ndbusX/firmware/activate' is +triggered. After that activation event the nmemX/firmware/result +attribute reflects the state of the last activation as one of: + +- none: + No runtime activation triggered since the last time the device was reset + +- success: + The last runtime activation completed successfully. + +- fail: + The last runtime activation failed for device-specific reasons. + +- not_staged: + The last runtime activation failed due to a sequencing error of the + firmware image not being staged. + +- need_reset: + Runtime firmware activation failed, but the firmware can still be + activated via the legacy method of power-cycling the system. + +[1]: https://docs.pmem.io/persistent-memory/ diff --git a/Documentation/filesystems/zonefs.rst b/Documentation/filesystems/zonefs.rst index 71d845c6a700..6c18bc8ce332 100644 --- a/Documentation/filesystems/zonefs.rst +++ b/Documentation/filesystems/zonefs.rst @@ -110,14 +110,14 @@ contain files named "0", "1", "2", ... The file numbers also represent increasing zone start sector on the device. All read and write operations to zone files are not allowed beyond the file -maximum size, that is, beyond the zone size. Any access exceeding the zone -size is failed with the -EFBIG error. +maximum size, that is, beyond the zone capacity. Any access exceeding the zone +capacity is failed with the -EFBIG error. Creating, deleting, renaming or modifying any attribute of files and sub-directories is not allowed. The number of blocks of a file as reported by stat() and fstat() indicates the -size of the file zone, or in other words, the maximum file size. +capacity of the zone file, or in other words, the maximum file size. Conventional zone files ----------------------- @@ -156,8 +156,8 @@ all accepted. Truncating sequential zone files is allowed only down to 0, in which case, the zone is reset to rewind the file zone write pointer position to the start of -the zone, or up to the zone size, in which case the file's zone is transitioned -to the FULL state (finish zone operation). +the zone, or up to the zone capacity, in which case the file's zone is +transitioned to the FULL state (finish zone operation). Format options -------------- @@ -324,7 +324,7 @@ file size set to 0. This is necessary as the write pointer of read-only zones is defined as invalib by the ZBC and ZAC standards, making it impossible to discover the amount of data that has been written to the zone. In the case of a read-only zone discovered at run-time, as indicated in the previous section. -the size of the zone file is left unchanged from its last updated value. +The size of the zone file is left unchanged from its last updated value. Zonefs User Space Tools ======================= @@ -401,8 +401,9 @@ append-writes to the file:: # ls -l /mnt/seq/0 -rw-r----- 1 root root 0 Nov 25 13:49 /mnt/seq/0 -Since files are statically mapped to zones on the disk, the number of blocks of -a file as reported by stat() and fstat() indicates the size of the file zone:: +Since files are statically mapped to zones on the disk, the number of blocks +of a file as reported by stat() and fstat() indicates the capacity of the file +zone:: # stat /mnt/seq/0 File: /mnt/seq/0 @@ -416,5 +417,6 @@ a file as reported by stat() and fstat() indicates the size of the file zone:: The number of blocks of the file ("Blocks") in units of 512B blocks gives the maximum file size of 524288 * 512 B = 256 MB, corresponding to the device zone -size in this example. Of note is that the "IO block" field always indicates the -minimum I/O size for writes and corresponds to the device physical sector size. +capacity in this example. Of note is that the "IO block" field always +indicates the minimum I/O size for writes and corresponds to the device +physical sector size. diff --git a/Documentation/gpu/backlight.rst b/Documentation/gpu/backlight.rst new file mode 100644 index 000000000000..9ebfc9d0aced --- /dev/null +++ b/Documentation/gpu/backlight.rst @@ -0,0 +1,12 @@ +================= +Backlight support +================= + +.. kernel-doc:: drivers/video/backlight/backlight.c + :doc: overview + +.. kernel-doc:: include/linux/backlight.h + :internal: + +.. kernel-doc:: drivers/video/backlight/backlight.c + :export: diff --git a/Documentation/gpu/index.rst b/Documentation/gpu/index.rst index 1fcf8e851e15..c9a51e3bfb5a 100644 --- a/Documentation/gpu/index.rst +++ b/Documentation/gpu/index.rst @@ -12,6 +12,7 @@ Linux GPU Driver Developer's Guide drm-uapi drm-client drivers + backlight vga-switcheroo vgaarbiter todo diff --git a/Documentation/staging/rpmsg.rst b/Documentation/staging/rpmsg.rst index 24b7a9e1a5f9..1ce353cb232a 100644 --- a/Documentation/staging/rpmsg.rst +++ b/Documentation/staging/rpmsg.rst @@ -192,9 +192,9 @@ Returns 0 on success and an appropriate error value on failure. :: - struct rpmsg_endpoint *rpmsg_create_ept(struct rpmsg_channel *rpdev, - void (*cb)(struct rpmsg_channel *, void *, int, void *, u32), - void *priv, u32 addr); + struct rpmsg_endpoint *rpmsg_create_ept(struct rpmsg_device *rpdev, + rpmsg_rx_cb_t cb, void *priv, + struct rpmsg_channel_info chinfo); every rpmsg address in the system is bound to an rx callback (so when inbound messages arrive, they are dispatched by the rpmsg bus using the diff --git a/Documentation/userspace-api/ioctl/ioctl-number.rst b/Documentation/userspace-api/ioctl/ioctl-number.rst index 59472cd6a11d..2a198838fca9 100644 --- a/Documentation/userspace-api/ioctl/ioctl-number.rst +++ b/Documentation/userspace-api/ioctl/ioctl-number.rst @@ -339,6 +339,7 @@ Code Seq# Include File Comments 0xB4 00-0F linux/gpio.h <mailto:linux-gpio@vger.kernel.org> 0xB5 00-0F uapi/linux/rpmsg.h <mailto:linux-remoteproc@vger.kernel.org> 0xB6 all linux/fpga-dfl.h +0xB7 all uapi/linux/remoteproc_cdev.h <mailto:linux-remoteproc@vger.kernel.org> 0xC0 00-0F linux/usb/iowarrior.h 0xCA 00-0F uapi/misc/cxl.h 0xCA 10-2F uapi/misc/ocxl.h |