tobetter · ginkage · Feb 23, 2022 · Feb 23, 2022 · Feb 23, 2022 · Feb 23, 2022
diff --git a/.mailmap b/.mailmap
@@ -74,6 +74,9 @@ Chris Chiu <chris.chiu@canonical.com> <chiu@endlessos.org>
 Christian Borntraeger <borntraeger@linux.ibm.com> <borntraeger@de.ibm.com>
 Christian Borntraeger <borntraeger@linux.ibm.com> <cborntra@de.ibm.com>
 Christian Borntraeger <borntraeger@linux.ibm.com> <borntrae@de.ibm.com>
+Christian Brauner <brauner@kernel.org> <christian@brauner.io>
+Christian Brauner <brauner@kernel.org> <christian.brauner@canonical.com>
+Christian Brauner <brauner@kernel.org> <christian.brauner@ubuntu.com>
 Christophe Ricard <christophe.ricard@gmail.com>
 Christoph Hellwig <hch@lst.de>
 Colin Ian King <colin.king@intel.com> <colin.king@canonical.com>

diff --git a/Documentation/ABI/testing/sysfs-driver-aspeed-uart-routing b/Documentation/ABI/testing/sysfs-driver-aspeed-uart-routing
@@ -1,4 +1,4 @@
-What: /sys/bus/platform/drivers/aspeed-uart-routing/*/uart*
+What: /sys/bus/platform/drivers/aspeed-uart-routing/\*/uart\*
 Date: September 2021
 Contact: Oskar Senft <osk@google.com>
  Chia-Wei Wang <chiawei_wang@aspeedtech.com>
@@ -9,15 +9,15 @@ Description: Selects the RX source of the UARTx device.
  depends on the selected file.
 
  e.g.
- cat /sys/bus/platform/drivers/aspeed-uart-routing/*.uart_routing/uart1
+ cat /sys/bus/platform/drivers/aspeed-uart-routing/\*.uart_routing/uart1
  [io1] io2 io3 io4 uart2 uart3 uart4 io6
 
  In this case, UART1 gets its input from IO1 (physical serial port 1).
 
 Users: OpenBMC. Proposed changes should be mailed to
  openbmc@lists.ozlabs.org
 
-What: /sys/bus/platform/drivers/aspeed-uart-routing/*/io*
+What: /sys/bus/platform/drivers/aspeed-uart-routing/\*/io\*
 Date: September 2021
 Contact: Oskar Senft <osk@google.com>
  Chia-Wei Wang <chiawei_wang@aspeedtech.com>

diff --git a/Documentation/accounting/psi.rst b/Documentation/accounting/psi.rst
@@ -92,7 +92,8 @@ Triggers can be set on more than one psi metric and more than one trigger
 for the same psi metric can be specified. However for each trigger a separate
 file descriptor is required to be able to poll it separately from others,
 therefore for each trigger a separate open() syscall should be made even
-when opening the same psi interface file.
+when opening the same psi interface file. Write operations to a file descriptor
+with an already existing psi trigger will fail with EBUSY.
 
 Monitors activate only when system enters stall state for the monitored
 psi metric and deactivates upon exit from the stall state. While system is

diff --git a/Documentation/admin-guide/cifs/usage.rst b/Documentation/admin-guide/cifs/usage.rst
@@ -734,10 +734,9 @@ SecurityFlags Flags which control security negotiation and
  using weaker password hashes is 0x37037 (lanman,
  plaintext, ntlm, ntlmv2, signing allowed). Some
  SecurityFlags require the corresponding menuconfig
