diff mbox series

[meta,02/07] linux-yocto/6.18: qat/intel configuration warning fixes

Message ID 20260528023714.4026613-3-bruce.ashfield@gmail.com
State Under Review
Headers show
Series linux-yocto: consolidated pull request | expand

Commit Message

Bruce Ashfield May 28, 2026, 2:37 a.m. UTC 
From: Bruce Ashfield <bruce.ashfield@gmail.com>

Integrating the following commit(s) to linux-yocto/.:

1/2 [
    Author: Yogesh Tyagi
    Email: yogesh.tyagi@intel.com
    Subject: qat: fix CONFIG_CRYPTO_CTS mismatch warnings
    Date: Mon, 18 May 2026 22:21:02 +0530

    [NOTE]: 'CONFIG_CRYPTO_CTS' last val (m) and .config val (y) do not match
    [INFO]: CONFIG_CRYPTO_CTS : y ## .config: 8103 :configs/v6.18/ktypes/base/base.cfg (y) configs/v6.18/standard/features/qat/qat.cfg (m)
    [INFO]: raw config text:

            config CRYPTO_CTS
                    tristate "CTS (Cipher Text Stealing)"
                    select CRYPTO_SKCIPHER
                    select CRYPTO_MANAGER
                    depends on CRYPTO
                    help
                      CBC-CS3 variant of CTS (Cipher Text Stealing) (NIST
                      Addendum to SP800-38A (October 2010))

                      This mode is required for Kerberos gss mechanism support
                      for AES encryption.

            Config 'CRYPTO_CTS' has the following Direct dependencies (CRYPTO_CTS=y):
                    CRYPTO(=y)
            Parent dependencies are:
                 CRYPTO [y]

    [INFO]: selection details for 'CONFIG_CRYPTO_CTS':
            Symbols currently y-selecting this symbol:
              - FS_ENCRYPTION_ALGS

            Symbols currently n-selecting this symbol (no effect):
              - RXGK
              - CRYPTO_KRB5

    base.cfg pins CRYPTO_CTS=y while features/qat/qat.cfg requests =m.
    FS_ENCRYPTION_ALGS=y forces the symbol to =y at .config time, which is
    the correct outcome -- QAT consumes CRYPTO_CTS via the in-kernel
    crypto API and works against either built-in or modular CTS. Add the
    symbol to the y_or_m_enabled.cfg whitelist so the audit no longer
    flags this mismatch, matching the existing handling of CRYPTO_CCM
    and CRYPTO_GCM.

    Signed-off-by: Yogesh Tyagi <yogesh.tyagi@intel.com>
    Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
]

2/2 [
    Author: Yogesh Tyagi
    Email: yogesh.tyagi@intel.com
    Subject: bsp/intel-{x86,common}: drop CONFIG_HIGHMEM64G
    Date: Mon, 18 May 2026 22:21:03 +0530

    CONFIG_HIGHMEM64G was removed from the kernel in v6.18-rc1 by:

        commit bbeb69ce301323e84f1677484eb8e4cd8fb1f9f8
        Author: Arnd Bergmann <arnd@arndb.de>
        Date:   Wed Feb 26 22:37:09 2025 +0100

            x86/mm: Remove CONFIG_HIGHMEM64G support

    The two intel 32-bit BSP fragments still carry CONFIG_HIGHMEM64G=y,
    which against a v6.18 kernel produces:

        [INFO]: the following symbols were not found in the active configuration:
            - CONFIG_HIGHMEM64G

    emitted by do_kernel_configcheck whenever MACHINE selects one of these
    BSPs (e.g. MACHINE=intel-core2-32).

    The replacement on x86-PAE kernels is the unconditional 64GiB ceiling
    that landed alongside the removal commit; no fragment-level opt-in is
    required. Drop the obsolete symbol from both fragments. This mirrors
    the recent "x86: drop CONFIG_BIG_SMP" cleanup (3260f662) for symbols
    upstream removed in the same series.

    Signed-off-by: Yogesh Tyagi <yogesh.tyagi@intel.com>
    Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
]

Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
---
 meta/recipes-kernel/linux/linux-yocto-rt_6.18.bb   | 2 +-
 meta/recipes-kernel/linux/linux-yocto-tiny_6.18.bb | 2 +-
 meta/recipes-kernel/linux/linux-yocto_6.18.bb      | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)
diff mbox series

Patch

diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_6.18.bb b/meta/recipes-kernel/linux/linux-yocto-rt_6.18.bb
index 031c81c2b3..b5775d2fd1 100644
--- a/meta/recipes-kernel/linux/linux-yocto-rt_6.18.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-rt_6.18.bb
@@ -16,7 +16,7 @@  python () {
 }
 
 SRCREV_machine ?= "dda294005f893c24b6322a7bdf58d7575f4ad21f"
-SRCREV_meta ?= "2d12860e7692327b02ec4d707585fe101b8c4d38"
+SRCREV_meta ?= "a5384458147b581e6beac32ee5cec4e4422d58b1"
 
 SRC_URI = "git://git.yoctoproject.org/linux-yocto.git;branch=${KBRANCH};name=machine;protocol=https \
            git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-6.18;destsuffix=${KMETA};protocol=https"
diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny_6.18.bb b/meta/recipes-kernel/linux/linux-yocto-tiny_6.18.bb
index 824546e661..70577b74b5 100644
--- a/meta/recipes-kernel/linux/linux-yocto-tiny_6.18.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-tiny_6.18.bb
@@ -19,7 +19,7 @@  KMETA = "kernel-meta"
 KCONF_BSP_AUDIT_LEVEL = "2"
 
 SRCREV_machine ?= "8b43828d68f73df49a408e5bba88eade55b0ca09"
-SRCREV_meta ?= "2d12860e7692327b02ec4d707585fe101b8c4d38"
+SRCREV_meta ?= "a5384458147b581e6beac32ee5cec4e4422d58b1"
 
 PV = "${LINUX_VERSION}+git"
 
diff --git a/meta/recipes-kernel/linux/linux-yocto_6.18.bb b/meta/recipes-kernel/linux/linux-yocto_6.18.bb
index 2964cf6000..26e02541b7 100644
--- a/meta/recipes-kernel/linux/linux-yocto_6.18.bb
+++ b/meta/recipes-kernel/linux/linux-yocto_6.18.bb
@@ -29,7 +29,7 @@  SRCREV_machine:qemux86 ?= "8b43828d68f73df49a408e5bba88eade55b0ca09"
 SRCREV_machine:qemux86-64 ?= "8b43828d68f73df49a408e5bba88eade55b0ca09"
 SRCREV_machine:qemumips64 ?= "9fb4ff0187c85426f21fd40d4c61b742800f65c4"
 SRCREV_machine ?= "8b43828d68f73df49a408e5bba88eade55b0ca09"
-SRCREV_meta ?= "2d12860e7692327b02ec4d707585fe101b8c4d38"
+SRCREV_meta ?= "a5384458147b581e6beac32ee5cec4e4422d58b1"
 
 # set your preferred provider of linux-yocto to 'linux-yocto-upstream', and you'll
 # get the <version>/base branch, which is pure upstream -stable, and the same