diff options
Diffstat (limited to 'Documentation')
72 files changed, 1501 insertions, 113 deletions
diff --git a/Documentation/RCU/whatisRCU.rst b/Documentation/RCU/whatisRCU.rst index 872ac665223f..94838c65c7d9 100644 --- a/Documentation/RCU/whatisRCU.rst +++ b/Documentation/RCU/whatisRCU.rst @@ -427,7 +427,7 @@ their assorted primitives. This section shows a simple use of the core RCU API to protect a global pointer to a dynamically allocated structure. More-typical -uses of RCU may be found in listRCU.rst, arrayRCU.rst, and NMI-RCU.rst. +uses of RCU may be found in listRCU.rst and NMI-RCU.rst. :: struct foo { @@ -510,8 +510,8 @@ So, to sum up: data item. See checklist.rst for additional rules to follow when using RCU. -And again, more-typical uses of RCU may be found in listRCU.rst, -arrayRCU.rst, and NMI-RCU.rst. +And again, more-typical uses of RCU may be found in listRCU.rst +and NMI-RCU.rst. .. _4_whatisRCU: diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index 396137ee018d..7d22e8a89a58 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -4785,7 +4785,9 @@ prot_virt= [S390] enable hosting protected virtual machines isolated from the hypervisor (if hardware supports - that). + that). If enabled, the default kernel base address + might be overridden even when Kernel Address Space + Layout Randomization is disabled. Format: <bool> psi= [KNL] Enable or disable pressure stall information @@ -5096,6 +5098,20 @@ delay, memory pressure or callback list growing too big. + rcutree.rcu_normal_wake_from_gp= [KNL] + Reduces a latency of synchronize_rcu() call. This approach + maintains its own track of synchronize_rcu() callers, so it + does not interact with regular callbacks because it does not + use a call_rcu[_hurry]() path. Please note, this is for a + normal grace period. + + How to enable it: + + echo 1 > /sys/module/rcutree/parameters/rcu_normal_wake_from_gp + or pass a boot parameter "rcutree.rcu_normal_wake_from_gp=1" + + Default is 0. + rcuscale.gp_async= [KNL] Measure performance of asynchronous grace-period primitives such as call_rcu(). @@ -6749,6 +6765,7 @@ - "tpm" - "tee" - "caam" + - "dcp" If not specified then it defaults to iterating through the trust source list starting with TPM and assigns the first trust source as a backend which is initialized @@ -6764,6 +6781,18 @@ If not specified, "default" is used. In this case, the RNG's choice is left to each individual trust source. + trusted.dcp_use_otp_key + This is intended to be used in combination with + trusted.source=dcp and will select the DCP OTP key + instead of the DCP UNIQUE key blob encryption. + + trusted.dcp_skip_zk_test + This is intended to be used in combination with + trusted.source=dcp and will disable the check if the + blob key is all zeros. This is helpful for situations where + having this key zero'ed is acceptable. E.g. in testing + scenarios. + tsc= Disable clocksource stability checks for TSC. Format: <string> [x86] reliable: mark tsc clocksource as reliable, this diff --git a/Documentation/arch/s390/index.rst b/Documentation/arch/s390/index.rst index 73c79bf586fd..e75a6e5d2505 100644 --- a/Documentation/arch/s390/index.rst +++ b/Documentation/arch/s390/index.rst @@ -8,6 +8,7 @@ s390 Architecture cds 3270 driver-model + mm monreader qeth s390dbf diff --git a/Documentation/arch/s390/mm.rst b/Documentation/arch/s390/mm.rst new file mode 100644 index 000000000000..084adad5eef9 --- /dev/null +++ b/Documentation/arch/s390/mm.rst @@ -0,0 +1,111 @@ +.. SPDX-License-Identifier: GPL-2.0 + +================= +Memory Management +================= + +Virtual memory layout +===================== + +.. note:: + + - Some aspects of the virtual memory layout setup are not + clarified (number of page levels, alignment, DMA memory). + + - Unused gaps in the virtual memory layout could be present + or not - depending on how partucular system is configured. + No page tables are created for the unused gaps. + + - The virtual memory regions are tracked or untracked by KASAN + instrumentation, as well as the KASAN shadow memory itself is + created only when CONFIG_KASAN configuration option is enabled. + +:: + + ============================================================================= + | Physical | Virtual | VM area description + ============================================================================= + +- 0 --------------+- 0 --------------+ + | | S390_lowcore | Low-address memory + | +- 8 KB -----------+ + | | | + | | | + | | ... unused gap | KASAN untracked + | | | + +- AMODE31_START --+- AMODE31_START --+ .amode31 rand. phys/virt start + |.amode31 text/data|.amode31 text/data| KASAN untracked + +- AMODE31_END ----+- AMODE31_END ----+ .amode31 rand. phys/virt end (<2GB) + | | | + | | | + +- __kaslr_offset_phys | kernel rand. phys start + | | | + | kernel text/data | | + | | | + +------------------+ | kernel phys end + | | | + | | | + | | | + | | | + +- ident_map_size -+ | + | | + | ... unused gap | KASAN untracked + | | + +- __identity_base + identity mapping start (>= 2GB) + | | + | identity | phys == virt - __identity_base + | mapping | virt == phys + __identity_base + | | + | | KASAN tracked + | | + | | + | | + | | + | | + | | + | | + | | + | | + | | + | | + | | + | | + | | + | | + +---- vmemmap -----+ 'struct page' array start + | | + | virtually mapped | + | memory map | KASAN untracked + | | + +- __abs_lowcore --+ + | | + | Absolute Lowcore | KASAN untracked + | | + +- __memcpy_real_area + | | + | Real Memory Copy| KASAN untracked + | | + +- VMALLOC_START --+ vmalloc area start + | | KASAN untracked or + | vmalloc area | KASAN shallowly populated in case + | | CONFIG_KASAN_VMALLOC=y + +- MODULES_VADDR --+ modules area start + | | KASAN allocated per module or + | modules area | KASAN shallowly populated in case + | | CONFIG_KASAN_VMALLOC=y + +- __kaslr_offset -+ kernel rand. virt start + | | KASAN tracked + | kernel text/data | phys == (kvirt - __kaslr_offset) + + | | __kaslr_offset_phys + +- kernel .bss end + kernel rand. virt end + | | + | ... unused gap | KASAN untracked + | | + +------------------+ UltraVisor Secure Storage limit + | | + | ... unused gap | KASAN untracked + | | + +KASAN_SHADOW_START+ KASAN shadow memory start + | | + | KASAN shadow | KASAN untracked + | | + +------------------+ ASCE limit diff --git a/Documentation/arch/s390/vfio-ap.rst b/Documentation/arch/s390/vfio-ap.rst index 929ee1c1c940..ea744cbc8687 100644 --- a/Documentation/arch/s390/vfio-ap.rst +++ b/Documentation/arch/s390/vfio-ap.rst @@ -380,6 +380,36 @@ matrix device. control_domains: A read-only file for displaying the control domain numbers assigned to the vfio_ap mediated device. + ap_config: + A read/write file that, when written to, allows all three of the + vfio_ap mediated device's ap matrix masks to be replaced in one shot. + Three masks are given, one for adapters, one for domains, and one for + control domains. If the given state cannot be set then no changes are + made to the vfio-ap mediated device. + + The format of the data written to ap_config is as follows: + {amask},{dmask},{cmask}\n + + \n is a newline character. + + amask, dmask, and cmask are masks identifying which adapters, domains, + and control domains should be assigned to the mediated device. + + The format of a mask is as follows: + 0xNN..NN + + Where NN..NN is 64 hexadecimal characters representing a 256-bit value. + The leftmost (highest order) bit represents adapter/domain 0. + + For an example set of masks that represent your mdev's current + configuration, simply cat ap_config. + + Setting an adapter or domain number greater than the maximum allowed for + the system will result in an error. + + This attribute is intended to be used by automation. End users would be + better served using the respective assign/unassign attributes for + adapters, domains, and control domains. * functions: @@ -550,7 +580,7 @@ These are the steps: following Kconfig elements selected: * IOMMU_SUPPORT * S390 - * ZCRYPT + * AP * VFIO * KVM diff --git a/Documentation/atomic_t.txt b/Documentation/atomic_t.txt index d7adc6d543db..bee3b1bca9a7 100644 --- a/Documentation/atomic_t.txt +++ b/Documentation/atomic_t.txt @@ -171,14 +171,14 @@ The rule of thumb: - RMW operations that are conditional are unordered on FAILURE, otherwise the above rules apply. -Except of course when an operation has an explicit ordering like: +Except of course when a successful operation has an explicit ordering like: {}_relaxed: unordered {}_acquire: the R of the RMW (or atomic_read) is an ACQUIRE {}_release: the W of the RMW (or atomic_set) is a RELEASE Where 'unordered' is against other memory locations. Address dependencies are -not defeated. +not defeated. Conditional operations are still unordered on FAILURE. Fully ordered primitives are ordered against everything prior and everything subsequent. Therefore a fully ordered primitive is like having an smp_mb() diff --git a/Documentation/dev-tools/kcsan.rst b/Documentation/dev-tools/kcsan.rst index 94b6802ab0ab..02143f060b22 100644 --- a/Documentation/dev-tools/kcsan.rst +++ b/Documentation/dev-tools/kcsan.rst @@ -91,6 +91,16 @@ the below options are available: behaviour when encountering a data race is deemed safe. Please see `"Marking Shared-Memory Accesses" in the LKMM`_ for more information. +* Similar to ``data_race(...)``, the type qualifier ``__data_racy`` can be used + to document that all data races due to accesses to a variable are intended + and should be ignored by KCSAN:: + + struct foo { + ... + int __data_racy stats_counter; + ... + }; + * Disabling data race detection for entire functions can be accomplished by using the function attribute ``__no_kcsan``:: diff --git a/Documentation/devicetree/bindings/access-controllers/access-controllers.yaml b/Documentation/devicetree/bindings/access-controllers/access-controllers.yaml new file mode 100644 index 000000000000..99e2865f0e46 --- /dev/null +++ b/Documentation/devicetree/bindings/access-controllers/access-controllers.yaml @@ -0,0 +1,84 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/access-controllers/access-controllers.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Generic Domain Access Controllers + +maintainers: + - Oleksii Moisieiev <oleksii_moisieiev@epam.com> + +description: |+ + Common access controllers properties + + Access controllers are in charge of stating which of the hardware blocks under + their responsibility (their domain) can be accesssed by which compartment. A + compartment can be a cluster of CPUs (or coprocessors), a range of addresses + or a group of hardware blocks. An access controller's domain is the set of + resources covered by the access controller. + + This device tree binding can be used to bind devices to their access + controller provided by access-controllers property. In this case, the device + is a consumer and the access controller is the provider. + + An access controller can be represented by any node in the device tree and + can provide one or more configuration parameters, needed to control parameters + of the consumer device. A consumer node can refer to the provider by phandle + and a set of phandle arguments, specified by '#access-controller-cells' + property in the access controller node. + + Access controllers are typically used to set/read the permissions of a + hardware block and grant access to it. Any of which depends on the access + controller. The capabilities of each access controller are defined by the + binding of the access controller device. + + Each node can be a consumer for the several access controllers. + +# always select the core schema +select: true + +properties: + "#access-controller-cells": + description: + Number of cells in an access-controllers specifier; + Can be any value as specified by device tree binding documentation + of a particular provider. The node is an access controller. + + access-controller-names: + $ref: /schemas/types.yaml#/definitions/string-array + description: + A list of access-controllers names, sorted in the same order as + access-controllers entries. Consumer drivers will use + access-controller-names to match with existing access-controllers entries. + + access-controllers: + $ref: /schemas/types.yaml#/definitions/phandle-array + description: + A list of access controller specifiers, as defined by the + bindings of the access-controllers provider. + +additionalProperties: true + +examples: + - | + clock_controller: access-controllers@50000 { + reg = <0x50000 0x400>; + #access-controller-cells = <2>; + }; + + bus_controller: bus@60000 { + reg = <0x60000 0x10000>; + #address-cells = <1>; + #size-cells = <1>; + ranges; + #access-controller-cells = <3>; + + uart4: serial@60100 { + reg = <0x60100 0x400>; + clocks = <&clk_serial>; + access-controllers = <&clock_controller 1 2>, + <&bus_controller 1 3 5>; + access-controller-names = "clock", "bus"; + }; + }; diff --git a/Documentation/devicetree/bindings/arm/bcm/brcm,bcm4708.yaml b/Documentation/devicetree/bindings/arm/bcm/brcm,bcm4708.yaml index 4cc4e6754681..d925e7a3b5ef 100644 --- a/Documentation/devicetree/bindings/arm/bcm/brcm,bcm4708.yaml +++ b/Documentation/devicetree/bindings/arm/bcm/brcm,bcm4708.yaml @@ -53,6 +53,7 @@ properties: - description: BCM4709 based boards items: - enum: + - asus,rt-ac3200 - asus,rt-ac87u - buffalo,wxr-1900dhp - linksys,ea9200 @@ -67,6 +68,7 @@ properties: items: - enum: - asus,rt-ac3100 + - asus,rt-ac5300 - asus,rt-ac88u - dlink,dir-885l - dlink,dir-890l diff --git a/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml b/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml index 39e3c248f5b7..1f84407a73e4 100644 --- a/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml +++ b/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml @@ -46,6 +46,30 @@ properties: - compatible - "#clock-cells" + gpio: + type: object + additionalProperties: false + + properties: + compatible: + const: raspberrypi,firmware-gpio + + gpio-controller: true + + "#gpio-cells": + const: 2 + description: + The first cell is the pin number, and the second cell is used to + specify the gpio polarity (GPIO_ACTIVE_HIGH or GPIO_ACTIVE_LOW). + + gpio-line-names: + minItems: 8 + + required: + - compatible + - gpio-controller + - "#gpio-cells" + reset: type: object additionalProperties: false @@ -96,6 +120,12 @@ examples: #clock-cells = <1>; }; + expgpio: gpio { + compatible = "raspberrypi,firmware-gpio"; + gpio-controller; + #gpio-cells = <2>; + }; + reset: reset { compatible = "raspberrypi,firmware-reset"; #reset-cells = <1>; diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml index 0027201e19f8..6d185d09cb6a 100644 --- a/Documentation/devicetree/bindings/arm/fsl.yaml +++ b/Documentation/devicetree/bindings/arm/fsl.yaml @@ -813,6 +813,14 @@ properties: - const: tq,imx6ull-tqma6ull2l # MCIMX6Y2, LGA SoM variant - const: fsl,imx6ull + - description: Seeed Stuido i.MX6ULL SoM on dev boards + items: + - enum: + - seeed,imx6ull-seeed-npi-emmc + - seeed,imx6ull-seeed-npi-nand + - const: seeed,imx6ull-seeed-npi + - const: fsl,imx6ull + - description: i.MX6ULZ based Boards items: - enum: @@ -1050,6 +1058,7 @@ properties: - enum: - beacon,imx8mp-beacon-kit # i.MX8MP Beacon Development Kit - dmo,imx8mp-data-modul-edm-sbc # i.MX8MP eDM SBC + - emcraft,imx8mp-navqp # i.MX8MP Emcraft Systems NavQ+ Kit - fsl,imx8mp-evk # i.MX8MP EVK Board - gateworks,imx8mp-gw71xx-2x # i.MX8MP Gateworks Board - gateworks,imx8mp-gw72xx-2x # i.MX8MP Gateworks Board @@ -1218,7 +1227,6 @@ properties: - enum: - einfochips,imx8qxp-ai_ml # i.MX8QXP AI_ML Board - fsl,imx8qxp-mek # i.MX8QXP MEK Board - - toradex,colibri-imx8x # Colibri iMX8X Modules - const: fsl,imx8qxp - description: i.MX8DXL based Boards @@ -1227,7 +1235,7 @@ properties: - fsl,imx8dxl-evk # i.MX8DXL EVK Board - const: fsl,imx8dxl - - description: i.MX8QXP Boards with Toradex Colibri iMX8X Modules + - description: i.MX8QXP/i.MX8DX Boards with Toradex Colibri iMX8X Modules items: - enum: - toradex,colibri-imx8x-aster # Colibri iMX8X Module on Aster Board @@ -1235,7 +1243,9 @@ properties: - toradex,colibri-imx8x-iris # Colibri iMX8X Module on Iris Board - toradex,colibri-imx8x-iris-v2 # Colibri iMX8X Module on Iris Board V2 - const: toradex,colibri-imx8x - - const: fsl,imx8qxp + - enum: + - fsl,imx8qxp + - fsl,imx8dx - description: TQMa8Xx is a series of SOM featuring NXP i.MX8X system-on-chip @@ -1536,6 +1546,12 @@ properties: - nxp,s32g274a-rdb2 - const: nxp,s32g2 + - description: S32G3 based Boards + items: + - enum: + - nxp,s32g399a-rdb3 + - const: nxp,s32g3 + - description: S32V234 based Boards items: - enum: diff --git a/Documentation/devicetree/bindings/arm/keystone/ti,sci.yaml b/Documentation/devicetree/bindings/arm/keystone/ti,sci.yaml index c24ad0968f3e..7f06b1080244 100644 --- a/Documentation/devicetree/bindings/arm/keystone/ti,sci.yaml +++ b/Documentation/devicetree/bindings/arm/keystone/ti,sci.yaml @@ -61,10 +61,6 @@ properties: mboxes: minItems: 2 - ti,system-reboot-controller: - description: Determines If system reboot can be triggered by SoC reboot - type: boolean - ti,host-id: $ref: /schemas/types.yaml#/definitions/uint32 description: | @@ -94,7 +90,6 @@ examples: - | pmmc: system-controller@2921800 { compatible = "ti,k2g-sci"; - ti,system-reboot-controller; mbox-names = "rx", "tx"; mboxes = <&msgmgr 5 2>, <&msgmgr 0 0>; diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml index 66beaac60e1d..ae885414b181 100644 --- a/Documentation/devicetree/bindings/arm/qcom.yaml +++ b/Documentation/devicetree/bindings/arm/qcom.yaml @@ -137,6 +137,7 @@ properties: - microsoft,dempsey - microsoft,makepeace - microsoft,moneypenny + - motorola,falcon - samsung,s3ve3g - const: qcom,msm8226 @@ -184,13 +185,16 @@ properties: - oneplus,bacon - samsung,klte - sony,xperia-castor + - sony,xperia-leo - const: qcom,msm8974pro - const: qcom,msm8974 - items: - - const: qcom,msm8916-mtp - - const: qcom,msm8916-mtp/1 - - const: qcom,msm8916 + - enum: + - samsung,kltechn + - const: samsung,klte + - const: qcom,msm8974pro + - const: qcom,msm8974 - items: - enum: @@ -200,6 +204,8 @@ properties: - gplus,fl8005a - huawei,g7 - longcheer,l8910 + - longcheer,l8150 + - qcom,msm8916-mtp - samsung,a3u-eur - samsung,a5u-eur - samsung,e5 @@ -221,11 +227,6 @@ properties: - const: qcom,msm8916 - items: - - const: longcheer,l8150 - - const: qcom,msm8916-v1-qrd/9-v1 - - const: qcom,msm8916 - - - items: - enum: - motorola,potter - xiaomi,daisy @@ -1003,6 +1004,7 @@ properties: - qcom,sm8550-hdk - qcom,sm8550-mtp - qcom,sm8550-qrd + - sony,pdx234 - const: qcom,sm8550 - items: diff --git a/Documentation/devicetree/bindings/arm/rockchip.yaml b/Documentation/devicetree/bindings/arm/rockchip.yaml index fcf7316ecd74..e04c213a0dee 100644 --- a/Documentation/devicetree/bindings/arm/rockchip.yaml +++ b/Documentation/devicetree/bindings/arm/rockchip.yaml @@ -49,6 +49,11 @@ properties: - anbernic,rg-arc-s - const: rockchip,rk3566 + - description: ArmSoM Sige7 board + items: + - const: armsom,sige7 + - const: rockchip,rk3588 + - description: Asus Tinker board items: - const: asus,rk3288-tinker @@ -198,6 +203,13 @@ properties: - const: firefly,rk3568-roc-pc - const: rockchip,rk3568 + - description: Forlinx FET3588-C SoM + items: + - enum: + - forlinx,ok3588-c + - const: forlinx,fet3588-c + - const: rockchip,rk3588 + - description: FriendlyElec NanoPi R2 series boards items: - enum: @@ -236,6 +248,11 @@ properties: - const: friendlyarm,nanopc-t6 - const: rockchip,rk3588 + - description: GameForce Chi + items: + - const: gameforce,chi + - const: rockchip,rk3326 + - description: GeekBuying GeekBox items: - const: geekbuying,geekbox @@ -631,7 +648,7 @@ properties: - const: phytec,rk3288-phycore-som - const: rockchip,rk3288 - - description: Pine64 PinebookPro + - description: Pine64 Pinebook Pro items: - const: pine64,pinebook-pro - const: rockchip,rk3399 @@ -644,7 +661,7 @@ properties: - const: pine64,pinenote - const: rockchip,rk3566 - - description: Pine64 PinePhonePro + - description: Pine64 PinePhone Pro items: - const: pine64,pinephone-pro - const: rockchip,rk3399 @@ -682,7 +699,7 @@ properties: - const: pine64,quartzpro64 - const: rockchip,rk3588 - - description: Pine64 SoQuartz SoM + - description: Pine64 SOQuartz items: - enum: - pine64,soquartz-blade @@ -700,12 +717,17 @@ properties: - powkiddy,x55 - const: rockchip,rk3566 + - description: Protonic MECSBC board + items: + - const: prt,mecsbc + - const: rockchip,rk3568 + - description: QNAP TS-433-4G 4-Bay NAS items: - const: qnap,ts433 - const: rockchip,rk3568 - - description: Radxa Compute Module 3(CM3) + - description: Radxa Compute Module 3 (CM3) items: - enum: - radxa,cm3-io @@ -767,22 +789,27 @@ properties: - const: radxa,rockpis - const: rockchip,rk3308 - - description: Radxa Rock2 Square + - description: Radxa Rock 2 Square items: - const: radxa,rock2-square - const: rockchip,rk3288 - - description: Radxa ROCK3 Model A + - description: Radxa ROCK 3A items: - const: radxa,rock3a - const: rockchip,rk3568 - - description: Radxa ROCK 5 Model A + - description: Radxa ROCK 3C + items: + - const: radxa,rock-3c + - const: rockchip,rk3566 + + - description: Radxa ROCK 5A items: - const: radxa,rock-5a - const: rockchip,rk3588s - - description: Radxa ROCK 5 Model B + - description: Radxa ROCK 5B items: - const: radxa,rock-5b - const: rockchip,rk3588 @@ -927,6 +954,11 @@ properties: - const: turing,rk1 - const: rockchip,rk3588 + - description: WolfVision PF5 mainboard + items: + - const: wolfvision,rk3568-pf5 + - const: rockchip,rk3568 + - description: Xunlong Orange Pi 5 Plus items: - const: xunlong,orangepi-5-plus diff --git a/Documentation/devicetree/bindings/arm/sunxi.yaml b/Documentation/devicetree/bindings/arm/sunxi.yaml index 09d835db6db5..c6d0d8d81ed4 100644 --- a/Documentation/devicetree/bindings/arm/sunxi.yaml +++ b/Documentation/devicetree/bindings/arm/sunxi.yaml @@ -56,6 +56,21 @@ properties: - const: anbernic,rg-nano - const: allwinner,sun8i-v3s + - description: Anbernic RG35XX (2024) + - items: + - const: anbernic,rg35xx-2024 + - const: allwinner,sun50i-h700 + + - description: Anbernic RG35XX Plus + - items: + - const: anbernic,rg35xx-plus + - const: allwinner,sun50i-h700 + + - description: Anbernic RG35XX H + - items: + - const: anbernic,rg35xx-h + - const: allwinner,sun50i-h700 + - description: Amarula A64 Relic items: - const: amarula,a64-relic @@ -774,6 +789,11 @@ properties: - const: pocketbook,touch-lux-3 - const: allwinner,sun5i-a13 + - description: PocketBook 614 Plus + items: + - const: pocketbook,614-plus + - const: allwinner,sun5i-a13 + - description: Point of View Protab2-IPS9 items: - const: pov,protab2-ips9 @@ -860,6 +880,11 @@ properties: - const: allwinner,sl631 - const: allwinner,sun8i-v3 + - description: Tanix TX1 + items: + - const: oranth,tanix-tx1 + - const: allwinner,sun50i-h616 + - description: Tanix TX6 items: - const: oranth,tanix-tx6 diff --git a/Documentation/devicetree/bindings/bus/st,stm32-etzpc.yaml b/Documentation/devicetree/bindings/bus/st,stm32-etzpc.yaml new file mode 100644 index 000000000000..d12b62a3a5a8 --- /dev/null +++ b/Documentation/devicetree/bindings/bus/st,stm32-etzpc.yaml @@ -0,0 +1,96 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/bus/st,stm32-etzpc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: STM32 Extended TrustZone protection controller + +description: | + The ETZPC configures TrustZone security in a SoC having bus masters and + devices with programmable-security attributes (securable resources). + +maintainers: + - Gatien Chevallier <gatien.chevallier@foss.st.com> + +select: + properties: + compatible: + contains: + const: st,stm32-etzpc + required: + - compatible + +properties: + compatible: + items: + - const: st,stm32-etzpc + - const: simple-bus + + reg: + maxItems: 1 + + "#address-cells": + const: 1 + + "#size-cells": + const: 1 + + ranges: true + + "#access-controller-cells": + const: 1 + description: + Contains the firewall ID associated to the peripheral. + +patternProperties: + "^.*@[0-9a-f]+$": + description: Peripherals + type: object + + additionalProperties: true + + required: + - access-controllers + +required: + - compatible + - reg + - "#address-cells" + - "#size-cells" + - "#access-controller-cells" + - ranges + +additionalProperties: false + +examples: + - | + // In this example, the usart2 device refers to rifsc as its access + // controller. + // Access rights are verified before creating devices. + + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/clock/stm32mp13-clks.h> + #include <dt-bindings/reset/stm32mp13-resets.h> + + etzpc: bus@5c007000 { + compatible = "st,stm32-etzpc", "simple-bus"; + reg = <0x5c007000 0x400>; + #address-cells = <1>; + #size-cells = <1>; + #access-controller-cells = <1>; + ranges; + + usart2: serial@4c001000 { + compatible = "st,stm32h7-uart"; + reg = <0x4c001000 0x400>; + interrupts-extended = <&exti 27 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&rcc USART2_K>; + resets = <&rcc USART2_R>; + wakeup-source; + dmas = <&dmamux1 43 0x400 0x5>, + <&dmamux1 44 0x400 0x1>; + dma-names = "rx", "tx"; + access-controllers = <&etzpc 17>; + }; + }; diff --git a/Documentation/devicetree/bindings/bus/st,stm32mp25-rifsc.yaml b/Documentation/devicetree/bindings/bus/st,stm32mp25-rifsc.yaml new file mode 100644 index 000000000000..20acd1a6b173 --- /dev/null +++ b/Documentation/devicetree/bindings/bus/st,stm32mp25-rifsc.yaml @@ -0,0 +1,105 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/bus/st,stm32mp25-rifsc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: STM32 Resource isolation framework security controller + +maintainers: + - Gatien Chevallier <gatien.chevallier@foss.st.com> + +description: | + Resource isolation framework (RIF) is a comprehensive set of hardware blocks + designed to enforce and manage isolation of STM32 hardware resources like + memory and peripherals. + + The RIFSC (RIF security controller) is composed of three sets of registers, + each managing a specific set of hardware resources: + - RISC registers associated with RISUP logic (resource isolation device unit + for peripherals), assign all non-RIF aware peripherals to zero, one or + any security domains (secure, privilege, compartment). + - RIMC registers: associated with RIMU logic (resource isolation master + unit), assign all non RIF-aware bus master to one security domain by + setting secure, privileged and compartment information on the system bus. + Alternatively, the RISUP logic controlling the device port access to a + peripheral can assign target bus attributes to this peripheral master port + (supported attribute: CID). + - RISC registers associated with RISAL logic (resource isolation device unit + for address space - Lite version), assign address space subregions to one + security domains (secure, privilege, compartment). + +select: + properties: + compatible: + contains: + const: st,stm32mp25-rifsc + required: + - compatible + +properties: + compatible: + items: + - const: st,stm32mp25-rifsc + - const: simple-bus + + reg: + maxItems: 1 + + "#address-cells": + const: 1 + + "#size-cells": + const: 1 + + ranges: true + + "#access-controller-cells": + const: 1 + description: + Contains the firewall ID associated to the peripheral. + +patternProperties: + "^.*@[0-9a-f]+$": + description: Peripherals + type: object + + additionalProperties: true + + required: + - access-controllers + +required: + - compatible + - reg + - "#address-cells" + - "#size-cells" + - "#access-controller-cells" + - ranges + +additionalProperties: false + +examples: + - | + // In this example, the usart2 device refers to rifsc as its domain + // controller. + // Access rights are verified before creating devices. + + #include <dt-bindings/interrupt-controller/arm-gic.h> + + rifsc: bus@42080000 { + compatible = "st,stm32mp25-rifsc", "simple-bus"; + reg = <0x42080000 0x1000>; + #address-cells = <1>; + #size-cells = <1>; + #access-controller-cells = <1>; + ranges; + + usart2: serial@400e0000 { + compatible = "st,stm32h7-uart"; + reg = <0x400e0000 0x400>; + interrupts = <GIC_SPI 115 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&ck_flexgen_08>; + access-controllers = <&rifsc 32>; + }; + }; diff --git a/Documentation/devicetree/bindings/clock/google,gs101-clock.yaml b/Documentation/devicetree/bindings/clock/google,gs101-clock.yaml index 1d2bcea41c85..caf442ead24b 100644 --- a/Documentation/devicetree/bindings/clock/google,gs101-clock.yaml +++ b/Documentation/devicetree/bindings/clock/google,gs101-clock.yaml @@ -30,16 +30,18 @@ properties: - google,gs101-cmu-top - google,gs101-cmu-apm - google,gs101-cmu-misc + - google,gs101-cmu-hsi0 + - google,gs101-cmu-hsi2 - google,gs101-cmu-peric0 - google,gs101-cmu-peric1 clocks: minItems: 1 - maxItems: 3 + maxItems: 5 clock-names: minItems: 1 - maxItems: 3 + maxItems: 5 "#clock-cells": const: 1 @@ -76,6 +78,55 @@ allOf: properties: compatible: contains: + const: google,gs101-cmu-hsi0 + + then: + properties: + clocks: + items: + - description: External reference clock (24.576 MHz) + - description: HSI0 bus clock (from CMU_TOP) + - description: DPGTC (from CMU_TOP) + - description: USB DRD controller clock (from CMU_TOP) + - description: USB Display Port debug clock (from CMU_TOP) + + clock-names: + items: + - const: oscclk + - const: bus + - const: dpgtc + - const: usb31drd + - const: usbdpdbg + + - if: + properties: + compatible: + contains: + enum: + - google,gs101-cmu-hsi2 + + then: + properties: + clocks: + items: + - description: External reference clock (24.576 MHz) + - description: High Speed Interface bus clock (from CMU_TOP) + - description: High Speed Interface pcie clock (from CMU_TOP) + - description: High Speed Interface ufs clock (from CMU_TOP) + - description: High Speed Interface mmc clock (from CMU_TOP) + + clock-names: + items: + - const: oscclk + - const: bus + - const: pcie + - const: ufs + - const: mmc + + - if: + properties: + compatible: + contains: const: google,gs101-cmu-misc then: diff --git a/Documentation/devicetree/bindings/crypto/st,stm32-cryp.yaml b/Documentation/devicetree/bindings/crypto/st,stm32-cryp.yaml index 0ddeb8a9a7a0..27354658d054 100644 --- a/Documentation/devicetree/bindings/crypto/st,stm32-cryp.yaml +++ b/Documentation/devicetree/bindings/crypto/st,stm32-cryp.yaml @@ -46,6 +46,10 @@ properties: power-domains: maxItems: 1 + access-controllers: + minItems: 1 + maxItems: 2 + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/crypto/st,stm32-hash.yaml b/Documentation/devicetree/bindings/crypto/st,stm32-hash.yaml index ac480765cde0..822318414095 100644 --- a/Documentation/devicetree/bindings/crypto/st,stm32-hash.yaml +++ b/Documentation/devicetree/bindings/crypto/st,stm32-hash.yaml @@ -51,6 +51,10 @@ properties: power-domains: maxItems: 1 + access-controllers: + minItems: 1 + maxItems: 2 + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml index a95445f40870..397e810008bd 100644 --- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml +++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml @@ -348,15 +348,6 @@ properties: # Yes Optoelectronics YTC700TLAG-05-201C 7" TFT LCD panel - yes-optoelectronics,ytc700tlag-05-201c - backlight: true - ddc-i2c-bus: true - enable-gpios: true - port: true - power-supply: true - no-hpd: true - hpd-gpios: true - data-mapping: true - if: not: properties: @@ -367,7 +358,7 @@ then: properties: data-mapping: false -additionalProperties: false +unevaluatedProperties: false required: - compatible diff --git a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.yaml b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.yaml index 94c5242c03b2..3563378a01af 100644 --- a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.yaml +++ b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.yaml @@ -182,6 +182,15 @@ allOf: compatible: contains: enum: + - nvidia,tegra194-host1x + then: + properties: + dma-coherent: true + - if: + properties: + compatible: + contains: + enum: - nvidia,tegra234-host1x then: properties: @@ -226,6 +235,8 @@ allOf: use. Should be a mapping of IDs 0..n to IOMMU entries corresponding to usable stream IDs. + dma-coherent: true + required: - reg-names diff --git a/Documentation/devicetree/bindings/dma/st,stm32-dma.yaml b/Documentation/devicetree/bindings/dma/st,stm32-dma.yaml index 329847ef096a..ff935a0068ec 100644 --- a/Documentation/devicetree/bindings/dma/st,stm32-dma.yaml +++ b/Documentation/devicetree/bindings/dma/st,stm32-dma.yaml @@ -82,6 +82,10 @@ properties: description: if defined, it indicates that the controller supports memory-to-memory transfer + access-controllers: + minItems: 1 + maxItems: 2 + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/dma/st,stm32-dmamux.yaml b/Documentation/devicetree/bindings/dma/st,stm32-dmamux.yaml index e722fbcd8a5f..ddf82bf1e71a 100644 --- a/Documentation/devicetree/bindings/dma/st,stm32-dmamux.yaml +++ b/Documentation/devicetree/bindings/dma/st,stm32-dmamux.yaml @@ -28,6 +28,10 @@ properties: resets: maxItems: 1 + access-controllers: + minItems: 1 + maxItems: 2 + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml index 4591523b51a0..7de2c29606e5 100644 --- a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml +++ b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml @@ -247,6 +247,37 @@ properties: reg: const: 0x18 + protocol@19: + type: object + allOf: + - $ref: '#/$defs/protocol-node' + - $ref: /schemas/pinctrl/pinctrl.yaml + + unevaluatedProperties: false + + properties: + reg: + const: 0x19 + + patternProperties: + '-pins$': + type: object + allOf: + - $ref: /schemas/pinctrl/pincfg-node.yaml# + - $ref: /schemas/pinctrl/pinmux-node.yaml# + unevaluatedProperties: false + + description: + A pin multiplexing sub-node describes how to configure a + set of pins in some desired function. + A single sub-node may define several pin configurations. + This sub-node is using the default pinctrl bindings to configure + pin multiplexing and using SCMI protocol to apply a specified + configuration. + + required: + - reg + additionalProperties: false $defs: @@ -355,7 +386,7 @@ examples: scmi_dvfs: protocol@13 { reg = <0x13>; - #clock-cells = <1>; + #power-domain-cells = <1>; mboxes = <&mhuB 1 0>, <&mhuB 1 1>; @@ -401,6 +432,25 @@ examples: scmi_powercap: protocol@18 { reg = <0x18>; }; + + scmi_pinctrl: protocol@19 { + reg = <0x19>; + + i2c2-pins { + groups = "g_i2c2_a", "g_i2c2_b"; + function = "f_i2c2"; + }; + + mdio-pins { + groups = "g_avb_mdio"; + drive-strength = <24>; + }; + + keys_pins: keys-pins { + pins = "gpio_5_17", "gpio_5_20", "gpio_5_22", "gpio_2_1"; + bias-pull-up; + }; + }; }; }; @@ -468,7 +518,7 @@ examples: reg = <0x13>; linaro,optee-channel-id = <1>; shmem = <&cpu_optee_lpri0>; - #clock-cells = <1>; + #power-domain-cells = <1>; }; scmi_clk0: protocol@14 { diff --git a/Documentation/devicetree/bindings/gpio/raspberrypi,firmware-gpio.txt b/Documentation/devicetree/bindings/gpio/raspberrypi,firmware-gpio.txt deleted file mode 100644 index ce97265e23ba..000000000000 --- a/Documentation/devicetree/bindings/gpio/raspberrypi,firmware-gpio.txt +++ /dev/null @@ -1,30 +0,0 @@ -Raspberry Pi GPIO expander - -The Raspberry Pi 3 GPIO expander is controlled by the VC4 firmware. The -firmware exposes a mailbox interface that allows the ARM core to control the -GPIO lines on the expander. - -The Raspberry Pi GPIO expander node must be a child node of the Raspberry Pi -firmware node. - -Required properties: - -- compatible : Should be "raspberrypi,firmware-gpio" -- gpio-controller : Marks the device node as a gpio controller -- #gpio-cells : Should be two. The first cell is the pin number, and - the second cell is used to specify the gpio polarity: - 0 = active high - 1 = active low - -Example: - -firmware: firmware-rpi { - compatible = "raspberrypi,bcm2835-firmware"; - mboxes = <&mailbox>; - - expgpio: gpio { - compatible = "raspberrypi,firmware-gpio"; - gpio-controller; - #gpio-cells = <2>; - }; -}; diff --git a/Documentation/devicetree/bindings/i2c/st,stm32-i2c.yaml b/Documentation/devicetree/bindings/i2c/st,stm32-i2c.yaml index 1b31b87c1800..8fd8be76875e 100644 --- a/Documentation/devicetree/bindings/i2c/st,stm32-i2c.yaml +++ b/Documentation/devicetree/bindings/i2c/st,stm32-i2c.yaml @@ -127,6 +127,10 @@ properties: wakeup-source: true + access-controllers: + minItems: 1 + maxItems: 2 + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/iio/adc/st,stm32-adc.yaml b/Documentation/devicetree/bindings/iio/adc/st,stm32-adc.yaml index 995cbf8cefc6..ec34c48d4878 100644 --- a/Documentation/devicetree/bindings/iio/adc/st,stm32-adc.yaml +++ b/Documentation/devicetree/bindings/iio/adc/st,stm32-adc.yaml @@ -93,6 +93,10 @@ properties: '#size-cells': const: 0 + access-controllers: + minItems: 1 + maxItems: 2 + allOf: - if: properties: diff --git a/Documentation/devicetree/bindings/iio/adc/st,stm32-dfsdm-adc.yaml b/Documentation/devicetree/bindings/iio/adc/st,stm32-dfsdm-adc.yaml index 1970503389aa..c1b1324fa132 100644 --- a/Documentation/devicetree/bindings/iio/adc/st,stm32-dfsdm-adc.yaml +++ b/Documentation/devicetree/bindings/iio/adc/st,stm32-dfsdm-adc.yaml @@ -59,6 +59,10 @@ properties: If not, SPI CLKOUT frequency will not be accurate. maximum: 20000000 + access-controllers: + minItems: 1 + maxItems: 2 + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/iio/dac/st,stm32-dac.yaml b/Documentation/devicetree/bindings/iio/dac/st,stm32-dac.yaml index 04045b932bd2..b15de4eb209c 100644 --- a/Documentation/devicetree/bindings/iio/dac/st,stm32-dac.yaml +++ b/Documentation/devicetree/bindings/iio/dac/st,stm32-dac.yaml @@ -45,6 +45,10 @@ properties: '#size-cells': const: 0 + access-controllers: + minItems: 1 + maxItems: 2 + additionalProperties: false required: diff --git a/Documentation/devicetree/bindings/media/cec/st,stm32-cec.yaml b/Documentation/devicetree/bindings/media/cec/st,stm32-cec.yaml index 2314a9a14650..1d930d9e10fd 100644 --- a/Documentation/devicetree/bindings/media/cec/st,stm32-cec.yaml +++ b/Documentation/devicetree/bindings/media/cec/st,stm32-cec.yaml @@ -29,6 +29,10 @@ properties: - const: cec - const: hdmi-cec + access-controllers: + minItems: 1 + maxItems: 2 + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/media/st,stm32-dcmi.yaml b/Documentation/devicetree/bindings/media/st,stm32-dcmi.yaml index 6b3e413cedb2..34147127192f 100644 --- a/Documentation/devicetree/bindings/media/st,stm32-dcmi.yaml +++ b/Documentation/devicetree/bindings/media/st,stm32-dcmi.yaml @@ -36,6 +36,10 @@ properties: resets: maxItems: 1 + access-controllers: + minItems: 1 + maxItems: 2 + port: $ref: /schemas/graph.yaml#/$defs/port-base unevaluatedProperties: false diff --git a/Documentation/devicetree/bindings/media/st,stm32mp25-video-codec.yaml b/Documentation/devicetree/bindings/media/st,stm32mp25-video-codec.yaml index b8611bc8756c..73726c65cfb9 100644 --- a/Documentation/devicetree/bindings/media/st,stm32mp25-video-codec.yaml +++ b/Documentation/devicetree/bindings/media/st,stm32mp25-video-codec.yaml @@ -30,6 +30,10 @@ properties: clocks: maxItems: 1 + access-controllers: + minItems: 1 + maxItems: 2 + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/memory-controllers/samsung,s5pv210-dmc.yaml b/Documentation/devicetree/bindings/memory-controllers/samsung,s5pv210-dmc.yaml new file mode 100644 index 000000000000..c0e47055f28c --- /dev/null +++ b/Documentation/devicetree/bindings/memory-controllers/samsung,s5pv210-dmc.yaml @@ -0,0 +1,33 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/memory-controllers/samsung,s5pv210-dmc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Samsung S5Pv210 SoC Dynamic Memory Controller + +maintainers: + - Krzysztof Kozlowski <krzk@kernel.org> + +description: + Dynamic Memory Controller interfaces external JEDEC DDR-type SDRAM. + +properties: + compatible: + const: samsung,s5pv210-dmc + + reg: + maxItems: 1 + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + memory-controller@f0000000 { + compatible = "samsung,s5pv210-dmc"; + reg = <0xf0000000 0x1000>; + }; diff --git a/Documentation/devicetree/bindings/memory-controllers/st,stm32-fmc2-ebi.yaml b/Documentation/devicetree/bindings/memory-controllers/st,stm32-fmc2-ebi.yaml index 84ac6f50a6fc..706e45eb4d27 100644 --- a/Documentation/devicetree/bindings/memory-controllers/st,stm32-fmc2-ebi.yaml +++ b/Documentation/devicetree/bindings/memory-controllers/st,stm32-fmc2-ebi.yaml @@ -50,6 +50,10 @@ properties: Reflects the memory layout with four integer values per bank. Format: <bank-number> 0 <address of the bank> <size> + access-controllers: + minItems: 1 + maxItems: 2 + patternProperties: "^.*@[0-4],[a-f0-9]+$": additionalProperties: true diff --git a/Documentation/devicetree/bindings/mfd/st,stm32-lptimer.yaml b/Documentation/devicetree/bindings/mfd/st,stm32-lptimer.yaml index 27329c5dc38e..d41308856408 100644 --- a/Documentation/devicetree/bindings/mfd/st,stm32-lptimer.yaml +++ b/Documentation/devicetree/bindings/mfd/st,stm32-lptimer.yaml @@ -44,6 +44,10 @@ properties: wakeup-source: true + access-controllers: + minItems: 1 + maxItems: 2 + pwm: type: object additionalProperties: false diff --git a/Documentation/devicetree/bindings/mfd/st,stm32-timers.yaml b/Documentation/devicetree/bindings/mfd/st,stm32-timers.yaml index f84e09a5743b..b0e438ff4950 100644 --- a/Documentation/devicetree/bindings/mfd/st,stm32-timers.yaml +++ b/Documentation/devicetree/bindings/mfd/st,stm32-timers.yaml @@ -67,6 +67,10 @@ properties: "#size-cells": const: 0 + access-controllers: + minItems: 1 + maxItems: 2 + pwm: type: object additionalProperties: false diff --git a/Documentation/devicetree/bindings/mmc/arm,pl18x.yaml b/Documentation/devicetree/bindings/mmc/arm,pl18x.yaml index 940b12688167..8f62e2c7fa64 100644 --- a/Documentation/devicetree/bindings/mmc/arm,pl18x.yaml +++ b/Documentation/devicetree/bindings/mmc/arm,pl18x.yaml @@ -79,6 +79,10 @@ properties: - const: rx - const: tx + access-controllers: + minItems: 1 + maxItems: 2 + power-domains: true resets: diff --git a/Documentation/devicetree/bindings/net/can/bosch,m_can.yaml b/Documentation/devicetree/bindings/net/can/bosch,m_can.yaml index f9ffb963d6b1..c4887522e8fe 100644 --- a/Documentation/devicetree/bindings/net/can/bosch,m_can.yaml +++ b/Documentation/devicetree/bindings/net/can/bosch,m_can.yaml @@ -118,6 +118,10 @@ properties: phys: maxItems: 1 + access-controllers: + minItems: 1 + maxItems: 2 + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/net/mediatek,net.yaml b/Documentation/devicetree/bindings/net/mediatek,net.yaml index e74502a0afe8..3202dc7967c5 100644 --- a/Documentation/devicetree/bindings/net/mediatek,net.yaml +++ b/Documentation/devicetree/bindings/net/mediatek,net.yaml @@ -337,8 +337,8 @@ allOf: minItems: 4 clocks: - minItems: 34 - maxItems: 34 + minItems: 24 + maxItems: 24 clock-names: items: @@ -351,18 +351,6 @@ allOf: - const: ethwarp_wocpu1 - const: ethwarp_wocpu0 - const: esw - - const: netsys0 - - const: netsys1 - - const: sgmii_tx250m - - const: sgmii_rx250m - - const: sgmii2_tx250m - - const: sgmii2_rx250m - - const: top_usxgmii0_sel - - const: top_usxgmii1_sel - - const: top_sgm0_sel - - const: top_sgm1_sel - - const: top_xfi_phy0_xtal_sel - - const: top_xfi_phy1_xtal_sel - const: top_eth_gmii_sel - const: top_eth_refck_50m_sel - const: top_eth_sys_200m_sel @@ -375,16 +363,10 @@ allOf: - const: top_netsys_sync_250m_sel - const: top_netsys_ppefb_250m_sel - const: top_netsys_warp_sel - - const: wocpu1 - - const: wocpu0 - const: xgp1 - const: xgp2 - const: xgp3 - mediatek,sgmiisys: - minItems: 2 - maxItems: 2 - patternProperties: "^mac@[0-1]$": type: object diff --git a/Documentation/devicetree/bindings/net/stm32-dwmac.yaml b/Documentation/devicetree/bindings/net/stm32-dwmac.yaml index fc8c96b08d7d..f2714b5b6cf4 100644 --- a/Documentation/devicetree/bindings/net/stm32-dwmac.yaml +++ b/Documentation/devicetree/bindings/net/stm32-dwmac.yaml @@ -93,6 +93,10 @@ properties: select RCC clock instead of ETH_REF_CLK. type: boolean + access-controllers: + minItems: 1 + maxItems: 2 + required: - compatible - clocks diff --git a/Documentation/devicetree/bindings/phy/phy-stm32-usbphyc.yaml b/Documentation/devicetree/bindings/phy/phy-stm32-usbphyc.yaml index 24a3dbde223b..ceea122ae1a6 100644 --- a/Documentation/devicetree/bindings/phy/phy-stm32-usbphyc.yaml +++ b/Documentation/devicetree/bindings/phy/phy-stm32-usbphyc.yaml @@ -55,6 +55,10 @@ properties: description: number of clock cells for ck_usbo_48m consumer const: 0 + access-controllers: + minItems: 1 + maxItems: 2 + # Required child nodes: patternProperties: diff --git a/Documentation/devicetree/bindings/regulator/st,stm32-vrefbuf.yaml b/Documentation/devicetree/bindings/regulator/st,stm32-vrefbuf.yaml index 05f4ad2c7d3a..6ceaffb45dc9 100644 --- a/Documentation/devicetree/bindings/regulator/st,stm32-vrefbuf.yaml +++ b/Documentation/devicetree/bindings/regulator/st,stm32-vrefbuf.yaml @@ -30,6 +30,10 @@ properties: vdda-supply: description: phandle to the vdda input analog voltage. + access-controllers: + minItems: 1 + maxItems: 2 + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/rng/st,stm32-rng.yaml b/Documentation/devicetree/bindings/rng/st,stm32-rng.yaml index 717f6b321f88..340d01d481d1 100644 --- a/Documentation/devicetree/bindings/rng/st,stm32-rng.yaml +++ b/Documentation/devicetree/bindings/rng/st,stm32-rng.yaml @@ -37,6 +37,10 @@ properties: description: If set, the RNG configuration in RNG_CR, RNG_HTCR and RNG_NSCR will be locked. + access-controllers: + minItems: 1 + maxItems: 2 + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/serial/st,stm32-uart.yaml b/Documentation/devicetree/bindings/serial/st,stm32-uart.yaml index 62f97da1b2fd..2ed526139269 100644 --- a/Documentation/devicetree/bindings/serial/st,stm32-uart.yaml +++ b/Documentation/devicetree/bindings/serial/st,stm32-uart.yaml @@ -73,6 +73,10 @@ properties: enum: [1, 2, 4, 8, 12, 14, 16] default: 8 + access-controllers: + minItems: 1 + maxItems: 2 + allOf: - $ref: rs485.yaml# - $ref: serial.yaml# diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,pmic-glink.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,pmic-glink.yaml index 4310bae6c58e..4512390f90f0 100644 --- a/Documentation/devicetree/bindings/soc/qcom/qcom,pmic-glink.yaml +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,pmic-glink.yaml @@ -58,20 +58,6 @@ patternProperties: required: - compatible -allOf: - - if: - not: - properties: - compatible: - contains: - enum: - - qcom,sm8450-pmic-glink - - qcom,sm8550-pmic-glink - - qcom,x1e80100-pmic-glink - then: - properties: - orientation-gpios: false - additionalProperties: false examples: diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,wcnss.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,wcnss.yaml index 74bb92e31554..fd6db0ca98eb 100644 --- a/Documentation/devicetree/bindings/soc/qcom/qcom,wcnss.yaml +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,wcnss.yaml @@ -116,8 +116,8 @@ examples: bluetooth { compatible = "qcom,wcnss-bt"; - /* BD address 00:11:22:33:44:55 */ - local-bd-address = [ 55 44 33 22 11 00 ]; + /* Updated by boot firmware (little-endian order) */ + local-bd-address = [ 00 00 00 00 00 00 ]; }; wifi { diff --git a/Documentation/devicetree/bindings/soc/renesas/renesas,r9a09g057-sys.yaml b/Documentation/devicetree/bindings/soc/renesas/renesas,r9a09g057-sys.yaml new file mode 100644 index 000000000000..ebbf0c9109ce --- /dev/null +++ b/Documentation/devicetree/bindings/soc/renesas/renesas,r9a09g057-sys.yaml @@ -0,0 +1,51 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/soc/renesas/renesas,r9a09g057-sys.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Renesas RZ/V2H(P) System Controller (SYS) + +maintainers: + - Geert Uytterhoeven <geert+renesas@glider.be> + +description: | + The RZ/V2H(P) SYS (System Controller) controls the overall + configuration of the LSI and supports the following functions, + - Trust zone control + - Extend access by specific masters to address beyond 4GB space + - GBETH configuration + - Control of settings and states of SRAM/PCIe/CM33/CA55/CR8/xSPI/ADC/TSU + - LSI version + - WDT stop control + - General registers + +properties: + compatible: + const: renesas,r9a09g057-sys + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + + resets: + maxItems: 1 + +required: + - compatible + - reg + - clocks + - resets + +additionalProperties: false + +examples: + - | + sys: system-controller@10430000 { + compatible = "renesas,r9a09g057-sys"; + reg = <0x10430000 0x10000>; + clocks = <&cpg 1>; + resets = <&cpg 1>; + }; diff --git a/Documentation/devicetree/bindings/soc/renesas/renesas.yaml b/Documentation/devicetree/bindings/soc/renesas/renesas.yaml index c1ce4da2dc32..09d3ce97efa2 100644 --- a/Documentation/devicetree/bindings/soc/renesas/renesas.yaml +++ b/Documentation/devicetree/bindings/soc/renesas/renesas.yaml @@ -513,6 +513,14 @@ properties: - renesas,rzv2mevk2 # RZ/V2M Eval Board v2.0 - const: renesas,r9a09g011 + - description: RZ/V2H(P) (R9A09G057) + items: + - enum: + - renesas,r9a09g057h41 # RZ/V2H + - renesas,r9a09g057h42 # RZ/V2H with Mali-G31 support + - renesas,r9a09g057h44 # RZ/V2HP with Mali-G31 + Mali-C55 support + - const: renesas,r9a09g057 + additionalProperties: true ... diff --git a/Documentation/devicetree/bindings/soc/samsung/samsung,exynos-sysreg.yaml b/Documentation/devicetree/bindings/soc/samsung/samsung,exynos-sysreg.yaml index c0c6ce8fc786..3ca220582897 100644 --- a/Documentation/devicetree/bindings/soc/samsung/samsung,exynos-sysreg.yaml +++ b/Documentation/devicetree/bindings/soc/samsung/samsung,exynos-sysreg.yaml @@ -15,6 +15,7 @@ properties: - items: - enum: - google,gs101-apm-sysreg + - google,gs101-hsi2-sysreg - google,gs101-peric0-sysreg - google,gs101-peric1-sysreg - samsung,exynos3-sysreg @@ -72,6 +73,7 @@ allOf: compatible: contains: enum: + - google,gs101-hsi2-sysreg - google,gs101-peric0-sysreg - google,gs101-peric1-sysreg - samsung,exynos850-cmgp-sysreg diff --git a/Documentation/devicetree/bindings/sound/st,stm32-i2s.yaml b/Documentation/devicetree/bindings/sound/st,stm32-i2s.yaml index b9111d375b93..8978f6bd63e5 100644 --- a/Documentation/devicetree/bindings/sound/st,stm32-i2s.yaml +++ b/Documentation/devicetree/bindings/sound/st,stm32-i2s.yaml @@ -65,6 +65,10 @@ properties: $ref: audio-graph-port.yaml# unevaluatedProperties: false + access-controllers: + minItems: 1 + maxItems: 2 + required: - compatible - "#sound-dai-cells" diff --git a/Documentation/devicetree/bindings/sound/st,stm32-sai.yaml b/Documentation/devicetree/bindings/sound/st,stm32-sai.yaml index 59df8a832310..b46a4778807d 100644 --- a/Documentation/devicetree/bindings/sound/st,stm32-sai.yaml +++ b/Documentation/devicetree/bindings/sound/st,stm32-sai.yaml @@ -48,6 +48,10 @@ properties: clock-names: maxItems: 3 + access-controllers: + minItems: 1 + maxItems: 2 + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/sound/st,stm32-spdifrx.yaml b/Documentation/devicetree/bindings/sound/st,stm32-spdifrx.yaml index bc48151b9adb..3dedc81ec12f 100644 --- a/Documentation/devicetree/bindings/sound/st,stm32-spdifrx.yaml +++ b/Documentation/devicetree/bindings/sound/st,stm32-spdifrx.yaml @@ -50,6 +50,10 @@ properties: resets: maxItems: 1 + access-controllers: + minItems: 1 + maxItems: 2 + required: - compatible - "#sound-dai-cells" diff --git a/Documentation/devicetree/bindings/spi/st,stm32-qspi.yaml b/Documentation/devicetree/bindings/spi/st,stm32-qspi.yaml index 8bba965a9ae6..3f1a27efff80 100644 --- a/Documentation/devicetree/bindings/spi/st,stm32-qspi.yaml +++ b/Documentation/devicetree/bindings/spi/st,stm32-qspi.yaml @@ -46,6 +46,10 @@ properties: - const: tx - const: rx + access-controllers: + minItems: 1 + maxItems: 2 + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/spi/st,stm32-spi.yaml b/Documentation/devicetree/bindings/spi/st,stm32-spi.yaml index 4bd9aeb81208..a55c8633c32c 100644 --- a/Documentation/devicetree/bindings/spi/st,stm32-spi.yaml +++ b/Documentation/devicetree/bindings/spi/st,stm32-spi.yaml @@ -52,6 +52,10 @@ properties: - const: rx - const: tx + access-controllers: + minItems: 1 + maxItems: 2 + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/tpm/tcg,tpm-tis-i2c.yaml b/Documentation/devicetree/bindings/tpm/tcg,tpm-tis-i2c.yaml index 3ab4434b7352..af7720dc4a12 100644 --- a/Documentation/devicetree/bindings/tpm/tcg,tpm-tis-i2c.yaml +++ b/Documentation/devicetree/bindings/tpm/tcg,tpm-tis-i2c.yaml @@ -32,6 +32,7 @@ properties: - enum: - infineon,slb9673 - nuvoton,npct75x + - st,st33ktpm2xi2c - const: tcg,tpm-tis-i2c - description: TPM 1.2 and 2.0 chips with vendor-specific I²C interface diff --git a/Documentation/devicetree/bindings/usb/dwc2.yaml b/Documentation/devicetree/bindings/usb/dwc2.yaml index 0a5c98ea711d..88c077673c8b 100644 --- a/Documentation/devicetree/bindings/usb/dwc2.yaml +++ b/Documentation/devicetree/bindings/usb/dwc2.yaml @@ -172,6 +172,10 @@ properties: tpl-support: true + access-controllers: + minItems: 1 + maxItems: 2 + dependencies: port: [ usb-role-switch ] role-switch-default-mode: [ usb-role-switch ] diff --git a/Documentation/devicetree/bindings/usb/fsl,usbmisc.yaml b/Documentation/devicetree/bindings/usb/fsl,usbmisc.yaml index 2d3589d284b2..0a6e7ac1b37e 100644 --- a/Documentation/devicetree/bindings/usb/fsl,usbmisc.yaml +++ b/Documentation/devicetree/bindings/usb/fsl,usbmisc.yaml @@ -33,6 +33,7 @@ properties: - fsl,imx7ulp-usbmisc - fsl,imx8mm-usbmisc - fsl,imx8mn-usbmisc + - fsl,imx8ulp-usbmisc - const: fsl,imx7d-usbmisc - const: fsl,imx6q-usbmisc - items: diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index b97d298b3eb6..460c729f6e30 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -151,6 +151,8 @@ patternProperties: description: ARM Ltd. "^armadeus,.*": description: ARMadeus Systems SARL + "^armsom,.*": + description: ArmSoM Technology Co., Ltd. "^arrow,.*": description: Arrow Electronics "^artesyn,.*": @@ -438,6 +440,8 @@ patternProperties: description: Dongguan EmbedFire Electronic Technology Co., Ltd. "^embest,.*": description: Shenzhen Embest Technology Co., Ltd. + "^emcraft,.*": + description: Emcraft Systems "^emlid,.*": description: Emlid, Ltd. "^emmicro,.*": @@ -1627,6 +1631,8 @@ patternProperties: description: Wondermedia Technologies, Inc. "^wobo,.*": description: Wobo + "^wolfvision,.*": + description: WolfVision GmbH "^x-powers,.*": description: X-Powers "^xen,.*": diff --git a/Documentation/driver-api/eisa.rst b/Documentation/driver-api/eisa.rst index 3eac11b7eb01..b33ebe1ec9ed 100644 --- a/Documentation/driver-api/eisa.rst +++ b/Documentation/driver-api/eisa.rst @@ -196,8 +196,8 @@ eisa_bus.disable_dev virtual_root.force_probe Force the probing code to probe EISA slots even when it cannot find an EISA compliant mainboard (nothing appears on slot 0). Defaults to 0 - (don't force), and set to 1 (force probing) when either - CONFIG_ALPHA_JENSEN or CONFIG_EISA_VLB_PRIMING are set. + (don't force), and set to 1 (force probing) when + CONFIG_EISA_VLB_PRIMING is set. Random notes ============ diff --git a/Documentation/litmus-tests/README b/Documentation/litmus-tests/README index 658d37860d39..6c666f3422ea 100644 --- a/Documentation/litmus-tests/README +++ b/Documentation/litmus-tests/README @@ -21,6 +21,51 @@ Atomic-RMW-ops-are-atomic-WRT-atomic_set.litmus Test that atomic_set() cannot break the atomicity of atomic RMWs. NOTE: Require herd7 7.56 or later which supports "(void)expr". +cmpxchg-fail-ordered-1.litmus + Demonstrate that a failing cmpxchg() operation acts as a full barrier + when followed by smp_mb__after_atomic(). + +cmpxchg-fail-ordered-2.litmus + Demonstrate that a failing cmpxchg() operation acts as an acquire + operation when followed by smp_mb__after_atomic(). + +cmpxchg-fail-unordered-1.litmus + Demonstrate that a failing cmpxchg() operation does not act as a + full barrier. + +cmpxchg-fail-unordered-2.litmus + Demonstrate that a failing cmpxchg() operation does not act as an + acquire operation. + + +locking (/locking directory) +---------------------------- + +DCL-broken.litmus + Demonstrates that double-checked locking needs more than just + the obvious lock acquisitions and releases. + +DCL-fixed.litmus + Demonstrates corrected double-checked locking that uses + smp_store_release() and smp_load_acquire() in addition to the + obvious lock acquisitions and releases. + +RM-broken.litmus + Demonstrates problems with "roach motel" locking, where code is + freely moved into lock-based critical sections. This example also + shows how to use the "filter" clause to discard executions that + would be excluded by other code not modeled in the litmus test. + Note also that this "roach motel" optimization is emulated by + physically moving P1()'s two reads from x under the lock. + + What is a roach motel? This is from an old advertisement for + a cockroach trap, much later featured in one of the "Men in + Black" movies. "The roaches check in. They don't check out." + +RM-fixed.litmus + The counterpart to RM-broken.litmus, showing P0()'s two loads from + x safely outside of the critical section. + RCU (/rcu directory) -------------------- diff --git a/Documentation/litmus-tests/atomic/cmpxchg-fail-ordered-1.litmus b/Documentation/litmus-tests/atomic/cmpxchg-fail-ordered-1.litmus new file mode 100644 index 000000000000..c0f93dc07105 --- /dev/null +++ b/Documentation/litmus-tests/atomic/cmpxchg-fail-ordered-1.litmus @@ -0,0 +1,35 @@ +C cmpxchg-fail-ordered-1 + +(* + * Result: Never + * + * Demonstrate that a failing cmpxchg() operation will act as a full + * barrier when followed by smp_mb__after_atomic(). + *) + +{} + +P0(int *x, int *y, int *z) +{ + int r0; + int r1; + + WRITE_ONCE(*x, 1); + r1 = cmpxchg(z, 1, 0); + smp_mb__after_atomic(); + r0 = READ_ONCE(*y); +} + +P1(int *x, int *y, int *z) +{ + int r0; + int r1; + + WRITE_ONCE(*y, 1); + r1 = cmpxchg(z, 1, 0); + smp_mb__after_atomic(); + r0 = READ_ONCE(*x); +} + +locations[0:r1;1:r1] +exists (0:r0=0 /\ 1:r0=0) diff --git a/Documentation/litmus-tests/atomic/cmpxchg-fail-ordered-2.litmus b/Documentation/litmus-tests/atomic/cmpxchg-fail-ordered-2.litmus new file mode 100644 index 000000000000..5c06054f4694 --- /dev/null +++ b/Documentation/litmus-tests/atomic/cmpxchg-fail-ordered-2.litmus @@ -0,0 +1,30 @@ +C cmpxchg-fail-ordered-2 + +(* + * Result: Never + * + * Demonstrate use of smp_mb__after_atomic() to make a failing cmpxchg + * operation have acquire ordering. + *) + +{} + +P0(int *x, int *y) +{ + int r1; + + WRITE_ONCE(*x, 1); + r1 = cmpxchg(y, 0, 1); +} + +P1(int *x, int *y) +{ + int r1; + int r2; + + r1 = cmpxchg(y, 0, 1); + smp_mb__after_atomic(); + r2 = READ_ONCE(*x); +} + +exists (0:r1=0 /\ 1:r1=1 /\ 1:r2=0) diff --git a/Documentation/litmus-tests/atomic/cmpxchg-fail-unordered-1.litmus b/Documentation/litmus-tests/atomic/cmpxchg-fail-unordered-1.litmus new file mode 100644 index 000000000000..39ea1f56a28d --- /dev/null +++ b/Documentation/litmus-tests/atomic/cmpxchg-fail-unordered-1.litmus @@ -0,0 +1,34 @@ +C cmpxchg-fail-unordered-1 + +(* + * Result: Sometimes + * + * Demonstrate that a failing cmpxchg() operation does not act as a + * full barrier. (In contrast, a successful cmpxchg() does act as a + * full barrier.) + *) + +{} + +P0(int *x, int *y, int *z) +{ + int r0; + int r1; + + WRITE_ONCE(*x, 1); + r1 = cmpxchg(z, 1, 0); + r0 = READ_ONCE(*y); +} + +P1(int *x, int *y, int *z) +{ + int r0; + int r1; + + WRITE_ONCE(*y, 1); + r1 = cmpxchg(z, 1, 0); + r0 = READ_ONCE(*x); +} + +locations[0:r1;1:r1] +exists (0:r0=0 /\ 1:r0=0) diff --git a/Documentation/litmus-tests/atomic/cmpxchg-fail-unordered-2.litmus b/Documentation/litmus-tests/atomic/cmpxchg-fail-unordered-2.litmus new file mode 100644 index 000000000000..61aab24a4a64 --- /dev/null +++ b/Documentation/litmus-tests/atomic/cmpxchg-fail-unordered-2.litmus @@ -0,0 +1,30 @@ +C cmpxchg-fail-unordered-2 + +(* + * Result: Sometimes + * + * Demonstrate that a failing cmpxchg() operation does not act as either + * an acquire release operation. (In contrast, a successful cmpxchg() + * does act as both an acquire and a release operation.) + *) + +{} + +P0(int *x, int *y) +{ + int r1; + + WRITE_ONCE(*x, 1); + r1 = cmpxchg(y, 0, 1); +} + +P1(int *x, int *y) +{ + int r1; + int r2; + + r1 = cmpxchg(y, 0, 1); + r2 = READ_ONCE(*x); +} + +exists (0:r1=0 /\ 1:r1=1 /\ 1:r2=0) diff --git a/Documentation/netlink/specs/rt_link.yaml b/Documentation/netlink/specs/rt_link.yaml index 8e4d19adee8c..4e702ac8bf66 100644 --- a/Documentation/netlink/specs/rt_link.yaml +++ b/Documentation/netlink/specs/rt_link.yaml @@ -1144,6 +1144,12 @@ attribute-sets: - name: mcast-querier-state type: binary + - + name: fdb-n-learned + type: u32 + - + name: fdb-max-learned + type: u32 - name: linkinfo-brport-attrs name-prefix: ifla-brport- diff --git a/Documentation/security/keys/trusted-encrypted.rst b/Documentation/security/keys/trusted-encrypted.rst index e989b9802f92..f4d7e162d5e4 100644 --- a/Documentation/security/keys/trusted-encrypted.rst +++ b/Documentation/security/keys/trusted-encrypted.rst @@ -42,6 +42,14 @@ safe. randomly generated and fused into each SoC at manufacturing time. Otherwise, a common fixed test key is used instead. + (4) DCP (Data Co-Processor: crypto accelerator of various i.MX SoCs) + + Rooted to a one-time programmable key (OTP) that is generally burnt + in the on-chip fuses and is accessible to the DCP encryption engine only. + DCP provides two keys that can be used as root of trust: the OTP key + and the UNIQUE key. Default is to use the UNIQUE key, but selecting + the OTP key can be done via a module parameter (dcp_use_otp_key). + * Execution isolation (1) TPM @@ -57,6 +65,12 @@ safe. Fixed set of operations running in isolated execution environment. + (4) DCP + + Fixed set of cryptographic operations running in isolated execution + environment. Only basic blob key encryption is executed there. + The actual key sealing/unsealing is done on main processor/kernel space. + * Optional binding to platform integrity state (1) TPM @@ -79,6 +93,11 @@ safe. Relies on the High Assurance Boot (HAB) mechanism of NXP SoCs for platform integrity. + (4) DCP + + Relies on Secure/Trusted boot process (called HAB by vendor) for + platform integrity. + * Interfaces and APIs (1) TPM @@ -94,6 +113,11 @@ safe. Interface is specific to silicon vendor. + (4) DCP + + Vendor-specific API that is implemented as part of the DCP crypto driver in + ``drivers/crypto/mxs-dcp.c``. + * Threat model The strength and appropriateness of a particular trust source for a given @@ -129,6 +153,13 @@ selected trust source: CAAM HWRNG, enable CRYPTO_DEV_FSL_CAAM_RNG_API and ensure the device is probed. + * DCP (Data Co-Processor: crypto accelerator of various i.MX SoCs) + + The DCP hardware device itself does not provide a dedicated RNG interface, + so the kernel default RNG is used. SoCs with DCP like the i.MX6ULL do have + a dedicated hardware RNG that is independent from DCP which can be enabled + to back the kernel RNG. + Users may override this by specifying ``trusted.rng=kernel`` on the kernel command-line to override the used RNG with the kernel's random number pool. @@ -231,6 +262,19 @@ Usage:: CAAM-specific format. The key length for new keys is always in bytes. Trusted Keys can be 32 - 128 bytes (256 - 1024 bits). +Trusted Keys usage: DCP +----------------------- + +Usage:: + + keyctl add trusted name "new keylen" ring + keyctl add trusted name "load hex_blob" ring + keyctl print keyid + +"keyctl print" returns an ASCII hex copy of the sealed key, which is in format +specific to this DCP key-blob implementation. The key length for new keys is +always in bytes. Trusted Keys can be 32 - 128 bytes (256 - 1024 bits). + Encrypted Keys usage -------------------- @@ -426,3 +470,12 @@ string length. privkey is the binary representation of TPM2B_PUBLIC excluding the initial TPM2B header which can be reconstructed from the ASN.1 octed string length. + +DCP Blob Format +--------------- + +.. kernel-doc:: security/keys/trusted-keys/trusted_dcp.c + :doc: dcp blob format + +.. kernel-doc:: security/keys/trusted-keys/trusted_dcp.c + :identifiers: struct dcp_blob_fmt diff --git a/Documentation/security/tpm/index.rst b/Documentation/security/tpm/index.rst index fc40e9f23c85..fa593d960040 100644 --- a/Documentation/security/tpm/index.rst +++ b/Documentation/security/tpm/index.rst @@ -5,6 +5,8 @@ Trusted Platform Module documentation .. toctree:: tpm_event_log + tpm-security + tpm_tis tpm_vtpm_proxy xen-tpmfront tpm_ftpm_tee diff --git a/Documentation/security/tpm/tpm-security.rst b/Documentation/security/tpm/tpm-security.rst new file mode 100644 index 000000000000..4f633f251033 --- /dev/null +++ b/Documentation/security/tpm/tpm-security.rst @@ -0,0 +1,216 @@ +.. SPDX-License-Identifier: GPL-2.0-only + +TPM Security +============ + +The object of this document is to describe how we make the kernel's +use of the TPM reasonably robust in the face of external snooping and +packet alteration attacks (called passive and active interposer attack +in the literature). The current security document is for TPM 2.0. + +Introduction +------------ + +The TPM is usually a discrete chip attached to a PC via some type of +low bandwidth bus. There are exceptions to this such as the Intel +PTT, which is a software TPM running inside a software environment +close to the CPU, which are subject to different attacks, but right at +the moment, most hardened security environments require a discrete +hardware TPM, which is the use case discussed here. + +Snooping and Alteration Attacks against the bus +----------------------------------------------- + +The current state of the art for snooping the `TPM Genie`_ hardware +interposer which is a simple external device that can be installed in +a couple of seconds on any system or laptop. Recently attacks were +successfully demonstrated against the `Windows Bitlocker TPM`_ system. +Most recently the same `attack against TPM based Linux disk +encryption`_ schemes. The next phase of research seems to be hacking +existing devices on the bus to act as interposers, so the fact that +the attacker requires physical access for a few seconds might +evaporate. However, the goal of this document is to protect TPM +secrets and integrity as far as we are able in this environment and to +try to insure that if we can't prevent the attack then at least we can +detect it. + +Unfortunately, most of the TPM functionality, including the hardware +reset capability can be controlled by an attacker who has access to +the bus, so we'll discuss some of the disruption possibilities below. + +Measurement (PCR) Integrity +--------------------------- + +Since the attacker can send their own commands to the TPM, they can +send arbitrary PCR extends and thus disrupt the measurement system, +which would be an annoying denial of service attack. However, there +are two, more serious, classes of attack aimed at entities sealed to +trust measurements. + +1. The attacker could intercept all PCR extends coming from the system + and completely substitute their own values, producing a replay of + an untampered state that would cause PCR measurements to attest to + a trusted state and release secrets + +2. At some point in time the attacker could reset the TPM, clearing + the PCRs and then send down their own measurements which would + effectively overwrite the boot time measurements the TPM has + already done. + +The first can be thwarted by always doing HMAC protection of the PCR +extend and read command meaning measurement values cannot be +substituted without producing a detectable HMAC failure in the +response. However, the second can only really be detected by relying +on some sort of mechanism for protection which would change over TPM +reset. + +Secrets Guarding +---------------- + +Certain information passing in and out of the TPM, such as key sealing +and private key import and random number generation, is vulnerable to +interception which HMAC protection alone cannot protect against, so +for these types of command we must also employ request and response +encryption to prevent the loss of secret information. + +Establishing Initial Trust with the TPM +--------------------------------------- + +In order to provide security from the beginning, an initial shared or +asymmetric secret must be established which must also be unknown to +the attacker. The most obvious avenues for this are the endorsement +and storage seeds, which can be used to derive asymmetric keys. +However, using these keys is difficult because the only way to pass +them into the kernel would be on the command line, which requires +extensive support in the boot system, and there's no guarantee that +either hierarchy would not have some type of authorization. + +The mechanism chosen for the Linux Kernel is to derive the primary +elliptic curve key from the null seed using the standard storage seed +parameters. The null seed has two advantages: firstly the hierarchy +physically cannot have an authorization, so we are always able to use +it and secondly, the null seed changes across TPM resets, meaning if +we establish trust on the null seed at start of day, all sessions +salted with the derived key will fail if the TPM is reset and the seed +changes. + +Obviously using the null seed without any other prior shared secrets, +we have to create and read the initial public key which could, of +course, be intercepted and substituted by the bus interposer. +However, the TPM has a key certification mechanism (using the EK +endorsement certificate, creating an attestation identity key and +certifying the null seed primary with that key) which is too complex +to run within the kernel, so we keep a copy of the null primary key +name, which is what is exported via sysfs so user-space can run the +full certification when it boots. The definitive guarantee here is +that if the null primary key certifies correctly, you know all your +TPM transactions since start of day were secure and if it doesn't, you +know there's an interposer on your system (and that any secret used +during boot may have been leaked). + +Stacking Trust +-------------- + +In the current null primary scenario, the TPM must be completely +cleared before handing it on to the next consumer. However the kernel +hands to user-space the name of the derived null seed key which can +then be verified by certification in user-space. Therefore, this chain +of name handoff can be used between the various boot components as +well (via an unspecified mechanism). For instance, grub could use the +null seed scheme for security and hand the name off to the kernel in +the boot area. The kernel could make its own derivation of the key +and the name and know definitively that if they differ from the handed +off version that tampering has occurred. Thus it becomes possible to +chain arbitrary boot components together (UEFI to grub to kernel) via +the name handoff provided each successive component knows how to +collect the name and verifies it against its derived key. + +Session Properties +------------------ + +All TPM commands the kernel uses allow sessions. HMAC sessions may be +used to check the integrity of requests and responses and decrypt and +encrypt flags may be used to shield parameters and responses. The +HMAC and encryption keys are usually derived from the shared +authorization secret, but for a lot of kernel operations that is well +known (and usually empty). Thus, every HMAC session used by the +kernel must be created using the null primary key as the salt key +which thus provides a cryptographic input into the session key +derivation. Thus, the kernel creates the null primary key once (as a +volatile TPM handle) and keeps it around in a saved context stored in +tpm_chip for every in-kernel use of the TPM. Currently, because of a +lack of de-gapping in the in-kernel resource manager, the session must +be created and destroyed for each operation, but, in future, a single +session may also be reused for the in-kernel HMAC, encryption and +decryption sessions. + +Protection Types +---------------- + +For every in-kernel operation we use null primary salted HMAC to +protect the integrity. Additionally, we use parameter encryption to +protect key sealing and parameter decryption to protect key unsealing +and random number generation. + +Null Primary Key Certification in Userspace +=========================================== + +Every TPM comes shipped with a couple of X.509 certificates for the +primary endorsement key. This document assumes that the Elliptic +Curve version of the certificate exists at 01C00002, but will work +equally well with the RSA certificate (at 01C00001). + +The first step in the certification is primary creation using the +template from the `TCG EK Credential Profile`_ which allows comparison +of the generated primary key against the one in the certificate (the +public key must match). Note that generation of the EK primary +requires the EK hierarchy password, but a pre-generated version of the +EC primary should exist at 81010002 and a TPM2_ReadPublic() may be +performed on this without needing the key authority. Next, the +certificate itself must be verified to chain back to the manufacturer +root (which should be published on the manufacturer website). Once +this is done, an attestation key (AK) is generated within the TPM and +it's name and the EK public key can be used to encrypt a secret using +TPM2_MakeCredential. The TPM then runs TPM2_ActivateCredential which +will only recover the secret if the binding between the TPM, the EK +and the AK is true. the generated AK may now be used to run a +certification of the null primary key whose name the kernel has +exported. Since TPM2_MakeCredential/ActivateCredential are somewhat +complicated, a more simplified process involving an externally +generated private key is described below. + +This process is a simplified abbreviation of the usual privacy CA +based attestation process. The assumption here is that the +attestation is done by the TPM owner who thus has access to only the +owner hierarchy. The owner creates an external public/private key +pair (assume elliptic curve in this case) and wraps the private key +for import using an inner wrapping process and parented to the EC +derived storage primary. The TPM2_Import() is done using a parameter +decryption HMAC session salted to the EK primary (which also does not +require the EK key authority) meaning that the inner wrapping key is +the encrypted parameter and thus the TPM will not be able to perform +the import unless is possesses the certified EK so if the command +succeeds and the HMAC verifies on return we know we have a loadable +copy of the private key only for the certified TPM. This key is now +loaded into the TPM and the Storage primary flushed (to free up space +for the null key generation). + +The null EC primary is now generated using the Storage profile +outlined in the `TCG TPM v2.0 Provisioning Guidance`_; the name of +this key (the hash of the public area) is computed and compared to the +null seed name presented by the kernel in +/sys/class/tpm/tpm0/null_name. If the names do not match, the TPM is +compromised. If the names match, the user performs a TPM2_Certify() +using the null primary as the object handle and the loaded private key +as the sign handle and providing randomized qualifying data. The +signature of the returned certifyInfo is verified against the public +part of the loaded private key and the qualifying data checked to +prevent replay. If all of these tests pass, the user is now assured +that TPM integrity and privacy was preserved across the entire boot +sequence of this kernel. + +.. _TPM Genie: https://www.nccgroup.trust/globalassets/about-us/us/documents/tpm-genie.pdf +.. _Windows Bitlocker TPM: https://dolosgroup.io/blog/2021/7/9/from-stolen-laptop-to-inside-the-company-network +.. _attack against TPM based Linux disk encryption: https://www.secura.com/blog/tpm-sniffing-attacks-against-non-bitlocker-targets +.. _TCG EK Credential Profile: https://trustedcomputinggroup.org/resource/tcg-ek-credential-profile-for-tpm-family-2-0/ +.. _TCG TPM v2.0 Provisioning Guidance: https://trustedcomputinggroup.org/resource/tcg-tpm-v2-0-provisioning-guidance/ diff --git a/Documentation/security/tpm/tpm_tis.rst b/Documentation/security/tpm/tpm_tis.rst new file mode 100644 index 000000000000..b9637f295638 --- /dev/null +++ b/Documentation/security/tpm/tpm_tis.rst @@ -0,0 +1,46 @@ +.. SPDX-License-Identifier: GPL-2.0 + +========================= +TPM FIFO interface driver +========================= + +TCG PTP Specification defines two interface types: FIFO and CRB. The former is +based on sequenced read and write operations, and the latter is based on a +buffer containing the full command or response. + +FIFO (First-In-First-Out) interface is used by the tpm_tis_core dependent +drivers. Originally Linux had only a driver called tpm_tis, which covered +memory mapped (aka MMIO) interface but it was later on extended to cover other +physical interfaces supported by the TCG standard. + +For historical reasons above the original MMIO driver is called tpm_tis and the +framework for FIFO drivers is named as tpm_tis_core. The postfix "tis" in +tpm_tis comes from the TPM Interface Specification, which is the hardware +interface specification for TPM 1.x chips. + +Communication is based on a 20 KiB buffer shared by the TPM chip through a +hardware bus or memory map, depending on the physical wiring. The buffer is +further split into five equal-size 4 KiB buffers, which provide equivalent +sets of registers for communication between the CPU and TPM. These +communication endpoints are called localities in the TCG terminology. + +When the kernel wants to send commands to the TPM chip, it first reserves +locality 0 by setting the requestUse bit in the TPM_ACCESS register. The bit is +cleared by the chip when the access is granted. Once it completes its +communication, the kernel writes the TPM_ACCESS.activeLocality bit. This +informs the chip that the locality has been relinquished. + +Pending localities are served in order by the chip in descending order, one at +a time: + +- Locality 0 has the lowest priority. +- Locality 5 has the highest priority. + +Further information on the purpose and meaning of the localities can be found +in section 3.2 of the TCG PC Client Platform TPM Profile Specification. + +References +========== + +TCG PC Client Platform TPM Profile (PTP) Specification +https://trustedcomputinggroup.org/resource/pc-client-platform-tpm-profile-ptp-specification/ diff --git a/Documentation/tee/index.rst b/Documentation/tee/index.rst index a23bd08847e5..4be6e69d7837 100644 --- a/Documentation/tee/index.rst +++ b/Documentation/tee/index.rst @@ -10,6 +10,7 @@ TEE Subsystem tee op-tee amd-tee + ts-tee .. only:: subproject and html diff --git a/Documentation/tee/ts-tee.rst b/Documentation/tee/ts-tee.rst new file mode 100644 index 000000000000..843e34422648 --- /dev/null +++ b/Documentation/tee/ts-tee.rst @@ -0,0 +1,71 @@ +.. SPDX-License-Identifier: GPL-2.0 + +================================= +TS-TEE (Trusted Services project) +================================= + +This driver provides access to secure services implemented by Trusted Services. + +Trusted Services [1] is a TrustedFirmware.org project that provides a framework +for developing and deploying device Root of Trust services in FF-A [2] S-EL0 +Secure Partitions. The project hosts the reference implementation of the Arm +Platform Security Architecture [3] for Arm A-profile devices. + +The FF-A Secure Partitions (SP) are accessible through the FF-A driver [4] which +provides the low level communication for this driver. On top of that the Trusted +Services RPC protocol is used [5]. To use the driver from user space a reference +implementation is provided at [6], which is part of the Trusted Services client +library called libts [7]. + +All Trusted Services (TS) SPs have the same FF-A UUID; it identifies the TS RPC +protocol. A TS SP can host one or more services (e.g. PSA Crypto, PSA ITS, etc). +A service is identified by its service UUID; the same type of service cannot be +present twice in the same SP. During SP boot each service in the SP is assigned +an "interface ID". This is just a short ID to simplify message addressing. + +The generic TEE design is to share memory at once with the Trusted OS, which can +then be reused to communicate with multiple applications running on the Trusted +OS. However, in case of FF-A, memory sharing works on an endpoint level, i.e. +memory is shared with a specific SP. User space has to be able to separately +share memory with each SP based on its endpoint ID; therefore a separate TEE +device is registered for each discovered TS SP. Opening the SP corresponds to +opening the TEE device and creating a TEE context. A TS SP hosts one or more +services. Opening a service corresponds to opening a session in the given +tee_context. + +Overview of a system with Trusted Services components:: + + User space Kernel space Secure world + ~~~~~~~~~~ ~~~~~~~~~~~~ ~~~~~~~~~~~~ + +--------+ +-------------+ + | Client | | Trusted | + +--------+ | Services SP | + /\ +-------------+ + || /\ + || || + || || + \/ \/ + +-------+ +----------+--------+ +-------------+ + | libts | | TEE | TS-TEE | | FF-A SPMC | + | | | subsys | driver | | + SPMD | + +-------+----------------+----+-----+--------+-----------+-------------+ + | Generic TEE API | | FF-A | TS RPC protocol | + | IOCTL (TEE_IOC_*) | | driver | over FF-A | + +-----------------------------+ +--------+-------------------------+ + +References +========== + +[1] https://www.trustedfirmware.org/projects/trusted-services/ + +[2] https://developer.arm.com/documentation/den0077/ + +[3] https://www.arm.com/architecture/security-features/platform-security + +[4] drivers/firmware/arm_ffa/ + +[5] https://trusted-services.readthedocs.io/en/v1.0.0/developer/service-access-protocols.html#abi + +[6] https://git.trustedfirmware.org/TS/trusted-services.git/tree/components/rpc/ts_rpc/caller/linux/ts_rpc_caller_linux.c?h=v1.0.0 + +[7] https://git.trustedfirmware.org/TS/trusted-services.git/tree/deployments/libts/arm-linux/CMakeLists.txt?h=v1.0.0 |