- options to be enabled (lanman and plaintext require
- CONFIG_CIFS_WEAK_PW_HASH for example). Enabling
- plaintext authentication currently requires also
- enabling lanman authentication in the security flags
+ options to be enabled. Enabling plaintext
+ authentication currently requires also enabling
+ lanman authentication in the security flags
  because the cifs module only supports sending
  laintext passwords using the older lanman dialect
  form of the session setup SMB. (e.g. for authentication

diff --git a/Documentation/admin-guide/devices.txt b/Documentation/admin-guide/devices.txt
@@ -2339,13 +2339,7 @@
  disks (see major number 3) except that the limit on
  partitions is 31.
 
- 162 char Raw block device interface
- 0 = /dev/rawctl Raw I/O control device
- 1 = /dev/raw/raw1 First raw I/O device
- 2 = /dev/raw/raw2 Second raw I/O device
- ...
- max minor number of raw device is set by kernel config
- MAX_RAW_DEVS or raw module parameter 'max_raw_devs'
+ 162 char Used for (now removed) raw block device interface
 
  163 char
 

diff --git a/Documentation/admin-guide/hw-vuln/spectre.rst b/Documentation/admin-guide/hw-vuln/spectre.rst
@@ -60,8 +60,8 @@ privileged data touched during the speculative execution.
 Spectre variant 1 attacks take advantage of speculative execution of
 conditional branches, while Spectre variant 2 attacks use speculative
 execution of indirect branches to leak privileged memory.
-See :ref:`[1] <spec_ref1>` :ref:`[5] <spec_ref5>` :ref:`[7] <spec_ref7>`
-:ref:`[10] <spec_ref10>` :ref:`[11] <spec_ref11>`.
+See :ref:`[1] <spec_ref1>` :ref:`[5] <spec_ref5>` :ref:`[6] <spec_ref6>`
+:ref:`[7] <spec_ref7>` :ref:`[10] <spec_ref10>` :ref:`[11] <spec_ref11>`.
 
 Spectre variant 1 (Bounds Check Bypass)
 ---------------------------------------
@@ -131,6 +131,19 @@ steer its indirect branch speculations to gadget code, and measure the
 speculative execution's side effects left in level 1 cache to infer the
 victim's data.
 
+Yet another variant 2 attack vector is for the attacker to poison the
+Branch History Buffer (BHB) to speculatively steer an indirect branch
+to a specific Branch Target Buffer (BTB) entry, even if the entry isn't
+associated with the source address of the indirect branch. Specifically,
+the BHB might be shared across privilege levels even in the presence of
+Enhanced IBRS.
+
+Currently the only known real-world BHB attack vector is via
+unprivileged eBPF. Therefore, it's highly recommended to not enable
+unprivileged eBPF, especially when eIBRS is used (without retpolines).
+For a full mitigation against BHB attacks, it's recommended to use
+retpolines (or eIBRS combined with retpolines).
+
 Attack scenarios
 ----------------
 
@@ -364,13 +377,15 @@ The possible values in this file are:
 
  - Kernel status:
 
- ==================================== =================================
- 'Not affected' The processor is not vulnerable
- 'Vulnerable' Vulnerable, no mitigation
- 'Mitigation: Full generic retpoline' Software-focused mitigation
- 'Mitigation: Full AMD retpoline' AMD-specific software mitigation
- 'Mitigation: Enhanced IBRS' Hardware-focused mitigation
- ==================================== =================================
+ ======================================== =================================
+ 'Not affected' The processor is not vulnerable
+ 'Mitigation: None' Vulnerable, no mitigation
+ 'Mitigation: Retpolines' Use Retpoline thunks
+ 'Mitigation: LFENCE' Use LFENCE instructions
+ 'Mitigation: Enhanced IBRS' Hardware-focused mitigation
+ 'Mitigation: Enhanced IBRS + Retpolines' Hardware-focused + Retpolines
+ 'Mitigation: Enhanced IBRS + LFENCE' Hardware-focused + LFENCE
+ ======================================== =================================
 
  - Firmware status: Show if Indirect Branch Restricted Speculation (IBRS) is
  used to protect against Spectre variant 2 attacks when calling firmware (x86 only).
@@ -468,7 +483,7 @@ Spectre variant 2
  before invoking any firmware code to prevent Spectre variant 2 exploits
  using the firmware.
 
- Using kernel address space randomization (CONFIG_RANDOMIZE_SLAB=y
+ Using kernel address space randomization (CONFIG_RANDOMIZE_BASE=y
  and CONFIG_SLAB_FREELIST_RANDOM=y in the kernel configuration) makes
  attacks on the kernel generally more difficult.
 
@@ -583,12 +598,13 @@ kernel command line.
 
  Specific mitigations can also be selected manually:
 
- retpoline
- replace indirect branches
- retpoline,generic
- google's original retpoline
- retpoline,amd
- AMD-specific minimal thunk
+ retpoline auto pick between generic,lfence
+ retpoline,generic Retpolines
+ retpoline,lfence LFENCE; indirect branch
+ retpoline,amd alias for retpoline,lfence
+ eibrs enhanced IBRS
+ eibrs,retpoline enhanced IBRS + Retpolines
+ eibrs,lfence enhanced IBRS + LFENCE
 
  Not specifying this option is equivalent to
  spectre_v2=auto.
@@ -599,7 +615,7 @@ kernel command line.
  spectre_v2=off. Spectre variant 1 mitigations
  cannot be disabled.
 
-For spectre_v2_user see :doc:`/admin-guide/kernel-parameters`.
+For spectre_v2_user see Documentation/admin-guide/kernel-parameters.txt
 
 Mitigation selection guide
 --------------------------
@@ -681,7 +697,7 @@ AMD white papers:
 
 .. _spec_ref6:
 
-[6] `Software techniques for managing speculation on AMD processors <https://developer.amd.com/wp-content/resources/90343-B_SoftwareTechniquesforManagingSpeculation_WP_7-18Update_FNL.pdf>`_.
+[6] `Software techniques for managing speculation on AMD processors <https://developer.amd.com/wp-content/resources/Managing-Speculation-on-AMD-Processors.pdf>`_.
 
 ARM white papers:
 

diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
@@ -5303,8 +5303,12 @@
  Specific mitigations can also be selected manually:
 
  retpoline - replace indirect branches
- retpoline,generic - google's original retpoline
- retpoline,amd - AMD-specific minimal thunk
+ retpoline,generic - Retpolines
+ retpoline,lfence - LFENCE; indirect branch
+ retpoline,amd - alias for retpoline,lfence
+ eibrs - enhanced IBRS
+ eibrs,retpoline - enhanced IBRS + Retpolines
+ eibrs,lfence - enhanced IBRS + LFENCE
 
  Not specifying this option is equivalent to
  spectre_v2=auto.

diff --git a/Documentation/admin-guide/mm/pagemap.rst b/Documentation/admin-guide/mm/pagemap.rst
@@ -23,7 +23,7 @@ There are four components to pagemap:
  * Bit 56 page exclusively mapped (since 4.2)
  * Bit 57 pte is uffd-wp write-protected (since 5.13) (see
  :ref:`Documentation/admin-guide/mm/userfaultfd.rst <userfaultfd>`)
- * Bits 57-60 zero
+ * Bits 58-60 zero
  * Bit 61 page is file-page or shared-anon (since 3.5)
  * Bit 62 page swapped
  * Bit 63 page present

diff --git a/Documentation/arm64/cpu-feature-registers.rst b/Documentation/arm64/cpu-feature-registers.rst
@@ -275,6 +275,23 @@ infrastructure:
  | SVEVer | [3-0] | y |
  +------------------------------+---------+---------+
 
+ 8) ID_AA64MMFR1_EL1 - Memory model feature register 1
+
+ +------------------------------+---------+---------+
+ | Name | bits | visible |
+ +------------------------------+---------+---------+
+ | AFP | [47-44] | y |
+ +------------------------------+---------+---------+
+
+ 9) ID_AA64ISAR2_EL1 - Instruction set attribute register 2
+
+ +------------------------------+---------+---------+
+ | Name | bits | visible |
+ +------------------------------+---------+---------+
+ | RPRES | [7-4] | y |
+ +------------------------------+---------+---------+
+
+
 Appendix I: Example
 -------------------
 

