mirror of
https://github.com/linux-msm/laptops-kernel.git
synced 2026-08-13 14:19:53 -07:00
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 ...
This commit is contained in:
@@ -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.
|
||||
@@ -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
|
||||
@@ -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.
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -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";
|
||||
};
|
||||
@@ -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>;
|
||||
};
|
||||
};
|
||||
@@ -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>;
|
||||
};
|
||||
|
||||
@@ -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>;
|
||||
}
|
||||
|
||||
@@ -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>;
|
||||
};
|
||||
...
|
||||
|
||||
@@ -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
|
||||
|
||||
+39
-3
@@ -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
|
||||
@@ -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>;
|
||||
};
|
||||
@@ -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
|
||||
|
||||
@@ -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
|
||||
---------------------
|
||||
|
||||
@@ -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>
|
||||
|
||||
@@ -11,6 +11,7 @@ Linux Virtualization Support
|
||||
uml/user_mode_linux_howto_v2
|
||||
paravirt_ops
|
||||
guest-halt-polling
|
||||
ne_overview
|
||||
|
||||
.. only:: html and subproject
|
||||
|
||||
|
||||
@@ -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
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user