Fix waking up from deep sleep on InfinityBook Pro Gen7

.gitignore

@@ -161,3 +161,6 @@ x509.genkey
 
 # Documentation toolchain
 sphinx_*/
+
+# Automatic build script
+!/.gitlab-ci.yml

.gitlab-ci.yml

@@ -0,0 +1,126 @@
+default:
+    # Custom docker image: ubuntu:jammy with some stuff preinstalled, see before_script comment.
+    image: linux-builder-ubuntu-jammy
+
+    before_script:
+        # This is already installed on linux-builder-ubuntu-jammy docker image, but manual
+        # installation required on runners that only have ubuntu:jammy available.
+        # - apt-get update
+        # - DEBIAN_FRONTEND=noninteractive apt-get install -y git fakeroot build-essential debhelper devscripts git-buildpackage flex bison dwarves bc cpio kmod gawk zstd dkms rsync kernel-wedge docutils-common default-jdk libssl-dev libelf-dev libudev-dev libpci-dev libiberty-dev libcap-dev ccache libdw-dev systemtap-sdt-dev libunwind-dev libssl-dev libslang2-dev libperl-dev python3-dev liblzma-dev libzstd-dev libnuma-dev libbabeltrace-dev binutils-dev llvm asciidoc
+
+        # Configure git to be able to push.
+        - git config --global user.name "Tuxedo BOT"
+        - git config --global user.email "tux@tuxedocomputers.com"
+        - gpg --import $TUXEDO_BOT_GPG_PRIVATE_KEY
+
+        # Setup author for dch.
+        - export DEBFULLNAME="Tuxedo BOT"
+        - export DEBEMAIL="tux@tuxedocomputers.com"
+
+variables:
+    # Create a fresh clone every time, instead of caching the last checkout of the repository. This
+    # is required for a clean slate the way the auto-update script expects.
+    GIT_STRATEGY: clone
+
+stages:
+    # The update job is not run on the same commit as the build, and deploy jobs. It's included in this
+    # explicit order here purely to make the CI script more readable.
+    - update
+    - build
+    - deploy
+    - notify
+    - sync
+
+update:
+    stage: update
+
+    only:
+        # Don't run on every push, but only manually issued and periodically.
+        - web
+        - schedule
+
+    script:
+        # GitLab CI checks out in a detached head state, correct this to be able to push.
+        - git checkout $CI_COMMIT_BRANCH
+
+        # Run the logic determining the new version, update, and push the result.
+        - ./tuxedo-update-repository auto-update
+
+        # Push using a GitLab Personal Access Token.
+        - git push --force --progress --verbose "https://${TUXEDO_BOT_GITLAB_USERNAME}:${TUXEDO_BOT_GITLAB_CI_PERSONAL_ACCESS_TOKEN}@${CI_REPOSITORY_URL#*@}" $CI_COMMIT_BRANCH
+        - git push --force --progress --verbose "https://${TUXEDO_BOT_GITLAB_USERNAME}:${TUXEDO_BOT_GITLAB_CI_PERSONAL_ACCESS_TOKEN}@${CI_REPOSITORY_URL#*@}" $(git describe --tags --abbrev=0)
+
+build:
+    stage: build
+
+    only:
+        # Build after new tag has been pushed.
+        - tags
+
+    script:
+        # Setup environment and create packages.
+        - LANG=C fakeroot debian/rules clean
+        - LANG=C AUTOBUILD=1 NOEXTRAS=1 fakeroot debian/rules binary
+
+        # Copy results into build directory so that the artifacts keyword can pick them up.
+        - rm -rf output
+        - mkdir output
+        - mv ../*.deb ../*.udeb ../*.tar.gz output || true
+
+    artifacts:
+        # Save build results.
+        paths:
+            - output
+
+deploy:
+    stage: deploy
+
+    only:
+        # Deploy after new tag has been pushed.
+        - tags
+
+    variables:
+        # This job does not need a clean working directory.
+        GIT_STRATEGY: fetch
+
+    script:
+        # Get version number.
+        - CURRENT_VERSION=$(grep -Pom1 '^linux-tuxedo-.*\(\K.*(?=\))' debian.tuxedo-*/changelog)
+
+        # Upload to new folder on internal Nextcould.
+        - curl -X MKCOL $TUXEDO_BOT_WEBDAV_LINUX_22_04_BASE_FOLDER_URL/$CURRENT_VERSION --user $TUXEDO_BOT_NEXTCLOUD_USERNAME:$TUXEDO_BOT_NEXTCLOUD_PASSWORD
+        - find output/* -exec curl -T '{}' $TUXEDO_BOT_WEBDAV_LINUX_22_04_BASE_FOLDER_URL/$CURRENT_VERSION/ --user $TUXEDO_BOT_NEXTCLOUD_USERNAME:$TUXEDO_BOT_NEXTCLOUD_PASSWORD \;
+
+notify:
+    stage: notify
+
+    only:
+        # Notify after new tag has been pushed.
+        - tags
+
+    variables:
+        # This job does not need the git repository.
+        GIT_STRATEGY: none
+
+    script:
+        - curl -X POST -F token=$LINUX_META_CI_TRIGGER_TOKEN -F ref=$LINUX_META_22_04_BRANCH_NAME $LINUX_META_CI_TRIGGER_URL
+
+sync:
+    stage: sync
+
+    only:
+        # Sync after new push, branch or tag.
+        - pushes
+
+    variables:
+        # This job does not need a clean working directory.
+        GIT_STRATEGY: fetch
+        # The default depth of 50 might miss the common ancestor.
+        GIT_DEPTH: 2000
+
+    script:
+        # GitLab CI checks out in a detached head state, correct this for branch syncs to be able to push.
+        - git checkout $CI_COMMIT_REF_NAME
+
+        # Update GitHub mirror.
+        - git push --force --progress --verbose "https://${TUXEDO_BOT_GITHUB_USERNAME}:${TUXEDO_BOT_GITHUB_CI_PERSONAL_ACCESS_TOKEN}@${GITHUB_REPOSITORY_CLONE_URL#https://}" $CI_COMMIT_REF_NAME

Documentation/ABI/testing/sysfs-devices-system-cpu

@@ -521,6 +521,7 @@ What:		/sys/devices/system/cpu/vulnerabilities
 		/sys/devices/system/cpu/vulnerabilities/tsx_async_abort
 		/sys/devices/system/cpu/vulnerabilities/itlb_multihit
 		/sys/devices/system/cpu/vulnerabilities/mmio_stale_data
+		/sys/devices/system/cpu/vulnerabilities/retbleed
 Date:		January 2018
 Contact:	Linux kernel mailing list <linux-kernel@vger.kernel.org>
 Description:	Information about CPU vulnerabilities

Documentation/ABI/testing/sysfs-driver-xen-blkback

@@ -42,5 +42,5 @@ KernelVersion:  5.10
 Contact:        SeongJae Park <sjpark@amazon.de>
 Description:
                 Whether to enable the persistent grants feature or not.  Note
-                that this option only takes effect on newly created backends.
+                that this option only takes effect on newly connected backends.
                 The default is Y (enable).

Documentation/ABI/testing/sysfs-driver-xen-blkfront

@@ -15,5 +15,5 @@ KernelVersion:  5.10
 Contact:        SeongJae Park <sjpark@amazon.de>
 Description:
                 Whether to enable the persistent grants feature or not.  Note
-                that this option only takes effect on newly created frontends.
+                that this option only takes effect on newly connected frontends.
                 The default is Y (enable).

Documentation/admin-guide/device-mapper/writecache.rst

@@ -78,16 +78,16 @@ Status:
 2. the number of blocks
 3. the number of free blocks
 4. the number of blocks under writeback
-5. the number of read requests
-6. the number of read requests that hit the cache
-7. the number of write requests
-8. the number of write requests that hit uncommitted block
-9. the number of write requests that hit committed block
-10. the number of write requests that bypass the cache
-11. the number of write requests that are allocated in the cache
+5. the number of read blocks
+6. the number of read blocks that hit the cache
+7. the number of write blocks
+8. the number of write blocks that hit uncommitted block
+9. the number of write blocks that hit committed block
+10. the number of write blocks that bypass the cache
+11. the number of write blocks that are allocated in the cache
 12. the number of write requests that are blocked on the freelist
 13. the number of flush requests
-14. the number of discard requests
+14. the number of discarded blocks
 
 Messages:
 	flush

Documentation/admin-guide/hw-vuln/processor_mmio_stale_data.rst

@@ -230,6 +230,20 @@ The possible values in this file are:
      * - 'Mitigation: Clear CPU buffers'
        - The processor is vulnerable and the CPU buffer clearing mitigation is
          enabled.
+     * - 'Unknown: No mitigations'
+       - The processor vulnerability status is unknown because it is
+	 out of Servicing period. Mitigation is not attempted.
+
+Definitions:
+------------
+
+Servicing period: The process of providing functional and security updates to
+Intel processors or platforms, utilizing the Intel Platform Update (IPU)
+process or other similar mechanisms.
+
+End of Servicing Updates (ESU): ESU is the date at which Intel will no
+longer provide Servicing, such as through IPU or other similar update
+processes. ESU dates will typically be aligned to end of quarter.
 
 If the processor is vulnerable then the following information is appended to
 the above information:

Documentation/admin-guide/kernel-parameters.txt

@@ -4993,20 +4993,33 @@
 			Speculative Code Execution with Return Instructions)
 			vulnerability.
 
+			AMD-based UNRET and IBPB mitigations alone do not stop
+			sibling threads from influencing the predictions of other
+			sibling threads. For that reason, STIBP is used on pro-
+			cessors that support it, and mitigate SMT on processors
+			that don't.
+
 			off          - no mitigation
 			auto         - automatically select a migitation
 			auto,nosmt   - automatically select a mitigation,
 				       disabling SMT if necessary for
 				       the full mitigation (only on Zen1
 				       and older without STIBP).
-			ibpb	     - mitigate short speculation windows on
-				       basic block boundaries too. Safe, highest
-				       perf impact.
-			unret        - force enable untrained return thunks,
-				       only effective on AMD f15h-f17h
-				       based systems.
-			unret,nosmt  - like unret, will disable SMT when STIBP
-			               is not available.
+			ibpb         - On AMD, mitigate short speculation
+				       windows on basic block boundaries too.
+				       Safe, highest perf impact. It also
+				       enables STIBP if present. Not suitable
+				       on Intel.
+			ibpb,nosmt   - Like "ibpb" above but will disable SMT
+				       when STIBP is not available. This is
+				       the alternative for systems which do not
+				       have STIBP.
+			unret        - Force enable untrained return thunks,
+				       only effective on AMD f15h-f17h based
+				       systems.
+			unret,nosmt  - Like unret, but will disable SMT when STIBP
+				       is not available. This is the alternative for
+				       systems which do not have STIBP.
 
 			Selecting 'auto' will choose a mitigation method at run
 			time according to the CPU.

Documentation/admin-guide/pm/cpuidle.rst

@@ -612,8 +612,8 @@ the ``menu`` governor to be used on the systems that use the ``ladder`` governor
 by default this way, for example.
 
 The other kernel command line parameters controlling CPU idle time management
-described below are only relevant for the *x86* architecture and some of
-them affect Intel processors only.
+described below are only relevant for the *x86* architecture and references
+to ``intel_idle`` affect Intel processors only.
 
 The *x86* architecture support code recognizes three kernel command line
 options related to CPU idle time management: ``idle=poll``, ``idle=halt``,
@@ -635,10 +635,13 @@ idle, so it very well may hurt single-thread computations performance as well as
 energy-efficiency.  Thus using it for performance reasons may not be a good idea
 at all.]
 
-The ``idle=nomwait`` option disables the ``intel_idle`` driver and causes
-``acpi_idle`` to be used (as long as all of the information needed by it is
-there in the system's ACPI tables), but it is not allowed to use the
-``MWAIT`` instruction of the CPUs to ask the hardware to enter idle states.
+The ``idle=nomwait`` option prevents the use of ``MWAIT`` instruction of
+the CPU to enter idle states. When this option is used, the ``acpi_idle``
+driver will use the ``HLT`` instruction instead of ``MWAIT``. On systems
+running Intel processors, this option disables the ``intel_idle`` driver
+and forces the use of the ``acpi_idle`` driver instead. Note that in either
+case, ``acpi_idle`` driver will function only if all the information needed
+by it is in the system's ACPI tables.
 
 In addition to the architecture-level kernel command line options affecting CPU
 idle time management, there are parameters affecting individual ``CPUIdle``

Documentation/admin-guide/sysctl/net.rst

@@ -271,7 +271,7 @@ poll cycle or the number of packets processed reaches netdev_budget.
 netdev_max_backlog
 ------------------
 
-Maximum number  of  packets,  queued  on  the  INPUT  side, when the interface
+Maximum number of packets, queued on the INPUT side, when the interface
 receives packets faster than kernel can process them.
 
 netdev_rss_key

Documentation/atomic_bitops.txt

@@ -59,7 +59,7 @@ Like with atomic_t, the rule of thumb is:
  - RMW operations that have a return value are fully ordered.
 
  - RMW operations that are conditional are unordered on FAILURE,
-   otherwise the above rules apply. In the case of test_and_{}_bit() operations,
+   otherwise the above rules apply. In the case of test_and_set_bit_lock(),
    if the bit in memory is unchanged by the operation then it is deemed to have
    failed.
 

Documentation/devicetree/bindings/arm/qcom.yaml

@@ -135,28 +135,34 @@ properties:
           - const: qcom,msm8974
 
       - items:
-          - enum:
-              - alcatel,idol347
-          - const: qcom,msm8916-mtp/1
           - const: qcom,msm8916-mtp
+          - const: qcom,msm8916-mtp/1
           - const: qcom,msm8916
 
       - items:
           - enum:
-              - longcheer,l8150
+              - alcatel,idol347
               - samsung,a3u-eur
               - samsung,a5u-eur
           - const: qcom,msm8916
 
+      - items:
+          - const: longcheer,l8150
+          - const: qcom,msm8916-v1-qrd/9-v1
+          - const: qcom,msm8916
+
       - items:
           - enum:
               - sony,karin_windy
+          - const: qcom,apq8094
+
+      - items:
+          - enum:
               - sony,karin-row
               - sony,satsuki-row
               - sony,sumire-row
               - sony,suzuran-row
-              - qcom,msm8994
-          - const: qcom,apq8094
+          - const: qcom,msm8994
 
       - items:
           - const: qcom,msm8996-mtp

Documentation/devicetree/bindings/clock/qcom,gcc-msm8996.yaml

@@ -22,16 +22,32 @@ properties:
     const: qcom,gcc-msm8996
 
   clocks:
+    minItems: 3
     items:
       - description: XO source
       - description: Second XO source
       - description: Sleep clock source
+      - description: PCIe 0 PIPE clock (optional)
+      - description: PCIe 1 PIPE clock (optional)
+      - description: PCIe 2 PIPE clock (optional)
+      - description: USB3 PIPE clock (optional)
+      - description: UFS RX symbol 0 clock (optional)
+      - description: UFS RX symbol 1 clock (optional)
+      - description: UFS TX symbol 0 clock (optional)
 
   clock-names:
+    minItems: 3
     items:
       - const: cxo
       - const: cxo2
       - const: sleep_clk
+      - const: pcie_0_pipe_clk_src
+      - const: pcie_1_pipe_clk_src
+      - const: pcie_2_pipe_clk_src
+      - const: usb3_phy_pipe_clk_src
+      - const: ufs_rx_symbol_0_clk_src
+      - const: ufs_rx_symbol_1_clk_src
+      - const: ufs_tx_symbol_0_clk_src
 
   '#clock-cells':
     const: 1

Documentation/devicetree/bindings/gpio/gpio-zynq.yaml

@@ -11,7 +11,11 @@ maintainers:
 
 properties:
   compatible:
-    const: xlnx,zynq-gpio-1.0
+    enum:
+      - xlnx,zynq-gpio-1.0
+      - xlnx,zynqmp-gpio-1.0
+      - xlnx,versal-gpio-1.0
+      - xlnx,pmc-gpio-1.0
 
   reg:
     maxItems: 1