diff --git a/Documentation/arm64/elf_hwcaps.rst b/Documentation/arm64/elf_hwcaps.rst
@@ -251,6 +251,14 @@ HWCAP2_ECV
 
  Functionality implied by ID_AA64MMFR0_EL1.ECV == 0b0001.
 
+HWCAP2_AFP
+
+ Functionality implied by ID_AA64MFR1_EL1.AFP == 0b0001.
+
+HWCAP2_RPRES
+
+ Functionality implied by ID_AA64ISAR2_EL1.RPRES == 0b0001.
+
 4. Unused AT_HWCAP bits
 -----------------------
 

diff --git a/Documentation/arm64/silicon-errata.rst b/Documentation/arm64/silicon-errata.rst
@@ -52,6 +52,12 @@ stable kernels.
 | Allwinner | A64/R18 | UNKNOWN1 | SUN50I_ERRATUM_UNKNOWN1 |
 +----------------+-----------------+-----------------+-----------------------------+
 +----------------+-----------------+-----------------+-----------------------------+
+| ARM | Cortex-A510 | #2064142 | ARM64_ERRATUM_2064142 |
++----------------+-----------------+-----------------+-----------------------------+
+| ARM | Cortex-A510 | #2038923 | ARM64_ERRATUM_2038923 |
++----------------+-----------------+-----------------+-----------------------------+
+| ARM | Cortex-A510 | #1902691 | ARM64_ERRATUM_1902691 |
++----------------+-----------------+-----------------+-----------------------------+
 | ARM | Cortex-A53 | #826319 | ARM64_ERRATUM_826319 |
 +----------------+-----------------+-----------------+-----------------------------+
 | ARM | Cortex-A53 | #827319 | ARM64_ERRATUM_827319 |
