[OS-BUILD PATCH] Allow building of kernel-tools standalone
by GitLab Bridge on behalf of dzickusrh
From: Don Zickus <dzickus(a)redhat.com>
For CKI and its cross-compile environment, it can not cross
compile userspace tools. Instead we will native compiles them.
To allow this split, the kernel.spec needs to support only
building userspace stuff and not the kernel itself.
However the userspace tools need some vars defined. This
patch creates a new function and sets up those vars.
Also very useful for debugging userspace tools and skipping
the hour long kernel build times (like LTO).
To use this effectively, one would use
--without_up
--without_debug
--without_zfcpdump
Original author is Brian Masney <bmasney(a)redhat.com>, which
I took from his RHEL-8 contribution.
Cc: Brian Masney <bmasney(a)redhat.com>
Signed-off-by: Don Zickus <dzickus(a)redhat.com>
---
redhat/kernel.spec.template | 68 +++++++++++++++++++++++--------------
1 file changed, 42 insertions(+), 26 deletions(-)
diff --git a/redhat/kernel.spec.template b/redhat/kernel.spec.template
index 7cbfb9c139eb..5354ee7cffdf 100644
--- a/redhat/kernel.spec.template
+++ b/redhat/kernel.spec.template
@@ -79,10 +79,9 @@ Summary: The Linux kernel
%define pkg_release %{specrelease}
-# What parts do we want to build? We must build at least one kernel.
-# These are the kernels that are built IF the architecture allows it.
-# All should default to 1 (enabled) and be flipped to 0 (disabled)
-# by later arch-specific checks.
+# What parts do we want to build? These are the kernels that are built IF the
+# architecture allows it. All should default to 1 (enabled) and be flipped to
+# 0 (disabled) by later arch-specific checks.
# The following build options are enabled by default.
# Use either --without <opt> in your rpmbuild command or force values
@@ -1338,33 +1337,18 @@ cp_vmlinux()
%define make %{__make} %{?cross_opts} %{?make_opts} HOSTCFLAGS="%{?build_hostcflags}" HOSTLDFLAGS="%{?build_hostldflags}"
-BuildKernel() {
- MakeTarget=$1
- KernelImage=$2
- Flavour=$4
- DoVDSO=$3
- Flav=${Flavour:++${Flavour}}
- InstallName=${5:-vmlinuz}
+InitBuildVars() {
+ # Initialize the kernel .config file and create some variables that are
+ # needed for the actual build process.
- DoModules=1
- if [ "$Flavour" = "zfcpdump" ]; then
- DoModules=0
- fi
+ Flavour=$1
+ Flav=${Flavour:++${Flavour}}
# Pick the right config file for the kernel we're building
Config=kernel-%{version}-%{_target_cpu}${Flavour:+-${Flavour}}.config
DevelDir=/usr/src/kernels/%{KVERREL}${Flav}
- # When the bootable image is just the ELF kernel, strip it.
- # We already copy the unstripped file into the debuginfo package.
- if [ "$KernelImage" = vmlinux ]; then
- CopyKernel=cp_vmlinux
- else
- CopyKernel=cp
- fi
-
KernelVer=%{version}-%{release}.%{_target_cpu}${Flav}
- echo BUILDING A KERNEL FOR ${Flavour} %{_target_cpu}...
# make sure EXTRAVERSION says what we want it to say
# Trim the release if this is a CI build, since KERNELVERSION is limited to 64 characters
@@ -1375,8 +1359,6 @@ BuildKernel() {
# if we are post rc1 this should match anyway so this won't matter
perl -p -i -e 's/^PATCHLEVEL.*/PATCHLEVEL = %{patchlevel}/' Makefile
- # and now to start the build process
-
%{make} %{?_smp_mflags} mrproper
cp configs/$Config .config
@@ -1393,6 +1375,32 @@ BuildKernel() {
if [ "$Flavour" == "" ]; then
KCFLAGS="$KCFLAGS %{?kpatch_kcflags}"
fi
+}
+
+BuildKernel() {
+ MakeTarget=$1
+ KernelImage=$2
+ Flavour=$4
+ DoVDSO=$3
+ Flav=${Flavour:++${Flavour}}
+ InstallName=${5:-vmlinuz}
+
+ DoModules=1
+ if [ "$Flavour" = "zfcpdump" ]; then
+ DoModules=0
+ fi
+
+ # When the bootable image is just the ELF kernel, strip it.
+ # We already copy the unstripped file into the debuginfo package.
+ if [ "$KernelImage" = vmlinux ]; then
+ CopyKernel=cp_vmlinux
+ else
+ CopyKernel=cp
+ fi
+
+ InitBuildVars $Flavour
+
+ echo BUILDING A KERNEL FOR ${Flavour} %{_target_cpu}...
%{make} ARCH=$Arch olddefconfig >/dev/null
@@ -1920,6 +1928,14 @@ BuildKernel %make_target %kernel_image %{use_vdso} lpae
BuildKernel %make_target %kernel_image %{_use_vdso}
%endif
+%ifnarch noarch i686
+%if !%{with_debug} && !%{with_zfcpdump} && !%{with_up}
+# If only building the user space tools, then initialize the build environment
+# and some variables so that the various userspace tools can be built.
+InitBuildVars
+%endif
+%endif
+
%global perf_make \
%{__make} -s EXTRA_CFLAGS="${RPM_OPT_FLAGS}" LDFLAGS="%{__global_ldflags}" %{?cross_opts} -C tools/perf V=1 NO_PERF_READ_VDSO32=1 NO_PERF_READ_VDSOX32=1 WERROR=0 NO_LIBUNWIND=1 HAVE_CPLUS_DEMANGLE=1 NO_GTK2=1 NO_STRLCPY=1 NO_BIONIC=1 prefix=%{_prefix} PYTHON=%{__python3}
%if %{with_perf}
--
GitLab
3 years, 6 months
✅ PASS: Test report for kernel 5.8.17-200.fc32 (fedora-32)
by CKI Project
Hello jforbes,
We ran automated tests on the following kernel build:
Kernel package: kernel-5.8.17-200.fc32
Task URL: https://koji.fedoraproject.org/koji/taskinfo?taskID=54498291
The results of these automated tests are provided below.
Overall result: PASSED
Tests: OK
All kernel binaries, config files, and logs are available for download here:
https://arr-cki-prod-datawarehouse-public.s3.amazonaws.com/index.html?pre...
Please reply to this email if you have any questions about the tests that we
ran or if you have any suggestions on how to make future tests more effective.
For the full detail on our testing procedures, please scroll to the bottom of
this message.
,-. ,-.
( C ) ( K ) Continuous
`-',-.`-' Kernel
( I ) Integration
`-'
______________________________________________________________________________
Hardware testing
----------------
We booted each kernel and ran the following tests:
aarch64:
Host 1:
⚡ Internal infrastructure issues prevented one or more tests (marked
with ⚡⚡⚡) from running on this architecture.
This is not the fault of the kernel that was tested.
✅ Boot test
✅ xfstests - ext4
✅ xfstests - xfs
✅ stress: stress-ng
🚧 ✅ xfstests - btrfs
🚧 ✅ Storage blktests
🚧 ⚡⚡⚡ Storage nvme - tcp
Host 2:
✅ Boot test
✅ ACPI table test
✅ LTP
✅ Loopdev Sanity
✅ Memory: fork_mem
✅ Memory function: memfd_create
✅ AMTU (Abstract Machine Test Utility)
🚧 ✅ CIFS Connectathon
🚧 ✅ Ethernet drivers sanity
ppc64le:
Host 1:
⚡ Internal infrastructure issues prevented one or more tests (marked
with ⚡⚡⚡) from running on this architecture.
This is not the fault of the kernel that was tested.
⚡⚡⚡ Boot test
⚡⚡⚡ xfstests - ext4
⚡⚡⚡ xfstests - xfs
🚧 ⚡⚡⚡ xfstests - btrfs
🚧 ⚡⚡⚡ Storage blktests
🚧 ⚡⚡⚡ Storage nvme - tcp
Host 2:
✅ Boot test
🚧 ✅ kdump - sysrq-c
Host 3:
✅ Boot test
✅ LTP
✅ Loopdev Sanity
✅ Memory: fork_mem
✅ Memory function: memfd_create
✅ AMTU (Abstract Machine Test Utility)
🚧 ✅ CIFS Connectathon
🚧 ✅ Ethernet drivers sanity
Host 4:
⚡ Internal infrastructure issues prevented one or more tests (marked
with ⚡⚡⚡) from running on this architecture.
This is not the fault of the kernel that was tested.
⚡⚡⚡ Boot test
⚡⚡⚡ xfstests - ext4
⚡⚡⚡ xfstests - xfs
🚧 ⚡⚡⚡ xfstests - btrfs
🚧 ⚡⚡⚡ Storage blktests
🚧 ⚡⚡⚡ Storage nvme - tcp
Host 5:
⚡ Internal infrastructure issues prevented one or more tests (marked
with ⚡⚡⚡) from running on this architecture.
This is not the fault of the kernel that was tested.
⚡⚡⚡ Boot test
⚡⚡⚡ xfstests - ext4
⚡⚡⚡ xfstests - xfs
🚧 ⚡⚡⚡ xfstests - btrfs
🚧 ⚡⚡⚡ Storage blktests
🚧 ⚡⚡⚡ Storage nvme - tcp
s390x:
Host 1:
✅ Boot test
✅ LTP
✅ Loopdev Sanity
✅ Memory: fork_mem
✅ Memory function: memfd_create
✅ AMTU (Abstract Machine Test Utility)
🚧 ✅ CIFS Connectathon
🚧 ✅ Ethernet drivers sanity
Host 2:
✅ Boot test
✅ stress: stress-ng
🚧 ✅ Storage blktests
🚧 ❌ Storage nvme - tcp
x86_64:
Host 1:
✅ Boot test
🚧 ✅ kdump - sysrq-c
Host 2:
✅ Boot test
✅ ACPI table test
✅ LTP
✅ Loopdev Sanity
✅ Memory: fork_mem
✅ Memory function: memfd_create
✅ AMTU (Abstract Machine Test Utility)
🚧 ✅ CIFS Connectathon
🚧 ✅ Ethernet drivers sanity
Host 3:
✅ Boot test
✅ xfstests - ext4
✅ xfstests - xfs
✅ stress: stress-ng
🚧 ✅ xfstests - btrfs
🚧 ✅ Storage blktests
🚧 ✅ Storage nvme - tcp
Test sources: https://gitlab.com/cki-project/kernel-tests
💚 Pull requests are welcome for new tests or improvements to existing tests!
Aborted tests
-------------
Tests that didn't complete running successfully are marked with ⚡⚡⚡.
If this was caused by an infrastructure issue, we try to mark that
explicitly in the report.
Waived tests
------------
If the test run included waived tests, they are marked with 🚧. Such tests are
executed but their results are not taken into account. Tests are waived when
their results are not reliable enough, e.g. when they're just introduced or are
being fixed.
Testing timeout
---------------
We aim to provide a report within reasonable timeframe. Tests that haven't
finished running yet are marked with ⏱.
3 years, 6 months
[Fedora 34] Call for Test Days
by Sumantro Mukherjee
Hi Fedora users, developers and friends!
It's time to start thinking about Test Days for Fedora 34.
For anyone who isn't aware, a Test Day is an event usually focused
around IRC for interaction and a Wiki page for instructions and results,
with the aim being to get a bunch of interested users and developers
together to test a specific feature or area of the distribution. You can
run a Test Day on just about anything for which it would be useful to do
some fairly focused testing in 'real time' with a group of testers; it
doesn't have to be code, for instance, we often run Test Days for
l10n/i18n topics. For more information on Test Days, see
https://fedoraproject.org/wiki/QA/Test_Days .
Anyone who wants to can host their own Test Day, or you can request that
the QA group helps you out with organization or any combination of the
two. To propose a Test Day, just file a ticket in fedora-qa pagure - here's
an example https://pagure.io/fedora-qa/issue/624 . For
instructions on hosting a Test Day, see
https://fedoraproject.org/wiki/QA/SOP_Test_Day_management .
You can see the schedule at https://pagure.io/fedora-qa/issues?tags=test+days .
There are many slots open right now. Consider the development
schedule, though, in deciding when you want to run your Test Day - for
some topics you may want to avoid
the time before the Beta release or the time after the feature freeze
or the Final Freeze.
We normally aim to schedule Test Days on Thursdays; however, if you want
to run a series of related Test Days, it's often a good idea to do
something like Tuesday / Wednesday / Thursday of the same week (this is
how we usually run the X Test Week, for instance). If all the Thursday
slots fill up but more people want to run Test Days, we will open up
Tuesday slots as overflows. And finally, if you really want to run a
Test Day in a specific time frame due to the development schedule, but
the Thursday slot for that week is full, we can add a slot on another
day. We're flexible! Just put in your ticket the date or time frame you'd
like, and we'll figure it out from there.
If you don't want to run your own Test Day, but you are willing to
help with another, feel free to join one or more of already accepted
Test Days:
GNOME Test Day
i18n Test Day*
Kernel Test Week*
Upgrade Test Day*
IoT Test Week*
And don't be afraid, there are a lot of more slots available for your
own Test Day!
[*] These are the test days we run generally to make sure everything
is working fine, the dates get announced as we move into the release
cycle.
If you have any questions about the Test Day process, please don't
hesitate to contact me or any member of the Fedora QA team on test at
lists.fedoraproject.org or in #fedora-qa on IRC. Thanks!
Best Regards,
Sumantrom
Fedora QE
3 years, 6 months
[ARK PATCH] Work around for gcc bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96377
by GitLab Bridge on behalf of jmflinuxtx
From: "Justin M. Forbes" <jforbes(a)fedoraproject.org>
Signed-off-by: Justin M. Forbes <jforbes(a)fedoraproject.org>
---
crypto/aegis128-neon-inner.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/crypto/aegis128-neon-inner.c b/crypto/aegis128-neon-inner.c
index 2a660ac1bc3a..fa87ff6a2a71 100644
--- a/crypto/aegis128-neon-inner.c
+++ b/crypto/aegis128-neon-inner.c
@@ -148,8 +148,8 @@ void crypto_aegis128_init_neon(void *state, const void *key, const void *iv)
kiv,
vld1q_u8(const1),
vld1q_u8(const0),
- k ^ vld1q_u8(const0),
- k ^ vld1q_u8(const1),
+ (uint8x16_t) (k ^ vld1q_u8(const0)),
+ (uint8x16_t) (k ^ vld1q_u8(const1)),
}};
int i;
--
GitLab
3 years, 6 months
[OS-BUILD PATCH] arm64/defconfig: Enable CONFIG_KEXEC_FILE
by GitLab Bridge on behalf of bhsharma
From: Bhupesh Sharma <bhsharma(a)redhat.com>
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1821565
Upstream Status: 2a379716f3d76aebc5574155de247b547a0214cc
kexec_file_load() syscall interface is now supported for
arm64 architecture as well via upstream commits:
3751e728cef2 ("arm64: kexec_file: add crash dump support") and
3ddd9992a590 ("arm64: enable KEXEC_FILE config")].
This patch enables config KEXEC_FILE by default in the fedora
arm64 defconfig, so that user-space tools like kexec-tools
can use the same as the default interface for kexec/kdump
on arm64 fedora systems.
Cc: kernel-team(a)fedoraproject.org
Signed-off-by: Bhupesh Sharma <bhsharma(a)redhat.com>
---
redhat/configs/fedora/generic/arm/aarch64/CONFIG_KEXEC_FILE | 1 +
1 file changed, 1 insertion(+)
create mode 100644 redhat/configs/fedora/generic/arm/aarch64/CONFIG_KEXEC_FILE
diff --git a/redhat/configs/fedora/generic/arm/aarch64/CONFIG_KEXEC_FILE b/redhat/configs/fedora/generic/arm/aarch64/CONFIG_KEXEC_FILE
new file mode 100644
index 000000000000..25862bf98de8
--- /dev/null
+++ b/redhat/configs/fedora/generic/arm/aarch64/CONFIG_KEXEC_FILE
@@ -0,0 +1 @@
+CONFIG_KEXEC_FILE=y
--
GitLab
3 years, 6 months
[OS-BUILD PATCH] redhat/configs: Cleanup CONFIG_CRYPTO_SHA512
by GitLab Bridge on behalf of prarit
From: Prarit Bhargava <prarit(a)redhat.com>
dzickus pointed out that my change is not optimal. CONFIG_CRYPTO_SHA512
can be moved to the common/generic directory since it is enabled on
both Fedora and ARK.
Cleanup the CONFIG_CRYPTO_SHA512 files.
Signed-off-by: Prarit Bhargava <prarit(a)redhat.com>
Cc: dzickus(a)redhat.com
Cc: jforbes(a)redhat.com
---
redhat/configs/{ark => common}/generic/CONFIG_CRYPTO_SHA512 | 0
1 file changed, 0 insertions(+), 0 deletions(-)
rename redhat/configs/{ark => common}/generic/CONFIG_CRYPTO_SHA512 (100%)
diff --git a/redhat/configs/ark/generic/CONFIG_CRYPTO_SHA512 b/redhat/configs/common/generic/CONFIG_CRYPTO_SHA512
similarity index 100%
rename from redhat/configs/ark/generic/CONFIG_CRYPTO_SHA512
rename to redhat/configs/common/generic/CONFIG_CRYPTO_SHA512
--
GitLab
3 years, 6 months
[OS-BUILD PATCH] Point pathfix to the new location for
gen_compile_commands.py
by GitLab Bridge on behalf of jmflinuxtx
From: "Justin M. Forbes" <jforbes(a)fedoraproject.org>
The existing call for pathfix.py fails because
scripts/gen_compile_commands.py is no longer present. It has been moved
to scripts/clang-tools and another script has been added there as well,
so fix up the directory.
Signed-off-by: Justin M. Forbes <jforbes(a)fedoraproject.org>
---
redhat/kernel.spec.template | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/redhat/kernel.spec.template b/redhat/kernel.spec.template
index 7cbfb9c139eb..81bdad537a10 100644
--- a/redhat/kernel.spec.template
+++ b/redhat/kernel.spec.template
@@ -1252,7 +1252,7 @@ pathfix.py -i "%{__python3} %{py3_shbang_opts}" -p -n \
tools/perf/scripts/python/sched-migration.py \
tools/testing/selftests/drivers/net/mlxsw/sharedbuffer_configuration.py \
Documentation \
- scripts/gen_compile_commands.py
+ scripts/clang-tools
# only deal with configs if we are going to build for the arch
%ifnarch %nobuildarches
--
GitLab
3 years, 6 months
[OS-BUILD PATCH] s390: correct __bootdata / __bootdata_preserved
macros
by GitLab Bridge on behalf of jmflinuxtx
From: Vasily Gorbik <gor(a)linux.ibm.com>
Currently s390 build is broken.
SECTCMP .boot.data
error: section .boot.data differs between vmlinux and arch/s390/boot/compressed/vmlinux
make[2]: *** [arch/s390/boot/section_cmp.boot.data] Error 1
SECTCMP .boot.preserved.data
error: section .boot.preserved.data differs between vmlinux and arch/s390/boot/compressed/vmlinux
make[2]: *** [arch/s390/boot/section_cmp.boot.preserved.data] Error 1
make[1]: *** [bzImage] Error 2
Commit 33def8498fdd ("treewide: Convert macro and uses of __section(foo)
to __section("foo")") converted all __section(foo) to __section("foo").
This is wrong for __bootdata / __bootdata_preserved macros which want
variable names to be a part of intermediate section names .boot.data.<var
name> and .boot.preserved.data.<var name>. Those sections are later
sorted by alignment + name and merged together into final .boot.data
/ .boot.preserved.data sections. Those sections must be identical in
the decompressor and the decompressed kernel (that is checked during
the build).
Fixes: 33def8498fdd ("treewide: Convert macro and uses of __section(foo) to __section("foo")")
Signed-off-by: Vasily Gorbik <gor(a)linux.ibm.com>
Signed-off-by: Heiko Carstens <hca(a)linux.ibm.com>
---
arch/s390/include/asm/sections.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/s390/include/asm/sections.h b/arch/s390/include/asm/sections.h
index a996d3990a02..0c2151451ba5 100644
--- a/arch/s390/include/asm/sections.h
+++ b/arch/s390/include/asm/sections.h
@@ -26,14 +26,14 @@ static inline int arch_is_kernel_initmem_freed(unsigned long addr)
* final .boot.data section, which should be identical in the decompressor and
* the decompressed kernel (that is checked during the build).
*/
-#define __bootdata(var) __section(".boot.data.var") var
+#define __bootdata(var) __section(".boot.data." #var) var
/*
* .boot.preserved.data is similar to .boot.data, but it is not part of the
* .init section and thus will be preserved for later use in the decompressed
* kernel.
*/
-#define __bootdata_preserved(var) __section(".boot.preserved.data.var") var
+#define __bootdata_preserved(var) __section(".boot.preserved.data." #var) var
extern unsigned long __sdma, __edma;
extern unsigned long __stext_dma, __etext_dma;
--
GitLab
3 years, 6 months
[OS-BUILD PATCH] [redhat] New configs in drivers/phy
by GitLab Bridge on behalf of jeremycline
From: Fedora Kernel Team <kernel-team(a)fedoraproject.org>
Hi,
As part of the ongoing rebase effort, the following configuration
options need to be reviewed.
As a reminder, the ARK configuration flow involves moving unreviewed
configuration options from the pending directory to the ark directory.
In the diff below, options are removed from the pending directory and
added to the ark hierarchy. The final options that need to be ACKed
are the files that are being added to the ark hierarchy.
If the value for a file that is added should be changed, please reply
with a better option.
CONFIG_PHY_INTEL_KEEMBAY_EMMC:
Choose this option if you have an Intel Keem Bay SoC.
To compile this driver as a module, choose M here: the module
will be called phy-keembay-emmc.ko.
Symbol: PHY_INTEL_KEEMBAY_EMMC [=n]
Type : tristate
Defined at drivers/phy/intel/Kconfig:5
Prompt: Intel Keem Bay EMMC PHY driver
Depends on: (OF [=y] && ARM64 [=y] || COMPILE_TEST [=n]) && HAS_IOMEM [=y]
Location:
-> Device Drivers
-> PHY Subsystem
Selects: GENERIC_PHY [=y] && REGMAP_MMIO [=y]
---
CONFIG_PHY_INTEL_LGM_EMMC:
Enable this to support the Intel EMMC PHY
Symbol: PHY_INTEL_LGM_EMMC [=n]
Type : tristate
Defined at drivers/phy/intel/Kconfig:31
Prompt: Intel Lightning Mountain EMMC PHY driver
Depends on: X86 [=y] || COMPILE_TEST [=n]
Location:
-> Device Drivers
-> PHY Subsystem
Selects: GENERIC_PHY [=n]
---
CONFIG_USB_LGM_PHY:
Enable this to support Intel DWC3 PHY USB phy. This driver provides
interface to interact with USB GEN-II and USB 3.x PHY that is part
of the Intel network SOC.
Symbol: USB_LGM_PHY [=n]
Type : tristate
Defined at drivers/phy/Kconfig:52
Prompt: INTEL Lightning Mountain USB PHY Driver
Depends on: USB_SUPPORT [=y]
Location:
-> Device Drivers
-> PHY Subsystem
Selects: USB_PHY [=n] && REGULATOR [=n] && REGULATOR_FIXED_VOLTAGE [=n]
---
Cc: John Linville <linville(a)redhat.com>
Signed-off-by: Fedora Kernel Team <kernel-team(a)fedoraproject.org>
---
.../generic/CONFIG_PHY_INTEL_KEEMBAY_EMMC | 1 +
.../common/generic/CONFIG_PHY_INTEL_LGM_EMMC | 1 +
.../configs/common/generic/CONFIG_USB_LGM_PHY | 1 +
.../generic/CONFIG_PHY_INTEL_KEEMBAY_EMMC | 20 -------------------
.../generic/CONFIG_PHY_INTEL_LGM_EMMC | 17 ----------------
.../pending-common/generic/CONFIG_USB_LGM_PHY | 19 ------------------
6 files changed, 3 insertions(+), 56 deletions(-)
create mode 100644 redhat/configs/common/generic/CONFIG_PHY_INTEL_KEEMBAY_EMMC
create mode 100644 redhat/configs/common/generic/CONFIG_PHY_INTEL_LGM_EMMC
create mode 100644 redhat/configs/common/generic/CONFIG_USB_LGM_PHY
delete mode 100644 redhat/configs/pending-common/generic/CONFIG_PHY_INTEL_KEEMBAY_EMMC
delete mode 100644 redhat/configs/pending-common/generic/CONFIG_PHY_INTEL_LGM_EMMC
delete mode 100644 redhat/configs/pending-common/generic/CONFIG_USB_LGM_PHY
diff --git a/redhat/configs/common/generic/CONFIG_PHY_INTEL_KEEMBAY_EMMC b/redhat/configs/common/generic/CONFIG_PHY_INTEL_KEEMBAY_EMMC
new file mode 100644
index 000000000000..6cc2e21fa59f
--- /dev/null
+++ b/redhat/configs/common/generic/CONFIG_PHY_INTEL_KEEMBAY_EMMC
@@ -0,0 +1 @@
+# CONFIG_PHY_INTEL_KEEMBAY_EMMC is not set
diff --git a/redhat/configs/common/generic/CONFIG_PHY_INTEL_LGM_EMMC b/redhat/configs/common/generic/CONFIG_PHY_INTEL_LGM_EMMC
new file mode 100644
index 000000000000..e268046158e3
--- /dev/null
+++ b/redhat/configs/common/generic/CONFIG_PHY_INTEL_LGM_EMMC
@@ -0,0 +1 @@
+# CONFIG_PHY_INTEL_LGM_EMMC is not set
diff --git a/redhat/configs/common/generic/CONFIG_USB_LGM_PHY b/redhat/configs/common/generic/CONFIG_USB_LGM_PHY
new file mode 100644
index 000000000000..793c45154118
--- /dev/null
+++ b/redhat/configs/common/generic/CONFIG_USB_LGM_PHY
@@ -0,0 +1 @@
+# CONFIG_USB_LGM_PHY is not set
diff --git a/redhat/configs/pending-common/generic/CONFIG_PHY_INTEL_KEEMBAY_EMMC b/redhat/configs/pending-common/generic/CONFIG_PHY_INTEL_KEEMBAY_EMMC
deleted file mode 100644
index 6c71e4d3ca8e..000000000000
--- a/redhat/configs/pending-common/generic/CONFIG_PHY_INTEL_KEEMBAY_EMMC
+++ /dev/null
@@ -1,20 +0,0 @@
-# CONFIG_PHY_INTEL_KEEMBAY_EMMC:
-#
-# Choose this option if you have an Intel Keem Bay SoC.
-#
-# To compile this driver as a module, choose M here: the module
-# will be called phy-keembay-emmc.ko.
-#
-# Symbol: PHY_INTEL_KEEMBAY_EMMC [=n]
-# Type : tristate
-# Defined at drivers/phy/intel/Kconfig:5
-# Prompt: Intel Keem Bay EMMC PHY driver
-# Depends on: (OF [=y] && ARM64 [=y] || COMPILE_TEST [=n]) && HAS_IOMEM [=y]
-# Location:
-# -> Device Drivers
-# -> PHY Subsystem
-# Selects: GENERIC_PHY [=y] && REGMAP_MMIO [=y]
-#
-#
-#
-# CONFIG_PHY_INTEL_KEEMBAY_EMMC is not set
diff --git a/redhat/configs/pending-common/generic/CONFIG_PHY_INTEL_LGM_EMMC b/redhat/configs/pending-common/generic/CONFIG_PHY_INTEL_LGM_EMMC
deleted file mode 100644
index e63273fb44de..000000000000
--- a/redhat/configs/pending-common/generic/CONFIG_PHY_INTEL_LGM_EMMC
+++ /dev/null
@@ -1,17 +0,0 @@
-# CONFIG_PHY_INTEL_LGM_EMMC:
-#
-# Enable this to support the Intel EMMC PHY
-#
-# Symbol: PHY_INTEL_LGM_EMMC [=n]
-# Type : tristate
-# Defined at drivers/phy/intel/Kconfig:31
-# Prompt: Intel Lightning Mountain EMMC PHY driver
-# Depends on: X86 [=y] || COMPILE_TEST [=n]
-# Location:
-# -> Device Drivers
-# -> PHY Subsystem
-# Selects: GENERIC_PHY [=n]
-#
-#
-#
-# CONFIG_PHY_INTEL_LGM_EMMC is not set
diff --git a/redhat/configs/pending-common/generic/CONFIG_USB_LGM_PHY b/redhat/configs/pending-common/generic/CONFIG_USB_LGM_PHY
deleted file mode 100644
index d2d16f0accfd..000000000000
--- a/redhat/configs/pending-common/generic/CONFIG_USB_LGM_PHY
+++ /dev/null
@@ -1,19 +0,0 @@
-# CONFIG_USB_LGM_PHY:
-#
-# Enable this to support Intel DWC3 PHY USB phy. This driver provides
-# interface to interact with USB GEN-II and USB 3.x PHY that is part
-# of the Intel network SOC.
-#
-# Symbol: USB_LGM_PHY [=n]
-# Type : tristate
-# Defined at drivers/phy/Kconfig:52
-# Prompt: INTEL Lightning Mountain USB PHY Driver
-# Depends on: USB_SUPPORT [=y]
-# Location:
-# -> Device Drivers
-# -> PHY Subsystem
-# Selects: USB_PHY [=n] && REGULATOR [=n] && REGULATOR_FIXED_VOLTAGE [=n]
-#
-#
-#
-# CONFIG_USB_LGM_PHY is not set
--
GitLab
3 years, 6 months