module: Fix minor problems related to MODULE_NAME_LEN

.github/workflows/kdevops-cleanup.yml

@@ -0,0 +1,60 @@
+# SPDX-License-Identifier: GPL-2.0
+#
+# This can be used towards the end of your action. All tasks here run even if
+# any of the previous tasks failed.
+
+name: Kdevops cleanup workflow
+
+on:
+  workflow_call:  # Makes this workflow reusable
+
+jobs:
+  cleanup:
+    name: Archive results and cleanup
+    runs-on: [self-hosted, Linux, X64]
+    steps:
+      - name: Set Linux kdevops development path
+        if: ${{ job.status != 'cancelled' }}
+        run: echo "LINUX_KDEVOPS_PATH=$GITHUB_WORKSPACE" >> $GITHUB_ENV
+
+      - name: Get systemd journal files
+        if: ${{ job.status != 'cancelled' }}
+        run: |
+          if [[ ! -d kdevops ]]; then
+            exit 0
+          fi
+          cd kdevops
+          make journal-dump
+
+      - name: Start SSH Agent
+        if: ${{ job.status != 'cancelled' }}
+        uses: webfactory/ssh-agent@v0.9.0
+        with:
+          ssh-private-key: ${{ secrets.SSH_PRIVATE_KEY }}
+
+      - name: Build our kdevops archive results
+        if: ${{ job.status != 'cancelled' }}
+        run: |
+          if [[ ! -d kdevops ]]; then
+            exit 0
+          fi
+          cd kdevops
+          make ci-archive
+
+      - name: Upload our kdevops results archive
+        if: ${{ job.status != 'cancelled' }}
+        uses: actions/upload-artifact@v4
+        with:
+          name: kdevops-ci-results
+          path: ${{ env.LINUX_KDEVOPS_PATH }}/kdevops/archive/*.zip
+
+      - name: Run kdevops make destroy
+        if: always()
+        run: |
+          if [[ ! -d kdevops ]]; then
+            exit 0
+          fi
+          cd kdevops
+          make destroy
+          cd ..
+          rm -rf kdevops

.github/workflows/kdevops-generic.yml

@@ -0,0 +1,37 @@
+# SPDX-License-Identifier: GPL-2.0
+#
+# Most simple Linux kernel subsystems can be tested with this target
+# test setup. For more elaborates tests look for a topic branch under the
+# kdevops-ci tree. For example to test a filesystem look at the fstests
+# branch.
+
+name: Run generic kdevops CI tests
+
+on:
+  push:
+    branches: ['**']
+  pull_request:
+    branches: ['**']
+  workflow_dispatch:  # Allow manual triggering
+
+jobs:
+  setup:
+    uses: ./.github/workflows/kdevops-init.yml
+    secrets: inherit
+
+  run-tests:
+    needs: setup
+    name: Run CI tests
+    runs-on: [self-hosted, Linux, X64]
+    steps:
+      - name: Run CI tests
+        run: |
+          cd kdevops
+          make ci-test
+          echo "ok" > ci.result
+
+  cleanup:
+    needs: [run-tests, setup]  # Add setup as a dependency to ensure proper ordering
+    if: always()  # This ensures cleanup runs even if run-tests fails
+    uses: ./.github/workflows/kdevops-cleanup.yml
+    secrets: inherit

.github/workflows/kdevops-init.yml

@@ -0,0 +1,192 @@
+# SPDX-License-Identifier: GPL-2.0
+#
+# This can be used as a initialization workflow for most Linux kernel
+# development environments. This takes care of:
+#
+#   - Checks out and re-using a local mirror for your kernel tree
+#   - Looks for a defconfig in kdevops to use for your kernel tree
+#   - Sets up CI metadata for kdevops-results-archive
+#   - Ensures your kernel tree at least builds with defconfig
+#   - Brings up target DUTs nodes
+#   - Installs your Linux kernel tree on them
+#   - Builds all of your test requirements for your Linux kernel tree
+
+name: Base kdevops workflow
+
+on:
+  workflow_call:  # Makes this workflow reusable
+    inputs:
+      kdevops_defconfig:
+        required: false
+        type: string
+
+jobs:
+  setup:
+    name: Setup kdevops environment
+    runs-on: [self-hosted, Linux, X64]
+    steps:
+      - name: Verify we won't expect user input interactions on the host key
+        run: |
+          mkdir -p ~/.ssh
+          if ! grep -q "StrictHostKeyChecking no" ~/.ssh/config 2>/dev/null; then
+            echo "StrictHostKeyChecking no" >> ~/.ssh/config
+          fi
+
+      - name: Start SSH Agent for initial test
+        uses: webfactory/ssh-agent@v0.9.0
+        with:
+          ssh-private-key: ${{ secrets.SSH_PRIVATE_KEY }}
+
+      # Modify the repo here if you have a custom or private URL for the archive
+      # This can also just be a repo variable later.
+      - name: Verify our ssh connection will work
+        run: |
+          if ! git ls-remote git@github.com:linux-kdevops/kdevops-results-archive.git HEAD; then
+            echo "Cannot access kdevops-results-archive repository"
+            exit 1
+          fi
+
+      - name: Configure git
+        run: |
+          git config --global --add safe.directory '*'
+          git config --global user.name "kdevops"
+          git config --global user.email "kdevops@lists.linux.dev"
+
+      - name: Checkout kdevops
+        run: |
+          rm -rf kdevops
+          git clone /mirror/kdevops.git kdevops
+
+      - name: Make sure our repo kdevops defconfig exists
+        run: |
+          cd kdevops
+          if [[ -z "${{ inputs.kdevops_defconfig }}" ]]; then
+            KDEVOPS_DEFCONFIG=$(basename ${{ github.repository }})
+          else
+            KDEVOPS_DEFCONFIG="${{ inputs.kdevops_defconfig }}"
+          fi
+
+          if [[ ! -f defconfigs/$KDEVOPS_DEFCONFIG ]]; then
+            echo "kdevops lacks a defconfig for this repository, expected to find: defconfigs/$KDEVOPS_DEFCONFIG"
+            exit 1
+          fi
+
+          echo "KDEVOPS_DEFCONFIG=$KDEVOPS_DEFCONFIG" >> $GITHUB_ENV
+
+      - name: Checkout custom branch with delta on kdevops/linux
+        run: |
+          LINUX_TREE="https://github.com/${{ github.repository }}"
+          LINUX_TREE_REF="${{ github.event_name == 'pull_request' && github.event.pull_request.head.sha || github.sha }}"
+          cd kdevops
+          git clone $LINUX_TREE --reference /mirror/linux.git/ --depth=5 linux
+          cd linux
+          git fetch origin $LINUX_TREE_REF
+          git checkout $LINUX_TREE_REF
+          git log -1
+
+      - name: Initialize CI metadata for kdevops-results-archive for linux
+        run: |
+          cd kdevops/linux
+          echo "$(basename ${{ github.repository }})" > ../ci.trigger
+
+          # This supports using kdevops github actions using two different
+          # approaches:
+          #
+          #  1) Commit the .github/ directory onto a Linux tree before your
+          #     kernel changes. This approach is used for example for
+          #     testing patches posted on the mailing list with patchwork,
+          #     this is the strategy kernel-patch-deaemon uses. Since the
+          #     patches are ephemeral there is not important git history to
+          #     maintain.
+          #
+          #  2) Merge the .github/ directory at the end of your development
+          #     tree. This is useful for kernel developers wishing to test
+          #     existing trees.
+          #
+          # So this checks to see if the last commit (top of the tree) *added*
+          # the .github directory. If the last commit added it, then we assume
+          # the commit prior to it was the one we'd like to document as the main
+          # test point.
+          if git diff-tree --no-commit-id --name-only --diff-filter=A -r HEAD | grep -q "^\.github/"; then
+            git log -2 --skip=1 --pretty=format:"%s" -1 > ../ci.subject
+            git describe --exact-match --tags HEAD^ 2>/dev/null || git rev-parse --short HEAD^ > ../ci.ref
+          else
+            git log -1 --pretty=format:"%s" > ../ci.subject
+            git describe --exact-match --tags HEAD 2>/dev/null || git rev-parse --short HEAD > ../ci.ref
+          fi
+
+          RELEVANT_GIT_TAG=$(cat ../ci.ref)
+          RELEVANT_GIT_REF=$(git rev-parse --short=12 $RELEVANT_GIT_TAG)
+
+          echo "LINUX_GIT_REF=$RELEVANT_GIT_REF" >> $GITHUB_ENV
+          echo "LINUX_GIT_TAG=$RELEVANT_GIT_TAG" >> $GITHUB_ENV
+
+          # Start out pessimistic
+          echo "unknown" > ../ci.result
+          echo "Nothing to write home about." > ../ci.commit_extra
+
+      - name: Run a quick Linux kernel defconfig build test
+        run: |
+          cd kdevops/linux
+          git reset --hard ${{ env.LINUX_GIT_TAG }}
+          make defconfig
+          make -j$(nproc)
+
+      - name: Run kdevops make defconfig-repo
+        run: |
+          LINUX_TREE="https://github.com/${{ github.repository }}"
+          LINUX_TREE_REF="${{ env.LINUX_GIT_TAG }}"
+
+          # We make the compromise here to use a relevant git tag for the
+          # host prefix so that folks can easily tell what exact kernel tree
+          # is being tested by using the relevant git ref. That is, if you
+          # pushed a tree with the .github/ directory as the top of the tree,
+          # that commit will not be used, we'll use the last one as that is
+          # the relevant git ref we want to annotate a test for.
+          #
+          # The compromise here we use special KDEVOPS to separete the
+          # commit ID and github.run_id. Exotic things likes UTF characters
+          # and dots have problems.
+          KDEVOPS_HOSTS_PREFIX="${{ env.LINUX_GIT_REF }}KDEVOPS${{ github.run_id }}"
+
+          echo "Going to use defconfig-${{ env.KDEVOPS_DEFCONFIG }}"
+
+          echo "Linux tree:          $LINUX_TREE"
+          echo "Linux trigger ref:   $LINUX_TREE_REF"
+          echo "Linux tag:           ${{ env.LINUX_GIT_TAG }}"
+          echo "Runner ID:           ${{ github.run_id }}"
+          echo "kdevops host prefix: $KDEVOPS_HOSTS_PREFIX"
+          echo "kdevops defconfig:   defconfig-${{ env.KDEVOPS_DEFCONFIG }}"
+
+          KDEVOPS_ARGS="\
+          KDEVOPS_HOSTS_PREFIX=$KDEVOPS_HOSTS_PREFIX \
+          LINUX_TREE=$LINUX_TREE \
+          LINUX_TREE_REF=$LINUX_TREE_REF \
+          ANSIBLE_CFG_CALLBACK_PLUGIN="debug" \
+          defconfig-${{ env.KDEVOPS_DEFCONFIG }}"
+          echo "Going to run:"
+          echo "make $KDEVOPS_ARGS"
+
+          cd kdevops
+          make $KDEVOPS_ARGS
+
+      - name: Run kdevops make
+        run: |
+          cd kdevops
+          make -j$(nproc)
+
+      - name: Run kdevops make bringup
+        run: |
+          cd kdevops
+          ls -ld linux
+          make bringup
+
+      - name: Build linux and boot test nodes on test kernel
+        run: |
+          cd kdevops
+          make linux
+
+      - name: Build required ci tests
+        run: |
+          cd kdevops
+          make ci-build-test

CREDITS

@@ -2336,7 +2336,7 @@ D: Author of the dialog utility, foundation
 D: for Menuconfig's lxdialog.
 
 N: Christoph Lameter
-E: cl@gentwo.org
+E: christoph@lameter.com
 D: Digiboard PC/Xe and PC/Xi, Digiboard EPCA
 D: NUMA support, Slab allocators, Page migration
 D: Scalability, Time subsystem
@@ -2981,11 +2981,6 @@ S: 521 Pleasant Valley Road
 S: Potsdam, New York 13676
 S: USA
 
-N: Shannon Nelson
-E: sln@onemain.com
-D: Worked on several network drivers including
-D: ixgbe, i40e, ionic, pds_core, pds_vdpa, pds_fwctl
-
 N: Dave Neuer
 E: dave.neuer@pobox.com
 D: Helped implement support for Compaq's H31xx series iPAQs

Documentation/ABI/stable/sysfs-block

@@ -547,21 +547,6 @@ Description:
 		[RO] Maximum size in bytes of a single element in a DMA
 		scatter/gather list.
 
-What:		/sys/block/<disk>/queue/max_write_streams
-Date:		November 2024
-Contact:	linux-block@vger.kernel.org
-Description:
-		[RO] Maximum number of write streams supported, 0 if not
-		supported. If supported, valid values are 1 through
-		max_write_streams, inclusive.
-
-What:		/sys/block/<disk>/queue/write_stream_granularity
-Date:		November 2024
-Contact:	linux-block@vger.kernel.org
-Description:
-		[RO] Granularity of a write stream in bytes.  The granularity
-		of a write stream is the size that should be discarded or
-		overwritten together to avoid write amplification in the device.
 
 What:		/sys/block/<disk>/queue/max_segments
 Date:		March 2010

Documentation/ABI/stable/sysfs-class-backlight

@@ -26,12 +26,7 @@ Date:		March 2006
 KernelVersion:	2.6.17
 Contact:	Richard Purdie <rpurdie@rpsys.net>
 Description:
-		Show the actual brightness by querying the hardware. Due
-		to implementation differences in hardware this may not
-		match the value in 'brightness'. For example some hardware
-		may treat blanking differently or have custom power saving
-		features. Userspace should generally use the values in
-		'brightness' to make decisions.
+		Show the actual brightness by querying the hardware.
 Users:		HAL
 
 What:		/sys/class/backlight/<backlight>/max_brightness