@@ -92,12 +98,20 @@ stable kernels.
 +----------------+-----------------+-----------------+-----------------------------+
 | ARM | Cortex-A77 | #1508412 | ARM64_ERRATUM_1508412 |
 +----------------+-----------------+-----------------+-----------------------------+
+| ARM | Cortex-A510 | #2051678 | ARM64_ERRATUM_2051678 |
++----------------+-----------------+-----------------+-----------------------------+
+| ARM | Cortex-A510 | #2077057 | ARM64_ERRATUM_2077057 |
++----------------+-----------------+-----------------+-----------------------------+
 | ARM | Cortex-A710 | #2119858 | ARM64_ERRATUM_2119858 |
 +----------------+-----------------+-----------------+-----------------------------+
 | ARM | Cortex-A710 | #2054223 | ARM64_ERRATUM_2054223 |
 +----------------+-----------------+-----------------+-----------------------------+
 | ARM | Cortex-A710 | #2224489 | ARM64_ERRATUM_2224489 |
 +----------------+-----------------+-----------------+-----------------------------+
+| ARM | Cortex-X2 | #2119858 | ARM64_ERRATUM_2119858 |
++----------------+-----------------+-----------------+-----------------------------+
+| ARM | Cortex-X2 | #2224489 | ARM64_ERRATUM_2224489 |
++----------------+-----------------+-----------------+-----------------------------+
 | ARM | Neoverse-N1 | #1188873,1418040| ARM64_ERRATUM_1418040 |
 +----------------+-----------------+-----------------+-----------------------------+
 | ARM | Neoverse-N1 | #1349291 | N/A |

diff --git a/Documentation/devicetree/bindings/arm/omap/omap.txt b/Documentation/devicetree/bindings/arm/omap/omap.txt
@@ -119,6 +119,9 @@ Boards (incomplete list of examples):
 - OMAP3 BeagleBoard : Low cost community board
  compatible = "ti,omap3-beagle", "ti,omap3430", "ti,omap3"
 
+- OMAP3 BeagleBoard A to B4 : Early BeagleBoard revisions A to B4 with a timer quirk
+ compatible = "ti,omap3-beagle-ab4", "ti,omap3-beagle", "ti,omap3430", "ti,omap3"
+
 - OMAP3 Tobi with Overo : Commercial expansion board with daughter board
  compatible = "gumstix,omap3-overo-tobi", "gumstix,omap3-overo", "ti,omap3430", "ti,omap3"
 

diff --git a/Documentation/devicetree/bindings/display/amlogic,meson-dw-hdmi.yaml b/Documentation/devicetree/bindings/display/amlogic,meson-dw-hdmi.yaml
@@ -10,6 +10,9 @@ title: Amlogic specific extensions to the Synopsys Designware HDMI Controller
 maintainers:
  - Neil Armstrong <narmstrong@baylibre.com>
 
+allOf:
+ - $ref: /schemas/sound/name-prefix.yaml#
+
 description: |
  The Amlogic Meson Synopsys Designware Integration is composed of
  - A Synopsys DesignWare HDMI Controller IP
@@ -99,6 +102,8 @@ properties:
  "#sound-dai-cells":
  const: 0
 
+ sound-name-prefix: true
+
 required:
  - compatible
  - reg

diff --git a/Documentation/devicetree/bindings/display/amlogic,meson-vpu.yaml b/Documentation/devicetree/bindings/display/amlogic,meson-vpu.yaml
@@ -78,6 +78,10 @@ properties:
  interrupts:
  maxItems: 1
 
