diff options
author | Linus Torvalds <torvalds@linux-foundation.org> | 2020-10-15 20:01:51 +0300 |
---|---|---|
committer | Linus Torvalds <torvalds@linux-foundation.org> | 2020-10-15 20:01:51 +0300 |
commit | 726eb70e0d34dc4bc4dada71f52bba8ed638431e (patch) | |
tree | e49674616f4513c8c6a4746a08e93c9441708d34 /Documentation | |
parent | c6dbef7307629cce855aa6b482b60cbf7777ed88 (diff) | |
parent | f3277cbfba763cd2826396521b9296de67cf1bbc (diff) | |
download | linux-726eb70e0d34dc4bc4dada71f52bba8ed638431e.tar.xz |
Merge tag 'char-misc-5.10-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc
Pull char/misc driver updates from Greg KH:
"Here is the big set of char, misc, and other assorted driver subsystem
patches for 5.10-rc1.
There's a lot of different things in here, all over the drivers/
directory. Some summaries:
- soundwire driver updates
- habanalabs driver updates
- extcon driver updates
- nitro_enclaves new driver
- fsl-mc driver and core updates
- mhi core and bus updates
- nvmem driver updates
- eeprom driver updates
- binder driver updates and fixes
- vbox minor bugfixes
- fsi driver updates
- w1 driver updates
- coresight driver updates
- interconnect driver updates
- misc driver updates
- other minor driver updates
All of these have been in linux-next for a while with no reported
issues"
* tag 'char-misc-5.10-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc: (396 commits)
binder: fix UAF when releasing todo list
docs: w1: w1_therm: Fix broken xref, mistakes, clarify text
misc: Kconfig: fix a HISI_HIKEY_USB dependency
LSM: Fix type of id parameter in kernel_post_load_data prototype
misc: Kconfig: add a new dependency for HISI_HIKEY_USB
firmware_loader: fix a kernel-doc markup
w1: w1_therm: make w1_poll_completion static
binder: simplify the return expression of binder_mmap
test_firmware: Test partial read support
firmware: Add request_partial_firmware_into_buf()
firmware: Store opt_flags in fw_priv
fs/kernel_file_read: Add "offset" arg for partial reads
IMA: Add support for file reads without contents
LSM: Add "contents" flag to kernel_read_file hook
module: Call security_kernel_post_load_data()
firmware_loader: Use security_post_load_data()
LSM: Introduce kernel_post_load_data() hook
fs/kernel_read_file: Add file_size output argument
fs/kernel_read_file: Switch buffer size arg to size_t
fs/kernel_read_file: Remove redundant size argument
...
Diffstat (limited to 'Documentation')
21 files changed, 496 insertions, 154 deletions
diff --git a/Documentation/ABI/stable/sysfs-bus-mhi b/Documentation/ABI/stable/sysfs-bus-mhi new file mode 100644 index 000000000000..ecfe7662f8d0 --- /dev/null +++ b/Documentation/ABI/stable/sysfs-bus-mhi @@ -0,0 +1,21 @@ +What: /sys/bus/mhi/devices/.../serialnumber +Date: Sept 2020 +KernelVersion: 5.10 +Contact: Bhaumik Bhatt <bbhatt@codeaurora.org> +Description: The file holds the serial number of the client device obtained + using a BHI (Boot Host Interface) register read after at least + one attempt to power up the device has been done. If read + without having the device power on at least once, the file will + read all 0's. +Users: Any userspace application or clients interested in device info. + +What: /sys/bus/mhi/devices/.../oem_pk_hash +Date: Sept 2020 +KernelVersion: 5.10 +Contact: Bhaumik Bhatt <bbhatt@codeaurora.org> +Description: The file holds the OEM PK Hash value of the endpoint device + obtained using a BHI (Boot Host Interface) register read after + at least one attempt to power up the device has been done. If + read without having the device power on at least once, the file + will read all 0's. +Users: Any userspace application or clients interested in device info. diff --git a/Documentation/ABI/testing/sysfs-bus-dfl b/Documentation/ABI/testing/sysfs-bus-dfl new file mode 100644 index 000000000000..23543be904f2 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-bus-dfl @@ -0,0 +1,15 @@ +What: /sys/bus/dfl/devices/dfl_dev.X/type +Date: Aug 2020 +KernelVersion: 5.10 +Contact: Xu Yilun <yilun.xu@intel.com> +Description: Read-only. It returns type of DFL FIU of the device. Now DFL + supports 2 FIU types, 0 for FME, 1 for PORT. + Format: 0x%x + +What: /sys/bus/dfl/devices/dfl_dev.X/feature_id +Date: Aug 2020 +KernelVersion: 5.10 +Contact: Xu Yilun <yilun.xu@intel.com> +Description: Read-only. It returns feature identifier local to its DFL FIU + type. + Format: 0x%x diff --git a/Documentation/ABI/testing/sysfs-bus-fsi b/Documentation/ABI/testing/sysfs-bus-fsi index 320697bdf41d..d148214181a1 100644 --- a/Documentation/ABI/testing/sysfs-bus-fsi +++ b/Documentation/ABI/testing/sysfs-bus-fsi @@ -36,3 +36,11 @@ Contact: linux-fsi@lists.ozlabs.org Description: Provides a means of reading/writing a 32 bit value from/to a specified FSI bus address. + +What: /sys/bus/platform/devices/../cfam_reset +Date: Sept 2020 +KernelVersion: 5.10 +Contact: linux-fsi@lists.ozlabs.org +Description: + Provides a means of resetting the cfam that is attached to the + FSI device. diff --git a/Documentation/ABI/testing/sysfs-bus-mei b/Documentation/ABI/testing/sysfs-bus-mei index 3d37e2796d5a..6e9a105fe5cb 100644 --- a/Documentation/ABI/testing/sysfs-bus-mei +++ b/Documentation/ABI/testing/sysfs-bus-mei @@ -41,6 +41,13 @@ Contact: Tomas Winkler <tomas.winkler@intel.com> Description: Stores mei client fixed address, if any Format: %d +What: /sys/bus/mei/devices/.../vtag +Date: Nov 2020 +KernelVersion: 5.9 +Contact: Tomas Winkler <tomas.winkler@intel.com> +Description: Stores mei client vtag support status + Format: %d + What: /sys/bus/mei/devices/.../max_len Date: Nov 2019 KernelVersion: 5.5 diff --git a/Documentation/ABI/testing/sysfs-bus-soundwire-slave b/Documentation/ABI/testing/sysfs-bus-soundwire-slave index db4c9511d1aa..d324aa0b678f 100644 --- a/Documentation/ABI/testing/sysfs-bus-soundwire-slave +++ b/Documentation/ABI/testing/sysfs-bus-soundwire-slave @@ -1,3 +1,21 @@ +What: /sys/bus/soundwire/devices/sdw:.../status + /sys/bus/soundwire/devices/sdw:.../device_number + +Date: September 2020 + +Contact: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> + Bard Liao <yung-chuan.liao@linux.intel.com> + Vinod Koul <vkoul@kernel.org> + +Description: SoundWire Slave status + + These properties report the Slave status, e.g. if it + is UNATTACHED or not, and in the latter case show the + device_number. This status information is useful to + detect devices exposed by platform firmware but not + physically present on the bus, and conversely devices + not exposed in platform firmware but enumerated. + What: /sys/bus/soundwire/devices/sdw:.../dev-properties/mipi_revision /sys/bus/soundwire/devices/sdw:.../dev-properties/wake_capable /sys/bus/soundwire/devices/sdw:.../dev-properties/test_mode_capable diff --git a/Documentation/ABI/testing/sysfs-driver-habanalabs b/Documentation/ABI/testing/sysfs-driver-habanalabs index 1a14bf9b22ba..169ae4b2a180 100644 --- a/Documentation/ABI/testing/sysfs-driver-habanalabs +++ b/Documentation/ABI/testing/sysfs-driver-habanalabs @@ -2,13 +2,17 @@ What: /sys/class/habanalabs/hl<n>/armcp_kernel_ver Date: Jan 2019 KernelVersion: 5.1 Contact: oded.gabbay@gmail.com -Description: Version of the Linux kernel running on the device's CPU +Description: Version of the Linux kernel running on the device's CPU. + Will be DEPRECATED in Linux kernel version 5.10, and be + replaced with cpucp_kernel_ver What: /sys/class/habanalabs/hl<n>/armcp_ver Date: Jan 2019 KernelVersion: 5.1 Contact: oded.gabbay@gmail.com Description: Version of the application running on the device's CPU + Will be DEPRECATED in Linux kernel version 5.10, and be + replaced with cpucp_ver What: /sys/class/habanalabs/hl<n>/clk_max_freq_mhz Date: Jun 2019 @@ -33,6 +37,18 @@ KernelVersion: 5.1 Contact: oded.gabbay@gmail.com Description: Version of the Device's CPLD F/W +What: /sys/class/habanalabs/hl<n>/cpucp_kernel_ver +Date: Oct 2020 +KernelVersion: 5.10 +Contact: oded.gabbay@gmail.com +Description: Version of the Linux kernel running on the device's CPU + +What: /sys/class/habanalabs/hl<n>/cpucp_ver +Date: Oct 2020 +KernelVersion: 5.10 +Contact: oded.gabbay@gmail.com +Description: Version of the application running on the device's CPU + What: /sys/class/habanalabs/hl<n>/device_type Date: Jan 2019 KernelVersion: 5.1 diff --git a/Documentation/ABI/testing/sysfs-driver-w1_therm b/Documentation/ABI/testing/sysfs-driver-w1_therm index 9b488c0afdfa..8873bbb075cb 100644 --- a/Documentation/ABI/testing/sysfs-driver-w1_therm +++ b/Documentation/ABI/testing/sysfs-driver-w1_therm @@ -49,10 +49,13 @@ Description: will be changed only in device RAM, so it will be cleared when power is lost. Trigger a 'save' to EEPROM command to keep values after power-on. Read or write are : - * '9..12': device resolution in bit + * '9..14': device resolution in bit or resolution to set in bit * '-xx': xx is kernel error when reading the resolution * Anything else: do nothing + Some DS18B20 clones are fixed in 12-bit resolution, so the + actual resolution is read back from the chip and verified. Error + is reported if the results differ. Users: any user space application which wants to communicate with w1_term device @@ -86,7 +89,7 @@ Description: *write* : * '0' : save the 2 or 3 bytes to the device EEPROM (i.e. TH, TL and config register) - * '9..12' : set the device resolution in RAM + * '9..14' : set the device resolution in RAM (if supported) * Anything else: do nothing refer to Documentation/w1/slaves/w1_therm.rst for detailed @@ -114,3 +117,47 @@ Description: of the bulk read command (not the current temperature). Users: any user space application which wants to communicate with w1_term device + + +What: /sys/bus/w1/devices/.../conv_time +Date: July 2020 +Contact: Ivan Zaentsev <ivan.zaentsev@wirenboard.ru> +Description: + (RW) Get, set, or measure a temperature conversion time. The + setting remains active until a resolution change. Then it is + reset to default (datasheet) conversion time for a new + resolution. + + *read*: Actual conversion time in milliseconds. *write*: + '0': Set the default conversion time from the datasheet. + '1': Measure and set the conversion time. Make a single + temperature conversion, measure an actual value. + Increase it by 20% for temperature range. A new + conversion time can be obtained by reading this + same attribute. + other positive value: + Set the conversion time in milliseconds. + +Users: An application using the w1_term device + + +What: /sys/bus/w1/devices/.../features +Date: July 2020 +Contact: Ivan Zaentsev <ivan.zaentsev@wirenboard.ru> +Description: + (RW) Control optional driver settings. + Bit masks to read/write (bitwise OR): + + 1: Enable check for conversion success. If byte 6 of + scratchpad memory is 0xC after conversion, and + temperature reads 85.00 (powerup value) or 127.94 + (insufficient power) - return a conversion error. + + 2: Enable poll for conversion completion. Generate read cycles + after the conversion start and wait for 1's. In parasite + power mode this feature is not available. + + *read*: Currently selected features. + *write*: Select features. + +Users: An application using the w1_term device diff --git a/Documentation/devicetree/bindings/extcon/extcon-ptn5150.txt b/Documentation/devicetree/bindings/extcon/extcon-ptn5150.txt deleted file mode 100644 index 936fbdf12815..000000000000 --- a/Documentation/devicetree/bindings/extcon/extcon-ptn5150.txt +++ /dev/null @@ -1,27 +0,0 @@ -* PTN5150 CC (Configuration Channel) Logic device - -PTN5150 is a small thin low power CC logic chip supporting the USB Type-C -connector application with CC control logic detection and indication functions. -It is interfaced to the host controller using an I2C interface. - -Required properties: -- compatible: should be "nxp,ptn5150" -- reg: specifies the I2C slave address of the device -- int-gpio: should contain a phandle and GPIO specifier for the GPIO pin - connected to the PTN5150's INTB pin. -- vbus-gpio: should contain a phandle and GPIO specifier for the GPIO pin which - is used to control VBUS. -- pinctrl-names : a pinctrl state named "default" must be defined. -- pinctrl-0 : phandle referencing pin configuration of interrupt and vbus - control. - -Example: - ptn5150@1d { - compatible = "nxp,ptn5150"; - reg = <0x1d>; - int-gpio = <&msmgpio 78 GPIO_ACTIVE_HIGH>; - vbus-gpio = <&msmgpio 148 GPIO_ACTIVE_HIGH>; - pinctrl-names = "default"; - pinctrl-0 = <&ptn5150_default>; - status = "okay"; - }; diff --git a/Documentation/devicetree/bindings/extcon/extcon-ptn5150.yaml b/Documentation/devicetree/bindings/extcon/extcon-ptn5150.yaml new file mode 100644 index 000000000000..4b0f414486d2 --- /dev/null +++ b/Documentation/devicetree/bindings/extcon/extcon-ptn5150.yaml @@ -0,0 +1,60 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/extcon/extcon-ptn5150.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: PTN5150 CC (Configuration Channel) Logic device + +maintainers: + - Krzysztof Kozlowski <krzk@kernel.org> + +description: | + PTN5150 is a small thin low power CC logic chip supporting the USB Type-C + connector application with CC control logic detection and indication + functions. It is interfaced to the host controller using an I2C interface. + +properties: + compatible: + const: nxp,ptn5150 + + int-gpios: + deprecated: true + description: + GPIO pin (input) connected to the PTN5150's INTB pin. + Use "interrupts" instead. + + interrupts: + maxItems: 1 + + reg: + maxItems: 1 + + vbus-gpios: + description: + GPIO pin (output) used to control VBUS. If skipped, no such control + takes place. + +required: + - compatible + - interrupts + - reg + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + #include <dt-bindings/interrupt-controller/irq.h> + i2c { + #address-cells = <1>; + #size-cells = <0>; + + ptn5150@1d { + compatible = "nxp,ptn5150"; + reg = <0x1d>; + interrupt-parent = <&msmgpio>; + interrupts = <78 IRQ_TYPE_LEVEL_HIGH>; + vbus-gpios = <&msmgpio 148 GPIO_ACTIVE_HIGH>; + }; + }; diff --git a/Documentation/devicetree/bindings/fsi/fsi-master-aspeed.txt b/Documentation/devicetree/bindings/fsi/fsi-master-aspeed.txt index b758f91914f7..9853fefff5d8 100644 --- a/Documentation/devicetree/bindings/fsi/fsi-master-aspeed.txt +++ b/Documentation/devicetree/bindings/fsi/fsi-master-aspeed.txt @@ -12,6 +12,13 @@ Required properties: - pinctrl-0: phandle to pinctrl node - pinctrl-names: pinctrl state +Optional properties: + - cfam-reset-gpios: GPIO for CFAM reset + + - fsi-routing-gpios: GPIO for setting the FSI mux (internal or cabled) + - fsi-mux-gpios: GPIO for detecting the desired FSI mux state + + Examples: fsi-master { @@ -21,4 +28,9 @@ Examples: pinctrl-names = "default"; pinctrl-0 = <&pinctrl_fsi1_default>; clocks = <&syscon ASPEED_CLK_GATE_FSICLK>; + + fsi-routing-gpios = <&gpio0 ASPEED_GPIO(Q, 7) GPIO_ACTIVE_HIGH>; + fsi-mux-gpios = <&gpio0 ASPEED_GPIO(B, 0) GPIO_ACTIVE_HIGH>; + + cfam-reset-gpios = <&gpio0 ASPEED_GPIO(Q, 0) GPIO_ACTIVE_LOW>; }; diff --git a/Documentation/devicetree/bindings/interconnect/interconnect.txt b/Documentation/devicetree/bindings/interconnect/interconnect.txt index 6f5d23a605b7..138c544c8c8c 100644 --- a/Documentation/devicetree/bindings/interconnect/interconnect.txt +++ b/Documentation/devicetree/bindings/interconnect/interconnect.txt @@ -19,7 +19,8 @@ directly. Required properties: - compatible : contains the interconnect provider compatible string - #interconnect-cells : number of cells in a interconnect specifier needed to - encode the interconnect node id + encode the interconnect node id and optionally add a + path tag Example: @@ -44,6 +45,10 @@ components it has to interact with. Required properties: interconnects : Pairs of phandles and interconnect provider specifier to denote the edge source and destination ports of the interconnect path. + An optional path tag value could specified as additional argument + to both endpoints and in such cases, this information will be passed + to the interconnect framework to do aggregation based on the attached + tag. Optional properties: interconnect-names : List of interconnect path name strings sorted in the same @@ -62,3 +67,20 @@ Example: interconnects = <&pnoc MASTER_SDCC_1 &bimc SLAVE_EBI_CH0>; interconnect-names = "sdhc-mem"; }; + +Example with path tags: + + gnoc: interconnect@17900000 { + ... + interconnect-cells = <2>; + }; + + mnoc: interconnect@1380000 { + ... + interconnect-cells = <2>; + }; + + cpu@0 { + ... + interconnects = <&gnoc MASTER_APPSS_PROC 3 &mnoc SLAVE_EBI1 3>; + } diff --git a/Documentation/devicetree/bindings/interconnect/qcom,bcm-voter.yaml b/Documentation/devicetree/bindings/interconnect/qcom,bcm-voter.yaml index 5971fc1df08d..e23df4836c6f 100644 --- a/Documentation/devicetree/bindings/interconnect/qcom,bcm-voter.yaml +++ b/Documentation/devicetree/bindings/interconnect/qcom,bcm-voter.yaml @@ -21,6 +21,23 @@ properties: enum: - qcom,bcm-voter + qcom,tcs-wait: + description: | + Optional mask of which TCSs (Triggered Command Sets) wait for completion + upon triggering. If not specified, then the AMC and WAKE sets wait for + completion. The mask bits are available in the QCOM_ICC_TAG_* defines. + + The AMC TCS is triggered immediately when icc_set_bw() is called. The + WAKE/SLEEP TCSs are triggered when the RSC transitions between active and + sleep modes. + + In most cases, it's necessary to wait in both the AMC and WAKE sets to + ensure resources are available before use. If a specific RSC and its use + cases can ensure sufficient delay by other means, then this can be + overridden to reduce latencies. + + $ref: /schemas/types.yaml#/definitions/uint32 + required: - compatible @@ -39,7 +56,10 @@ examples: # as defined in Documentation/devicetree/bindings/soc/qcom/rpmh-rsc.txt - | + #include <dt-bindings/interconnect/qcom,icc.h> + disp_bcm_voter: bcm_voter { compatible = "qcom,bcm-voter"; + qcom,tcs-wait = <QCOM_ICC_TAG_AMC>; }; ... diff --git a/Documentation/devicetree/bindings/interconnect/qcom,osm-l3.yaml b/Documentation/devicetree/bindings/interconnect/qcom,osm-l3.yaml index 91f70c9067d1..d6a95c3cb26f 100644 --- a/Documentation/devicetree/bindings/interconnect/qcom,osm-l3.yaml +++ b/Documentation/devicetree/bindings/interconnect/qcom,osm-l3.yaml @@ -19,6 +19,8 @@ properties: enum: - qcom,sc7180-osm-l3 - qcom,sdm845-osm-l3 + - qcom,sm8150-osm-l3 + - qcom,sm8250-epss-l3 reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/interconnect/qcom,sdm845.yaml b/Documentation/devicetree/bindings/interconnect/qcom,rpmh.yaml index dab17c0716ce..30c2a092d2d3 100644 --- a/Documentation/devicetree/bindings/interconnect/qcom,sdm845.yaml +++ b/Documentation/devicetree/bindings/interconnect/qcom,rpmh.yaml @@ -1,16 +1,17 @@ # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) %YAML 1.2 --- -$id: http://devicetree.org/schemas/interconnect/qcom,sdm845.yaml# +$id: http://devicetree.org/schemas/interconnect/qcom,rpmh.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# -title: Qualcomm SDM845 Network-On-Chip Interconnect +title: Qualcomm RPMh Network-On-Chip Interconnect maintainers: - Georgi Djakov <georgi.djakov@linaro.org> + - Odelu Kukatla <okukatla@codeaurora.org> description: | - SDM845 interconnect providers support system bandwidth requirements through + RPMh interconnect providers support system bandwidth requirements through RPMh hardware accelerators known as Bus Clock Manager (BCM). The provider is able to communicate with the BCM through the Resource State Coordinator (RSC) associated with each execution environment. Provider nodes must point to at @@ -23,6 +24,19 @@ properties: compatible: enum: + - qcom,sc7180-aggre1-noc + - qcom,sc7180-aggre2-noc + - qcom,sc7180-camnoc-virt + - qcom,sc7180-compute-noc + - qcom,sc7180-config-noc + - qcom,sc7180-dc-noc + - qcom,sc7180-gem-noc + - qcom,sc7180-ipa-virt + - qcom,sc7180-mc-virt + - qcom,sc7180-mmss-noc + - qcom,sc7180-npu-noc + - qcom,sc7180-qup-virt + - qcom,sc7180-system-noc - qcom,sdm845-aggre1-noc - qcom,sdm845-aggre2-noc - qcom,sdm845-config-noc @@ -31,6 +45,28 @@ properties: - qcom,sdm845-mem-noc - qcom,sdm845-mmss-noc - qcom,sdm845-system-noc + - qcom,sm8150-aggre1-noc + - qcom,sm8150-aggre2-noc + - qcom,sm8150-camnoc-noc + - qcom,sm8150-compute-noc + - qcom,sm8150-config-noc + - qcom,sm8150-dc-noc + - qcom,sm8150-gem-noc + - qcom,sm8150-ipa-virt + - qcom,sm8150-mc-virt + - qcom,sm8150-mmss-noc + - qcom,sm8150-system-noc + - qcom,sm8250-aggre1-noc + - qcom,sm8250-aggre2-noc + - qcom,sm8250-compute-noc + - qcom,sm8250-config-noc + - qcom,sm8250-dc-noc + - qcom,sm8250-gem-noc + - qcom,sm8250-ipa-virt + - qcom,sm8250-mc-virt + - qcom,sm8250-mmss-noc + - qcom,sm8250-npu-noc + - qcom,sm8250-system-noc '#interconnect-cells': const: 1 diff --git a/Documentation/devicetree/bindings/interconnect/qcom,sc7180.yaml b/Documentation/devicetree/bindings/interconnect/qcom,sc7180.yaml deleted file mode 100644 index 8659048f92a7..000000000000 --- a/Documentation/devicetree/bindings/interconnect/qcom,sc7180.yaml +++ /dev/null @@ -1,85 +0,0 @@ -# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) -%YAML 1.2 ---- -$id: http://devicetree.org/schemas/interconnect/qcom,sc7180.yaml# -$schema: http://devicetree.org/meta-schemas/core.yaml# - -title: Qualcomm SC7180 Network-On-Chip Interconnect - -maintainers: - - Odelu Kukatla <okukatla@codeaurora.org> - -description: | - SC7180 interconnect providers support system bandwidth requirements through - RPMh hardware accelerators known as Bus Clock Manager (BCM). The provider is - able to communicate with the BCM through the Resource State Coordinator (RSC) - associated with each execution environment. Provider nodes must point to at - least one RPMh device child node pertaining to their RSC and each provider - can map to multiple RPMh resources. - -properties: - reg: - maxItems: 1 - - compatible: - enum: - - qcom,sc7180-aggre1-noc - - qcom,sc7180-aggre2-noc - - qcom,sc7180-camnoc-virt - - qcom,sc7180-compute-noc - - qcom,sc7180-config-noc - - qcom,sc7180-dc-noc - - qcom,sc7180-gem-noc - - qcom,sc7180-ipa-virt - - qcom,sc7180-mc-virt - - qcom,sc7180-mmss-noc - - qcom,sc7180-npu-noc - - qcom,sc7180-qup-virt - - qcom,sc7180-system-noc - - '#interconnect-cells': - const: 1 - - qcom,bcm-voters: - $ref: /schemas/types.yaml#/definitions/phandle-array - description: | - List of phandles to qcom,bcm-voter nodes that are required by - this interconnect to send RPMh commands. - - qcom,bcm-voter-names: - $ref: /schemas/types.yaml#/definitions/string-array - description: | - Names for each of the qcom,bcm-voters specified. - -required: - - compatible - - reg - - '#interconnect-cells' - - qcom,bcm-voters - -additionalProperties: false - -examples: - - | - #include <dt-bindings/interconnect/qcom,sc7180.h> - - config_noc: interconnect@1500000 { - compatible = "qcom,sc7180-config-noc"; - reg = <0x01500000 0x28000>; - #interconnect-cells = <1>; - qcom,bcm-voters = <&apps_bcm_voter>; - }; - - system_noc: interconnect@1620000 { - compatible = "qcom,sc7180-system-noc"; - reg = <0x01620000 0x17080>; - #interconnect-cells = <1>; - qcom,bcm-voters = <&apps_bcm_voter>; - }; - - mmss_noc: interconnect@1740000 { - compatible = "qcom,sc7180-mmss-noc"; - reg = <0x01740000 0x1c100>; - #interconnect-cells = <1>; - qcom,bcm-voters = <&apps_bcm_voter>; - }; diff --git a/Documentation/devicetree/bindings/soundwire/qcom,sdw.txt b/Documentation/devicetree/bindings/soundwire/qcom,sdw.txt index 436547f3b155..b104be131235 100644 --- a/Documentation/devicetree/bindings/soundwire/qcom,sdw.txt +++ b/Documentation/devicetree/bindings/soundwire/qcom,sdw.txt @@ -11,6 +11,7 @@ board specific bus parameters. Example: "qcom,soundwire-v1.3.0" "qcom,soundwire-v1.5.0" + "qcom,soundwire-v1.5.1" "qcom,soundwire-v1.6.0" - reg: Usage: required diff --git a/Documentation/driver-api/mei/mei.rst b/Documentation/driver-api/mei/mei.rst index c800d8e5f422..cea0b69ec216 100644 --- a/Documentation/driver-api/mei/mei.rst +++ b/Documentation/driver-api/mei/mei.rst @@ -42,6 +42,11 @@ The session is terminated calling :c:func:`close(int fd)`. A code snippet for an application communicating with Intel AMTHI client: +In order to support virtualization or sandboxing a trusted supervisor +can use :c:macro:`MEI_CONNECT_CLIENT_IOCTL_VTAG` to create +virtual channels with an Intel ME feature. Not all features support +virtual channels such client with answer EOPNOTSUPP. + .. code-block:: C struct mei_connect_client_data data; @@ -110,6 +115,38 @@ Connect to firmware Feature/Client. data that can be sent or received. (e.g. if MTU=2K, can send requests up to bytes 2k and received responses up to 2k bytes). +IOCTL_MEI_CONNECT_CLIENT_VTAG: +------------------------------ + +.. code-block:: none + + Usage: + + struct mei_connect_client_data_vtag client_data_vtag; + + ioctl(fd, IOCTL_MEI_CONNECT_CLIENT_VTAG, &client_data_vtag); + + Inputs: + + struct mei_connect_client_data_vtag - contain the following + Input field: + + in_client_uuid - GUID of the FW Feature that needs + to connect to. + vtag - virtual tag [1, 255] + + Outputs: + out_client_properties - Client Properties: MTU and Protocol Version. + + Error returns: + + ENOTTY No such client (i.e. wrong GUID) or connection is not allowed. + EINVAL Wrong IOCTL Number or tag == 0 + ENODEV Device or Connection is not initialized or ready. + ENOMEM Unable to allocate memory to client internal data. + EFAULT Fatal Error (e.g. Unable to access user input data) + EBUSY Connection Already Open + EOPNOTSUPP Vtag is not supported IOCTL_MEI_NOTIFY_SET --------------------- diff --git a/Documentation/userspace-api/ioctl/ioctl-number.rst b/Documentation/userspace-api/ioctl/ioctl-number.rst index 2a198838fca9..5f7ff00f394e 100644 --- a/Documentation/userspace-api/ioctl/ioctl-number.rst +++ b/Documentation/userspace-api/ioctl/ioctl-number.rst @@ -328,8 +328,11 @@ Code Seq# Include File Comments 0xAC 00-1F linux/raw.h 0xAD 00 Netfilter device in development: <mailto:rusty@rustcorp.com.au> -0xAE all linux/kvm.h Kernel-based Virtual Machine +0xAE 00-1F linux/kvm.h Kernel-based Virtual Machine <mailto:kvm@vger.kernel.org> +0xAE 40-FF linux/kvm.h Kernel-based Virtual Machine + <mailto:kvm@vger.kernel.org> +0xAE 20-3F linux/nitro_enclaves.h Nitro Enclaves 0xAF 00-1F linux/fsl_hypervisor.h Freescale hypervisor 0xB0 all RATIO devices in development: <mailto:vgo@ratio.de> diff --git a/Documentation/virt/index.rst b/Documentation/virt/index.rst index d20490292642..350f5c869b56 100644 --- a/Documentation/virt/index.rst +++ b/Documentation/virt/index.rst @@ -11,6 +11,7 @@ Linux Virtualization Support uml/user_mode_linux_howto_v2 paravirt_ops guest-halt-polling + ne_overview .. only:: html and subproject diff --git a/Documentation/virt/ne_overview.rst b/Documentation/virt/ne_overview.rst new file mode 100644 index 000000000000..39b0c8fe2654 --- /dev/null +++ b/Documentation/virt/ne_overview.rst @@ -0,0 +1,95 @@ +.. SPDX-License-Identifier: GPL-2.0 + +============== +Nitro Enclaves +============== + +Overview +======== + +Nitro Enclaves (NE) is a new Amazon Elastic Compute Cloud (EC2) capability +that allows customers to carve out isolated compute environments within EC2 +instances [1]. + +For example, an application that processes sensitive data and runs in a VM, +can be separated from other applications running in the same VM. This +application then runs in a separate VM than the primary VM, namely an enclave. + +An enclave runs alongside the VM that spawned it. This setup matches low latency +applications needs. The resources that are allocated for the enclave, such as +memory and CPUs, are carved out of the primary VM. Each enclave is mapped to a +process running in the primary VM, that communicates with the NE driver via an +ioctl interface. + +In this sense, there are two components: + +1. An enclave abstraction process - a user space process running in the primary +VM guest that uses the provided ioctl interface of the NE driver to spawn an +enclave VM (that's 2 below). + +There is a NE emulated PCI device exposed to the primary VM. The driver for this +new PCI device is included in the NE driver. + +The ioctl logic is mapped to PCI device commands e.g. the NE_START_ENCLAVE ioctl +maps to an enclave start PCI command. The PCI device commands are then +translated into actions taken on the hypervisor side; that's the Nitro +hypervisor running on the host where the primary VM is running. The Nitro +hypervisor is based on core KVM technology. + +2. The enclave itself - a VM running on the same host as the primary VM that +spawned it. Memory and CPUs are carved out of the primary VM and are dedicated +for the enclave VM. An enclave does not have persistent storage attached. + +The memory regions carved out of the primary VM and given to an enclave need to +be aligned 2 MiB / 1 GiB physically contiguous memory regions (or multiple of +this size e.g. 8 MiB). The memory can be allocated e.g. by using hugetlbfs from +user space [2][3]. The memory size for an enclave needs to be at least 64 MiB. +The enclave memory and CPUs need to be from the same NUMA node. + +An enclave runs on dedicated cores. CPU 0 and its CPU siblings need to remain +available for the primary VM. A CPU pool has to be set for NE purposes by an +user with admin capability. See the cpu list section from the kernel +documentation [4] for how a CPU pool format looks. + +An enclave communicates with the primary VM via a local communication channel, +using virtio-vsock [5]. The primary VM has virtio-pci vsock emulated device, +while the enclave VM has a virtio-mmio vsock emulated device. The vsock device +uses eventfd for signaling. The enclave VM sees the usual interfaces - local +APIC and IOAPIC - to get interrupts from virtio-vsock device. The virtio-mmio +device is placed in memory below the typical 4 GiB. + +The application that runs in the enclave needs to be packaged in an enclave +image together with the OS ( e.g. kernel, ramdisk, init ) that will run in the +enclave VM. The enclave VM has its own kernel and follows the standard Linux +boot protocol [6]. + +The kernel bzImage, the kernel command line, the ramdisk(s) are part of the +Enclave Image Format (EIF); plus an EIF header including metadata such as magic +number, eif version, image size and CRC. + +Hash values are computed for the entire enclave image (EIF), the kernel and +ramdisk(s). That's used, for example, to check that the enclave image that is +loaded in the enclave VM is the one that was intended to be run. + +These crypto measurements are included in a signed attestation document +generated by the Nitro Hypervisor and further used to prove the identity of the +enclave; KMS is an example of service that NE is integrated with and that checks +the attestation doc. + +The enclave image (EIF) is loaded in the enclave memory at offset 8 MiB. The +init process in the enclave connects to the vsock CID of the primary VM and a +predefined port - 9000 - to send a heartbeat value - 0xb7. This mechanism is +used to check in the primary VM that the enclave has booted. The CID of the +primary VM is 3. + +If the enclave VM crashes or gracefully exits, an interrupt event is received by +the NE driver. This event is sent further to the user space enclave process +running in the primary VM via a poll notification mechanism. Then the user space +enclave process can exit. + +[1] https://aws.amazon.com/ec2/nitro/nitro-enclaves/ +[2] https://www.kernel.org/doc/html/latest/admin-guide/mm/hugetlbpage.html +[3] https://lwn.net/Articles/807108/ +[4] https://www.kernel.org/doc/html/latest/admin-guide/kernel-parameters.html +[5] https://man7.org/linux/man-pages/man7/vsock.7.html +[6] https://www.kernel.org/doc/html/latest/x86/boot.html diff --git a/Documentation/w1/slaves/w1_therm.rst b/Documentation/w1/slaves/w1_therm.rst index cc4edae17751..e39202e2b000 100644 --- a/Documentation/w1/slaves/w1_therm.rst +++ b/Documentation/w1/slaves/w1_therm.rst @@ -6,6 +6,7 @@ Supported chips: * Maxim ds18*20 based temperature sensors. * Maxim ds1825 based temperature sensors. + * GXCAS GC20MH01 temperature sensor. Author: Evgeniy Polyakov <johnpol@2ka.mipt.ru> @@ -13,8 +14,8 @@ Author: Evgeniy Polyakov <johnpol@2ka.mipt.ru> Description ----------- -w1_therm provides basic temperature conversion for ds18*20 devices, and the -ds28ea00 device. +w1_therm provides basic temperature conversion for ds18*20, ds28ea00, GX20MH01 +devices. Supported family codes: @@ -26,59 +27,72 @@ W1_THERM_DS1825 0x3B W1_THERM_DS28EA00 0x42 ==================== ==== -Support is provided through the sysfs w1_slave file. Each open and -read sequence will initiate a temperature conversion then provide two +Support is provided through the sysfs entry ``w1_slave``. Each open and +read sequence will initiate a temperature conversion, then provide two lines of ASCII output. The first line contains the nine hex bytes read along with a calculated crc value and YES or NO if it matched. If the crc matched the returned values are retained. The second line displays the retained values along with a temperature in millidegrees Centigrade after t=. -Alternatively, temperature can be read using temperature sysfs, it -return only temperature in millidegrees Centigrade. +Alternatively, temperature can be read using ``temperature`` sysfs, it +returns only the temperature in millidegrees Centigrade. -A bulk read of all devices on the bus could be done writing 'trigger' -in the therm_bulk_read sysfs entry at w1_bus_master level. This will -sent the convert command on all devices on the bus, and if parasite -powered devices are detected on the bus (and strong pullup is enable +A bulk read of all devices on the bus could be done writing ``trigger`` +to ``therm_bulk_read`` entry at w1_bus_master level. This will +send the convert command to all devices on the bus, and if parasite +powered devices are detected on the bus (and strong pullup is enabled in the module), it will drive the line high during the longer conversion time required by parasited powered device on the line. Reading -therm_bulk_read will return 0 if no bulk conversion pending, +``therm_bulk_read`` will return 0 if no bulk conversion pending, -1 if at least one sensor still in conversion, 1 if conversion is complete but at least one sensor value has not been read yet. Result temperature is -then accessed by reading the temperature sysfs entry of each device, which +then accessed by reading the ``temperature`` entry of each device, which may return empty if conversion is still in progress. Note that if a bulk read is sent but one sensor is not read immediately, the next access to -temperature on this device will return the temperature measured at the +``temperature`` on this device will return the temperature measured at the time of issue of the bulk read command (not the current temperature). -Writing a value between 9 and 12 to the sysfs w1_slave file will change the -precision of the sensor for the next readings. This value is in (volatile) -SRAM, so it is reset when the sensor gets power-cycled. +A strong pullup will be applied during the conversion if required. -To store the current precision configuration into EEPROM, the value 0 -has to be written to the sysfs w1_slave file. Since the EEPROM has a limited -amount of writes (>50k), this command should be used wisely. +``conv_time`` is used to get current conversion time (read), and +adjust it (write). A temperature conversion time depends on the device type and +it's current resolution. Default conversion time is set by the driver according +to the device datasheet. A conversion time for many original device clones +deviate from datasheet specs. There are three options: 1) manually set the +correct conversion time by writing a value in milliseconds to ``conv_time``; 2) +auto measure and set a conversion time by writing ``1`` to +``conv_time``; 3) use ``features`` to enable poll for conversion +completion. Options 2, 3 can't be used in parasite power mode. To get back to +the default conversion time write ``0`` to ``conv_time``. -Alternatively, resolution can be set or read (value from 9 to 12) using the -dedicated resolution sysfs entry on each device. This sysfs entry is not -present for devices not supporting this feature. Driver will adjust the -correct conversion time for each device regarding to its resolution setting. -In particular, strong pullup will be applied if required during the conversion -duration. +Writing a resolution value (in bits) to ``w1_slave`` will change the +precision of the sensor for the next readings. Allowed resolutions are defined by +the sensor. Resolution is reset when the sensor gets power-cycled. -The write-only sysfs entry eeprom is an alternative for EEPROM operations: - * 'save': will save device RAM to EEPROM - * 'restore': will restore EEPROM data in device RAM. +To store the current resolution in EEPROM, write ``0`` to ``w1_slave``. +Since the EEPROM has a limited amount of writes (>50k), this command should be +used wisely. -ext_power syfs entry allow tho check the power status of each device. - * '0': device parasite powered - * '1': device externally powered +Alternatively, resolution can be read or written using the dedicated +``resolution`` entry on each device, if supported by the sensor. -sysfs alarms allow read or write TH and TL (Temperature High an Low) alarms. +Some non-genuine DS18B20 chips are fixed in 12-bit mode only, so the actual +resolution is read back from the chip and verified. + +Note: Changing the resolution reverts the conversion time to default. + +The write-only sysfs entry ``eeprom`` is an alternative for EEPROM operations. +Write ``save`` to save device RAM to EEPROM. Write ``restore`` to restore EEPROM +data in device RAM. + +``ext_power`` entry allows checking the power state of each device. Reads +``0`` if the device is parasite powered, ``1`` if the device is externally powered. + +Sysfs ``alarms`` allow read or write TH and TL (Temperature High an Low) alarms. Values shall be space separated and in the device range (typical -55 degC to 125 degC). Values are integer as they are store in a 8bit register in -the device. Lowest value is automatically put to TL.Once set, alarms could +the device. Lowest value is automatically put to TL. Once set, alarms could be search at master level. The module parameter strong_pullup can be set to 0 to disable the @@ -102,5 +116,24 @@ The DS28EA00 provides an additional two pins for implementing a sequence detection algorithm. This feature allows you to determine the physical location of the chip in the 1-wire bus without needing pre-existing knowledge of the bus ordering. Support is provided through the sysfs -w1_seq file. The file will contain a single line with an integer value +``w1_seq``. The file will contain a single line with an integer value representing the device index in the bus starting at 0. + +``features`` sysfs entry controls optional driver settings per device. +Insufficient power in parasite mode, line noise and insufficient conversion +time may lead to conversion failure. Original DS18B20 and some clones allow for +detection of invalid conversion. Write bit mask ``1`` to ``features`` to enable +checking the conversion success. If byte 6 of scratchpad memory is 0xC after +conversion and temperature reads 85.00 (powerup value) or 127.94 (insufficient +power), the driver returns a conversion error. Bit mask ``2`` enables poll for +conversion completion (normal power only) by generating read cycles on the bus +after conversion starts. In parasite power mode this feature is not available. +Feature bit masks may be combined (OR). More details in +Documentation/ABI/testing/sysfs-driver-w1_therm + +GX20MH01 device shares family number 0x28 with DS18*20. The device is generally +compatible with DS18B20. Added are lowest 2\ :sup:`-5`, 2\ :sup:`-6` temperature +bits in Config register; R2 bit in Config register enabling 13 and 14 bit +resolutions. The device is powered up in 14-bit resolution mode. The conversion +times specified in the datasheet are too low and have to be increased. The +device supports driver features ``1`` and ``2``. |