+ amlogic,canvas:
+ description: should point to a canvas provider node
+ $ref: /schemas/types.yaml#/definitions/phandle
+
  power-domains:
  maxItems: 1
  description: phandle to the associated power domain
@@ -106,6 +110,7 @@ required:
  - port@1
  - "#address-cells"
  - "#size-cells"
+ - amlogic,canvas
 
 additionalProperties: false
 
@@ -118,6 +123,7 @@ examples:
  interrupts = <3>;
  #address-cells = <1>;
  #size-cells = <0>;
+ amlogic,canvas = <&canvas>;
 
  /* CVBS VDAC output port */
  port@0 {

diff --git a/Documentation/devicetree/bindings/input/hid-over-i2c.txt b/Documentation/devicetree/bindings/input/hid-over-i2c.txt
@@ -32,6 +32,8 @@ device-specific compatible properties, which should be used in addition to the
 - vdd-supply: phandle of the regulator that provides the supply voltage.
 - post-power-on-delay-ms: time required by the device after enabling its regulators
  or powering it on, before it is ready for communication.
+- touchscreen-inverted-x: See touchscreen.txt
+- touchscreen-inverted-y: See touchscreen.txt
 
 Example:
 

diff --git a/Documentation/devicetree/bindings/net/can/tcan4x5x.txt b/Documentation/devicetree/bindings/net/can/tcan4x5x.txt
@@ -31,7 +31,7 @@ tcan4x5x: tcan4x5x@0 {
  #address-cells = <1>;
  #size-cells = <1>;
  spi-max-frequency = <10000000>;
- bosch,mram-cfg = <0x0 0 0 32 0 0 1 1>;
+ bosch,mram-cfg = <0x0 0 0 16 0 0 1 1>;
  interrupt-parent = <&gpio1>;
  interrupts = <14 IRQ_TYPE_LEVEL_LOW>;
  device-state-gpios = <&gpio3 21 GPIO_ACTIVE_HIGH>;

diff --git a/Documentation/devicetree/bindings/pwm/pwm-gpio.txt b/Documentation/devicetree/bindings/pwm/pwm-gpio.txt
@@ -0,0 +1,18 @@
+Generic GPIO bit-banged PWM driver
+
+Required properties:
+ - compatible: should be "pwm-gpio"
+ - #pwm-cells: should be 3, see pwm.txt in this directory for a general
+ description of the cells format.
+ - pwm-gpios: one or more gpios describing the used gpio, see the gpio
+ bindings for the used gpio driver.
+
+Example:
+#include <dt-bindings/gpio/gpio.h>
+
+ pwm: pwm@0 {
+ compatible = "pwm-gpio";
+ #pwm-cells = 3;
+ pwm-gpios = <&pio 7 1 GPIO_ACTIVE_LOW>;
+ pwm-gpios = <&pio 7 2 GPIO_ACTIVE_LOW>;
+ };
diff --git a/Documentation/devicetree/bindings/thermal/thermal-zones.yaml b/Documentation/devicetree/bindings/thermal/thermal-zones.yaml
@@ -199,12 +199,11 @@ patternProperties:
 
  contribution:
  $ref: /schemas/types.yaml#/definitions/uint32
- minimum: 0
- maximum: 100
  description:
- The percentage contribution of the cooling devices at the
- specific trip temperature referenced in this map
- to this thermal zone
+ The cooling contribution to the thermal zone of the referred
+ cooling device at the referred trip point. The contribution is
+ a ratio of the sum of all cooling contributions within a
+ thermal zone.
 
  required:
  - trip

diff --git a/Documentation/devicetree/bindings/watchdog/samsung-wdt.yaml b/Documentation/devicetree/bindings/watchdog/samsung-wdt.yaml
@@ -39,8 +39,8 @@ properties:
  samsung,syscon-phandle:
  $ref: /schemas/types.yaml#/definitions/phandle
  description:
- Phandle to the PMU system controller node (in case of Exynos5250
- and Exynos5420).
+ Phandle to the PMU system controller node (in case of Exynos5250,
+ Exynos5420 and Exynos7).
 
 required:
  - compatible
@@ -58,6 +58,7 @@ allOf:
  enum:
  - samsung,exynos5250-wdt
  - samsung,exynos5420-wdt
+ - samsung,exynos7-wdt
  then:
  required:
  - samsung,syscon-phandle